Templates

• 1: 오픈소스 정책
• 1.1: Appendix
• 2: 오픈소스 프로세스

1 - 오픈소스 정책

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회 이상 검토되며, 최신 오픈소스 동향과 조직의 요구사항을 반영하여 갱신됩니다.
   • 갱신된 정책은 모든 프로그램 참여자에게 공유됩니다.

1.1 - Appendix

Appendix 1. 담당자 현황

2 - 오픈소스 프로세스

OO 회사(이하 “회사"라 함)는 소프트웨어를 포함하는 제품과 서비스를 개발하면서 오픈소스 소프트웨어를 적극적으로 활용합니다. 회사는 오픈소스 리스크를 최소화하기 위해 소프트웨어를 배포하면서 (1) 오픈소스 라이선스가 부과하는 의무사항을 준수하기 위한 활동과 (2) 오픈소스 보안 취약점을 검출하고 후속 조치를 위한 적절한 활동을 수행해야 합니다. 이러한 활동을 보장하기 위해 오픈소스 프로세스를 따릅니다.

1. 오픈소스 프로세스

OO 회사(이하 “회사"라 함)는 소프트웨어를 포함하는 제품과 서비스를 개발하면서 오픈소스 소프트웨어를 적극적으로 활용합니다. 회사는 오픈소스 리스크를 최소화하기 위해 공급 소프트웨어를 배포하면서 (1) 오픈소스 라이선스가 부과하는 의무사항을 준수하기 위한 활동과 (2) 오픈소스 보안 취약점을 검출하고 후속 조치를 위한 적절한 활동을 수행해야 합니다. 이러한 활동을 보장하기 위해 오픈소스 프로세스를 따릅니다.

오픈소스 프로세스는 회사가 공급 소프트웨어를 개발하고 배포하기 위한 각 개발 단계에 맞게 오픈소스 라이선스 의무 준수와 오픈소스 보안 보증을 위해 수행해야 할 절차를 정의합니다. 프로그램 참여자는 다음의 오픈소스 프로세스 11단계를 준수합니다.

회사는 오픈소스 프로세스를 통해 오픈소스 리스크를 최소화하고, 고객에게 안전하고 안정적인 공급 소프트웨어를 제공하기 위해 노력합니다.

오픈소스 프로그램 매니저는 프로세스를 1년에 한 번 이상 주기적으로 검토하여 내부 모범 사례는 확산 전파하고, 미흡한 부분은 보완할 수 있도록 개선해야 합니다.

(1) 오픈소스 식별

사업 부서는 소프트웨어 설계 단계에서 다음 사항을 준수합니다:

• 소프트웨어를 설계하면서 예측 가능한 오픈소스 사용 현황을 파악하고 식별된 라이선스를 확인합니다.
• 오픈소스 라이선스별 의무 사항을 확인합니다. 라이선스별 의무 사항은 회사의 오픈소스 라이선스 가이드에서 확인할 수 있습니다: https://sktelecom.github.io/guide/use/obligation/
• 각 오픈소스 라이선스의 소스 코드 공개 범위를 고려하여 소프트웨어를 설계합니다.

오픈소스 프로그램 매니저는 주요 오픈소스 라이선스 의무, 제한, 권리에 대한 가이드를 작성하고 공개하여 전사의 사업 부서에서 참고할 수 있도록 합니다. 이 가이드에는 일반적인 오픈소스 라이선스의 사용 사례가 관리될 수 있도록 다음과 같은 사용 사례가 포함되어야 합니다:

• 바이너리 형태로 배포
• 소스 형태로 배포
• 추가 라이선스 의무를 유발하는 다른 오픈소스와 통합
• 수정된 오픈소스 포함
• 공급 소프트웨어 내의 다른 컴포넌트와 서로 호환되지 않는 라이선스 하의 오픈소스 또는 다른 소프트웨어를 포함
• 저작자 표시 요구사항을 갖는 오픈소스 포함

사업 부서는 회사 규칙에 맞게 소스 코드에 저작권 및 라이선스를 표기합니다. 회사의 소스 코드 내 저작권 및 라이선스 표기 규칙은 다음 페이지에서 확인할 수 있습니다. (insert_link)

사업 부서는 새로운 오픈소스 도입 검토 시, 먼저 라이선스를 식별합니다. 회사의 오픈소스 라이선스 가이드에 따라 라이선스 의무, 제한 및 권리를 확인합니다. 회사의 오픈소스 라이선스 가이드에서 설명하지 않는 라이선스일 경우, 오픈소스 프로그램 매니저에게 도입 가능 여부 및 주의 사항을 문의합니다. 문의를 위해서 Jira Ticket을 생성합니다.

오픈소스 프로그램 매니저는 오픈소스 라이선스 의무를 분석하여 소프트웨어 개발 조직에 안내합니다.

• 의문이 있는 경우, 법무 담당에 자문을 요청하여 명확한 가이드를 제공합니다.
• 새롭게 분석한 라이선스 정보는 전사 라이선스 가이드에 반영합니다.

보안 담당은 회사의 보안 보증을 위한 가이드를 제공합니다.

(2) 소스 코드 검사

사업 부서는 IT 담당자의 안내에 따라 오픈소스 점검을 요청하고 소스 코드를 제공합니다.

IT 담당은 오픈소스 분석 도구를 사용하여 오픈소스 점검을 하고, SBOM(Software Bill of Materials)을 생성합니다.

오픈소스 프로그램 매니저는 오픈소스 라이선스 의무 준수 가능 여부, 오픈소스 라이선스 충돌 여부를 검토하고, 이슈가 있으면 사업 부서에 해결을 요청합니다. 이슈 사항은 Jira Ticket으로 생성하여 사업 부서에 할당합니다.

보안 담당은 검출된 알려진 취약점을 검토하고 사전 정의한 Risk 분류 기준에 따라 사업 부서에 대응 가이드를 제공합니다. Risk는 CVSS(Common Vulnerability Scoring System) Score로 분류하며, Critical Risk는 1주 이내 조치할 수 있는 계획을 수립하도록 안내합니다.

(3) 문제 해결

사업 부서는 소스 코드 검사 단계에서 발견된 모든 문제를 해결합니다.

이슈가 된 오픈소스를 제거하거나, 다른 라이선스 하의 오픈소스로 교체합니다. 알려진 취약점 또는 새로 발견된 취약점 이슈의 경우 취약점이 수정된 버전으로 교체하는 등의 조치를 취합니다.

사업 부서는 발견된 모든 이슈를 해결하면 Jira Ticket 이슈를 Resolve하고, 재검토를 요청합니다.

(4) 검토

오픈소스 프로그램 매니저는 모든 이슈가 적절하게 보완되었는지 검토합니다. 필요할 경우, 오픈소스 분석 도구를 사용하여 소스 코드 검사를 재수행합니다.

보안 담당은 심각한 취약점이 모두 해결되었는지 검토합니다. 해결하기 어려운 취약점이 남아 있을 경우, 비즈니스 형태와 서비스 노출 현황 등을 고려하여 승인 가능 여부를 검토합니다.

(5) 승인

오픈소스 프로그램 매니저는 오픈소스 라이선스 컴플라이언스 절차가 적절하게 수행되었는지 최종 승인하거나 거절합니다. 거절 시에는 이유에 대한 설명과 수정 방법을 사업 부서에 제안합니다.

(6) 등록

오픈소스 프로그램 매니저는 공급 소프트웨어의 버전별 오픈소스 사용 목록을 추적하기 위한 SBOM을 확정합니다.

IT 담당은 확정된 SBOM을 시스템에 등록합니다. SBOM에는 공급 소프트웨어에 포함된 오픈소스 목록과 다음과 같은 정보를 포함합니다:

• 공급 소프트웨어의 제품(혹은 서비스) 이름과 버전
• 오픈소스 목록
  • 컴포넌트 이름, 버전, 라이선스, 출처(URL)
  • 사용 목적 및 방식
  • 수정 여부 및 수정 내용
  • 버전 히스토리 및 각 버전별 주요 변경 사항

등록된 정보는 정기적으로 검토하고 업데이트합니다.

(7) 고지

오픈소스 프로그램 매니저는 고지 의무를 준수하기 위해 오픈소스 고지문을 생성합니다. 오픈소스 고지문에는 다음과 같은 내용이 포함됩니다:

• 오픈소스 관련 문의할 수 있는 오픈소스 연락처
• 오픈소스별 고지 내용
  • 저작권
  • 오픈소스 라이선스 이름
  • 오픈소스 라이선스 사본
  • (해당하는 경우) 소스 코드 사본을 얻을 수 있는 서면 청약 (Written Offer)

오픈소스 프로그램 매니저는 오픈소스 고지문을 생성하여 사업 부서에 전달합니다. 이때 소스 코드 공개가 필요할 경우 사업 부서에 공개할 소스 코드 취합 방법을 안내합니다.

사업 부서는 오픈소스 고지문을 제품 배포 시 동봉합니다. 화면이 있는 제품일 경우, 사용자가 메뉴를 통해 확인할 수 있도록 조치합니다. (예: 앱 > 메뉴 > 설정 > 저작권 정보 > 오픈소스 라이선스)

사업 부서는 GPL, LGPL 등 소스 코드 공개를 요구하는 라이선스 하의 오픈소스를 사용하였을 경우, 이에 대한 소스 코드 공개 범위를 확인하여 공개할 소스 코드를 취합합니다.

• GPL, LGPL 등의 라이선스 의무 준수를 위해 취합한 소스 코드는 제품에 탑재된 바이너리를 구성하는 소스 코드와 일치해야 합니다. 즉, 취합한 소스 코드를 빌드하면 제품에 탑재된 바이너리와 동일해야 합니다.

(8) 배포 전 확인

사업 부서는 오픈소스 라이선스 컴플라이언스 활동이 적절히 수행되었음을 입증하는 다음의 컴플라이언스 산출물을 제출합니다:

1. 제품에 포함한 최종 오픈소스 고지문
2. 제품에 오픈소스 고지문이 포함되었음을 확인하는 자료 (예: 오픈소스 고지문을 보여주는 화면 캡처 이미지)
3. (해당할 경우) 공개할 소스 코드 (하나의 파일로 압축하여 제출)

오픈소스 프로그램 매니저는 사업 부서가 제출한 자료를 검토하여 이상 여부를 확인합니다.

(9) 배포

오픈소스 프로그램 매니저는 사업 부서가 제출한 컴플라이언스 산출물을 IT 담당자에게 제출합니다.

IT 담당은 컴플라이언스 산출물을 회사의 오픈소스 배포 사이트에 등록합니다.

(10) 최종 확인

오픈소스 프로그램 매니저는 컴플라이언스 산출물이 이상 없이 회사의 오픈소스 포털에 등록되었는지, 외부에서 이상 없이 다운로드가 되는지 등 종합적인 확인을 합니다.

(11) 모니터링

오픈소스 프로그램 매니저는 오픈소스 라이선스 컴플라이언스 산출물 생성이 미흡한 공급 소프트웨어가 있는지 주기적으로 확인합니다. 그리고, 외부 문의에 신속하게 대응하기 위한 프로세스를 운영합니다. 외부 문의 대응 프로세스의 자세한 절차는 [2. 외부 문의 대응 프로세스]를 따릅니다.

보안 담당은 알려진 취약점 또는 새로 발견된 취약점을 모니터링하고 대응하기 위한 프로세스를 운영합니다. 이 프로세스는 다음 사항을 포함해야 합니다:

1. 공급 소프트웨어에 사용된 오픈소스 소프트웨어 컴포넌트의 알려진 취약점 또는 새로 발견된 취약점을 지속적으로 모니터링하는 방법
2. 발견된 취약점에 대한 위험/영향 평가 절차
3. 필요한 경우 고객에게 연락하고 소프트웨어 컴포넌트를 업그레이드하는 등의 적절한 조치를 취하는 방법
4. 공급 소프트웨어가 시장에 출시된 후에도 지속적인 모니터링 및 대응 기능을 유지하는 방법

이러한 보안 취약점 대응 프로세스의 자세한 절차는 [2. 보안 취약점 관리 프로세스]를 따릅니다.

2. 보안 취약점 관리 프로세스

공급 소프트웨어가 시장에 출시된 후 알려진 취약점 또는 새로 발견된 취약점이 보고될 경우 위험도에 따라 적절한 조치를 취하기 위해 다음과 같은 프로세스를 준수합니다.

(1) 출시 전 지속적인 보안 테스트

IT 담당은 모든 공급 소프트웨어에 대해 출시 전 지속적이고 반복적인 보안 테스트를 적용하는 시스템을 구축하고 운영합니다 :

1. 자동화된 보안 테스트:
   • CI/CD 파이프라인에 자동화된 보안 테스트 도구를 통합합니다.
   • 코드 변경 시마다 자동으로 보안 테스트를 실행합니다.
2. 취약점 스캔:
   • SCA 도구를 사용하여 오픈소스 컴포넌트의 알려진 취약점을 스캔합니다.
   • 매일 자동으로 취약점 데이터베이스를 업데이트하고 스캔을 수행합니다.
3. 보안 테스트 결과 검토:
   • 보안 담당자는 보안 테스트 결과를 검토하고 필요한 조치를 취합니다.
   • 심각한 취약점 발견 시 즉시 개발팀에 통보하고 해결 방안을 수립합니다.

(2) 알려진 취약점 및 새로 발견된 취약점 모니터링

IT 담당은 알려진 취약점 및 새로 발견된 취약점을 모니터링하는 시스템을 구축하여 운영합니다. 이 시스템은 구조적 / 기술적 위협 식별을 위해 다음과 같은 기능을 수행합니다:

1. 자동화된 취약점 모니터링:
   • 매일 신규 게시되는 취약점을 분석하고, 영향받는 공급 소프트웨어 버전을 자동으로 확인합니다.
   • 공개적으로 사용 가능한 보안 취약점 정보를 주기적으로 수집합니다.
2. SBOM 기반 분석:
   • SCA 도구를 활용하여 SBOM 기반 분석을 수행합니다.
   • CI/CD 파이프라인에 SCA 도구를 통합하여 자동화된 분석을 수행합니다.
3. 알림 및 기록:
   • 취약점이 발견된 경우, 해당 공급 소프트웨어의 개발 담당자와 보안 담당자에게 자동으로 알림을 보냅니다.
   • 알림부터 검토, 조치, 해결 사항이 모두 문서화되어 기록될 수 있도록 이슈 추적 시스템을 사용합니다.

(3) 취약점 평가 및 대응

보안 담당은 사전 정의한 위험/영향 평가 기준에 따라 각 취약점을 평가하고 사업 부서에 대응 가이드를 제공합니다. 위험은 CVSS(Common Vulnerability Scoring System) 점수로 분류하며, 심각도에 따라 조치 기한을 설정합니다.

사업 부서는 기존 출시한 공급 소프트웨어에 알려진 취약점 또는 새로 발견된 취약점이 확인된 경우, 보안 담당자가 제공한 대응 가이드에 따라 조치 계획을 수립합니다.

필요한 경우, 사업 부서는 위험/영향 점수에 따라 고객에게 확인된 취약점을 고지합니다.

(4) 취약점 해결 및 검증

• 사업 부서는 수립한 조치 계획에 따라 취약점 문제를 해결합니다
• 문제가 되는 오픈소스 소프트웨어 컴포넌트를 제거하거나 패치된 버전으로 교체하는 등의 방법으로 취약점을 해결합니다.
• IT 담당은 오픈소스 분석 도구를 활용하여 문제가 적절하게 해결되었는지 확인합니다.
• 보안 담당은 해결된 취약점에 대해 추가적인 보안 테스트를 수행하여 완전히 해결되었는지 검증합니다.
• 검증 결과는 문서화하여 기록합니다.
• 심각한 취약점이 모두 해결되었는지 검토합니다.
• 해결하기 어려운 취약점이 남아 있을 경우, 비즈니스 형태와 서비스 노출 현황 등을 고려하여 승인 여부를 검토합니다.

(5) 출시 후 취약점 분석 및 대응

IT 담당은 모든 공급 소프트웨어에 대해 출시 후에도 자동화된 시스템을 통해 매일 출시된 공급 소프트웨어의 취약점을 분석하도록 운영합니다.

• 영향받는 공급 소프트웨어가 확인되면 즉시 개발 담당자와 보안 담당자에게 알림을 보냅니다.
• 알림을 받은 담당자는 취약점의 심각도를 평가하고 대응 계획을 수립합니다.
• 대응 계획에 따라 패치 개발, 완화 조치 등을 실행합니다.
• 조치 완료 후 검증을 수행하고 결과를 문서화합니다.

(6) 취약점 기록 관리

각 오픈소스 컴포넌트별로 다음 정보를 포함한 취약점 기록을 유지합니다:

• 취약점 ID (예: CVE 번호)
• 취약점 설명
• 영향을 받는 버전
• 심각도 (CVSS 점수)
• 발견 날짜
• 해결 상태
• 적용된 해결 방법
• 검증 결과

취약점 기록은 중앙 데이터베이스에 저장하고 정기적으로 백업합니다.

IT 담당은 취약점이 해결된 SBOM(Software Bill of Materials)을 시스템에 등록합니다.

(7) 보고 및 커뮤니케이션

• 월간 취약점 관리 보고서를 작성하여 경영진과 관련 이해관계자에게 제공합니다.
• 보고서에는 새로 발견된 취약점 수, 해결된 취약점 수, 미해결 취약점 현황 및 조치 계획, 주요 위험 요소 및 대응 전략을 포함합니다.
• 심각한 취약점 발견 시 즉시 관련 부서와 경영진에게 보고합니다.

(8) 고객 및 제3자 통지

오픈소스 프로그램 매니저는 취약점이 해결된 SBOM을 기준으로 업데이트된 오픈소스 고지문을 생성하여 사업 부서에 전달합니다.

1. 고객 통지:

   사업 부서는 다음과 같은 방법으로 고객에게 취약점 해결 사항을 통지합니다:

   • 제품 배포 시 동봉한 오픈소스 고지문을 교체합니다.
   • 필요한 경우 이메일 등의 방법으로 고객에게 직접 통지합니다.
   • 공급 소프트웨어의 취약점이 해결된 버전을 재배포합니다.

2. 제3자 정보 공개:

   IT 담당은 다음과 같은 방법으로 제3자에게 위험 정보를 공개합니다:

   • 수정된 오픈소스 고지문과 취약점 관련 정보를 회사의 오픈소스 웹사이트에 등록합니다.
   • 공개 취약점 데이터베이스(예: NVD)에 취약점 정보를 제출합니다.
   • 오픈소스 프로젝트 메인테이너에게 발견된 취약점과 해결 방법을 통지합니다.

3. 통지 내용:

   고객 및 제3자에게 제공되는 정보에는 다음 사항이 포함됩니다:

   • 취약점 개요 및 식별자(예: CVE 번호)
   • 영향을 받는 제품 및 버전
   • 취약점의 잠재적 영향 및 CVSS 점수
   • 임시 대응 방안
   • 패치 또는 업데이트 가용성 및 적용 방법
   • 추가 정보를 얻을 수 있는 연락처

3. 외부 문의 대응 프로세스

외부로부터의 오픈소스 라이선스 컴플라이언스 및 보안 보증 관련 문의에 신속하고 정확하게 대응하면 법적 소송으로 진행될 위험을 크게 줄일 수 있습니다. 이를 위해 조직은 다음과 같은 프로세스를 준수합니다:

(1) 접수 알림

오픈소스 프로그램 매니저는 문의를 받은 즉시 요청자에게 문의가 접수되었음을 알립니다. 이때 적절한 응답 시간을 명시합니다. 요청자의 의도를 정확히 파악하기 위해 문의가 불명확한 경우 추가 설명을 요청합니다.

주요 문의 및 요청 내용:

• 특정 공급 소프트웨어의 오픈소스 사용 여부
• 서면 청약에 언급된 GPL, LGPL 라이선스 하의 소스 코드 제공 요청
• 오픈소스 고지문에 누락된 오픈소스에 대한 해명 및 소스 코드 공개 요청
• 공개된 소스 코드의 누락 파일 및 빌드 방법 제공 요청
• 저작권 표시 요청
• 알려진 취약점 또는 새로 발견된 취약점 관련 문의

오픈소스 프로그램 매니저는 접수한 요청에 대한 이슈를 생성하여 대응 상황을 상세히 기록합니다.

(2) 조사 알림

오픈소스 프로그램 매니저는 요청자에게 오픈소스 라이선스 컴플라이언스와 보안 보증을 충실히 수행하고 있음과 문의 사항을 조사 중임을 알립니다. 내부 조사 진행 상황을 주기적으로 업데이트하여 알립니다.

(3) 내부 조사

오픈소스 프로그램 매니저는 요청 사항에 대한 내부 조사를 진행합니다. 해당 공급 소프트웨어에 대해 라이선스 컴플라이언스 및 보안 보증 프로세스가 적절하게 수행되었는지 SBOM 및 문서화된 검토 이력을 통해 확인합니다. 필요 시 법무 담당과 보안 담당에 자문을 요청합니다.

특정 사업 부서의 확인이 필요한 경우, 오픈소스 프로그램 매니저는 해당 부서에 조사를 요청합니다. 조사를 요청받은 사업 부서는 컴플라이언스 산출물과 보안 관련 사항에 문제가 있는지 즉시 확인하고 결과를 보고합니다.

(4) 요청자에게 보고

오픈소스 프로그램 매니저는 명시된 응답 시간 내에 내부 조사를 마치고 요청자에게 결과를 알립니다.

• 요청자의 문의가 오해로 인한 잘못된 지적이었다면 추가 조치 없이 이를 설명하고 처리를 종료합니다.
• 문제가 확인된 경우, 요청자에게 해당 오픈소스 라이선스의 의무를 이행하거나 보안 취약점을 해결하기 위한 정확한 방법과 시기를 알립니다.

(5) 문제 보완 / 알림

내부 조사에서 실제 라이선스 컴플라이언스나 보안 문제가 발견되면 해당 사업 부서는 이를 해결하는 데 필요한 모든 절차를 수행합니다.

(6) 문제 해결 알림

문제를 해결한 후에는 즉시 요청자에게 알리고 문제가 해결되었음을 확인할 수 있는 최선의 방법을 제공합니다.

(7) 프로세스 개선

라이선스 컴플라이언스나 보안 문제가 있었던 경우, OSRB 미팅을 통해 사례를 검토하고 문제 발생 경위를 파악하여 재발 방지를 위한 프로세스 개선 방안을 수립합니다.

4. 오픈소스 기여 프로세스

조직이 외부 오픈소스 프로젝트에 기여하는 것을 허용하는 경우, 다음과 같은 프로세스를 수행해야 합니다.

(1) 기여 정책 수립 및 전파

• 오픈소스 프로젝트로의 기여를 관리하는 문서화된 정책을 수립해야 합니다.
• 이 정책을 조직 내부에 전파해야 합니다.
• 정책을 시행하는 프로세스가 있어야 합니다.

오픈소스 프로그램 매니저는 다음 사항을 수행해야 합니다:

• 문서화된 오픈소스 기여 정책을 작성합니다.
• 모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식하도록 하는 문서화된 절차를 수립합니다(예: 교육, 내부 위키, 또는 기타 실질적인 전달 방법 등).

(2) 기여 검토 및 승인 절차

오픈소스 기여를 관리하는 문서화된 절차를 수립해야 합니다. 이 절차는 다음 사항을 포함해야 합니다:

• 기여하려는 코드의 출처와 라이선스를 확인합니다.
• 기여할 권리가 있는 코드인지 검토합니다.
• 기여하려는 프로젝트의 라이선스와 기여 정책을 검토합니다.
• 필요한 경우, 법무팀의 검토를 받습니다.
• 기여에 대한 승인 절차를 정의합니다.
• 승인된 기여의 제출 방법을 명시합니다.

오픈소스 프로그램 매니저는 이 절차가 올바르게 수행되었음을 입증하는 기록을 유지해야 합니다.

이러한 프로세스를 통해 조직은 외부 오픈소스 프로젝트에 대한 기여를 효과적으로 관리하고, 잠재적인 법적 위험을 최소화할 수 있습니다.