오픈소스 정책

1. 목적 및 적용 범위

1.1 목적

이 정책은 회사가 오픈소스 소프트웨어를 안전하고 효과적으로 활용하기 위한 원칙과 절차를 제공합니다. 정책의 주요 목적은 다음과 같습니다:

1. 오픈소스 라이선스 컴플라이언스:
   • 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 라이선스 의무를 준수하고, 관련 법적 요구사항을 충족합니다.
2. 오픈소스 보안 보증:
   • 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을 식별하고, 적절한 대응 조치를 통해 보안 위험을 최소화합니다.
3. 외부 오픈소스 프로젝트로의 기여:
   • 외부 오픈소스 프로젝트에 기여함으로써 오픈소스 커뮤니티와의 협업을 촉진하고, 회사의 지식재산을 보호합니다.
4. 사내 프로젝트의 오픈소스화:
   • 내부 프로젝트를 오픈소스로 공개하여 오픈소스 커뮤니티와의 협력을 증진시키고, 회사의 기술력을 홍보합니다.

이러한 원칙은 ISO/IEC 5230(오픈소스 라이선스 컴플라이언스) 및 ISO/IEC 18974(오픈소스 보안 보증)의 요구사항을 충족하도록 설계되었습니다.

1.2 미준수 시 영향

이 정책을 준수하지 않을 경우, 회사는 다음과 같은 위험에 직면할 수 있습니다:

• 법적 위험: 외부로부터 오픈소스 라이선스 준수 요구를 받을 수 있으며, 법적 소송이나 벌금 부과 위험이 있습니다.
• 평판 손상: 소스 코드 공개 의무 또는 보안 사고로 인해 회사의 평판이 손상될 수 있습니다.
• 비즈니스 손실: 계약 위반으로 인해 고객 또는 공급업체와의 관계가 악화될 수 있습니다.
• 보안 사고 발생: 알려진 취약점 또는 새로 발견된 취약점으로 인해 심각한 보안 사고가 발생할 수 있습니다.

1.3 프로그램 참여자의 기여 방법

회사의 모든 프로그램 참여자는 이 정책을 이해하고 준수해야 합니다. 참여자는 다음과 같은 방식으로 기여할 수 있습니다:

• 자신의 역할에 따라 정책에서 정의된 책임과 의무를 수행합니다.
• 오픈소스 라이선스와 보안 관련 교육을 이수하고, 이를 실무에 적용합니다.
• 정책 준수를 방해하는 문제를 발견하면 즉시 보고합니다.

1.4 적용 범위

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

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

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

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

2. 정의

이 섹션에서는 정책에서 사용되는 주요 용어를 정의합니다. 이러한 정의는 정책의 명확한 이해와 적용을 돕기 위해 필요합니다.

2.1 주요 용어

1. 오픈소스 소프트웨어 (Open Source Software):
   • Open Source Initiative에서 정의한 Open Source Definition 또는 Free Software Foundation에서 정의한 Free Software Definition을 충족하는 소프트웨어를 의미합니다. 이는 사용자들이 소프트웨어를 자유롭게 사용, 수정, 배포할 수 있도록 허용하는 라이선스를 가진 소프트웨어입니다.
2. SBOM (Software Bill of Materials):
   • 소프트웨어를 구성하는 모든 컴포넌트, 라이브러리, 그리고 종속성을 나열한 목록입니다. 이는 소프트웨어의 “재료 목록"과 같으며, 소프트웨어 공급망의 투명성을 확보하고, 잠재적인 보안 취약점과 라이선스 관련 문제를 식별하는 데 사용됩니다.
3. 알려진 취약점 (Known Vulnerability):
   • 이전에 발견된 공개적으로 사용 가능한 보안 취약점을 의미합니다. 이는 NVD, CVE 등과 같은 데이터베이스에서 확인할 수 있습니다.
4. 새로 발견된 취약점 (Newly Discovered Vulnerability):
   • 이전에 발견되지 않았던 새로운 보안 취약점을 의미합니다. 이는 소프트웨어 사용 중에 발견되거나, 외부 연구자에 의해 보고될 수 있습니다.
5. 보안 보증 (Security Assurance):
   • 시스템이 보안 모범 사례에 대한 요구사항을 충족하고, 알려진 취약점에 대해 복원력을 갖추고 있다는 확신을 의미합니다.
6. 검증 자료 (Verification Material):
   • 규격의 주어진 요구사항이 충족되었음을 입증하는 자료입니다. 이는 문서, 기록, 테스트 결과 등 다양한 형태로 제공될 수 있습니다.
7. 공급 소프트웨어 (Supplied Software):
   • 조직이 제3자에게 제공하거나 배포하는 모든 소프트웨어를 의미합니다.
8. 프로그램 (Program):
   • 조직의 오픈소스 라이선스 컴플라이언스 및 보안 보증 활동을 구성하는 정책, 프로세스, 그리고 인력의 집합을 의미합니다.
9. 프로그램 참여자 (Program Participant):
   • 공급 소프트웨어를 정의하고 이에 기여하거나 준비할 책임이 있는 모든 조직 구성원이나 계약자를 의미합니다. 여기에는 소프트웨어 개발자, 릴리스 엔지니어, 품질 엔지니어, 제품 마케팅 및 제품 관리자 등이 포함됩니다.
10. 컴플라이언스 산출물 (Compliance Artifact):
    • 오픈소스 라이선스 컴플라이언스 프로그램의 결과물을 나타내며, 공급 소프트웨어와 함께 제공해야 하는 산출물의 모음입니다. 여기에는 저작자 고지, 소스 코드, 라이선스 사본, 저작권 고지, 수정 내용 고지, 서면 청약(Written Offer) 등이 포함됩니다.
11. 식별된 라이선스 (Identified License):
    • 공급 소프트웨어에 포함된 오픈소스 컴포넌트를 식별하기 위한 적절한 방법으로 식별된 일련의 오픈소스 라이선스 집합을 의미합니다.

3. 역할 및 책임

이 섹션에서는 오픈소스 소프트웨어 관리와 관련된 주요 역할과 책임을 정의합니다. 각 역할은 조직의 오픈소스 라이선스 컴플라이언스와 보안 보증을 보장하기 위해 필수적입니다.

3.1 역할 설명

1. 오픈소스 프로그램 매니저 (OSPM)
   • 책임: 회사의 오픈소스 프로그램에 대한 총괄 책임.
   • 주요 업무:
     • 오픈소스 라이선스 컴플라이언스 및 보안 보증 활동 관리.
     • SBOM 생성 및 유지.
     • 외부 오픈소스 관련 문의 대응.
     • 내부 모범 사례 관리
   • 필요 역량: 소프트웨어 개발 프로세스 이해, 오픈소스 라이선스 전문 지식, 커뮤니케이션 스킬.
2. 법무 담당
   • 책임: 오픈소스 라이선스와 관련된 법적 위험 평가 및 자문 제공.
   • 주요 업무:
     • 오픈소스 라이선스 의무 해석 및 검토.
     • 라이선스 호환성 검토 및 지식재산 보호 조언 제공.
   • 필요 역량: 소프트웨어 저작권 전문 지식, 오픈소스 라이선스 전문 지식, 법적 위험 평가 능력.
3. IT 담당
   • 책임: 오픈소스 분석 도구 운영 및 자동화.
   • 주요 업무:
     • 오픈소스 분석 도구 운영 및 DevOps 환경 통합.
     • SBOM 생성 및 유지 관리.
   • 필요 역량: IT 인프라 전문 지식, 오픈소스 분석 도구 이해, CI/CD 파이프라인 이해.
4. 보안 담당
   • 책임: 오픈소스 보안 취약점 분석 도구 운영.
   • 주요 업무:
     • 알려진 취약점 및 새로 발견된 취약점 대응.
     • DevSecOps 환경 통합 및 보안 조치 수행.
   • 필요 역량: DevSecOps 이해, 보안 취약점 분석 도구 이해, 위험 평가 및 관리 능력.
5. 개발 문화 담당
   • 책임: 사내 개발자들이 오픈소스를 적극적으로 활용하도록 지원.
   • 주요 업무:
     • 오픈소스 커뮤니티 참여 장려 및 개발 문화 개선.
     • 외부 기여 활동 지원.
   • 필요 역량: 소프트웨어 개발 프로세스 이해, 교육 설계 능력, 커뮤니티 참여 경험.
6. 품질 담당
   • 책임: 공급 소프트웨어 배포 시 오픈소스 라이선스 의무 확인.
   • 주요 업무:
     • 컴플라이언스 산출물 생성 확인.
     • 배포 전 라이선스 의무 준수 여부 검토.
   • 필요 역량: 소프트웨어 개발 프로세스 이해, 컴플라이언스 기본 지식.
7. OSRB (Open Source Review Board)
   • 책임: 오픈소스 관리를 위한 정책과 프로세스를 수립 및 개선.
   • 주요 업무:
     • 정책 정기 검토 및 개선.
     • 주요 이슈 논의 및 해결 방안 마련.
   • 필요 역량: 정책 수립 전문 지식, 협의체 운영 경험.
8. OSPO (Open Source Program Office)
   • 책임: 외부 오픈소스 프로젝트 기여와 사내 프로젝트 공개 지원.
   • 주요 업무:
     • 외부 기여 가이드 제공.
     • 사내 프로젝트의 공개 절차 관리.
   • 필요 역량: 커뮤니티 참여 경험, 프로젝트 관리 능력.

3.2 인력 배치 및 자금 지원

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

3.3 내부 책임 할당 절차

1. 책임 할당 절차:

   a. 오픈소스 프로그램 매니저(OSPM)가 연간 책임 할당 회의를 소집합니다.

   b. 각 부서장(법무, IT, 보안, 개발, 품질 등)과 협의하여 활동별 책임자를 선정합니다.

   c. 선정된 책임자 목록을 OSRB(Open Source Review Board)에 제출하여 최종 승인을 받습니다.

2. 책임과 권한의 균형:

   • 각 책임자에게는 해당 업무를 수행하는 데 필요한 적절한 권한이 부여됩니다.
   • 책임 수행에 필요한 자원(예: 예산, 인력)을 요청할 수 있는 권한을 갖습니다.

3. 정기적인 검토 및 업데이트:

   • OSRB는 연 1회 이상 책임 할당 현황을 검토하고 필요시 조정합니다.
   • 조직 구조 변경, 인사 이동 등 주요 변화가 있을 때마다 즉시 책임 할당을 갱신합니다.

4. 문서화:

   • 책임 할당 결과는 공식 문서로 작성하여 회사의 문서 관리 시스템에 등록합니다.
   • 문서에는 각 활동, 책임자, 역할, 필요 역량이 명시됩니다.

5. 교육 및 인식 제고:

   • 새로 할당된 책임자에 대해 필요한 교육을 제공합니다.
   • 전체 조직을 대상으로 책임 할당 결과를 공유하여 인식을 제고합니다.

3.4 담당자 현황

각 역할의 담당 조직과 담당자는 [부록 A: 담당자 현황]에서 확인할 수 있습니다. 필요에 따라 명단은 업데이트됩니다.

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 또는 기타 이슈 추적 시스템을 통해 기록되고 보존됩니다.
   • 대응 기록은 정기적으로 검토되어 향후 유사한 문제 발생 시 참고 자료로 활용됩니다.

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이 내부 모범 사례 준수를 담당하며, 정기적으로 운영 방식을 검토하고 개선 사항을 제안합니다.

6. 교육 및 인식 제고

이 섹션에서는 프로그램 참여자의 역량과 인식을 보장하기 위해 필요한 교육 및 인식 제고 활동을 설명합니다. 이를 통해 참여자는 오픈소스 정책, 관련 프로그램 목표, 그리고 자신의 역할과 책임을 충분히 이해하고, 오픈소스 라이선스 컴플라이언스와 보안 보증에 대한 인식을 높일 수 있습니다.

6.1 오픈소스 교육

1. 교육 목표:
   • 프로그램 참여자가 오픈소스를 올바르게 활용하고, 라이선스 컴플라이언스와 보안 보증 절차를 이해하며 실무에 적용할 수 있도록 돕습니다.
   • 주요 교육 내용:
     • 오픈소스 정책의 목적과 원칙.
     • 라이선스 의무 사항 및 컴플라이언스 절차.
     • SBOM 생성 및 활용 방법.
     • 알려진 취약점 및 새로 발견된 취약점 관리 절차.
2. 교육 방법:
   • [Learning Portal]에서 제공하는 온라인 강의를 통해 이수합니다.
   • 필요 시 워크숍 또는 세미나 형식의 추가 교육을 제공합니다.
   • 사례 기반 학습을 통해 실제 문제 해결 능력을 강화합니다.

6.2 역량 평가

1. 평가 기준:
   • 각 역할에 맞는 필요 역량을 평가합니다.
   • 평가 항목:
     • 오픈소스 정책 이해도.
     • 컴플라이언스 절차 수행 능력.
     • 보안 취약점 관리 능력.
2. 평가 방법:
   • 정기적인 테스트와 실무 평가를 통해 참여자의 역량을 측정합니다.
   • 평가 결과는 개인별 성과 기록에 반영되며, 필요 시 추가 교육이 제공됩니다.

6.3 인식 제고 활동

1. 정기적인 뉴스레터 및 워크숍:
   • 정기적으로 발행되는 뉴스레터를 통해 최신 오픈소스 동향과 정책 변경 사항을 공유합니다.
   • 워크숍과 세미나를 통해 프로그램 참여자의 이해도를 높이고 협력을 촉진합니다.
2. 커뮤니케이션 채널 활용:
   • 사내 커뮤니케이션 채널(예: 이메일, 사내 포털)을 통해 오픈소스 관련 정보를 공유합니다.
   • 프로그램 참여자 간의 협업과 정보 교류를 장려합니다.

6.4 기록 보관

1. 교육 및 평가 기록:
   • 모든 교육 이수 기록과 평가 결과는 최소 3년간 보관됩니다.
   • 이를 통해 프로그램 참여자가 정책과 프로세스를 충분히 이해하고 있음을 입증할 수 있습니다.
2. 정기적인 검토 및 업데이트:
   • 오픈소스 프로그램 매니저는 연 1회 이상 교육 내용과 평가 방식을 검토하고 필요 시 업데이트하여 최신의 오픈소스 동향과 조직의 요구사항을 반영합니다.

6.5 전문 지식 식별 및 활용

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

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는 정기적으로 기여 활동의 효과성을 평가하고, 필요 시 개선 방안을 제안합니다.

8. 사내 프로젝트 오픈소스로 공개

이 섹션에서는 사내 프로젝트를 오픈소스로 공개하는 절차와 원칙을 설명합니다. 이를 통해 회사는 오픈소스 커뮤니티와의 협력을 증진시키고, 지식재산을 보호하며, 법적 위험을 최소화할 수 있습니다.

8.1 승인 절차

1. 리뷰 및 승인:
   • 사내 프로젝트를 오픈소스로 공개하려면 OSPO(Open Source Program Office)에 리뷰 요청 및 승인을 받아야 합니다.
   • OSPO는 공개하려는 코드가 회사의 지식재산을 침해하지 않는지 확인하고, 필요한 경우 법무팀의 검토를 요청합니다.
2. 지식재산 보호:
   • 민감한 정보, 특허 등 회사의 지식재산이 포함되지 않도록 주의합니다.
   • 특허가 포함된 코드는 법무팀과 협력하여 공개 가능 여부를 확인합니다.
3. 저작권 표시:
   • 공개하는 코드에 회사의 저작권을 명시합니다.
   • 예: “Copyright (c) [Year] [Company Name]”

8.2 공개 준비

1. 코드 준비:
   • 공개할 코드는 외부에서 사용할 수 있도록 정리하고 문서화합니다.
   • 코드의 출처를 확인하고, 문제 소지가 있는 코드는 삭제하거나 수정합니다.
2. 오픈소스 라이선스 선택:
   • 적절한 오픈소스 라이선스를 선택하여 코드를 공개합니다.
   • 라이선스 선택 시 회사의 지식재산 보호와 커뮤니티 요구를 고려합니다.
3. 리소스 확보:
   • 프로젝트를 유지하고 관리하는 데 필요한 인프라와 예산을 확보합니다.
   • GitHub와 같은 프로젝트 호스팅 플랫폼을 활용하여 투명성을 유지합니다.

8.3 공개 후 관리

1. 커뮤니티 관리:
   • 공개된 프로젝트에 대한 커뮤니티 피드백을 수집하고 적절히 대응합니다.
   • OSPO가 커뮤니티와의 관계를 관리하며, 외부 기여를 적극적으로 받아들입니다.
2. 지속적인 유지보수:
   • 공개된 프로젝트는 지속적으로 유지보수되며, 버그 수정 및 기능 개선이 이루어집니다.
   • 코드 리뷰를 통해 품질을 보장하며, 외부 기여자들과 협력합니다.
3. 회사 이메일 사용:
   • 오픈소스 활동 시 개인 이메일 대신 회사 이메일을 사용하여 회사의 대표성을 유지합니다.

8.4 기록 보관

1. 공개 기록 보관:
   • 공개한 프로젝트와 관련된 모든 기록은 최소 3년간 보관됩니다.
   • 기록에는 승인 절차, 코드 버전, 커뮤니티 피드백 등이 포함됩니다.
2. 정기적인 검토 및 업데이트:
   • 공개된 프로젝트는 정기적으로 검토되고 필요 시 업데이트됩니다.
   • 최신의 오픈소스 동향과 조직 요구사항을 반영하여 지속적으로 개선합니다.

9. 외부 문의 대응

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

9.1 외부 문의 대응 책임

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

9.2 연락처 공개

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

9.3 외부 문의 대응 절차

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

10. 프로그램 효과성 측정 및 개선

이 섹션에서는 오픈소스 프로그램의 효과성을 측정하고 지속적으로 개선하는 절차를 설명합니다. 이를 통해 회사는 오픈소스 라이선스 컴플라이언스와 보안 보증 프로그램의 성과를 평가하고 개선할 수 있습니다.

10.1 성과 지표 정의

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

10.2 정기적인 프로그램 평가

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

10.3 지속적 개선 계획

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

10.4 내부 모범 사례 통합 및 개선

1. 통합 활동 계획:
   • 내부 모범 사례와 오픈소스 보안 보증 프로그램 간의 차이를 식별하고, 이를 기반으로 통합 계획을 수립합니다.
   • 예: 취약점 관리 시스템 통합, 코드 리뷰 절차 표준화.
2. 정기적인 검토 및 업데이트:
   • 연 1회 이상 내부 모범 사례와 오픈소스 프로그램 간의 일치 여부를 검토하고, 필요 시 개선 사항을 반영합니다.
   • 검토 결과는 OSRB(Open Source Review Board)에 보고됩니다.

10.5 인력 및 자원 평가

1. 평가 주기:
   • 회사는 연 1회 이상 각 역할에 대한 인력 배치와 자금 지원 상태를 평가합니다.
   • 평가 결과는 OSRB에 보고되며, 필요 시 개선 사항이 실행됩니다.
2. 평가 항목:
   • 각 역할에 필요한 인력이 적절히 배치되었는지 여부.
   • 각 역할 수행에 필요한 예산이 충분히 제공되었는지 여부.
   • 지원 부족으로 인해 발생한 문제 사례와 해결 방안.
3. 개선 계획 수립:
   • 평가 결과를 바탕으로 부족한 인력 또는 자원을 보완하기 위한 구체적인 계획을 수립합니다.
   • 개선 계획은 OSRB의 승인을 받아 실행됩니다.

11. ISO 표준 준수 선언 및 유지

이 섹션에서는 회사가 ISO/IEC 5230(오픈소스 라이선스 컴플라이언스) 및 ISO/IEC 18974(오픈소스 보안 보증)의 요구사항을 준수하고 유지하는 절차를 설명합니다. 이를 통해 회사는 오픈소스 프로그램의 지속적인 개선과 표준 준수를 보장할 수 있습니다.

11.1 ISO 표준 준수 선언

1. 준수 선언:
   • 회사는 이 정책을 통해 ISO/IEC 5230(오픈소스 라이선스 컴플라이언스)와 ISO/IEC 18974(오픈소스 보안 보증)의 모든 요구사항을 충족함을 선언합니다.
   • 선언 일자와 유효 기간(18개월)을 명확히 기재합니다.
   • 준수 선언은 Linux Foundation의 OpenChain 프로젝트의 Self Certification을 통해 이루어질 수 있습니다.
2. 증거 문서화:
   • 오픈소스 프로그램 매니저(OSPM)는 각 요구사항에 대한 충족 증거를 문서화하고 유지합니다.
   • 증거 문서에는 정책 문서, 프로세스 설명, 교육 기록, 컴플라이언스 산출물, 보안 취약점 관리 기록 등이 포함됩니다.
   • 모든 증거 문서는 중앙 저장소에 보관되며, 최소 3년간 유지됩니다.
   • 이 문서는 적합성 검증을 받은 후 18개월 이내에 작성되어야 하며, 최소 연 1회 갱신됩니다.
3. 정기적인 검토 및 갱신:
   • OSRB는 연 1회 이상 요구사항 충족 여부를 검토하고, 필요시 정책과 프로세스를 개선합니다.
   • 검토 결과와 개선 사항은 문서화되어 보관됩니다.
4. 외부 검증 준비:
   • 요구 시 외부 감사나 인증 기관에 증거 문서를 제공할 수 있도록 준비합니다.

11.2 준수 상태 유지

1. 정기적인 검토:
   • OSRB는 최소 연 1회 이상 ISO/IEC 5230 및 ISO/IEC 18974의 모든 요구사항에 대한 내부 검토를 수행합니다.
   • 검토 결과는 문서화하여 보관하며, 미충족 항목에 대해서는 개선 계획을 수립합니다.
2. 정기적인 내부 감사:
   • 내부 감사는 프로그램 참여자의 역할 수행 여부, 컴플라이언스 산출물의 적합성, 그리고 보안 보증 활동의 효과성을 평가합니다.
   • 감사 결과에 따라 개선 영역을 식별하고, 필요한 조치를 취합니다.
3. 교육 및 훈련 제공:
   • 프로그램 참여자의 역량과 인식을 지속적으로 향상시키기 위해 정기적인 교육 및 훈련을 제공합니다.
   • 교육 내용은 최신 오픈소스 동향과 조직의 요구사항을 반영하며, ISO 표준 준수를 강조합니다.
4. 외부 문의 대응 준비:
   • 외부에서 ISO 표준 준수와 관련된 문의가 있을 경우, 신속하고 효과적으로 대응할 수 있는 체계를 유지합니다.
   • 문의 대응은 오픈소스 프로그램 매니저가 담당하며, 필요 시 법무팀과 협력합니다.
5. 정기적인 정책 갱신:
   • 정책은 최소 연 1회 이상 검토되며, 최신 오픈소스 동향과 조직의 요구사항을 반영하여 갱신됩니다.
   • 갱신된 정책은 모든 프로그램 참여자에게 공유됩니다.