Guide

• 1: [2026] ISO 표준 기반 기업 오픈소스 관리 가이드
• 1.1: 0. OpenChain 살펴보기
• 1.2: 1. 조직
• 1.3: 2. 정책
• 1.4: 3. 프로세스
• 1.5: 4. 도구
• 1.6: 5. 교육
• 1.7: 6. 준수 선언
• 2: ISO/IEC 5230 준수 가이드
• 2.1: §3.1 프로그램 기반
• 2.1.1: §3.1.1 정책
• 2.1.2: §3.1.2 역량
• 2.1.3: §3.1.3 인식
• 2.1.4: §3.1.4 프로그램 범위
• 2.1.5: §3.1.5 라이선스 의무
• 2.2: §3.2 관련 업무
• 2.2.1: §3.2.1 외부 문의 대응
• 2.2.2: §3.2.2 효과적 리소스
• 2.3: §3.3 콘텐츠 검토 및 승인
• 2.3.1: §3.3.1 SBOM
• 2.3.2: §3.3.2 라이선스 컴플라이언스
• 2.4: §3.4 컴플라이언스 산출물
• 2.4.1: §3.4.1 산출물
• 2.5: §3.5 커뮤니티 참여
• 2.5.1: §3.5.1 기여
• 2.6: §3.6 규격 준수
• 2.6.1: §3.6.1 적합성
• 2.6.2: §3.6.2 지속 기간
• 3: ISO/IEC 18974 준수 가이드
• 3.1: §4.1 프로그램 기반
• 3.1.1: §4.1.1 정책
• 3.1.2: §4.1.2 역량
• 3.1.3: §4.1.3 인식
• 3.1.4: §4.1.4 프로그램 범위
• 3.1.5: §4.1.5 표준 관행 구현
• 3.2: §4.2 관련 업무
• 3.2.1: §4.2.1 접근성
• 3.2.2: §4.2.2 효과적 리소스
• 3.3: §4.3 콘텐츠 검토 및 승인
• 3.3.1: §4.3.1 SBOM
• 3.3.2: §4.3.2 보안 보증
• 3.4: §4.4 규격 준수
• 3.4.1: §4.4.1 완전성
• 3.4.2: §4.4.2 기간
• 3.5: ISO/IEC 5230 vs 18974 비교
• 4: Templates
• 4.1: 오픈소스 정책
• 4.1.1: Appendix
• 4.2: 오픈소스 프로세스
• 5: Tools
• 5.1: FOSSology
• 5.2: SW360
• 5.3: FOSSLight
• 5.4: OSV-SCALIBR
• 5.5: cdxgen
• 5.6: Syft
• 5.7: Dependency-Track
• 6: Archive
• 6.1: 오픈소스 보안 보증: ISO/IEC 18974 기업 도입 및 인증 가이드
• 6.1.1: 1. 오픈소스 보안, 왜 중요한가?
• 6.1.2: 2. ISO/IEC 18974의 주요 요구사항
• 6.1.3: 3. ISO/IEC 18974 구현 방법
• 6.1.3.1: 3.1 Program Foundation
• 6.1.3.2: 3.2 Relevant Tasks Defined and Supported
• 6.1.3.3: 3.3 Open Source Software Content Review and Approval
• 6.1.3.4: 3.4 Adherence to the specification requirements
• 6.1.4: 4. ISO/IEC 5230과의 비교 및 통합
• 6.1.5: 5. 조직 특성별 구현 고려사항
• 6.1.6: 6. ISO/IEC 18974 자체 인증 절차
• 6.1.7: 7. 사례 연구 및 성공 전략
• 6.1.8: 8. 결론 및 향후 전망
• 6.2: 기업 오픈소스SW 거버넌스 - OpenChain 해설서
• 6.2.1: I. OpenChain 프로젝트란?
• 6.2.1.1: 1. OpenChain 표준
• 6.2.1.2: 2. OpenChain 인증
• 6.2.1.3: 3. OpenChain 리소스
• 6.2.2: II. OpenChain ISO 표준 준수 방법
• 6.2.2.1: 1. 프로그램 설립
• 6.2.2.2: 2. 관련 업무 정의 및 지원
• 6.2.2.3: 3. 오픈소스 콘텐츠 검토 및 승인
• 6.2.2.4: 4. 컴플라이언스 산출물 생성 및 제공
• 6.2.2.5: 5. 오픈소스 커뮤니티 참여에 대한 이해
• 6.2.2.6: 6. 규격 요구사항 준수
• 6.3: (구) 국제표준(ISO/IEC 5230)에 기반한 기업 오픈소스 거버넌스 구축 가이드
• 6.3.1: 1. ISO/IEC 5230 살펴보기
• 6.3.2: 2. 필수 구성 요소
• 6.3.3: 3. 조직 (담당자)
• 6.3.4: 4. 정책
• 6.3.5: 5. 프로세스
• 6.3.6: 6. 도구
• 6.3.7: 7. 교육/평가
• 6.3.8: 8. 준수 선언
• 6.3.9: Appendix
• 6.3.9.1: 1. 오픈소스 정책 (샘플)
• 6.3.9.2: 2. 오픈소스 컴플라이언스 프로세스 (샘플)
• 6.3.9.3: 3. Tools (FOSSology, SW360)
• 6.3.9.3.1: FOSSology
• 6.3.9.3.2: SW360
• 7:

1 - [2026] ISO 표준 기반 기업 오픈소스 관리 가이드

오픈소스 관리 국제표준

오픈소스 관리를 위한 ISO 국제 표준은 다음 두 가지입니다:

1. ISO/IEC 5230 : OpenChain Specification - 오픈소스 컴플라이언스를 위한 국제표준
2. ISO/IEC 18974 : OpenChain Security Assurance Specification - 오픈소스 보안을 위한 국제 표준

OpenChain과 ISO/IEC 5230

ISO/IEC 5230은 오픈소스 컴플라이언스를 위한 유일한 국제표준으로, 기업이 효과적인 오픈소스 프로그램을 구축하기 위한 핵심 요구사항을 정의합니다. 자세한 내용은 OpenChain 살펴보기 페이지를 참조하세요.

기업의 오픈소스 관리 방안

ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 준수함으로써 기업은 효과적인 오픈소스 관리 체계를 구축할 수 있습니다. 이를 위해 기업은 다음 6가지 핵심 요소를 갖추어야 합니다:

1. 조직: 오픈소스 관리를 위한 전담 조직 구성
2. 정책: 명확한 오픈소스 정책 수립 및 문서화
3. 프로세스: 오픈소스 사용, 기여, 배포를 위한 체계적인 프로세스 구축
4. 도구: 오픈소스 검사, 추적, 관리를 위한 자동화 도구 도입
5. 교육: 임직원 대상 오픈소스 인식 제고 및 역량 강화 교육 실시
6. 준수: 지속적인 모니터링 및 개선을 통한 표준 준수 유지

이 가이드는 각 요소별로 기업이 구체적으로 어떻게 실행할 수 있는지 상세한 방법과 예시를 제공합니다.

References

본 가이드는 다음의 권위 있는 자료를 참고하여 작성되었습니다:

1.1 - 0. OpenChain 살펴보기

1. OpenChain Project란?

오늘날 소프트웨어는 갈수록 그 규모와 복잡도가 커지고 있습니다. 하나의 소프트웨어를 개발하기 위해서는 자체 개발한 소프트웨어뿐 아니라 오픈소스, 타사 소프트웨어_{3rd party software}, 벤더의 SDK 등 소프트웨어 공급망에 걸친 다양한 소프트웨어가 사용될 수 있습니다.

이러한 복잡한 소프트웨어 공급망의 여러 조직 중 한 곳이라도 오픈소스 라이선스 의무를 준수하지 않거나 올바른 오픈소스 사용 정보를 제공하지 않으면 최종 소프트웨어를 배포하는 기업은 오픈소스 라이선스 의무 준수에 실패할 수밖에 없습니다. 이로 인해 소송을 제기당해 제품 판매가 중단되는 상황이 발생할 수도 있습니다.

2009년 12월, Busybox라는 오픈소스 관련된 소송이 있었습니다. Busybox는 임베디드 시스템에 광범위하게 사용되고 있는 GPL-2.0 라이선스가 적용된 오픈소스인데, 국내 회사 두 곳을 포함하여 14개 회사가 소송 대상이 되었습니다. 이 사례에서 주목할만한 점은 이 중에는 제품을 직접 개발하지 않고 배포만 한 회사도 소송을 당하였다는 점입니다.

이와 같은 복잡한 소프트웨어 공급망 환경에서는 어느 한 기업이 아무리 훌륭한 프로세스를 갖추고 있다고 해도 자체적으로 완벽한 오픈소스 컴플라이언스를 달성하는 건 매우 어렵습니다. 결국 한 기업이 오픈소스 컴플라이언스를 제대로 이행하기 위해서는 소프트웨어 공급망의 모든 구성원이 라이선스 의무를 준수하고 올바른 오픈소스 정보를 제공해야 합니다. 공급망 전체에 걸쳐 이런 신뢰가 구축되어야 합니다.

Linux Foundation의 OpenChain 프로젝트는 기업이 오픈소스 컴플라이언스를 위해 준수해야 할 핵심 사항을 간결하고 일관성 있게 정의하고, 이를 모두가 준수한다면 소프트웨어 공급망 전체에 걸쳐 오픈소스 라이선스 측면의 신뢰를 구축할 수 있다는 믿음으로 설립되었습니다.

2016년 유럽에서의 한 오픈소스 콘퍼런스에서 퀄컴의 오픈소스 변호사인 데이브 머_{Dave Marr}는 바로 이 점을 강조하였습니다. 한 기업의 오픈소스 컴플라이언스 수준을 높이기 위해서는 소프트웨어 공급망 내 모든 구성원의 오픈소스 컴플라이언스 수준을 높여야 합니다. 아울러 이를 위해서는 오픈소스를 충분히 이해하고, 정책 및 프로세스를 이미 구축하고 있는 선진 기업이 자신의 자산과 노하우를 공개하여 누구나 이를 참고할 수 있게 하면 어떻겠냐는 의견을 제시하였습니다. 콘퍼런스 참석자들은 “오픈소스 컴플라이언스는 기업의 이익을 차별화할 수 있는 분야가 아니다. 기업은 적은 리소스를 투입하면서도 적정한 수준의 리스크 관리를 원한다. 그렇기 때문에 기업이 가진 자산을 서로 공유하면 할수록 적은 리소스로 모두 함께 컴플라이언스를 달성 할 수 있게 된다"는 아이디어에 공감하였습니다. 그렇게 OpenChain 프로젝트(당시에는 Work Group)는 시작되었고, 퀄컴, 지멘스, 윈드리버, ARM, 어도비 등 다수 글로벌 기업들이 참여하였습니다.

OpenChain 프로젝트는 기업들이 오픈소스 컴플라이언스를 더욱 쉽게 달성 할 수 있도록 크게 다음 세 가지를 제공합니다.

1. OpenChain 규격
2. OpenChain 적합성 인증
3. 문서 자료

기업이 어떻게 이들을 활용할 수 있을지 하나씩 알아보겠습니다.

2. OpenChain 규격과 ISO/IEC 표준

OpenChain 규격은 오픈소스 컴플라이언스를 위한 핵심 요구사항을 정의한 10페이지 분량의 문서입니다. 2016년 OpenChain 규격 버전 1.0이 발표되었습니다. OpenChain 규격은 기업의 규모나 업종과 관계없이 모든 기업에 적합하도록 설계되었습니다.

2020년에는 버전 2.1의 규격이 배포됐으며, 기업이 오픈소스 컴플라이언스 달성을 위해 꼭 수행해야 할 여섯 가지 핵심 요구사항과 이를 입증하기 위해 필요한 자료 목록을 정의하고 있습니다.

1. 프로그램 설립
2. 관련 업무 정의 및 지원
3. 오픈소스 콘텐츠 검토 및 승인
4. 컴플라이언스 산출물 생성 및 전달
5. 오픈소스 커뮤니티 참여에 대한 이해
6. 규격 요구사항 준수

오픈소스 컴플라이언스를 처음 시작하는 기업이라면 이러한 OpenChain 규격의 요구사항을 하나씩 충족해가면서 수준을 향상시키는 것이 좋은 전략입니다.

이 OpenChain 규격은 2020년 12월 오픈소스 컴플라이언스에 대한 국제 표준인 ISO/IEC 5230:2020으로 정식 등록되었습니다.

지난 4년간 사실상의 표준이었던 OpenChain 규격이 ISO/IEC 5230:2020이라는 정식 국제 표준으로 전환되었고, 이는 오픈소스 컴플라이언스 및 프로세스 관리를 정의한 최초의 국제 표준입니다. 이로써 글로벌 IT기업의 ISO/IEC 5230 준수에 관한 관심이 높아지고 있고, 소프트웨어 공급망에서 공급자들에게 ISO/IEC 5230 준수를 요구하는 기업이 늘어날 것으로 예상됩니다.

2023년에는 오픈소스 보안 보증을 위한 새로운 표준인 ISO/IEC 18974가 발표되었습니다. 이 표준은 OpenChain 보안 보증 규격을 기반으로 하며, 오픈소스 소프트웨어의 알려진 보안 취약점을 관리하기 위한 핵심 요구사항을 정의합니다. ISO/IEC 18974는 다음과 같은 주요 영역을 다룹니다:

1. 보안 프로세스가 필요한 핵심 영역 식별
2. 역할과 책임 할당 방법
3. 프로세스의 지속 가능성 보장 방법

ISO/IEC 18974는 ISO/IEC 5230과 마찬가지로 간결하고 이해하기 쉬우며, 글로벌 커뮤니티의 지원을 받아 무료 참조 자료와 적합성 리소스를 제공합니다.

이 두 표준은 함께 작동하여 조직이 오픈소스 소프트웨어의 라이선스 컴플라이언스와 보안 보증을 효과적으로 관리할 수 있도록 지원합니다. ISO/IEC 5230이 라이선스 컴플라이언스에 중점을 둔다면, ISO/IEC 18974는 보안 취약점 관리에 초점을 맞추고 있어 상호 보완적인 역할을 합니다.

3. ISO/IEC 표준 인증 방법

ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 모두 준수한다면 이 표준들에 적합한 오픈소스 프로그램을 보유했음을 인증받을 수 있습니다. 오픈소스 프로그램이란 정책, 프로세스, 인원 등 기업이 오픈소스 컴플라이언스와 보안 보증 활동을 수행하기 위한 일련의 관리 체계를 의미합니다.

아래의 이미지는 ISO/IEC 5230이 요구하는 항목 번호를 나열한 그림입니다. 이 항목을 모두 충족하는 기업은 소프트웨어 공급망에서 투명하고 신뢰할 수 있는 오픈소스 거버넌스 체계를 구축하였다고 인정받을 수 있습니다.

OpenChain 프로젝트에서 제안하는 인증 방법은 세 가지입니다:

• 자체 인증
• 독립 평가
• 타사 인증

각각의 방법을 알아보겠습니다.

(1) 자체 인증

자체 인증은 OpenChain 프로젝트에서 가장 권장하는 방법이며, 비용이 발생하지 않는다는 장점이 있습니다. OpenChain Project는 기업이 OpenChain 규격을 준수하는지 자체적으로 확인할 수 있도록 ISO/IEC 5230 자체 인증 웹사이트를 제공합니다. 기업의 오픈소스 담당자는 이 웹사이트에 가입해 온라인 자체 인증을 시작할 수 있습니다. 자체 인증은 아래와 같이 Yes/No 질문에 답변하는 방식으로 진행됩니다.

오픈소스 컴플라이언스 체계를 잘 구축하여 OpenChain 자체 인증의 모든 질문에 Yes로 대답할 수 있다면 이 결과를 웹사이트상에 제출할 수 있습니다(Conforming Submission). 그러면 Linux Foundation의 간단한 문답식의 확인 절차를 거친 후 ISO/IEC 5230 인증을 선언할 수 있게 됩니다.

이렇게 인증 선언을 하게 되면, Global Software Supply Chain에서 ISO/IEC 5230을 준수하는 오픈소스 프로그램을 가진 기업으로 인정받게 됩니다.

OpenChain 프로젝트는 자체 인증 방식을 권장합니다. 참고로, OpenChain 적합성을 선언한 대부분의 기업도 자체 인증 방식을 채택하였습니다.

또한, 기업은 자체 인증 과정을 통해 부족한 부분이 무엇인지, 추가로 필요한 활동이 무엇인지 판단할 수 있습니다. 이 가이드에서는 조직, 정책, 프로세스 등 주요 구성 요소별로 ISO/IEC 5230과 ISO/IEC 18974 요구사항을 준수할 수 있는 방법을 설명합니다.

가이드만으로 자체적으로 보완할 수 있는 역량이 부족한 기업인 경우 독립 평가 방법을 고려할 수 있습니다.

(2) 독립 평가

독립 평가는 기업 외부의 독립 기관이 공정한 관점에서 기업의 오픈소스 컴플라이언스와 보안 보증 상태를 점검하고 평가합니다. 독립 평가의 특징은 평가 보고서를 생성하는 것에 그치지 않고 도출된 미비점을 보완하기 위한 컨설팅을 제공한다는 것입니다. (단, 공인 인증서를 발급하지는 않습니다.)

기업은 독립 기관으로부터의 공정한 평가와 컨설팅을 받아 컴플라이언스와 보안 보증 수준을 높이고, 다시 독립 평가를 수행하는 반복적인 과정을 통해 정책을 세분화하고 프로세스를 구축할 수 있습니다.

결국 기업은 ISO/IEC 5230과 ISO/IEC 18974 인증을 받을 수 있는 수준에 도달하게 되고, 그때 자체 인증, 혹은 타사 인증을 획득하는 절차에 돌입할 수 있습니다. 독립 평가는 이렇게 기업의 오픈소스 컴플라이언스와 보안 보증 수준을 높이기 위한 평가와 컨설팅을 제공하여 기업이 ISO/IEC 5230과 ISO/IEC 18974 적합 프로그램을 보유하고 인증을 획득할 수 있게 지원합니다.

독립 평가를 제공하는 업체는 AlektoMetis, Source Code Control 등이 있습니다.

국내에서는 OpenChain Korea Work Group의 Subgroup인 Conformance Group에서 기업간에 자체적으로 ISO/IEC 5230과 ISO/IEC 18974 준수를 위한 방법을 논의하고 공유하는 커뮤니티가 있습니다. OpenChain Korea Work Group 멤버라면 누구나 참여하여 도움을 받을 수 있습니다.

(3) 타사 인증

소프트웨어 공급망에서 구매자에게 보다 신뢰성 있고 투명한 오픈소스 컴플라이언스와 보안 보증 수준을 나타내고자 한다면 타사 인증 기관으로부터 인증서를 발급받고 이를 홍보에 활용할 수 있습니다. 또한, 오픈소스 컴플라이언스와 보안 보증의 보다 견고한 신뢰성을 요구하는 일부 구매자는 공급자(Supplier)에게 타사 인증을 의무화할 수도 있을 것으로 예상됩니다.

2024년 기준, OpenChain의 공인 타사 인증 기관은 ORCRO, PWC, TÜV SÜD, Synopsys, Bureau Veritas입니다.

이들은 ISO/IEC 5230과 ISO/IEC 18974 적합 프로그램 확인을 위한 평가를 제공하고 통과한 기업에 인증서를 발급합니다.

2024년 현재, 아직은 타사 인증을 의무적으로 요구하는 구매자나 기관은 많지 않습니다. 하지만 유럽의 자동차 업계에서는 ISO/IEC 5230과 ISO/IEC 18974가 ASPICE(Automotive SPICE, 자동차 소프트웨어 개발을 위한 국제 표준 프로세스 모델)와 같이 자동차 소프트웨어 공급자에게 의무화될 날이 머지않을 것이라고 예견하는 전문가도 있습니다.

또한, 자세한 자체 인증 방법은 다음 슬라이드를 참고할 수 있습니다:

• OpenChain Korea 9th Meeting - How to Self Certify

4. OpenChain Resources

OpenChain 프로젝트에서는 기업이 컴플라이언스 프로그램을 구축하는 데 필요한 정책 문서 템플릿, 교육 자료 등 다양한 문서 자료를 제공합니다. 이 자료는 OpenChain 규격을 준수하고 일반적인 오픈소스 컴플라이언스 활동을 지원하기 위해 고안됐으며, 누구나 자유롭게 사용할 수 있도록 CC-0 라이선스로 제공됩니다.

이 가이드의 많은 내용도 OpenChain에서 공개한 자료를 기반으로 작성하였습니다. 각 기업의 오픈소스 담당자는 정책, 프로세스, 교육자료가 필요하다면 OpenChain Resources를 먼저 찾아보기 바랍니다. 또한 이 자료는 한국어로도 번역되어 공개되고 있습니다. OpenChain Korea Work Group에서 이러한 번역 작업을 주도하고 있습니다. 한국어 번역은 관심 있는 누구나 참여할 수 있습니다.

OpenChain 프로젝트는 또한 다양한 웨비나와 스터디 그룹을 운영하여 추가적인 리소스를 제공하고 있습니다:

1. 웨비나: OpenChain 프로젝트는 정기적으로 웨비나를 개최하여 오픈소스 컴플라이언스와 보안 관련 최신 동향과 모범 사례를 공유합니다. 이 웨비나는 OpenChain 웹사이트에서 확인할 수 있으며, 녹화본도 제공됩니다.

2. 교육 자료: OpenChain 프로젝트는 종합적인 교육 커리큘럼을 제공하여 기업이 내부 교육 프로그램을 개발하는 데 도움을 줍니다. 이 자료는 오픈소스 소프트웨어의 기본 개념부터 라이선스 컴플라이언스, 보안 보증까지 다양한 주제를 다룹니다.

이러한 다양한 리소스를 활용함으로써, 기업은 ISO/IEC 5230과 ISO/IEC 18974 표준을 준수하는 강력한 오픈소스 프로그램을 구축하고 유지할 수 있습니다.

5. ISO/IEC 표준 적용 추세

ISO/IEC 5230과 ISO/IEC 18974 표준의 적용은 글로벌 소프트웨어 공급망에서 점차 확대되는 추세를 보이고 있습니다.

2021년 초, 독일의 자동차 제조사가 부품 공급업체에게 ISO/IEC 5230 준수 계획을 요구하기 시작했다는 소식이 전해졌습니다. 이에 대해 유럽의 한 오픈소스 분야 교수는 “앞으로 소프트웨어 공급망의 구매자는 공급자에게 ISO/IEC 5230 준수를 요구할 것이 명백하다"며, “자동차 업계에서는 ASPICE와 같은 위치를 차지하게 될 것"이라고 전망했습니다.

이러한 전망을 반영하듯 2021년 5월, 폭스바겐 그룹의 Scania는 공급업체가 따라야 하는 자체 기업 표준(STD 4589)에 ISO/IEC 5230 준수를 요구하는 내용을 포함시켰습니다.

또한, 2021년 7월, 자동차 및 산업 기술 기업인 Bosch는 연말까지 모든 그룹사가 ISO/IEC 5230을 준수하는 프로그램을 갖추겠다고 선언하였습니다. 업계에서는 모든 자동차 제조사나 다른 산업에서도 소프트웨어 공급망 내에서 ISO/IEC 5230을 요구하기 시작하는 것은 시간 문제라는 전망을 내놓고 있습니다.

2023년에는 오픈소스 보안 보증을 위한 새로운 표준인 ISO/IEC 18974가 발표되었습니다. 이 표준은 오픈소스 소프트웨어의 알려진 보안 취약점을 관리하기 위한 핵심 요구사항을 정의합니다. ISO/IEC 18974는 ISO/IEC 5230과 함께 조직이 오픈소스 소프트웨어의 라이선스 컴플라이언스와 보안 보증을 효과적으로 관리할 수 있도록 지원합니다.

2024년 현재, 이러한 추세는 더욱 가속화되고 있습니다. 예를 들어, KT는 2024년 10월에 ISO/IEC 18974 인증을 획득했다고 발표했습니다. 이는 국내 기업들도 오픈소스 보안 관리에 대한 국제 표준을 적극적으로 도입하고 있음을 보여줍니다.

또한, OpenChain Korea Work Group의 활동도 활발해지고 있습니다. 2024년 6월에 열린 제22차 정기 모임에서는 ISO/IEC 18974 오픈소스 보안 표준 준비 현황과 SBOM 기반 SW공급망 관리 가이드라인에 대한 논의가 이루어졌습니다. 이는 국내 기업들이 ISO/IEC 5230과 ISO/IEC 18974 표준을 적극적으로 수용하고 있음을 보여줍니다.

이러한 추세는 앞으로도 계속될 것으로 예상됩니다. 소프트웨어 공급망의 복잡성이 증가하고 보안 위협이 늘어남에 따라, ISO/IEC 5230과 ISO/IEC 18974와 같은 국제 표준의 중요성은 더욱 커질 것으로 보입니다. 기업들은 이러한 표준을 준수함으로써 오픈소스 사용의 투명성을 높이고, 보안 리스크를 효과적으로 관리할 수 있을 것입니다.

1.2 - 1. 조직

먼저, 기업은 오픈소스 관리 업무를 담당할 조직을 구성해야 합니다.

조직 구성 시 고려해야 할 내용은 다음과 같습니다:

• 조직의 역할과 책임
• 각 역할의 필요 역량
• 각 역할을 담당할 조직/담당자

1. 조직의 역할과 책임 정의

ISO 표준은 공통적으로 다음과 같이 프로그램 내 여러 참여자의 역할과 책임을 기술한 문서를 요구합니다.

오픈소스 프로그램 매니저

오픈소스 관리 체계를 구축하기 위해서는 먼저 이를 책임지고 수행할 책임자가 필요합니다. 책임자는 오픈소스 프로그램 매니저 또는 오픈소스 컴플라이언스 담당자 등의 명칭으로 불리며, 여기서는 오픈소스 프로그램 매니저라는 용어를 사용합니다.

오픈소스 프로그램 매니저는 기업의 오픈소스 프로그램 오피스를 담당합니다. 오픈소스 프로그램 오피스란 기업의 오픈소스 관리를 위한 조직을 의미하며, 오픈소스 사무국이라는 용어로도 사용됩니다.

아래의 역량을 가지고 있다면 오픈소스 프로그램 매니저 역할에 적합하다고 할 수 있습니다.

• 오픈소스 생태계에 대한 이해 및 개발 경험
• 기업의 비즈니스에 대한 폭넓은 이해
• 기업 구성원에게 효과적인 오픈소스 활용을 전파할 수 있는 열정과 커뮤니케이션 능력

오픈소스 프로그램 매니저는 가능한 풀타임으로 역할을 수행할 수 있도록 보장되는 것이 좋습니다.

글로벌 ICT 기업은 이와 같은 우수한 오픈소스 프로그램 매니저를 채용하기 위해 노력하고 있습니다. 다음 사이트에서 다양한 채용 공고를 확인할 수 있습니다. : https://github.com/todogroup/job-descriptions

역할과 책임 문서화

기업은 오픈소스 프로그램 오피스에 필요한 각 역할을 정의하고, 어떠한 책임을 부여해야 하는지를 판단해야 합니다.

소규모 기업의 경우, 오픈소스 프로그램 매니저 혼자서 모든 역할을 수행하는 것도 가능합니다. 기업의 규모에 따라 오픈소스 도구를 운영하는 IT 담당자도 필요할 수 있으며, 전문적인 법무 자문을 제공하기 위한 법무 담당의 역할이 요구될 수도 있습니다.

일반적으로 기업의 오픈소스 관리 체계 구축을 위해서는 아래의 역할이 필요합니다.

• 법무 담당
• IT 담당
• 보안 담당
• 개발 문화 담당

이를 위해 아래와 같이 오픈소스 프로그램 오피스를 구성하는 역할과 책임을 문서화해야 합니다.

2. 필요 역량 정의

각 역할과 그에 대한 책임을 정의하였다면, 그 역할을 수행할 인원이 갖춰야 할 필수 역량이 무엇인지 파악해야 합니다.

ISO 표준은 공통적으로 다음과 같이 각 역할을 위해 필요한 역량을 기술한 문서를 요구합니다.

이를 통해 역할별 담당자가 해당 역할을 수행할 수 있는 역량을 갖추었는지 평가하고, 필요시 교육을 제공해야 하기 때문입니다.

이를 위해 기업은 아래와 같이 각 역할을 위해 필요한 역량을 기술하여 문서화해야 합니다.

3. 담당자 지정

오픈소스 프로그램 매니저는 관련 부서와 협의하여 각 역할을 위한 담당자를 지정하고 이를 문서화합니다. 이를 위해서는 CEO 등 최고 의사결정권자에게 오픈소스 컴플라이언스 체계 구축을 위한 목표와 방향을 보고하여 필요한 지원을 받아야 합니다.

오픈소스 관련 조직과 담당자는 반드시 풀타임으로 오픈소스 업무에 참여할 필요는 없습니다. OSRB (Open Source Review Board) 형태의 가상 조직을 구성하여 필요한 역할을 수행하는 것도 가능합니다.

ISO 표준은 공통적으로 다음과 같이 프로그램 내 각 역할을 담당하는 인원, 그룹 또는 직무의 이름을 기재한 문서를 요구합니다.

이를 위해 기업은 아래와 같이 프로그램 내 각 역할을 담당하는 인원, 그룹 또는 직무의 이름을 문서화해야 합니다.

다음 페이지에서는 역할, 책임, 필요 역량 및 담당자 지정 등을 문서화한 샘플을 참고할 수 있습니다. [부록1]오픈소스 정책(샘플) - Appendix 1. 담당자 현황

SK텔레콤은 OSRB를 구성하여 기업 내 오픈소스 정책과 프로세스를 만들고, 이슈 발생 시 협업하여 대응 방안을 마련하고 있습니다.

4. Summary

역할, 책임, 필요 역량 및 담당자 지정을 문서화한 샘플은 오픈소스 정책 템플릿 문서에서 확인할 수 있습니다. : Appendix 1. 담당자 현황

기업은 이를 참고하여 기업의 상황에 맞게 오픈소스 관리 조직을 구성할 수 있습니다.

이렇게 오픈소스 프로그램 오피스 조직을 지정하고 문서화하면, ISO 표준 규격 중 아래의 붉은색으로 표시된 요구사항을 충족하게 됩니다.

사실, 문서화하는 것보다 실제 업무를 충실히 수행할 담당자를 지정하고, 담당자가 역량을 확보할 수 있도록 지원하는 것이 더 중요합니다.

한국저작권위원회의 오픈소스 라이선스 전문 교육이나 NIPA의 공개소프트웨어 매니지먼트 아카데미에 참여하여 체계적인 교육을 수강하는 것도 매우 도움이 됩니다.

오픈소스 프로그램 매니저와 보안 담당의 역할이 더욱 중요해지고 있습니다. 오픈소스 프로그램 매니저는 오픈소스 보안 보증에 대한 기본 지식도 갖추어야 하며, 보안 담당자는 SBOM (Software Bill of Materials) 관리와 같은 새로운 보안 요구사항에 대한 이해도 필요합니다.

ISO/IEC 5230 / 18974 준수 가이드 — 이 섹션과 관련된 조항:

• §3.1.2 역량 — 역할별 역량 정의·평가 기록
• §3.2.2 효과적 리소스 — 담당자 지정 문서화, 미준수 검토 절차

또한, 모든 역할에서 지속적인 학습과 최신 트렌드 파악이 중요해지고 있습니다. 오픈소스 생태계와 관련 기술, 법규는 빠르게 변화하고 있어, 각 담당자는 자신의 분야에서 지속적으로 지식을 업데이트해야 합니다. 이를 위해 OpenChain이나 TODO Group과 같은 국제 커뮤니티에 참여하거나, 국내 오픈소스 컨퍼런스에 참석하는 것도 좋은 방법입니다.

1.3 - 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. **성과 지표 목록**:
    ISO/IEC 18974 §4.1.4.2는 프로그램이 달성해야 할 **정량적 성과 메트릭 세트**를 요구합니다.
    아래는 권장 지표와 초기 목표값 예시입니다. 각 기업은 비즈니스 환경에 맞춰 목표값을 조정할 수 있습니다.

    | 지표 | 측정 방법 | 목표값(예시) | 측정 주기 |
    |------|----------|------------|---------|
    | SBOM 완전성 | 공급 소프트웨어 중 SBOM이 생성된 비율 | 100% | 분기 |
    | Critical 취약점 평균 대응 시간(MTTD) | CVE 공개 → 조치 완료까지의 평균 일수 | 7일 이내 | 분기 |
    | High 취약점 평균 대응 시간 | CVE 공개 → 조치 완료까지의 평균 일수 | 30일 이내 | 분기 |
    | 취약점 재발생률 | 동일 컴포넌트에서 6개월 내 재발 비율 | 10% 이하 | 반기 |
    | 외부 문의 초기 응답 준수율 | 14영업일 이내 초기 응답 비율 | 95% 이상 | 분기 |
    | 신규 참여자 교육 이수율 | 온보딩 후 3개월 내 교육 완료 비율 | 100% | 분기 |
    | 컴플라이언스 산출물 제공율 | 공급 소프트웨어 배포 시 산출물 동봉 비율 | 100% | 릴리스마다 |

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. **공개 연락처**:
    - **라이선스 컴플라이언스 문의** (ISO/IEC 5230 §3.2.1.1): 오픈소스 프로그램 매니저의 공식 이메일 주소를 공개합니다. (예: `oss@company.com`)
    - **보안 취약점 신고 채널** (ISO/IEC 18974 §4.2.1.1): 보안 취약점 전용 이메일 주소를 별도로 공개합니다. (예: `security@company.com`)
    - 두 채널을 구분하면 처리 우선순위 관리와 담당자 배정이 용이합니다.
    - 연락처는 다음과 같은 위치에 공개합니다:
        - 오픈소스 고지문
        - 회사 웹사이트(보안 정책 페이지 포함)
        - Linux Foundation의 Open Compliance Directory
        - `/.well-known/security.txt` 파일 (RFC 9116, 보안 취약점 신고 채널 표준)
2. **보안 취약점 채널 운영 원칙**:
    - 보고 채널이 실제로 모니터링되고 있음을 명시합니다. (예: "영업일 기준 3일 이내 수신 확인 응답")
    - CVD(Coordinated Vulnerability Disclosure) 원칙에 따라 비공개 협력 후 공개하는 방침을 명시합니다.
3. **문의 방법 안내**:
    - 외부에서 오픈소스 관련 문의를 할 수 있는 방법을 명확히 안내합니다.
    - 이메일 주소, 웹사이트 문의 양식 등을 통해 문의를 받을 수 있도록 시스템을 운영합니다.

### 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 표준의 주요 요구사항을 충족할 수 있습니다.

ISO/IEC 5230 / 18974 준수 가이드 — 이 섹션과 관련된 조항:

• §3.1.1 정책 — 문서화된 오픈소스 정책
• §3.1.4 프로그램 범위 — 적용 범위 정의
• §3.2.1 외부 문의 접근성 — 공개 문의 채널
• §3.2.2 효과적 리소스 — 인원·예산·미준수 검토
• §3.5.1 기여 — 기여 정책
• §4.1.4 프로그램 범위(18974) — 성과 메트릭 정의
• §4.2.1 접근성(18974) — 취약점 신고 채널

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

1.4 - 3. 프로세스

오픈소스 프로세스는 소프트웨어 개발 및 배포 과정에서 기업이 오픈소스 정책을 준수할 수 있도록 하는 실행 가능한 절차입니다.

오픈소스 라이선스 컴플라이언스 측면에서는 공급 소프트웨어를 개발하고 배포하면서 사용한 오픈소스에 대해 각 라이선스가 요구하는 조건을 준수하기 위한 활동을 수행하여 오픈소스 고지문(Notice), 공개할 소스 코드 (Source Code) 등의 컴플라이언스 산출물을 생성하게 됩니다.

오픈소스 보안 보증을 위해서는 공급 소프트웨어에 대한 알려진 취약점 또는 새로 발견된 취약점 존재 여부를 탐지하고, 구조적/기술적 위협을 식별하여 출시 전에 문제를 해결하기 위한 활동을 수행해야 합니다.

기업이 효과적인 오픈소스 라이선스 컴플라이언스와 보안 보증을 이루기 위해서는 아래와 같은 프로세스를 구축해야 합니다:

• 오픈소스 프로세스
• 오픈소스 보안 취약점 대응 프로세스
• 외부 문의 대응 프로세스
• 오픈소스 기여 프로세스

그럼 각 프로세스가 어떻게 구성되어야 하는지 하나하나 살펴보겠습니다.

1. 오픈소스 프로세스

기업은 소프트웨어 개발 프로세스에 따라 오픈소스 라이선스 컴플라이언스와 보안 보증을 위한 오픈소스 프로세스를 구축해야 합니다.

아래의 이미지는 기업이 일반적으로 채택하여 사용할 수 있는 샘플 오픈소스 프로세스입니다.

위 오픈소스 프로세스에 맞춰서 각 단계별로 취해야 할 절차는 다음과 같습니다.

(1) 오픈소스 식별 및 검사

오픈소스 식별 및 검사 단계에서는 사용하려는 오픈소스의 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무사항은 무엇인지, 알려진 취약점은 존재하는지 확인해야 합니다.

어떤 오픈소스를 사용하려고 하는지, 그 라이선스는 무엇인지, 각 라이선스가 부여하는 의무는 무엇인지, 알려진 취약점은 무엇인지 검토하고 기록합니다.

ISO/IEC 5230 표준은 라이선스 컴플라이언스를 위해 일반적인 오픈소스 라이선스의 사용 사례를 다룰 수 있어야 하고, 각 식별된 라이선스에 의해 부여된 의무, 제한 및 권리를 검토하고 기록하기 위한 문서화된 절차를 요구합니다.

이를 위한 절차의 예는 다음과 같습니다:

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

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

2. 사업 부서는 오픈소스 정책에서 정의한 기준에 따라 라이선스와 알려진 취약점을 확인합니다.

3. 사업 부서는 의문 사항을 오픈소스 프로그램 매니저와 보안 담당에게 문의합니다. 필요할 경우 외부 전문가에게 자문을 요청합니다.

4. 모든 결정 및 관련 근거는 문서화하여 보관합니다.

이를 위해 기업은 아래의 예시와 같이 공급 소프트웨어 출시 전에 오픈소스 식별, 검사 단계를 통해 각 식별된 라이선스가 부가하는 의무, 제한과 알려진 취약점을 검토하고 기록하기 위한 문서화된 절차를 수립해야 합니다.

(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주 이내 조치할 수 있는 계획을 수립하도록 안내합니다.

오픈소스 식별 및 검사 단계에서는 소스 코드 스캔 도구를 사용할 수 있습니다. 이에 대한 자세한 내용은 “1. 소스 코드 스캔 도구“에서 설명합니다.

(2) 문제 해결

오픈소스 식별 및 검사를 통해 오픈소스를 식별하고 라이선스와 보안 취약점의 위험을 확인한 후에는 문제를 해결하는 절차가 필요합니다. 다음과 같은 방법으로 검출된 모든 문제를 해결해야 합니다:

• 이슈가 되는 오픈소스를 삭제합니다.
• 오픈소스 라이선스 이슈 해결을 위해 다른 라이선스 하의 오픈소스로 교체합니다.
• 알려진 취약점 또는 새로 발견된 취약점이 해결된 버전의 오픈소스로 교체합니다.

이를 위한 문서화된 프로세스의 예는 다음과 같습니다:

(3) 문제 해결

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

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

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

(3) SBOM 식별, 검토, 보관

오픈소스 라이선스 컴플라이언스 활동의 가장 기본은 공급 소프트웨어에 포함된 오픈소스 현황을 파악하는 것입니다. 공급 소프트웨어에 포함된 오픈소스와 그 라이선스를 식별하여 그 정보를 담고 있는 SBOM(Software Bill of Materials)을 작성하고 관리하는 프로세스를 구축해야 합니다. 공급 소프트웨어의 버전마다 어떤 오픈소스가 포함되어 있는지 알고 있어야 소프트웨어를 배포할 때 각 오픈소스의 라이선스가 요구하는 의무 사항을 준수할 수 있기 때문입니다. 이는 오픈소스 보안 취약점을 발견하고 대응하기 위해서도 꼭 필요한 과정입니다.

모든 오픈소스는 공급 소프트웨어에 통합하기 전에 검토 및 승인되어야 합니다. 오픈소스의 기능, 품질뿐만 아니라 출처, 라이선스 요건을 충족할 수 있는지, 알려진 취약점 또는 새로 발견된 취약점을 해결하였는지 등에 대해 사전 검토가 되어야 합니다. 이를 위해 검토 요청 → 리뷰 → 승인 과정이 필요합니다.

ISO 표준은 공통적으로 다음과 같이 공급 소프트웨어에 사용된 모든 오픈소스 소프트웨어가 소프트웨어 수명 주기 동안 지속적으로 기록되도록 하는 문서화된 절차를 요구합니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 프로세스에 SBOM에 대한 내용을 반영할 수 있습니다:

(4) 검토

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

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

(5) 승인

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

(6) 등록

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

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

- 공급 소프트웨어의 제품(혹은 서비스) 이름과 버전
- 오픈소스 목록
  - 오픈소스 이름 / 버전
  - 오픈소스 라이선스

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

SBOM 관리를 위한 도구에 대해서는 “SBOM 관리 도구“에서 자세히 설명합니다.

또 이와 같은 오픈소스 프로세스의 모든 과정과 결과는 문서화가 되어야 합니다. 이메일을 사용하는 것보다는 Jira, Bugzilla 등의 이슈 트래킹 시스템을 이용하는 것이 이러한 과정을 효율적으로 문서화 할 수 있습니다.

(4) 라이선스 컴플라이언스 산출물 생성

오픈소스 라이선스 컴플라이언스 활동의 가장 기본은 공급 소프트웨어에 포함된 오픈소스 현황을 파악하는 것입니다. 이는 오픈소스 라이선스 컴플라이언스의 핵심인 오픈소스 라이선스 요구사항을 올바르게 충족하기 위해서입니다. 즉, 공급 소프트웨어에 포함된 오픈소스에 대한 컴플라이언스 산출물 세트를 생성하는 프로세스가 구축되어야 합니다.

ISO/IEC 5230 표준은 다음과 같이 컴플라이언스 산출물을 준비하고, 이를 공급 소프트웨어와 함께 제공하기 위한 프로세스를 설명하는 문서화된 절차를 요구합니다.

컴플라이언스 산출물은 크게 두 가지로 구분됩니다:

1. 오픈소스 고지문: 오픈소스 라이선스 전문과 저작권 정보 제공을 위한 문서

   

• 도구를 활용하여 취합한 SBOM에 해당하는 오픈소스 고지문을 생성하는 방법에 대해 “오픈소스 컴플라이언스 산출물 생성 도구“에서 추가로 설명합니다.

2. 공개할 소스 코드 패키지: GPL, LGPL 등 소스 코드 공개를 요구하는 오픈소스 라이선스 의무 이행을 위해 공개할 소스 코드를 취합한 패키지

컴플라이언스 산출물은 공급 소프트웨어를 배포할 때 함께 제공해야 합니다.

이를 위해 기업은 아래의 예시와 같이 오픈소스 프로세스에 고지 단계부터 배포 단계까지 컴플라이언스 산출물 생성에 대한 내용을 반영할 수 있습니다:

(7) 고지

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

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

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

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

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

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

(8) 배포 전 확인

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

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

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

(9) 배포

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

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

공급 소프트웨어를 배포하는 경우, 공개할 소스 코드 패키지를 동봉하는 것이 곤란할 수 있습니다. 이 경우, 최소 3년간 소스 코드를 제공하겠다는 서면 청약(Written Offer)을 제공하는 것으로 대신할 수 있습니다. 일반적으로 서면 청약은 제품의 사용자 매뉴얼을 통해 제공되며, 예시는 다음과 같습니다:

The software included in this product contains copyrighted software 
that is licensed under the GPL. A copy of that license is included 
in this document on page X. You may obtain the complete Corresponding 
Source code from us for a period of three years after our last shipment 
of this product, which will be no earlier than 2011-08- 01, by sending 
a money order or check for $5 to:

GPL Compliance Division
Our Company
Any Town, US 99999

Please write"source for product Y" in the memo line of your payment.
You may also find a copy of the source at http://www.example.com/sources/Y/.
This offer is valid to anyone in receipt of this information.

<출처 : SFLC Guide to GPL Compliance>

따라서, 컴플라이언스 산출물은 3년 이상 보관해야 하며, 이를 위한 프로세스가 구축되어야 합니다.

이를 위해 기업은 오픈소스 웹사이트 구축을 고려할 수 있습니다. 자세한 내용은 “오픈소스 컴플라이언스 산출물 보관“에서 확인하실 수 있습니다.

(5) 보안 취약점 검사 및 평가

보안 담당은 공급 소프트웨어의 오픈소스 소프트웨어 컴포넌트에 대한 알려진 취약점 또는 새로 발견된 취약점을 검사하고 평가하는 프로세스를 구축해야 합니다. 이 프로세스는 다음과 같은 단계를 포함해야 합니다:

1. 취약점 데이터베이스 검색: National Vulnerability Database (NVD)와 같은 공개 취약점 데이터베이스를 활용하여 사용 중인 오픈소스 컴포넌트의 알려진 취약점을 검색합니다.

2. 자동화된 취약점 스캔 도구 사용: OWASP Dependency-Check와 같은 도구를 사용하여 공급 소프트웨어의 의존성을 스캔하고 알려진 취약점을 식별합니다.

3. 취약점 심각도 평가: CVSS (Common Vulnerability Scoring System)를 사용하여 발견된 취약점의 심각도를 평가합니다.

4. 위험 분석: 식별된 취약점이 공급 소프트웨어에 미치는 잠재적 영향을 분석합니다.

5. 대응 계획 수립: 심각도와 위험 분석 결과에 따라 각 취약점에 대한 대응 계획을 수립합니다.

(2) 소스 코드 검사

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

| Risk | CVSS 2.0 | CVSS 3.0 | 조치 권고 일정 |
|---|:---:|:---:|:---:|
| Low | 0.0 - 3.9 | 0.0 - 3.9 | - |
| Medium | 4.0 - 6.9 | 4.0 - 6.9 | - |
| High | 7.0 - 10.0 | 7.0 - 8.9 | 4주 이내 | 
| Critical | - | 9.0 - 10.0 | 1주 이내 |

6. 보고 및 문서화: 검사 결과, 평가 내용, 대응 계획을 문서화하고 관련 이해관계자에게 보고합니다.

7. 지속적인 모니터링: 새로운 취약점이 발견되거나 기존 취약점의 심각도가 변경될 수 있으므로, 지속적인 모니터링 체계를 구축합니다.

이러한 프로세스를 통해 공급 소프트웨어의 보안 취약점을 효과적으로 관리하고, ISO/IEC 18974의 요구사항을 충족할 수 있습니다.

2. 오픈소스 보안 취약점 대응 프로세스

기업은 공급 소프트웨어를 개발하면서 오픈소스 보안 취약점을 탐지하고 해결하는 등 보안 보증을 위한 활동을 수행해야 합니다.

ISO/IEC 18974 표준은 다음과 같이 보안 보증 방법에 대한 문서화된 절차와 수행된 조치를 기록하도록 요구합니다.

이를 위해 기업은 공급 소프트웨어에서 알려진 취약점 또는 새로 발견된 취약점 존재 여부를 탐지하고, 식별된 위험이 출시 전에 해결해야 할 뿐 아니라 출시 후 새롭게 알려진 취약점에 대응하기 위한 방법과 절차를 갖춰야 합니다.

먼저 기업은 배포용 소프트웨어에 알려진 취약점이 있는지 탐지하고, 식별된 위험을 출시 전에 해결해야 합니다. 이와 같이 알려진 취약점을 탐지하고 해결하는 절차는 오픈소스 프로세스의 오픈소스 식별 단계, 소스 코드 검사 단계, 문제 해결 단계를 통해 수행할 수 있습니다.

그리고, 배포용 소프트웨어의 릴리스 후 새롭게 알려진 취약점이 공개되었을 때 이미 배포된 소프트웨어에 존재하는지 확인하고, 해결하기 위해서는 신규 보안 취약점 대응 프로세스를 수립해야 합니다.

아래는 신규 보안 취약점 발견 시 대응을 위한 프로세스 샘플입니다.

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

(1) 모니터링

IT 담당은 새로운 보안 취약점을 모니터링하는 시스템을 구축하여 운영합니다. 이 시스템은 다음과 같은 기능을 수행합니다.

- 새로운 보안 취약점이 공개되는 것을 주기적으로 수집합니다.
- 새로운 알려진 취약점을 갖고 있는 오픈소스가 이미 출시된 제품/서비스에 사용된 경우, 해당 제품/서비스의 사업 부서 담당자에게 알림을 보냅니다. 이때 알림부터 검토, 조치, 해결 사항이 모두 문서화되어 기록될 수 있도록 Jira Issue Tracker를 사용합니다.

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

• National Vulnerability Database (NVD)와 같은 공개 취약점 데이터베이스에서 새로운 보안 취약점 정보를 주기적으로 수집합니다.
• 알려진 취약점 또는 새로 발견된 취약점을 갖고 있는 오픈소스 소프트웨어 컴포넌트가 이미 출시된 공급 소프트웨어에 사용된 경우, 해당 공급 소프트웨어의 사업 부서 담당자에게 알림을 보냅니다.
• 알림부터 검토, 조치, 해결 사항이 모두 문서화되어 기록될 수 있도록 Jira와 같은 이슈 추적 시스템을 사용합니다.

(2) 취약점 평가 및 대응

(2) 초기 대응

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

사업 부서는 기존 출시한 제품/서비스에 새로운 보안 취약점이 발견된 경우, 보안 담당자가 제공한 대응 가이드에 따라 조치 계획을 수립합니다.

보증이 필요한 고객이 있는 경우, 사업 부서는 위험도에 따라 필요한 경우 이메일 등의 방법으로 확인된 알려진 취약점을 고지합니다.

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

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

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

(3) 보안 테스트 적용

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

• 공급 소프트웨어의 구조적 및 기술적 위협을 식별합니다.
• 알려진 취약점 또는 새로 발견된 취약점의 존재를 탐지합니다.
• 식별된 위험이 공급 소프트웨어의 출시 전에 해결되었는지 확인합니다.

(4) 취약점 해결 및 패치 관리

(3) 문제 해결

사업 부서는 수립한 조치 계획에 따라 문제가 되는 오픈소스를 삭제하거나 패치된 버전으로 교체하는 등의 방법으로 보안 취약점 문제를 해결합니다. 발견된 모든 이슈를 해결하면, 재검토를 요청합니다.

(4) 검토

IT 담당은 오픈소스 분석 도구를 활용하여 문제가 적절하게 해결되었는지 확인합니다.

(5) 승인

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

(6) 등록

IT 담당은 오픈소스 보안 취약점이 해결된 SBOM을 시스템에 등록합니다.

사업 부서는 수립한 조치 계획에 따라 문제가 되는 오픈소스 소프트웨어 컴포넌트를 제거하거나 패치된 버전으로 교체하는 등의 방법으로 취약점 문제를 해결합니다.

IT 담당은 오픈소스 분석 도구를 활용하여 문제가 적절하게 해결되었는지 확인합니다.

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

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

(5) 고객 통지

(7) 고지

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

사업 부서는 제품 배포 시 동봉한 오픈소스 고지문을 교체합니다.

IT 담당은 수정된 오픈소스 고지문을 회사의 오픈소스 배포 사이트에 등록합니다.

(8) 배포

사업 부서는 오픈소스 보안 취약점 문제가 해결된 버전의 소프트웨어를 재배포합니다.

보안 담당은 제3자에게 공개가 필요한 위험 정보가 존재하는지 식별하고, 존재할 경우 IT 담당자에게 전달합니다.

IT 담당은 신별된 위험에 대한 정보를 오픈소스 웹사이트에 등록하여 제3자가 확인할 수 있게 합니다.

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

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

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

IT 담당은 수정된 오픈소스 고지문과 취약점 관련 정보를 회사의 오픈소스 배포 사이트에 등록하여 제3자가 확인할 수 있게 합니다.

이 프로세스를 통해 공급 소프트웨어가 시장에 출시된 후에도 지속적인 모니터링 및 대응 기능을 유지합니다.

이러한 체계적인 접근 방식을 통해 조직은 다음과 같은 이점을 얻을 수 있습니다:

1. 새로운 취약점에 대한 신속한 대응 능력 확보
2. 고객에 대한 투명성 및 신뢰도 향상
3. 보안 위험의 최소화 및 관리
4. 규제 요구사항 준수 보장
5. 지속적인 제품 품질 및 보안 개선

또한 이 프로세스는 ISO/IEC 18974의 요구사항을 충족시키며, 조직의 오픈소스 보안 보증 프로그램의 효과성을 지속적으로 향상시킬 수 있습니다.

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

기업이 외부 클레임으로 인해 법적 소송에까지 이르지 않기 위해서는 외부 문의 및 요청에 가능한 한 빠르고 정확하게 대응하는 것이 중요합니다. 이를 위해 기업은 외부 오픈소스 문의에 빠르고 효과적으로 대응할 수 있는 프로세스를 구축해야 합니다.

ISO 표준은 공통적으로 다음과 같이 제3자의 문의에 대응하기 위한 내부의 문서화된 절차를 요구합니다.

아래 그림은 외부 문의 대응을 위해 기업이 갖춰야할 프로세스 샘플입니다.

다음은 오픈소스 프로세스 템플릿에서 제시하는 외부 문의 대응 프로세스입니다:

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

(1) 접수 알림

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

주요 문의 및 요청 내용:

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

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

(2) 조사 알림

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

(3) 내부 조사

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

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

(4) 요청자에게 보고

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

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

(5) 문제 보완 / 알림

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

(6) 문제 해결 알림

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

(7) 프로세스 개선

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

이러한 체계적인 외부 문의 대응 프로세스를 통해 기업은 오픈소스 관련 이슈에 신속하고 효과적으로 대응할 수 있으며, 잠재적인 법적 위험을 최소화할 수 있습니다.

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

기업이 외부 오픈소스 프로젝트에 기여를 허용하는 정책을 갖고 있다면, 프로그램 참여자들이 어떤 절차로 외부 프로젝트에 기여할 수 있을지 관리하는 문서화된 절차가 있어야 합니다.

ISO/IEC 5230 표준은 다음과 같이 오픈소스 기여를 관리하는 문서화된 절차를 요구합니다.

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

오픈소스 프로세스 템플릿에서는 다음과 같이 기여 정책 수립 및 전파에 대해 설명하고 있습니다:

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

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

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

오픈소스 프로세스 템플릿에서는 다음과 같이 기여 검토 및 승인 절차에 대해 설명하고 있습니다:

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

오픈소스 기여를 관리하는 문서화된 절차를 수립해야 합니다. 이 절차는 다음 사항을 포함해야 합니다:
- 기여하려는 코드의 출처와 라이선스를 확인합니다.
- 기여할 권리가 있는 코드인지 검토합니다.
- 기여하려는 프로젝트의 라이선스와 기여 정책을 검토합니다.
- 필요한 경우, 법무팀의 검토를 받습니다.
- 기여에 대한 승인 절차를 정의합니다.
- 승인된 기여의 제출 방법을 명시합니다.

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

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

SK텔레콤에서 공개한 오픈소스 기여 절차는 좋은 예시입니다:

https://sktelecom.github.io/guide/contribute/process/

이 절차는 기여 검토 요청부터 승인, 기여 제출까지의 과정을 명확하게 보여주고 있어 프로그램 참여자들이 쉽게 이해하고 따를 수 있습니다.

5. 프로세스 현행화

프로세스가 문서화만 되어 있고 실제 운영되지 않거나, 업무 상황이나 조직 구성에 맞지 않게 되어 있다면 효과적이지 않습니다. 기업은 프로세스가 회사 내부 조직과 상황에 맞게 항상 최신 상태로 유지되도록 해야 합니다.

ISO/IEC 18974 표준은 다음과 같이 프로세스를 주기적으로 검토 및 개선해야 함을 요구합니다:

(1) 정기적인 프로세스 검토

오픈소스 프로세스 템플릿에서는 다음과 같이 정기적인 프로세스 검토에 대해 설명하고 있습니다:

OSRB(Open Source Review Board)는 회사의 오픈소스 관리를 위해 오픈소스 프로그램 매니저와 법무팀, 특허팀, 개발팀, 인프라팀 등 관련 조직의 책임자로 구성된 협의체입니다.

OSRB는 매년 정기적으로 검토하여 정책과 프로세스를 개선합니다. 모든 개선 과정은 문서화하여 기록합니다.

(2) 개선 사항 식별 및 구현

프로세스 개선을 위해 다음과 같은 활동을 수행합니다:

• OSRB는 회사의 프로세스 수행 성과와 미흡한 부분, 모범 사례를 분석합니다.
• 비즈니스 환경 변화를 반영하여 프로세스를 개선합니다.
• 오픈소스 라이선스 컴플라이언스를 위한 정책과 프로세스는 오픈소스 프로그램 매니저가 책임을 갖고 관리합니다.
• 오픈소스 보안 보증을 위한 정책과 프로세스는 보안 담당이 책임을 갖고 관리합니다.

(3) 프로세스 업데이트 문서화

프로세스 개선 및 업데이트 과정을 문서화하여 기록합니다. 이는 다음을 포함해야 합니다:

• 검토 일자 및 참여자
• 식별된 개선 사항
• 구현된 변경 내용
• 변경 사유
• 변경 승인자

이러한 문서화된 기록은 Jira나 Confluence와 같은 도구를 활용하여 관리할 수 있습니다.

프로세스 현행화를 통해 기업은 오픈소스 라이선스 컴플라이언스와 보안 보증 프로그램의 효과성을 지속적으로 개선하고, ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 충족할 수 있습니다.

6. Summary

여기까지 프로세스를 구축하게 되면 ISO/IEC 5230과 ISO/IEC 18974 표준 규격의 주요 요구사항을 충족할 수 있습니다.

이러한 프로세스 구축을 통해 기업은 다음과 같은 이점을 얻을 수 있습니다:

1. 오픈소스 라이선스 컴플라이언스 체계 확립

   • 공급 소프트웨어의 오픈소스 사용 현황을 정확히 파악
   • 라이선스 의무사항을 준수하여 법적 위험 최소화
   • 컴플라이언스 산출물의 체계적인 생성 및 관리

2. 오픈소스 보안 보증 강화

   • 알려진 취약점 및 새로 발견된 취약점에 대한 지속적인 모니터링
   • 취약점 평가 및 대응 체계 구축
   • 보안 테스트를 통한 사전 위험 예방

3. 외부 문의에 대한 효과적인 대응

   • 체계적인 외부 문의 처리 프로세스 수립
   • 신속하고 정확한 대응을 통한 법적 위험 감소

4. 오픈소스 기여 활동의 체계화

   • 기여 정책 수립을 통한 일관된 기여 활동 보장
   • 기여 검토 및 승인 절차를 통한 지식재산 보호

5. 지속적인 프로세스 개선

   • 정기적인 프로세스 검토 및 개선을 통한 효율성 향상
   • 최신 오픈소스 동향 및 기술 변화에 대한 대응력 강화

이러한 프로세스 구축을 통해 기업은 오픈소스 라이선스 컴플라이언스와 보안 보증을 체계적으로 관리하고, 지속적으로 개선할 수 있는 기반을 마련할 수 있습니다. 또한, OpenChain Project와 같은 국제 표준 이니셔티브에 부합하는 프로세스를 갖춤으로써 글로벌 소프트웨어 공급망에서의 신뢰도를 높일 수 있습니다.

ISO/IEC 5230 / 18974 준수 가이드 — 이 섹션과 관련된 조항:

• §3.1.5 라이선스 의무 — 8가지 사용 사례별 처리 절차
• §3.3.2 오픈소스 컴포넌트 기록 — SBOM 기록 절차
• §3.4.1 컴플라이언스 산출물 — 산출물 보관 기간·버전 관리
• §3.5.1 기여 — 기여 승인 절차
• §4.1.5 표준 관행 구현 — 8가지 취약점 처리 방법
• §4.3.2 보안 보증 — CVE 탐지→평가→조치→통보→모니터링

1.5 - 4. 도구

1. 소스 코드 스캔 도구

오픈소스 프로세스의 오픈소스 식별 및 검사 단계에서는 소스 코드 스캔 도구를 사용할 수 있습니다. 소스 코드 스캔 도구는 공급 소프트웨어에 포함된 오픈소스를 식별하고, 라이선스 및 저작권 정보를 추출하는 데 도움을 줍니다. 이러한 도구는 무료로 사용할 수 있는 오픈소스 기반 도구부터 상용 도구까지 다양합니다. 각 도구는 특장점이 있지만, 어떤 도구도 모든 문제를 해결할 수 있는 완벽한 기능을 제공하지 않습니다. 따라서 기업은 공급 소프트웨어의 특성과 요구사항에 맞는 적합한 도구를 선택해야 합니다.

많은 기업이 이러한 자동화된 소스 코드 스캔 도구와 수동 검토를 병행하여 이용합니다. 여기서는 두 가지 주요 오픈소스 소스 코드 스캔 도구를 소개합니다.

(1) FOSSology

FOSSology는 Linux Foundation에서 관리하는 오픈소스 프로젝트로, 라이선스 컴플라이언스 워크플로우를 지원하는 소스 코드 스캔 도구입니다.

주요 기능:

• 소스 코드 스캔 및 라이선스 식별
• 라이선스 및 저작권 정보 추출
• 웹 기반 사용자 인터페이스 제공
• 대규모 코드베이스 분석 지원

FOSSology는 기업들이 무료로 사용할 수 있으며, 오픈소스 커뮤니티의 지속적인 개선과 지원을 받고 있습니다.

FOSSology의 설치 및 사용 방법은 FOSSology 가이드를 참조하시기 바랍니다.

(2) SCANOSS

SCANOSS는 오픈소스 소프트웨어 구성 요소를 식별하고 관리하기 위한 플랫폼입니다.

주요 기능:

• 빠른 소스 코드 스캔 및 오픈소스 컴포넌트 식별
• 라이선스 및 취약점 정보 제공
• API를 통한 통합 지원
• SBOM(Software Bill of Materials) 생성

SCANOSS는 무료 버전과 유료 버전을 제공하며, 클라우드 기반 서비스와 온프레미스 솔루션을 모두 지원합니다.

이러한 소스 코드 스캔 도구를 활용하여 공급 소프트웨어의 오픈소스 컴포넌트를 효과적으로 식별하고 관리할 수 있습니다. 그러나 도구의 결과만을 전적으로 신뢰하기보다는, 프로그램 참여자의 전문적인 검토와 판단이 함께 이루어져야 합니다.

2. Dependency 분석 도구

최근의 소프트웨어 개발에서는 Gradle, Maven과 같은 패키지 관리자를 지원하는 빌드 환경을 사용합니다. 이러한 빌드 환경에서는 소스 코드가 없어도 빌드 타임에 필요한 Dependency 라이브러리를 원격 저장소로부터 받아와 공급 소프트웨어를 구성합니다. 이때의 Dependency 라이브러리는 공급 소프트웨어에는 포함되지만 소스 코드 스캔 도구로는 검출되지 않습니다. 따라서 Dependency 분석을 위한 도구를 활용하는 것이 중요합니다.

(1) OSS Review Toolkit

OSS Review Toolkit (ORT)은 오픈소스 라이선스 컴플라이언스를 자동화하기 위한 도구 모음입니다. ORT는 Analyzer라는 Dependency 분석 도구를 제공합니다.

Analyzer의 주요 기능:

• 다양한 패키지 관리자 지원 (Maven, Gradle, NPM 등)
• 프로젝트의 종속성 트리 생성
• 라이선스 및 저작권 정보 추출
• SPDX 형식의 보고서 생성

(2) FOSSLight Dependency Scanner

LG전자에서 개발하고 오픈소스로 공개한 FOSSLight Dependency Scanner는 다양한 패키지 관리자를 지원하는 종속성 분석 도구입니다.

주요 기능:

• Gradle, Maven, NPM, PIP, Pub, Cocoapods 등 다양한 패키지 관리자 지원
• 오픈소스 라이선스 및 버전 정보 추출
• SBOM(Software Bill of Materials) 생성

(3) cdxgen

cdxgen은 OWASP CycloneDX 프로젝트의 일환으로 개발된 오픈소스 SBOM 생성 도구입니다. 다양한 언어와 패키지 관리자를 지원하며, CI/CD 파이프라인에 쉽게 통합할 수 있습니다.

주요 기능:

• Java, JavaScript, Python, Go, Rust 등 20여 개 언어 및 패키지 생태계 지원
• CycloneDX 및 SPDX 형식의 SBOM 생성
• 컨테이너 이미지 및 바이너리 분석 지원
• GitHub Actions, Jenkins 등 CI/CD 통합

cdxgen의 설치 및 사용 방법은 cdxgen 가이드를 참조하시기 바랍니다.

(4) Syft

Syft는 Anchore에서 개발한 오픈소스 SBOM 생성 도구로, 컨테이너 이미지와 파일시스템을 분석하여 SBOM을 생성합니다.

주요 기능:

• 컨테이너 이미지, 파일시스템, 아카이브 등 다양한 소스 분석
• SPDX, CycloneDX, Syft JSON 등 다양한 SBOM 형식 출력
• Grype(취약점 스캐너)와 연동하여 취약점 분석 가능
• Kubernetes, CI/CD 파이프라인 통합 지원

Syft의 설치 및 사용 방법은 Syft 가이드를 참조하시기 바랍니다.

이러한 Dependency 분석 도구를 활용하여 공급 소프트웨어에 포함된 오픈소스 컴포넌트를 정확히 식별하고, SBOM을 생성할 수 있습니다. 이는 ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 충족하는 데 도움이 됩니다.

3. 오픈소스 거버넌스 / SBOM 관리 도구

오픈소스 거버넌스와 SBOM(Software Bill of Materials) 관리는 효과적인 오픈소스 라이선스 컴플라이언스와 보안 보증을 위해 필수적입니다. ISO/IEC 5230과 ISO/IEC 18974 규격은 공급 소프트웨어에 포함된 오픈소스 소프트웨어 컴포넌트 기록을 문서화하여 보관할 것을 요구합니다.

SBOM은 스프레드시트 프로그램으로도 관리할 수 있지만, 공급 소프트웨어의 수와 버전이 많아질 경우 수동 관리는 어려워집니다. 따라서 자동화된 오픈소스 도구를 도입하는 것이 효율적입니다.

(1) SW360

SW360은 Eclipse 재단이 후원하는 오픈소스 프로젝트로, 공급 소프트웨어별 오픈소스 목록을 추적하는 기능을 제공합니다.

주요 기능:

• 프로젝트, 컴포넌트, 라이선스 관리
• SBOM 생성 및 관리
• 취약점 관리
• 라이선스 의무사항 추적

SW360의 설치 및 사용 방법은 SW360 가이드에서 확인할 수 있습니다.

(2) FOSSLight

FOSSLight는 LG전자가 개발하고 오픈소스로 공개한 종합적인 오픈소스 관리 도구입니다.

주요 기능:

• SBOM 생성 및 관리
• 오픈소스 라이선스 컴플라이언스 검사
• 취약점 관리
• 오픈소스 고지문 생성

LG전자는 FOSSLight를 수년간 사용하여 전사적으로 SBOM을 관리해왔으며, 2021년 6월에 이를 오픈소스로 공개했습니다. 한국어 가이드를 제공하여 국내 기업들의 사용을 돕고 있습니다.

FOSSLight의 설치 및 사용 방법은 FOSSLight 가이드를 참조하시기 바랍니다.

(3) Dependency-Track

Dependency-Track은 OWASP에서 관리하는 오픈소스 SBOM 관리 및 취약점 분석 플랫폼입니다. SBOM을 수집·관리하고, 각 컴포넌트의 취약점을 지속적으로 모니터링합니다.

주요 기능:

• CycloneDX 및 SPDX 형식의 SBOM 수집 및 관리
• NVD, OSV 등 취약점 데이터베이스와 연동한 자동 취약점 탐지
• 프로젝트별 컴포넌트 및 라이선스 현황 대시보드
• REST API 및 CI/CD 파이프라인 통합

Dependency-Track의 설치 및 사용 방법은 Dependency-Track 가이드를 참조하시기 바랍니다.

이러한 도구들을 활용하여 기업은 효과적으로 오픈소스 거버넌스를 수행하고 SBOM을 관리할 수 있으며, ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 충족할 수 있습니다.

4. 오픈소스 보안취약점 관리 도구

공급 소프트웨어에 포함된 알려진 취약점 또는 새로 발견된 취약점을 효과적으로 관리하기 위해 기업은 자동화된 도구 환경을 구축해야 합니다. 여기서는 세 가지 주요 오픈소스 보안취약점 관리 도구를 소개합니다.

(1) OWASP Dependency-Check

OWASP Dependency-Check는 프로젝트의 종속성을 분석하여 알려진 취약점이 있는지 검출하는 오픈소스 도구입니다.

주요 기능:

• 다양한 언어 및 패키지 관리자 지원 (Java, .NET, JavaScript, Ruby 등)
• CVE(Common Vulnerabilities and Exposures) 데이터베이스와 연동
• CI/CD 파이프라인과의 쉬운 통합
• HTML, XML, CSV, JSON 등 다양한 형식의 보고서 생성

(2) SW360

SW360은 Eclipse 재단에서 관리하는 오픈소스 소프트웨어 컴포넌트 관리 도구로, 보안 취약점 관리 기능도 제공합니다.

주요 기능:

• 등록된 Release에 대한 자동 취약점 확인
• CVE 정보 주기적 수집 (24시간마다 스케줄링)
• 프로젝트별 보안 취약점 조회
• 새로 공개된 취약점의 기존 제품 영향 추적

SW360으로 보안취약점을 관리하는 방법은 SW360 가이드를 참고할 수 있습니다.

(3) FOSSLight

FOSSLight도 이와 유사하게 보안취약점 정보를 자동으로 취득하고, 보안취약점이 검출된 프로젝트 정보를 자동으로 확인하여 필요 시 메일 등 알림을 제공합니다.

(4) OSV-SCALIBR

OSV-SCALIBR은 Google에서 개발한 오픈소스 소프트웨어 컴포지션 분석(SCA) 라이브러리로, 파일시스템과 컨테이너 이미지에서 오픈소스 컴포넌트를 추출하고 OSV(Open Source Vulnerabilities) 데이터베이스와 연동하여 취약점을 탐지합니다.

주요 기능:

• 파일시스템, 컨테이너 이미지, 아카이브에서 패키지 추출
• OSV 데이터베이스 기반 취약점 탐지
• Python, Go, Java, npm 등 주요 패키지 생태계 지원
• 라이브러리 형태로 기존 도구에 통합 가능

OSV-SCALIBR의 설치 및 사용 방법은 OSV-SCALIBR 가이드를 참조하시기 바랍니다.

이러한 도구들을 활용하여 기업은 ISO/IEC 18974의 요구사항을 충족하면서 효과적으로 오픈소스 보안 취약점을 관리할 수 있습니다.

5. 오픈소스 컴플라이언스 산출물 생성 도구

주요 오픈소스 컴플라이언스 산출물인 오픈소스 고지문은 공급 소프트웨어에 포함된 오픈소스의 저작권과 라이선스 정보를 제공하기 위한 문서입니다. 오픈소스 고지문은 수동으로 작성할 수도 있지만, 자동으로 생성하는 도구를 활용하는 것이 효율적입니다.

(1) onot

SK텔레콤은 사내에서 사용하는 오픈소스 고지문 자동 생성 도구를 onot이라는 이름으로 오픈소스로 공개하였습니다. 카카오에서도 주요 기능을 기여하는 방식으로 공동 개발에 참여하였습니다.

onot은 SPDX 문서 형식으로 작성된 SBOM을 자동으로 오픈소스 고지문 형식으로 변환하는 도구입니다. Python 프로그램으로 가볍고 간단하게 사용할 수 있습니다.

(2) FOSSLight

FOSSLight도 취득한 SBOM을 기반으로 오픈소스 고지문을 자동으로 생성하는 기능을 제공합니다.

이러한 도구들을 활용하면 오픈소스 고지문 생성 과정을 자동화하고 표준화할 수 있어, 오픈소스 라이선스 컴플라이언스 프로세스의 효율성과 정확성을 높일 수 있습니다. 또한 ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 충족하는 데 도움이 됩니다.

6. 오픈소스 컴플라이언스 산출물 보관

오픈소스 컴플라이언스 산출물을 체계적으로 보관하고 관리하는 것은 오픈소스 라이선스 컴플라이언스를 위해 매우 중요합니다. 특히 GPL, LGPL 등 소스 코드 공개를 요구하는 라이선스의 경우, 공급 소프트웨어 배포 후 최소 3년간 소스 코드를 제공할 수 있어야 합니다.

이를 위해 ISO/IEC 5230 표준은 다음과 같이 배포용 소프트웨어의 컴플라이언스 산출물 사본을 보관하기 위한 문서화된 절차를 요구합니다.

이를 위해 기업은 오픈소스 컴플라이언스 산출물을 안전하게 보관하고 필요시 외부에 공개할 수 있는 시스템을 구축해야 합니다.

(1) GitHub Pages

GitHub Pages는 GitHub 저장소에서 직접 웹사이트를 호스팅할 수 있는 서비스입니다. 이를 활용하여 오픈소스 컴플라이언스 산출물을 보관하고 공개할 수 있습니다.

GitHub Pages를 사용하여 오픈소스 컴플라이언스 산출물을 보관하는 방법은 다음과 같습니다:

1. GitHub에 전용 저장소 생성
2. 저장소에 오픈소스 고지문 및 소스 코드 업로드
3. GitHub Pages 설정을 통해 웹사이트 활성화
4. 공개 URL을 통해 외부에서 접근 가능하도록 설정

GitHub Pages를 사용하면 다음과 같은 이점이 있습니다:

• 무료로 사용 가능
• 버전 관리 기능 제공
• 높은 가용성 및 안정성
• 쉬운 업데이트 및 관리

이러한 도구 환경은 SK텔레콤의 오픈소스 웹사이트에서 참고하실 수 있습니다.

이 웹사이트는 오픈소스로 개발하였고, 소스 코드를 공개하고 있어서 다른 기업들도 쉽게 유사한 환경을 구축할 수 있습니다.

GitHub Pages를 활용하여 오픈소스 컴플라이언스 산출물을 보관하고 공개함으로써, 기업은 오픈소스 라이선스 의무를 효과적으로 이행하고 투명성을 제고할 수 있습니다.

7. 지속적 통합/배포(CI/CD) 도구와의 연동

오픈소스 컴플라이언스 및 보안 보증 활동을 지속적 통합/배포(CI/CD) 파이프라인에 통합하면 개발 프로세스 전반에 걸쳐 자동화된 검사와 관리가 가능해집니다. 이를 통해 오픈소스 관련 이슈를 조기에 발견하고 해결할 수 있습니다.

(1) Jenkins 플러그인

Jenkins는 널리 사용되는 오픈소스 자동화 서버로, 다양한 플러그인을 통해 오픈소스 컴플라이언스 및 보안 보증 도구들과 연동할 수 있습니다.

주요 Jenkins 플러그인:

• FOSSology Plugin: FOSSology 스캔을 Jenkins 파이프라인에 통합합니다.
• OWASP Dependency-Check Plugin: 알려진 취약점 또는 새로 발견된 취약점 검사를 자동화합니다.
• SW360 Plugin: SW360와 Jenkins를 연동하여 SBOM 관리를 자동화합니다.

Jenkins 파이프라인 예시:

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        stage('Dependency Scan') {
            steps {
                dependencyCheck additionalArguments: '', odcInstallation: 'Default'
            }
        }
        stage('License Scan') {
            steps {
                fossology()
            }
        }
        stage('SBOM Update') {
            steps {
                sw360UpdateProject()
            }
        }
    }
    post {
        always {
            dependencyCheckPublisher pattern: '**/dependency-check-report.xml'
        }
    }
}

이 파이프라인은 소스 코드 체크아웃, 의존성 취약점 검사, 라이선스 스캔, SBOM 업데이트를 순차적으로 수행합니다.

(2) GitLab CI/CD 파이프라인

GitLab CI/CD는 GitLab에 내장된 지속적 통합/배포 도구로, .gitlab-ci.yml 파일을 통해 파이프라인을 정의합니다.

GitLab CI/CD 파이프라인 예시:

stages:
  - scan
  - analyze
  - report

dependency_scan:
  stage: scan
  script:
    - docker run --rm -v $(pwd):/src owasp/dependency-check --scan /src --format "ALL" --out /src/reports

license_scan:
  stage: scan
  script:
    - docker run --rm -v $(pwd):/project fossology/fossology:latest /usr/local/fossology/fo_cli -c /project

sbom_update:
  stage: analyze
  script:
    - sw360 update-project

vulnerability_report:
  stage: report
  script:
    - generate_vulnerability_report
  artifacts:
    reports:
      dependency_scanning: reports/dependency-check-report.json

license_report:
  stage: report
  script:
    - generate_license_report
  artifacts:
    reports:
      license_scanning: reports/license-scan-report.json

이 파이프라인은 의존성 취약점 검사, 라이선스 스캔, SBOM 업데이트, 취약점 보고서 및 라이선스 보고서 생성을 수행합니다.

CI/CD 파이프라인에 이러한 프로세스를 통합함으로써, 오픈소스 컴플라이언스 및 보안 보증 활동을 자동화하고 개발 워크플로우에 원활하게 통합할 수 있습니다. 이는 ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 효과적으로 충족하는 데 도움이 됩니다.

8. Summary

여기까지 도구 환경을 구축하게 되면 ISO/IEC 5230과 ISO/IEC 18974 표준 규격의 주요 요구사항을 충족할 수 있습니다.

이러한 도구들을 활용함으로써 다음과 같은 이점을 얻을 수 있습니다:

1. 소스 코드 스캔 및 Dependency 분석 도구를 통해 공급 소프트웨어에 포함된 오픈소스를 정확히 식별하고 라이선스를 파악할 수 있습니다.

2. 오픈소스 거버넌스 및 SBOM 관리 도구를 사용하여 공급 소프트웨어의 오픈소스 컴포넌트를 체계적으로 관리하고 추적할 수 있습니다.

3. 오픈소스 보안취약점 관리 도구를 통해 알려진 취약점 또는 새로 발견된 취약점을 지속적으로 모니터링하고 대응할 수 있습니다.

4. 오픈소스 컴플라이언스 산출물 생성 및 보관 도구를 활용하여 라이선스 의무사항을 준수하는 데 필요한 문서를 효율적으로 생성하고 관리할 수 있습니다.

5. CI/CD 도구와의 연동을 통해 오픈소스 관리 프로세스를 개발 워크플로우에 통합하여 자동화할 수 있습니다.

이러한 도구 환경 구축을 통해 기업은 오픈소스 라이선스 컴플라이언스와 보안 보증 활동을 체계적이고 효율적으로 수행할 수 있으며, ISO/IEC 5230과 ISO/IEC 18974의 요구사항을 충족하는 데 큰 도움을 받을 수 있습니다.

오픈소스 관리 도구를 효과적으로 활용함으로써, 기업은 오픈소스 사용에 따른 법적 위험을 최소화하고, 보안 취약점에 신속하게 대응하며, 투명하고 신뢰할 수 있는 소프트웨어 공급망을 구축할 수 있습니다. 이는 궁극적으로 기업의 경쟁력 향상과 고객 신뢰 증진으로 이어질 것입니다.

ISO/IEC 5230 / 18974 준수 가이드 — 이 섹션과 관련된 조항:

• §3.4.1 컴플라이언스 산출물 — 산출물 보관 기간·버전 관리 절차
• §4.1.5 표준 관행 구현 — SCA·SAST·DAST 도구 활용 방법
• §4.3.2 보안 보증 — SBOM 기반 취약점 탐지 및 기록

1.6 - 5. 교육

1. 교육

아무리 훌륭한 정책과 프로세스를 구축하였다고 해도 기업의 구성원이 아무도 신경쓰지 않는다면 무용지물일 것입니다. 오픈소스 정책과 오픈소스 프로세스가 기업에서 효과적으로 동작하기 위해서는 구성원 교육이 중요합니다.

기업은 모든 프로그램 참여자가 조직 내에 오픈소스 정책이 있다는 것을 인식하고 필요한 활동을 할 수 있도록 교육, 내부 위키 등 실질적인 수단을 제공해야 합니다. 여기서 프로그램 참여자란 기업이 소프트웨어를 개발하고 배포, 기여하는 데 관여하는 모든 직원을 의미하며, 소프트웨어 개발자, 배포 엔지니어, 품질 엔지니어 등을 포함합니다.

이를 위해 ISO 표준은 공통적으로 다음과 같이 오픈소스 정책을 알리기 위한 문서화된 절차를 요구합니다.

많은 기업은 오픈소스 정책 문서를 사내 위키 사이트를 통해 공개하여 직원 누구나 필요한 사항을 확인할 수 있게 합니다. 또한, 신규 채용 인원의 입사 연수 시 오픈소스 정책에 대한 교육을 의무화하고, 프로그램 참여자를 대상으로 매년 혹은 2년에 한 번씩 주기적인 교육을 제공함으로써 모든 프로그램 참여자가 오픈소스 정책의 존재를 인식하게 합니다.

기업은 이러한 방법들을 다음의 예와 같이 작성하여 오픈소스 정책 문서에 포함해야 합니다.

5. 교육 및 평가

4장에서 정의한 각 역할을 담당하는 모든 구성원은 [Learning Portal]에서 제공하는 오픈소스 교육 고급 과정을 수강해야 합니다. 이를 통해 오픈소스 정책, 관련 교육 정책 및 조회 방법을 숙지합니다. 교육 이력과 평가 결과는 [Learning Portal]에 최소 3년간 보존합니다.

기업은 프로그램 참여자가 기업의 오픈소스 정책, 오픈소스 관련 목표, 효과적인 오픈소스 프로그램이 되기 위한 참여자의 기여 방법, 그리고 프로그램 요구사항을 준수하지 않을 경우 미치는 영향에 대해 인식하도록 해야 합니다. 이를 위해 기업은 교육을 제공하고, 프로그램 참여자가 올바르게 인식하였는지 확인하기 위해 평가를 수행하고 평가 결과를 문서화하여 보관해야 합니다.

ISO 표준은 공통적으로 다음과 같이 프로그램 참여자의 인식을 평가하였음을 나타내는 문서화된 증거를 요구합니다.

따라서 기업은 아래의 예와 같은 내용을 기업의 오픈소스 정책에 포함할 수 있다.

1. 목적

(1) 정책의 목적 

이 정책은 OOO 주식회사(이하 "회사"라 함)에서 소프트웨어 개발, 서비스, 배포에 관여하는 전체 조직이 올바르게 오픈소스 소프트웨어(이하 "오픈소스"라 함)를 활용하기 위해 다음과 같은 원칙을 제공합니다.

1. 오픈소스 컴플라이언스 / 보안 보증 원칙
2. 외부 오픈소스 프로젝트로의 기여 원칙
3. 사내 프로젝트를 오픈소스로 공개하기 위한 원칙

이러한 원칙은 회사의 모든 구성원이 오픈소스의 가치를 이해하고, 오픈소스를 올바르게 사용하며, 오픈소스 커뮤니티에 기여하기 위한 방법을 제공합니다.

회사의 모든 구성원은 사내 위키의 다음 링크에서 오픈소스 정책을 확인할 수 있습니다 : [internal_link]

(2) 미준수 시 영향
이 정책을 준수하지 않는다면 다음과 같은 상황이 발생할 수 있습니다.

- 외부로부터 오픈소스 라이선스 준수 요구를 받을 수 있습니다.
- 회사가 개발한 소스 코드를 원치 않게 공개해야 할 수 있습니다.
- 오픈소스 저작권자로부터 법적 소송을 제기당할 수 있습니다.
- 저작권 침해 및 계약 위반으로 벌금을 부과받거나, 제품 판매 중지 명령을 받을 수 있습니다.
- 회사 평판이 손상될 수 있습니다.
- 공급업체와의 계약 위반이 되어 손해배상 청구를 받을 수 있습니다.
- 심각한 보안 사고에 노출되어 회사에 막대한 손해를 입힐 수 있습니다.

이러한 이유로 회사는 오픈소스 정책의 위반을 심각하게 간주하며, 이를 위반하는 구성원이나 조직은 징계 절차에 처할 수 있습니다.

(3) 구성원의 기여 방법

회사의 모든 구성원은 이 정책의 근거와 내용을 이해하고 필요한 활동을 충실히 수행함으로써 정책의 효과 및 회사의 컴플라이언스 수준 향상에 기여할 수 있습니다.

평가에 대해서는 아래에서 한번 더 자세히 설명합니다.

오픈소스 교육에는 오픈소스 기여 정책에 대한 내용도 포함됩니다. 오픈소스 기여 정책을 만들었다 해도 사내 구성원이 이에 대한 존재를 알지 못한다면 무분별한 기여 활동으로 개인과 회사에 피해가 발생할 우려가 있습니다.

이를 위해 ISO/IEC 5230 표준은 다음과 같이 모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식하도록 하는 문서화된 절차를 요구합니다.

따라서 기업은 모든 사내 개발자가 오픈소스 기여 정책의 존재를 알 수 있도록 오픈소스 교육을 제공해야 합니다.

교육자료를 새롭게 제작하는 것도 처음 업무를 시작하는 담당자에게는 쉽지 않은 일일 수 있습니다. 이러한 어려움을 돕고자 엔씨소프트는 사내 오픈소스 교육자료를 누구나 사용할 수 있도록 교안(PPT)와 강의 스크립트를 GitHub에 공개했습니다.

또한, 국내 대표 플랫폼 기업인 카카오도 사내 개발자를 위한 오픈소스 교육자료를 누구나 열람할 수 있도록 공개했습니다.

아직 교육 자료를 만들지 않았다면, 이런 오픈소스 관리 우수 기업들의 오픈소스 교육 자료를 활용하는 것도 좋은 방법입니다.

2. 평가

기업은 각 역할에 대한 담당자를 지정하였으면, 지정된 담당자가 교육, 훈련 및 경험을 바탕으로 맡은 역할을 수행할 수 있는 자격을 갖추었음을 확인해야 합니다. 역량이 미흡한 프로그램 참여자에게는 충분한 역량을 갖출 수 있도록 교육도 제공해야 합니다. 그리고 기업은 각 참여자가 역량을 갖추고 있는지 평가하고 결과를 보관해야 합니다.

이를 위해 ISO 표준은 공통적으로 다음과 같이 프로그램 참여자의 역량을 평가한 문서화된 증거를 요구합니다.

따라서, 기업은 아래와 같이 교육과 평가를 수행하고 결과를 유지해야 합니다.

1. 기업은 각 참여자가 필요한 역량을 보유할 수 있도록 교육을 제공합니다.
2. 교육 내용을 기반으로 평가를 수행합니다.
3. 평가 결과는 기업의 교육 시스템 혹은 HR 부서에서 보관합니다.

프로그램 참여자가 수백 명 이상이어서 교육 제공이 쉽지 않을 경우, 기업의 온라인 교육과 평가 시스템을 이용하는 것도 좋은 방법입니다.

이와 같은 내용은 기업의 오픈소스 정책에 다음과 같이 포함할 수 있습니다.

4. 역할, 책임 및 역량

정책의 효과를 보장하기 위해 다음과 같이 역할과 책임 및 각 역할의 담당자가 갖추어야 할 역량을 정의합니다.

각 역할의 담당 조직/담당자와 필요 역량 수준은 [부록 1. 담당자 현황]에서 정의합니다.


5. 교육 및 평가

4장에서 정의한 각 역할을 담당하는 모든 구성원은 [Learning Portal]에서 제공하는 오픈소스 교육 고급 과정을 수강해야 합니다. 이를 통해 오픈소스 정책, 관련 교육 정책 및 조회 방법을 숙지합니다. 

교육 이력과 평가 결과는 [Learning Portal]에 최소 3년간 보존합니다.

3. 오픈소스 라이선스 가이드

오픈소스 라이선스를 제대로 준수하기 위해서는 오픈소스 라이선스별로 요구하는 사항에 대해 정확히 알고 있어야 합니다. 하지만 개별 소프트웨어 개발자가 이를 일일이 파악하는 것은 어려우므로, 오픈소스 프로그램 매니저는 자주 사용되는 오픈소스 라이선스에 대해 일반적인 사용 사례별 요구사항/주의사항을 정리하여 회사 내부에 공유하는 것이 좋습니다.

오픈소스 라이선스 가이드에는 일반적인 오픈소스 라이선스 사용 사례별 요건을 포함하여 개발 부서에서 오픈소스를 사용하면서 올바른 라이선스 의무 준수 활동을 할 수 있게 해야 합니다.

이를 위해 ISO/IEC 5230 표준은 다음과 같이 배포용 소프트웨어 내의 오픈소스 컴포넌트에 대해 일반적인 오픈소스 라이선스 사용 사례를 처리하기 위한 문서화된 절차를 요구합니다.

오픈소스 라이선스 사용 사례를 처리하기 위해서는 오픈소스 라이선스별로 분류된 라이선스 가이드가 필요합니다. 오픈소스 라이선스에 대한 일반적인 가이드와 라이선스 의무 요약 자료는 한국저작권위원회에서 제공하는 라이선스 가이드를 참고할 수 있습니다.

SK텔레콤의 오픈소스 가이드 내 라이선스별 의무사항항 문서도 좋은 자료입니다.

https://sktelecom.github.io/guide/use/obligation/gpl-2.0/

기업은 구성원이 쉽게 접근하여 참고할 수 있는 공간에 오픈소스 라이선스 가이드를 제공해야 합니다.

4. 인식 제고 활동

프로그램 참여자의 오픈소스 라이선스 컴플라이언스 및 보안 보증에 대한 인식을 지속적으로 제고하기 위해 다음과 같은 활동을 수행합니다:

(1) 정기적인 뉴스레터 발행

• 오픈소스 프로그램 매니저는 월 1회 오픈소스 관련 뉴스레터를 발행합니다.
• 뉴스레터에는 최신 오픈소스 동향, 라이선스 컴플라이언스 사례, 보안 취약점 정보 등을 포함합니다.
• 모든 프로그램 참여자에게 이메일로 배포하고, 사내 인트라넷에도 게시합니다.

(2) 워크샵 및 세미나 개최

• 분기별로 오픈소스 관련 워크샵 또는 세미나를 개최합니다.
• 외부 전문가를 초청하여 오픈소스 라이선스, 보안, 최신 기술 동향 등에 대한 강연을 진행합니다.
• 프로그램 참여자들의 참여를 독려하고, 참석 기록을 유지합니다.

(3) 오픈소스 기여 장려 프로그램

• 프로그램 참여자의 외부 오픈소스 프로젝트 기여를 장려하는 프로그램을 운영합니다.
• 기여 활동에 대한 인센티브 제도를 마련하고, 우수 기여자를 분기별로 선정하여 포상합니다.
• 기여 활동 내용을 사내에 공유하고, 성과 평가에 반영합니다.

5. 교육 효과성 측정 및 개선

오픈소스 교육 프로그램의 효과성을 지속적으로 측정하고 개선하기 위해 다음과 같은 활동을 수행합니다:

(1) 교육 프로그램 평가 지표

• 다음과 같은 정량적, 정성적 지표를 설정하여 교육 프로그램을 평가합니다:
  • 교육 이수율
  • 평가 시험 점수
  • 라이선스 컴플라이언스 위반 건수 감소율
  • 보안 취약점 대응 시간 단축률
  • 프로그램 참여자 만족도 점수

(2) 피드백 수집 및 분석

• 모든 교육 프로그램 종료 후 참가자들로부터 피드백을 수집합니다.
• 온라인 설문 조사를 통해 교육 내용, 강사, 교육 방법 등에 대한 의견을 수집합니다.
• 수집된 피드백을 분석하여 개선 포인트를 도출합니다.

(3) 지속적인 개선 계획 수립

• 평가 지표 결과와 피드백 분석을 바탕으로 반기별로 교육 프로그램 개선 계획을 수립합니다.
• 오픈소스 프로그램 매니저는 개선 계획을 OSRB에 보고하고 승인을 받습니다.
• 승인된 개선 사항을 다음 교육 프로그램에 반영하고, 그 효과를 모니터링합니다.

이러한 활동을 통해 프로그램 참여자의 오픈소스에 대한 인식을 제고하고, 교육 프로그램의 효과성을 지속적으로 향상시킬 수 있습니다.

6. Summary

여기까지 교육, 평가, 인식 제고 활동 및 교육 효과성 측정과 개선 프로세스를 구축하게 되면 ISO/IEC 5230과 ISO/IEC 18974 표준 규격의 주요 요구사항을 충족할 수 있습니다.

이러한 교육 및 평가 체계를 통해 기업은 프로그램 참여자들의 오픈소스 라이선스 컴플라이언스와 보안 보증에 대한 이해도를 높이고, 역량을 지속적으로 개선할 수 있습니다. 또한, 정기적인 평가와 개선 활동을 통해 프로그램의 효과성을 지속적으로 향상시킬 수 있습니다.

이는 궁극적으로 기업의 오픈소스 관리 수준을 높이고, 오픈소스 사용에 따른 법적 위험을 최소화하며, 보안 취약점에 대한 대응 능력을 강화하는 데 기여할 것입니다.

ISO/IEC 5230 / 18974 준수 가이드 — 이 섹션과 관련된 조항:

• §3.1.3 인식 — 프로그램 참여자 인식 제고 절차
• §3.1.4 프로그램 범위 — 교육 대상 범위 정의
• §3.5.1 기여 — 기여 정책 인식 절차(3.5.1.3)

1.7 - 6. 준수 선언

ISO/IEC 5230과 ISO/IEC 18974의 모든 요구사항을 준수하는 오픈소스 프로그램(오픈소스 정책 / 프로세스 / 도구 / 조직)을 구축한 기업은 다음 두 가지를 문서화하여 명시해야 합니다.

(1) 표준 요구사항 충족 확인

ISO/IEC 5230과 ISO/IEC 18974는 다음과 같이 프로그램이 모든 요구사항을 충족함을 확인하는 문서를 요구합니다:

이를 위해 기업은 다음과 같은 내용을 포함하는 문서를 작성해야 합니다:

[회사명]의 오픈소스 프로그램은 ISO/IEC 5230:2020(오픈소스 라이선스 컴플라이언스)과 ISO/IEC 18974(오픈소스 보안 보증)의 모든 요구사항을 충족합니다. 

이는 다음의 문서와 프로세스를 통해 확인할 수 있습니다:
1. 오픈소스 정책 문서
2. 오픈소스 프로세스 문서
3. 오픈소스 교육 및 평가 기록
4. SBOM(Software Bill of Materials) 관리 시스템
5. 오픈소스 라이선스 컴플라이언스 산출물 생성 및 보관 시스템
6. 오픈소스 보안 취약점 관리 시스템
7. 외부 문의 대응 프로세스 기록

[날짜]
[오픈소스 프로그램 매니저 서명]

(2) 지속적 준수 보장 선언

ISO/IEC 5230과 ISO/IEC 18974는 또한 적합성 인증 획득 후 18개월 동안 모든 요구사항을 충족하고 있음을 확인하는 문서를 요구합니다:

이를 위해 기업은 다음과 같은 내용을 포함하는 문서를 작성하고 주기적으로 갱신해야 합니다:

[회사명]은 ISO/IEC 5230:2020(오픈소스 라이선스 컴플라이언스)과 ISO/IEC 18974(오픈소스 보안 보증)의 적합성 인증을 획득한 후 18개월 이상 모든 요구사항을 충족하는 상태를 유지할 것을 보장합니다.

이를 위해 다음과 같은 활동을 수행합니다:
1. 최소 6개월마다 내부 감사를 실시하여 모든 요구사항 충족 여부를 확인
2. 연 1회 이상 외부 전문가의 검토를 받아 프로그램의 효과성 평가
3. 프로그램 참여자에 대한 지속적인 교육 및 역량 평가 실시
4. 오픈소스 정책 및 프로세스의 정기적인 검토 및 업데이트
5. 새로운 기술 동향 및 법적 요구사항 변화에 대한 모니터링 및 대응

[날짜]
[오픈소스 프로그램 매니저 서명]

기업은 이러한 문서를 오픈소스 정책에 포함시키거나, 외부에 공개된 웹사이트를 통해 게재할 수 있습니다. 예를 들어, SK텔레콤은 자사의 오픈소스 포털 사이트에 이러한 내용을 게재하고 있습니다: https://sktelecom.github.io/compliance/iso5230/ 이러한 문서화를 통해 기업은 ISO/IEC 5230과 ISO/IEC 18974의 모든 요구사항을 충족하게 되며, 오픈소스 라이선스 컴플라이언스와 보안 보증에 대한 지속적인 관리와 개선을 보장할 수 있습니다.

ISO/IEC 5230 / 18974 준수 가이드 — 이 섹션과 관련된 조항:

• §3.6.1 준수 선언 — 표준 요구사항 충족 확인 문서
• §3.6.2 지속적 준수 — 18개월 준수 유지 선언
• §4.1.4 프로그램 범위(18974) — 성과 메트릭 및 지속적 개선 증거

2 - ISO/IEC 5230 준수 가이드

이 가이드는 ISO/IEC 5230(OpenChain License Compliance)의 각 요구사항 조항을 하나씩 풀어서 설명한다. 각 조항이 요구하는 입증자료가 무엇인지, 어떻게 준수할 수 있는지, 바로 활용할 수 있는 샘플 문서는 무엇인지 안내한다.

Author : OpenChain Korea Work Group / CC BY 4.0

대상 독자

• 오픈소스 컴플라이언스 담당자 및 오픈소스 프로그램 매니저
• ISO/IEC 5230 인증 취득을 준비 중인 기업의 담당자
• 기존 오픈소스 관리 체계를 ISO 표준 기준으로 점검하고 싶은 실무자

이 가이드의 활용 방법

전체 조항 체크리스트

ISO/IEC 5230은 총 13개 조항, 24개 입증자료 항목으로 구성된다.

§3.1 프로그램 기반

§3.2 관련 업무

§3.3 콘텐츠 검토 및 승인

§3.4 컴플라이언스 산출물

§3.5 커뮤니티 참여

§3.6 규격 준수

합계: 13개 조항 / 24개 입증자료 항목

ISO/IEC 5230 인증 절차

ISO/IEC 5230 준수 여부를 공식적으로 인정받는 방법은 세 가지다.

2.1 - §3.1 프로그램 기반

2.1.1 - §3.1.1 정책

1. 조항 개요

오픈소스 정책이 없는 기업은 개발자가 오픈소스 라이선스 의무를 인지하지 못한 채 소프트웨어를 배포하게 되며, 이는 저작권 침해 소송, 소스코드 강제 공개, 거래처 계약 해지 등 심각한 법적·사업적 위험으로 이어질 수 있다. §3.1.1은 이러한 위험을 예방하기 위해 오픈소스 라이선스 컴플라이언스를 관리하는 문서화된 정책을 수립하고, 조직 내 모든 프로그램 참여자가 정책의 존재를 인식할 수 있도록 전파할 것을 요구한다. 이 조항은 ISO/IEC 5230 프로그램 전체의 기반이 되며, 이후 모든 조항(역량·프로세스·산출물 등)은 이 정책 위에서 작동한다.

2. 해야 할 활동

• 오픈소스 라이선스 컴플라이언스를 관리하는 정책 문서를 작성하고 공식화한다.
• 정책에 적용 범위(외부 배포 소프트웨어, 기여 활동, 사내 공개 등)를 명확히 정의한다.
• 정책 내에 오픈소스 사용·기여·배포·SBOM 관리·보안 취약점 대응 원칙을 포함한다.
• 프로그램 참여자(개발자·법무·IT·보안 등)에게 정책을 전파하는 절차를 수립하고 문서화한다.
• 전파 사실을 증명할 수 있는 기록(교육 이수, 공지 이력 등)을 보관한다.
• 정기적으로 정책을 검토하고 변경 시 재전파하는 절차를 정책 내에 포함한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.1.1.1 문서화된 오픈소스 정책

준수 방법

오픈소스 정책은 기업이 오픈소스 소프트웨어를 안전하고 효과적으로 활용하기 위한 원칙과 절차를 담은 공식 문서다. 정책 문서에는 목적, 적용 범위, 역할과 책임, 오픈소스 사용·기여·배포 원칙, SBOM 관리, 보안 취약점 대응, 교육 및 검토 주기 등 핵심 항목이 포함되어야 한다. 이 문서 자체가 입증자료 3.1.1.1에 해당하므로 반드시 공식 문서로 관리해야 하며, 버전과 승인 이력을 기록해야 한다.

정책 수립 시에는 회사의 비즈니스 환경과 소프트웨어 공급망 특성을 반영해야 한다. 예를 들어 외부에 소프트웨어를 배포하는 제품 기업과 서비스 기업은 컴플라이언스 산출물 생성 의무 범위가 다를 수 있으므로, 적용 범위를 명확하게 정의한다. 정책은 법무팀 또는 OSRB(Open Source Review Board)의 검토를 거쳐 최고 경영진 또는 권한 있는 부서장이 승인하는 절차를 거쳐야 한다.

정책은 한 번 수립한 뒤 방치하는 문서가 아니다. ISO/IEC 5230 요구사항 변경, 새로운 라이선스 유형의 등장, 법적 환경 변화 등을 반영하여 최소 연 1회 정기 검토를 실시하고, 변경 이력을 문서에 기록해야 한다.

고려사항

• 포함 항목: 오픈소스 사용, 외부 기여, 사내 프로젝트 공개, SBOM 관리, 보안 취약점 대응 원칙을 정책에 모두 포함한다.
• 적용 범위 명시: 외부 배포 소프트웨어, 내부 사용 소프트웨어, 기여 활동 등 정책이 적용되는 범위를 명확하게 구분한다.
• 승인 절차: OSRB 또는 법무팀장 이상이 최종 승인하고, 승인 날짜와 승인자를 문서에 기록한다.
• 버전 관리: 문서 버전 번호와 변경 이력을 유지하여 감사 시 이전 버전과 비교할 수 있도록 한다.
• 정기 검토: 연 1회 이상 정책을 검토하며, 검토 완료 날짜와 검토자를 기록한다.

샘플

아래는 오픈소스 정책 문서의 목적 및 적용 범위 샘플이다. 이 텍스트 자체가 입증자료 3.1.1.1(문서화된 오픈소스 정책)의 핵심 구성 요소가 된다.

## 1. 목적 및 적용 범위

### 1.1 목적

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

1. 오픈소스 라이선스 컴플라이언스:
   공급 소프트웨어에 포함된 오픈소스 컴포넌트의 라이선스 의무를 준수하고,
   관련 법적 요구사항을 충족합니다.
2. 오픈소스 보안 보증:
   공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을 식별하고,
   적절한 대응 조치를 통해 보안 위험을 최소화합니다.

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

### 1.4 적용 범위

이 정책은 회사가 개발, 배포, 또는 사용하는 모든 소프트웨어 프로젝트에 적용됩니다.

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

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

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

3.1.1.2 정책 인식 방법 문서화

준수 방법

정책 문서를 작성하는 것만으로는 부족하다. 프로그램 참여자(소프트웨어 개발·배포·기여에 관여하는 모든 직원)가 정책의 존재를 실제로 인식할 수 있도록 전파 절차를 수립하고 문서화해야 한다. 전파 절차 문서에는 어떤 채널을 통해, 언제, 누구에게 정책을 전달하는지 구체적으로 명시해야 한다. 이 전파 절차 문서 자체가 입증자료 3.1.1.2다.

전파 방법은 복수의 채널을 조합하는 것이 효과적이다. 신규 입사자에게는 온보딩 과정에 오픈소스 정책 안내를 포함하고, 기존 직원에게는 사내 위키 게시와 이메일 공지를 활용한다. 정책 변경 시에는 변경 내용을 즉시 공지하는 절차도 포함해야 한다. 전파 사실을 증명하기 위해 공지 발송 이력, 교육 이수 기록, 정책 인식 확인 서명 등의 증거를 최소 3년간 보관한다.

고려사항

• 복수 채널 활용: 사내 위키, 이메일 공지, 온보딩 교육 등 둘 이상의 채널을 활용하여 전파 효과를 높인다.
• 신규 입사자: 온보딩 프로세스에 오픈소스 정책 안내를 필수 항목으로 포함한다.
• 정책 변경 시: 변경 사항을 프로그램 참여자에게 즉시 공지하는 별도 절차를 수립한다.
• 증거 보관: 공지 이력, 교육 이수 확인서, 정책 인식 확인 서명을 최소 3년간 보관한다.
• 접근성: 정책 문서를 사내 포털이나 위키에 항시 게시하여 참여자가 언제든 확인할 수 있도록 한다.

샘플

아래는 정책 전파 공지 이메일 샘플이다. 전송 이력을 보관하면 입증자료 3.1.1.2의 증거로 활용할 수 있다.

제목: [오픈소스] 오픈소스 정책 안내 및 숙지 요청

수신: 전체 개발/배포 관련 임직원
발신: 오픈소스 프로그램 매니저

안녕하세요.

당사의 오픈소스 정책이 제정(또는 개정)되었습니다.
오픈소스 소프트웨어를 사용, 기여, 또는 배포하는 업무에 관여하는
모든 임직원은 아래 링크의 정책 문서를 확인하고 숙지해 주시기 바랍니다.

- 정책 문서: [사내 포털 링크]
- 주요 내용: 오픈소스 사용 원칙, 라이선스 컴플라이언스 절차,
             SBOM 관리, 보안 취약점 대응 원칙
- 정책 버전: v1.0 (시행일: YYYY-MM-DD)

정책 내용에 대한 문의는 오픈소스 프로그램 매니저(oss@company.com)에게
연락해 주십시오.

감사합니다.
오픈소스 프로그램 매니저

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 2. 정책
• 관련 템플릿: 오픈소스 정책 템플릿

2.1.2 - §3.1.2 역량

1. 조항 개요

오픈소스 프로그램이 실제로 작동하려면 관련 역할을 맡은 사람들이 그 역할을 수행할 역량을 갖추어야 한다. 역할과 책임이 문서에만 적혀 있고 담당자가 오픈소스 라이선스나 보안 취약점 관리에 대한 기본 지식도 없다면, 정책과 프로세스는 유명무실해진다. §3.1.2는 프로그램에 관여하는 역할을 식별하고 각 역할에 필요한 역량을 정의하며, 참여자가 실제로 그 역량을 갖추었는지 평가하고 기록하도록 요구한다. 이 조항은 §3.1.1 정책에서 정의한 역할 구조를 구체적인 역량 체계로 발전시키는 단계다.

2. 해야 할 활동

• 오픈소스 프로그램의 성과에 영향을 미치는 역할과 각 역할의 책임을 목록으로 작성한다.
• 각 역할을 수행하는 데 필요한 역량(지식·기술·경험)을 구체적으로 정의하고 문서화한다.
• 각 프로그램 참여자가 해당 역할에 필요한 역량을 갖추었는지 평가한다.
• 역량이 미흡한 경우 교육·훈련·멘토링 등 역량 확보 조치를 취한다.
• 역량 평가 결과와 후속 조치 이력을 문서화하여 보관한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.1.2.1 역할과 책임 목록 문서

준수 방법

프로그램에 관여하는 모든 역할을 열거하고, 각 역할이 어떤 책임을 지는지 명확하게 정의한 문서를 작성해야 한다. 일반적으로 오픈소스 프로그램 매니저, 법무 담당, IT 담당, 보안 담당, 개발 문화 담당, 사업 부서가 핵심 역할에 해당한다. 기업 규모나 조직 구조에 따라 역할을 겸임하거나 OSRB(Open Source Review Board) 형태의 가상 조직으로 운영하는 것도 가능하다.

역할 정의 시 추상적인 서술보다 구체적인 책임 항목을 나열하는 것이 감사 시 입증에 유리하다. 예를 들어 “오픈소스 관리"가 아니라 “공급 소프트웨어에 사용된 오픈소스 컴포넌트의 라이선스 검토 및 SBOM 생성 감독"처럼 명확하게 기술한다. 이 문서는 오픈소스 정책 문서(§3.1.1.1)의 역할 및 책임 섹션에 포함하거나 별도 Appendix로 관리할 수 있다.

고려사항

• 역할 식별 범위: 개발·법무·IT·보안·구매 등 소프트웨어 공급망에 관여하는 모든 조직의 역할을 포함하며, 외주 개발 및 벤더 관리 담당도 검토한다.
• 책임 구체화: 역할별 책임은 추상적 서술이 아닌 구체적 활동 단위로 기술한다.
• 겸임 명시: 한 사람이 여러 역할을 겸임하는 경우 해당 사실을 문서에 명기한다.
• 갱신 주기: 조직 변경·인사 이동 발생 시 즉시 문서를 갱신하고 버전을 업데이트한다.

샘플

아래는 오픈소스 정책 Appendix의 역할·책임 목록 샘플이다. 오픈소스 정책 템플릿 Appendix 1에서 전체 양식을 확인할 수 있다.

| 역할 | 책임 |
|------|------|
| 오픈소스 프로그램 매니저 | 회사의 오픈소스 프로그램 총괄 / SBOM 생성 감독 /
                            외부 문의 대응 / 내부 모범 사례 관리 |
| 법무 담당 | 오픈소스 라이선스 의무 해석 및 검토 /
             라이선스 호환성 검토 / 법적 위험 평가 및 자문 |
| IT 담당 | 오픈소스 분석 도구 운영 및 CI/CD 파이프라인 통합 /
            SBOM 생성 자동화 지원 |
| 보안 담당 | 알려진 취약점 및 새로 발견된 취약점 대응 /
             DevSecOps 환경 통합 및 보안 조치 수행 |
| 개발 문화 담당 | 오픈소스 커뮤니티 참여 장려 / 교육 프로그램 운영 |
| 사업 부서 | 오픈소스 정책 및 프로세스 준수 / 오픈소스 식별 및 신고 |

3.1.2.2 역할별 필요 역량 문서

준수 방법

각 역할을 수행하기 위해 필요한 지식·기술·경험을 구체적으로 정의하고 문서화해야 한다. 역량 정의는 해당 역할을 새로 맡은 사람이 “내가 무엇을 알아야 하는가"를 명확히 파악할 수 있는 수준으로 작성한다. 단순히 “오픈소스 지식 필요"처럼 모호하게 쓰지 않고, “주요 오픈소스 라이선스(MIT, Apache-2.0, GPL-2.0 등)의 의무 사항 및 호환성 이해"처럼 구체적으로 기술한다.

역량 수준을 “기본 이해”, “실무 적용 가능”, “전문가” 등으로 세분화하면 평가 기준이 명확해지고 교육 계획을 수립하기 쉬워진다. 이 문서는 오픈소스 정책 문서에 포함하거나 별도 역량 정의서로 관리할 수 있으며, 정기적으로 검토하여 기술 환경 변화를 반영해야 한다.

고려사항

• 구체성: 역량 항목은 측정 가능한 수준으로 기술하여 평가 기준으로 활용할 수 있게 한다.
• 역량 수준 구분: “기본 이해 / 실무 적용 / 전문가” 등 수준을 정의하면 평가와 교육 설계가 용이해진다.
• 갱신 주기: 새로운 도구·라이선스·보안 기술 등장 시 역량 항목을 업데이트한다.
• 교육 연계: 정의된 역량을 기반으로 역할별 교육 커리큘럼을 설계한다.

샘플

아래는 역할별 필요 역량 정의표 샘플이다.

| 역할 | 필요 역량 |
|------|-----------|
| 오픈소스 프로그램 매니저 | 주요 오픈소스 라이선스 의무 및 호환성 이해 /
                            소프트웨어 개발 프로세스 이해 /
                            SBOM 생성·관리 지식 / 커뮤니케이션 스킬 |
| 법무 담당 | 소프트웨어 저작권법 전문 지식 /
             오픈소스 라이선스 해석 능력 / 법적 위험 평가 능력 |
| IT 담당 | 오픈소스 분석 도구(FOSSology, ORT, Syft 등) 운용 /
            CI/CD 파이프라인 이해 / IT 인프라 전문 지식 |
| 보안 담당 | DevSecOps 이해 / 취약점 분석 도구 운용 /
             CVSS 점수 해석 및 위험 평가 능력 |
| 개발 문화 담당 | 오픈소스 정책 이해 / 교육 설계 능력 /
                  오픈소스 커뮤니티 참여 경험 |
| 사업 부서 | 오픈소스 컴플라이언스 기본 지식 /
              오픈소스 라이선스 기본 이해 / 오픈소스 정책 이해 |

3.1.2.3 역량 평가 증거

준수 방법

각 프로그램 참여자가 정의된 역량을 실제로 갖추었는지 평가하고, 그 결과를 문서화하여 보관해야 한다. 평가 방법은 온라인 교육 이수 확인, 자격증 보유 여부 확인, 필기·실기 시험, 담당 업무 수행 실적 검토, 면담 등 다양한 방식을 조합할 수 있다. 중요한 것은 평가 결과가 기록으로 남아야 한다는 점이다. 이 기록 자체가 입증자료 3.1.2.3이다.

평가 결과 미흡한 역량이 발견되면 교육 수강, 외부 컨설팅, 멘토링 등 보완 조치를 취하고 그 완료 기록도 함께 보관한다. 평가는 최소 연 1회 정기적으로 실시하고, 담당자 변경 시에는 신규 담당자에 대해 즉시 초기 평가를 수행한다. 평가 기록은 사내 학습 관리 시스템(LMS) 또는 문서 시스템에 저장하여 감사 시 즉시 제출 가능한 상태로 유지한다.

고려사항

• 평가 방법 다양화: 온라인 교육 이수, 시험, 실무 수행 실적 등 복수의 방법을 조합하여 역량을 종합적으로 평가한다.
• 정기 평가 주기: 최소 연 1회 실시하며, 담당자 변경 시 즉시 신규 평가를 수행한다.
• 미흡 역량 보완: 평가 결과 미흡 항목에 대해 교육 계획을 수립하고 이수 후 재평가를 실시한다.
• 기록 보관 기간: 평가 기록은 최소 해당 담당자 재직 기간 동안 보관하며, 퇴직 후에도 감사 목적으로 일정 기간 유지한다.

샘플

아래는 역량 평가 기록부 샘플이다. 역할별로 작성하여 LMS 또는 문서 시스템에 보관한다.

| 이름 | 역할 | 평가 항목 | 평가 방법 | 평가 결과 | 평가일 | 비고 |
|------|------|-----------|-----------|-----------|--------|------|
| 홍길동 | 오픈소스 프로그램 매니저 | 라이선스 의무 이해 | 온라인 교육 이수 | 완료 (95점) | 2026-01-15 | - |
| 홍길동 | 오픈소스 프로그램 매니저 | SBOM 관리 지식 | 실무 평가 | 완료 | 2026-01-15 | - |
| 김철수 | 보안 담당 | DevSecOps 이해 | 외부 교육 이수 | 완료 | 2026-02-03 | 수료증 보관 |
| 이영희 | 법무 담당 | 오픈소스 라이선스 해석 | 면담 평가 | 완료 | 2026-01-20 | - |

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 1. 조직
• 관련 템플릿: 오픈소스 정책 템플릿 — Appendix 1. 담당자 현황

2.1.3 - §3.1.3 인식

1. 조항 개요

역할과 역량을 갖춘 참여자라도 오픈소스 프로그램의 목적과 자신의 기여가 전체 컴플라이언스 체계에 어떤 의미를 갖는지 인식하지 못하면 형식적 참여에 그치게 된다. §3.1.3은 프로그램 참여자가 프로그램의 목표, 자신의 기여 방법, 그리고 프로그램을 준수하지 않을 경우 발생하는 결과를 실제로 인식하고 있음을 평가하고 기록할 것을 요구한다. 이 조항은 §3.1.2 역량(지식·기술 보유)의 다음 단계로, 참여자가 보유한 역량을 프로그램 목적과 연결하여 실질적 동기를 형성하는 단계다.

2. 해야 할 활동

• 프로그램 참여자가 오픈소스 프로그램의 목표(라이선스 컴플라이언스, 보안 보증 등)를 이해하고 있는지 확인한다.
• 각 참여자가 자신의 역할이 전체 프로그램 운영에 어떻게 기여하는지 인식하고 있는지 평가한다.
• 프로그램 요구사항을 미준수할 경우 발생할 수 있는 법적·사업적 영향에 대해 참여자가 인식하고 있는지 확인한다.
• 인식 평가를 주기적으로 실시하고, 그 결과를 문서로 기록하여 보관한다.
• 인식이 미흡한 참여자에 대해서는 추가 교육을 실시하고 재평가 결과를 보관한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.1.3.1 참여자 인식 평가 증거

준수 방법

프로그램 참여자가 세 가지 핵심 내용을 인식하고 있음을 평가하고 그 결과를 기록해야 한다. 세 가지 핵심 내용은 ①프로그램의 목표(오픈소스 라이선스 컴플라이언스 및 보안 보증), ②자신의 역할이 프로그램에 기여하는 방법, ③프로그램을 준수하지 않을 경우 발생하는 법적·사업적 영향이다.

평가 방법은 온라인 퀴즈, 오프라인 설문, 교육 후 이수 확인, 인터뷰 등 다양하게 조합할 수 있다. 중요한 것은 평가 결과가 문서로 남아야 한다는 점이다. 이 기록이 입증자료 3.1.3.1에 해당한다. 평가는 최소 연 1회 정기적으로 실시하고, 신규 참여자는 프로그램 합류 시 즉시 초기 평가를 수행한다. 인식이 미흡한 참여자에 대해서는 추가 교육을 실시하고 재평가 결과를 함께 보관한다.

고려사항

• 평가 범위: 세 가지 핵심 인식(목표·기여·영향)을 모두 포함하는 평가 문항을 설계한다.
• 평가 주기: 최소 연 1회 정기 평가를 실시하고, 신규 참여자는 합류 즉시 초기 평가를 수행한다.
• 증거 형식: 퀴즈 결과, 서명된 정책 인식 확인서, 교육 이수 증명 등 감사 시 제출 가능한 형식으로 보관한다.
• 미흡자 조치: 평가 결과 미흡한 참여자에 대해 추가 교육을 실시하고 재평가 기록을 남긴다.
• 접근성: 평가에 활용되는 정책 문서 및 교육 자료를 사내 포털에 항상 접근 가능한 상태로 유지한다.

샘플

아래는 참여자 인식 평가 기록부 샘플이다. 교육 이수 시 작성하여 LMS 또는 문서 시스템에 보관한다.

| 이름 | 역할 | 평가 항목 | 평가 방법 | 결과 | 평가일 | 비고 |
|------|------|-----------|-----------|------|--------|------|
| 홍길동 | 오픈소스 프로그램 매니저 | 프로그램 목표 이해 | 온라인 퀴즈 | 완료 (90점) | 2026-01-15 | - |
| 홍길동 | 오픈소스 프로그램 매니저 | 미준수 영향 인식 | 온라인 퀴즈 | 완료 (90점) | 2026-01-15 | - |
| 김철수 | 개발자 | 프로그램 목표 이해 | 온라인 퀴즈 | 완료 (85점) | 2026-01-20 | - |
| 이영희 | 보안 담당 | 자신의 기여 방법 인식 | 인터뷰 | 완료 | 2026-01-22 | 면담 기록 보관 |

아래는 정책 인식 확인서 샘플이다. 교육 완료 후 서명을 받아 보관하면 입증자료로 활용할 수 있다.

[오픈소스 정책 인식 확인서]

본인은 다음 사항을 숙지하였음을 확인합니다:

1. 당사 오픈소스 정책의 존재와 해당 문서의 위치
2. 오픈소스 라이선스 컴플라이언스 및 보안 보증 프로그램의 목표
3. 본인의 역할이 오픈소스 프로그램 운영에 기여하는 방법
4. 오픈소스 정책 및 프로세스를 준수하지 않을 경우 발생할 수 있는
   법적·사업적 위험

이름: ________________  역할: ________________
서명: ________________  날짜: ________________

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 5. 교육
• 관련 템플릿: 오픈소스 정책 템플릿 — §6 교육 및 인식 제고

2.1.4 - §3.1.4 프로그램 범위

1. 조항 개요

오픈소스 프로그램이 조직 전체에 적용되는지, 특정 제품군이나 사업 단위에만 적용되는지 명확하지 않으면 컴플라이언스 활동의 경계가 모호해지고 책임 소재가 불분명해진다. §3.1.4는 오픈소스 프로그램이 어떤 소프트웨어·조직 단위·배포 채널에 적용되는지, 그리고 어디까지가 적용 범위 밖인지를 명확하게 정의한 문서화된 진술을 요구한다. 적용 범위는 조직의 규모와 비즈니스 모델에 따라 다를 수 있으며, 이 조항은 그 선택을 명시적으로 기록하도록 한다.

2. 해야 할 활동

• 오픈소스 프로그램이 적용되는 소프트웨어 유형(외부 배포 제품, 서비스, 내부 시스템 등)을 결정한다.
• 프로그램이 적용되는 조직 범위(전사, 특정 사업부, 특정 제품군 등)를 정의한다.
• 적용 범위에서 명시적으로 제외되는 항목이 있다면 해당 예외 사항과 그 근거를 함께 기록한다.
• 적용 범위 진술을 문서화하여 오픈소스 정책 또는 별도 문서로 공식 관리한다.
• 비즈니스 환경 변화(신규 사업 진출, 인수합병 등) 시 적용 범위를 재검토하고 갱신한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.1.4.1 프로그램 적용 범위 진술

준수 방법

프로그램이 어디에 적용되고 어디에 적용되지 않는지를 명확하게 서술한 문서를 작성해야 한다. 이 진술은 오픈소스 정책 문서(§3.1.1.1)의 적용 범위 섹션에 포함하거나 별도 문서로 관리할 수 있다. 핵심은 경계가 명확해야 한다는 점이다. 예를 들어 “외부에 배포하는 모든 소프트웨어 제품"처럼 명확하게 기술하거나, “A 사업부가 개발하는 임베디드 소프트웨어에 한정"처럼 범위를 구체적으로 한정할 수 있다.

적용 범위를 결정할 때는 소프트웨어 배포 형태(바이너리 제품, SaaS, 내부 도구), 오픈소스 사용 방식(직접 사용, 간접 의존성), 외부 기여 활동 등을 종합적으로 고려한다. 내부 사용 목적 소프트웨어에 대한 처리 방침도 명시하는 것이 바람직하다. 적용 범위 진술은 비즈니스 환경 변화에 따라 정기적으로 검토하고 버전을 관리해야 한다.

고려사항

• 배포 형태 구분: 외부 배포 제품, SaaS 서비스, 내부 시스템 등 소프트웨어 배포 유형별로 적용 여부를 명시한다.
• 조직 범위 명시: 전사 적용인지, 특정 사업부·제품군에만 적용되는지 명확하게 기술한다.
• 예외 항목 기록: 적용 범위에서 제외되는 항목이 있다면 예외 사유와 함께 문서에 명기한다.
• 갱신 주기: 신규 사업 진출, 인수합병, 제품 포트폴리오 변경 시 즉시 재검토하고 버전을 업데이트한다.
• 정책 연계: 적용 범위 진술은 오픈소스 정책 §1.4 적용 범위 섹션과 일관성을 유지한다.

샘플

아래는 오픈소스 정책 내 적용 범위 진술 샘플이다. 이 텍스트 자체가 입증자료 3.1.4.1에 해당한다.

## 프로그램 적용 범위

본 오픈소스 프로그램은 다음 범위에 적용된다:

**적용 대상**
- 회사가 외부에 배포하거나 판매하는 모든 소프트웨어 제품 (임베디드 소프트웨어
  포함)
- 외부 오픈소스 프로젝트에 대한 기여 활동
- 내부 프로젝트를 오픈소스로 공개하는 활동

**적용 제외**
- 외부에 배포되지 않고 사내에서만 사용되는 소프트웨어 (단, 별도 검토 절차
  적용 가능)
- 제3자로부터 도입하는 상용 소프트웨어 (단, 오픈소스 포함 여부 검토 필요)

**조직 범위**
본 프로그램은 [회사명] 전 사업부에 적용되며, 자회사 및 계열사는 별도 협의를
통해 적용 여부를 결정한다.

이 적용 범위는 비즈니스 환경 변화에 따라 연 1회 이상 검토하며,
변경 시 오픈소스 프로그램 매니저가 개정 버전을 공표한다.

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 2. 정책
• 관련 템플릿: 오픈소스 정책 템플릿 — §1.4 적용 범위

2.1.5 - §3.1.5 라이선스 의무

1. 조항 개요

오픈소스 컴포넌트를 소프트웨어에 포함할 때 가장 핵심적인 작업은 해당 컴포넌트에 적용된 라이선스가 부과하는 의무·제한·권리를 정확히 파악하는 것이다. 라이선스 의무를 검토하지 않고 배포하면 소스코드 강제 공개, 저작권 고지 누락, 특허 조항 위반 등 심각한 법적 리스크가 발생할 수 있다. §3.1.5는 식별된 모든 라이선스에 대해 의무·제한·권리를 검토하고 기록하는 절차를 수립하도록 요구한다. 이 절차는 §3.3.2 라이선스 컴플라이언스 프로세스의 토대가 된다.

2. 해야 할 활동

• 소프트웨어에 사용된 오픈소스 컴포넌트의 라이선스를 식별하고 목록화한다.
• 각 라이선스가 부과하는 의무(고지 의무, 소스코드 공개 의무 등), 제한(상업적 사용 제한, 특허 사용 제한 등), 권리(사용·수정·재배포 권리 등)를 검토한다.
• 검토 결과를 라이선스별로 문서화하고 기록을 유지한다.
• 라이선스 해석에 불확실성이 있는 경우 법무 담당에게 검토를 의뢰하는 절차를 수립한다.
• 신규 라이선스 등장 또는 기존 라이선스 해석 변경 시 절차를 갱신한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.1.5.1 라이선스 의무 검토 절차

준수 방법

각 오픈소스 라이선스의 의무·제한·권리를 검토하고 기록하는 절차를 문서화해야 한다. 절차에는 ①라이선스 식별, ②의무·제한·권리 분석, ③검토 결과 기록, ④불확실 사항에 대한 법무 검토 의뢰, ⑤기록 보관의 단계가 포함되어야 한다. 이 절차 문서 자체가 입증자료 3.1.5.1이다.

라이선스별 의무는 사전에 정리된 라이선스 데이터베이스(SPDX License List 등)를 활용하면 효율적으로 관리할 수 있다. 주요 라이선스(MIT, Apache-2.0, GPL-2.0, GPL-3.0, LGPL-2.1, AGPL-3.0 등)에 대한 의무 요약표를 미리 작성해 두고, 신규 라이선스 발견 시 즉시 추가 검토하는 방식이 실무적으로 효과적이다. 복잡한 라이선스 조합이나 법적 판단이 필요한 경우 법무 담당에게 에스컬레이션하는 기준도 절차에 명시한다.

고려사항

• SPDX 활용: SPDX License List를 기준 라이선스 목록으로 사용하면 식별과 분류가 표준화된다.
• 의무 유형 구분: 고지 의무, 소스코드 공개 의무, 특허 조항, 상표 제한 등 의무 유형을 구분하여 기록한다.
• 배포 형태별 검토: 바이너리 배포, SaaS, 내부 사용 등 배포 형태에 따라 라이선스 의무가 달라질 수 있으므로 형태별로 검토한다.
• 에스컬레이션 기준: 법무 검토가 필요한 상황(라이선스 충돌, 비표준 라이선스, 상업적 제한 조항 등)을 절차에 명시한다.
• 갱신 주기: 신규 라이선스 채택 또는 기존 라이선스 해석 변경 시 즉시 절차와 기록을 갱신한다.

샘플

아래는 주요 오픈소스 라이선스 의무 요약표 샘플이다. 라이선스 검토 절차의 일환으로 작성하여 보관하면 입증자료로 활용할 수 있다.

| 라이선스 | 고지 의무 | 소스코드 공개 | 수정본 동일 라이선스 | 특허 조항 | 상업적 사용 |
|----------|-----------|--------------|----------------------|-----------|-------------|
| MIT | O | X | X | X | O |
| Apache-2.0 | O | X | X | O (특허 허여) | O |
| GPL-2.0 | O | O (배포 시) | O | X | O |
| GPL-3.0 | O | O (배포 시) | O | O (특허 허여) | O |
| LGPL-2.1 | O | O (라이브러리) | O (라이브러리) | X | O |
| AGPL-3.0 | O | O (네트워크 포함) | O | O (특허 허여) | O |
| MPL-2.0 | O | O (파일 단위) | O (파일 단위) | O (특허 허여) | O |
| BSD-2-Clause | O | X | X | X | O |
| BSD-3-Clause | O | X | X | X | O |

아래는 라이선스 의무 검토 절차 개요 샘플이다.

[라이선스 의무 검토 절차]

1. 라이선스 식별
   - SBOM 생성 도구(FOSSology, ORT 등)를 통해 오픈소스 컴포넌트 및
     라이선스를 식별한다.

2. 의무·제한·권리 분석
   - 사전 작성된 라이선스 의무 요약표를 참조하여 해당 라이선스의
     의무·제한·권리를 확인한다.
   - 요약표에 없는 라이선스는 SPDX License List 및 라이선스 원문을
     검토하여 신규 항목을 추가한다.

3. 법무 검토 의뢰 (해당 시)
   - 라이선스 충돌, 비표준 라이선스, 상업적 제한 조항이 포함된 경우
     법무 담당에게 검토를 의뢰한다.

4. 검토 결과 기록
   - 검토 결과를 SBOM 또는 라이선스 검토 기록서에 기록하고
     오픈소스 관리 시스템에 보관한다.

5. 의무 이행 확인
   - 배포 전 라이선스 의무(고지문 포함, 소스코드 공개 등)가 완료되었는지
     확인한다.

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
• 관련 템플릿: 오픈소스 프로세스 템플릿

2.2 - §3.2 관련 업무

2.2.1 - §3.2.1 외부 문의 대응

1. 조항 개요

소프트웨어를 배포하는 기업은 제3자(고객, 오픈소스 저작권자, 연구자 등)로부터 오픈소스 라이선스 컴플라이언스에 관한 문의를 받을 수 있다. 이 문의에 제때 응답하지 못하면 저작권 침해 분쟁으로 확대될 위험이 있다. §3.2.1은 외부 문의를 접수할 수 있는 공개된 연락 수단을 마련하고, 내부적으로는 문의에 체계적으로 대응하기 위한 절차를 문서화하도록 요구한다. 이 조항은 공개 채널(입증자료 3.2.1.1)과 내부 대응 절차(입증자료 3.2.1.2) 두 가지를 모두 갖출 것을 요구한다.

2. 해야 할 활동

• 제3자가 오픈소스 라이선스 컴플라이언스 문의를 보낼 수 있는 공개 연락처(이메일 주소, 웹폼 등)를 제품 또는 웹사이트에 명시한다.
• 외부 문의 접수부터 검토·답변·종결까지의 내부 대응 절차를 문서화한다.
• 문의 유형별 담당자(오픈소스 프로그램 매니저, 법무 담당 등)와 에스컬레이션 경로를 절차에 포함한다.
• 문의 접수 및 대응 이력을 기록하고 보관한다.
• 정기적으로 공개 연락처 유효성과 내부 절차의 최신성을 점검한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.2.1.1 공개된 외부 문의 채널

준수 방법

제3자가 오픈소스 라이선스 컴플라이언스에 관한 문의를 보낼 수 있는 수단을 공개적으로 명시해야 한다. 가장 일반적인 방법은 전용 이메일 주소(예: oss@company.com)를 제품 설명서, 소프트웨어 오픈소스 고지문, 또는 회사 웹사이트에 게시하는 것이다. 이 공개 연락처 자체가 입증자료 3.2.1.1이다.

연락처는 담당자 개인 이메일이 아닌 역할 기반 주소(role-based address)를 사용하는 것이 좋다. 담당자가 변경되더라도 주소가 유지되며, 문의가 누락되지 않도록 팀 메일함으로 관리하는 것이 바람직하다. OpenChain Conformance 웹사이트에 연락처를 등록하는 방법도 활용할 수 있다.

고려사항

• 역할 기반 주소 사용: 개인 이메일 대신 oss@company.com과 같은 역할 기반 주소를 사용하여 담당자 변경에 대비한다.
• 게시 위치: 제품 매뉴얼, 오픈소스 고지문(NOTICES 파일), 회사 웹사이트 등 제3자가 쉽게 찾을 수 있는 위치에 게시한다.
• 응답 가능성 확인: 게시된 연락처가 실제로 수신되고 모니터링되는지 정기적으로 점검한다.
• 다국어 고려: 글로벌 제품의 경우 영문 연락처도 함께 제공한다.

샘플

아래는 제품 오픈소스 고지문 또는 웹사이트에 게시하는 공개 연락처 샘플이다.

오픈소스 라이선스 컴플라이언스 문의

이 소프트웨어에 포함된 오픈소스 컴포넌트의 라이선스 컴플라이언스에 관한
문의는 아래 이메일로 연락해 주십시오.

- 이메일: oss@company.com
- 응답 기간: 영업일 기준 14일 이내

Open Source License Compliance Inquiry

For inquiries regarding open source license compliance of this software,
please contact: oss@company.com

3.2.1.2 내부 외부 문의 대응 절차

준수 방법

외부 문의가 접수되었을 때 어떻게 처리할지를 정의한 내부 절차를 문서화해야 한다. 절차에는 ①문의 접수 및 분류, ②담당자 배정, ③검토 및 답변 작성, ④법무 검토 (필요 시), ⑤답변 발송, ⑥기록 보관의 단계가 포함되어야 한다. 이 절차 문서가 입증자료 3.2.1.2다.

답변 기한은 합리적인 범위에서 설정하고 절차에 명시한다. 일반적으로 14일 이내 초기 응답, 60일 이내 최종 답변을 기준으로 삼는 경우가 많다. 문의 접수·처리· 종결 이력은 사내 시스템에 기록하여 감사 시 제출할 수 있도록 보관한다.

고려사항

• 담당자 및 에스컬레이션: 1차 담당자(오픈소스 프로그램 매니저)와 법무 검토 에스컬레이션 경로를 절차에 명시한다.
• 응답 기한: 초기 응답과 최종 답변의 기한을 절차에 명시하고 준수한다.
• 기록 보관: 문의 내용, 검토 과정, 최종 답변을 기록하고 최소 3년간 보관한다.
• 유형별 대응: 라이선스 고지 요청, 소스코드 제공 요청, 저작권 침해 주장 등 문의 유형별 대응 방법을 절차에 포함한다.

샘플

아래는 외부 문의 대응 절차 개요 샘플이다.

[외부 오픈소스 문의 대응 절차]

1. 접수 및 분류 (1영업일 이내)
   - oss@company.com 수신함을 매일 확인한다.
   - 문의를 유형별로 분류한다:
     A. 오픈소스 고지문 또는 소스코드 제공 요청
     B. 라이선스 의무 준수 여부 확인 요청
     C. 저작권 침해 주장 또는 법적 경고

2. 담당자 배정 및 초기 응답 (3영업일 이내)
   - 오픈소스 프로그램 매니저가 문의를 검토하고 수신 확인 답변을 발송한다.
   - C유형(법적 경고)은 즉시 법무 담당에게 에스컬레이션한다.

3. 검토 및 답변 작성 (14영업일 이내)
   - 관련 SBOM, 라이선스 기록, 컴플라이언스 산출물을 검토한다.
   - A유형: 고지문 또는 소스코드를 확인하여 제공한다.
   - B유형: 컴플라이언스 이행 증거를 검토하여 답변한다.
   - 필요 시 법무 담당에게 답변 초안 검토를 의뢰한다.

4. 답변 발송 및 종결
   - 최종 답변을 발송하고 문의를 종결 처리한다.

5. 기록 보관
   - 문의 내용, 검토 과정, 최종 답변을 문서화하여 최소 3년간 보관한다.

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
• 관련 템플릿: 오픈소스 정책 템플릿 — §9 외부 문의 대응

2.2.2 - §3.2.2 효과적 리소스

1. 조항 개요

오픈소스 프로그램이 실제로 작동하려면 역할을 정의하는 것만으로는 부족하다. 각 역할을 담당할 실제 인원이 배정되고, 업무 수행에 필요한 시간과 예산이 충분히 지원되어야 한다. §3.2.2는 프로그램 역할별 담당자를 문서로 명시하고, 인원 배치와 예산이 적절히 이루어졌음을 확인하며, 법률 자문 접근 방법과 내부 책임 할당 절차, 미준수 사례 처리 절차를 갖출 것을 요구한다. 이 조항은 5개의 입증자료 항목으로 구성되어 §3.1 프로그램 기반에서 정의한 역할 구조를 실제 운영 체계로 구현하는 단계다.

2. 해야 할 활동

• 프로그램 내 각 역할(오픈소스 프로그램 매니저, 법무 담당, IT 담당 등)을 맡은 담당자의 이름 또는 직무를 문서에 기재한다.
• 각 역할 담당자가 업무를 수행할 수 있도록 충분한 시간과 예산이 배정되었음을 확인하고 기록한다.
• 오픈소스 라이선스 컴플라이언스 관련 법적 문제 발생 시 이용할 수 있는 내부 또는 외부 법률 자문 수단을 식별하고 문서화한다.
• 오픈소스 컴플라이언스 내부 책임을 각 역할에 할당하는 절차를 문서화한다.
• 컴플라이언스 미준수 사례를 발견했을 때 검토하고 시정하는 절차를 문서화한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.2.2.1 역할 담당자 명시 문서

준수 방법

프로그램의 각 역할을 실제로 담당하는 인원의 이름, 그룹명, 또는 직무명을 기재한 문서를 작성해야 한다. 이 문서는 §3.1.2.1의 역할·책임 목록 문서에 담당자 정보를 추가하는 형태로 관리하거나, 오픈소스 정책 Appendix에 담당자 현황표로 포함할 수 있다. 특정 개인 이름 대신 직무명(오픈소스 프로그램 매니저, 법무팀장 등)을 사용해도 무방하며, 조직 변경 시 즉시 갱신해야 한다.

고려사항

• 개인명 또는 직무명: 이름 대신 직무명을 사용하면 인사 변동 시에도 문서를 자주 갱신할 필요가 줄어든다.
• 겸임 명시: 한 사람이 여러 역할을 담당하는 경우 모든 역할에 해당 사실을 기재한다.
• 갱신 관리: 조직 변경·인사 이동 발생 시 즉시 문서를 업데이트하고 버전을 기록한다.

샘플

아래는 역할 담당자 현황표 샘플이다. 오픈소스 정책 템플릿 Appendix 1에서 전체 양식을 확인할 수 있다.

| 역할 | 담당자 | 연락처 |
|------|--------|--------|
| 오픈소스 프로그램 매니저 | 홍길동 (개발팀장) | oss@company.com |
| 법무 담당 | 김법무 (법무팀장) | legal@company.com |
| IT 담당 | 이인프라 (인프라팀) | it-oss@company.com |
| 보안 담당 | 박보안 (보안팀) | security@company.com |
| 개발 문화 담당 | 최문화 (HR팀) | culture@company.com |

3.2.2.2 인원 배치 및 예산 지원 확인

준수 방법

각 역할 담당자가 오픈소스 프로그램 업무를 수행할 수 있도록 충분한 시간과 예산이 배정되었음을 확인하고 그 근거를 기록해야 한다. 별도의 전담 조직이 없는 경우에도 겸임 담당자가 해당 업무에 투입할 수 있는 시간이 확보되었는지, 도구 구매나 교육비 등 필요 예산이 편성되었는지를 확인하는 내부 기록이 있어야 한다. 경영진 승인이 포함된 예산 계획서나 업무 분장 문서가 이 입증자료에 해당할 수 있다.

고려사항

• 전담 여부 명시: 전담 인원인지 겸임인지를 기록하고, 겸임의 경우 투입 비율(예: 업무 시간의 20%)을 명시한다.
• 예산 근거 보관: 도구 구매 계약서, 교육비 집행 내역, 외부 컨설팅 계약 등 예산 지원을 증명하는 기록을 보관한다.
• 경영진 확인: 인원 배치와 예산 지원에 대한 경영진 승인 또는 확인 기록을 유지한다.

샘플

[오픈소스 프로그램 리소스 배정 확인서]

프로그램 연도: 2026년
승인자: [임원명] / 승인일: 2026-01-10

| 역할 | 담당자 | 투입 비율 | 연간 예산 |
|------|--------|-----------|-----------|
| 오픈소스 프로그램 매니저 | 홍길동 | 50% | - |
| 법무 담당 | 김법무 | 20% | - |
| IT 담당 (도구 운영) | 이인프라 | 10% | 도구 라이선스 비용 포함 |
| 교육 예산 | - | - | 연간 OOO만 원 |
| 외부 법률 자문 예산 | - | - | 필요 시 집행 |

3.2.2.3 법률 자문 접근 방법

준수 방법

오픈소스 라이선스 컴플라이언스와 관련된 법적 문제가 발생했을 때 전문 법률 자문을 받을 수 있는 방법을 식별하고 문서화해야 한다. 내부 법무팀이 있는 경우 해당 팀의 연락처와 에스컬레이션 절차를 기록하고, 내부 법무팀이 없거나 전문성이 부족한 경우 외부 법무법인 또는 오픈소스 컨설팅 전문가를 활용하는 방법을 문서에 명시한다.

고려사항

• 내부 vs. 외부: 내부 법무팀 활용 방법과 외부 자문 의뢰 기준을 모두 명시한다.
• 에스컬레이션 기준: 어떤 상황에서 법률 자문을 받아야 하는지(저작권 침해 주장, 비표준 라이선스, 특허 조항 등) 기준을 절차에 포함한다.
• 외부 자문 목록 관리: 오픈소스 전문 외부 법무법인 또는 컨설턴트 정보를 최신 상태로 유지한다.

샘플

[법률 자문 접근 방법]

내부 법무팀:
- 담당: 법무팀 (legal@company.com)
- 에스컬레이션 기준: 저작권 침해 주장 접수, GPL 계열 라이선스 의무
  해석 불확실, 비표준 라이선스 검토 필요 시

외부 법률 자문:
- 활용 기준: 내부 법무팀에서 판단이 어려운 복잡한 법적 분쟁 발생 시
- 계약 현황: [외부 법무법인명] (연간 자문 계약 체결)
- 오픈소스 전문 컨설팅: OpenChain 파트너사 목록 참조

3.2.2.4 내부 책임 할당 절차

준수 방법

오픈소스 컴플라이언스와 관련된 내부 책임을 각 역할에 명확히 할당하는 절차를 문서화해야 한다. 이 절차는 누가 무엇을 책임지는지를 정의하며, 오픈소스 사용 승인, SBOM 생성, 라이선스 검토, 컴플라이언스 산출물 배포 등 각 업무 단계별 책임자를 명시한다. 이 절차 문서는 오픈소스 정책 또는 프로세스 문서에 포함할 수 있다.

고려사항

• 업무 단계별 책임 명시: 오픈소스 도입, 검토, 승인, 배포 각 단계마다 책임자를 지정한다.
• RACI 활용: 역할별 책임(Responsible, Accountable, Consulted, Informed)을 RACI 매트릭스로 정의하면 명확성이 높아진다.
• 갱신 주기: 조직 변경 또는 프로세스 변경 시 절차를 즉시 갱신한다.

샘플

| 업무 | 오픈소스 PM | 법무 담당 | IT 담당 | 보안 담당 | 개발자 |
|------|------------|-----------|---------|-----------|--------|
| 오픈소스 사용 승인 | A | C | - | C | R |
| 라이선스 의무 검토 | R | A | - | - | I |
| SBOM 생성 | A | - | R | - | C |
| 취약점 모니터링 | I | - | C | A/R | I |
| 컴플라이언스 산출물 배포 | A | C | R | - | I |
| 외부 문의 대응 | A/R | C | - | - | - |

R: 실행 책임 / A: 최종 책임 / C: 협의 / I: 정보 공유

3.2.2.5 미준수 사례 검토 및 시정 절차

준수 방법

오픈소스 컴플라이언스 미준수 사례(라이선스 의무 불이행, SBOM 누락, 무승인 오픈소스 사용 등)가 발견되었을 때 이를 검토하고 시정하는 절차를 문서화해야 한다. 절차에는 ①미준수 사례 식별 및 보고, ②심각도 평가, ③원인 분석, ④시정 조치, ⑤재발 방지 대책, ⑥기록 보관이 포함되어야 한다.

미준수 사례는 내부 감사, 외부 문의, 자동화 도구 알림 등 다양한 경로로 발견될 수 있다. 심각도에 따라 긴급 조치(배포 중단, 소스코드 즉시 공개 등)와 일반 조치를 구분하여 처리 기한을 다르게 설정하는 것이 효과적이다.

고려사항

• 심각도 분류: 미준수 사례의 법적 리스크에 따라 심각도(높음/중간/낮음)를 분류하고 처리 기한을 다르게 설정한다.
• 에스컬레이션: 심각도가 높은 사례는 경영진 보고 및 법무 검토를 의무화한다.
• 재발 방지: 시정 조치 완료 후 동일 유형의 미준수가 재발하지 않도록 프로세스 개선 방안을 도출하고 기록한다.
• 기록 보관: 미준수 사례 이력과 시정 완료 기록을 최소 3년간 보관한다.

샘플

[미준수 사례 처리 절차]

1. 식별 및 보고
   - 내부 감사, 외부 문의, CI/CD 도구 알림 등을 통해 미준수 사례를 식별한다.
   - 오픈소스 프로그램 매니저에게 즉시 보고한다.

2. 심각도 평가
   - 높음: 배포된 소프트웨어의 GPL 소스코드 미공개, 저작권 침해 주장 접수
     → 48시간 이내 긴급 검토 착수
   - 중간: SBOM 누락, 라이선스 고지문 불완전
     → 7영업일 이내 시정 조치 완료
   - 낮음: 내부 프로세스 미준수 (승인 절차 생략 등)
     → 30일 이내 시정 조치 완료

3. 원인 분석 및 시정 조치
   - 미준수 원인을 파악하고 시정 방안을 수립한다.
   - 높음·중간 사례는 법무 담당과 협의 후 조치한다.

4. 재발 방지
   - 프로세스 또는 교육 개선 방안을 도출하고 이행한다.

5. 기록 보관
   - 사례 내용, 조치 경과, 완료 일자를 기록하고 최소 3년간 보관한다.

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 1. 조직
• 관련 템플릿: 오픈소스 정책 템플릿 — Appendix 1. 담당자 현황

2.3 - §3.3 콘텐츠 검토 및 승인

2.3.1 - §3.3.1 SBOM

1. 조항 개요

공급 소프트웨어에 어떤 오픈소스 컴포넌트가 포함되어 있는지 파악하지 못하면 라이선스 의무를 이행할 수 없고 보안 취약점 대응도 불가능하다. §3.3.1은 공급 소프트웨어를 구성하는 오픈소스 컴포넌트를 식별·추적·검토·승인·보관하는 절차를 수립하고, 그 절차가 실제로 이행되었음을 입증하는 컴포넌트 기록(SBOM)을 유지하도록 요구한다. 이 조항은 오픈소스 라이선스 컴플라이언스와 보안 보증의 핵심 인프라인 SBOM을 운영하는 기반이 된다.

2. 해야 할 활동

• 공급 소프트웨어에 포함된 오픈소스 컴포넌트를 자동화 도구(FOSSology, ORT, Syft, cdxgen 등)를 활용하여 식별하고 목록화한다.
• 오픈소스 컴포넌트 정보(컴포넌트명, 버전, 라이선스, 출처 등)를 추적하고 검토·승인·보관하는 절차를 문서화한다.
• 각 공급 소프트웨어 릴리스에 대한 SBOM을 생성하고 관리한다.
• SBOM 데이터를 SPDX 또는 CycloneDX 표준 형식으로 작성하여 상호 운용성을 확보한다.
• 소프트웨어 변경(신규 컴포넌트 추가, 버전 업그레이드, 컴포넌트 제거) 시 SBOM을 즉시 갱신한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.3.1.1 오픈소스 컴포넌트 관리 절차

준수 방법

공급 소프트웨어에 포함된 오픈소스 컴포넌트를 식별·추적·검토·승인·보관하는 일련의 절차를 문서화해야 한다. 절차는 소프트웨어 개발 주기 전반에 걸쳐 오픈소스가 어떻게 관리되는지를 다루며, ①컴포넌트 식별, ②라이선스 확인, ③의무 검토, ④사용 승인, ⑤SBOM 생성 및 등록, ⑥배포 시 SBOM 제공, ⑦변경 시 SBOM 갱신, ⑧SBOM 보관의 단계를 포함해야 한다. 이 절차 문서 자체가 입증자료 3.3.1.1이다.

SBOM은 SPDX(ISO/IEC 5962) 또는 CycloneDX 형식을 채택하여 표준화하는 것을 권장한다. 자동화 도구를 CI/CD 파이프라인에 통합하면 컴포넌트 변경 시 SBOM이 자동으로 갱신되어 최신성을 유지하기 쉽다.

고려사항

• 자동화 도구 통합: FOSSology, ORT, Syft, cdxgen 등을 CI/CD에 통합하여 SBOM 생성을 자동화한다.
• 표준 형식 채택: SPDX 또는 CycloneDX 형식으로 SBOM을 작성하여 공급망 파트너와의 상호 운용성을 확보한다.
• 갱신 트리거 정의: 신규 컴포넌트 추가, 버전 업그레이드, 컴포넌트 제거, 라이선스 변경 발생 시 SBOM 갱신을 의무화한다.
• 승인 절차 명시: 새로운 오픈소스 컴포넌트 도입 시 오픈소스 프로그램 매니저 또는 OSRB의 승인 절차를 절차에 포함한다.
• 보관 기간: SBOM은 해당 소프트웨어 배포 후 최소 [N]년간 보관한다.

샘플

아래는 오픈소스 컴포넌트 관리 절차 개요 샘플이다. 오픈소스 프로세스 템플릿에서 전체 프로세스 양식을 확인할 수 있다.

[오픈소스 컴포넌트 관리 절차 개요]

(1) 식별
    - 개발자는 오픈소스 컴포넌트 도입 시 오픈소스 관리 시스템에 신고한다.
    - CI/CD 파이프라인의 SCA 도구(Syft, ORT 등)가 컴포넌트를 자동 탐지한다.

(2) 라이선스 확인 및 의무 검토
    - 식별된 컴포넌트의 라이선스를 SPDX License List 기준으로 확인한다.
    - 라이선스 의무 요약표를 참조하여 배포 형태에 따른 의무를 검토한다.
    - 불확실한 경우 법무 담당에게 검토를 의뢰한다.

(3) 사용 승인
    - 오픈소스 프로그램 매니저가 검토 결과를 바탕으로 사용을 승인한다.
    - 라이선스 정책에 반하는 컴포넌트는 대안 검토 후 반려한다.

(4) SBOM 생성 및 등록
    - 승인된 컴포넌트를 SBOM에 등록한다 (형식: SPDX 또는 CycloneDX).
    - SBOM에는 컴포넌트명, 버전, 라이선스, 출처(URL), 저작권 고지를 포함한다.

(5) 배포 및 SBOM 제공
    - 소프트웨어 배포 시 SBOM을 함께 제공하거나 요청 시 제공한다.

(6) 변경 시 갱신
    - 컴포넌트 추가·업그레이드·제거·라이선스 변경 발생 시 SBOM을 즉시 갱신한다.

(7) 보관
    - SBOM은 소프트웨어 배포 후 최소 [N]년간 버전별로 보관한다.

3.3.1.2 오픈소스 컴포넌트 기록 (SBOM)

준수 방법

3.3.1.1에서 정의한 절차가 실제로 이행되었음을 보여주는 컴포넌트 기록을 공급 소프트웨어별로 유지해야 한다. 이 기록이 SBOM(Software Bill of Materials)이며 입증자료 3.3.1.2에 해당한다. SBOM에는 최소한 각 오픈소스 컴포넌트의 이름·버전· 라이선스·출처가 포함되어야 하며, SPDX 또는 CycloneDX 형식으로 작성하면 감사 시 즉시 제출 가능한 형태가 된다.

SBOM은 소프트웨어 릴리스 버전별로 관리하고, 과거 버전의 SBOM도 보관하여 특정 시점의 컴포넌트 구성을 언제든 확인할 수 있어야 한다. SBOM 생성 도구의 출력 결과를 그대로 활용하거나, 오픈소스 관리 시스템(SW360, Dependency-Track 등)에 저장·관리하는 방식을 사용할 수 있다.

고려사항

• 필수 포함 항목: 컴포넌트명, 버전, 라이선스 식별자(SPDX ID), 출처(패키지 레지스트리 URL 또는 소스 저장소), 저작권 고지를 포함한다.
• 버전별 관리: 소프트웨어 릴리스 버전별로 SBOM을 별도 관리하고 과거 버전도 보관한다.
• 관리 도구 활용: SW360, Dependency-Track 등 오픈소스 관리 시스템을 활용하면 SBOM의 생성·추적·배포를 체계적으로 관리할 수 있다.
• 고객 제공: 고객 또는 공급망 파트너가 SBOM을 요청하는 경우 즉시 제공할 수 있도록 접근 가능한 형태로 보관한다.

샘플

아래는 SPDX 형식 SBOM의 핵심 항목 샘플이다.

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: MyProduct-v1.2.0-sbom
DocumentNamespace: https://company.com/sbom/myproduct-1.2.0

PackageName: openssl
SPDXID: SPDXRef-openssl
PackageVersion: 3.0.8
PackageDownloadLocation: https://www.openssl.org/source/openssl-3.0.8.tar.gz
PackageLicenseConcluded: Apache-2.0
PackageLicenseDeclared: Apache-2.0
PackageCopyrightText: Copyright (c) 1998-2023 The OpenSSL Project

PackageName: zlib
SPDXID: SPDXRef-zlib
PackageVersion: 1.2.13
PackageDownloadLocation: https://zlib.net/zlib-1.2.13.tar.gz
PackageLicenseConcluded: Zlib
PackageLicenseDeclared: Zlib
PackageCopyrightText: Copyright (C) 1995-2022 Jean-loup Gailly and Mark Adler

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
• 관련 템플릿: 오픈소스 프로세스 템플릿
• 관련 도구: FOSSology, ORT, Syft, cdxgen, Dependency-Track

2.3.2 - §3.3.2 라이선스 컴플라이언스

1. 조항 개요

오픈소스 컴포넌트는 배포 형태(바이너리·소스코드), 수정 여부, 다른 컴포넌트와의 결합 방식에 따라 라이선스 의무가 달라진다. §3.3.2는 공급 소프트웨어에 포함된 오픈소스 컴포넌트에 대해 자주 발생하는 라이선스 사용 사례들을 처리할 수 있는 능력을 프로그램이 갖추도록 요구한다. 이 조항은 단순히 라이선스를 식별하는 것을 넘어, 다양한 배포 시나리오별로 의무 이행 방법을 정의한 절차를 마련하도록 한다.

2. 해야 할 활동

• 바이너리 형태 배포, 소스코드 형태 배포, 수정된 오픈소스 배포 등 주요 라이선스 사용 사례를 식별하고 각 사례별 처리 절차를 수립한다.
• 라이선스 충돌(비호환 라이선스 컴포넌트 결합)이 발생했을 때의 처리 방법을 절차에 포함한다.
• 고지 의무(저작권 고지문, 라이선스 전문 포함)가 필요한 라이선스에 대한 처리 방법을 정의한다.
• GPL 등 소스코드 공개 의무가 있는 라이선스가 포함된 소프트웨어의 배포 절차를 수립한다.
• 절차를 문서화하고 정기적으로 검토하여 새로운 라이선스 유형에 대응한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.3.2.1 라이선스 사용 사례별 처리 절차

준수 방법

공급 소프트웨어에 오픈소스가 포함되는 다양한 시나리오별로 라이선스 의무를 어떻게 이행하는지 정의한 절차를 문서화해야 한다. 이 절차 문서가 입증자료 3.3.2.1이다. ISO/IEC 5230은 아래 6가지 주요 사용 사례를 예시로 제시하며, 조직의 비즈니스 환경에 따라 해당되는 사례를 선택하여 처리 절차를 수립한다.

각 사용 사례별 절차에는 ①해당 사례 해당 여부 판단 기준, ②라이선스 의무 항목, ③의무 이행 방법, ④담당자, ⑤산출물(고지문, 소스코드 패키지 등)이 포함되어야 한다. 라이선스 충돌이 발생하는 경우 법무 담당에게 에스컬레이션하는 경로도 명시한다.

고려사항

• 사용 사례 범위 확정: 조직의 소프트웨어 배포 방식에 맞는 사용 사례를 선택하여 절차를 수립한다 (모든 사례가 모든 조직에 해당되지 않을 수 있다).
• 라이선스 충돌 대응: GPL과 Apache-2.0 등 비호환 라이선스 조합 발생 시 처리 방법을 미리 정의해 둔다.
• 고지문 관리: 저작권 고지 의무가 있는 라이선스에 대해 NOTICES 파일 또는 제품 설명서 내 고지문 작성 절차를 수립한다.
• 소스코드 공개 절차: GPL 계열 라이선스의 소스코드 공개 요청 대응 절차를 별도로 정의한다.
• 갱신 주기: 신규 라이선스 유형 도입 또는 배포 형태 변경 시 절차를 갱신한다.

샘플

아래는 라이선스 사용 사례별 처리 절차 요약표 샘플이다.

| 사용 사례 | 라이선스 예시 | 주요 의무 | 처리 방법 |
|-----------|--------------|-----------|-----------|
| 바이너리 형태 배포 | MIT, Apache-2.0 | 저작권 고지문 포함 | NOTICES 파일 또는 앱 내 고지 화면에 고지문 포함 |
| 바이너리 형태 배포 | GPL-2.0, GPL-3.0 | 소스코드 공개 또는 제공 약정서 포함 | 소스코드 패키지 배포 또는 written offer 동봉 |
| 소스코드 형태 배포 | 모든 라이선스 | 원본 라이선스 파일 및 저작권 고지 보존 | 라이선스 파일과 저작권 고지를 그대로 유지 |
| 수정된 오픈소스 포함 | GPL-2.0, LGPL-2.1 | 수정 사항 명시, 수정본 동일 라이선스 적용 | 수정 내역 기록, 수정본 소스코드 공개 |
| 비호환 라이선스 결합 | GPL-2.0 + Apache-2.0 | 라이선스 충돌 해소 | 법무 검토 후 컴포넌트 대체 또는 구조 변경 |
| 저작권 고지 요건 | BSD-3-Clause, Apache-2.0 | 제품 문서 또는 UI에 저작권 고지 포함 | 제품 설명서 또는 About 화면에 고지문 추가 |

아래는 배포 형태별 라이선스 의무 처리 절차 개요 샘플이다.

[바이너리 배포 시 라이선스 의무 처리 절차]

1. SBOM 확인
   - 배포 소프트웨어의 최신 SBOM을 기준으로 포함된 오픈소스 목록을 확인한다.

2. 라이선스 의무 분류
   - 고지문 의무: MIT, Apache-2.0, BSD 등 → NOTICES 파일 작성
   - 소스코드 공개 의무: GPL-2.0, GPL-3.0 → 소스코드 패키지 준비
   - LGPL: 동적 링크 여부에 따라 의무 범위 판단 (필요 시 법무 검토)

3. 컴플라이언스 산출물 준비
   - NOTICES 파일: 모든 오픈소스의 저작권 고지문 및 라이선스 전문 포함
   - 소스코드 패키지: GPL 컴포넌트의 수정된 소스코드 및 빌드 스크립트 포함

4. 검토 및 승인
   - 오픈소스 프로그램 매니저가 산출물의 완전성을 최종 검토한다.
   - 라이선스 충돌 또는 불확실한 사항은 법무 담당에게 에스컬레이션한다.

5. 배포
   - 컴플라이언스 산출물을 소프트웨어와 함께 제공한다.
   - 산출물 사본을 보관한다 (§3.4.1 참조).

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
• 관련 템플릿: 오픈소스 프로세스 템플릿

2.4 - §3.4 컴플라이언스 산출물

2.4.1 - §3.4.1 산출물

1. 조항 개요

라이선스 의무를 이행하려면 실제로 고지문, 소스코드 패키지 등 컴플라이언스 산출물을 준비하여 소프트웨어와 함께 제공해야 한다. §3.4.1은 식별된 라이선스가 요구하는 컴플라이언스 산출물을 준비하고 공급 소프트웨어와 함께 배포하는 절차, 그리고 산출물 사본을 일정 기간 보관하는 절차를 수립하도록 요구한다. 이 조항은 §3.3 검토·승인 단계의 결과물을 실제 배포와 보관으로 연결하는 단계다.

2. 해야 할 활동

• 라이선스별로 요구되는 컴플라이언스 산출물(NOTICES 파일, 소스코드 패키지, written offer 등)의 유형을 정의한다.
• 산출물을 준비하여 공급 소프트웨어와 함께 제공하는 절차를 문서화한다.
• 배포된 산출물의 사본을 일정 기간 보관하는 절차를 수립하고 문서화한다.
• 산출물 보관 기간을 정책에 명시한다 (업계 관행: 마지막 배포 후 최소 3년).
• 보관 절차가 올바르게 수행되었음을 입증하는 기록을 유지한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.4.1.1 컴플라이언스 산출물 준비 및 배포 절차

준수 방법

라이선스 의무에 따른 컴플라이언스 산출물을 준비하고 공급 소프트웨어와 함께 제공하는 절차를 문서화해야 한다. 이 절차 문서가 입증자료 3.4.1.1이다. 절차에는 ①산출물 유형 결정, ②산출물 작성, ③검토 및 승인, ④소프트웨어와 함께 제공, ⑤기록 보관의 단계가 포함되어야 한다.

컴플라이언스 산출물의 유형은 배포하는 라이선스에 따라 달라진다. 일반적으로 고지 의무 라이선스(MIT, Apache-2.0 등)는 NOTICES 파일이 필요하고, GPL 계열 라이선스는 소스코드 패키지 또는 written offer가 필요하다. 산출물 형태는 제품에 동봉, 패키지에 포함, 웹사이트 게시, 요청 시 제공 등 다양한 방식으로 제공할 수 있다.

고려사항

• 산출물 유형 정의: 라이선스별로 어떤 산출물이 필요한지 미리 정의하여 배포 준비 시 빠르게 대응할 수 있도록 한다.
• NOTICES 파일 품질: 모든 오픈소스 컴포넌트의 저작권 고지문과 라이선스 전문이 누락 없이 포함되었는지 검토한다.
• 소스코드 패키지: GPL 컴포넌트의 경우 수정된 소스코드와 빌드 스크립트를 포함한 완전한 소스코드 패키지를 준비한다.
• 제공 방식: 산출물을 소프트웨어에 동봉할지, 웹사이트에 게시할지, 요청 시 제공할지를 라이선스 요건에 맞게 결정한다.
• 최종 검토: 배포 전 오픈소스 프로그램 매니저가 산출물의 완전성을 최종 확인한다.

샘플

아래는 컴플라이언스 산출물 준비 및 배포 절차 개요 샘플이다.

[컴플라이언스 산출물 준비 및 배포 절차]

1. 산출물 유형 결정
   - SBOM을 기준으로 포함된 라이선스 목록을 확인한다.
   - 라이선스별 의무에 따라 필요한 산출물을 결정한다:
     · 고지 의무 라이선스 → NOTICES 파일
     · GPL-2.0/3.0 → 소스코드 패키지 또는 written offer
     · LGPL → 동적 링크 구조 증명 문서 또는 소스코드

2. 산출물 작성
   - NOTICES 파일: 자동화 도구(FOSSology, ORT 등)로 생성하거나 수동 작성.
     컴포넌트명, 버전, 라이선스 전문, 저작권 고지문 포함.
   - 소스코드 패키지: GPL 컴포넌트의 수정된 소스코드와 빌드 스크립트 포함.

3. 검토 및 승인
   - 오픈소스 프로그램 매니저가 산출물의 완전성과 정확성을 검토한다.
   - 불완전한 항목은 수정 후 재검토한다.

4. 소프트웨어와 함께 제공
   - 제품 패키지에 동봉하거나 설치 시 표시되는 화면에 포함한다.
   - 웹사이트 게시 또는 요청 시 제공하는 경우 해당 URL 또는 절차를 명시한다.
   - written offer를 사용하는 경우 3년간 유효한 서면 약정을 포함한다.

3.4.1.2 컴플라이언스 산출물 보관 절차

준수 방법

배포된 공급 소프트웨어의 컴플라이언스 산출물 사본을 일정 기간 보관하는 절차를 문서화하고, 그 절차가 실제로 이행되었음을 입증하는 기록을 유지해야 한다. 이 절차 문서와 보관 기록이 입증자료 3.4.1.2다.

보관 기간은 해당 소프트웨어의 마지막 배포 시점으로부터 합리적인 기간이어야 하며, 업계 관행상 최소 3년을 권장한다. 보관 대상은 NOTICES 파일, 소스코드 패키지, written offer 사본, SBOM 등 배포 시 제공한 모든 산출물이다. 소프트웨어 버전별로 산출물을 체계적으로 관리하여 특정 버전의 산출물을 즉시 검색·제출할 수 있어야 한다.

고려사항

• 보관 기간 명시: 정책 또는 절차 문서에 보관 기간(최소 3년)을 명시한다.
• 버전별 관리: 소프트웨어 릴리스 버전과 산출물을 연결하여 버전별로 보관한다.
• 보관 위치: 사내 파일 서버, 문서 관리 시스템, 소스코드 저장소 등 접근 가능하고 안전한 위치에 보관한다.
• 보관 기록 유지: 어떤 버전의 산출물을 언제 보관했는지 이력을 기록한다.
• 접근성: 감사 또는 외부 문의 발생 시 즉시 산출물을 제출할 수 있도록 검색 가능한 형태로 보관한다.

샘플

아래는 컴플라이언스 산출물 보관 기록부 샘플이다.

| 소프트웨어명 | 버전 | 배포일 | 산출물 유형 | 보관 위치 | 보관 기한 | 담당자 |
|-------------|------|--------|------------|-----------|-----------|--------|
| MyProduct | v1.0.0 | 2024-03-01 | NOTICES 파일, GPL 소스코드 패키지 | /archive/myproduct/v1.0.0/ | 2027-03-01 | 홍길동 |
| MyProduct | v1.1.0 | 2024-09-15 | NOTICES 파일 | /archive/myproduct/v1.1.0/ | 2027-09-15 | 홍길동 |
| FirmwareX | v2.3.0 | 2025-01-10 | NOTICES 파일, LGPL 소스코드 패키지, SBOM | /archive/firmwarex/v2.3.0/ | 2028-01-10 | 이인프라 |

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
• 관련 템플릿: 오픈소스 프로세스 템플릿

2.5 - §3.5 커뮤니티 참여

2.5.1 - §3.5.1 기여

1. 조항 개요

많은 기업이 외부 오픈소스 프로젝트에 코드·문서·버그 리포트 등을 기여한다. 기여 활동은 커뮤니티 신뢰를 높이고 기술 영향력을 확대하지만, 회사 코드나 특허가 의도치 않게 공개될 수 있는 리스크도 수반한다. §3.5.1은 조직이 외부 오픈소스 기여를 허용하는 경우, 기여를 규율하는 문서화된 정책과 절차를 수립하고 프로그램 참여자가 그 존재를 인식하도록 할 것을 요구한다. 이 조항은 기여를 허용하지 않는 조직에는 적용되지 않으나, 허용하는 경우 세 가지 입증자료를 모두 갖추어야 한다.

2. 해야 할 활동

• 조직의 외부 오픈소스 기여 허용 여부를 결정하고 정책에 명시한다.
• 기여를 허용하는 경우 기여 유형(코드, 문서, 버그 리포트 등), 승인 절차, 저작권·특허 처리 방침 등을 포함한 기여 정책을 문서화한다.
• 기여 제안부터 승인·제출·기록까지 실제 기여를 관리하는 절차를 수립하고 문서화한다.
• 기여 정책의 존재를 프로그램 참여자에게 전파하는 절차를 마련한다.
• 기여 이력을 기록하고 보관한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.5.1.1 오픈소스 기여 정책

준수 방법

외부 오픈소스 프로젝트에 기여하는 행위를 규율하는 정책을 문서화해야 한다. 이 정책 문서가 입증자료 3.5.1.1이다. 기여 정책에는 ①기여 허용 범위(코드, 문서, 버그 리포트 등), ②기여 승인 절차, ③저작권 처리(회사 소유 vs. 개인 소유), ④특허 처리 방침, ⑤CLA(Contributor License Agreement) 서명 기준, ⑥기여 금지 항목(영업 비밀, 미공개 특허 등)이 포함되어야 한다.

정책은 오픈소스 정책 문서의 별도 섹션으로 포함하거나 독립된 기여 정책 문서로 관리할 수 있다. 기여를 완전히 금지하는 조직도 “기여를 허용하지 않는다"는 정책을 명시적으로 문서화하는 것이 바람직하다.

고려사항

• 기여 범위 정의: 허용되는 기여 유형(버그 수정, 기능 추가, 문서 작성 등)을 구체적으로 열거한다.
• 저작권 귀속: 기여물의 저작권이 회사에 귀속되는지, 개인에게 귀속되는지 정책에 명시한다.
• 특허 리스크 관리: 기여물에 회사 특허가 포함될 수 있는 경우 법무 검토를 의무화한다.
• CLA 처리: 외부 프로젝트가 CLA를 요구하는 경우 서명 권한자와 절차를 정책에 명시한다.
• 기여 금지 항목: 영업 비밀, 미등록 특허, 제3자 지식재산이 포함된 코드는 기여를 금지한다.

샘플

아래는 오픈소스 기여 정책 핵심 항목 샘플이다.

## 오픈소스 기여 정책

### 기여 허용 범위
회사는 임직원이 업무 목적으로 외부 오픈소스 프로젝트에 기여하는 것을 허용한다.
허용되는 기여 유형은 다음과 같다:
- 버그 수정 및 패치 제출
- 문서 개선
- 기능 추가 (사전 승인 필요)
- 버그 리포트 및 이슈 제기

### 저작권 및 특허
- 업무 시간에 회사 자원을 사용하여 작성한 기여물의 저작권은 회사에 귀속된다.
- 기여물에 회사 특허가 포함될 가능성이 있는 경우 법무 담당의 사전 검토를 받아야 한다.

### 기여 금지 항목
다음 항목이 포함된 코드는 기여할 수 없다:
- 영업 비밀 또는 기밀 정보
- 제3자의 지식재산
- 회사의 미공개 특허 기술

### CLA (Contributor License Agreement)
외부 프로젝트가 CLA 서명을 요구하는 경우 오픈소스 프로그램 매니저에게
사전 보고하고 승인을 받아야 한다.

3.5.1.2 오픈소스 기여 관리 절차

준수 방법

실제 기여 활동을 어떻게 처리하는지 단계별로 정의한 절차를 문서화해야 한다. 이 절차 문서가 입증자료 3.5.1.2다. 절차에는 ①기여 제안 및 승인 요청, ②법무·특허 검토(필요 시), ③승인, ④기여 제출, ⑤기여 이력 기록의 단계가 포함되어야 한다. 기여 규모나 유형에 따라 간소화된 절차(소규모 버그 수정)와 정식 절차(대규모 기능 추가)를 구분하여 운영할 수 있다.

고려사항

• 기여 규모별 절차 구분: 소규모 버그 수정은 간소 승인, 대규모 기능 추가는 정식 법무 검토를 거치도록 규모별 기준을 설정한다.
• 기여 기록 보관: 기여 제안서, 승인 기록, 제출 링크(PR/커밋 URL)를 기록하고 보관한다.
• 에스컬레이션: 특허 또는 저작권 이슈가 발생하는 경우 법무 담당에게 에스컬레이션하는 경로를 절차에 포함한다.

샘플

아래는 오픈소스 기여 관리 절차 개요 샘플이다.

[오픈소스 기여 관리 절차]

1. 기여 제안
   - 임직원이 기여하고자 하는 내용(프로젝트명, 기여 유형, 내용 요약)을
     오픈소스 프로그램 매니저에게 보고한다.

2. 검토 및 승인
   - 소규모 기여 (버그 수정, 문서 개선):
     오픈소스 프로그램 매니저가 정책 적합성을 확인 후 승인한다.
   - 대규모 기여 (기능 추가, 핵심 모듈 기여):
     법무 담당의 특허·저작권 검토 후 오픈소스 프로그램 매니저가 최종 승인한다.

3. CLA 처리 (해당 시)
   - 외부 프로젝트가 CLA를 요구하는 경우 승인된 CLA 서명 양식에 따라 처리한다.

4. 기여 제출
   - 승인된 내용에 한정하여 기여를 제출한다.
   - 회사 이메일 또는 회사가 승인한 계정으로 기여한다.

5. 기여 기록
   - 기여 내용, 승인자, 제출일, 기여 URL(PR/커밋 링크)을 기록하고 보관한다.

3.5.1.3 기여 정책 인식 절차

준수 방법

모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식할 수 있도록 전파하는 절차를 문서화해야 한다. 이 절차 문서가 입증자료 3.5.1.3이다. §3.1.1.2의 오픈소스 정책 전파 절차에 기여 정책을 포함하는 방식으로 통합 관리할 수 있다.

전파 방법은 신규 입사자 온보딩 시 기여 정책 안내, 사내 위키 게시, 이메일 공지 등을 조합하는 것이 효과적이다. 전파 사실을 증명하기 위해 공지 이력, 교육 이수 기록 등을 보관한다.

고려사항

• 온보딩 포함: 신규 입사자 온보딩 과정에 기여 정책 안내를 필수 항목으로 포함한다.
• 정책 갱신 시 재전파: 기여 정책이 변경된 경우 프로그램 참여자에게 즉시 공지한다.
• 증거 보관: 공지 발송 이력, 교육 이수 확인서 등을 최소 3년간 보관한다.
• 정책 접근성: 기여 정책을 사내 포털 또는 위키에 항시 게시하여 언제든 확인할 수 있도록 한다.

샘플

아래는 기여 정책 전파 공지 이메일 샘플이다.

제목: [오픈소스] 오픈소스 기여 정책 안내

수신: 전체 개발 관련 임직원
발신: 오픈소스 프로그램 매니저

안녕하세요.

당사 오픈소스 기여 정책을 안내드립니다.
외부 오픈소스 프로젝트에 기여하는 업무에 관여하는 모든 임직원은
아래 링크의 정책 문서를 확인하고 숙지해 주시기 바랍니다.

- 정책 문서: [사내 포털 링크]
- 주요 내용: 기여 허용 범위, 승인 절차, 저작권·특허 처리 방침
- 정책 버전: v1.0 (시행일: YYYY-MM-DD)

기여를 희망하는 경우 반드시 사전 승인 절차를 거쳐 주십시오.
문의: 오픈소스 프로그램 매니저 (oss@company.com)

감사합니다.
오픈소스 프로그램 매니저

5. 참고

• 관련 가이드: 기업 오픈소스 관리 가이드 — 2. 정책 §(9) 오픈소스 기여
• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스 §4 오픈소스 기여 프로세스
• 관련 템플릿: 오픈소스 정책 템플릿 — §3 오픈소스 기여

2.6 - §3.6 규격 준수

2.6.1 - §3.6.1 적합성

1. 조항 개요

ISO/IEC 5230 인증을 받으려면 §3.1.4에서 정의한 프로그램이 이 규격의 모든 요구사항을 충족한다는 사실을 문서로 확인해야 한다. §3.6.1은 앞서 §3.1부터 §3.5까지의 모든 조항을 충족하였음을 공식적으로 선언하는 단계다. 이 조항은 규격 준수를 완결 짓는 최종 확인 절차로, 프로그램이 ISO/IEC 5230:2020 버전 2.1의 모든 요구사항을 만족한다는 조직의 공식 확인이 필요하다.

2. 해야 할 활동

• §3.1부터 §3.5까지 모든 조항의 입증자료(24개 항목)가 갖추어졌는지 자체 점검한다.
• 프로그램이 §3.1.4에서 정의한 적용 범위 내에서 ISO/IEC 5230의 모든 요구사항을 충족함을 확인하는 문서를 작성한다.
• 확인 문서에 검토자, 승인자, 확인 날짜를 기록한다.
• 자가 인증, 독립 평가, 또는 제3자 인증 중 적합한 인증 방법을 선택하여 진행한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.6.1.1 규격 준수 확인 문서

준수 방법

§3.1.4에서 정의한 프로그램의 적용 범위 내에서 ISO/IEC 5230:2020의 모든 요구사항을 충족한다는 사실을 확인하는 문서를 작성해야 한다. 이 문서가 입증자료 3.6.1.1이다. 이 문서는 24개 입증자료 항목 각각에 대해 준수 여부를 확인하는 체크리스트 형태, 또는 전반적인 준수 선언문 형태로 작성할 수 있다.

작성 전 이 가이드의 전체 조항 체크리스트를 활용하여 모든 입증자료가 갖추어졌는지 점검한다. 문서에는 확인 대상 프로그램의 적용 범위, 확인 기준 규격 버전(ISO/IEC 5230:2020 버전 2.1), 확인 날짜, 검토자 및 승인자가 반드시 포함되어야 한다.

고려사항

• 자체 점검 선행: 문서 작성 전 24개 입증자료 항목 전체를 자체 점검하여 누락 항목이 없는지 확인한다.
• 규격 버전 명시: 준수를 확인한 규격 버전(ISO/IEC 5230:2020 버전 2.1)을 문서에 명시한다.
• 승인 절차: 오픈소스 프로그램 매니저의 검토와 경영진 또는 OSRB의 승인을 거쳐 문서를 공식화한다.
• 갱신 주기: 규격 새 버전 발행 후 18개월 이내에 최신 버전 기준으로 재확인해야 한다 (§3.6.2 참조).

샘플

아래는 ISO/IEC 5230 규격 준수 확인 문서 샘플이다.

[ISO/IEC 5230 규격 준수 확인서]

프로그램 명칭: [회사명] 오픈소스 컴플라이언스 프로그램
적용 범위: [§3.1.4에서 정의한 범위 기재]
준수 확인 규격: ISO/IEC 5230:2020 (버전 2.1)
확인 날짜: YYYY-MM-DD

본 문서는 위 프로그램이 ISO/IEC 5230:2020의 §3.1부터 §3.6까지
모든 요구사항을 충족함을 확인한다.

준수 확인 항목 요약:
- §3.1 프로그램 기반 (5개 조항, 8개 입증자료): 충족 ✓
- §3.2 관련 업무 (2개 조항, 7개 입증자료): 충족 ✓
- §3.3 콘텐츠 검토 및 승인 (2개 조항, 3개 입증자료): 충족 ✓
- §3.4 컴플라이언스 산출물 (1개 조항, 2개 입증자료): 충족 ✓
- §3.5 커뮤니티 참여 (1개 조항, 3개 입증자료): 충족 ✓
- §3.6 규격 준수 (2개 조항, 2개 입증자료): 충족 ✓

검토자: [오픈소스 프로그램 매니저 이름]
승인자: [경영진 또는 OSRB 책임자 이름]
승인일: YYYY-MM-DD

5. 참고

• ISO/IEC 5230 자가 인증: https://certification.openchainproject.org/
• 전체 조항 체크리스트: ISO/IEC 5230 준수 가이드

2.6.2 - §3.6.2 지속 기간

1. 조항 개요

ISO/IEC 5230 인증은 한 번 취득으로 영구히 유효하지 않다. 규격의 새 버전이 발행되면 이전 버전 기준으로 인증을 받은 프로그램은 새 버전 발행 후 18개월까지만 적합성이 유지된다. §3.6.2는 프로그램이 적합성 인증을 취득한 날로부터 최근 18개월 이내에 규격의 모든 요구사항을 충족하고 있음을 확인하는 문서를 유지하도록 요구한다. 이 조항은 오픈소스 컴플라이언스 프로그램이 형식적 인증에 그치지 않고 지속적으로 운영되는지 확인하는 장치다.

2. 해야 할 활동

• 적합성 인증 취득 날짜를 기록하고 관리한다.
• 인증 취득 후 최근 18개월 이내에 규격의 모든 요구사항을 충족하고 있음을 재확인하고 문서화한다.
• 새로운 버전의 규격이 발행된 경우 18개월 이내에 최신 버전 기준으로 프로그램을 갱신하고 재확인한다.
• 정기적인 내부 감사를 통해 프로그램의 지속적 준수 여부를 점검한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

3.6.2.1 18개월 이내 요구사항 충족 확인 문서

준수 방법

적합성 인증 취득 후 18개월 이내에 프로그램이 규격의 모든 요구사항을 여전히 충족하고 있음을 확인하는 문서를 유지해야 한다. 이 문서가 입증자료 3.6.2.1이다. 가장 간단한 방법은 §3.6.1.1의 규격 준수 확인 문서를 정기적으로(최소 연 1회) 재검토하고 갱신하는 것이다. 갱신 시마다 검토 날짜와 검토자를 기록하여 최근 18개월 이내에 검토가 이루어졌음을 증명할 수 있도록 한다.

새로운 버전의 ISO/IEC 5230이 발행된 경우 18개월의 유예 기간 내에 최신 버전 기준으로 프로그램을 갱신하고 재확인 문서를 작성한다. 유예 기간을 초과하면 인증 효력이 만료되므로, 규격 개정 동향을 모니터링하고 적시에 대응하는 것이 중요하다.

고려사항

• 정기 재확인 일정 수립: 최소 연 1회 정기 내부 감사를 통해 모든 입증자료 항목의 유효성을 재확인하고 문서화한다.
• 규격 개정 모니터링: OpenChain 프로젝트의 규격 개정 공지를 정기적으로 확인하고, 새 버전 발행 시 18개월 이내에 대응 계획을 수립한다.
• 인증 만료 관리: 인증 취득일과 유효 기간(18개월)을 캘린더 또는 관리 시스템에 등록하여 만료 전 갱신 알림을 받도록 설정한다.
• 변경 사항 반영: 조직 구조, 제품 포트폴리오, 프로세스 변경 발생 시 즉시 프로그램에 반영하고 재확인 문서를 갱신한다.

샘플

아래는 ISO/IEC 5230 규격 준수 정기 재확인 기록 샘플이다.

[ISO/IEC 5230 규격 준수 정기 재확인 기록]

프로그램 명칭: [회사명] 오픈소스 컴플라이언스 프로그램
최초 인증 취득일: YYYY-MM-DD
준수 확인 규격: ISO/IEC 5230:2020 (버전 2.1)

| 재확인 날짜 | 확인 결과 | 변경 사항 | 검토자 | 비고 |
|------------|-----------|-----------|--------|------|
| 2025-01-10 | 전체 충족 | 담당자 변경 반영 (§3.2.2.1 갱신) | 홍길동 | - |
| 2026-01-08 | 전체 충족 | 없음 | 홍길동 | 다음 재확인 예정: 2027-01-08 |

다음 재확인 예정일: YYYY-MM-DD (최근 재확인일로부터 12개월 이내)
18개월 유효 기한: YYYY-MM-DD (최근 재확인일로부터 18개월)

아래는 규격 새 버전 발행 시 대응 체크리스트 샘플이다.

[ISO/IEC 5230 새 버전 발행 대응 체크리스트]

새 버전 발행일: YYYY-MM-DD
대응 기한 (18개월): YYYY-MM-DD

□ 새 버전과 현행 버전의 요구사항 변경 사항 파악
□ 변경된 요구사항에 따른 프로그램 갱신 계획 수립
□ 갱신 작업 완료 및 새 버전 기준 입증자료 정비
□ 새 버전 기준 규격 준수 확인 문서 작성 및 승인
□ 자가 인증 또는 인증 갱신 절차 진행

5. 참고

• OpenChain 규격 최신 버전 확인: https://www.openchainproject.org/license-compliance
• 자가 인증 갱신: https://certification.openchainproject.org/
• §3.6.1 적합성: 이전 조항 바로가기

3 - ISO/IEC 18974 준수 가이드

이 가이드는 ISO/IEC 18974(OpenChain Security Assurance)의 각 요구사항 조항을 하나씩 풀어서 설명한다. 각 조항이 요구하는 입증자료가 무엇인지, 어떻게 준수할 수 있는지, 바로 활용할 수 있는 샘플 문서는 무엇인지 안내한다.

Author : OpenChain Korea Work Group / CC BY 4.0

대상 독자

• 오픈소스 보안 보증 체계를 처음 수립하는 기업의 보안 담당자 및 오픈소스 프로그램 매니저
• DevSecOps 환경에서 오픈소스 취약점 관리 프로세스를 구축하는 엔지니어
• ISO/IEC 5230 인증 취득 후 ISO/IEC 18974 추가 인증을 준비하는 기업 담당자

ISO/IEC 5230과의 관계

이 가이드의 활용 방법

전체 조항 체크리스트

ISO/IEC 18974는 총 11개 조항, 25개 입증자료 항목으로 구성된다. ★ 표시는 ISO/IEC 5230 대비 추가되거나 보안 관점으로 변경된 항목이다.

§4.1 프로그램 기반

§4.2 관련 업무

§4.3 콘텐츠 검토 및 승인

§4.4 규격 준수

합계: 11개 조항 / 25개 입증자료 항목

ISO/IEC 18974 인증 절차

ISO/IEC 18974 준수 여부를 공식적으로 인정받는 방법은 세 가지다.

3.1 - §4.1 프로그램 기반

3.1.1 - §4.1.1 정책

1. 조항 개요

§4.1.1은 ISO/IEC 5230 §3.1.1(라이선스 컴플라이언스 정책)과 대응하는 조항이지만, 초점이 보안 보증으로 전환된다. 오픈소스 컴포넌트의 알려진 취약점과 새로 발견되는 취약점을 체계적으로 관리하는 정책이 문서화되어 있어야 하며, 그 정책이 조직 내부에 전파되어야 한다. ISO/IEC 5230 §3.1.1과의 핵심 차이점은 정책과 전파 절차 자체에 대한 정기 검토 프로세스를 요구한다는 점이다. 정책을 수립하는 것에 그치지 않고, 정책이 항상 유효하고 최신 상태를 유지하도록 검토 체계를 갖추어야 한다.

2. 해야 할 활동

• 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을 관리하는 정책을 문서화하고 공식화한다.
• 정책에 취약점 탐지·평가·대응·통보 원칙과 CVD(Coordinated Vulnerability Disclosure) 방침을 포함한다.
• 프로그램 참여자(개발자·보안 담당·법무·IT 등)에게 정책을 전파하는 절차를 수립하고 문서화한다.
• 정책과 전파 절차 자체를 정기적으로 검토하여 최신 상태를 유지하는 검토 프로세스를 정책 내에 명시한다.
• 검토 완료 일자, 검토자, 변경 이력을 문서에 기록한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

4.1.1.1 문서화된 보안 보증 정책

준수 방법

ISO/IEC 5230의 오픈소스 정책을 이미 보유한 경우, 해당 정책에 보안 보증 관련 섹션을 추가하거나 별도 보안 보증 정책 문서를 작성하는 두 가지 방법을 선택할 수 있다. 두 방법 모두 입증자료 4.1.1.1을 충족한다.

정책에는 ①보안 취약점 식별·추적·대응 원칙, ②CVSS 기반 위험 평가 및 조치 기한 기준, ③CVD(Coordinated Vulnerability Disclosure) 방침, ④배포 후 모니터링 원칙, ⑤정기 검토 주기와 검토자가 포함되어야 한다. ISO/IEC 5230 §3.1.1.1과의 핵심 차이는 정기 검토 프로세스를 정책 문서 안에 명시해야 한다는 점이다.

고려사항

• 5230 정책과 통합: 기존 ISO/IEC 5230 정책의 §5 보안 취약점 대응 섹션을 확장하는 방식으로 통합 관리할 수 있다.
• 검토 주기 명시: 최소 연 1회 정기 검토를 수행하며, 새로운 위협 환경이나 법적 요건 변화 시 즉시 검토한다는 조항을 포함한다.
• CVSS 기준 채택: 취약점 심각도 평가에 CVSS(Common Vulnerability Scoring System)를 활용하고 조치 기한(예: Critical 7일, High 30일)을 정책에 명시한다.
• CVD 방침 포함: 외부에서 취약점이 보고되었을 때 비공개로 협력하여 해결한 후 공개하는 CVD 절차를 정책에 포함한다.
• 버전 관리: 정책 버전 번호, 변경 이력, 검토 완료 날짜를 기록한다.

샘플

아래는 오픈소스 정책의 보안 보증 섹션 샘플이다.

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

### 5.1 목적
회사는 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 보안 취약점을
체계적으로 식별하고 대응하여 보안 위험을 최소화한다.

### 5.2 취약점 대응 원칙
알려진 취약점(CVE)에 대한 조치 기한 기준은 다음과 같다:
- Critical (CVSS 9.0~10.0): 7일 이내 패치 또는 완화 조치
- High (CVSS 7.0~8.9): 30일 이내 패치 또는 완화 조치
- Medium (CVSS 4.0~6.9): 90일 이내 패치 계획 수립
- Low (CVSS 0.1~3.9): 다음 정기 업데이트 시 처리

### 5.3 CVD(Coordinated Vulnerability Disclosure) 방침
외부에서 취약점이 보고된 경우 보고자와 협력하여 해결 후 공개한다.
취약점 보고 채널: security@company.com

### 5.4 정책 검토
이 정책과 전파 절차는 최소 연 1회 검토하며 최신 상태를 유지한다.
검토 완료 날짜와 검토자를 문서에 기록한다.

4.1.1.2 보안 보증 정책 인식 방법 문서화

준수 방법

ISO/IEC 5230의 정책 전파 절차(§3.1.1.2)와 동일한 방식으로 보안 보증 정책을 프로그램 참여자에게 전파하는 절차를 문서화해야 한다. §4.1.1의 추가 요건은 전파 절차 자체도 정기적으로 검토하여 유효성을 유지해야 한다는 점이다. 기존 5230 정책 전파 절차에 보안 보증 정책 내용을 추가하거나, 별도 보안 정책 전파 절차를 수립하는 방식으로 대응할 수 있다.

고려사항

• 5230 절차 재활용: 기존 오픈소스 정책 전파 채널(온보딩, 사내 위키, 이메일)에 보안 보증 정책을 추가하는 방식으로 효율적으로 대응한다.
• 전파 절차 검토: 전파 절차 문서에 검토 주기(연 1회)와 검토자를 명시하여 절차 자체의 유효성을 관리한다.
• 증거 보관: 공지 이력, 교육 이수 기록을 최소 3년간 보관한다.

샘플

제목: [보안] 오픈소스 보안 보증 정책 안내 및 숙지 요청

수신: 전체 개발/배포/보안 관련 임직원
발신: 오픈소스 프로그램 매니저

안녕하세요.

당사 오픈소스 보안 보증 정책이 제정(또는 개정)되었습니다.
아래 링크의 정책 문서를 확인하고 숙지해 주시기 바랍니다.

- 정책 문서: [사내 포털 링크]
- 주요 내용: 취약점 대응 원칙, CVSS 기반 조치 기한, CVD 방침
- 정책 버전: v1.0 (시행일: YYYY-MM-DD) / 차기 검토 예정: YYYY-MM-DD

문의: 오픈소스 프로그램 매니저 (oss@company.com)

5. 참고

• 대응 ISO/IEC 5230 조항: §3.1.1 정책
• 관련 가이드: 기업 오픈소스 관리 가이드 — 2. 정책
• 관련 템플릿: 오픈소스 정책 템플릿

3.1.2 - §4.1.2 역량

1. 조항 개요

§4.1.2는 ISO/IEC 5230 §3.1.2(역량)와 기본 구조는 동일하지만, 입증자료 항목이 3건 더 많다. 5230이 역할 목록·역량 정의·역량 평가 증거 3가지를 요구하는 반면, 18974는 여기에 참여자 목록 및 역할 매핑(4.1.2.3), 주기적 검토 및 프로세스 변경 증거(4.1.2.5), 내부 모범 사례와의 일치 검증(4.1.2.6) 을 추가로 요구한다. 이 세 가지 추가 항목은 역량 체계가 형식에 그치지 않고 실제로 최신 상태를 유지하며 업계 표준과 정합성을 갖추고 있음을 입증하도록 요구한다.

2. 해야 할 활동

• 프로그램 역할별 책임 목록을 작성한다 (5230과 동일).
• 각 역할에 필요한 역량을 정의하고 문서화한다 (5230과 동일).
• 참여자 이름과 각자의 역할을 매핑한 목록을 별도로 작성한다 (18974 추가).
• 각 참여자의 역량을 평가하고 기록한다 (5230과 동일).
• 주기적으로 역량 체계를 검토하고 프로세스 변경 사항을 기록한다 (18974 추가).
• 역량 체계가 회사 내부 모범 사례와 일치하는지 확인하고 담당자를 지정한다 (18974 추가).

3. 요구사항 및 입증자료

★ = ISO/IEC 5230 §3.1.2 대비 추가 항목

4. 입증자료별 준수 방법 및 샘플

4.1.2.1 역할과 책임 목록 문서

ISO/IEC 5230 §3.1.2.1과 동일하다. 보안 보증 관점에서 보안 담당(DevSecOps, 취약점 분석)의 역할을 명확히 포함해야 한다. 작성 방법은 §3.1.2.1 역할과 책임 목록 문서를 참고한다.

4.1.2.2 역할별 필요 역량 문서

ISO/IEC 5230 §3.1.2.2와 동일하다. 보안 담당 역할에 CVSS 점수 해석, 취약점 분석 도구(OSV-SCALIBR, Dependency-Track 등) 운용, DevSecOps 이해 역량을 포함해야 한다. 작성 방법은 §3.1.2.2 역할별 필요 역량 문서를 참고한다.

4.1.2.3 참여자 목록 및 역할 ★

준수 방법

4.1.2.1의 역할 목록과 달리, 이 항목은 실제 인원의 이름과 그들이 담당하는 역할을 매핑한 목록을 요구한다. 조직도 상의 역할이 아니라 현재 프로그램에 참여하는 실제 담당자가 누구인지를 명확히 하는 것이 목적이다. 인사 변동 시 즉시 갱신해야 한다.

고려사항

• 이름 또는 직무명: 개인 이름 대신 직무명을 사용해도 무방하나, 특정인을 식별할 수 있는 수준이어야 한다.
• 겸임 명시: 여러 역할을 겸임하는 경우 모든 역할을 기재한다.
• 갱신 즉시성: 담당자 변경 즉시 문서를 갱신하고 버전을 업데이트한다.

샘플

| 이름 | 역할 | 연락처 | 지정일 |
|------|------|--------|--------|
| 홍길동 | 오픈소스 프로그램 매니저 | oss@company.com | 2025-01-01 |
| 김철수 | 보안 담당 (DevSecOps) | security@company.com | 2025-01-01 |
| 이영희 | 법무 담당 | legal@company.com | 2025-01-01 |
| 박인프라 | IT 담당 | it@company.com | 2025-03-15 |

4.1.2.4 역량 평가 증거

ISO/IEC 5230 §3.1.2.3과 동일하다. 작성 방법은 §3.1.2.3 역량 평가 증거를 참고한다.

4.1.2.5 주기적 검토 및 프로세스 변경 증거 ★

준수 방법

역량 체계(역할 정의, 역량 기준, 평가 방법)를 주기적으로 검토하고, 검토 과정에서 발생한 변경 사항을 기록해야 한다. 새로운 보안 도구 도입, 조직 구조 변경, 취약점 대응 프로세스 개선 등이 역량 체계에 반영되었는지 확인하는 것이 핵심이다. 검토 기록 자체가 입증자료 4.1.2.5다.

고려사항

• 검토 주기: 최소 연 1회 정기 검토를 실시하고, 조직·프로세스 변경 시 즉시 검토한다.
• 변경 이력 기록: 변경 내용, 변경 이유, 변경 날짜, 변경자를 기록한다.
• 검토 증거 형식: 검토 회의록, 검토 완료 확인서, 변경 이력 로그 등이 증거로 활용 가능하다.

샘플

[역량 체계 정기 검토 기록]

| 검토 날짜 | 검토 내용 | 변경 사항 | 검토자 |
|----------|-----------|-----------|--------|
| 2025-01-10 | 전체 역할·역량 검토 | 보안 담당 역량에 CVSS v4.0 해석 항목 추가 | 홍길동 |
| 2026-01-08 | 전체 역할·역량 검토 | Dependency-Track 운용 역량 IT 담당에 추가 | 홍길동 |

4.1.2.6 내부 모범 사례 일치 검증 ★

준수 방법

역량 정의 및 평가 프로세스가 회사 내부 모범 사례(HR 정책, 기술 교육 기준 등)와 정합성을 유지하고 있는지 확인하며, 이를 지속적으로 관리하는 담당자를 지정해야 한다. 역량 체계가 산업 표준이나 내부 지침과 괴리되지 않도록 하는 것이 목적이다.

고려사항

• 담당자 지정: 역량 체계의 최신성과 내부 모범 사례 정합성을 관리하는 책임자를 명시적으로 지정하고 기록한다.
• 모범 사례 기준: 업계 표준(NIST SSDF, ISO 27001 등), 사내 보안 정책, DevSecOps 가이드라인 등을 모범 사례 기준으로 활용할 수 있다.

샘플

[내부 모범 사례 정합성 확인서]

역량 체계 관리 담당자: 홍길동 (오픈소스 프로그램 매니저)
마지막 정합성 검토일: 2026-01-08
참조 모범 사례 기준: 사내 보안 교육 기준 v3.0, NIST SSDF 1.1

검토 결과:
- 보안 담당 역량 기준이 사내 보안 교육 커리큘럼과 일치함 ✓
- 취약점 분석 도구 역량이 최신 도구(Dependency-Track v4.x)를 반영함 ✓
- 다음 정합성 검토 예정일: 2027-01-08

5. 참고

• 대응 ISO/IEC 5230 조항: §3.1.2 역량
• 관련 가이드: 기업 오픈소스 관리 가이드 — 1. 조직
• 관련 템플릿: 오픈소스 정책 템플릿 — Appendix 1. 담당자 현황

3.1.3 - §4.1.3 인식

1. 조항 개요

§4.1.3은 ISO/IEC 5230 §3.1.3(인식)과 입증자료 구조가 동일하다. 프로그램 참여자가 프로그램의 목표, 자신의 기여 방법, 미준수 시 발생하는 영향을 인식하고 있음을 평가하고 기록하도록 요구한다. 5230과의 차이는 인식 평가의 초점이 보안 보증으로 전환된다는 점이다. 참여자는 라이선스 컴플라이언스뿐 아니라 취약점 관리 프로세스, CVD 절차, CVSS 기반 대응 기준을 인식하고 있어야 한다.

2. 해야 할 활동

• 프로그램 참여자가 오픈소스 보안 보증 프로그램의 목표(취약점 탐지·평가· 대응·통보)를 이해하고 있는지 확인한다.
• 각 참여자가 자신의 역할이 보안 보증 체계에 어떻게 기여하는지 인식하고 있는지 평가한다.
• 취약점 대응 프로세스를 미준수할 경우 발생하는 법적·사업적·보안적 영향에 대한 인식을 평가한다.
• 인식 평가 결과를 문서로 기록하고 보관한다.
• 미흡한 참여자에 대해 추가 교육을 실시하고 재평가 결과를 보관한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

4.1.3.1 참여자 인식 평가 증거

준수 방법

ISO/IEC 5230 §3.1.3.1과 기본 방법은 동일하나, 인식 평가 문항이 보안 보증에 초점을 두어야 한다. 세 가지 핵심 인식 항목은 ①보안 보증 프로그램의 목표(취약점 식별·평가·대응·CVD), ②자신의 역할이 보안 체계에 기여하는 방법, ③프로세스 미준수 시 발생하는 보안·법적·사업적 위험이다.

평가 결과를 문서로 기록하고 보관하는 방법은 5230과 동일하다. 최소 연 1회 정기 평가를 실시하고, 신규 참여자는 합류 즉시 초기 평가를 수행한다.

고려사항

• 보안 특화 문항 설계: 취약점 대응 절차, CVSS 기준, CVD 방침 등 보안 보증 고유의 내용을 평가 문항에 포함한다.
• 역할별 심화 평가: 보안 담당자는 기술적 취약점 분석 인식까지 평가하고, 개발자는 안전한 코딩 관행 인식을 함께 평가한다.
• 평가 주기 및 증거 보관: 최소 연 1회, 신규 참여자 합류 즉시 평가를 실시하고 결과를 최소 3년간 보관한다.

샘플

아래는 보안 보증 관점의 정책 인식 확인서 샘플이다.

[오픈소스 보안 보증 정책 인식 확인서]

본인은 다음 사항을 숙지하였음을 확인합니다:

1. 당사 오픈소스 보안 보증 정책의 존재와 해당 문서의 위치
2. 오픈소스 컴포넌트 취약점 탐지·평가·대응·CVD 프로그램의 목표
3. 본인의 역할이 보안 보증 프로그램 운영에 기여하는 방법
4. 취약점 대응 프로세스를 준수하지 않을 경우 발생할 수 있는
   보안 침해, 법적 책임, 사업적 위험

이름: ________________  역할: ________________
서명: ________________  날짜: ________________

5. 참고

• 대응 ISO/IEC 5230 조항: §3.1.3 인식
• 관련 가이드: 기업 오픈소스 관리 가이드 — 5. 교육
• 관련 템플릿: 오픈소스 정책 템플릿 — §6 교육 및 인식 제고

3.1.4 - §4.1.4 프로그램 범위

1. 조항 개요

§4.1.4는 ISO/IEC 5230 §3.1.4(프로그램 범위)에 입증자료 2건이 추가된 조항이다. 5230이 프로그램 적용 범위를 명확히 정의한 진술만 요구하는 반면, 18974는 여기에 프로그램이 달성해야 하는 성과 메트릭(4.1.4.2) 과 지속적 개선을 입증하는 검토·감사 증거(4.1.4.3) 를 추가로 요구한다. 이 두 항목은 보안 보증 프로그램이 정적인 규정 준수에 그치지 않고 측정 가능한 목표를 가지고 지속적으로 개선되는 체계임을 입증하기 위한 것이다.

2. 해야 할 활동

• 프로그램 적용 범위(대상 소프트웨어, 조직 단위, 제외 항목)를 명확히 정의한 문서화된 진술을 작성한다 (5230과 동일).
• 프로그램이 개선하기 위해 달성해야 하는 성과 메트릭을 정의한다 (18974 추가).
• 정기 검토·업데이트·감사를 통해 지속적 개선이 이루어지고 있음을 증명하는 기록을 유지한다 (18974 추가).
• 메트릭 목표 대비 실적을 주기적으로 측정하고 기록한다.
• 개선 필요 사항을 도출하고 후속 조치 이력을 문서화한다.

3. 요구사항 및 입증자료

★ = ISO/IEC 5230 §3.1.4 대비 추가 항목

4. 입증자료별 준수 방법 및 샘플

4.1.4.1 프로그램 적용 범위 진술

ISO/IEC 5230 §3.1.4.1과 동일하다. 작성 방법은 §3.1.4.1 프로그램 적용 범위 진술을 참고한다. 보안 보증 관점에서 “알려진 취약점 및 새로 발견된 취약점 대응"이 적용 범위 내에 포함됨을 명시한다.

4.1.4.2 성과 메트릭 세트 ★

준수 방법

보안 보증 프로그램이 개선하고자 하는 성과 메트릭을 정의하고 문서화해야 한다. 메트릭은 측정 가능하고 현실적이어야 하며, 프로그램의 주요 목표(취약점 탐지율, 대응 시간, SBOM 완전성 등)와 연결되어야 한다. 메트릭 세트 자체가 입증자료 4.1.4.2다.

고려사항

• 측정 가능성: 정성적 서술보다 수치 기반 지표를 설정한다.
• 현실적 목표: 초기에는 달성 가능한 수준으로 목표를 설정하고 점진적으로 높인다.
• 주기적 측정: 메트릭을 최소 분기별로 측정하고 결과를 기록한다.

샘플

[보안 보증 프로그램 성과 메트릭]

| 메트릭 | 측정 방법 | 목표 | 측정 주기 |
|--------|-----------|------|-----------|
| SBOM 완전성 | 배포 소프트웨어 중 SBOM 보유 비율 | 100% | 분기 |
| Critical 취약점 평균 대응 시간 | 탐지일~패치 적용일 | 7일 이하 | 분기 |
| High 취약점 평균 대응 시간 | 탐지일~패치 적용일 | 30일 이하 | 분기 |
| 취약점 재발생률 | 동일 컴포넌트 재취약점 비율 | 10% 이하 | 반기 |
| 신규 참여자 인식 평가 완료율 | 입사 30일 이내 평가 완료 비율 | 100% | 분기 |
| 외부 취약점 문의 응답 준수율 | 14일 이내 응답 완료 비율 | 95% 이상 | 분기 |

4.1.4.3 지속적 개선 증거 ★

준수 방법

정기 검토, 프로세스 업데이트, 내부 감사 등을 통해 보안 보증 프로그램이 실제로 개선되고 있음을 보여주는 기록을 유지해야 한다. 각 검토·감사 시마다 발견된 문제점, 수행된 개선 조치, 개선 결과를 문서화한다. 이 기록 자체가 입증자료 4.1.4.3이다.

고려사항

• 정기 감사 일정: 최소 연 1회 전체 프로그램 감사를 실시하고 결과를 기록한다.
• 개선 이력 추적: 이전 감사에서 제기된 문제가 다음 감사에서 해결되었는지 추적하여 기록한다.
• 메트릭 연계: 4.1.4.2에서 정의한 메트릭의 실적 추이를 개선 증거로 활용한다.

샘플

[보안 보증 프로그램 정기 검토 기록]

검토 날짜: 2026-01-10
검토자: 홍길동 (오픈소스 프로그램 매니저), 김철수 (보안 담당)

메트릭 실적:
- SBOM 완전성: 97% → 100% (목표 달성)
- Critical 취약점 평균 대응 시간: 9일 → 6일 (목표 달성)
- High 취약점 평균 대응 시간: 35일 → 28일 (목표 달성)

발견된 개선 사항:
1. 외부 취약점 문의 응답 준수율 88% → 95% 목표 미달
   조치: 문의 모니터링 담당자 추가 지정 (2026-02-01 완료)
2. 신규 참여자 인식 평가 지연 사례 발생
   조치: 온보딩 체크리스트에 인식 평가 필수 항목 추가 (2026-01-20 완료)

다음 검토 예정일: 2027-01-09

5. 참고

• 대응 ISO/IEC 5230 조항: §3.1.4 프로그램 범위
• 관련 가이드: 기업 오픈소스 관리 가이드 — 2. 정책
• 관련 템플릿: 오픈소스 정책 템플릿 — §1.4 적용 범위

3.1.5 - §4.1.5 표준 관행 구현

1. 조항 개요

§4.1.5는 ISO/IEC 5230에 없는 18974 전용 신규 조항이다. 오픈소스 취약점을 다루는 8가지 표준 처리 방법 각각에 대해 문서화된 절차를 수립하도록 요구한다. 이 조항은 단순히 취약점에 “대응한다"는 선언을 넘어, 위협 식별·탐지·후속 조치· 고객 통보·배포 후 모니터링·지속적 보안 테스트·위험 검증·정보 수출까지 전체 취약점 생명주기를 절차로 명문화할 것을 요구한다. 이 조항은 §4.3.2 보안 보증과 함께 ISO/IEC 18974의 핵심을 이룬다.

2. 해야 할 활동

8가지 방법 각각에 대한 문서화된 절차를 수립한다:

1. 구조적·기술적 위협 식별: 공급 소프트웨어에 영향을 미치는 위협을 식별하는 방법을 정의한다.
2. 알려진 취약점 탐지: 오픈소스 컴포넌트의 알려진 취약점(CVE) 존재를 탐지하는 방법을 정의한다.
3. 취약점 후속 조치: 식별된 취약점에 대해 패치·완화·수용 등 후속 조치를 취하는 방법을 정의한다.
4. 고객 통보: 해당되는 경우 식별된 취약점을 고객에게 전달하는 방법을 정의한다.
5. 배포 후 신규 취약점 분석: 출시 후 새로 공개된 CVE에 대해 기배포 소프트웨어를 분석하는 방법을 정의한다.
6. 지속적 보안 테스트: 출시 전 모든 소프트웨어에 지속적·반복적 보안 테스트를 적용하는 방법을 정의한다.
7. 위험 해결 검증: 식별된 위험이 출시 전에 해결되었는지 검증하는 방법을 정의한다.
8. 위험 정보 수출: 적절한 경우 제3자에게 위험 정보를 내보내는 방법을 정의한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

4.1.5.1 8가지 취약점 처리 방법에 대한 문서화된 절차

준수 방법

8가지 방법 각각에 대해 “어떻게 수행하는가"를 설명하는 절차를 문서화해야 한다. 이 절차들이 모여 입증자료 4.1.5.1을 구성한다. 별도의 8개 문서를 작성할 수도 있고, 하나의 통합 취약점 관리 절차 문서 안에 8개 섹션으로 구성할 수도 있다. 후자가 관리 부담이 적고 일관성을 유지하기 쉬운 방식이다.

방법 1 — 구조적·기술적 위협 식별

공급 소프트웨어에 영향을 미칠 수 있는 구조적(아키텍처 설계, 의존성 구조) 및 기술적(알려진 취약 패턴, 위험 컴포넌트) 위협을 식별하는 방법을 정의한다. 위협 모델링(STRIDE, PASTA 등)을 활용하거나, 정기적으로 의존성 트리를 분석하여 위험 컴포넌트를 식별하는 방식이 일반적이다.

[위협 식별 절차 개요]
- 신규 소프트웨어 아키텍처 설계 시 위협 모델링을 수행한다.
- 분기별로 의존성 트리를 분석하여 EOL(End-of-Life) 컴포넌트,
  유지보수 중단 프로젝트, 높은 의존성 집중도를 가진 컴포넌트를 식별한다.
- 식별된 위협은 위험 레지스트리(Risk Registry)에 등록하고 담당자를 배정한다.

방법 2 — 알려진 취약점 탐지

SBOM을 기반으로 오픈소스 컴포넌트의 CVE(Common Vulnerabilities and Exposures) 존재 여부를 탐지하는 방법을 정의한다. 자동화 도구(OSV-SCALIBR, Dependency-Track, Grype 등)를 CI/CD 파이프라인에 통합하여 빌드 시마다 취약점을 스캔하는 것이 효과적이다.

[취약점 탐지 절차 개요]
- CI/CD 파이프라인에 SCA(Software Composition Analysis) 도구를 통합한다.
- 빌드마다 SBOM 기반 취약점 스캔을 자동 실행한다.
- OSV(Open Source Vulnerabilities), NVD(National Vulnerability Database),
  GitHub Advisory Database 등 복수의 취약점 데이터베이스를 참조한다.
- 탐지된 취약점은 심각도와 함께 보안 담당자에게 자동 알림 발송한다.

방법 3 — 취약점 후속 조치

식별된 취약점에 대해 패치 적용, 완화 조치, 컴포넌트 교체, 위험 수용 등 후속 조치를 취하는 방법을 정의한다. CVSS 점수 기반 우선순위와 조치 기한을 절차에 명시한다.

[후속 조치 절차 개요]
- CVSS 점수에 따라 조치 우선순위와 기한을 결정한다:
  Critical(9.0+): 7일 이내 / High(7.0-8.9): 30일 이내
  Medium(4.0-6.9): 90일 이내 / Low(0.1-3.9): 다음 릴리스 시
- 패치가 없는 경우 완화 조치(네트워크 격리, WAF 규칙 추가 등)를 수행하고
  위험 수용 결정은 보안 담당자 + 오픈소스 PM이 공동 승인한다.
- 조치 결과를 취약점 추적 시스템에 기록하고 완료 여부를 검증한다.

방법 4 — 고객 통보

공급한 소프트웨어에서 취약점이 발견되어 고객에게 영향을 미칠 수 있는 경우 이를 고객에게 전달하는 방법을 정의한다. 고객 통보 기준(심각도, 고객 영향 범위), 통보 채널, 통보 기한을 절차에 명시한다.

[고객 통보 절차 개요]
- Critical/High 취약점 중 고객 배포 제품에 영향을 미치는 경우 통보한다.
- 통보 채널: 제품 보안 공지(웹사이트), 고객사 담당자 이메일, 보안 권고문 발행
- 통보 기한: 패치 또는 완화 조치 확정 후 7일 이내
- 통보 내용: 영향받는 컴포넌트, CVE ID, 심각도, 권장 조치, 패치 제공 일정

방법 5 — 배포 후 신규 취약점 분석

이미 배포된 소프트웨어에 대해 새로 공개된 CVE가 영향을 미치는지 분석하는 방법을 정의한다. 배포된 소프트웨어의 SBOM을 보관하고, 신규 CVE 발행 시 해당 컴포넌트 포함 여부를 자동 대조하는 모니터링 체계가 필요하다.

[배포 후 신규 취약점 분석 절차 개요]
- 배포된 소프트웨어의 SBOM을 버전별로 보관한다.
- Dependency-Track 등 도구를 활용하여 신규 CVE 발행 시 기배포 SBOM과
  자동 대조하고 영향을 받는 소프트웨어 버전 목록을 생성한다.
- 영향받는 버전이 확인된 경우 방법 3(후속 조치)과 방법 4(고객 통보) 절차에
  따라 처리한다.
- 모니터링은 상시 자동 수행하며, 주간 요약 보고를 보안 담당자에게 발송한다.

방법 6 — 지속적 보안 테스트

출시 전 모든 공급 소프트웨어에 지속적이고 반복적인 보안 테스트를 적용하는 방법을 정의한다. SAST(Static Application Security Testing), DAST(Dynamic Application Security Testing), SCA를 CI/CD 파이프라인에 통합하는 것이 일반적인 방식이다.

[지속적 보안 테스트 절차 개요]
- CI/CD 파이프라인 단계별 보안 테스트:
  · 코드 커밋 시: SAST(정적 분석), SCA(오픈소스 취약점 스캔)
  · PR 머지 시: 보안 게이트 통과 여부 확인 (Critical/High 미해결 시 블로킹)
  · 릴리스 후보 빌드: DAST(동적 분석), 컨테이너 이미지 스캔
- 보안 테스트 실패 시 릴리스를 자동 차단하고 보안 담당자에게 알림 발송한다.
- 테스트 커버리지와 결과를 대시보드에서 지속 모니터링한다.

방법 7 — 위험 해결 검증

식별된 위험이 출시 전에 실제로 해결되었는지 검증하는 방법을 정의한다. 패치 적용 후 재스캔을 통해 취약점이 제거되었음을 확인하고 그 결과를 기록해야 한다.

[위험 해결 검증 절차 개요]
- 패치 또는 완화 조치 완료 후 동일 도구로 재스캔을 실행한다.
- 재스캔 결과 취약점이 제거되었음을 확인하고 취약점 추적 시스템에 기록한다.
- Critical/High 취약점의 경우 보안 담당자가 검증 결과를 승인한다.
- 위험이 해결되지 않은 채 출시하는 경우 경영진 승인과 완화 계획을 문서화한다.

방법 8 — 위험 정보 수출

적절한 경우 식별된 위험 정보를 제3자(공급망 파트너, 고객, 취약점 데이터베이스 등)에게 내보내는 방법을 정의한다. VEX(Vulnerability Exploitability eXchange) 형식을 활용하거나, CVD 채널을 통해 상류 프로젝트에 취약점 정보를 제보하는 절차가 여기에 해당한다.

[위험 정보 수출 절차 개요]
- 자체적으로 새로운 취약점을 발견한 경우 CVD 절차에 따라 상류 프로젝트
  또는 CERT에 보고한다.
- 공급망 파트너에게 취약점 영향 정보를 공유할 때는 VEX 형식을 사용한다.
- 제3자 공유 전 법무 담당의 검토를 거쳐 영업 비밀 또는 미공개 정보가
  포함되지 않도록 확인한다.
- 정보 수출 이력(대상, 날짜, 내용 요약)을 기록하고 보관한다.

5. 참고

• ISO/IEC 5230 대응 조항 없음 (18974 전용 신규 조항)
• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
• 관련 도구: OSV-SCALIBR, Dependency-Track

3.2 - §4.2 관련 업무

3.2.1 - §4.2.1 접근성

1. 조항 개요

§4.2.1은 ISO/IEC 5230 §3.2.1(외부 문의 대응)과 구조가 동일하지만, 초점이 라이선스 컴플라이언스 문의에서 취약점 문의로 전환된다. 제3자가 공급 소프트웨어에서 알려진 취약점 또는 새로 발견한 취약점에 대해 문의할 수 있는 공개 채널을 마련하고, 내부적으로는 이 문의에 체계적으로 대응하는 절차를 문서화해야 한다. 보안 취약점 보고 채널은 CVD(Coordinated Vulnerability Disclosure) 절차와 연결되어 있으므로, 보안 연구자나 고객이 발견한 취약점을 안전하게 접수하고 처리하는 체계가 필요하다.

2. 해야 할 활동

• 제3자가 취약점 관련 문의를 보낼 수 있는 공개 연락처(이메일 주소, 웹폼 등)를 제품 또는 웹사이트에 명시한다.
• 공개 채널을 통해 접수된 취약점 보고를 내부적으로 처리하는 절차를 문서화한다.
• 문의 접수·분류·담당자 배정·대응·종결까지의 처리 단계를 절차에 포함한다.
• CVD 원칙(비공개 협력 후 공개)에 따른 처리 방침을 절차에 명시한다.
• 문의 접수 및 대응 이력을 기록하고 일정 기간 보관한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

4.2.1.1 공개된 취약점 문의 채널

준수 방법

제3자가 취약점을 보고하거나 문의할 수 있는 공개 연락처를 마련하고 외부에 명시해야 한다. 보안 전용 이메일 주소(예: security@company.com)를 제품 문서, 웹사이트 보안 정책 페이지, 또는 SECURITY.md 파일(GitHub 등 오픈소스 저장소)에 게시하는 것이 일반적이다. 이 공개 채널 자체가 입증자료 4.2.1.1이다.

ISO/IEC 5230 §3.2.1.1(라이선스 문의 채널)과 별도로 운영하거나, 보안 취약점 보고 전용 채널을 추가하는 방식으로 구성할 수 있다.

고려사항

• 보안 전용 채널 분리: 라이선스 문의 채널(oss@company.com)과 보안 취약점 보고 채널(security@company.com)을 분리하여 운영하면 처리 우선순위 관리가 용이하다.
• 응답 보장: 보고 채널이 실제로 모니터링되고 있음을 명시한다(예: “영업일 기준 3일 이내 수신 확인 응답”).
• security.txt 표준 활용: RFC 9116의 security.txt 표준을 적용하면 보안 연구자가 쉽게 연락처를 찾을 수 있다.

샘플

[웹사이트 보안 정책 페이지 / SECURITY.md 샘플]

## 보안 취약점 보고

당사 소프트웨어에서 보안 취약점을 발견하신 경우 아래 채널로 보고해 주십시오.
저희는 책임있는 공개(Coordinated Vulnerability Disclosure) 원칙을 따릅니다.

- 보고 이메일: security@company.com
- 수신 확인: 영업일 기준 3일 이내
- 처리 원칙: 비공개로 취약점을 검토하고 패치 후 공개

Security Vulnerability Reporting

To report a security vulnerability, please contact: security@company.com
We follow Coordinated Vulnerability Disclosure (CVD) practices.

4.2.1.2 내부 취약점 문의 대응 절차

준수 방법

외부에서 취약점 보고가 접수되었을 때 내부적으로 처리하는 절차를 문서화해야 한다. CVD 원칙에 따라 보고자와 비공개로 협력하여 취약점을 해결하고, 패치 준비 후 공개하는 흐름이 기본 골격이 된다. 이 절차 문서가 입증자료 4.2.1.2다.

고려사항

• CVD 원칙 준수: 보고자와 협력하여 취약점 해결 전까지 비공개를 유지하고 공개 일정을 합의한다.
• 처리 기한: 수신 확인, 취약점 검증, 패치 제공, 공개 각 단계별 기한을 절차에 명시한다.
• 기록 보관: 보고 내용, 검토 과정, 대응 조치, 공개 이력을 최소 3년간 보관한다.

샘플

[외부 취약점 보고 대응 절차]

1. 접수 및 수신 확인 (3영업일 이내)
   - security@company.com 수신함을 매일 확인한다.
   - 보고자에게 수신 확인 및 비공개 처리 약속을 회신한다.

2. 취약점 검증 (7영업일 이내)
   - 보안 담당자가 보고된 취약점의 재현 가능성과 영향 범위를 검증한다.
   - CVSS 점수를 산정하고 심각도를 분류한다.

3. 패치 개발 및 조치 (심각도에 따라 7~90일)
   - §4.1.5 방법 3(후속 조치) 절차에 따라 패치 또는 완화 조치를 수행한다.
   - 필요 시 보고자와 패치 일정을 공유하고 협의한다.

4. 공개 (패치 완료 후)
   - 보안 권고문(Security Advisory)을 작성하고 보고자 확인 후 공개한다.
   - CVE ID 발급을 요청한다 (필요 시).
   - 영향받는 고객에게 §4.1.5 방법 4(고객 통보) 절차에 따라 통보한다.

5. 기록 보관
   - 보고 내용, 검토 과정, 조치 결과, 공개 이력을 최소 3년간 보관한다.

5. 참고

• 대응 ISO/IEC 5230 조항: §3.2.1 외부 문의 대응
• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스

3.2.2 - §4.2.2 효과적 리소스

1. 조항 개요

§4.2.2는 ISO/IEC 5230 §3.2.2(효과적 리소스)에 대응하지만 두 가지 차이가 있다. 첫째, 5230이 5개 입증자료를 요구하는 반면 18974는 4개를 요구한다. 5230의 §3.2.2.5(미준수 사례 검토·시정 절차)가 18974에서는 §4.1.5 표준 관행 구현에 흡수된다. 둘째, §3.2.2.3(법률 자문 접근 방법)이 §4.2.2.3에서는 취약점 해결 전문성으로 대체된다. 라이선스 법률 자문이 아니라, 알려진 취약점을 실제로 해결할 수 있는 기술적·보안 전문성을 확보하고 그 접근 방법을 문서화해야 한다.

2. 해야 할 활동

• 프로그램 내 각 역할을 담당하는 인원의 이름 또는 직무를 문서에 기재한다.
• 각 역할 담당자에게 충분한 시간과 예산이 배정되었음을 확인하고 기록한다.
• 알려진 취약점을 해결하기 위해 이용 가능한 내부 또는 외부 보안 전문성을 식별하고 문서화한다 (5230과 초점이 다름).
• 보안 보증 컴플라이언스에 대한 내부 책임을 각 역할에 할당하는 절차를 문서화한다.

3. 요구사항 및 입증자료

★ = ISO/IEC 5230 §3.2.2.3(법률 자문)과 다름 — 보안 전문성으로 초점 전환

4. 입증자료별 준수 방법 및 샘플

4.2.2.1 역할 담당자 명시 문서

ISO/IEC 5230 §3.2.2.1과 동일하다. 보안 보증 역할(DevSecOps 엔지니어, 취약점 분석 담당 등)이 명시되어야 한다. 작성 방법은 §3.2.2.1 역할 담당자 명시 문서를 참고한다.

4.2.2.2 인원 배치 및 예산 지원 확인

ISO/IEC 5230 §3.2.2.2와 동일하다. 취약점 스캔 도구, 보안 교육, 외부 보안 컨설팅 등 보안 관련 예산 항목이 포함되어야 한다. 작성 방법은 §3.2.2.2 인원 배치 및 예산 지원 확인을 참고한다.

4.2.2.3 취약점 해결 전문성 명시 문서 ★

준수 방법

알려진 취약점이 식별되었을 때 이를 실제로 분석하고 해결할 수 있는 전문성이 어디에 있는지를 식별하고 문서화해야 한다. 이는 ISO/IEC 5230 §3.2.2.3의 법률 자문 접근 방법과 성격이 다르다. 내부 보안 팀이 있으면 해당 팀의 역량과 연락처를 기록하고, 내부에 전문성이 부족한 경우 외부 보안 전문가 또는 PSIRT(Product Security Incident Response Team) 서비스를 활용하는 방법을 문서화한다.

고려사항

• 내부 전문성 목록: 취약점 유형별(웹 보안, 펌웨어 보안, 암호화 등) 내부 전문가 또는 담당 팀을 식별한다.
• 외부 전문성 확보: 내부에 처리하기 어려운 취약점 유형에 대해 외부 보안 전문 기관(CERT, 보안 컨설팅사)과의 계약 또는 연락 방법을 기록한다.
• 에스컬레이션 기준: 어떤 상황에서 외부 전문성을 활용하는지 기준을 명시한다.

샘플

[취약점 해결 전문성 현황]

내부 전문성:
- 보안 담당 (김철수): 웹 취약점, 오픈소스 컴포넌트 CVE 분석, CVSS 평가
- DevSecOps 팀: CI/CD 보안 파이프라인 운영, 컨테이너 취약점 분석

외부 전문성 활용 기준:
- Zero-day 취약점, 펌웨어 취약점, 암호화 관련 취약점 발생 시
- 내부 팀이 30일 이내 해결 불가능하다고 판단하는 경우

외부 전문 기관:
- [외부 보안 컨설팅사명] (연간 계약, 취약점 분석 서비스)
- KrCERT/CC (취약점 조정 및 신고 채널)

4.2.2.4 내부 책임 할당 절차

ISO/IEC 5230 §3.2.2.4와 동일한 구조이나, 보안 보증에 특화된 책임(취약점 탐지, CVSS 평가, 고객 통보, CVD 관리 등)을 각 역할에 할당하는 절차를 포함해야 한다. 작성 방법은 §3.2.2.4 내부 책임 할당 절차를 참고하되, 아래 샘플처럼 보안 업무를 반영한다.

샘플

| 업무 | 오픈소스 PM | 보안 담당 | IT 담당 | 개발자 |
|------|------------|-----------|---------|--------|
| 취약점 스캔 도구 운영 | I | C | A/R | I |
| CVE 탐지 및 분류 | I | A/R | C | I |
| CVSS 점수 평가 | I | A/R | - | C |
| 패치 적용 및 검증 | C | A | C | R |
| 고객 통보 결정 | A | R | - | I |
| CVD 외부 보고 대응 | C | A/R | - | I |
| 취약점 기록 관리 | I | A/R | C | I |

R: 실행 책임 / A: 최종 책임 / C: 협의 / I: 정보 공유

5. 참고

• 대응 ISO/IEC 5230 조항: §3.2.2 효과적 리소스
• 관련 가이드: 기업 오픈소스 관리 가이드 — 1. 조직

3.3 - §4.3 콘텐츠 검토 및 승인

3.3.1 - §4.3.1 SBOM

1. 조항 개요

§4.3.1은 ISO/IEC 5230 §3.3.1(SBOM)과 기본 구조는 동일하지만, 강조점이 다르다. 5230은 오픈소스 컴포넌트의 라이선스 관리를 위한 SBOM을 다루는 반면, 18974의 §4.3.1은 소프트웨어 수명주기 전반에 걸쳐 지속적으로 SBOM을 기록하고 보관하는 것을 강조한다. 특히 배포 후에도 SBOM을 유지하여 §4.3.2 보안 보증의 취약점 모니터링과 연계되어야 한다. SBOM이 없으면 배포 후 새로 공개된 CVE에 대한 영향 분석(§4.1.5 방법 5)을 수행할 수 없다.

2. 해야 할 활동

• 공급 소프트웨어의 오픈소스 컴포넌트를 식별·추적·검토·승인하는 절차를 수립한다 (5230과 동일).
• 소프트웨어 수명주기 동안 지속적으로 SBOM을 기록하고 보관하는 절차를 수립한다 (18974 강조 사항).
• 배포된 소프트웨어 버전별로 SBOM을 보관하여 배포 후 취약점 영향 분석에 활용한다.
• SBOM 정보를 취약점 관리 도구(Dependency-Track 등)와 연동하여 신규 CVE 발행 시 자동으로 영향 분석이 이루어지도록 구성한다.
• 컴포넌트 추가·변경·제거 시 SBOM을 즉시 갱신하는 트리거를 정의한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

4.3.1.1 SBOM 수명주기 지속 기록 절차

준수 방법

ISO/IEC 5230 §3.3.1.1의 SBOM 관리 절차를 기반으로 하되, 수명주기 지속 기록과 아카이브에 초점을 맞춰 절차를 보강해야 한다. 이 절차 문서가 입증자료 4.3.1.1이다.

보안 보증 관점에서 SBOM 관리의 핵심은 배포 후에도 SBOM이 유효하게 유지되어 신규 CVE 발행 시 즉시 영향 분석에 활용될 수 있어야 한다는 점이다. 이를 위해 배포된 모든 소프트웨어 버전의 SBOM을 아카이브하고, 취약점 관리 도구와 연동하는 절차를 포함해야 한다.

고려사항

• 수명주기 단계별 SBOM 유지: 개발·빌드·배포·배포 후 모니터링 각 단계에서 SBOM이 최신 상태를 유지하도록 절차를 정의한다.
• 아카이브 정책: 배포된 모든 버전의 SBOM을 버전별로 아카이브하고 보관 기간을 명시한다(최소 해당 소프트웨어 지원 기간 + 3년).
• 취약점 도구 연동: Dependency-Track 등에 SBOM을 임포트하여 신규 CVE가 발행될 때마다 자동 대조가 이루어지도록 설정한다.
• 갱신 트리거: 컴포넌트 추가·업그레이드·제거, 라이선스 변경, 새로운 취약점 발견 시 SBOM 갱신을 의무화한다.

샘플

아래는 보안 보증 관점으로 강화된 SBOM 관리 절차 개요 샘플이다.

[SBOM 수명주기 관리 절차 개요]

(1) 개발 단계
    - 오픈소스 컴포넌트 도입 시 즉시 SBOM에 등록한다.
    - CI/CD 파이프라인 SCA 도구(Syft, cdxgen 등)가 자동 탐지한다.

(2) 빌드 단계
    - 빌드마다 최신 SBOM을 자동 생성한다 (SPDX 또는 CycloneDX 형식).
    - 취약점 스캔 도구와 연동하여 빌드 시점 취약점 현황을 기록한다.

(3) 배포 단계
    - 릴리스 버전의 SBOM을 확정하고 아카이브 저장소에 보관한다.
    - Dependency-Track에 SBOM을 임포트하여 지속 모니터링을 활성화한다.

(4) 배포 후 모니터링
    - 신규 CVE 발행 시 아카이브된 모든 버전 SBOM과 자동 대조한다.
    - 영향받는 버전이 확인되면 §4.1.5 방법 5 절차에 따라 처리한다.

(5) 갱신 트리거
    - 다음 이벤트 발생 시 SBOM을 즉시 갱신한다:
      · 컴포넌트 추가, 버전 업그레이드, 컴포넌트 제거
      · 라이선스 변경, 새로운 취약점 발견으로 인한 대체

(6) 아카이브 보관
    - 배포된 모든 버전의 SBOM을 버전별로 보관한다.
    - 보관 기간: 해당 소프트웨어 공식 지원 종료 후 최소 3년

4.3.1.2 오픈소스 컴포넌트 기록 (SBOM)

ISO/IEC 5230 §3.3.1.2와 동일하다. 보안 보증 관점에서 SBOM에는 라이선스 정보 외에 각 컴포넌트의 알려진 취약점 현황 또는 취약점 관리 도구 링크를 함께 기록하면 §4.3.2와 연계가 용이하다. 작성 방법은 §3.3.1.2 오픈소스 컴포넌트 기록을 참고한다.

5. 참고

• 대응 ISO/IEC 5230 조항: §3.3.1 SBOM
• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
• 관련 도구: Syft, cdxgen, Dependency-Track

3.3.2 - §4.3.2 보안 보증

1. 조항 개요

§4.3.2는 ISO/IEC 18974의 핵심 조항으로, ISO/IEC 5230에 없는 18974 전용 신규 조항이다. SBOM에 포함된 각 오픈소스 컴포넌트에 대해 취약점 탐지 → 위험 평가 → 조치 결정 → 고객 동의(필요 시) → 조치 수행 → 배포 후 신규 취약점 대응 → 지속 모니터링 의 전 과정을 절차로 수립하고 이행 기록을 유지하도록 요구한다. §4.1.5가 취약점 처리 방법의 존재를 요구한다면, §4.3.2는 그 방법이 각 컴포넌트에 실제로 적용되어 기록이 남아 있을 것을 요구한다.

2. 해야 할 활동

• SBOM의 각 오픈소스 컴포넌트에 대해 알려진 취약점 존재 여부를 탐지한다.
• 탐지된 각 취약점에 위험·영향 점수(CVSS)를 할당한다.
• 각 취약점에 대해 필요한 수정 또는 완화 단계를 결정하고 문서화한다.
• 필요한 경우 사전에 결정된 수준 이상에서 고객 동의를 획득한다.
• 위험·영향 점수에 따라 적절한 조치를 수행하고 기록한다.
• 배포된 소프트웨어에 새로 공개된 취약점이 있는 경우 적절한 조치를 수행한다.
• 출시 후에도 공급 소프트웨어의 취약점 공개를 모니터링하고 대응한다.
• 취약점별 탐지 및 조치 결과를 컴포넌트 기록으로 유지한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

4.3.2.1 취약점 탐지 및 해결 절차

준수 방법

SBOM의 각 오픈소스 컴포넌트에 대한 취약점 탐지부터 해결까지의 전체 과정을 문서화한 절차가 입증자료 4.3.2.1이다. 이 절차는 §4.1.5에서 정의한 개별 방법들을 통합하여 운영 흐름으로 구체화한 것이다.

아래 플로우차트는 CVE 탐지부터 조치 완료까지의 전체 흐름을 나타낸다.

flowchart TD
    A([SBOM 컴포넌트]) --> B[취약점 스캔\nSCA 도구]
    B --> C{CVE 탐지?}
    C -- 없음 --> D[탐지 없음 기록\n정기 재스캔 대기]
    C -- 있음 --> E[CVSS 점수 산정\n위험·영향 평가]
    E --> F{심각도 분류}
    F -- Critical/High --> G[즉시 대응\n7~30일 기한]
    F -- Medium --> H[계획 대응\n90일 기한]
    F -- Low --> I[다음 릴리스 처리]
    G --> J{고객 영향?}
    H --> J
    J -- 있음 --> K[고객 통보\n§4.1.5 방법 4]
    J -- 없음 --> L[조치 결정]
    K --> L
    L --> M{패치 가능?}
    M -- 예 --> N[패치 적용\n재스캔 검증]
    M -- 아니오 --> O[완화 조치\n또는 위험 수용]
    N --> P[조치 결과 기록\n§4.3.2.2]
    O --> P
    P --> Q([지속 모니터링\n§4.1.5 방법 5])

절차 단계별 상세

아래는 플로우차트의 각 단계를 절차 문서 형태로 기술한 샘플이다.

[취약점 탐지 및 해결 절차]

1단계 — 취약점 탐지
- CI/CD 파이프라인 빌드 시 SCA 도구(Dependency-Track, OSV-SCALIBR 등)가
  SBOM을 기반으로 취약점을 자동 스캔한다.
- NVD, OSV, GitHub Advisory Database 등 복수의 취약점 DB를 참조한다.
- 배포 후에도 신규 CVE 발행 시 아카이브된 SBOM과 자동 대조한다.

2단계 — 위험·영향 점수 산정
- 탐지된 CVE에 대해 CVSS v3.1 기준 기본 점수를 산정한다.
- 당사 제품의 실제 사용 맥락(네트워크 노출도, 권한 필요 여부 등)을 고려하여
  환경 점수(Environmental Score)를 조정한다.
- 심각도 분류: Critical(9.0+) / High(7.0-8.9) / Medium(4.0-6.9) / Low(0.1-3.9)

3단계 — 조치 결정 및 문서화
- 심각도와 고객 영향 범위에 따라 조치 방법을 결정한다:
  · 패치 적용: 상위 버전으로 업그레이드 또는 패치 적용
  · 완화 조치: 패치가 없는 경우 네트워크 격리, 기능 비활성화 등
  · 위험 수용: 실제 악용 가능성이 낮고 완화 조치도 불필요한 경우
    (보안 담당자 + 오픈소스 PM 공동 승인 필수)
- 조치 결정 근거를 취약점 추적 시스템에 기록한다.

4단계 — 고객 동의 획득 (해당 시)
- Critical/High 취약점이 고객 배포 제품에 영향을 미치는 경우:
  · 고객사 보안 담당자에게 취약점 정보와 대응 계획을 사전 통보한다.
  · 패치 배포 일정과 완화 조치 방법을 공유한다.

5단계 — 조치 수행
- 결정된 조치를 조치 기한 내에 수행한다.
- 패치 적용 후 재스캔을 실행하여 취약점 제거를 확인한다.
- 조치 완료 결과를 §4.3.2.2 기록에 업데이트한다.

6단계 — 지속 모니터링
- Dependency-Track 등 도구를 통해 배포된 소프트웨어의 취약점 현황을
  상시 모니터링한다.
- 신규 CVE 발행 시 1~3단계를 자동 또는 즉시 재수행한다.

4.3.2.2 취약점 및 조치 기록

준수 방법

SBOM의 각 오픈소스 컴포넌트에 대해 식별된 취약점과 취해진 조치(조치가 불필요 하다고 판단한 경우 포함)를 기록하고 유지해야 한다. 이 기록이 입증자료 4.3.2.2다. “조치가 필요하지 않은 경우도 포함"이라는 표현이 중요하다 — 취약점이 탐지되지 않은 컴포넌트도 스캔했다는 사실과 탐지 결과를 기록해야 한다.

기록은 Dependency-Track, Jira 보안 이슈 트래커, 스프레드시트 등 다양한 도구로 관리할 수 있으며, 감사 시 즉시 제출 가능한 형태로 유지한다.

고려사항

• 컴포넌트별 기록: SBOM의 각 컴포넌트에 대해 개별 기록을 유지한다.
• 탐지 없음도 기록: 취약점이 탐지되지 않은 컴포넌트도 스캔 날짜와 결과를 기록한다.
• 조치 이력 추적: 동일 컴포넌트의 취약점 발생·조치·재스캔 이력을 시계열로 관리한다.
• 보관 기간: 해당 소프트웨어의 지원 기간 + 최소 3년간 보관한다.

샘플

아래는 컴포넌트별 취약점 및 조치 기록부 샘플이다.

| 소프트웨어 | 버전 | 컴포넌트 | 컴포넌트 버전 | CVE ID | CVSS | 심각도 | 조치 내용 | 조치일 | 담당자 | 비고 |
|-----------|------|---------|--------------|--------|------|--------|-----------|--------|--------|------|
| MyProduct | v1.2.0 | openssl | 3.0.7 | CVE-2023-0286 | 7.4 | High | 3.0.8로 업그레이드 | 2023-02-10 | 김철수 | 재스캔 확인 완료 |
| MyProduct | v1.2.0 | zlib | 1.2.11 | CVE-2022-37434 | 9.8 | Critical | 1.2.13으로 업그레이드 | 2022-10-15 | 김철수 | 고객 통보 완료 |
| MyProduct | v1.2.0 | libpng | 1.6.37 | 없음 | - | - | 조치 불필요 | 2023-03-01 | 김철수 | 정기 스캔 결과 |
| FirmwareX | v2.3.0 | busybox | 1.35.0 | CVE-2022-28391 | 9.8 | Critical | 위험 수용 (네트워크 격리 완화) | 2022-11-20 | 김철수 | 패치 미존재, PM 승인 완료 |

5. 참고

• ISO/IEC 5230 대응 조항 없음 (18974 전용 신규 조항)
• 관련 가이드: 기업 오픈소스 관리 가이드 — 3. 프로세스
• 관련 도구: Dependency-Track, OSV-SCALIBR
• 연계 조항: §4.1.5 표준 관행 구현, §4.3.1 SBOM

3.4 - §4.4 규격 준수

3.4.1 - §4.4.1 완전성

1. 조항 개요

§4.4.1은 ISO/IEC 5230 §3.6.1(적합성)에 대응하는 조항이다. §4.1.4에서 정의한 프로그램이 ISO/IEC 18974의 모든 요구사항을 충족함을 확인하는 문서를 작성해야 한다. 5230 §3.6.1과 구조는 동일하지만, 확인 대상이 18974의 25개 입증자료 항목 전체라는 점이 다르다. ISO/IEC 5230 인증과 18974 인증을 동시에 준비하는 경우 두 규격의 공통 항목을 통합 점검하고, 18974 전용 9개 항목(★ 표시)을 추가로 확인하는 방식이 효율적이다.

2. 해야 할 활동

• §4.1부터 §4.3까지 모든 조항의 입증자료(25개 항목)가 갖추어졌는지 자체 점검한다.
• 프로그램이 §4.1.4에서 정의한 적용 범위 내에서 ISO/IEC 18974의 모든 요구사항을 충족함을 확인하는 문서를 작성한다.
• 확인 문서에 검토자, 승인자, 확인 날짜를 기록한다.
• ISO/IEC 5230과 18974를 동시에 준수하는 경우 통합 점검표를 활용하여 중복 검토 부담을 줄인다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

4.4.1.1 규격 준수 확인 문서

준수 방법

§4.1.4에서 정의한 프로그램의 적용 범위 내에서 ISO/IEC 18974의 모든 요구사항을 충족한다는 사실을 확인하는 문서를 작성해야 한다. 이 문서가 입증자료 4.4.1.1이다. 아래 체크리스트를 활용하여 25개 입증자료 항목 전체를 점검하고, 확인 결과를 기록한다.

ISO/IEC 18974 준수 자체 점검 체크리스트

§4.1 프로그램 기반
□ 4.1.1.1 문서화된 보안 보증 정책
□ 4.1.1.2 정책 인식 전파 절차
□ 4.1.2.1 역할과 책임 목록
□ 4.1.2.2 역할별 역량 정의 문서
□ 4.1.2.3 참여자 목록 및 역할 매핑 ★
□ 4.1.2.4 역량 평가 증거
□ 4.1.2.5 주기적 검토 및 변경 증거 ★
□ 4.1.2.6 내부 모범 사례 일치 검증 ★
□ 4.1.3.1 참여자 인식 평가 증거
□ 4.1.4.1 프로그램 적용 범위 진술
□ 4.1.4.2 성과 메트릭 세트 ★
□ 4.1.4.3 지속적 개선 증거 ★
□ 4.1.5.1 8가지 취약점 처리 방법 문서화 절차 ★

§4.2 관련 업무
□ 4.2.1.1 공개된 취약점 문의 채널
□ 4.2.1.2 내부 취약점 문의 대응 절차
□ 4.2.2.1 역할 담당자 명시 문서
□ 4.2.2.2 인원 배치 및 예산 확인
□ 4.2.2.3 취약점 해결 전문성 명시 ★
□ 4.2.2.4 내부 책임 할당 절차

§4.3 콘텐츠 검토 및 승인
□ 4.3.1.1 SBOM 수명주기 지속 기록 절차
□ 4.3.1.2 오픈소스 컴포넌트 기록 (SBOM)
□ 4.3.2.1 취약점 탐지 및 해결 절차 ★
□ 4.3.2.2 취약점 및 조치 기록 ★

§4.4 규격 준수
□ 4.4.1.1 모든 요구사항 충족 확인 문서
□ 4.4.2.1 18개월 이내 요구사항 충족 확인 문서

★ = ISO/IEC 5230 대비 추가 항목 (9건)

고려사항

• 5230과 통합 점검: ISO/IEC 5230 인증을 보유한 경우 공통 항목(16건)은 기존 자료를 재활용하고 18974 전용 항목(9건)에 집중한다.
• 승인 절차: 오픈소스 프로그램 매니저의 검토와 경영진 승인을 거쳐 문서를 공식화한다.
• 규격 버전 명시: ISO/IEC 18974:2023(버전 1.0)을 준수 확인 규격으로 문서에 명시한다.

샘플

[ISO/IEC 18974 규격 준수 확인서]

프로그램 명칭: [회사명] 오픈소스 보안 보증 프로그램
적용 범위: [§4.1.4에서 정의한 범위]
준수 확인 규격: ISO/IEC 18974:2023 (버전 1.0)
확인 날짜: YYYY-MM-DD

본 문서는 위 프로그램이 ISO/IEC 18974:2023의 §4.1부터 §4.4까지
모든 요구사항(25개 입증자료 항목)을 충족함을 확인한다.

준수 확인 항목 요약:
- §4.1 프로그램 기반 (5개 조항, 13개 입증자료): 충족 ✓
- §4.2 관련 업무 (2개 조항, 6개 입증자료): 충족 ✓
- §4.3 콘텐츠 검토 및 승인 (2개 조항, 4개 입증자료): 충족 ✓
- §4.4 규격 준수 (2개 조항, 2개 입증자료): 충족 ✓

검토자: [오픈소스 프로그램 매니저 이름]
승인자: [경영진 또는 OSRB 책임자 이름]
승인일: YYYY-MM-DD

5. 참고

• 대응 ISO/IEC 5230 조항: §3.6.1 적합성
• ISO/IEC 18974 자가 인증: https://certification.openchainproject.org/
• 전체 조항 체크리스트: ISO/IEC 18974 준수 가이드

3.4.2 - §4.4.2 기간

1. 조항 개요

§4.4.2는 ISO/IEC 5230 §3.6.2(지속 기간)와 동일한 구조다. 적합성 인증을 취득한 후 18개월 이내에 이 규격의 모든 요구사항을 충족하고 있음을 확인하는 문서를 유지하도록 요구한다. 규격의 새 버전이 발행되면 18개월의 유예 기간 동안 이전 버전 기준 인증이 유지되며, 유예 기간 내에 최신 버전 기준으로 갱신하는 것을 권장한다.

2. 해야 할 활동

• 적합성 인증 취득 날짜를 기록하고 관리한다.
• 인증 취득 후 최근 18개월 이내에 규격의 모든 요구사항을 충족하고 있음을 재확인하고 문서화한다.
• 새로운 버전의 ISO/IEC 18974가 발행된 경우 18개월 이내에 최신 버전 기준으로 프로그램을 갱신하고 재확인한다.
• 정기적인 내부 감사를 통해 25개 입증자료 항목의 지속적 준수 여부를 점검한다.

3. 요구사항 및 입증자료

4. 입증자료별 준수 방법 및 샘플

4.4.2.1 18개월 이내 요구사항 충족 확인 문서

준수 방법

ISO/IEC 5230 §3.6.2.1과 동일한 방식으로, §4.4.1.1의 규격 준수 확인 문서를 최소 연 1회 재검토하고 갱신한다. 갱신 시마다 검토 날짜와 검토자를 기록하여 최근 18개월 이내에 검토가 이루어졌음을 증명한다.

ISO/IEC 5230과 18974를 동시에 운영하는 경우, 두 규격의 정기 재확인 일정을 통합하여 연 1회 통합 감사로 처리하면 관리 효율이 높다.

샘플

[ISO/IEC 18974 규격 준수 정기 재확인 기록]

최초 인증 취득일: YYYY-MM-DD
준수 확인 규격: ISO/IEC 18974:2023 (버전 1.0)

| 재확인 날짜 | 확인 결과 | 변경 사항 | 검토자 | 비고 |
|------------|-----------|-----------|--------|------|
| 2025-01-10 | 전체 충족 | 취약점 해결 전문성 문서 갱신 (§4.2.2.3) | 홍길동 | - |
| 2026-01-08 | 전체 충족 | 성과 메트릭 목표치 상향 (§4.1.4.2) | 홍길동 | - |

다음 재확인 예정일: YYYY-MM-DD
18개월 유효 기한: YYYY-MM-DD

5. 참고

• 대응 ISO/IEC 5230 조항: §3.6.2 지속 기간
• OpenChain 규격 최신 버전 확인: https://www.openchainproject.org/security-assurance

3.5 - ISO/IEC 5230 vs 18974 비교

1. 두 표준의 관계

ISO/IEC 5230과 ISO/IEC 18974는 모두 OpenChain 프로젝트가 주도하는 오픈소스 관련 국제 표준이지만, 서로 다른 문제를 다룬다. 5230은 오픈소스 라이선스 컴플라이언스(저작권 의무 이행·SBOM 관리·컴플라이언스 산출물 배포)를 다루고, 18974는 오픈소스 보안 보증(취약점 탐지·평가·대응·CVD)을 다룬다. 두 표준은 완전한 상위·하위 집합 관계가 아니다. 정책·역량·SBOM 등 9개 공통 조항을 공유하되, 5230에만 있는 조항(라이선스 컴플라이언스·산출물·기여)과 18974에만 있는 조항(표준 관행 구현·보안 보증)이 각각 존재한다.

두 표준을 동시에 준수하면 라이선스 의무 이행과 보안 취약점 관리를 하나의 통합 오픈소스 프로그램으로 운영할 수 있다. 공통 기반 문서(정책·역량 기록·SBOM 절차)는 한 번 작성으로 두 표준에 동시 활용되므로, 5230 인증 후 18974를 추가로 준비하는 데 드는 실질적 추가 작업량은 전체의 30~40% 수준이다.

2. 조항 1:1 대조표

요약

• 공통 조항: 9개 (입증자료 16개)
• 5230 전용 조항: §3.3.2, §3.4.1, §3.5.1 (입증자료 6개)
• 18974 전용 조항: §4.1.5, §4.3.2 (입증자료 3개)
• 18974에서 확장된 공통 조항: 4개 — §4.1.1, §4.1.2, §4.1.4, §4.2.2 (입증자료 6개 추가)

3. 입증자료 수 비교

4. 두 표준 동시 준수 전략

5230을 먼저 취득한 후 18974를 추가로 준비하는 경로가 가장 효율적이다. 5230 인증 과정에서 구축한 정책 문서, 역량 기록, SBOM 절차는 18974의 공통 조항(§4.1.1~§4.1.4, §4.2.1, §4.2.2, §4.3.1, §4.4.1, §4.4.2)에 그대로 활용된다. 별도로 작성이 필요한 것은 기존 문서에 추가하는 항목들과 18974 전용 신규 조항 2개다.

18974 전용으로 새로 준비해야 하는 항목은 다음과 같다:

• §4.1.5 표준 관행 구현: 8가지 취약점 처리 방법(위협 식별·탐지·후속 조치· 고객 통보·배포 후 분석·보안 테스트·위험 검증·정보 수출) 각각의 절차 문서화
• §4.3.2 보안 보증: CVE 탐지→위험 평가→조치 결정→수행→모니터링 전 과정 절차 및 컴포넌트별 취약점 조치 기록
• 공통 조항 보완: §4.1.2 참여자 목록(4.1.2.3)·주기적 검토 증거(4.1.2.5)· 모범 사례 일치 검증(4.1.2.6), §4.1.4 성과 메트릭(4.1.4.2)·지속 개선 증거 (4.1.4.3) 추가 작성

5230 체계를 갖춘 조직이 18974를 추가로 준비하는 데 드는 실질적 작업량은 전체 5230 준비 작업의 약 30~40% 수준으로 예상된다.

5. 참고 링크

• ISO/IEC 5230 준수 가이드
• ISO/IEC 18974 준수 가이드
• 기업 오픈소스 관리 가이드
• OpenChain 자가 인증

4 - Templates

4.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. 책임 할당 절차:

   1. 오픈소스 프로그램 매니저(OSPM)가 연간 책임 할당 회의를 소집합니다.
   2. 각 부서장(법무, IT, 보안, 개발, 품질 등)과 협의하여 활동별 책임자를 선정합니다.
   3. 선정된 책임자 목록을 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.2.1 라이선스 사용 사례별 처리 방침

오픈소스 컴포넌트의 사용 형태에 따라 다음 기준을 적용합니다:

1. 내부 사용: 외부 배포 없이 사내에서만 사용하는 경우, 별도 컴플라이언스 산출물 생성 의무는 없으나 SBOM 기록은 유지합니다.
2. 외부 배포 (바이너리): GPL 등 소스 공개 의무 라이선스가 포함된 경우, 소스 코드 패키지를 함께 제공하거나 서면 청약을 포함합니다.
3. 외부 배포 (SaaS/네트워크 서비스): AGPL 등 네트워크 사용을 배포로 간주하는 라이선스가 포함된 경우, 법무팀의 별도 검토를 거칩니다.
4. 오픈소스 프로젝트에 기여: 기여 코드에 적용되는 라이선스가 프로젝트 라이선스와 호환되는지 확인합니다.

각 사용 사례에 해당하는 오픈소스 컴포넌트는 §4.3의 절차에 따라 컴플라이언스 산출물을 생성·관리합니다.

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

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

4.4 SBOM 생성 및 관리

1. SBOM 생성:
   • 공급 소프트웨어를 구성하는 모든 오픈소스 컴포넌트의 SBOM(Software Bill of Materials)을 생성합니다.
   • SBOM에는 각 컴포넌트의 이름, 버전, 라이선스 정보, 다운로드 위치 등이 포함됩니다.
   • SBOM은 SPDX 또는 CycloneDX 표준 형식 중 하나를 채택하여 생성합니다. (ISO/IEC 18974 §3.3.1.2)
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. 대응 조치:
   • 고위험 취약점에 대해서는 즉시 패치를 적용하거나 완화 조치를 수행합니다.
   • 고객에게 영향을 미칠 수 있는 경우, 고객에게 통지하고 해결 방안을 제시합니다.
   • 취약점 심각도에 따라 다음 기한 내에 조치합니다: Critical(CVSS 9.0 이상) 1주 이내, High(CVSS 7.0~8.9) 4주 이내. (ISO/IEC 18974 §3.3.2.1)
4. 대응 기록 유지:
   • 모든 취약점과 대응 조치는 데이터베이스에 기록되며, 정기적으로 보고서를 생성합니다.
   • 대응 기록은 향후 유사한 문제 발생 시 참고 자료로 활용됩니다.
   • 취약점 대응 기록은 해당 공급 소프트웨어의 마지막 배포 시점으로부터 최소 3년간 보관합니다. (ISO/IEC 18974 §3.3.2.2)

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. 인식 평가 증거 보관 절차:
   • 역량 평가의 증거는 다음 형태 중 하나 이상으로 수집하고 보관합니다: 테스트 점수, 교육 이수 확인서, 정책 인식 확인 서명. (ISO/IEC 5230 §3.1.3, ISO/IEC 18974 §3.1.3)
   • 증거는 사내 문서 관리 시스템(예: Learning Portal, HR 시스템)에 등록하여 감사 시 즉시 제출 가능한 상태로 유지합니다.
   • 보관 기간 만료 후에는 개인정보 보호 정책에 따라 파기합니다.
3. 정기적인 검토 및 업데이트:
   • 오픈소스 프로그램 매니저는 연 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는 정기적으로 기여 활동의 효과성을 평가하고, 필요 시 개선 방안을 제안합니다.

7.5 기여 정책 인식 절차

1. 정책 인식 의무화:
   • 모든 프로그램 참여자는 외부 오픈소스 기여 정책(제7조) 및 사내 프로젝트 공개 정책(제8조)의 존재와 내용을 인식해야 합니다.
   • OSPO는 신규 참여자 온보딩 시 기여 정책을 고지하고, 연간 교육을 통해 재확인합니다. (ISO/IEC 5230 §3.1.3)
2. 인식 확인 및 기록:
   • OSPO는 기여 정책 인식 여부를 확인하고, 그 결과를 기록으로 관리합니다.
   • 인식 확인 기록은 최소 3년간 보관됩니다.

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. 피드백 제공 및 개선:
   • 대응 후, 외부 문의자에게 피드백을 제공하며, 필요 시 개선 방안을 제안합니다.
   • 반복적인 문제를 방지하기 위해 대응 기록을 분석하고 프로세스를 개선합니다.
4. 대응 기록 보관:
   • 외부 문의 대응 기록은 해당 문의가 종결된 날로부터 최소 3년간 보관합니다. (ISO/IEC 18974 §3.2.1.2)

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

4.1.1 - Appendix

Appendix 1. 담당자 현황

4.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)
  • 사용 목적 및 방식
  • 수정 여부 및 수정 내용
  • 버전 히스토리 및 각 버전별 주요 변경 사항

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

SBOM은 SPDX 또는 CycloneDX 표준 형식으로 작성하며, 등록 전 형식 적합성을 검증합니다.

(7) 고지

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

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

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

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

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

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

(8) 배포 전 확인

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

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

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

(9) 배포

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

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

고객이 요청하는 경우, IT 담당은 해당 공급 소프트웨어의 SBOM을 고객에게 제공할 수 있도록 준비합니다.

(10) 최종 확인

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

(11) 모니터링

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

오픈소스 컴포넌트의 추가·변경·제거, 새로운 취약점 발견, 또는 라이선스 변경이 확인된 경우에는 해당 공급 소프트웨어의 SBOM을 즉시 갱신합니다.

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

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 점수)
• 발견 날짜
• 해결 상태
• 적용된 해결 방법
• 검증 결과

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

취약점 기록은 해당 공급 소프트웨어의 마지막 배포 시점으로부터 최소 3년간 보관합니다. (ISO/IEC 18974 §3.3.2.2)

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

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

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

(8) 고객 및 제3자 통지

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

1. 고객 통지:

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

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

2. 제3자 정보 공개:

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

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

3. 통지 내용:

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

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

(9) 취약점 공개 타이밍 절차 (CVD)

새로 발견된 취약점(회사 내부 발견 또는 외부 연구자 보고)에 대해서는 조정된 취약점 공개(Coordinated Vulnerability Disclosure, CVD) 절차를 따릅니다.

1. 공개 전 조율:
   • 취약점 발견 즉시 영향받는 오픈소스 프로젝트 메인테이너에게 비공개로 통보합니다.
   • 패치 개발 및 배포에 충분한 시간을 부여하기 위해 원칙적으로 최초 통보 후 90일 이내에 공개합니다.
   • 메인테이너와 협의하여 공개 일정을 조정할 수 있으며, 합의된 일정은 문서화합니다.
2. 즉시 공개 예외:
   • 취약점이 이미 외부에 알려져 악용되고 있거나 즉각적인 위협이 있는 경우, 조율 기간 없이 즉시 공개할 수 있습니다.
   • 즉시 공개 결정은 보안 담당과 오픈소스 프로그램 매니저가 공동으로 승인합니다.
3. 공개 내용 및 채널:
   • 공개 시 CVE ID 발급 신청(MITRE 또는 CNA)을 병행합니다.
   • 취약점 정보, 영향 범위, 패치 또는 완화 방법을 회사 보안 공지 페이지 및 관련 공개 데이터베이스(NVD 등)에 게시합니다.

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

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

(1) 접수 알림

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

주요 문의 및 요청 내용:

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

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

(2) 조사 알림

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

(3) 내부 조사

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

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

(4) 요청자에게 보고

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

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

(5) 문제 보완 / 알림

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

(6) 문제 해결 알림

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

(7) 프로세스 개선

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

(8) 기록 보관

오픈소스 프로그램 매니저는 외부 문의 대응의 전 과정(접수, 조사, 대응, 해결)을 이슈 추적 시스템에 기록합니다. 이 기록은 해당 문의가 종결된 날로부터 최소 3년간 보관합니다. (ISO/IEC 18974 §3.2.1.2)

보관 기록에는 다음 내용이 포함되어야 합니다:

• 문의 접수 일시 및 요청자 정보
• 문의 내용 및 분류 (라이선스 컴플라이언스 / 보안 취약점)
• 내부 조사 결과 및 대응 조치
• 최종 처리 결과 및 완료 일시

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

프로그램 참여자가 외부 오픈소스 프로젝트에 기여할 때는 회사의 지식재산 보호와 라이선스 호환성을 확보하기 위해 다음 절차를 준수합니다. 자세한 정책은 오픈소스 정책 §7을 참조하십시오.

(1) 기여 의사 확인 및 사전 검토 요청

프로그램 참여자는 외부 오픈소스 프로젝트에 기여하기 전에 OSPO에 기여 검토를 요청합니다.

요청 시 포함할 정보:

• 기여 대상 프로젝트명 및 저장소 URL
• 기여 내용 개요 (버그 수정, 기능 추가 등)
• 기여 코드의 출처 (자체 작성 여부, 회사 소유 여부)
• 관련 특허 포함 여부

(2) OSPO 검토 및 승인

OSPO는 기여 요청을 검토하고 다음 사항을 확인합니다:

1. 라이선스 호환성: 기여 코드의 라이선스와 대상 프로젝트 라이선스의 호환 여부 확인.
2. 지식재산 검토: 기여 코드에 회사의 특허 또는 민감 정보가 포함되지 않았는지 확인. 필요 시 법무팀 자문을 요청합니다.
3. CLA 검토: 대상 프로젝트가 CLA(Contributor License Agreement) 서명을 요구하는 경우, 조건을 검토하고 저작권 양도 조항이 없는지 확인합니다.

검토 완료 후 OSPO는 승인 또는 반려 결정을 요청자에게 통보합니다.

(3) 기여 수행

승인된 기여에 대해 프로그램 참여자는 다음 사항을 준수하며 기여합니다:

• 파일 상단에 회사 저작권 표시 및 SPDX 라이선스 식별자를 명기합니다.
• 회사 이메일을 사용하여 기여합니다.
• 직접 작성한 코드 또는 회사가 권리를 보유한 코드만 기여합니다.

(4) 기여 이력 기록 및 보관

OSPO는 모든 승인된 기여를 내부 시스템에 기록합니다.

기록 항목:

• 기여 대상 프로젝트 및 기여 일시
• 기여 내용 요약
• 승인자 및 승인 일시
• CLA 서명 여부

기여 이력은 최소 3년간 보관합니다.

5. 사내 프로젝트 공개 프로세스

사내에서 개발한 프로젝트를 오픈소스로 공개할 때는 회사의 지식재산 보호와 라이선스 선택의 적절성을 확보하기 위해 다음 절차를 준수합니다. 자세한 정책은 오픈소스 정책 §8을 참조하십시오.

(1) 공개 검토 요청

공개를 희망하는 부서는 OSPO에 공개 검토를 요청합니다.

요청 시 포함할 정보:

• 프로젝트 개요 및 공개 목적
• 공개 범위 (코드, 문서 등)
• 특허 포함 여부
• 의존하는 서드파티 라이브러리 목록

(2) OSPO 검토 및 승인

OSPO는 다음 사항을 검토합니다:

1. 지식재산 검토: 공개 코드에 회사 특허, 영업 비밀, 민감 정보가 포함되지 않았는지 확인합니다. 필요 시 법무팀 자문을 요청합니다.
2. 라이선스 선택: 공개 목적(커뮤니티 육성, 표준화 기여 등)과 지식재산 보호를 고려하여 적절한 오픈소스 라이선스를 선택합니다.
3. 의존성 라이선스 호환성: 포함된 서드파티 컴포넌트의 라이선스가 선택한 공개 라이선스와 호환되는지 확인합니다.

(3) 공개 준비

승인 후 담당 부서는 다음 작업을 수행합니다:

• 코드에서 민감 정보(API 키, 내부 서버 주소 등)를 제거합니다.
• 파일 상단에 저작권 표시 및 SPDX 라이선스 식별자를 명기합니다.
• README, 기여 가이드(CONTRIBUTING.md), 라이선스 파일(LICENSE)을 작성합니다.
• GitHub 등 공개 저장소에 프로젝트를 등록합니다.

(4) 공개 후 관리

OSPO와 담당 부서는 공개된 프로젝트의 지속적인 유지보수를 위해 다음을 수행합니다:

• 외부 기여(Pull Request, Issue)를 주기적으로 검토하고 대응합니다.
• 보안 취약점 보고 시 §2 보안 취약점 관리 프로세스에 따라 대응합니다.
• 프로젝트 상태(활성/유지보수/아카이브)를 정기적으로 검토하고 README에 명시합니다.

(5) 공개 기록 보관

OSPO는 공개 승인 내역과 관련 검토 기록을 최소 3년간 보관합니다.

보관 항목:

• 공개 요청 및 승인 일시, 승인자
• 선택한 라이선스 및 선택 근거
• 지식재산 검토 결과
• 공개 저장소 URL

6. 교육·평가 실행 프로세스

오픈소스 프로그램 참여자가 정책과 프로세스를 충분히 이해하고 역량을 유지할 수 있도록, 다음 절차에 따라 교육과 역량 평가를 실행합니다. 자세한 정책은 오픈소스 정책 §6을 참조하십시오.

(1) 교육 대상 및 주기 결정

오픈소스 프로그램 매니저는 연 1회 이상 교육 대상을 확인하고 교육 계획을 수립합니다.

• 신규 참여자: 온보딩 시 필수 교육을 이수합니다.
• 기존 참여자: 연 1회 이상 정기 교육을 이수합니다.
• 역할 변경자: 새로운 역할에 맞는 추가 교육을 이수합니다.

(2) 교육 실시

오픈소스 프로그램 매니저는 다음 방법으로 교육을 제공합니다:

1. 온라인 교육: Learning Portal의 필수 과목을 이수하고, 이수 완료를 시스템에서 자동 기록합니다.
2. 오프라인 교육: 필요 시 워크숍 또는 세미나를 개최하고, 참석자 명단과 교육 자료를 기록합니다.

교육 내용에는 다음 주제가 포함되어야 합니다:

• 오픈소스 정책의 목적과 원칙
• 라이선스 의무 및 컴플라이언스 절차
• SBOM 생성 및 활용
• 취약점 관리 절차
• 외부 오픈소스 기여 정책 및 사내 프로젝트 공개 절차

(3) 역량 평가 실시

교육 이수 후 오픈소스 프로그램 매니저는 참여자의 역량을 평가합니다.

• 온라인 테스트 또는 실무 과제를 통해 평가를 수행합니다.
• 평가 기준(합격 점수 등)은 교육 계획 수립 시 사전에 정의합니다.
• 평가 미통과자에게는 보충 교육 기회를 제공하고 재평가를 실시합니다.

(4) 평가 결과 기록 및 보관

오픈소스 프로그램 매니저는 교육 이수 및 평가 결과를 기록합니다.

기록 항목:

• 교육 이수자 이름, 역할, 이수 일시
• 평가 결과 (점수 또는 합격/불합격)
• 보충 교육 이력 (해당 시)

기록은 사내 문서 관리 시스템 또는 Learning Portal에 등록하며, 최소 3년간 보관합니다. (ISO/IEC 5230 §3.1.3, ISO/IEC 18974 §3.1.3)

(5) 교육 내용 검토 및 개선

오픈소스 프로그램 매니저는 연 1회 이상 교육 내용과 평가 방식을 검토하고, 다음 사항을 반영하여 업데이트합니다:

• 오픈소스 관련 법·규제 변화
• 새로운 취약점 트렌드 및 사례
• 사내 정책 및 프로세스 변경 사항

5 - Tools

5.1 - FOSSology

오픈소스 컴플라이언스를 위해 소프트웨어 내에 포함된 오픈소스와 라이선스 정보를 검출하기 위해 소스코드 스캔 도구를 사용할 수 있다.

Linux Foundation의 FOSSology 프로젝트는 이러한 스캔 도구를 개발하고 오픈소스로 공개해 누구나 자유롭게 사용할 수 있게 한 도구이다.

주요 특징

FOSSology는 웹기반의 프로그램으로 사용자는 웹사이트에 로그인하여 개별 파일 혹은 소프트웨어 패키지를 업로드할 수 있다. FOSSology는 업로드된 파일 내에 라이선스 텍스트와 Copyright 정보를 검출한다. 개발자는 사용하고자 하는 오픈소스의 라이선스가 무엇인지, Copyright은 어떻게 되는지에 대한 정보를 확인하고자 할때 FOSSology를 이용하는 것이 좋다. FOSSology는 개발자가 업로드한 오픈소스 패키지 내의 모든 파일을 스캔하여 각 파일 내 라이선스 관련 텍스트와 Copyright 정보를 자동으로 검출하고, 이를 리포트로 생성한다. FOSSology 주요 특징에 대한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://www.fossology.org/features/

설치

기업 내에서 FOSSology를 사용하기 위해서는 사내에 FOSSology 서버를 구축해야 한다. 이를 위해 리눅스 기반의 서버 시스템에 FOSSology를 설치해야 한다. FOSSology는 다음 세 가지 방법으로 설치할 수 있다.

1. Docker 사용
2. Vagrant와 VirtualBox 사용
3. Source build하여 설치

여기서는 가장 간편한 방법인 Docker를 사용하는 방법에 대해 설명한다.

FOSSology는 컨테이너화 된 Docker 이미지를 Docker Hub (https://hub.docker.com/)를 통해 공개하고 있다. : https://hub.docker.com/r/fossology/fossology

Pre-built 된 Docker 이미지는 다음 명령어를 사용하여 실행할 수 있다.

$ docker run -p 8081:80 fossology/fossology

Docker 이미지는 다음 URL과 계정 정보로 사용할 수 있다. : http://[IP_OF_DOCKER_HOST]:8081/repo

• Username : fossy
• Passwd : fossy

설치와 관련한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://github.com/fossology/fossology/blob/master/README.md

테스트 서버

FOSSology를 설치할 수 있는 시스템 구축이 곤란한 상황이라면, FOSSology Project에서 제공하는 테스트 서버를 이용할 수 있다. FOSSology 프로젝트에서는 테스트를 위한 환경을 제공한다. (테스트 서버는 예고없이 중단될 수 있다.)

사용자는 다음 계정으로 FOSSology 테스트 서버에 접속하여 FOSSology 기능을 시험해볼 수 있다.

Basic Workflow

FOSSology의 기본 사용 절차는 다음과 같다.

• 사용하고자 하는 오픈소스의 라이선스와 Copyright 정보를 확인하기 위해 오픈소스의 소스 코드를 하나의 파일로 압축하여 FOSSology에 업로드한다.
• 이를 위해 메뉴 > Upload > From File을 선택합니다.

• 업로드할 파일을 선택하고 Upload 버튼을 클릭한다.
• 업로드가 완료되면 Job Agent에 의해 자동으로 분석을 수행한다.
• 메뉴 > Jobs > My Recent Jobs에서 분석 중인 Status를 확인할 수 있다.

• 분석이 완료되면 메뉴 > Browse에서 분석 결과를 확인할 수 있다.

• 개별 파일을 선택하면 FOSSology가 검출한 라이선스 관련 텍스트가 무엇인지 확인할 수 있다.

• 메뉴 > Browser > 파일 혹은 디렉터리를 선택 > Copyright/Email/Url/Author에서는 FOSSology가 검출한 Copyright/Email/Url/Author 정보를 보여다.

사용자는 FOSSology는 이렇게 분석한 결과가 유효한지 여부에 대해 확인 후 잘못 검출된 항목에 대해서는 분석 결과에서 제외시키는 작업을 할 수 있다. FOSSology는 이를 Clearing 과정이라고 설명하며, 자세한 사항은 다음 페이지를 참고할 수 있다. : https://www.fossology.org/get-started/basic-workflow/

위와 같은 방법으로 사용하고자 하는 오픈소스의 라이선스는 무엇인지, Copyright 정보는 어떻게 되는지를 간단히 확인할 수 있다.

5.2 - SW360

(Updated on August 29, 2023.)

오픈소스를 포함하는 제품을 개발하고 배포하는 기업이라면 각 제품과 릴리스 버전마다 사용한 오픈소스의 버전, 라이선스 등의 정보를 수집하고 추적해야 한다. 이를 통해 기업은 올바른 오픈소스 컴플라이언스 활동을 수행할 수 있다.

특히, NVD (https://nvd.nist.gov/vuln)에서 특정 오픈소스 버전에 보안 취약점이 보고 되었을때, 해당 버전을 사용하고 있는 제품이 무엇인지 추적을 할 수 없다면, 그 기업은 어느 제품에 보안 패치를 적용해야 할 지 알 수 없는 상황에 처하게 되고, 그 기업의 제품들은 보안취약점에 그대로 노출이 될 수 밖에 없다.

이렇듯, 오픈소스 정보를 추적하는 활동은 꼭 필요하다. 기업들은 이를 위해 자체 시스템을 구축하거나, 상용 서비스를 구매하여 사용하기도 한다. SW360은 Eclipse 재단에서 후원하는 오픈소스로서 소프트웨어 BOM에 대한 정보를 수집 및 추적하기 위한 웹 애플리케이션 및 저장소를 제공한다.

주요 특징

SW360은 웹 기반의 UI를 제공하며 주요 기능은 다음과 같다.

• 제품에 사용된 컴포넌트 추적
• 보안 취약점 평가
• 라이선스 의무 관리
• 고지문 등 법적 문서 생성

설치

SW360은 다음과 같이 구성된다.

• Frontend : Liferay-(Tomcat-)based portal application
• Backend : Tomcat-based thrift service
• Database : CouchDB

Project 구조와 설치를 위해 요구되는 소프트웨어 등 자세한 내용은 README의 Required software 부분에서 확인할 수 있다. : https://github.com/eclipse-sw360/sw360

SW360은 다음 두 가지의 설치 방법을 제공한다. 사용자는 이 중 하나를 선택하여 설치할 수 있다.

1. Docker를 통해 Deploy 할 수 있다. : https://github.com/eclipse-sw360/sw360/blob/main/README_DOCKER.md
2. SW360의 구성요소를 개별적으로 설치할 수 있다. : https://github.com/eclipse/sw360
3. Vagrant (https://www.vagrantup.com/) 기반 설치 : Vagrant는 가상화 인스턴스를 관리하는 도구로서 sw360vagrant에서는 SW360을 한 번에 Deploy 하기 위한 환경을 제공한다. : https://github.com/sw360/sw360vagrant
   • Vagrant 기반 설치 가이드는 여기에서 확인할 수 있다. (단, 가이드 작성 시점과 현재 코드가 상이하여 정상동작하지 않을 가능성이 있습니다.)

이 가이드에서는 Docker로 Deploy하는 방법을 소개한다. 자세한 사항은 README를 참고한다. : https://github.com/eclipse-sw360/sw360/blob/main/README_DOCKER.md

1. 코드 다운로드

Docker Image 빌드를 위해 코드를 다운로드 한다. 테스트가 완료된 코드는 여기서 받을 수 있다. : https://github.com/haksungjang/sw360/tree/docker_build

git clone -b docker_build https://github.com/haksungjang/sw360.git

2. 빌드

먼저 Docker를 설치한다. (기업 개발자가 사용하려면 유료 구매가 필요할 수 있음에 주의하세요.)

아래와 같이 docker_build.sh를 실행하여 빌드한다.

cd sw360
./docker_build.sh

정상적으로 빌드가 완료되면 아래와 같이 생성된 이미지를 확인할 수 있다.

docker image ls

REPOSITORY                       TAG              IMAGE ID       CREATED          SIZE
eclipse-sw360/sw360              18-development   ab0fd848bf80   8 minutes ago    2.95GB
eclipse-sw360/sw360              latest           ab0fd848bf80   8 minutes ago    2.95GB
ghcr.io/eclipse-sw360/sw360      18-development   ab0fd848bf80   8 minutes ago    2.95GB
ghcr.io/eclipse-sw360/sw360      latest           ab0fd848bf80   8 minutes ago    2.95GB
eclipse-sw360/binaries           18-development   aa7debf0a1fc   8 minutes ago    347MB
eclipse-sw360/binaries           latest           aa7debf0a1fc   8 minutes ago    347MB
ghcr.io/eclipse-sw360/binaries   18-development   aa7debf0a1fc   8 minutes ago    347MB
ghcr.io/eclipse-sw360/binaries   latest           aa7debf0a1fc   8 minutes ago    347MB
eclipse-sw360/base               18-development   e5147733fc88   37 minutes ago   1.52GB
eclipse-sw360/base               latest           e5147733fc88   37 minutes ago   1.52GB
ghcr.io/eclipse-sw360/base       18-development   e5147733fc88   37 minutes ago   1.52GB
ghcr.io/eclipse-sw360/base       latest           e5147733fc88   37 minutes ago   1.52GB
ghcr.io/eclipse-sw360/thrift     0.18.1           0012d7998058   4 weeks ago      152MB
ghcr.io/eclipse-sw360/thrift     latest           0012d7998058   4 weeks ago      152MB
eclipse-sw360/thrift             0.18.1           0012d7998058   4 weeks ago      152MB
eclipse-sw360/thrift             latest           0012d7998058   4 weeks ago      152MB

3. 실행

docker-compose up 명령으로 생성된 이미지를 실행한다.

docker-compose up

정상적으로 실행이 완료되면 아래와 같이 세개의 container가 실행된 것을 볼 수 있다.

docker ps 

CONTAINER ID   IMAGE                 COMMAND                  CREATED         STATUS                   PORTS                                              NAMES
4299fd39010c   eclipse-sw360/sw360   "/app/entry_point.sh"    3 minutes ago   Up 3 minutes             0.0.0.0:8080->8080/tcp, 0.0.0.0:11311->11311/tcp   sw360
13fd5696b140   postgres:14           "docker-entrypoint.s…"   3 minutes ago   Up 3 minutes (healthy)   0.0.0.0:5438->5432/tcp                             sw360-postgresdb-1
7bb70f2daaf4   couchdb               "tini -- /docker-ent…"   3 minutes ago   Up 3 minutes (healthy)   4369/tcp, 9100/tcp, 0.0.0.0:5984->5984/tcp         sw360-couchdb-1

이 상태에서 http://localhost:8080/로 접근하면 다음과 같은 화면에 진입한다.

설정

SW360을 정상적으로 설치한 후에는 아래의 절차대로 초기 설정이 필요하다. 자세한 내용은 여기에서 확인할 수 있다. : SW360 Initial Setup Configuration

1. User, Login 설정

설정을 위해 다음 계정으로 로그인한다.

• id : setup@sw360.org
• pw : sw360fossy

로그인을 하면 아래와 같이 Not Found라는 표시가 나타나게 된다.

화면 우상단의 아이템 아이콘(큐브 모양)을 클릭하고 Control Panel 탭을 선택한다.

SECURITY > Password Policies > Default Password Policy > PASSWORD CHANGES > Change Requried를 활성화한다.

그리고, 다시 Control Panel탭에서 CONFIGURATION > Instance Settings을 선택한다. 그러면, PLATFORM메뉴를 볼 수 있다.

거기서 Users를 선택한다. 그리고, Default User Associations 메뉴로 진입하고, Apply to Existing Users를 체크한다. 그리고 Save한다.

이번에는 Instance Settings > PLATFORM에서 User Authentication를 선택한다. General로 진입하여 모든 항목을 Uncheck한다. (관리 목적상 필요한 항목은 Check하여 활성화할 수 있다.) 그리고 Save한다.

끝으로, jquery와 font awesome을 활성화시켜야 한다. 이를 위해 Control Panel 탭에서 CONFIGURATION > System Settings으로 진입하면 PLATFORM 하위에 Third Party를 볼 수 있다.

Third Party에 진입하여 JQuery와 Font Awesome을 각각 Enable시킨다.

브라우저를 새로 실행하면 변경 사항이 적용된다.

2. LAR 파일 import

SW360 설정을 위해서는 *.lar 파일들을 import해야 한다. 이를 설정하기 위해서는 메뉴로 진입해야 하는데, 메뉴 버튼은 화면 좌측 상단에 있다.

메뉴에서 Publishing > Import에 진입한다.

우측의 + 버튼을 눌러 LAR 파일을 업로드 할 수 있는데, LAR 파일은 SW360 소스 파일 내 frontend/configuration 폴더 하위에 있다. (예: https://github.com/haksungjang/sw360/tree/docker_build/frontend/configuration)

먼저, Public_Pages_7_4_3_18_GA18.lar 파일을 업로드하고 Continue 버튼을 누른다.

File Summary 화면에서 업로드된 LAR 파일 세부 내용을 볼 수 있다.

제일 아래의 AUTHORSHIP OF THE CONTENT를 Use the Current User as Author로 변경하고 Import 버튼을 누른다.

그러면 Import가 성공적으로 완료된 걸 볼 수 있다.

이와 유사하게 Private_Pages_7_4_3_18_GA18.lar 파일을 Import한다. File Summary 화면에서 아래와 같이 PAGES > Private Pages로 변경한다.

그리고, PERMISSIONS, UPDATE DATA, AUTHORSHIP OF THE CONTENT 항목을 각각 아래 이미지와 같이 선택하고, Import버튼을 눌러 Import를 수행한다.

여기까지 수행을 마친 후 메뉴 상단의 Home 버튼을 누른다.

그럼 아래와 같이 Welcome to SW360! 화면에 진입한다.

Start 버튼을 눌러 SW360 첫 화면에 진입할 수 있다. (모든 항목이 비어있다.)

3. User Account 설정 (테스트용)

SW360 메뉴에서 Admin > User를 선택한다.

화면 하단의 UPLOAD USERS 메뉴에서 테스트를 위한 User 리스트를 업로드 한다. (테스트를 위한 User 리스트는 여기에서 다운 받을 수 있다. : test_users_with_passwords_12345.csv )

그러면 다음과 같이 9개의 User 리스트가 업로드 된 것을 볼 수 있다.

여기서 보이는 User 리스트 중 하나인 user@@sw360.org 계정으로 다시 로그인을 시도한다. Password는 12345이다.

Basic Workflow

1. License 등록

SW360을 처음 설치하면 먼저 자주 사용하는 오픈소스 라이선스 들을 등록해야 한다. 라이선스 다음과 같은 정보를 포함한다.

• Full Name
• Short Name
• License Type
• GPL-2.0 Compatibility (예: yes, no)
• License Text

메뉴 > Licenses > Add License를 선택하면 다음과 같이 Create License 화면으로 진입한다.

이와 같이 라이선스를 하나씩 수동으로 등록하는 일은 상당히 수고스러울 수 있는데, 다행히 SW360은 SPDX License List를 한 번에 Import 하는 기능을 제공한다. 메뉴 > Admin < Import SPDX Information을 클릭한다.

그러면, 곧 SPDX License List가 자동으로 등록됩니다. 메뉴 > Licenses에서 338개의 License가 등록된 것을 확인할 수 있다.

2. Component 및 Release 등록

SW360에서 Component는 하나의 소프트웨어 단위이다. 여기에는 다양한 형태의 소프트웨어가 해당할 수 있으며, 그 예는 다음과 같다.

• 오픈소스 소프트웨어
• 라이브러리
• 3rd party 소프트웨어

Component는 다음과 같은 정보를 포함한다.

• Component Name
• Main Licenses
• Categories (예: Library, Cloud, Mobile, …)
• Component Type (예: OSS, Internal, InnerSource, Service, Freeware)
• Default Vendor
• Homepage URL

Release는 Component에서 하나의 Version을 가리키는 단위이다. 따라서 하나의 Component는 여러 개의 Release를 가질 수 있다. Release는 하나의 Component 하위에 생성되어 관리된다.

Release는 다음과 같은 정보들을 포함한다.

• Component Name
• Version
• License
• Download URL
• CPE ID (예: cpe:2.3:a:apache:maven:3.0.4)

예를 들어, zlib-1.2.8을 등록해야 한다면, 먼저 Component에 zlib을 먼저 등록한 후, Release에 zlib 1.2.8을 등록한다. Menu > Components > Add Component를 선택하면 Create Component 화면으로 진입하여 zlib에 대한 정보를 등록할 수 있다.

Component를 생성하면, Components > Releases > Add Release에서 zlib-1.2.8 version에 대한 정보를 등록할 수 있다.

하나의 zlib이라는 Component에 1.2.8과 1.2.11 version을 각각의 Release로 등록하였을 때, Release Overview 화면에서 다음과 같이 2개의 Release가 존재하는 것을 볼 수 있다.

SW360은 다수의 Component 정보를 Import 시키기 위한 기능을 제공한다. 메뉴 > Admin > Import / Export에 CSV template에 등록을 원하는 Component 정보를 입력 후 Import 할 수 있다.

단, 이 기능은 2020년 2월 기준 아직 안정적으로 동작하지 않을 수 있다.

3. Project 생성

Project는 하나의 제품을 가리킨다. 사업 유형에 따라 제품일수도 있고, 서비스 혹은 소프트웨어 일수도 있다. Project에는 제품에 사용된 Component/Release를 등록하여 관리한다.

Project 생성 시에는 다음과 같은 정보를 등록한다.

• Project Name
• Version
• Project type (예: Product, Customer Project, Service, Internal Project, InnerSource)

메뉴 > Projects > Add Project를 통해 Project를 생성할 수 있다.

Project를 생성하고 나면, 포함하는 Release나 하위 Project를 등록한다. 메뉴 > Projects에서 해당 Project를 선택하면 “Linked Releases and Projects”에서 Linked Projects와 Linked Releases를 등록할 수 있다.

다음은 SuperCalc라는 Project에 OpenSSL 1.0.1과 zlib 1.2.8을 Linked Releases로 등록한 이후의 화면이다.

4. 보안 취약점 관리

SW360은 등록된 Release에 대해 보안 취약점이 있는지 자동으로 확인할 수 있다. 이를 위해 SW360은 CVE 정보를 주기적으로 수집하도록 스케쥴링하는 기능을 제공한다. 메뉴 > Admin > Schedule 에서 CVE SEARCH 정보를 24시간마다 수집하도록 스케쥴링을 설정할 수 있다.

이렇게 스케쥴링을 설정하면 SW360은 정해진 시간에 CVE Search 사이트(https://cve.circl.lu/)에서 CVE 정보를 수집한다. 수집한 CVE 정보는 메뉴 > Vulnerabilities에서 확인할 수 있다.

이렇게 Vulnerabilities 정보가 수집된 이후에는 생성한 Project에 보안 취약점이 있는지 조회할 수 있다. 위에서 생성한 SuperCalc Project에서는 85개의 보안 취약점이 보고된 것을 확인할 수 있다.

이와 같은 방법으로 기업에서 개발/배포하는 소프트웨어를 SW360에 등록하여 관리한다면, 오픈소스 컴플라이언스뿐만 아니라 보안 취약점에 대해서도 리스크를 최소화할 수 있는 형태로 관리가 가능하다.

또한 SW360은 위와 같은 Web Interface 뿐만 아니라 대부분의 기능을 REST API로 제공하여서 FOSSology 등의 다른 도구와의 연동이 가능하다. : https://github.com/eclipse/sw360/wiki/Dev-REST-API

즉, 소스 코드 스캐닝 도구의 분석 결과를 SW360에 Import 시키는 등의 방법으로 DevOps에 Integration 시켜서 Project, Release 등록을 자동화시켜서 관리한다면 효율성이 크게 증가될 것이다.

5.3 - FOSSLight

FOSSLight는 LG Electronics에서 주도하는 오픈소스 프로젝트로, 다양한 스캐너를 활용하여 소스 코드, 바이너리, 의존성을 분석하고 SBOM(Software Bill of Materials, 소프트웨어 자재 명세서)을 생성하는 도구입니다. 특히 FOSSLight Hub는 오픈소스 관리, 라이선스 관리, 취약점 관리 기능을 제공하여 컴플라이언스 프로세스를 지원합니다.

1 FOSSLight 소개

• 주요 기능:
  • 다양한 스캐너 연동: ScanCode Toolkit, SPDX Tools, CycloneDX, 그리고 Fossology 등 다양한 오픈소스 스캐너를 통합하여 사용
  • 다양한 분석 대상 지원: 소스 코드, 바이너리, 컨테이너 이미지, Linux 패키지 등 다양한 분석 대상 지원
  • SBOM 생성 및 관리: 다양한 형식(SPDX, CycloneDX, Excel, Text)으로 SBOM 생성 및 관리
  • 라이선스 정보 탐지 및 관리: 오픈소스 라이선스 정보를 정확하게 탐지하고 관리
  • 취약점 정보 연동: NVD, CVE 등 외부 취약점 데이터베이스와 연동하여 취약점 정보 제공
  • FOSSLight Hub: 웹 기반 UI를 통해 오픈소스 관리, 라이선스 관리, 취약점 관리 기능 제공
• 장점:
  • 높은 확장성: 다양한 스캐너를 플러그인 형태로 통합하여 사용할 수 있음
  • 웹 기반 UI 제공: FOSSLight Hub를 통해 사용자 친화적인 인터페이스 제공
  • 다양한 보고서 형식 지원: SPDX, CycloneDX, Excel, Text 등 다양한 형식으로 보고서 생성 가능
  • 오픈소스 라이선스
• 단점:
  • 초기 설정 복잡: 다양한 스캐너를 연동해야 하므로 초기 설정이 다소 복잡할 수 있음
  • FOSSLight Hub 설치 필요: 웹 기반 UI를 사용하려면 FOSSLight Hub를 별도로 설치해야 함

2 FOSSLight 설치

FOSSLight는 FOSSLight Scanner와 FOSSLight Hub로 구성됩니다. FOSSLight Scanner는 다양한 스캐너를 실행하여 분석 결과를 생성하는 역할을 하며, FOSSLight Hub는 스캐너 결과를 통합 관리하고 시각화하는 웹 기반 UI를 제공합니다.

여기서는 Docker Compose를 사용하여 FOSSLight Scanner와 FOSSLight Hub를 동시에 설치하는 방법을 설명합니다.

1. Docker 및 Docker Compose 설치:

   • FOSSLight를 설치하기 전에 Docker와 Docker Compose가 시스템에 설치되어 있는지 확인합니다.
   • Docker 설치 방법은 운영체제에 따라 다르므로, Docker 공식 문서를 참고하십시오(https://docs.docker.com/get-docker/).
   • Docker Compose는 Docker를 사용하여 여러 컨테이너를 동시에 실행하고 관리하는 도구입니다. Docker Compose 설치 방법은 Docker 공식 문서를 참고하십시오(https://docs.docker.com/compose/install/).

2. FOSSLight 저장소 복제:

   • 다음 명령어를 실행하여 FOSSLight GitHub 저장소를 복제합니다.

   git clone <https://github.com/fosslight/fosslight_hub.git>
   cd fosslight_hub
   

3. Docker Compose 파일 설정:

   • fosslight_hub 디렉토리에는 docker-compose.yml 파일이 포함되어 있습니다. 이 파일을 텍스트 편집기로 열고, FOSSLight Hub의 설정을 변경할 수 있습니다.

   version: "3.7"
   services:
     fosslight_db:
       image: mariadb:10.6.4
       container_name: fosslight_db
       volumes:
         - fosslight_db:/var/lib/mysql
       restart: always
       environment:
         - MYSQL_ROOT_PASSWORD=fosslight
         - MYSQL_DATABASE=fosslight_db
         - MYSQL_USER=fosslight
         - MYSQL_PASSWORD=fosslight
   
     fosslight_web:
       image: fosslight/fosslight_hub:latest
       container_name: fosslight_web
       ports:
         - "8080:8080"
       restart: always
       environment:
         - FOSSLightDB_HOST=fosslight_db
         - FOSSLightDB_PORT=3306
         - FOSSLightDB_USER=fosslight
         - FOSSLightDB_PASSWORD=fosslight
         - FOSSLightDB_NAME=fosslight_db
       depends_on:
         - fosslight_db
   
     fosslight_scanner:
       image: fosslight/fosslight_scanner:latest
       container_name: fosslight_scanner
       restart: always
       volumes:
         - ./upload:/home/fosslight_scanner/upload
         - ./result:/home/fosslight_scanner/result
   volumes:
     fosslight_db:
   

   • 필요에 따라 포트 번호, 데이터베이스 설정 등을 변경할 수 있습니다.

4. FOSSLight 실행:

   • 다음 명령어를 실행하여 FOSSLight를 실행합니다.

   docker-compose up -d
   

   • 이 명령어는 FOSSLight Hub, FOSSLight Scanner, 그리고 MariaDB 데이터베이스를 Docker 컨테이너로 실행합니다.

5. FOSSLight 설치 확인:

   • 웹 브라우저에서 http://localhost:8080에 접속하여 FOSSLight Hub에 접속할 수 있는지 확인합니다.
   • FOSSLight Hub 웹 UI가 표시되면 설치가 성공적으로 완료된 것입니다.

   그림 2.1: FOSSLight Hub 웹 UI

   (FOSSLight Hub 웹 UI 화면 캡쳐 이미지 삽입)

3 FOSSLight 사용 가이드

FOSSLight는 웹 UI(FOSSLight Hub)와 CLI(FOSSLight Scanner)를 통해 사용할 수 있습니다.

3.1 FOSSLight Hub 사용

FOSSLight Hub는 웹 UI를 통해 오픈소스 프로젝트를 관리하고, 스캔 결과를 확인하며, 다양한 보고서를 생성할 수 있는 기능을 제공합니다.

1. 프로젝트 등록:

   • FOSSLight Hub에 접속하여 새로운 프로젝트를 등록합니다.
   • 프로젝트 이름, 설명, 담당자 등의 정보를 입력합니다.

   그림 2.2: FOSSLight Hub 프로젝트 등록 화면

   (FOSSLight Hub 프로젝트 등록 화면 캡쳐 이미지 삽입)

2. 스캔 결과 업로드:

   • FOSSLight Scanner를 사용하여 생성한 스캔 결과를 FOSSLight Hub에 업로드합니다.
   • 스캔 결과 파일은 SPDX, CycloneDX, 또는 FOSSLight JSON 형식이어야 합니다.

   그림 2.3: FOSSLight Hub 스캔 결과 업로드 화면

   (FOSSLight Hub 스캔 결과 업로드 화면 캡쳐 이미지 삽입)

3. 스캔 결과 확인:

   • 업로드된 스캔 결과를 확인합니다.
   • FOSSLight Hub는 SBOM 정보, 라이선스 정보, 그리고 취약점 정보를 시각적으로 제공합니다.

   그림 2.4: FOSSLight Hub 스캔 결과 확인 화면

   (FOSSLight Hub 스캔 결과 확인 화면 캡쳐 이미지 삽입)

4. 보고서 생성:

   • 스캔 결과를 바탕으로 다양한 보고서를 생성합니다.
   • 보고서 형식은 SPDX, CycloneDX, Excel, 또는 Text 형식을 선택할 수 있습니다.

   그림 2.5: FOSSLight Hub 보고서 생성 화면

   (FOSSLight Hub 보고서 생성 화면 캡쳐 이미지 삽입)

3.2 FOSSLight Scanner 사용

FOSSLight Scanner는 CLI를 통해 소스 코드, 바이너리, 컨테이너 이미지를 스캔하고 SBOM을 생성하는 기능을 제공합니다.

1. 스캔 실행:

   • 다음 명령어를 실행하여 스캔을 실행합니다.

   docker run --rm -v $(pwd)/upload:/home/fosslight_scanner/upload -v $(pwd)/result:/home/fosslight_scanner/result fosslight/fosslight_scanner -p /home/fosslight_scanner/upload/<스캔 대상> -o /home/fosslight_scanner/result/<결과 파일명> -f <결과 형식>
   

   • 각 옵션에 대한 설명은 다음과 같습니다.
     • -rm: 컨테이너 실행 후 자동으로 제거합니다.
     • v $(pwd)/upload:/home/fosslight_scanner/upload: 현재 디렉토리의 upload 디렉토리를 컨테이너 내부의 /home/fosslight_scanner/upload 디렉토리와 공유합니다. 스캔 대상 파일 또는 디렉토리를 이 디렉토리에 복사해야 합니다.
     • v $(pwd)/result:/home/fosslight_scanner/result: 현재 디렉토리의 result 디렉토리를 컨테이너 내부의 /home/fosslight_scanner/result 디렉토리와 공유합니다. 스캔 결과 파일이 이 디렉토리에 저장됩니다.
     • p /home/fosslight_scanner/upload/<스캔 대상>: 스캔 대상 파일 또는 디렉토리 경로를 지정합니다.
     • o /home/fosslight_scanner/result/<결과 파일명>: 스캔 결과 파일 이름을 지정합니다.
     • f <결과 형식>: 스캔 결과 형식을 지정합니다 (spdx, cyclonedx, fosslight_json).
   • 예시:

   docker run --rm -v $(pwd)/upload:/home/fosslight_scanner/upload -v $(pwd)/result:/home/fosslight_scanner/result fosslight/fosslight_scanner -p /home/fosslight_scanner/upload/my_project -o /home/fosslight_scanner/result/my_project_sbom.json -f fosslight_json
   

2. 스캔 결과 확인:

   • 스캔이 완료되면 result 디렉토리에 스캔 결과 파일이 생성됩니다.
   • 스캔 결과 파일을 텍스트 편집기 또는 FOSSLight Hub를 사용하여 확인할 수 있습니다.

4 FOSSLight 사용 시 주의사항

• FOSSLight는 다양한 스캐너를 연동하여 사용하므로, 각 스캐너의 특징과 사용법을 이해해야 합니다.
• FOSSLight Hub는 웹 서버와 데이터베이스를 필요로 하므로, 시스템 자원 요구사항을 고려하여 설치해야 합니다.
• FOSSLight Scanner는 스캔 대상 파일 또는 디렉토리에 접근할 수 있는 권한이 필요합니다.

5 문제 해결

• Docker 실행 오류: Docker가 제대로 설치되었는지 확인하고, 권한 문제가 없는지 확인합니다.
  • sudo docker run ... 명령어를 사용하여 관리자 권한으로 실행해봅니다.
• 스캔 오류: 스캔 대상 파일 또는 디렉토리 경로가 정확한지 확인하고, 해당 파일 또는 디렉토리에 접근 권한이 있는지 확인합니다.
• FOSSLight Hub 접속 오류: Docker 컨테이너가 정상적으로 실행 중인지 확인하고, 포트 포워딩 설정이 제대로 되었는지 확인합니다.

6 추가 정보

• FOSSLight 공식 웹사이트: https://fosslight.org/
• FOSSLight GitHub 저장소: https://github.com/fosslight/fosslight_hub
• SPDX 공식 웹사이트: https://spdx.dev/
• CycloneDX 공식 웹사이트: https://cyclonedx.org/

5.4 - OSV-SCALIBR

OSV-SCALIBR (Open Source Vulnerabilities - Software Composition Analysis LIBRary)은 Google이 개발한 오픈소스 소프트웨어 구성 분석 도구입니다. 파일시스템, 컨테이너 이미지, 바이너리를 스캔하여 포함된 패키지를 식별하고, OSV(Open Source Vulnerabilities) 데이터베이스와 대조하여 알려진 취약점을 검출합니다. SPDX 형식의 SBOM 생성도 지원합니다.

• GitHub: https://github.com/google/osv-scalibr
• 라이선스: Apache-2.0

1. 주요 특징

• 다양한 스캔 대상 지원: 로컬 파일시스템, 컨테이너 이미지, 아카이브 파일
• 폭넓은 생태계 지원: Go, Python, Java(Maven), JavaScript(npm), Rust, Ruby 등
• OSV DB 연동: 스캔 결과를 OSV 데이터베이스와 대조하여 CVE 등 취약점 정보 제공
• SBOM 출력: SPDX 2.3 형식으로 결과 내보내기 가능
• CLI 및 라이브러리 이중 제공: 독립 실행 바이너리(CLI)와 Go 라이브러리 모두 제공

2. 설치 방법

Go 1.21 이상이 설치된 환경에서 아래 명령으로 빌드합니다.

git clone https://github.com/google/osv-scalibr.git
cd osv-scalibr
go build -o scalibr ./binary/cli/...

또는 Releases 페이지에서 사전 빌드된 바이너리를 내려받아 사용할 수 있습니다.

3. 기본 사용법

(1) 파일시스템 스캔

# 현재 디렉토리 스캔 후 취약점 결과 출력
./scalibr scan --result=result.json /path/to/project

# SPDX 형식으로 SBOM 생성
./scalibr scan --output=sbom.spdx.json /path/to/project

(2) 컨테이너 이미지 스캔

./scalibr scan --image=ubuntu:22.04 --result=result.json

(3) 결과 확인

# JSON 결과 파일에서 취약점 목록 조회
cat result.json | jq '.findings[].adv.id'

4. 활용 시나리오

OSV-SCALIBR은 CI/CD 파이프라인에 통합하여 빌드·배포 단계에서 자동으로 취약점을 검출하는 데 적합합니다.

# GitHub Actions 예시
- name: Run OSV-SCALIBR
  run: |
    ./scalibr scan --result=result.json .
    # 취약점 발견 시 빌드 실패
    jq -e '.findings | length == 0' result.json

5. 참고 자료

• OSV-SCALIBR GitHub: https://github.com/google/osv-scalibr
• OSV 데이터베이스: https://osv.dev/
• SPDX 공식 사이트: https://spdx.dev/

5.5 - cdxgen

cdxgen은 OWASP(Open Web Application Security Project)가 관리하는 오픈소스 SBOM 생성 도구입니다. 소스 코드, 빌드 결과물, 컨테이너 이미지를 분석하여 CycloneDX 형식의 SBOM을 자동으로 생성합니다.

• GitHub: https://github.com/CycloneDX/cdxgen
• 라이선스: Apache-2.0

주요 특징

• 광범위한 언어·생태계 지원: Java(Maven/Gradle), Node.js, Python, Go, Rust, PHP, Ruby, .NET 등 20개 이상
• 다양한 스캔 대상: 소스 코드 디렉토리, 컨테이너 이미지, GitHub 저장소
• CycloneDX 표준 출력: CycloneDX 1.4/1.5/1.6 JSON 및 XML 형식 지원
• REPL 모드: 대화형 인터페이스로 SBOM 탐색 및 조회 가능
• CI/CD 통합: GitHub Actions, GitLab CI 등 주요 파이프라인과 쉽게 연동

설치 방법

Node.js 18 이상이 설치된 환경에서 아래 명령으로 설치합니다.

npm install -g @cyclonedx/cdxgen

또는 Docker 이미지를 사용할 수 있습니다.

docker pull ghcr.io/cyclonedx/cdxgen

기본 사용법

(1) 소스 코드 디렉토리 스캔

# 현재 디렉토리 스캔 후 CycloneDX JSON SBOM 생성
cdxgen -o sbom.json .

# 언어 명시 스캔 (자동 감지 실패 시)
cdxgen -t java -o sbom.json /path/to/project

(2) 컨테이너 이미지 스캔

cdxgen -t docker -o sbom.json ubuntu:22.04

(3) GitHub 저장소 스캔

cdxgen -t github -o sbom.json https://github.com/org/repo

(4) REPL 모드로 SBOM 탐색

cdxgen --repl -o sbom.json .

CI/CD 연동 예시

# GitHub Actions 예시
- name: Generate SBOM with cdxgen
  run: |
    npm install -g @cyclonedx/cdxgen
    cdxgen -o sbom.json .
- name: Upload SBOM
  uses: actions/upload-artifact@v4
  with:
    name: sbom
    path: sbom.json

참고 자료

• cdxgen GitHub: https://github.com/CycloneDX/cdxgen
• CycloneDX 표준: https://cyclonedx.org/
• OWASP CycloneDX: https://owasp.org/www-project-cyclonedx/

5.6 - Syft

Syft는 Anchore가 개발한 오픈소스 SBOM 생성 CLI 도구입니다. 컨테이너 이미지, 파일시스템, 아카이브를 스캔하여 포함된 패키지를 식별하고 SPDX 또는 CycloneDX 형식의 SBOM을 생성합니다.

• GitHub: https://github.com/anchore/syft
• 라이선스: Apache-2.0

주요 특징

• 다양한 스캔 대상: 컨테이너 이미지(Docker, OCI), 로컬 파일시스템, tar 아카이브
• 폭넓은 생태계 지원: Alpine(apk), Debian/Ubuntu(dpkg), RPM, Python, Java, Go, Node.js, Ruby, Rust 등
• 표준 출력 형식: SPDX 2.2/2.3 (JSON·tag-value), CycloneDX 1.4/1.5 (JSON·XML), Syft JSON
• Grype 연동: Anchore의 취약점 스캐너 Grype와 자연스럽게 연동하여 SBOM 기반 취약점 분석 가능
• 빠른 설치: 단일 바이너리 배포, 별도 런타임 불필요

설치 방법

스크립트 설치 (Linux/macOS)

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

Homebrew (macOS)

brew install syft

Docker

docker pull anchore/syft

기본 사용법

(1) 컨테이너 이미지 스캔

# Docker 이미지 스캔 (SPDX JSON 출력)
syft ubuntu:22.04 -o spdx-json=sbom.spdx.json

# CycloneDX JSON 출력
syft ubuntu:22.04 -o cyclonedx-json=sbom.cdx.json

(2) 로컬 디렉토리 스캔

syft dir:/path/to/project -o spdx-json=sbom.spdx.json

(3) 표준 출력으로 결과 확인

# 터미널에서 패키지 목록 확인
syft ubuntu:22.04

# JSON 형식으로 표준 출력
syft ubuntu:22.04 -o json

(4) Grype와 연동하여 취약점 스캔

# Syft로 SBOM 생성 후 Grype로 취약점 분석
syft ubuntu:22.04 -o json | grype

CI/CD 연동 예시

# GitHub Actions 예시
- name: Generate SBOM with Syft
  uses: anchore/sbom-action@v0
  with:
    image: myapp:latest
    format: spdx-json
    output-file: sbom.spdx.json
- name: Upload SBOM
  uses: actions/upload-artifact@v4
  with:
    name: sbom
    path: sbom.spdx.json

참고 자료

• Syft GitHub: https://github.com/anchore/syft
• Grype(취약점 스캐너): https://github.com/anchore/grype
• SPDX 표준: https://spdx.dev/
• CycloneDX 표준: https://cyclonedx.org/

5.7 - Dependency-Track

Dependency-Track은 OWASP가 관리하는 오픈소스 SBOM 관리 및 취약점 분석 플랫폼입니다. 업로드된 SBOM(CycloneDX, SPDX)을 기반으로 컴포넌트별 취약점을 지속적으로 모니터링하고, 정책 위반 여부를 자동으로 평가합니다.

• GitHub: https://github.com/DependencyTrack/dependency-track
• 공식 문서: https://docs.dependencytrack.org/
• 라이선스: Apache-2.0

주요 특징

• SBOM 기반 지속 모니터링: SPDX 및 CycloneDX 형식의 SBOM을 업로드하면 컴포넌트별 최신 취약점을 자동으로 추적
• 다양한 취약점 데이터소스 연동: NVD, OSV, GitHub Advisories, VulnDB 등
• 정책 엔진: 라이선스 정책, 취약점 심각도 기준, 컴포넌트 사용 가능 여부를 규칙으로 정의하여 자동 평가
• REST API: CI/CD 파이프라인과 통합하여 빌드 시 SBOM을 자동 업로드하고 결과를 피드백
• 웹 UI 대시보드: 프로젝트별 위험 점수, 취약점 현황, 라이선스 분포를 한눈에 파악
• 알림: Slack, 이메일, Webhook 등 다양한 채널로 신규 취약점 알림 발송

설치 방법

Docker Compose를 사용하는 방법이 가장 간편합니다.

# 공식 Docker Compose 파일 다운로드
curl -LO https://dependencytrack.org/docker-compose.yml

# 실행
docker compose up -d

기본적으로 API 서버는 포트 8081, 프론트엔드는 포트 8080에서 실행됩니다. 초기 관리자 계정: admin / admin (최초 로그인 후 즉시 변경 필요)

기본 사용법

(1) 웹 UI에서 프로젝트 생성 및 SBOM 업로드

1. http://localhost:8080 접속
2. Projects → Create Project 클릭
3. 프로젝트 이름·버전 입력 후 저장
4. 해당 프로젝트 → Components 탭 → Upload BOM 클릭
5. SBOM 파일(.cdx.json 또는 .spdx.json) 업로드

업로드 후 Dependency-Track이 자동으로 취약점 분석을 시작합니다.

(2) API를 통한 SBOM 업로드 (CI/CD 연동)

# API Key는 Administration > Access Management > Teams에서 발급
API_KEY="your-api-key"
PROJECT_UUID="your-project-uuid"

curl -X PUT \
  "http://localhost:8081/api/v1/bom" \
  -H "X-Api-Key: ${API_KEY}" \
  -H "Content-Type: multipart/form-data" \
  -F "project=${PROJECT_UUID}" \
  -F "bom=@sbom.cdx.json"

(3) GitHub Actions 연동 예시

- name: Upload SBOM to Dependency-Track
  uses: DependencyTrack/gh-upload-sbom@v3
  with:
    serverhostname: dependency-track.example.com
    apikey: ${{ secrets.DT_API_KEY }}
    project: ${{ secrets.DT_PROJECT_UUID }}
    bomfilename: sbom.cdx.json

cdxgen / Syft와 함께 사용하기

Dependency-Track은 SBOM 생성 도구(cdxgen, Syft)와 함께 사용할 때 가장 효과적입니다.

cdxgen 또는 Syft  →  SBOM 생성  →  Dependency-Track 업로드  →  지속 모니터링

• SBOM 생성: cdxgen 또는 Syft로 빌드 시 SBOM 생성
• 중앙 관리: Dependency-Track에 업로드하여 전사 프로젝트 취약점 현황 통합 관리

참고 자료

• Dependency-Track 공식 문서: https://docs.dependencytrack.org/
• Dependency-Track GitHub: https://github.com/DependencyTrack/dependency-track
• CycloneDX 표준: https://cyclonedx.org/

6 - Archive

현재는 최신 가이드로 대체된 구버전 문서가 보관되어 있습니다.

6.1 - 오픈소스 보안 보증: ISO/IEC 18974 기업 도입 및 인증 가이드

오픈소스 보안 보증: ISO/IEC 18974 기업 도입 및 인증 가이드는 현대 소프트웨어 개발 환경에서 필수적인 요소가 된 오픈소스 소프트웨어(OSS)의 안전한 활용을 위한 지침을 제공합니다. 이 가이드는 오픈소스 소프트웨어의 사용 증가와 함께 중요성이 더욱 강조되고 있는 보안 문제에 대한 효과적인 해결 방안을 제시하고, 국제 표준인 ISO/IEC 18974 인증 획득을 위한 단계별 절차와 핵심 전략을 상세히 안내합니다.

본 가이드의 주요 목표는 다음과 같습니다.

1. ISO/IEC 18974 표준에 대한 이해: ISO/IEC 18974의 핵심 요구사항과 구현 방법을 명확하게 설명하여 조직이 오픈소스 보안 관리 체계를 효과적으로 구축할 수 있도록 지원합니다.
2. 조직 특성별 맞춤형 전략 제시: 대기업, 중소기업, 스타트업 등 다양한 규모와 특성을 가진 조직이 ISO/IEC 18974를 성공적으로 구현할 수 있도록 맞춤형 접근 방식을 제공합니다.
3. 실질적인 가이드라인 및 템플릿 제공: 정책 수립, SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) 관리, 취약점 대응 등 각 단계별 필요한 구체적인 가이드라인과 템플릿을 제공하여 실무 적용을 돕습니다.
4. 성공 사례 및 교훈 공유: ISO/IEC 18974 인증 획득에 성공한 기업들의 사례를 분석하고, 성공 요인과 실패 요인을 공유하여 조직이 시행착오를 줄이고 효율적으로 인증을 획득할 수 있도록 지원합니다.

본 가이드의 주요 대상 독자는 다음과 같습니다.

• 오픈소스 소프트웨어 보안 관리 담당자
• 소프트웨어 개발자 및 엔지니어
• 정보 보안 책임자(CISO) 및 IT 관리자
• 법무 및 컴플라이언스 담당자
• 오픈소스 프로그램 오피스(OSPO) 담당자

이 가이드를 통해 독자들은 ISO/IEC 18974 표준을 효과적으로 이해하고, 조직의 오픈소스 보안 관리 역량을 강화하며, 더 나아가 안전하고 신뢰할 수 있는 소프트웨어 개발 생태계를 구축하는 데 기여할 수 있을 것입니다.

참고 문헌

본 가이드는 다음 자료들을 참고하여 작성되었습니다.

1. ISO/IEC 18974:2023, Information technology - Open source supply chain security assurance
2. ISO/IEC 5230:2020, Information technology - OpenChain Specification
3. The Linux Foundation, OpenChain Project: https://www.openchainproject.org/
4. National Institute of Standards and Technology (NIST), National Vulnerability Database (NVD): https://nvd.nist.gov/
5. Common Vulnerabilities and Exposures (CVE): https://cve.mitre.org/
6. OWASP (Open Web Application Security Project): https://owasp.org/
7. PwC, Understanding the open source security ISO 18974: https://www.pwc.de/en/digitale-transformation/open-source-software-management-and-compliance/understanding-the-open-source-security-iso-18974.html
8. The Momentum, Integrating DevSecOps: A Guide to Development, Security and Operations: https://www.themomentum.ai/blog/integrating-devsecops-a-guide-to-development-security-and-operations
9. Enterprise Networking Planet, Integrating IT Security With DevSecOps Best Practices: https://www.enterprisenetworkingplanet.com/management/integrating-it-security-with-devsecops-best-practices/
10. Synopsys, What is Software Composition Analysis?: https://www.synopsys.com/glossary/what-is-software-composition-analysis.html
11. GuideM, DORA vs. ISO 27001: https://www.guidem.com/en/dora-vs-iso-27001/
12. 해외정보보호 동향, 주요국의 사이버 복원력 강화 정책 동향: https://www.kisa.or.kr/cmm/fms/FileDown.do?atchFileId=FILE_0000000000024149&fileSn=1

6.1.1 - 1. 오픈소스 보안, 왜 중요한가?

이 단원에서는 오픈소스 소프트웨어와 보안 보증의 개념을 소개하고, ISO/IEC 18974 표준의 개발 배경, 목적, 중요성, 그리고 인증 혜택을 설명합니다.

1.1 오픈소스 소프트웨어와 보안 보증의 개념

오픈소스 소프트웨어(OSS, Open Source Software)는 소스 코드가 공개되어 있어 누구나 자유롭게 사용, 수정, 배포할 수 있는 소프트웨어를 말합니다. 이는 투명성, 협업, 혁신을 촉진하는 장점이 있지만, 동시에 보안 위험도 수반합니다.

오픈소스 소프트웨어의 특징

• 소스 코드 공개
• 자유로운 사용, 수정, 배포
• 커뮤니티 기반 개발
• 비용 효율성

표 1.1: 오픈소스 소프트웨어의 장점과 단점

현대 소프트웨어 개발에서 오픈소스는 필수적인 요소가 되었습니다. 많은 기업들이 자체 개발보다 오픈소스 컴포넌트를 활용하여 개발 시간과 비용을 절감하고 있습니다. 그러나 이는 소프트웨어 공급망에 새로운 위험을 도입했습니다.

오픈소스 사용으로 인한 주요 보안 위험은 다음과 같습니다.

1. 알려진 취약점(CVE, Common Vulnerabilities and Exposures): CVE 등에 등록된 공개된 취약점을 악용한 공격에 노출될 수 있습니다.
   • 예시: 2021년 발생한 Log4Shell 취약점(CVE-2021-44228)은 Apache Log4j라는 널리 사용되는 오픈소스 로깅 라이브러리에서 발견되었으며, 전 세계적으로 수많은 시스템에 심각한 영향을 미쳤습니다. 이 취약점을 통해 공격자는 원격 코드 실행이 가능했습니다.
2. 악성코드 삽입: 오픈소스 저장소에 악성 코드가 삽입된 경우, 이를 다운로드하여 사용하는 시스템이 감염될 수 있습니다.
3. 라이선스 위반으로 인한 법적 문제: 오픈소스 라이선스 조건을 준수하지 않을 경우 저작권 침해 등의 법적 분쟁이 발생할 수 있습니다.
4. 지원 중단된 컴포넌트 사용: 더 이상 유지보수가 이루어지지 않는 오픈소스 컴포넌트는 새로운 취약점에 대한 대응이 어려워 보안 위험이 증가합니다.

이러한 위험을 관리하기 위해 ‘보안 보증’이 필요합니다. 보안 보증은 소프트웨어가 의도된 대로 안전하게 작동하며, 알려진 취약점이나 악의적인 코드가 없음을 확인하는 프로세스입니다. 이는 위험 완화, 신뢰성 확보, 규제 준수를 위해 필수적입니다.

1.2 ISO/IEC 18974 표준의 개발 배경 및 목표

ISO/IEC 18974는 오픈소스 보안 보증을 위한 국제 표준입니다. 이 표준은 Linux Foundation의 OpenChain 프로젝트에서 시작되었으며, 오픈소스 소프트웨어의 보안 관리를 위한 핵심 요구사항을 정의합니다.

ISO/IEC 18974 표준 개발 배경은 다음과 같습니다.

• 증가하는 오픈소스 사용과 그에 따른 보안 위험: 오픈소스 사용이 증가함에 따라 보안 취약점을 악용한 공격 시도가 늘어나고 있습니다.
• 소프트웨어 공급망 공격의 증가: SolarWinds, Log4Shell 등 소프트웨어 공급망을 공격하여 대규모 피해를 야기하는 사례가 증가하고 있습니다.
• 기업들의 체계적인 오픈소스 보안 관리 필요성 인식: 기업들은 오픈소스 사용에 따른 보안 위험을 인지하고 체계적인 관리 체계 구축의 필요성을 느끼고 있습니다.

ISO/IEC 18974 표준의 주요 목표는 다음과 같습니다.

1. 오픈소스 보안 관리를 위한 표준화된 프레임워크 제공: 기업들이 오픈소스 보안 관리를 위한 일관된 프로세스와 절차를 구축할 수 있도록 지원합니다.
2. 조직의 오픈소스 보안 프로세스 개선: 조직이 자체적인 오픈소스 보안 관리 수준을 평가하고 개선할 수 있는 기준을 제시합니다.
3. 소프트웨어 공급망의 전반적인 보안 강화: 공급망 내 모든 참여자가 오픈소스 보안을 준수하도록 유도하여 전체적인 보안 수준을 향상시킵니다.

1.3 ISO/IEC 18974의 목적과 중요성

ISO/IEC 18974의 주요 목적은 조직이 오픈소스 소프트웨어의 알려진 보안 취약점을 효과적으로 관리할 수 있는 체계를 구축하는 것입니다. 이 표준은 다음과 같은 핵심 영역을 식별합니다.

1. 보안 프로세스가 필요한 주요 지점
2. 역할과 책임의 할당 방법
3. 프로세스의 지속가능성 보장 방법

글로벌 소프트웨어 산업에서 ISO/IEC 18974는 오픈소스 보안 관리의 기준점 역할을 합니다. 이는 기업이 자사의 오픈소스 관리 능력을 객관적으로 평가하고 개선할 수 있는 도구를 제공합니다.

표준 준수는 조직의 지속 가능성에 긍정적인 영향을 미칩니다.

• 보안 사고 감소로 인한 비용 절감: 취약점을 사전에 관리함으로써 보안 사고 발생 가능성을 줄이고, 사고 발생 시 복구 비용을 절감할 수 있습니다.
• 고객 신뢰도 향상: 안전한 소프트웨어 개발 및 제공 능력을 입증하여 고객의 신뢰를 얻을 수 있습니다.
• 규제 준수 용이성 증가: GDPR, CCPA 등 개인정보보호 규제를 준수하는 데 도움이 됩니다.
• 경쟁 우위 확보: 보안을 중시하는 고객의 요구사항을 충족시켜 경쟁사 대비 우위를 확보할 수 있습니다.

1.4 ISO/IEC 18974 인증의 혜택

ISO/IEC 18974 인증을 통해 기업은 다음과 같은 혜택을 얻을 수 있습니다.

1. 체계적인 오픈소스 관리 체계 구축
   • 일관된 보안 정책 및 프로세스 확립
   • 오픈소스 구성 요소의 체계적인 식별, 추적, 제어
   • SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) 생성 및 관리 프로세스 구축
2. 공급망 신뢰도 향상
   • 협력업체 및 고객과의 신뢰 관계 강화
   • 보안 리스크 감소를 통한 비즈니스 안정성 확보
   • 공급업체 평가 시 객관적인 기준 제공
3. 오픈소스 활용 역량 인정
   • 글로벌 수준의 오픈소스 관리 능력 입증
   • 기업 이미지 및 브랜드 가치 향상
   • 새로운 비즈니스 기회 창출
4. 법적 책임 감소
   • 라이선스 의무 준수 및 침해 방지
   • 소송 위험 감소
   • 규제 준수 용이성 증가 (예: DORA, EU Cyber Resilience Act)

요약

ISO/IEC 18974는 오픈소스 보안 관리의 중요성을 강조하고, 기업이 이를 체계적으로 수행할 수 있는 프레임워크를 제공합니다. 이 표준을 준수함으로써 기업은 오픈소스의 이점을 최대한 활용하면서도 관련 위험을 효과적으로 관리할 수 있게 됩니다.

6.1.2 - 2. ISO/IEC 18974의 주요 요구사항

ISO/IEC 18974는 오픈소스 소프트웨어의 보안 보증을 위한 핵심 요구사항을 정의합니다. 이 표준은 조직이 오픈소스 소프트웨어의 알려진 보안 취약점을 효과적으로 관리할 수 있는 체계를 구축하는 데 필요한 지침을 제공합니다. 각 요구사항에 대한 자세한 내용은 부록을 참고하십시오.

2.1 프로그램 기반

이 섹션에서는 오픈소스 보안 보증 프로그램을 위한 기본적인 정책, 역량, 인식, 자원, 그리고 측정에 대한 요구사항을 정의합니다. 프로그램 기반은 조직이 ISO/IEC 18974를 효과적으로 구현하고 지속적으로 유지하기 위한 토대를 제공합니다.

2.1.1 정책 (Policy)

조직은 공급하는 소프트웨어의 오픈소스 소프트웨어 보안 보증을 관리하는 문서화된 정책을 수립해야 합니다. 이 정책은 조직 내 모든 관련자에게 공유되어야 하며, 정책과 그 전달 방법은 최신성과 관련성을 보장하기 위한 검토 프로세스를 거쳐야 합니다.

표 2.1: 정책 (Policy) 요구사항 및 검증 자료

정책 수립 시 고려사항

• 적용 범위: 정책이 적용되는 오픈소스 소프트웨어의 범위 (예: 모든 내부 개발 프로젝트, 외부 공급망 등)를 명확히 정의합니다.
• 역할 및 책임: 오픈소스 보안 관리에 관련된 모든 역할 (예: 개발자, 보안팀, 법무팀, 경영진)의 책임을 명확히 정의합니다.
• 프로세스: 오픈소스 사용 승인, SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) 관리, 취약점 관리, 라이선스 준수 등 주요 프로세스에 대한 지침을 제공합니다.
• 준수: 정책 준수를 위한 모니터링 및 감사 절차를 명시합니다.
• 예외: 정책 예외 상황에 대한 처리 절차를 정의합니다.

2.1.2 역량 (Competence)

조직은 프로그램의 성과와 효과성에 영향을 미치는 역할과 책임을 식별하고, 각 역할을 수행하는 프로그램 참여자에게 필요한 역량을 결정해야 합니다. 또한, 프로그램 참여자들이 적절한 교육, 훈련, 그리고/또는 경험을 갖추도록 보장해야 합니다.

표 2.2: 역량 (Competence) 요구사항 및 검증 자료