2. 정책

1. 오픈소스 정책 문서화

기업은 공급 소프트웨어 개발, 서비스, 배포에 관여하는 조직이 올바르게 오픈소스를 활용하기 위한 원칙으로 구성된 오픈소스 정책을 수립하여 문서화하고 이를 조직 내 전파해야 합니다.

이를 위해 ISO 표준은 공통적으로 다음과 같이 문서화된 오픈소스 정책 및 보안 보증 정책을 요구합니다.

일반적인 오픈소스 정책은 다음을 포함합니다. 기업은 이러한 원칙을 포함한 오픈소스 정책을 만들어서 문서화해야 합니다:

1. 공급 소프트웨어 제품과 서비스 배포 시 오픈소스 라이선스 컴플라이언스 및 보안 취약점 리스크를 최소화하기 위한 원칙
2. 외부 오픈소스 프로젝트에 기여하기 위한 원칙
3. 기업의 소프트웨어를 오픈소스로 공개하기 위한 원칙
4. 오픈소스 소프트웨어 컴포넌트의 SBOM(Software Bill of Materials) 생성 및 관리 원칙
5. 알려진 취약점 및 새로 발견된 취약점에 대한 대응 원칙

또한 오픈소스 정책은 프로그램 참여자에게 전파되어야 하며, 정기적으로 검토 및 업데이트되어야 합니다. 이를 통해 정책이 항상 최신 상태를 유지하고 조직의 요구사항을 반영할 수 있도록 해야 합니다.

2. 오픈소스 정책에서 다뤄야할 내용

오픈소스 정책은 다음과 같은 핵심 내용을 포함해야 합니다:

(1) 오픈소스 라이선스 컴플라이언스 원칙

오픈소스 라이선스 컴플라이언스를 위해 다음 원칙을 수립해야 합니다:

• 오픈소스 식별 및 라이선스 의무 사항 검토
• 오픈소스 라이선스를 고려한 설계
• 컴플라이언스 산출물 생성 및 관리
• SBOM 생성 및 관리
• 컴플라이언스 이슈 대응 절차

[부록1] 오픈소스 정책 template의 4. 오픈소스 라이선스 컴플라이언스에서 이를 문서화한 원칙을 살펴보실 수 있습니다.

## 4. 오픈소스 라이선스 컴플라이언스

이 섹션에서는 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 라이선스 의무를 준수하기 위한 절차를 설명합니다. 이를 통해 회사는 오픈소스 라이선스 컴플라이언스를 보장하고, 법적 위험을 최소화할 수 있습니다.

### 4.1 오픈소스 식별 및 라이선스 의무 사항 검토

1. **오픈소스 식별**:
    - 공급 소프트웨어 개발 시 사용되는 모든 오픈소스 컴포넌트를 식별합니다.
    - SCA(Software Composition Analysis) 도구를 활용하여 오픈소스 컴포넌트를 자동으로 탐지하고 기록합니다.
2. **라이선스 의무 사항 검토**:
    - 식별된 오픈소스 컴포넌트의 라이선스를 검토하고, 각 라이선스가 요구하는 의무 사항을 확인합니다.
    - 회사의 [오픈소스 라이선스 가이드]를 참고하여 라이선스를 이해하고, 법무팀과 협력하여 호환성 문제를 해결합니다.

### 4.2 오픈소스 라이선스를 고려한 설계

1. **소프트웨어 아키텍처 설계**:
    - 오픈소스 라이선스의 영향을 최소화하기 위해 소프트웨어 아키텍처를 설계합니다.
    - 오픈소스 컴포넌트와 자사 코드 간의 결합 관계를 파악하여 라이선스 의무를 준수합니다.
2. **라이선스 호환성 검토**:
    - 여러 오픈소스 컴포넌트의 라이선스가 서로 호환되는지 검토합니다.
    - 호환되지 않는 라이선스를 사용하는 경우, 대체 가능한 컴포넌트를 제안하거나 적절한 조치를 취합니다.

### 4.3 컴플라이언스 산출물 생성 및 관리

1. **오픈소스 고지문 생성**:
    - 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 저작권 정보와 라이선스를 포함한 고지문을 작성합니다.
    - 고지문은 각 라이선스가 요구하는 조건에 따라 작성되며, 배포 패키지에 포함됩니다.
2. **공개할 소스 코드 패키지 생성**:
    - GPL, LGPL 등 소스 코드 공개를 요구하는 라이선스를 준수하기 위해 필요한 소스 코드 패키지를 생성합니다.
    - 소스 코드 패키지는 별도의 저장소에 안전하게 보관되며, 외부 요청 시 제공됩니다.
3. **컴플라이언스 산출물 배포 및 보관**:
    - 모든 컴플라이언스 산출물은 공급 소프트웨어와 함께 배포되며, 내부 저장소에서 체계적으로 관리됩니다.
    - 외부 요청 시 산출물을 제공할 수 있는 시스템을 운영합니다.

### 4.4 SBOM 생성 및 관리

1. **SBOM 생성**:
    - 공급 소프트웨어를 구성하는 모든 오픈소스 컴포넌트의 SBOM(Software Bill of Materials)을 생성합니다.
    - SBOM에는 각 컴포넌트의 이름, 버전, 라이선스 정보, 다운로드 위치 등이 포함됩니다.
2. **SBOM 유지 및 업데이트**:
    - SBOM은 소프트웨어 릴리스마다 업데이트되며, 최신 상태를 유지합니다.
    - SBOM은 내부 저장소에서 안전하게 관리되며, 외부 요청 시 제공할 수 있도록 준비됩니다.
3. **오픈소스 컴포넌트 기록 관리**: 
    - 각 오픈소스 컴포넌트에 대해 상세한 기록을 유지합니다. 이 기록에는 다음 정보가 포함됩니다:
        a. 컴포넌트 식별 정보 (이름, 버전, 출처)
        b. 라이선스 정보 및 의무사항
        c. 사용 목적 및 방식
        d. 수정 여부 및 수정 내용
        e. 취약점 분석 결과 및 대응 조치
        
    - 이 기록은 정기적으로 검토 및 업데이트되며, 문서화된 절차에 따라 관리됩니다.
4. **기록 검증 절차**: 
    - 분기별로 오픈소스 컴포넌트 기록의 정확성과 완전성을 검증합니다.
    - 검증 결과는 문서화하여 보관하며, 필요시 개선 조치를 수행합니다.

### 4.5 컴플라이언스 이슈 대응 절차

1. **이슈 확인 및 대응**:
    - 컴플라이언스 이슈 발생 시, 오픈소스 프로그램 매니저는 즉시 이슈를 확인하고 대응 방안을 마련합니다.
    - 법무팀과 협력하여 이슈의 심각성을 평가하고 필요한 조치를 결정합니다.
2. **대응 기록 유지**:
    - 모든 대응 과정은 Jira 또는 기타 이슈 추적 시스템을 통해 기록되고 보존됩니다.
    - 대응 기록은 정기적으로 검토되어 향후 유사한 문제 발생 시 참고 자료로 활용됩니다.

(2) 오픈소스 보안 보증 원칙

오픈소스 보안 보증을 위해 다음 원칙을 수립해야 합니다:

• 알려진 취약점 탐지 및 대응 절차
• 새로 발견된 취약점 대응 절차
• 지속적인 모니터링 및 대응
• 내부 모범 사례와의 일치 여부 확인

[부록1] 오픈소스 정책 template의 5. 오픈소스 보안 보증에서 이를 문서화한 원칙을 살펴보실 수 있습니다.

## 5. 오픈소스 보안 보증

이 섹션에서는 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안을 보장하기 위한 절차를 설명합니다. 이를 통해 회사는 알려진 취약점과 새로 발견된 취약점을 효과적으로 관리하고, 소프트웨어의 보안 수준을 높일 수 있습니다.

### 5.1 알려진 취약점 탐지 및 대응 절차

1. **취약점 탐지**:
    - SCA(Software Composition Analysis) 도구를 활용하여 SBOM에 포함된 각 오픈소스 컴포넌트의 알려진 취약점을 탐지합니다.
    - NVD(국가 취약점 데이터베이스), CVE(Common Vulnerabilities and Exposures) 등과 같은 취약점 데이터베이스를 정기적으로 업데이트하여 최신 정보를 확인합니다.
2. **취약점 심각도 평가**:
    - CVSS(Common Vulnerability Scoring System) 점수를 활용하여 취약점의 심각도를 평가합니다.
    - 취약점의 익스플로잇 가능성, 영향 범위, 그리고 시스템에 미치는 잠재적인 영향을 고려하여 대응 우선순위를 결정합니다.
3. **대응 조치**:
    - 고위험 취약점에 대해서는 즉시 패치를 적용하거나 완화 조치를 수행합니다.
    - 고객에게 영향을 미칠 수 있는 경우, 고객에게 통지하고 해결 방안을 제시합니다.
4. **대응 기록 유지**:
    - 모든 취약점과 대응 조치는 데이터베이스에 기록되며, 정기적으로 보고서를 생성합니다.
    - 대응 기록은 향후 유사한 문제 발생 시 참고 자료로 활용됩니다.

### 5.2 새로 발견된 취약점 대응 절차

1. **새로 발견된 취약점 탐지**:
    - 이전에 발견되지 않았던 새로운 보안 취약점을 식별하고 평가합니다.
    - 새로 발견된 취약점은 외부 연구자나 내부 테스트를 통해 보고될 수 있습니다.
2. **심각도 평가 및 대응**:
    - 새로 발견된 취약점의 심각도를 CVSS 점수를 활용하여 평가합니다.
    - 평가 결과에 따라 대응 우선순위를 결정하고 필요한 조치를 수행합니다.
    - 고객에게 영향을 미칠 수 있는 경우, 고객에게 통지하고 해결 방안을 제시합니다.
3. **대응 기록 유지**:
    - 새로 발견된 취약점과 대응 조치는 데이터베이스에 기록되며, 정기적으로 보고서를 생성합니다.

### 5.3 지속적인 모니터링 및 대응

1. **취약점 모니터링**:
    - 소프트웨어 릴리스 후에도 지속적으로 소프트웨어를 모니터링하여 알려진 취약점 또는 새로 발견된 취약점을 식별합니다.
    - 자동화된 도구를 활용하여 최신 데이터를 기반으로 이상 징후를 탐지합니다.
2. **대응 준비**:
    - 보안 전문가가 대응을 준비하며, 필요 시 외부 전문가의 도움을 받습니다.
    - 대응 계획은 정기적으로 검토되고 업데이트됩니다.
3. **보고 및 개선**:
    - 모든 모니터링 및 대응 활동은 정기적으로 보고되며, 프로그램 참여자와 공유됩니다.
    - 모니터링 결과를 바탕으로 프로세스를 개선하여 보안 수준을 지속적으로 향상시킵니다.

### 5.4 내부 모범 사례와의 일치 여부 확인

1. **내부 모범 사례 조사**:
    - 회사 내 다른 팀이나 부서에서 성공적으로 운영 중인 보안 관련 활동 및 프로세스를 조사합니다.
    - 예: 정보보안팀의 취약점 관리 프로세스, 개발팀의 안전한 코딩 가이드라인 등.
2. **프로세스 비교 및 분석**:
    - 조사된 모범 사례와 오픈소스 보안 보증 프로그램 간의 운영 방식을 비교 분석합니다.
    - 차이점, 약점, 그리고 개선 기회를 식별합니다.
3. **프로세스 통합 및 개선**:
    - 오픈소스 보안 보증 프로그램을 회사 내부 모범 사례에 맞게 조정하거나 통합합니다.
    - 예: 회사 전체에서 사용하는 취약점 관리 시스템을 오픈소스 취약점 관리에도 적용.
4. **담당자 지정 및 관리**:
    - OSPM이 내부 모범 사례 준수를 담당하며, 정기적으로 운영 방식을 검토하고 개선 사항을 제안합니다.

(3) 내부 책임 할당 절차

오픈소스 정책은 오픈소스 관리 이슈를 해결하기 위한 책임을 내부에 할당하는 절차를 다뤄야 합니다.

ISO 표준은 공통적으로 다음과 같이 내부 책임을 할당하는 문서화된 절차를 요구합니다.

오픈소스 프로그램 매니저는 라이선스 컴플라이언스 이슈를 파악하고 이를 해결하기 위해 각 역할의 담당자에게 적절히 책임을 할당해야 합니다. 마찬가지로 오픈소스 보안 취약점 이슈에 대해서는 보안 담당이 이슈를 파악하고 이를 해결하기 위해 적절한 인원에게 책임을 할당합니다.

이를 위해 아래의 예시와 같이 오픈소스 정책에 내부 책임을 할당하는 문서화된 절차를 반영할 수 있습니다.

### 3.3 내부 책임 할당 절차

1. 책임 할당 절차:  
    1. 오픈소스 프로그램 매니저(OSPM)가 연간 책임 할당 회의를 소집합니다.
    2. 각 부서장(법무, IT, 보안, 개발, 품질 등)과 협의하여 활동별 책임자를 선정합니다.
    3. 선정된 책임자 목록을 OSRB(Open Source Review Board)에 제출하여 최종 승인을 받습니다.
    
2. 책임과 권한의 균형:
    - 각 책임자에게는 해당 업무를 수행하는 데 필요한 적절한 권한이 부여됩니다.
    - 책임 수행에 필요한 자원(예: 예산, 인력)을 요청할 수 있는 권한을 갖습니다.
3. 정기적인 검토 및 업데이트:
    - OSRB는 연 1회 이상 책임 할당 현황을 검토하고 필요시 조정합니다.
    - 조직 구조 변경, 인사 이동 등 주요 변화가 있을 때마다 즉시 책임 할당을 갱신합니다.
4. 문서화:
    - 책임 할당 결과는 공식 문서로 작성하여 회사의 문서 관리 시스템에 등록합니다.
    - 문서에는 각 활동, 책임자, 역할, 필요 역량이 명시됩니다.
5. 교육 및 인식 제고:
    - 새로 할당된 책임자에 대해 필요한 교육을 제공합니다.
    - 전체 조직을 대상으로 책임 할당 결과를 공유하여 인식을 제고합니다.

이러한 절차를 통해 오픈소스 라이선스 컴플라이언스와 보안 보증에 대한 내부 책임을 명확히 할당하고, 각 담당자가 자신의 역할을 이해하고 수행할 수 있도록 합니다. 또한 OSRB(Open Source Review Board)와의 협의를 통해 조직 전체의 오픈소스 전략과 일관성을 유지할 수 있습니다.

내부 책임 할당 절차는 정기적으로 검토하고 업데이트해야 하며, 조직의 구조나 프로젝트의 변화에 따라 유연하게 조정될 수 있어야 합니다. 이를 통해 오픈소스 관리의 효율성과 효과성을 지속적으로 개선할 수 있습니다.

(4) 미준수 사례 대응

기업은 오픈소스 라이선스 컴플라이언스 및 보안 보증 미준수 사례가 발생하면 이를 신속히 검토하고 대응하기 위한 절차를 문서화해야 합니다.

ISO/IEC 5230는 다음과 같이 미준수 사례를 검토하고 이를 수정하기 위한 문서화된 절차를 요구합니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 정책에 미준수 사례를 검토하고 이를 수정하기 위한 문서화된 절차를 반영할 수 있습니다.

### 4.5 컴플라이언스 이슈 대응 절차

1. **이슈 확인 및 대응**:
    - 컴플라이언스 이슈 발생 시, 오픈소스 프로그램 매니저는 즉시 이슈를 확인하고 대응 방안을 마련합니다.
    - 법무팀과 협력하여 이슈의 심각성을 평가하고 필요한 조치를 결정합니다.
2. **대응 기록 유지**:
    - 모든 대응 과정은 Jira 또는 기타 이슈 추적 시스템을 통해 기록되고 보존됩니다.
    - 대응 기록은 정기적으로 검토되어 향후 유사한 문제 발생 시 참고 자료로 활용됩니다.

이러한 절차를 통해 기업은 오픈소스 라이선스 컴플라이언스 및 보안 보증과 관련된 미준수 사례를 체계적으로 관리하고, 지속적인 개선을 도모할 수 있습니다. 또한, SPDX와 같은 표준화된 형식을 사용하여 라이선스 및 보안 정보를 관리하면, 미준수 사례를 더욱 효과적으로 식별하고 대응할 수 있습니다.

(5) 인원, 예산 지원

기업은 오픈소스 프로그램이 원활하게 기능을 수행할 수 있도록 충분한 리소스를 제공해야 합니다. 프로그램 내 각 역할을 담당하는 인원을 적합하게 배치하고, 충분한 예산과 업무 시간을 보장해야 합니다. 그렇지 않을 경우, 이를 보완할 수 있는 절차가 마련되어야 합니다.

ISO 표준은 공통적으로 다음과 같이 프로그램 내 각 역할을 담당하는 인원이 적합하게 배치되고, 예산이 적절하게 지원되어야 함을 요구합니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 정책에 인원, 예산 지원에 대한 내용을 반영할 수 있습니다:

### 3.2 인력 배치 및 자금 지원

1. 적절한 인력 배치:
    - 각 역할에 대해 필요한 역량과 전문성을 갖춘 적절한 인력을 배치합니다.
    - 각 부서의 장은 해당 역할을 수행할 수 있는 적합한 담당자를 지정해야 합니다.
2. 충분한 자금 지원:
    - 회사는 각 역할 수행에 필요한 충분한 예산과 자원을 제공합니다.
    - 예산 항목에는 교육, 도구 사용료, 외부 컨설팅 비용 등이 포함됩니다.
3. 정기적인 검토:
    - OSRB는 연 1회 이상 각 역할의 인력 배치와 자금 지원 상태를 검토하며, 필요 시 조정을 권고합니다.
    - 검토 결과는 문서화되어 OSPO(Open Source Program Office)에 보고됩니다.
4. 문제 해결 절차:
    - 각 부서의 담당자는 필요한 지원(인력 또는 자금)이 부족할 경우, 이를 즉시 오픈소스 프로그램 매니저에게 보고해야 합니다.
    - 오픈소스 프로그램 매니저는 관련 부서와 협력하여 문제를 해결하며, 필요 시 OSRB에 문제 해결을 요청합니다.

추가적으로, 기업은 다음과 같은 사항을 고려하여 인원 및 예산 지원을 강화할 수 있습니다:

1. 오픈소스 프로그램 매니저에게 전담 인력 할당
2. 오픈소스 라이선스 컴플라이언스 및 보안 보증을 위한 전문 도구 구매 예산 확보
3. 프로그램 참여자의 교육 및 역량 강화를 위한 예산 책정
4. 외부 전문가 자문을 위한 예산 할당
5. 정기적인 인력 및 예산 검토 프로세스 수립

이러한 지원을 통해 기업은 오픈소스 라이선스 컴플라이언스와 보안 보증 프로그램의 효과성을 높이고, ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 충족할 수 있습니다.

(6) 전문 자문 제공

기업은 각 역할의 담당자가 오픈소스 이슈를 해결하기 위해 전문적인 검토가 필요할 경우, 이에 대한 자문을 요청할 수 있는 방법을 제공해야 합니다.

ISO 표준은 공통적으로 다음과 같이 문제 해결을 위해 내부 또는 외부의 전문 자문을 이용할 수 있는 방법을 요구합니다.

오픈소스 라이선스 컴플라이언스 이슈에 대해서는 회사 내의 법무팀을 통해 우선 담당하고, 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인을 이용할 수 있습니다.

오픈소스 보안 취약점 이슈에 대해서는 회사 내 보안팀에서 우선 담당하고, 이슈가 복잡하고 첨예한 경우, 외부 보안 전문 기술 업체에 자문을 요청할 수 있습니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 정책에 자문을 제공하기 위한 내용을 반영할 수 있습니다.

### 6.5 전문 지식 식별 및 활용

1. **필요한 전문 분야 식별**:
    - 프로그램 운영에 필요한 기술적 및 법률적 전문 분야를 정기적으로 식별합니다.
    - 예: 웹 보안, 암호화, 네트워크 보안, 시스템 관리, 오픈소스 라이선스 해석 등.
2. **내부 전문가 목록 작성 및 최신화**:
    - 회사 내에서 해당 분야의 전문성을 가진 인력 목록을 작성하고 정기적으로 업데이트합니다.
    - 각 전문가의 경력, 자격증, 그리고 연락처 정보를 기록합니다.
3. **외부 자원 확보 계획 수립**:
    - 내부적으로 해결하기 어려운 문제에 대비하여 외부 전문가 또는 컨설팅 업체를 활용할 수 있는 계획을 수립합니다.
    - 신뢰할 수 있는 외부 자원을 확보하고 계약 조건을 명확히 정의합니다.
4. **전문 지식 접근 절차 마련**:
    - 프로그램 참여자가 필요한 전문 지식에 쉽게 접근할 수 있도록 절차를 마련합니다.
    - 예: 내부 전문가에게 문의하는 방법, 외부 컨설팅 업체를 활용하는 방법 등.

참고로, OpenChain 프로젝트에서는 파트너 프로그램을 통해 오픈소스 관련 자문을 제공하는 글로벌 법무법인 리스트를 제공합니다: https://www.openchainproject.org/partners

OpenChain 파트너로 등록된 법무법인은 OpenChain 프로젝트에서 요구하는 요건을 충족한 곳들이며, 대한민국에서는 유일하게 법무법인 태평양이 등록되어 있습니다.

(7) 적용 범위 지정

하나의 오픈소스 정책(프로그램)을 반드시 전체 조직에 적용해야 하는 것은 아닙니다. 기업 내 각 조직과 제품의 특성에 따라 적용 범위를 달리 지정할 수 있습니다. 예를 들어, 공급 소프트웨어를 전혀 배포하지 않는 조직은 오픈소스 프로그램의 적용 범위에서 제외할 수 있습니다.

ISO 표준은 공통적으로 다음과 같이 프로그램의 적용 범위와 한계를 명확하게 정의한 문서화된 진술 등을 요구합니다.

기업은 조직과 제품의 특성을 고려하여 오픈소스 프로그램의 적용 범위와 한계를 명확히 정의하고, 이를 오픈소스 정책에 명시해야 합니다.

또한, 비즈니스 환경에 맞추어 변화함에 따라 조직 구조, 제품 및 서비스가 프로그램의 적용 범위를 결정하거나 수정해야 하는 상황이 발생할 수 있습니다. 기업은 적용 범위를 평가하기 위한 측정 기준을 수립하고, 지속적인 개선을 위해 검토, 검사를 수행하여 미흡한 부분을 개선해야 합니다.

이를 위해 기업은 아래와 같이 오픈소스 정책에 다음과 같이 적용 범위에 대해 명확히 정의하고, 활동 이력을 문서화하는 체계를 갖춰야 합니다.

### 1.4 적용 범위

이 정책은 회사가 개발, 배포, 또는 사용하는 모든 소프트웨어 프로젝트에 적용됩니다. 주요 적용 범위는 다음과 같습니다:

- 외부로 제공하거나 배포하는 모든 공급 소프트웨어.
- 외부 오픈소스 프로젝트에 기여하는 활동.
- 내부 프로젝트를 오픈소스로 공개하는 활동.

단, 내부 사용 목적으로만 사용되는 오픈소스는 별도의 검토 절차를 통해 정책 적용 여부를 결정할 수 있습니다.

정책의 적용 범위는 회사의 비즈니스 환경 변화에 따라 정기적으로 검토되고 갱신됩니다.

### 10.1 성과 지표 정의

1. **성과 지표 목록**:
    - 분석한 공급 소프트웨어의 수.
    - 해결된 알려진 취약점 및 새로 발견된 취약점의 수.
    - 컴플라이언스 산출물 생성 및 배포 수.
    - 외부 문의에 대한 응답 시간.
    - 프로그램 참여자의 교육 이수율.
    - 외부 오픈소스 기여 및 공개 프로젝트의 수.
2. **지표 목표 설정**:
    - 각 지표에 대한 목표치를 설정하여 프로그램의 성과를 평가할 수 있도록 합니다.
    - 목표치는 조직의 비즈니스 목표와 프로그램의 목적에 맞추어 설정됩니다.

### 10.2 정기적인 프로그램 평가

1. **평가 주기**:
    - 최소 연 1회 이상 프로그램 평가를 실시합니다.
    - 필요 시, 비즈니스 환경 변화나 주요 이슈 발생 시 추가로 평가를 수행합니다.
2. **평가 절차**:
    - 평가 결과를 문서화하고 OSRB(Open Source Review Board)에 보고합니다.
    - 평가 과정에서 프로그램 참여자의 피드백을 수집하고 반영합니다.
    - 평가 결과는 내부 시스템(예: Jira Issue Tracker)을 통해 기록되고 보존됩니다.
3. **정기적인 정책 검토 및 갱신**:
    - 정책은 정기적으로 검토되고, 필요 시 갱신하여 최신의 오픈소스 동향과 조직의 요구사항을 반영합니다.
    - 이를 통해 프로그램의 효과성을 지속적으로 향상시킵니다.

### 10.3 지속적 개선 계획

1. **개선 영역 식별**:
    - 평가 결과를 바탕으로 개선이 필요한 영역을 식별하고 우선순위를 정합니다.
    - 개선이 필요한 영역에는 프로세스 효율성, 교육 내용, 대응 시간 등이 포함될 수 있습니다.
2. **개선 목표 설정**:
    - 구체적인 개선 목표와 일정을 설정합니다.
    - 개선 활동의 진행 상황은 모니터링되고 문서화됩니다.
3. **개선 결과 반영**:
    - 개선 결과를 다음 평가 주기에 반영하여 프로그램의 효과성을 지속적으로 향상시킵니다.
    - 개선 결과는 프로그램 참여자에게 공유되어 지속적인 개선 의지를 고취시킵니다.

따라서 기업은 오픈소스 정책에 다음과 같이 적용 범위를 명확히 정의하고, 활동 이력을 문서화하는 체계를 갖춰야 합니다.

(8) 외부 문의 대응

오픈소스를 사용하여 개발한 공급 소프트웨어에 대해 고객 및 오픈소스 저작권자가 기업에 오픈소스 관련 문의, 요청 및 클레임을 제기하기 위해 연락을 취하는 경우가 있습니다. 외부 문의 및 요청의 주된 내용은 다음과 같습니다:

• 특정 공급 소프트웨어에 오픈소스가 사용되었는지 문의
• 서면 청약에 언급된 GPL, LGPL 라이선스 하의 소스 코드 제공 요청
• 오픈소스 고지문에 명시되지 않았지만, 공급 소프트웨어에서 발견된 오픈소스에 대한 해명 및 소스 코드 공개 요청
• GPL, LGPL 등의 의무로 공개된 소스 코드에 누락된 파일 및 빌드 방법 제공 요청
• 저작권 표시 요청
• 오픈소스 보안 취약점 관련한 문의 및 요청

기업은 이러한 외부 문의를 처리할 담당자를 지정해야 합니다. 일반적으로 오픈소스 프로그램 매니저가 담당합니다.

외부의 오픈소스 개발자가 특정 기업의 오픈소스 관련 이슈를 논의하기 위해 기업 담당자에게 연락하고 싶어도 연락 방법을 찾지 못하다가 결국 바로 법적 클레임을 제기하는 경우가 있습니다. 이를 방지하기 위해 기업은 제3자가 기업에 오픈소스 관련하여 문의 및 요청을 할 수 있는 연락 방법을 항시 공개적으로 밝혀야 합니다.

ISO 표준은 공통적으로 다음과 같이 제3자가 오픈소스에 대해 문의할 수 있는 공개된 방법을 요구합니다:

외부에서 기업에 오픈소스 관련 문의를 할 수 있도록 다음과 같이 연락 방법을 제공할 수 있습니다:

1. 오픈소스 담당 조직의 대표 이메일 주소를 공개합니다.
2. Linux Foundation의 Open Compliance Directory를 이용합니다.
3. 기업의 오픈소스 웹사이트가 있다면 이를 통해 이메일 주소를 공개합니다.

공급 소프트웨어와 동봉하는 오픈소스 고지문에 오픈소스 담당 조직의 대표 이메일 주소를 포함하여 공개하는 것도 좋은 방법입니다.

기업은 아래의 예시와 같이 오픈소스 정책에 외부 문의 대응에 대한 내용을 반영할 수 있습니다:

## 9. 외부 문의 대응

이 섹션에서는 외부에서 오픈소스 관련 문의나 요청이 있을 때, 특히 오픈소스 라이선스 컴플라이언스 및 오픈소스 보안 취약점과 관련된 사항에 대해 회사가 신속하고 효과적으로 대응하는 절차를 설명합니다. 이를 통해 회사는 외부의 요구에 적절히 대응하고, 법적 위험을 최소화하며, 오픈소스 커뮤니티와의 협력을 증진시킬 수 있습니다.

### 9.1 외부 문의 대응 책임

1. **책임자 지정**:
    - 외부 오픈소스 관련 문의 및 요청에 대한 대응은 **오픈소스 프로그램 매니저(OSPM)** 가 담당합니다.
    - 필요 시, 법무팀(라이선스 컴플라이언스 관련) 또는 보안팀(보안 취약점 관련)과 협력하여 문제를 해결합니다.
2. **문의 전달 절차**:
    - 외부로부터 오픈소스 관련 문의를 받은 모든 프로그램 참여자는 이를 즉시 **오픈소스 프로그램 매니저**에게 전달해야 합니다.
    - 문의 성격에 따라 라이선스 컴플라이언스 또는 보안 취약점 담당 부서로 신속히 분배합니다.

### 9.2 연락처 공개

1. **공개 연락처**:
    - *오픈소스 프로그램 매니저*의 공식 연락처를 공개적으로 제공합니다.
    - 연락처는 다음과 같은 채널에 등록됩니다:
        - 오픈소스 고지문
        - 회사 웹사이트
        - Linux Foundation의 Open Compliance Directory
2. **문의 방법 안내**:
    - 외부에서 오픈소스 관련 문의를 할 수 있는 방법을 명확히 안내합니다.
    - 이메일 주소, 웹사이트 문의 양식 등을 통해 문의를 받을 수 있도록 시스템을 운영합니다.

### 9.3 외부 문의 대응 절차

1. **문의 접수 및 확인**:
    - 외부 문의가 접수되면, **오픈소스 프로그램 매니저**가 즉시 확인하고, 적절한 해결 시간을 명시합니다.
    - 문의 성격을 검토하여 라이선스 컴플라이언스 또는 보안 취약점으로 분류합니다.
        - 라이선스 컴플라이언스: 법무팀과 협력하여 검토 및 대응.
        - 보안 취약점: 보안팀과 협력하여 심각도 평가 및 조치.
2. **대응 수행**:
    - 문의 내용에 따라 적절한 대응 조치를 수행하며, 필요 시 외부 전문가의 도움을 받습니다.
    - 모든 대응 과정은 내부 시스템(예: Jira Tracker)을 통해 기록됩니다.
3. **피드백 제공 및 개선**:
    - 대응 후, 외부 문의자에게 피드백을 제공하며, 필요 시 개선 방안을 제안합니다.
    - 반복적인 문제를 방지하기 위해 대응 기록을 분석하고 프로세스를 개선합니다.

SK텔레콤은 모든 공급 소프트웨어에 오픈소스 고지문을 포함하고 있습니다. 오픈소스 고지문에는 SK텔레콤 오픈소스 웹사이트 주소와 오픈소스 프로그램 오피스로 연락할 수 있는 메일 주소가 함께 제공됩니다.

또한, SK텔레콤 오픈소스 웹사이트에서도 오픈소스 프로그램 오피스로 연락할 수 있는 메일 주소를 제공하고 있습니다.

(9) 오픈소스 기여

글로벌 소프트웨어 기업들은 제품을 만들고 서비스를 제공하는 데 오픈소스를 사용하는 것뿐만 아니라 오픈소스 프로젝트에 기여하고 창출할 수 있는 전략적 가치도 중요시합니다. 그러나 오픈소스 프로젝트 생태계와 커뮤니티 운영 방식에 대한 충분한 이해와 전략 없이 접근한다면 예기치 않게 회사의 명성이 손상되고 법적 위험이 발생할 수 있습니다. 따라서 기업은 오픈소스 프로젝트에 참여하고 기여하기 위한 전략과 정책을 수립하는 것이 중요합니다.

ISO/IEC 5230은 다음과 같이 문서화된 오픈소스 기여 정책을 요구합니다.

이러한 오픈소스 기여에 대한 정책은 [부록1] 오픈소스 정책 샘플 7. 오픈소스 기여에서 확인할 수 있습니다.

## 7. 외부 오픈소스 프로젝트 기여

이 섹션에서는 회사의 프로그램 참여자가 외부 오픈소스 프로젝트에 기여할 때 준수해야 할 절차와 원칙을 설명합니다. 이를 통해 회사는 외부 오픈소스 프로젝트에 적극적으로 참여하면서도, 지식재산 보호와 저작권 문제를 방지할 수 있습니다.

### 7.1 기여 절차

1. **리뷰 요청 및 승인**:
    - 외부 오픈소스 프로젝트에 기여하려는 경우, 프로그램 참여자는 OSPO(Open Source Program Office)에 리뷰 요청 및 승인을 받아야 합니다.
    - OSPO는 기여하려는 코드가 회사의 지식재산을 침해하지 않는지 확인하고, 필요한 경우 법무팀의 검토를 요청합니다.
2. **기여할 권리가 있는 코드만 기여**:
    - 프로그램 참여자는 직접 작성한 코드나 회사가 소유하고 있는 코드만 기여할 수 있습니다.
    - 제3자의 코드를 임의로 기여해서는 안 됩니다.
3. **지식재산 노출 주의**:
    - 민감한 정보, 특허 등 회사의 지식재산이 포함되지 않도록 주의합니다.
    - 기여하려는 코드에 회사의 특허가 포함되어 있다면, OSPO와 법무팀의 검토를 받아야 합니다.

### 7.2 CLA 서명 주의

1. **CLA 검토**:
    - 일부 오픈소스 프로젝트는 기여자에게 CLA(Contributor License Agreement)에 서명할 것을 요구합니다.
    - CLA 서명 전, OSPO에 검토를 요청하여 회사의 지식재산 보호를 보장합니다.
2. **저작권 양도 금지**:
    - 회사는 자사의 지식재산 보호를 위해 저작권 양도를 요구하는 CLA 조건이 있는 오픈소스 프로젝트로의 기여를 허용하지 않습니다.

### 7.3 저작권 표시

1. **저작권 표기**:
    - 프로그램 참여자가 외부 오픈소스 프로젝트에 코드를 기여할 때, 회사의 저작권을 명시해야 합니다.
    - 파일 상단에 다음과 같이 저작권과 라이선스를 표기합니다:
        
        `textCopyright (c) [Year] [Company Name]
        SPDX-License-Identifier: [SPDX_license_name]`
        
2. **회사 이메일 사용**:
    - 오픈소스 프로젝트에 기여할 때는 개인 이메일을 사용하지 말고, 회사 이메일을 사용해야 합니다.
    - 이를 통해 회사를 대표하여 커뮤니티와 소통한다는 책임감을 갖게 됩니다.

### 7.4 기여 기록 유지

1. **기여 이력 관리**:
    - 외부 오픈소스 프로젝트에 기여한 모든 이력을 관리하고, OSPO에 보고합니다.
    - 기여 이력은 내부 시스템(예: Learning Portal)에 최소 3년간 보관됩니다.
2. **기여 활동 평가**:
    - 외부 오픈소스 프로젝트로의 기여 활동은 프로그램 참여자의 성과 평가에 반영됩니다.
    - OSPO는 정기적으로 기여 활동의 효과성을 평가하고, 필요 시 개선 방안을 제안합니다.

오픈소스 기여 정책에는 기여 절차, 승인 프로세스, 지식재산권 보호 방안, CLA (Contributor License Agreement) 서명 지침 등이 포함되어야 합니다. 또한 프로그램 참여자들이 회사를 대표하여 오픈소스 커뮤니티에 참여할 때의 행동 지침도 제공해야 합니다.

3. Summary

오픈소스 정책을 문서화하는 것은 효과적인 오픈소스 관리를 위해 가장 중요한 과정입니다.

다음 페이지에서 위에서 언급한 ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 충족하는 샘플 오픈소스 정책 문서를 제공합니다: [부록1] 오픈소스 정책 (template)

위의 내용을 참고하여 각 요구사항을 회사의 상황에 맞게 적절한 원칙을 수립하는 것이 필요합니다. 또한 문서로만 그치지 않고, 실행 가능한 절차까지 고려해야 합니다. 말뿐인 정책은 소용이 없습니다.

오픈소스 정책은 다음과 같은 핵심 요소를 포함해야 합니다:

1. 오픈소스 라이선스 컴플라이언스 원칙
2. 오픈소스 보안 보증 원칙
3. 내부 책임 할당 정차
4. 미준수 사례 대응
5. 인원, 예산 지원
6. 전문 자문 제공
7. 적용 범위 지정
8. 외부 문의 대응
9. 오픈소스 기여

이러한 요소들을 포함하여 오픈소스 정책을 수립하고 문서화하면, ISO/IEC 5230과 ISO/IEC 18974 표준의 주요 요구사항을 충족할 수 있습니다.

정책은 단순히 문서화에 그치지 않고 조직 내에서 실제로 이행되어야 합니다. 이를 위해 정기적인 검토와 업데이트, 그리고 프로그램 참여자들의 교육이 필요합니다. 효과적인 오픈소스 정책은 조직의 오픈소스 사용과 기여를 체계적으로 관리하고, 잠재적인 법적 및 보안 위험을 최소화하는 데 도움을 줄 것입니다.