Guide

여기에서는 기업의 오픈소스 관리를 위한 가이드를 제공합니다.

Author : OpenChain Korea Work Group Authors / CC BY 4.0

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

ISO 국제 표준에 기반하여 기업이 오픈소스를 효과적으로 관리하기 위한 방안을 소개합니다.

오픈소스는 현대 소프트웨어 개발에 필수적인 요소입니다. 그러나 적절한 관리 없이 오픈소스를 사용하면 기업은 라이선스 컴플라이언스 위반, 보안 취약점 노출 등 심각한 리스크에 직면할 수 있습니다.

이 가이드는 ISO 국제표준을 기반으로 기업이 오픈소스를 효과적으로 관리하기 위해 수행해야 할 핵심 요구사항과 구체적인 실행 방법을 제시합니다.

Author : OpenChain Korea Work Group / CC BY 4.0

최근 업데이트 사항 (2025.1.6):

  • ISO/IEC 18974 (OpenChain Security Assurance Specification) 관련 내용 추가
  • 오픈소스 보안 보증 프로세스 및 요구사항 상세화
  • SBOM (Software Bill of Materials) 관리에 대한 내용 보강
  • 오픈소스 기여 및 공개 프로세스 개선
  • 프로그램 효과성 측정 및 지속적 개선 방안 추가

오픈소스 관리 국제표준

오픈소스 관리를 위한 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 등 소프트웨어 공급망에 걸친 다양한 소프트웨어가 사용될 수 있습니다.

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

[OpenChain Open Source Software License Compliance General Public Guide]

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

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

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

[OpenChain Project Logo]

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 규격의 요구사항을 하나씩 충족해가면서 수준을 향상시키는 것이 좋은 전략입니다.

< 출처 : https://github.com/OpenChain-Project/Specification/blob/master/Official/en/2.1/openchainspec-2.1.pdf>

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

< 출처 : https://www.iso.org/standard/81039.html>

지난 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 프로젝트에서 제안하는 인증 방법은 세 가지입니다:

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

https://www.openchainproject.org/get-started/conformance

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

(1) 자체 인증

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

< 출처 : https://certification.openchainproject.org/>

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

<예: SK텔레콤 인증 선언 - 출처: https://www.openchainproject.org/featured/2021/09/08/sk-telecom>

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

< ISO/IEC 5230 적합 프로그램 보유 선언 기업, 출처 - https://www.openchainproject.org/ >

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

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

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

(2) 독립 평가

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

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

< Independent Compliance Assessment, 출처 - https://youtu.be/DEBd-g0Ab8E >

결국 기업은 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입니다.

< Third-Party Certifiers, 출처 - https://www.openchainproject.org/partners >

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

< PWC certification, 출처 - https://youtu.be/HslvXCM-4pQ >

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

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

4. OpenChain Resources

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

< OpenChain Curriculum, 출처 - https://www.openchainproject.org/resources >

이 가이드의 많은 내용도 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 준수를 요구하는 내용을 포함시켰습니다.

linkedin, May 2021

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

linkedin, July 2021

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 담당
  • 보안 담당
  • 개발 문화 담당

Individuals and teams involved in ensuring open source compliance : https://www.linuxfoundation.org/wp-content/uploads/OpenSourceComplianceHandbook_2018_2ndEdition_DigitalEdition.pdf

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

No역할책임
1오픈소스 프로그램 매니저회사의 오픈소스 프로그램에 대한 총괄 책임을 담당한다.
2법무 담당오픈소스 라이선스와 의무를 해석한다. 이러한 의무를 실제 이행하는 등 오픈소스 활용을 위해 발생할 수 있는 법적 위험의 완화를 위한 자문을 제공한다.
3IT 담당오픈소스 분석 도구를 운영하고 자동화하여 모든 배포용 소프트웨어에 대해 오픈소스 분석이 원활히 수행되도록 시스템을 구축한다.
4보안 담당오픈소스 보안취약점 분석 도구를 운영하여 모든 배포용 소프트웨어에 대해 보안취약점 분석이 수행되도록 시스템을 구축하고 발견된 보안취약점이 기준에 맞게 보완되도록 조치한다.
5개발 문화 담당사내 개발자들이 오픈소스를 적극적으로 활용하고 사내외 커뮤니티에 참여하여 선진 개발 문화를 습득할 수 있도록 지원한다.
6사업 부서소프트웨어 개발/배포 조직은 올바른 오픈소스 활용을 위해 오픈소스 정책 및 프로세스를 준수한다.

2. 필요 역량 정의

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

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

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

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

No역할필요 역량
1오픈소스 프로그램 매니저1. 소프트웨어 개발 프로세스 이해
2. 저작권, 특허 등 오픈소스 라이선스와 관련한 지식재산 이해
3. 오픈소스 컴플라이언스에 대한 전문 지식
4. 오픈소스 개발 경험
5. 커뮤니케이션 스킬
6. 오픈소스 보안 보증에 대한 기본 지식
2법무 담당1. 오픈소스 생태계에 대한 기본 지식
2. 소프트웨어 저작권에 대한 전문 지식
3. 오픈소스 라이선스에 대한 전문 지식
4. 오픈소스 관련 법적 위험 평가 능력
3IT 담당1. 오픈소스 컴플라이언스 프로세스에 기본 지식
2. 오픈소스 분석 도구에 대한 이해
3. IT 인프라에 대한 전문 지식
4. 자동화 및 CI/CD 파이프라인에 대한 이해
4보안 담당1. DevSecOps에 대한 폭넓은 이해
2. 오픈소스 보안취약점 분석 도구에 대한 이해
3. 오픈소스 보안취약점에 대한 전문 지식
4. 커뮤니케이션 스킬
5. 위험 평가 및 관리 능력
5개발 문화 담당1. 소프트웨어 개발 프로세스 이해
2. 오픈소스 컴플라이언스에 대한 기본 지식
3. 오픈소스 정책에 대한 이해
4. 교육 및 트레이닝 설계 능력
5. 오픈소스 커뮤니티 참여 경험
6사업 부서1. 소프트웨어 개발 프로세스 이해
2. 오픈소스 컴플라이언스에 대한 기본 지식
3. 오픈소스 정책에 대한 이해
4. 오픈소스 라이선스에 대한 기본 지식
5. 오픈소스 사용이 비즈니스에 미치는 영향 이해

3. 담당자 지정

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

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

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

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

No역할담당 조직담당자
1오픈소스 프로그램 매니저CTOOOO
2법무 담당법무팀OOO
3IT 담당IT 인프라팀OOO
4보안 담당보안팀OOO
5개발 문화 담당DROOO
6사업 부서개발팀전원

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

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

https://sktelecom.github.io/about/osrb/

4. Summary

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

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

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

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

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

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

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

1.3 - 2. 정책

1. 오픈소스 정책 문서화

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

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

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

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

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

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

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

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

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

  • 공급 소프트웨어에 포함된 모든 오픈소스를 식별하고 문서화
  • 각 오픈소스의 라이선스 의무사항 파악 및 준수
  • 라이선스 의무를 충족하는 컴플라이언스 산출물 생성
  • 오픈소스 고지문 및 소스코드 공개 등 라이선스 의무 이행

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

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

  • 공급 소프트웨어의 오픈소스 컴포넌트에 대한 알려진 취약점 및 새로 발견된 취약점 모니터링
  • 취약점 발견 시 위험/영향 평가 수행
  • 심각한 취약점에 대한 신속한 대응 및 패치 적용
  • 취약점 정보의 고객 통지 및 업데이트 제공

(3) 오픈소스 리스크 대응

오픈소스 사용에 따른 라이선스 및 보안 리스크를 최소화하기 위해 다음 절차를 수립해야 합니다:

  1. 오픈소스 식별 및 라이선스 의무 사항 검토
  2. 오픈소스 라이선스를 고려한 아키텍처 설계
  3. 오픈소스 컴플라이언스 산출물 생성
  4. SBOM (Software Bill of Materials) 생성 및 관리
  5. 오픈소스 라이선스 컴플라이언스 이슈 대응
  6. 오픈소스 보안 취약점 대응

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

1. 오픈소스 사용

공급 소프트웨어를 개발하고 배포할 때 각 오픈소스 라이선스가 요구하는 의무 사항을 준수해야 합니다. 이를 위한 활동을 오픈소스 라이선스 컴플라이언스라고 합니다.

올바른 오픈소스 라이선스 컴플라이언스 활동과 보안 보증을 위해 소프트웨어 개발/배포 조직은 다음 사항을 준수하고 모든 과정은 이슈 추적 시스템에 기록하여 보존합니다. 

(1) 오픈소스 식별 및 라이선스 의무 사항 검토

오픈소스를 공급 소프트웨어 개발에 도입 시, 먼저 오픈소스 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무 사항을 검토하고 확인합니다.

회사의 [오픈소스 라이선스 가이드]에는 주요 오픈소스 라이선스 목록이 포함되어 있으며, 라이선스마다 다음의 배포 형태별 요구하는 의무사항을 구분하여 설명합니다.

- 바이너리 형태
- 소스 형태
- 강한/약한 Copyleft
- SaaS 기반 제공
- 수정 여부
- 저작자 표시 요구 오픈소스 포함 등

소프트웨어 개발/배포 조직은 오픈소스 라이선스 의무 검토 시 이 가이드를 참고할 수 있습니다. 이 가이드에서 언급하지 않는 오픈소스 라이선스의 검토가 필요할 경우, 오픈소스 프로그램 매니저에게 문의합니다.

(2) 오픈소스 라이선스 고려 설계

오픈소스의 결합 관계를 파악하여 자사의 코드가 오픈소스 라이선스의 영향을 받지 않도록 소프트웨어 아키텍처를 설계합니다.

회사의 [오픈소스 라이선스 가이드]에서는 오픈소스 라이선스별 소스 코드 공개 범위 및 자사 코드의 공개를 방지하기 위한 설계 방법을 설명합니다.

(3) 오픈소스 컴플라이언스 산출물 생성

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

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

1. 오픈소스 고지문 : 오픈소스 라이선스 전문과 저작권 정보 제공을 위한 문서
2. 공개할 소스 코드 패키지 : GPL, LGPL 등 소스 코드 공개를 요구하는 오픈소스 라이선스 의무 이행을 위해 공개할 소스 코드를 취합한 패키지

이러한 컴플라이언스 산출물을 취합, 배포, 보관하기 위해 다음 사항을 준수합니다.

- 오픈소스 고지문이나 공개할 소스 코드 패키지는 각 라이선스가 요구하는 조건대로 취합합니다. 예를 들어, 라이선스가 라이선스 전체 텍스트의 동봉을 요구하는데, 링크만을 제공해서는 안 됩니다.
- 취합한 산출물은 별도의 저장소에 보관합니다.
- 공개할 소스 코드를 서면 청약으로 제공할 경우, 취합한 산출물의 저장소를 외부에서 접근할 수 있도록 다운로드 링크를 공개합니다.
  
회사의 오픈소스 프로세스를 통해 오픈소스 고지문을 발급하고, 공개할 소스 코드 패키지를 취합할 수 있습니다.

(4) SBOM (Software Bill of Materials) 생성

공급 소프트웨어를 구성하는 각 오픈소스 소프트웨어 컴포넌트 내역을 포함하는 SBOM(Software Bill of Materials)을 생성하고 이를 유지하는 프로세스가 있어야 합니다.

회사의 오픈소스 프로세스를 통해 오픈소스 도구를 활용하여 SBOM을 생성하고 보존할 수 있습니다.

(5) 컴플라이언스 이슈 대응 절차

컴플라이언스 이슈가 제기될 경우, 오픈소스 프로그램 매니저는 다음의 절차를 수행하여 신속히 대응합니다.

1. 문의 접수를 확인하고 적절한 해결 시간을 명시합니다.
2. 이슈 내용이 실제 문제를 지적하고 있는지를 확인합니다. (아닐 경우, 이슈 제기자에게 문제가 아님을 알립니다.)
3. 실제 문제인 경우, 우선순위를 정하고 적절한 대응 방안을 결정합니다.
4. 대응을 수행하고, 필요할 경우, 오픈소스 프로세스를 적절하게 보완합니다.
5. 위의 내용은 이슈 추적 시스템을 이용하여 보존합니다.

(6) 오픈소스 보안 보증 관리

공급 소프트웨어의 오픈소스 소프트웨어 컴포넌트에 대한 알려진 취약점의 탐지 및 해결을 위한 문서화된 절차를 수립하고 유지해야 합니다. 이 절차에는 다음 사항이 포함되어야 합니다:

- 알려진 취약점의 존재를 발견하기 위한 방법 적용
- 각 발견된 취약점에 대한 위험/영향 평가
- 필요한 경우 고객에게 연락, 소프트웨어 컴포넌트 업그레이드 등 적절한 조치 수행

또한 다음과 같은 프로세스를 구축해야 합니다:

- 공급 소프트웨어에 대한 구조적 및 기술적 위협 식별
- 지속적이고 반복적인 보안 테스트 적용
- 식별된 위험이 공급 소프트웨어의 출시 전에 해결되었는지 확인
- 공급 소프트웨어가 시장에 출시된 후 모니터링 및 대응 기능 확보

각 오픈소스 소프트웨어 컴포넌트에 대해 식별된 알려진 취약점 및 새로 발견된 취약점, 그리고 수행된 조치에 대한 기록을 유지해야 합니다.

(4) 내부 책임 할당 절차

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

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

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

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

4. 역할, 책임 및 역량

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

(2) 오픈소스 프로그램 매니저

- 오픈소스 라이선스 컴플라이언스를 위해 필요한 역할을 정의하고, 각 역할을 책임질 담당 조직 및 담당자를 지정합니다. 필요 시 OSRB와 협의합니다. 

(6) 보안 담당

- 오픈소스 보안 보증을 성공할 수 있도록 각 업무에 대한 책임을 할당합니다.

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

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

(5) 미준수 사례 대응

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

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

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

6. 오픈소스 사용

(5) 컴플라이언스 및 보안 보증 이슈 대응 절차

라이선스 컴플라이언스 또는 보안 보증 이슈가 제기될 경우, 오픈소스 프로그램 매니저는 다음의 절차를 수행하여 신속히 대응합니다:

1. 문의 접수를 확인하고 적절한 해결 시간을 명시합니다.
2. 이슈 내용이 실제 문제를 지적하고 있는지를 확인합니다. (아닐 경우, 이슈 제기자에게 문제가 아님을 알립니다.)
3. 실제 문제인 경우, 우선순위를 정하고 적절한 대응 방안을 결정합니다.
   - 라이선스 컴플라이언스 이슈의 경우, 법무 담당과 협의하여 라이선스 의무 준수 방안을 수립합니다.
   - 보안 보증 이슈의 경우, 보안 담당과 협의하여 취약점 해결 방안을 수립합니다.
4. 대응을 수행하고, 필요할 경우 오픈소스 프로세스를 적절하게 보완합니다.
5. 위의 내용은 이슈 추적 시스템을 이용하여 기록하고 보존합니다.
6. 미준수 사례에 대한 근본 원인을 분석하고, 재발 방지를 위한 개선 계획을 수립합니다.
7. OSRB(Open Source Review Board)에 미준수 사례와 대응 결과를 보고하고, 필요시 정책 및 프로세스 개선 방안을 논의합니다.

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

(6) 인원, 예산 지원

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

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

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

4. 역할, 책임 및 역량

각 역할에 대한 담당 조직의 장은 조직 내 담당자를 지정하고, 담당자가 역할을 충실하게 수행할 수 있는 적절한 시간과 예산을 할당합니다.

- 각 역할의 담당자는 자신이 역할을 수행하면서 적절한 지원이 되지 않는다면 오픈소스 프로그램 매니저에게 문제를 제기해야 합니다.
- 오픈소스 프로그램 매니저는 해당 조직장과 문제 해결을 논의합니다. 적절하게 해결되지 않는다면, 오픈소스 프로그램 매니저는 OSRB에 문제 해결을 요청할 수 있습니다.
- OSRB는 상위 조직의 장에게 문제를 공유하고 해결을 요청합니다.

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

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

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

(7) 전문 자문 제공

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

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

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

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

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

4. 역할, 책임 및 역량

(4) 법무 담당

법무 담당은 오픈소스 라이선스와 의무를 해석하는 등 오픈소스 활용 과정에서 발생할 수 있는 법적 위험과 완화 방안에 대한 자문을 제공합니다.

- 프로그램 참여자가 오픈소스 라이선스 컴플라이언스 이슈에 대한 문의를 할 수 있는 합리적인 방법을 제공합니다.
- 호환되지 않는 오픈소스 라이선스로 인한 충돌을 포함하여 라이선스 및 지식재산권 문제에 대해 자문을 제공합니다.
- 외부 오픈소스 프로젝트로의 기여 시 오픈소스 라이선스, CLA(Contributor License Agreement) 등 필요한 법적 사항을 검토합니다.
- 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인에 자문을 요청합니다.

(6) 보안 담당

보안 담당은 오픈소스 보안 취약점 분석 도구를 운영하여 모든 공급 소프트웨어에 대해 보안 취약점 분석이 원활히 수행되도록 시스템을 구축합니다.

- 프로그램 참여자가 알려진 취약점 또는 새로 발견된 취약점에 대한 문의를 할 수 있는 합리적인 방법을 제공하고, 취약점 해결을 위해 필요 시 외부 전문 기술 자문을 이용합니다.

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

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

(8) 적용 범위 지정

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

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

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

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

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

2. 적용 범위

이 정책은 다음 세 부분에 적용됩니다.

1. 회사가 외부로 제공하거나 배포하는 모든 공급 소프트웨어에 적용됩니다. 단, 오픈소스를 내부 사용 목적으로만 사용하는 것은 이 정책의 범위에 포함되지 않습니다.
2. 프로그램 참여자가 외부 오픈소스 프로젝트에 기여할 때 적용됩니다.
3. 내부 코드를 오픈소스로 공개할 때 적용됩니다.

적용 범위는 회사의 비즈니스 환경에 맞추어 변경할 수 있습니다. 특히, 오픈소스 프로그램 매니저는 지속적인 효과를 보장하기 위해 이 정책의 적용되지 않고 사외로 배포 혹은 서비스되는 공급 소프트웨어가 있는지 월 1회 이상 조사합니다. 이를 측정하여 1건이라도 발견 시 적용 범위를 변경해야 하는 기준으로 삼습니다.

적용 범위를 변경하기 위한 절차는 다음과 같습니다.

1. 오픈소스 프로그램 매니저는 신규사업, 조직개편 등 회사의 비즈니스 환경이 변화에 따라 정책의 적용 범위 변경이 필요하다고 판단할 경우, 이를 위한 제안을 OSRB에 제출합니다.
2. OSRB에서는 적절한 수준의 적용 범위 변경을 승인합니다.
3. OSRB는 오픈소스 정책을 수정하여 정책의 적용 범위를 변경합니다.

오픈소스 프로그램 매니저는 지속적으로 월 1회 이상 적용 범위를 개선하기 위해 검토, 업데이트 및 검사 이력을 [Jira](https://www.atlassian.com/software/jira) Issue Tracker를 활용하여 문서화합니다.

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

(9) 외부 문의 대응

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

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

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

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

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

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

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

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

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

9. 외부 문의 대응

(1) 외부 문의 대응 책임

외부로부터 오픈소스에 대한 문의 및 요청에 대한 대응은 오픈소스 프로그램 매니저가 담당합니다.

- 오픈소스 프로그램 매니저는 회사 내의 적절한 프로그램 참여자에게 문의에 대한 전체 또는 일부의 처리를 할당할 수 있습니다. 필요할 경우 법률 담당자에게 문의하여 처리합니다.
- 외부로부터 오픈소스에 대한 문의를 받은 프로그램 참여자는 누구나 이를 오픈소스 프로그램 매니저에게 알려서 신속한 대응이 될 수 있게 합니다.

(2) 연락처 공개

오픈소스 프로그램 매니저는 외부에서 오픈소스 관련한 문의 및 요청을 할 수 있도록 담당자의 연락처를 공개적으로 제공합니다.

- 오픈소스 고지문에 연락받을 수 있는 이메일 주소 정보를 제공합니다.
- 오픈소스 웹사이트에 이메일 주소 정보를 제공합니다.
- Linux Foundation의 Open Compliance Directory에 연락처를 등록합니다.

(3) 외부 문의 대응 절차

외부로부터의 오픈소스 문의에 신속하고 정확하게 대응한다면 클레임이나 법적 소송 위험을 크게 줄일 수 있습니다. 이를 위해 회사는 외부의 오픈소스 문의에 대응하기 위해 회사의 오픈소스 프로세스에서 정의한 외부 문의 대응 절차를 준수합니다.

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

SK텔레콤 오픈소스 고지문

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

SK텔레콤 오픈소스 웹사이트

(10) 오픈소스 기여

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

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

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

7. 오픈소스 기여

회사는 오픈소스에서의 비즈니스 가치 창출을 위해 외부 오픈소스 프로젝트로의 참여와 기여를 권장합니다. 그러나 이 과정에서 의도하지 않은 회사의 지식 재산 노출 혹은 제 3자의 권리 침해에 주의해야 합니다. 이를 위해 회사의 프로그램 참여자가 외부 오픈소스 프로젝트로의 기여를 위해서는 다음 사항을 준수해야 합니다.

(1) 리뷰 요청 및 승인

오픈소스 기여는 저작권 관점에서 저작자가 저작물을 수정/사용/배포할 수 있는 권한을 오픈소스 프로젝트에 부여하는 것입니다. 때에 따라서는 오픈소스 프로젝트에 저작권을 양도해야 하기도 합니다. 일반적으로 고용 기간에 만든 저작물의 저작권은 고용주가 소유합니다. 즉, 프로그램 참여자가 만든 저작물은 회사가 소유합니다. 프로그램 참여자가 임의로 저작물을 오픈소스에 기여하는 행위는 불필요한 저작권 침해 이슈를 유발할 수 있습니다.

따라서, 기여하고자 하는 오픈소스 프로젝트가 있다면 오픈소스 기여 프로세스에 따라 최초 기여하기 전에 리뷰 요청 및 승인 절차를 준수합니다.

단, 다음과 같이 단순한 내용일 경우, 저작권 침해 리스크가 크지 않기 때문에 리뷰 절차 없이 프로그램 참여자의 판단에 따라 기여할 수 있습니다.

- 10 라인 이하의 작은 코드 조각
- Stack Overflow에서의 문의 / 답변
- GitHub에서의 관리 활동 : Issue 생성, Pull Request Review / Approve 등

...

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

(11) SBOM 생성 및 관리

SBOM (Software Bill of Materials) 생성 및 관리 절차를 수립해야 합니다:

  • SBOM 생성 도구 및 방법론 선정
  • SBOM 정보의 정확성 및 완전성 보장
  • SBOM 업데이트 및 버전 관리 프로세스 수립
  • SBOM 공유 및 배포 방법 정의

기업은 아래의 예시와 같이 오픈소스 정책에 SBOM 생성 및 관리에 대한 내용을 반영할 수 있습니다:

6. 오픈소스 사용

(4) SBOM (Software Bill of Materials) 생성

공급 소프트웨어를 구성하는 각 오픈소스 소프트웨어 컴포넌트 내역을 포함하는 SBOM(Software Bill of Materials)을 생성하고 이를 유지하는 프로세스가 있어야 합니다.

회사의 오픈소스 프로세스를 통해 오픈소스 도구를 활용하여 SBOM을 생성하고 보존할 수 있습니다.

- SBOM은 [SPDX](https://spdx.dev/) 또는 [CycloneDX](https://cyclonedx.org/)와 같은 표준 형식을 사용하여 생성합니다.
- 모든 공급 소프트웨어에 대해 SBOM을 생성하고 관리합니다.
- SBOM은 공급 소프트웨어의 릴리스마다 업데이트하고 버전 관리합니다.
- SBOM 정보의 정확성을 주기적으로 검증합니다.
- 필요한 경우 고객 및 규제 기관과 SBOM을 공유할 수 있도록 준비합니다.

SBOM 생성 및 관리는 오픈소스 라이선스 컴플라이언스와 보안 보증을 위한 핵심 요소입니다. 이를 통해 기업은 사용 중인 오픈소스 컴포넌트를 정확히 파악하고, 알려진 취약점이나 라이선스 이슈에 신속하게 대응할 수 있습니다.

기업은 이러한 SBOM 관련 원칙을 오픈소스 정책에 포함하여, 체계적인 SBOM 관리 체계를 구축해야 합니다.

3. Summary

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

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

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

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

  1. 오픈소스 라이선스 컴플라이언스 원칙
  2. 오픈소스 보안 보증 원칙
  3. 오픈소스 리스크 대응 방안
  4. 내부 책임 할당 절차
  5. 미준수 사례 대응 방법
  6. 인원 및 예산 지원 계획
  7. 전문 자문 제공 방식
  8. 정책의 적용 범위 지정
  9. 외부 문의 대응 절차
  10. 오픈소스 기여 가이드라인
  11. SBOM(Software Bill of Materials) 생성 및 관리 방법

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

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

1.4 - 3. 프로세스

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

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

Simplified view of the compliance end-to-end process : https://www.linuxfoundation.org/wp-content/uploads/OpenSourceComplianceHandbook_2018_2ndEdition_DigitalEdition.pdf

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

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

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

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

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. 오픈소스 고지문: 오픈소스 라이선스 전문과 저작권 정보 제공을 위한 문서

  1. 공개할 소스 코드 패키지: 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주 이내 |
  1. 보고 및 문서화: 검사 결과, 평가 내용, 대응 계획을 문서화하고 관련 이해관계자에게 보고합니다.

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

이러한 프로세스를 통해 공급 소프트웨어의 보안 취약점을 효과적으로 관리하고, 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) 프로세스 업데이트 문서화

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

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

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

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

6. Summary

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

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

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

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

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

    • 체계적인 외부 문의 처리 프로세스 수립
    • 신속하고 정확한 대응을 통한 법적 위험 감소
  4. 오픈소스 기여 활동의 체계화

    • 기여 정책 수립을 통한 일관된 기여 활동 보장
    • 기여 검토 및 승인 절차를 통한 지식재산 보호
  5. 지속적인 프로세스 개선

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

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

1.5 - 4. 도구

1. 소스 코드 스캔 도구

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

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

(1) FOSSology

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

https://www.fossology.org/

주요 기능:

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

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 형식의 보고서 생성

https://github.com/oss-review-toolkit/ort#analyzer

(2) FOSSLight Dependency Scanner

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

주요 기능:

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

https://fosslight.org/ko/scanner/

이러한 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

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

주요 기능:

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

https://fosslight.org/fosslight-guide/started/2_try/4_project.html

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

https://fosslight.org/

이러한 도구들을 활용하여 기업은 효과적으로 오픈소스 거버넌스를 수행하고 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도 이와 유사하게 보안취약점 정보를 자동으로 취득하고, 보안취약점이 검출된 프로젝트 정보를 자동으로 확인하여 필요 시 메일 등 알림을 제공합니다.

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

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

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

(1) onot

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

onot 설치방법

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

onot 생성 오픈소스 고지문 샘플

(2) FOSSLight

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

https://fosslight.org/fosslight-guide/started/2_try/4_project.html

이러한 도구들을 활용하면 오픈소스 고지문 생성 과정을 자동화하고 표준화할 수 있어, 오픈소스 라이선스 컴플라이언스 프로세스의 효율성과 정확성을 높일 수 있습니다. 또한 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텔레콤의 오픈소스 웹사이트에서 참고하실 수 있습니다.

https://sktelecom.github.io/compliance/

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

https://github.com/sktelecom/sktelecom.github.io

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

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

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

(1) Jenkins 플러그인

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

주요 Jenkins 플러그인:

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의 요구사항을 충족하는 데 큰 도움을 받을 수 있습니다.

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

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에 공개했습니다.

https://github.com/ncsoft/oss-basic-training

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

http://t1.kakaocdn.net/olive/assets/opensource_guide_kakao.pdf

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

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

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

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

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의 모든 요구사항을 충족하게 되며, 오픈소스 라이선스 컴플라이언스와 보안 보증에 대한 지속적인 관리와 개선을 보장할 수 있습니다.

2 - 오픈소스 보안 보증: ISO/IEC 18974 기업 도입 및 인증 가이드

기업이 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

2.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는 오픈소스 보안 관리의 중요성을 강조하고, 기업이 이를 체계적으로 수행할 수 있는 프레임워크를 제공합니다. 이 표준을 준수함으로써 기업은 오픈소스의 이점을 최대한 활용하면서도 관련 위험을 효과적으로 관리할 수 있게 됩니다.

2.2 - 2. ISO/IEC 18974의 주요 요구사항

ISO/IEC 18974는 오픈소스 소프트웨어의 보안 보증을 위한 핵심 요구사항을 정의합니다. 이 표준은 조직이 오픈소스 소프트웨어의 알려진 보안 취약점을 효과적으로 관리할 수 있는 체계를 구축하는 데 필요한 지침을 제공합니다. 각 요구사항에 대한 자세한 내용은 부록을 참고하십시오.

2.1 프로그램 기반

이 섹션에서는 오픈소스 보안 보증 프로그램을 위한 기본적인 정책, 역량, 인식, 자원, 그리고 측정에 대한 요구사항을 정의합니다. 프로그램 기반은 조직이 ISO/IEC 18974를 효과적으로 구현하고 지속적으로 유지하기 위한 토대를 제공합니다.

2.1.1 정책 (Policy)

조직은 공급하는 소프트웨어의 오픈소스 소프트웨어 보안 보증을 관리하는 문서화된 정책을 수립해야 합니다. 이 정책은 조직 내 모든 관련자에게 공유되어야 하며, 정책과 그 전달 방법은 최신성과 관련성을 보장하기 위한 검토 프로세스를 거쳐야 합니다.

표 2.1: 정책 (Policy) 요구사항 및 검증 자료

요구사항 (Requirement)원문 (Original Text)한글 번역 (Korean Translation)
2.1.1 정책 (Policy)A written policy shall be created that governs open source software security assurance of supplied software. The policy shall be internally communicated. The policy and its method of communication shall have a review process to ensure they are current and relevant.공급 소프트웨어의 오픈소스 소프트웨어 보안 보증을 관리하는 문서화된 정책을 수립해야 합니다. 이 정책은 내부적으로 전달되어야 합니다. 정책과 그 전달 방법은 현재성과 관련성을 보장하기 위한 검토 프로세스를 가져야 합니다.
검증 자료 (Verification Materials)4.1.1.1: A documented open source software security assurance policy
4.1.1.2: A documented procedure to make program participants aware of the security assurance policy
4.1.1.1: 문서화된 오픈소스 소프트웨어 보안 보증 정책
4.1.1.2: 프로그램 참여자들에게 보안 보증 정책을 인식시키기 위한 문서화된 절차

정책 수립 시 고려사항

  • 적용 범위: 정책이 적용되는 오픈소스 소프트웨어의 범위 (예: 모든 내부 개발 프로젝트, 외부 공급망 등)를 명확히 정의합니다.
  • 역할 및 책임: 오픈소스 보안 관리에 관련된 모든 역할 (예: 개발자, 보안팀, 법무팀, 경영진)의 책임을 명확히 정의합니다.
  • 프로세스: 오픈소스 사용 승인, SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) 관리, 취약점 관리, 라이선스 준수 등 주요 프로세스에 대한 지침을 제공합니다.
  • 준수: 정책 준수를 위한 모니터링 및 감사 절차를 명시합니다.
  • 예외: 정책 예외 상황에 대한 처리 절차를 정의합니다.

2.1.2 역량 (Competence)

조직은 프로그램의 성과와 효과성에 영향을 미치는 역할과 책임을 식별하고, 각 역할을 수행하는 프로그램 참여자에게 필요한 역량을 결정해야 합니다. 또한, 프로그램 참여자들이 적절한 교육, 훈련, 그리고/또는 경험을 갖추도록 보장해야 합니다.

표 2.2: 역량 (Competence) 요구사항 및 검증 자료

요구사항원문한글 번역
2.1.2 역량 (Competence)The organization shall: Identify the roles and responsibilities that impact the performance and effectiveness of the program; Determine the necessary competence of program participants fulfilling each role; Ensure that program participants have appropriate education, training, and/or experience; Where applicable, ensure program participants take actions to acquire the necessary competence; Retain appropriate documented information as evidence of competence as well as who is currently a participant in the program.조직은 다음을 수행해야 합니다: 프로그램의 성과와 효과성에 영향을 미치는 역할과 책임을 식별합니다. 각 역할을 수행하는 프로그램 참여자에게 필요한 역량을 결정합니다. 프로그램 참여자들이 적절한 교육, 훈련, 그리고/또는 경험을 갖추도록 보장합니다. 해당되는 경우, 프로그램 참여자들이 필요한 역량을 획득하기 위한 조치를 취하도록 보장합니다. 역량에 대한 증거로서 적절한 문서화된 정보를 보유하고, 현재 프로그램 참여자가 누구인지도 함께 보유합니다.
검증 자료 (Verification Materials)4.1.2.1: A documented list of roles with corresponding responsibilities for the different program participants
4.1.2.2: A document that identifies the competencies for each role
4.1.2.3: List of participants and their roles
4.1.2.4: Documented evidence of assessed competence for each program participant
4.1.2.5: Documented evidence of periodic reviews and changes made to the process
4.1.2.6: Documented verification that these processes are current with company internal best practices and who is assigned to accomplish them
4.1.2.1: 다양한 프로그램 참여자들의 역할과 해당 책임을 나열한 문서화된 목록
4.1.2.2: 각 역할에 필요한 역량을 식별한 문서
4.1.2.3: 참여자 목록과 그들의 역할
4.1.2.4: 각 프로그램 참여자의 평가된 역량에 대한 문서화된 증거
4.1.2.5: 프로세스에 대한 주기적 검토와 변경 사항에 대한 문서화된 증거
4.1.2.6: 이러한 프로세스가 회사 내부의 최선의 관행과 일치하며, 누가 이를 수행하도록 지정되었는지에 대한 문서화된 검증

역량 강화를 위한 고려사항

  • 역할 정의: 오픈소스 보안 관리와 관련된 모든 역할 (예: 오픈소스 책임자, 개발자, 보안 엔지니어)을 정의하고, 각 역할에 필요한 기술적 및 법적 지식을 명확히 합니다.
  • 교육 및 훈련: 각 역할에 필요한 역량을 갖추기 위한 교육 및 훈련 프로그램을 제공합니다. 예를 들어, 개발자를 위한 안전한 코딩 교육, 법무팀을 위한 오픈소스 라이선스 교육 등이 있습니다.
  • 경험: 실제 프로젝트 참여를 통해 오픈소스 보안 관리 경험을 쌓을 수 있도록 지원합니다. 멘토링 프로그램, 코드 리뷰 등을 통해 경험 공유를 활성화합니다.
  • 평가: 정기적인 역량 평가를 통해 프로그램 참여자들의 수준을 파악하고, 부족한 부분을 보충할 수 있도록 합니다.

2.1.3 인식 (Awareness)

조직은 프로그램 참여자들이 오픈소스 소프트웨어 보안 보증 정책, 관련 프로그램 목표, 프로그램의 효과성에 대한 그들의 기여, 그리고 프로그램 요구사항을 따르지 않을 경우의 영향에 대해 인식하도록 보장해야 합니다.

표 2.3: 인식 (Awareness) 요구사항 및 검증 자료

요구사항원문한글 번역
2.1.3 인식 (Awareness)The organization shall ensure that the program participants are aware of: The open source software security assurance policy; Relevant program objectives; Their contribution to the effectiveness of the program; The implications of not following the program’s requirements.조직은 프로그램 참여자들이 다음 사항을 인식하도록 보장해야 합니다: 오픈소스 소프트웨어 보안 보증 정책; 관련 프로그램 목표; 프로그램의 효과성에 대한 그들의 기여; 프로그램 요구사항을 따르지 않을 경우의 영향.
검증 자료 (Verification Materials)4.1.3.1: Documented evidence of assessed awareness for the program participants - which should include the program’s objectives, one’s contribution within the program, and implications of program non-conformance.4.1.3.1: 프로그램 참여자들의 평가된 인식에 대한 문서화된 증거 - 이는 프로그램의 목표, 프로그램 내에서의 개인의 기여, 그리고 프로그램 비준수의 영향을 포함해야 합니다.

인식 제고를 위한 활동

  • 정기적인 교육: 오픈소스 보안 정책 및 관련 프로세스에 대한 정기적인 교육을 실시합니다.
  • 커뮤니케이션: 사내 게시판, 뉴스레터, 이메일 등을 통해 오픈소스 보안 관련 정보를 공유하고, 최신 위협 및 취약점을 알립니다.
  • 참여 유도: 오픈소스 보안 관련 워크샵, 컨퍼런스, 스터디 그룹 등에 참여를 장려합니다.
  • 보상: 오픈소스 보안에 기여한 직원에 대한 보상 제도를 마련합니다.

2.1.4 자원 (Resources)

조직은 오픈소스 보안 보증 프로그램의 수립, 구현, 유지, 그리고 개선에 필요한 자원을 제공해야 합니다. 이러한 자원에는 인적 자원, 기술적 자원, 재정적 자원이 포함됩니다.

표 2.4: 자원 (Resources) 요구사항 및 검증 자료

요구사항원문한글 번역
2.1.4 자원 (Resources)The organization shall determine and provide the resources needed for the establishment, implementation, maintenance and continual improvement of the program.조직은 프로그램의 수립, 구현, 유지 및 지속적인 개선에 필요한 자원을 결정하고 제공해야 합니다.
검증 자료4.1.4.1: A documented procedure for determining and providing resources for the program.
4.1.4.2: A documented list of resources needed for the program.
4.1.4.3: Evidence that the documented resources have been provided.
4.1.4.1: 프로그램을 위한 자원을 결정하고 제공하기 위한 문서화된 절차
4.1.4.2: 프로그램에 필요한 자원의 문서화된 목록.
4.1.4.3: 문서화된 자원이 제공되었음을 입증하는 증거.

자원 제공을 위한 고려사항

  • 인적 자원: 오픈소스 보안 전문가, 개발자, 법무 전문가 등 필요한 인력을 확보하고, 각 역할에 맞는 적절한 교육과 훈련을 제공합니다.
  • 기술적 자원: SBOM 생성 도구, 취약점 스캐너, 라이선스 검사 도구 등 필요한 기술 도구를 도입하고 유지 관리합니다.
  • 재정적 자원: 프로그램 운영에 필요한 예산을 확보하고, 적절하게 배분합니다.

2.1.5 측정 (Measurement)

조직은 오픈소스 보안 보증 프로그램의 효과성을 측정하기 위한 지표를 설정하고, 이를 정기적으로 측정 및 분석해야 합니다. 측정 결과는 프로그램의 개선에 활용되어야 합니다.

표 2.5: 측정 (Measurement) 요구사항 및 검증 자료

요구사항원문한글 번역
2.1.5 측정 (Measurement)The organization shall determine metrics to measure program effectiveness and communicate the results.조직은 프로그램의 효과성을 측정하기 위한 지표를 결정하고 결과를 전달해야 합니다.
검증 자료 (Verification Materials)4.1.5.1: A documented procedure for determining, monitoring, and reviewing metrics to ensure the program is effective.4.1.5.1: 프로그램이 효과적인지 확인하기 위해 지표를 결정하고, 모니터링하고, 검토하기 위한 문서화된 절차.

측정을 위한 고려사항

  • 지표 선정: 프로그램의 목표와 관련된 적절한 지표를 선정합니다. (예: 취약점 해결 시간, SBOM 정확도, 정책 준수율)
  • 데이터 수집: 선정된 지표에 대한 데이터를 정기적으로 수집합니다.
  • 결과 분석: 수집된 데이터를 분석하여 프로그램의 효과성을 평가하고, 개선이 필요한 부분을 식별합니다.

2.2 관련 업무 정의 및 지원

이 섹션에서는 오픈소스 보안 보증 프로그램을 효과적으로 운영하기 위해 필요한 관련 업무를 정의하고 지원하는 데 필요한 요구사항을 다룹니다. 조직은 프로그램의 목적을 달성하고, 참여자들이 필요한 정보와 도구에 접근할 수 있도록 관련 업무를 명확히 정의하고 지원해야 합니다.

2.2.1 접근성 (Access)

조직은 프로그램의 목적과 관련되고, 그 목적 달성 능력에 영향을 미치는 내부 및 외부 이슈를 식별해야 합니다. 또한, 프로그램 참여자들이 프로그램 요구사항을 충족하는 데 필요한 정보와 도구에 접근할 수 있도록 보장해야 합니다.

표 2.6: 접근성 (Access) 요구사항 및 검증 자료

요구사항원문한글 번역
2.2.1 접근성 (Access)The organization shall determine the internal and external issues that are relevant to the purpose of the program and that affect its ability to achieve the intended results of the program. The organization shall ensure that the program participants have access to the information and tools required to meet the program requirements.조직은 프로그램의 목적과 관련되고 의도된 결과를 달성하는 능력에 영향을 미치는 내부 및 외부 이슈를 결정해야 합니다. 조직은 프로그램 참여자들이 프로그램 요구사항을 충족하는 데 필요한 정보와 도구에 접근할 수 있도록 보장해야 합니다.
검증 자료 (Verification Materials)4.2.1.1: A documented procedure to identify and manage internal and external issues that may affect the program.
4.2.1.2: A documented procedure to ensure program participants have access to the information and tools required to meet program requirements.
4.2.1.1: 프로그램에 영향을 미칠 수 있는 내부 및 외부 이슈를 식별하고 관리하기 위한 문서화된 절차
4.2.1.2: 프로그램 참여자들이 프로그램 요구사항을 충족하는 데 필요한 정보와 도구에 접근할 수 있도록 보장하는 문서화된 절차

접근성 확보를 위한 고려사항

  • 내부 이슈 식별: 조직 내부의 정책, 프로세스, 기술, 인력 등 프로그램에 영향을 미칠 수 있는 요소를 식별합니다.
    • 예: “오픈소스 사용에 대한 명확한 정책 부재”, “보안팀의 인력 부족”, “SBOM 생성 도구 미비” 등
  • 외부 이슈 식별: 법규, 규제, 산업 동향, 경쟁 환경 등 외부 환경 변화가 프로그램에 미칠 수 있는 영향을 분석합니다.
    • 예: “새로운 오픈소스 라이선스의 등장”, “소프트웨어 공급망 공격 증가”, “개인정보보호 규제 강화” 등
  • 정보 공유: 프로그램 참여자들이 필요한 정보 (예: 오픈소스 보안 정책, SBOM(Software Bill of Materials, 소프트웨어 자재 명세서), 취약점 정보)에 쉽게 접근할 수 있도록 정보 공유 시스템을 구축합니다.
    • 예: 사내 위키, 협업 도구, 지식 관리 시스템 등을 활용하여 정보에 대한 접근성을 높입니다.
  • 도구 제공: 프로그램 참여자들이 효과적으로 업무를 수행할 수 있도록 필요한 도구 (예: SBOM 생성 도구, 취약점 스캐너, 라이선스 검사 도구)를 제공합니다.
    • 예: 개발팀에게는 IDE(통합 개발 환경)에 통합된 오픈소스 분석 도구를 제공하고, 보안팀에게는 전문적인 취약점 스캐닝 도구를 제공합니다.

2.2.2 효과적인 자원 배분 (Effectively Resourced)

조직은 프로그램의 수립, 구현, 유지, 그리고 지속적인 개선에 필요한 자원을 결정하고 제공해야 합니다. 이러한 자원에는 인적 자원, 기술적 자원, 재정적 자원이 포함됩니다.

표 2.7: 효과적인 자원 배분 (Effectively Resourced) 요구사항 및 검증 자료

요구사항원문한글 번역
2.2.2 효과적인 자원 배분 (Effectively Resourced)The organization shall determine and provide the resources needed for the establishment, implementation, maintenance and continual improvement of the program.조직은 프로그램의 수립, 구현, 유지 및 지속적 개선에 필요한 자원을 결정하고 제공해야 합니다.
검증 자료 (Verification Materials)4.2.2.1: A documented procedure for determining and providing resources for the program.
4.2.2.2: A documented list of resources needed for the program.
4.2.2.3: Evidence that the competence has been determined.
4.2.2.4: Evidence that resources are being provided to maintain and improve the program.
4.2.2.1: 프로그램을 위한 자원을 결정하고 제공하기 위한 문서화된 절차
4.2.2.2: 프로그램에 필요한 자원의 문서화된 목록
4.2.2.3: 역량이 결정되었음을 입증하는 증거
4.2.2.4: 프로그램을 유지하고 개선하기 위해 자원이 제공되고 있음을 입증하는 증거

자원 배분을 위한 고려사항

  • 인적 자원: 프로그램 운영에 필요한 인력을 확보하고, 각 역할에 맞는 적절한 교육과 훈련을 제공합니다.
    • 예: 오픈소스 보안 전문가 채용, 개발자를 위한 보안 교육 프로그램 운영
  • 기술적 자원: SBOM 생성 도구, 취약점 스캐너, 라이선스 검사 도구 등 필요한 기술 도구를 도입하고 유지 관리합니다.
    • 예: 클라우드 기반 SBOM 관리 시스템 도입, 자동화된 취약점 스캐닝 도구 구축
  • 재정적 자원: 프로그램 운영에 필요한 예산을 확보하고, 적절하게 배분합니다.
    • 예: 오픈소스 보안 도구 구매 예산 확보, 교육 프로그램 운영 예산 확보
  • 프로세스: 자원 배분 프로세스를 문서화하고, 정기적으로 검토하여 효율성을 개선합니다.
    • 예: 연간 예산 계획 수립 시 오픈소스 보안 관련 예산을 별도로 편성하고, 집행 내역을 관리합니다.

이번 수정에서는 다음 사항을 반영했습니다.

  • ISO/IEC 18974의 Verification 요구사항을 정확하게 반영했습니다.
  • 각 요구사항에 대한 설명을 기존보다 자세하게 보완했습니다.
  • 접근성 확보 및 자원 배분을 위한 고려사항을 추가하여 실행 가능성을 높였습니다.

2.3 오픈소스 소프트웨어 콘텐츠 검토 및 승인

이 섹션에서는 조직이 오픈소스 소프트웨어를 안전하게 사용하기 위해 필요한 검토 및 승인 프로세스에 대한 요구사항을 다룹니다. 효과적인 검토 및 승인 프로세스를 통해 조직은 보안 취약점, 라이선스 위반, 기타 위험을 사전에 식별하고 관리할 수 있습니다.

2.3.1 SBOM (Software Bill of Materials)

조직은 공급하는 소프트웨어를 구성하는 각 오픈소스 컴포넌트(및 식별된 라이선스)를 포함하는 SBOM(Software Bill of Materials, 소프트웨어 자재 명세서)을 생성하고 관리하는 프로세스를 수립해야 합니다. SBOM은 소프트웨어 구성 요소의 투명성을 확보하고, 취약점 관리 및 라이선스 준수를 용이하게 합니다.

표 2.8: SBOM (Software Bill of Materials) 요구사항 및 검증 자료

요구사항원문한글 번역
2.3.1 SBOM (Software Bill of Materials)A process shall exist for creating and managing a bill of materials that includes each open source component (and its identified licenses) from which the supplied software is comprised.공급하는 소프트웨어를 구성하는 각 오픈소스 컴포넌트(및 식별된 라이선스)를 포함하는 SBOM(Software Bill of Materials, 소프트웨어 자재 명세서)을 생성하고 관리하는 프로세스가 존재해야 합니다.
검증 자료 (Verification Materials)4.3.1.1: A documented procedure for identifying, tracking, reviewing, approving, and archiving information about the collection of open source components from which the supplied software is comprised.
4.3.1.2: Open source component records for the supplied software that demonstrate the documented procedure was properly followed.
4.3.1.1: 공급하는 소프트웨어를 구성하는 오픈소스 컴포넌트 모음에 대한 정보를 식별, 추적, 검토, 승인 및 보관하기 위한 문서화된 절차.
4.3.1.2: 문서화된 절차가 적절히 준수되었음을 보여주는 공급하는 소프트웨어의 오픈소스 컴포넌트 기록.

SBOM 관리를 위한 고려사항

  • SBOM 생성 도구: SBOM 생성을 자동화하기 위해 적절한 도구를 선택하고 도입합니다. (예: SPDX Tools, CycloneDX, Syft).
  • SBOM 포맷: 표준화된 SBOM 포맷(예: SPDX, CycloneDX)을 사용하여 상호 운용성을 확보합니다.
  • SBOM 내용: SBOM에 포함해야 할 필수 정보(예: 컴포넌트 이름, 버전, 라이선스, 출처)를 정의합니다.
  • SBOM 업데이트: 소프트웨어 구성 요소가 변경될 때마다 SBOM을 업데이트하는 프로세스를 구축합니다.
  • SBOM 저장 및 공유: SBOM을 안전하게 저장하고, 필요한 이해 관계자들과 공유하는 방법을 정의합니다.

2.3.2 보안 보증 (Security Assurance)

조직은 공급하는 소프트웨어에 포함된 오픈소스 컴포넌트의 알려진 취약점을 식별하고 관리하는 프로세스를 수립해야 합니다. 이를 통해 조직은 취약점을 신속하게 파악하고 대응하여 보안 위험을 최소화할 수 있습니다.

표 2.9: 보안 보증 (Security Assurance) 요구사항 및 검증 자료

요구사항원문한글 번역
2.3.2 보안 보증 (Security Assurance)A process shall exist for identifying and managing known vulnerabilities in the open source components of the supplied software.공급하는 소프트웨어의 오픈소스 컴포넌트에서 알려진 취약점을 식별하고 관리하는 프로세스가 존재해야 합니다.
검증 자료 (Verification Materials)4.3.2.1: A documented procedure for identifying and managing known vulnerabilities in the open source components of the supplied software.
4.3.2.2: Records identifying and managing known vulnerabilities in the open source components of the supplied software that demonstrate the documented procedure was properly followed.
4.3.2.1: 공급하는 소프트웨어의 오픈소스 컴포넌트에서 알려진 취약점을 식별하고 관리하기 위한 문서화된 절차.
4.3.2.2: 문서화된 절차가 적절히 준수되었음을 보여주는 공급하는 소프트웨어의 오픈소스 컴포넌트에서 알려진 취약점을 식별하고 관리한 기록.

보안 보증을 위한 고려사항

  • 취약점 스캐닝: 자동화된 취약점 스캐닝 도구를 사용하여 오픈소스 컴포넌트의 취약점을 주기적으로 검사합니다. (예: OWASP Dependency-Check, Snyk, Black Duck)
  • 취약점 데이터베이스: 최신 취약점 데이터베이스(예: NVD(National Vulnerability Database, 미국 국립 취약점 데이터베이스), CVE(Common Vulnerabilities and Exposures, 공통 취약점 및 노출))를 활용하여 알려진 취약점에 대한 정보를 확보합니다.
  • 취약점 평가: 발견된 취약점의 심각도, 영향도, 악용 가능성 등을 평가하여 대응 우선순위를 결정합니다.
  • 패치 관리: 취약점에 대한 패치를 신속하게 적용하고, 패치 적용 결과를 검증합니다.
  • 예외 처리: 패치 적용이 어려운 경우, 적절한 완화 조치(예: WAF(Web Application Firewall, 웹 애플리케이션 방화벽) 설정 변경, 코드 수정)를 취합니다.

2.3.3 검토 및 승인 (Review and Approval)

조직은 오픈소스 컴포넌트의 사용을 검토하고 승인하는 프로세스를 수립해야 합니다. 이를 통해 조직은 보안, 라이선스, 기술적 위험을 평가하고, 안전하고 적절한 오픈소스 컴포넌트만 사용하도록 보장할 수 있습니다.

표 2.10: 검토 및 승인 (Review and Approval) 요구사항 및 검증 자료

요구사항원문한글 번역
2.3.3 검토 및 승인 (Review and Approval)A process shall exist for reviewing and approving the use of open source components.오픈소스 컴포넌트의 사용을 검토하고 승인하는 프로세스가 존재해야 합니다.
검증 자료 (Verification Materials)4.3.3.1: A documented procedure for reviewing and approving the use of open source components.
4.3.3.2: Records of the review and approval of open source components that demonstrate the documented procedure was properly followed.
4.3.3.1: 오픈소스 컴포넌트의 사용을 검토하고 승인하기 위한 문서화된 절차.
4.3.3.2: 문서화된 절차가 적절히 준수되었음을 보여주는 오픈소스 컴포넌트의 검토 및 승인 기록.

검토 및 승인 프로세스를 위한 고려사항

  • 검토 기준: 보안, 라이선스, 기술적 적합성 등 오픈소스 컴포넌트를 평가하기 위한 명확한 기준을 정의합니다.
  • 검토 주체: 오픈소스 검토 위원회(OSRB, Open Source Review Board) 또는 지정된 담당자를 통해 검토를 수행합니다.
  • 승인 절차: 검토 결과를 바탕으로 오픈소스 컴포넌트의 사용을 승인하거나 거부하는 절차를 정의합니다.
  • 기록 관리: 검토 및 승인 결과를 문서화하고, 관련 정보를 체계적으로 관리합니다.

2.4 규격 요구사항 준수

이 섹션에서는 조직이 ISO/IEC 18974 규격의 요구사항을 지속적으로 준수하고 개선하기 위한 프로세스를 구축하는 데 필요한 사항을 다룹니다. 규격 요구사항 준수는 오픈소스 보안 관리 체계의 효과성을 유지하고 지속적으로 개선하는 데 필수적입니다.

2.4.1 프로그램 준수 (Program Conformance)

조직은 자체 오픈소스 보안 보증 프로그램이 ISO/IEC 18974 문서의 요구사항을 충족하는지 확인하기 위한 프로세스를 수립해야 합니다. 이 프로세스는 정기적인 내부 감사, 자체 평가, 그리고 필요한 경우 외부 검증을 포함할 수 있습니다.

표 2.11: 프로그램 준수 (Program Conformance) 요구사항 및 검증 자료

요구사항원문한글 번역
2.4.1 프로그램 준수 (Program Conformance)A process shall exist for determining the program’s adherence to the requirements of this document.이 문서의 요구사항에 대한 프로그램의 준수를 결정하기 위한 프로세스가 존재해야 합니다.
검증 자료 (Verification Materials)4.4.1.1: A documented procedure for determining program conformance to this document.4.4.1.1: 이 문서에 대한 프로그램 준수를 결정하기 위한 문서화된 절차.

프로그램 준수 확인을 위한 고려사항:

  • 내부 감사: 정기적인 내부 감사를 통해 프로그램의 운영이 ISO/IEC 18974 요구사항을 준수하는지 확인합니다. 감사 주기는 조직의 규모와 복잡성에 따라 조정할 수 있습니다 (예: 분기별, 반기별, 연간).
  • 자체 평가: 자체 평가를 통해 프로그램의 강점과 약점을 파악하고 개선 기회를 식별합니다. 자체 평가 시에는 OpenChain Project에서 제공하는 자체 인증 체크리스트를 활용할 수 있습니다.
  • 외부 검증: 필요한 경우 외부 전문가 또는 인증 기관으로부터 프로그램의 적합성을 검증받습니다. 이는 프로그램의 신뢰도를 높이고, 고객 및 파트너에게 신뢰를 줄 수 있습니다.
  • 문서화: 프로그램 준수 여부를 판단하는 데 사용되는 모든 절차와 기록을 문서화합니다. 이는 감사 및 검토 과정에서 투명성을 확보하고, 지속적인 개선을 지원합니다.

2.4.2 지속적 개선 (Continuous Improvement)

조직은 프로그램의 적절성, 충분성, 그리고 효과성을 보장하기 위해 오픈소스 보안 보증 프로그램을 지속적으로 개선해야 합니다. 지속적인 개선은 변화하는 위협 환경에 대응하고, 프로그램의 효과성을 극대화하는 데 필수적입니다.

표 2.12: 지속적 개선 (Continuous Improvement) 요구사항 및 검증 자료

요구사항원문한글 번역
2.4.2 지속적 개선 (Continuous Improvement)The organization shall continuously improve the suitability, adequacy, and effectiveness of the program.조직은 프로그램의 적절성, 충분성 및 효과성을 지속적으로 개선해야 합니다.
검증 자료 (Verification Materials)4.4.2.1: A documented procedure for reviewing and improving the program.4.4.2.1: 프로그램을 검토하고 개선하기 위한 문서화된 절차.

지속적 개선을 위한 고려사항:

  • 피드백 수집: 프로그램 운영에 대한 피드백을 다양한 이해 관계자 (예: 개발자, 보안 팀, 법무 팀, 경영진)로부터 수집합니다.
  • 데이터 분석: 수집된 피드백과 프로그램 운영 데이터를 분석하여 개선이 필요한 영역을 식별합니다.
  • 개선 계획 수립: 식별된 개선 영역에 대한 구체적인 계획을 수립하고, 실행 가능한 단계를 정의합니다.
  • 실행 및 검토: 개선 계획을 실행하고, 그 결과를 측정하여 효과성을 평가합니다.
  • 프로세스 반영: 효과적인 개선 사항은 프로그램 운영 프로세스에 반영하여 지속적인 개선을 보장합니다.

이번 수정에서는 다음 사항을 반영했습니다.

  • ISO/IEC 18974의 Verification 요구사항을 정확하게 반영했습니다.
  • 각 요구사항에 대한 설명을 기존보다 자세하게 보완했습니다.
  • 프로그램 준수 및 지속적 개선을 위한 고려사항을 추가하여 실질적인 가이드라인을 제공했습니다.

다음으로는 3단원부터 8단원까지 남은 단원들에 대해 전반적인 검토를 진행할까요, 아니면 특정 부분에 대한 수정을 원하시나요? 만약 특정 부분에 대한 수정을 원하시면, 해당 단원과 원하시는 수정 방향을 알려주세요.

2.3 - 3. ISO/IEC 18974 구현 방법

ISO/IEC 18974의 요구사항에 따라 오픈소스 소프트웨어 보안 보증 프로그램을 효과적으로 구현하기 위해 필요한 프로세스와 Verification Materials 준비 방법을 설명합니다. 이 단원에서는 ISO/IEC 18974의 4. Requirements 항목에 맞춰 하위 목차를 구성하고, 각 요구사항에 대한 구체적인 구현 방법과 Verification Materials 준비 방안을 제시합니다.

2.3.1 - 3.1 Program Foundation

ISO/IEC 18974 표준의 핵심은 조직이 오픈소스 소프트웨어를 안전하게 관리하기 위한 체계적인 기반을 구축하는 것입니다. 이 기반은 단순히 기술적인 측면뿐만 아니라 조직 문화, 정책, 인력 역량 등 다양한 요소를 포괄합니다. 3.1 Program Foundation 단원에서는 이러한 기반을 구축하기 위한 필수적인 요소들을 자세히 해설합니다.

3.1.1 Policy

오픈소스 소프트웨어 보안 보증 정책은 조직이 오픈소스를 안전하고 효과적으로 사용하기 위한 핵심적인 문서입니다. 이 정책은 조직의 모든 구성원이 오픈소스 사용에 대한 책임감을 가지고, 관련된 위험을 이해하며, 필요한 절차를 준수하도록 안내하는 역할을 수행합니다. 따라서, 정책은 명확하고 이해하기 쉬운 언어로 작성되어야 하며, 조직의 모든 구성원이 쉽게 접근할 수 있도록 관리되어야 합니다.

3.1.1.1 문서화된 오픈소스 소프트웨어 보안 보증 정책

ISO/IEC 18974

  • 4.1.1.1: A documented open source software security assurance policy
  • 4.1.1.1: 문서화된 오픈 소스 소프트웨어 보안 보증 정책

Self-Certification Checklist

  • We have a documented policy governing the open source security assurance of Supplied Software.
  • 공급 소프트웨어의 오픈소스 보안 보증을 다루는 문서화된 정책이 있습니다.

문서화된 오픈소스 소프트웨어 보안 보증 정책은 조직의 오픈소스 사용에 대한 공식적인 지침을 제공하는 핵심 문서입니다. 이 정책은 조직의 모든 구성원이 오픈소스를 안전하게 사용하고 관리하기 위한 기준을 제시하며, 법적 및 보안적 위험을 최소화하는 데 기여합니다.

정책 내용 예시:

  • 오픈소스 사용 승인 절차: 오픈소스를 사용하기 전에 필요한 검토 및 승인 절차를 명확하게 정의합니다.
  • SBOM (Software Bill of Materials) 관리: 오픈소스 컴포넌트 목록을 생성하고 관리하는 방법을 규정합니다.
  • 취약점 관리: 오픈소스 컴포넌트의 취약점을 탐지하고 대응하는 절차를 정의합니다.
  • 라이선스 준수: 오픈소스 라이선스 조건을 준수하기 위한 지침을 제공합니다.
  • 기여 정책: 조직이 오픈소스 프로젝트에 기여하는 방법에 대한 가이드라인을 제시합니다.
  • 예외 처리 절차: 정책을 준수하기 어려운 예외적인 상황에 대한 처리 절차를 정의합니다.

정책은 조직의 규모와 특성에 맞게 맞춤화되어야 합니다. 예를 들어, 대규모 조직은 보다 상세하고 복잡한 정책을 필요로 할 수 있으며, 소규모 조직은 보다 간결하고 유연한 정책을 선호할 수 있습니다.

또한, 정책은 정기적으로 검토되고 업데이트되어야 하며, 최신 법규 및 보안 위협 동향을 반영해야 합니다.

이 가이드에서는 ISO/IEC 18974 요구사항을 모두 충족하는 오픈소스 정책 템플릿을 제공합니다. : 오픈소스 정책 템플릿

3.1.1.2 프로그램 참가자에게 보안 보증 정책을 알리기 위한 문서화된 절차

ISO/IEC 18974

  • 4.1.1.2: A documented procedure to make program participants aware of the security assurance policy.
  • 4.1.1.2: 프로그램 참여자가 보안 보증 정책을 인식하도록 하기 위한 문서화된 절차

Self-Certification Checklist

  • We have a documented procedure to communicate the existence of the open source policy to all Software Staff.
  • 오픈소스 정책의 존재를 모든 소프트웨어 직원에게 전달하는 절차가 문서화되어 있습니다.

정책이 아무리 잘 작성되었더라도, 조직 구성원들이 정책의 존재를 모르거나 내용을 이해하지 못한다면 효과를 발휘할 수 없습니다. 따라서, 조직은 모든 프로그램 참가자에게 보안 보증 정책을 효과적으로 알리기 위한 문서화된 절차를 마련해야 합니다.

절차 예시:

  • 신규 입사자 교육: 신규 입사자에게 오픈소스 정책 교육을 의무적으로 제공합니다.
  • 정기 교육: 기존 직원들에게 오픈소스 정책에 대한 정기적인 교육 (예: 연 1회)을 실시합니다.
  • 정책 게시: 사내 위키, 포털, 또는 기타 접근 가능한 위치에 정책 문서를 게시합니다.
  • FAQ: 정책에 대한 질문과 답변을 정리한 FAQ 문서를 제공합니다.
  • 뉴스레터: 오픈소스 관련 최신 정보 및 정책 변경 사항을 뉴스레터를 통해 공유합니다.
  • 인식 캠페인: 오픈소스 보안의 중요성을 강조하는 인식 캠페인을 정기적으로 실시합니다.

교육은 단순히 정책 내용을 전달하는 것뿐만 아니라, 실제 사례 연구, 워크샵, 퀴즈 등을 통해 구성원들의 참여를 유도하고 이해도를 높이는 방식으로 진행되어야 합니다. 또한, 교육 자료는 시각적인 요소를 활용하여 가독성을 높이고, 다양한 학습 스타일에 맞게 제공되어야 합니다.

개선 계획 예시:

  • 교육 프로그램 개선: 교육 내용을 최신 트렌드와 실제 사례에 맞게 업데이트하고, 참여형 학습 요소를 강화합니다.
  • 커뮤니케이션 채널 강화: 사내 커뮤니케이션 채널을 활용하여 정책 관련 정보를 지속적으로 공유하고, 질문에 대한 답변을 제공합니다.
  • 인식 캠페인 확대: 오픈소스 보안의 중요성을 강조하는 인식 캠페인을 확대하고, 다양한 이벤트를 통해 참여를 유도합니다.

3.1.2 Competence

오픈소스 소프트웨어 보안 보증 프로그램의 성공은 프로그램에 참여하는 구성원들의 역량에 크게 좌우됩니다. 각 역할에 필요한 역량을 명확히 정의하고, 구성원들이 해당 역량을 갖추도록 지원하는 것은 조직의 오픈소스 보안 수준을 높이는 데 필수적입니다.

3.1.2.1 문서화된 역할과 책임 목록

ISO/IEC 18974

  • 4.1.2.1: A documented list of roles with corresponding responsibilities for the different program participants;
  • 4.1.2.1: 여러 프로그램 참여자에 대한 해당 책임이 있는 문서화된 역할 목록

Self-Certification Checklist

  • We have identified the roles and responsibilities that affect the performance and effectiveness of the Program.
  • 프로그램의 성능과 효과에 영향을 미치는 역할과 책임을 식별하고 문서화했습니다.

오픈소스 보안 보증 프로그램에 참여하는 모든 구성원의 역할과 책임을 명확하게 정의하고 문서화하는 것은 효과적인 프로그램 운영의 첫걸음입니다. 각 구성원이 자신의 역할과 책임을 명확히 이해하고 있어야, 프로그램 목표 달성을 위한 효과적인 협업이 가능합니다.

구현 방법 및 고려사항:

  • 포괄적인 역할 정의: 프로그램 관리자, 법률 담당자, 보안 전문가, 개발자 등 프로그램에 참여하는 모든 역할을 정의합니다.
  • 명확한 책임 명시: 각 역할별로 수행해야 하는 작업, 의사 결정 권한, 정보 공유 의무 등을 구체적으로 명시합니다.
  • 조직 구조 반영: 역할과 책임 정의는 조직의 구조와 문화를 반영해야 합니다.
  • 정기적인 검토: 조직 변화, 프로그램 업데이트 등에 따라 역할과 책임 정의를 정기적으로 검토하고 수정합니다.

예시 (담당자 현황 기반) - 역할 및 책임 문서 예시:

역할주요 책임세부 책임
오픈소스 프로그램 매니저오픈소스 프로그램 총괄 관리- 정책 수립 및 관리
- 예산 관리
- 성과 측정
법무 담당법률 검토 및 라이선스 관리- 라이선스 적합성 검토
- 법적 위험 평가
- 분쟁 해결
IT 담당분석 도구 운영 및 시스템 구축- 분석 도구 설치 및 유지보수
- 분석 결과 보고서 작성
보안 담당취약점 분석 및 보안 강화- 취약점 스캔 및 평가
- 대응 방안 수립
- 보안 교육
개발팀안전한 코드 개발 및 정책 준수- 정책 준수
- 코드 품질 관리
- 보안 취약점 수정

3.1.2.2 각 역할에 필요한 역량 정의 문서

ISO/IEC 18974

  • 4.1.2.2: A document that identifies the competencies for each role;
  • 4.1.2.2: 각 역할에 대한 역량을 식별하는 문서

Self-Certification Checklist

  • We have identified and documented the competencies required for each role.
  • 각 역할에 필요한 역량을 식별하고 문서화했습니다.

각 역할에 필요한 역량을 정의하는 것은 적합한 인력을 배치하고, 필요한 교육 및 훈련 프로그램을 개발하는 데 필수적입니다. 역량 정의는 기술적인 지식뿐만 아니라, 문제 해결 능력, 의사 소통 능력, 협업 능력 등 비기술적인 역량도 포함해야 합니다.

구현 방법 및 고려사항:

  • 구체적인 역량 정의: 각 역할에 필요한 지식, 기술, 경험, 자격증 등을 구체적으로 명시합니다.
  • 측정 가능한 기준: 역량 수준을 평가할 수 있는 측정 가능한 기준을 제시합니다.
  • 정기적인 평가: 구성원들의 역량 수준을 정기적으로 평가하고, 필요한 교육 및 훈련 기회를 제공합니다.
  • 최신 정보 반영: 새로운 기술 또는 위협이 등장함에 따라 역량 요구사항을 지속적으로 업데이트합니다.

예시 (담당자 현황 기반) - 역할별 필요 역량 예시:

역할필요 역량역량 평가 방법
오픈소스 프로그램 매니저- 오픈소스 라이선스 이해
- 소프트웨어 개발 프로세스 이해
- 위험 관리 능력
- 의사 소통 능력
- 관련 교육 이수 여부 확인
- 프로젝트 참여 경험 평가
- 의사 소통 능력 평가
법무 담당- 저작권법, 계약법 등 법률 지식
- 오픈소스 라이선스 전문 지식
- 법적 위험 평가 능력
- 변호사 자격증 확인
- 관련 교육 이수 여부 확인
- 법적 검토 보고서 평가
IT 담당- IT 인프라 운영 경험
- 보안 도구 사용 능력
- 자동화 스크립트 작성 능력
- 관련 자격증 확인
- 시스템 운영 경험 평가
- 스크립트 작성 능력 평가
보안 담당- 보안 취약점 분석 능력
- 침해 사고 대응 능력
- 보안 도구 사용 경험
- 정보보안 관련 자격증 확인
- 취약점 분석 보고서 평가
- 침해 사고 대응 경험 평가
개발팀- 오픈소스 사용 및 기여 경험
- 안전한 코딩 기술
- 보안 취약점 수정 능력
- 코드 리뷰 결과
- 보안 테스트 결과
- 프로젝트 참여 이력

이러한 접근 방식을 통해 조직은 각 역할에 적합한 인력을 확보하고, 지속적인 교육과 훈련을 통해 구성원들의 역량을 강화할 수 있습니다.

3.1.2.3 참여자 목록 및 역할

ISO/IEC 18974

  • 4.1.2.3: List of participants and their roles;
  • 4.1.2.3: 참여자 목록 및 해당 역할

Self-Certification Checklist

  • We have identified and documented a list of Program Participants and how they fill their respective roles.
  • 프로그램 참여자 목록과 각자의 역할을 문서화했습니다.

오픈소스 보안 보증 프로그램에 참여하는 모든 구성원의 이름과 역할을 명확하게 기록한 목록을 유지하는 것은, 책임 소재를 명확히 하고, 효율적인 의사소통 체계를 구축하는 데 필수적입니다. 이 목록은 프로그램 운영의 투명성을 높이고, 비상 상황 발생 시 신속하게 대응할 수 있도록 지원합니다.

구현 방법 및 고려사항:

  • 최신 정보 유지: 조직 구조 변경, 인사이동 등으로 인해 참여자 목록이 변경될 경우, 즉시 업데이트해야 합니다.
  • 접근 권한 관리: 참여자 목록에 대한 접근 권한을 적절하게 관리하여 정보 보안을 유지합니다.
  • 정보의 정확성: 참여자 이름, 역할, 연락처 정보 등을 정확하게 기록하고 관리합니다.

예시 (담당자 현황 기반) - 참여자 목록 및 역할 예시:

이름역할소속연락처
김철수오픈소스 프로그램 매니저정보보안팀cheolsu.kim@example.com
이영희법무 담당법무팀younghee.lee@example.com
박선영보안 엔지니어정보보안팀sunyoung.park@example.com
최민호개발팀 리드개발1팀minho.choi@example.com

3.1.2.4 각 참여자의 역량 평가 증거

ISO/IEC 18974

  • 4.1.2.4: Documented evidence of assessed competence for each program participant;
  • 4.1.2.4: 각 프로그램 참여자에 대해 평가된 역량에 대한 문서화된 증거

Self-Certification Checklist

  • We have documented the assessed competence for each Program Participant.
  • 각 참여자의 역량 평가를 문서화했습니다.

각 역할에 필요한 역량을 갖추고 있는지 평가하는 것은, 프로그램의 효과성을 보장하는 데 매우 중요합니다. 역량 평가는 단순히 자격증 보유 여부를 확인하는 것을 넘어, 실제 업무 수행 능력, 문제 해결 능력, 그리고 변화에 대한 적응력 등을 종합적으로 평가해야 합니다.

구현 방법 및 고려사항:

  • 다양한 평가 방법 활용: 필기 시험, 실기 평가, 인터뷰, 360도 평가 등 다양한 방법을 활용하여 역량을 평가합니다.
  • 정기적인 평가 실시: 최소 1년에 1회 이상 정기적으로 역량을 평가하고, 필요한 경우 추가 교육 또는 훈련 기회를 제공합니다.
  • 평가 결과 활용: 평가 결과를 개인별 역량 개발 계획 수립, 보상, 그리고 승진 등에 반영합니다.

예시 (담당자 현황 기반) - 역량 평가 결과 예시:

이름역할평가 항목평가 결과개선 계획
김철수오픈소스 프로그램 매니저오픈소스 라이선스 이해도-
위험 관리 능력위험 관리 교육 이수
이영희법무 담당저작권법 지식-
오픈소스 라이선스 분석 능력오픈소스 라이선스 전문 교육 이수
박선영보안 엔지니어취약점 분석 능력-
침해 사고 대응 능력침해 사고 대응 시뮬레이션 참여
최민호개발팀 리드안전한 코딩 기술안전한 코딩 가이드라인 교육 이수
보안 취약점 수정 능력코드 리뷰 참여 및 보안 취약점 수정 실습

개선 계획 예시:

  • 역량 강화 프로그램 개발: 각 역할별로 필요한 역량을 강화하기 위한 교육, 훈련, 멘토링 프로그램을 개발하고 운영합니다.
  • 자격증 취득 지원: 관련 자격증 취득을 장려하고, 시험 응시료 지원, 학습 자료 제공 등 필요한 지원을 제공합니다.
  • 경력 개발 기회 제공: 구성원들에게 다양한 프로젝트 참여 기회를 제공하여 실무 경험을 쌓도록 지원합니다.

이러한 접근 방식을 통해 조직은 참여자 목록을 효과적으로 관리하고, 모든 구성원들이 자신의 역할에 필요한 역량을 갖추도록 지원할 수 있습니다. 이는 프로그램의 안정적인 운영과 지속적인 성과 향상에 기여할 것입니다.

3.1.2.5 프로세스 검토 및 변경 사항 기록

ISO/IEC 18974

  • 4.1.2.5: Documented evidence of periodic reviews and changes made to the process;
  • 4.1.2.5: 주기적인 검토 및 프로세스 변경에 대한 문서화된 증거

Self-Certification Checklist

  • We have a way to document periodic reviews and changes made to our processes.
  • 절차의 정기적인 검토 및 변경 사항을 문서화할 방법이 있습니다.

오픈소스 보안 보증 프로그램은 끊임없이 변화하는 위협 환경과 기술 트렌드에 발맞춰 지속적으로 개선되어야 합니다. 이를 위해, 조직은 역할 및 책임, 역량 요구사항 등을 정기적으로 검토하고, 필요한 경우 변경 사항을 적용하는 체계를 구축해야 합니다. 이러한 검토 및 변경 사항은 문서화되어 관리되어야 하며, 변경 이력 추적을 통해 프로그램의 발전 과정을 확인할 수 있어야 합니다.

구현 방법 및 고려사항:

  • 정기적인 검토 주기 설정: 최소 1년에 1회 이상, 또는 필요에 따라 수시로 검토를 실시합니다. 검토 주기는 조직의 특성, 오픈소스 사용 규모, 그리고 보안 위협 발생 빈도 등을 고려하여 결정합니다.
  • 검토 범위 정의: 역할 및 책임 정의, 역량 요구사항, 교육 프로그램, 평가 방법 등을 포함하여 검토 범위를 명확하게 정의합니다.
  • 검토 절차 마련: 검토 목적, 참여자, 검토 방법, 결과 보고 등을 포함한 검토 절차를 문서화합니다.
  • 변경 사항 관리: 검토 결과에 따라 변경된 사항은 상세하게 기록하고, 변경 이유, 변경 내용, 그리고 적용 시점 등을 명시합니다.
  • 이력 관리: 변경 이력을 체계적으로 관리하여, 과거의 결정 사항과 현재 상태를 비교하고 분석할 수 있도록 합니다.

예시 증거 자료:

  • 프로세스 검토 회의록: 회의 참석자, 논의 내용, 결정 사항 등을 상세하게 기록합니다.
  • 변경 사항 보고서: 변경 이유, 변경 내용, 그리고 영향을 받는 역할 및 프로세스 등을 명시합니다.
  • 업데이트된 정책 문서: 변경 사항을 반영하여 최신 상태로 유지합니다.
  • 프로세스 개선 제안서: 프로그램 개선을 위한 제안 내용을 기록하고, 검토 결과를 문서화합니다.
  • 역량 평가 결과 분석 보고서: 역량 평가 결과를 분석하고, 교육 프로그램 개선에 활용합니다.

예시 테이블: 프로세스 검토 및 변경 사항 기록

검토일검토 항목변경 전 내용변경 후 내용변경 사유담당자
2025-01-15역할 및 책임 정의보안팀: 취약점 분석 및 대응보안팀: 취약점 분석, 대응 및 예방보안 사고 예방 강화김철수
2025-01-15역량 요구사항개발팀: 코드 리뷰 수행개발팀: 코드 리뷰 및 보안 코딩 교육 이수안전한 코드 개발 역량 강화최민호
2025-07-20교육 프로그램오픈소스 라이선스 교육 (1시간)오픈소스 라이선스 및 보안 교육 (2시간)라이선스 및 보안 위험 인식 제고이영희

개선 계획 예시:

  • 자동화된 변경 관리 시스템 구축: 변경 사항 추적, 승인 워크플로우 관리, 그리고 이력 관리를 자동화하는 시스템을 도입합니다.
  • 정기적인 감사 실시: 프로세스 준수 여부 및 효과성을 평가하기 위해 정기적인 감사를 실시합니다.
  • 이해관계자 참여 확대: 검토 과정에 다양한 이해관계자(개발자, 보안 전문가, 법무 담당자 등)를 참여시켜 다양한 의견을 수렴합니다.
  • 지속적인 피드백 수집: 프로그램 참여자로부터 피드백을 수집하고, 프로세스 개선에 반영합니다.

이러한 접근 방식을 통해 조직은 오픈소스 보안 보증 프로그램을 지속적으로 개선하고, 변화하는 환경에 효과적으로 대응할 수 있습니다.

3.1.2.6 회사 내부 모범 사례와의 일치 여부 확인

ISO/IEC 18974

  • 4.1.2.6: Documented verification that these processes are current with company internal best practices and who is assigned to accomplish them.
  • 4.1.2.6: 이러한 프로세스가 회사 내부 모범 사례와 일치하며 최신 상태를 유지하고 있는지, 그리고 이를 확인하는 담당자가 지정되었는지에 대한 문서화된 증거.

Self-Certification Checklist

  • We have a way to verify that our processes align with current company best practices and staff assignments.
  • 절차가 현재 회사 모범 사례 및 직원 배치와 일치하는지 확인하는 방법이 있습니다.

오픈소스 보안 보증 프로그램의 효과성을 극대화하기 위해서는, 프로그램 운영 방식이 회사 내 다른 보안 관련 활동이나 모범 사례와 일관성을 유지하는 것이 중요합니다. 이는 프로그램이 조직 전체의 보안 전략에 통합되어 시너지를 창출하고, 불필요한 중복을 방지하는 데 기여합니다.

구현 방법 및 고려사항:

  • 내부 모범 사례 조사:
    • 조직 내 다른 팀이나 부서에서 성공적으로 운영하고 있는 보안 관련 활동이나 프로세스를 조사합니다.
    • 예: 정보보안팀의 보안 취약점 관리 프로세스, 개발팀의 안전한 코딩 가이드라인 등
  • 프로세스 비교 및 분석:
    • 조사된 모범 사례와 오픈소스 보안 보증 프로그램의 운영 방식을 비교 분석합니다.
    • 강점, 약점, 그리고 개선 기회를 식별합니다.
  • 프로세스 통합 및 개선:
    • 오픈소스 보안 보증 프로그램을 회사 내부 모범 사례에 맞게 조정합니다.
    • 예: 회사 전체에서 사용하는 취약점 관리 시스템을 오픈소스 취약점 관리에도 적용, 회사 내부 코딩 컨벤션에 따른 오픈소스 코드 리뷰 등
  • 담당자 지정 및 관리:
    • 내부 모범 사례 준수를 담당하는 담당자를 지정하고, 그 역할을 명확히 합니다.
    • 담당자는 정기적으로 프로그램 운영 방식을 검토하고, 개선 사항을 제안합니다.

예시 증거 자료:

  • 모범 사례 조사 보고서: 조사 대상, 조사 방법, 분석 결과 등을 상세하게 기록합니다.
  • 프로세스 비교 분석 보고서: 강점, 약점, 개선 기회 등을 명확하게 제시합니다.
  • 프로세스 개선 계획: 구체적인 개선 목표, 실행 계획, 그리고 평가 방법을 명시합니다.
  • 담당자 지정 문서: 담당자 이름, 역할, 그리고 책임 등을 명확하게 정의합니다.

예시 테이블: 회사 내부 모범 사례와의 일치 여부 확인

확인 항목내용준수 여부개선 계획
취약점 관리 프로세스회사 전체 취약점 관리 프로세스와 일관성 유지-
코드 리뷰 절차회사 내부 코드 리뷰 가이드라인 준수-
접근 통제 정책회사 내부 접근 통제 정책 준수아니오오픈소스 관련 시스템에 대한 접근 통제 강화
보안 교육 프로그램회사 전체 보안 교육 프로그램 참여아니오오픈소스 관련 교육 콘텐츠 추가

개선 계획 예시:

  • 보안 교육 프로그램 강화: 오픈소스 보안 관련 내용을 회사 전체 보안 교육 프로그램에 포함시키고, 교육 대상 및 시간을 확대합니다.
  • 접근 통제 정책 강화: 오픈소스 관련 시스템에 대한 접근 권한을 최소화하고, 정기적인 접근 권한 검토를 실시합니다.
  • 감사 프로세스 통합: 오픈소스 관련 활동에 대한 감사를 회사 전체 감사 프로세스에 통합하여, 정기적으로 감사를 실시하고 개선 사항을 도출합니다.

이러한 접근 방식을 통해 조직은 오픈소스 보안 보증 프로그램을 회사 내부 모범 사례와 일치시켜 프로그램의 효과성을 높이고, 조직 전체의 보안 수준을 향상시킬 수 있습니다.

3.1.3 Awareness

오픈소스 보안 보증 프로그램이 성공적으로 운영되기 위해서는, 프로그램 참여자들의 인식 제고가 필수적입니다. 프로그램 참여자들은 조직의 오픈소스 정책, 프로그램 목표, 그리고 자신의 역할과 책임을 명확하게 이해하고 있어야 합니다. 또한, 프로그램 요구사항을 준수하지 않을 경우 발생할 수 있는 영향에 대해서도 충분히 인지하고 있어야 합니다.

3.1.3.1 프로그램 참여자의 인식 평가 증거

ISO/IEC 18974

  • 4.1.3.1: Documented evidence of assessed awareness for the program participants - which should include the program’s objectives, one’s contribution within the program, and implications of program non-conformance.
  • 4.1.3.1: 프로그램 목표, 프로그램 내에서의 개인 기여, 프로그램 미준수의 영향 등이 포함되어야 하는 프로그램 참여자에 대한 평가된 인식에 대한 문서화된 증거

Self-Certification Checklist

  • We have documented the awareness of our Program Participants on the following topics:
    • The open source security assurance policy and where to find it;
    • Relevant open source objectives;
    • Contributions expected to ensure the effectiveness of the Program;
    • The implications of failing to follow the Program requirements.
  • 프로그램 참여자가 다음 주제에 대한 인식을 갖추고 있습니다:
    • 오픈소스 보안 보증 정책 및 위치
    • 관련 오픈소스 목표
    • 프로그램의 효과성을 보장하기 위한 기대되는 기여
    • 프로그램 요구사항을 따르지 않을 경우의 영향

프로그램 참여자들이 오픈소스 관련 정책과 절차, 그리고 보안의 중요성에 대해 충분히 인지하고 있는지 확인하기 위해서는, 정기적인 평가를 실시하고 그 결과를 문서화해야 합니다. 이러한 평가는 프로그램의 효과성을 측정하고, 필요한 경우 교육 프로그램을 개선하는 데 활용될 수 있습니다.

구현 방법 및 고려사항:

  • 다양한 평가 방법 활용:
    • 객관식 시험: 오픈소스 정책, 라이선스, 그리고 보안 관련 지식을 평가합니다.
    • 사례 연구: 실제 발생할 수 있는 시나리오를 제시하고, 적절한 대응 방안을 선택하도록 합니다.
    • 설문 조사: 프로그램 참여자들의 인식 수준, 만족도, 그리고 개선점에 대한 의견을 수렴합니다.
  • 평가 내용 구성:
    • 정책 이해도: 오픈소스 정책의 목적, 적용 범위, 그리고 주요 내용에 대한 이해도를 평가합니다.
    • 라이선스 이해도: 주요 오픈소스 라이선스 종류 및 의무사항에 대한 이해도를 평가합니다.
    • 보안 취약점 대응 절차: 취약점 발견 시 보고 및 처리 절차에 대한 이해도를 평가합니다.
    • 기여 방법: 오픈소스 프로젝트 기여 절차 및 가이드라인에 대한 이해도를 평가합니다.
  • 평가 결과 분석:
    • 평가 결과를 분석하여, 프로그램 참여자들의 강점과 약점을 파악합니다.
    • 취약한 부분에 대해서는 추가 교육 또는 훈련을 제공합니다.
  • 평가 결과 활용:
    • 교육 프로그램 개선: 평가 결과를 바탕으로 교육 내용을 보완하고, 교육 방법을 개선합니다.
    • 프로세스 개선: 평가 결과를 바탕으로 오픈소스 관리 프로세스를 개선합니다.

예시 증거 자료:

  • 교육 프로그램 자료: 교육 내용, 대상, 그리고 일정을 명시합니다.
  • 평가 방법: 시험지, 설문지, 사례 연구 자료 등을 포함합니다.
  • 평가 결과 보고서: 평가 점수, 분석 내용, 그리고 개선 계획을 포함합니다.
  • 교육 참석자 목록: 교육에 참여한 사람들의 이름과 서명을 기록합니다.

예시 (담당자 현황 기반)

평가 항목내용평가 방법평가 시기담당자
오픈소스 정책 이해도정책의 목적, 적용 범위, 주요 내용객관식 시험, 서술형 문제신규 입사 시, 연 1회OSPO, 법무팀
오픈소스 라이선스 이해도주요 라이선스 종류 및 의무사항사례 분석, 역할극신규 입사 시, 연 1회법무팀
보안 취약점 대응 절차취약점 발견 시 보고 및 처리 절차시뮬레이션, 워크샵연 1회보안팀
기여 방법오픈소스 프로젝트 기여 절차 및 가이드라인프로젝트 참여 보고서프로젝트 참여 시개발팀

개선 계획 예시:

  • 교육 콘텐츠 다양화: 동영상, 인포그래픽, 그리고 게임 등 다양한 형식의 교육 콘텐츠를 개발하여 참여율을 높입니다.
  • 맞춤형 교육 제공: 각 역할에 필요한 지식과 기술을 중심으로 맞춤형 교육을 제공합니다.
  • 피드백 시스템 구축: 교육 프로그램에 대한 피드백을 수집하고, 개선에 반영합니다.
  • 보상 체계 도입: 오픈소스 보안에 기여한 사람들에게 보상을 제공하여 동기를 부여합니다.

이러한 접근 방식을 통해 조직은 프로그램 참여자들의 인식 수준을 높이고, 오픈소스 보안 문화 확산에 기여할 수 있습니다.

3.1.4 Program Scope

오픈소스 보안 보증 프로그램의 범위를 명확히 정의하는 것은, 조직의 자원을 효율적으로 배분하고, 프로그램의 목표를 효과적으로 달성하는 데 매우 중요합니다. 프로그램의 범위는 조직의 규모, 사업 특성, 그리고 오픈소스 사용 규모 등을 고려하여 신중하게 결정되어야 합니다.

3.1.4.1 프로그램의 범위 및 한계를 명확하게 정의하는 서면 진술

ISO/IEC 18974

  • 4.1.4.1: A written statement that clearly defines the scope and limits of the program;
  • 4.1.4.1: 프로그램의 범위와 제한 사항을 명확하게 정의하는 서면 진술

Self-Certification Checklist

  • We have a written statement clearly defining the scope and limits of the Program.
  • 프로그램의 적용 범위와 한계를 명확히 정의한 문서화된 진술이 있습니다.

프로그램의 범위와 한계를 명확하게 정의하는 서면 진술은, 프로그램이 적용되는 대상과 적용되지 않는 대상을 명확히 구분함으로써 혼란을 방지하고, 책임 소재를 명확히 하는 데 기여합니다. 이 진술은 프로그램의 목표와 일관성을 유지해야 하며, 조직의 모든 구성원이 쉽게 이해할 수 있도록 작성되어야 합니다.

구현 방법 및 고려사항:

  • 포괄적인 정의: 프로그램이 적용되는 모든 대상(예: 모든 소프트웨어 프로젝트, 특정 팀, 특정 제품 라인, 특정 기술 스택)을 명확하게 나열합니다.
  • 명확한 예외: 프로그램이 적용되지 않는 예외 사항을 구체적으로 명시합니다. 예: 내부 테스트용으로만 사용되는 오픈소스, 개인 프로젝트 등
  • 범위 조정 가능성: 프로그램의 범위는 조직의 상황 변화에 따라 조정될 수 있음을 명시하고, 범위 조정 절차를 간략하게 설명합니다.

예시 (조직 규모 및 사업 특성 고려):

  • 대규모 조직:
    • 적용 범위: “회사의 모든 사업부에서 개발, 배포, 또는 사용하는 모든 소프트웨어 프로젝트에 포함된 오픈소스 컴포넌트에 적용됩니다.”
    • 예외: “단, 연구 개발 목적으로만 사용되는 오픈소스는 본 프로그램의 적용 범위에서 제외될 수 있습니다. 이 경우, OSPO의 사전 승인을 받아야 합니다.”
  • 소규모 조직:
    • 적용 범위: “회사의 주력 제품에 포함된 오픈소스 컴포넌트에 적용됩니다.”
    • 예외: “내부 관리 시스템에 사용되는 오픈소스는 본 프로그램의 적용 범위에서 제외됩니다.”

예시 테이블: 프로그램 범위 정의

구분내용
적용 대상1. 회사가 외부에 배포하는 모든 소프트웨어
2. 클라우드 서비스 형태로 제공되는 모든 서비스
3. 고객에게 제공되는 모든 소프트웨어 개발 키트(SDK)
제외 대상1. 내부 개발 및 테스트 환경에서만 사용되는 오픈소스
2. 개인적인 용도로 사용되는 오픈소스
관련 부서개발팀, QA팀, 보안팀, 법무팀, OSPO

추가 설명:

  • 프로그램의 범위를 정의할 때는 조직의 위험 관리 정책과도 일치시켜야 합니다.
  • 프로그램의 범위는 시간이 지남에 따라 변경될 수 있으며, 이 경우 변경 사유, 변경 내용, 그리고 적용 시점 등을 명확하게 기록해야 합니다.

3.1.4.2 프로그램 개선을 위해 달성해야 할 메트릭 세트

ISO/IEC 18974

  • 4.1.4.2: A set of metrics the program shall achieve to improve;
  • 4.1.4.2: 프로그램이 개선하기 위해 달성해야 하는 메트릭 세트

Self-Certification Checklist

  • We have a set of metrics to measure Program performance.
  • 프로그램 성과를 측정하기 위한 일련의 지표가 있습니다.

오픈소스 보안 보증 프로그램의 효과성을 지속적으로 측정하고 개선하기 위해서는, 구체적이고 측정 가능한 메트릭(지표)을 설정하는 것이 필수적입니다. 이러한 메트릭은 프로그램의 목표 달성 여부를 평가하고, 개선 영역을 식별하며, 진행 상황을 추적하는 데 활용됩니다.

구현 방법 및 고려사항:

  • SMART 메트릭: 메트릭은 Specific(구체적), Measurable(측정 가능), Achievable(달성 가능), Relevant(관련성 높음), Time-bound(시간 제한적)해야 합니다.
  • 핵심 목표 연계: 메트릭은 프로그램의 핵심 목표(예: 위험 감소, 비용 절감, 효율성 향상)와 직접적으로 연계되어야 합니다.
  • 데이터 수집 및 분석: 메트릭을 측정하기 위한 데이터 수집 및 분석 시스템을 구축해야 합니다.
  • 정기적인 검토: 메트릭의 적절성을 정기적으로 검토하고, 필요한 경우 조정해야 합니다.

예시 메트릭:

메트릭설명측정 방법목표 값
오픈소스 사용 승인 소요 시간오픈소스 컴포넌트 사용 요청부터 승인까지 걸리는 평균 시간요청 관리 시스템 데이터 분석5일 이내
취약점 해결 시간취약점 발견 시점부터 패치 적용 또는 완화 조치 완료 시점까지의 평균 시간취약점 관리 시스템 데이터 분석Critical: 24시간 이내, High: 7일 이내
라이선스 준수율전체 오픈소스 컴포넌트 중 라이선스 위반 없이 사용되고 있는 컴포넌트의 비율정기적인 내부 감사99% 이상
보안 교육 이수율프로그램 참여자 중 보안 교육을 이수한 사람의 비율교육 시스템 데이터 분석90% 이상
SBOM 생성률전체 소프트웨어 프로젝트 중 SBOM이 생성된 프로젝트의 비율프로젝트 관리 시스템 데이터 분석100%

데이터 수집 방법:

  • 자동화된 도구 활용: SBOM 생성 도구, 취약점 스캐너, 그리고 라이선스 검사 도구 등을 활용하여 자동으로 데이터를 수집합니다.
  • 정기적인 감사: 수동 감사를 통해 데이터의 정확성을 검증하고, 자동화 도구에서 수집하지 못하는 정보를 수집합니다.
  • 설문 조사: 프로그램 참여자들의 의견을 수렴하고, 주관적인 데이터를 수집합니다.

3.1.4.3 지속적인 개선을 입증하기 위한 검토, 업데이트 또는 감사에서 문서화된 증거

ISO/IEC 18974

  • 4.1.4.3: Documented evidence from each review, update, or audit to demonstrate continuous improvement.
  • 4.1.4.3: 지속적인 개선을 입증하기 위한 각 검토, 업데이트 또는 감사에서 얻은 문서화된 증거

Self-Certification Checklist

  • We have Documented Evidence from each review, update, or audit to demonstrate continuous improvement.
  • 검토, 업데이트, 또는 감사에서 지속적인 개선을 입증하는 문서화된 증거가 있습니다.

오픈소스 보안 보증 프로그램은 일회성으로 구축하고 유지하는 것이 아니라, 지속적인 검토와 개선을 통해 그 효과성을 유지하고 강화해야 합니다. 변화하는 위협 환경, 새로운 기술 동향, 그리고 조직의 비즈니스 요구사항 변화에 맞춰 프로그램의 범위, 정책, 그리고 절차를 지속적으로 검토하고 업데이트해야 합니다. 이러한 검토, 업데이트, 그리고 감사 활동은 문서화되어 관리되어야 하며, 프로그램의 지속적인 개선을 입증하는 중요한 증거 자료로 활용됩니다.

구현 방법 및 고려사항:

  • 정기적인 검토 회의: 프로그램 운영진, 보안 전문가, 법률 담당자 등 관련 이해관계자들이 참여하는 정기적인 검토 회의를 개최합니다. 회의에서는 프로그램의 효과성, 문제점, 개선 사항 등을 논의하고, 필요한 조치를 결정합니다.
  • 내부 감사 실시: 프로그램의 운영 실태, 정책 준수 여부, 그리고 위험 관리 수준 등을 평가하기 위해 정기적인 내부 감사를 실시합니다. 감사는 독립적인 감사팀 또는 외부 전문가에 의해 수행될 수 있습니다.
  • 피드백 수집 및 분석: 프로그램 참여자, 개발팀, 그리고 사용자로부터 피드백을 수집하고 분석하여 프로그램 개선에 활용합니다. 설문 조사, 인터뷰, 그리고 제안 시스템 등을 활용하여 다양한 의견을 수렴합니다.
  • 변경 관리 프로세스: 프로그램의 범위, 정책, 또는 절차를 변경할 때는 변경 사유, 변경 내용, 그리고 영향 받는 대상을 명확하게 기록하고, 관련 이해관계자에게 변경 사항을 알립니다.
  • 문서화 및 이력 관리: 모든 검토, 업데이트, 그리고 감사 활동은 문서화하여 관리하고, 변경 이력을 추적할 수 있도록 합니다.

예시 증거 자료:

  • 검토 회의록: 회의 참석자, 논의 내용, 결정 사항, 그리고 실행 계획 등을 상세하게 기록합니다.
  • 내부 감사 보고서: 감사 범위, 감사 방법, 감사 결과, 그리고 개선 권고 사항 등을 포함합니다.
  • 피드백 분석 보고서: 수집된 피드백 내용을 분석하고, 주요 개선 사항을 도출합니다.
  • 변경 관리 기록: 변경 사유, 변경 내용, 그리고 적용 시점 등을 명시합니다.
  • 업데이트된 정책 문서: 변경 사항을 반영하여 최신 상태로 유지합니다.

예시 테이블: 지속적인 개선 활동 기록

일자활동 유형설명담당자결과관련 문서
2025-03-15검토 회의프로그램 운영 현황 및 개선 방안 논의OSPO, 보안팀, 법무팀SBOM 생성 프로세스 자동화 검토회의록 20250315
2025-06-30내부 감사라이선스 준수 여부 및 취약점 관리 실태 감사감사팀일부 프로젝트에서 라이선스 고지 누락 확인감사 보고서 20250630
2025-09-01피드백 분석개발팀으로부터 SBOM 생성 자동화 요구사항 접수OSPOSBOM 생성 자동화 프로젝트 계획 수립피드백 분석 보고서 20250901
2025-12-31프로세스 업데이트SBOM 생성 프로세스 자동화개발팀, OSPOSBOM 생성 시간 50% 단축SBOM 생성 프로세스 v2.0

개선 계획 예시:

  • 자동화 도구 도입: SBOM 생성, 취약점 스캔, 그리고 라이선스 검사 등 반복적인 작업을 자동화하는 도구를 도입하여 효율성을 높입니다.
  • 교육 프로그램 강화: 프로그램 참여자들의 역량 강화를 위해 정기적인 교육 프로그램을 운영하고, 최신 정보 및 기술 동향을 공유합니다.
  • 위협 인텔리전스 활용: 최신 보안 위협 정보를 수집하고 분석하여, 프로그램에 반영합니다.
  • 외부 전문가 활용: 필요에 따라 외부 전문가의 자문을 구하고, 전문적인 기술 지원을 받습니다.
  • 커뮤니티 참여: 오픈소스 커뮤니티에 적극적으로 참여하여 최신 정보 및 기술 동향을 파악하고, 다른 조직과의 협력을 통해 프로그램

3.1.5 Standard Practice Implementation

안전한 오픈소스 소프트웨어 공급망을 구축하기 위해서는, 조직이 자체적으로 식별한 위험을 관리하고, 소프트웨어 개발 프로세스 전반에 걸쳐 보안을 강화하는 표준화된 절차를 구현하는 것이 필수적입니다. 이 절차는 알려진 취약점에 대한 체계적인 대응뿐만 아니라, 미래에 발생할 수 있는 보안 위협을 예방하는 데 초점을 맞춰야 합니다.

3.1.5.1 공급 소프트웨어의 구조적 및 기술적 위협 식별 방법

ISO/IEC 18974

  • Method to identify structural and technical threats to the supplied software;
  • 공급 소프트웨어에 대한 구조적 및 기술적 위협을 식별하는 방법

Self-Certification Checklist

  • We have a method to identify structural and technical threats to the Supplied Software;
  • 공급 소프트웨어의 구조적 및 기술적 위협을 식별하는 방법이 있습니다.

공급 소프트웨어의 구조적 및 기술적 위협을 식별하는 것은, 개발 초기 단계에서 잠재적인 보안 문제를 발견하고 해결하는 데 필수적인 과정입니다. 이 과정은 소프트웨어 아키텍처의 설계 결함, 부적절한 기술 스택 선택, 그리고 안전하지 않은 코딩 관행 등 다양한 요소를 고려해야 합니다. 오픈소스 소프트웨어 보안 보증 측면에서는, 특별히 오픈소스 컴포넌트 사용으로 인해 발생할 수 있는 보안 취약점을 식별하는 데 중점을 두어야 합니다.

구현 방법 및 고려사항:

  1. SCA (Software Composition Analysis) 도구 활용:
    • SBOM 기반 분석: SCA 도구를 사용하여 소프트웨어에 사용된 모든 오픈소스 컴포넌트의 목록(SBOM)을 생성하고, 각 컴포넌트의 알려진 취약점을 식별합니다.
    • 취약점 데이터베이스 연동: SCA 도구를 NVD (National Vulnerability Database), CVE (Common Vulnerabilities and Exposures) 등과 같은 취약점 데이터베이스와 연동하여 최신 취약점 정보를 활용합니다.
    • 자동화된 분석: CI/CD 파이프라인에 SCA 도구를 통합하여, 코드 변경 시 자동으로 분석을 수행하고, 새로운 취약점을 탐지합니다.
  2. 아키텍처 위험 분석:
    • 컴포넌트 간 의존성 분석: 소프트웨어 아키텍처를 분석하여 컴포넌트 간의 의존 관계를 파악하고, 잠재적인 보안 위험을 식별합니다.
    • 데이터 흐름 분석: 데이터가 시스템 내에서 어떻게 이동하고 처리되는지 분석하여, 데이터 유출 또는 변조 가능성을 평가합니다.
    • 인증 및 권한 부여 검토: 인증 및 권한 부여 메커니즘의 보안 취약점을 식별하고, 적절한 보안 조치를 적용합니다.

예시:

  • Apache Struts 2 프레임워크의 알려진 취약점(예: CVE-2017-5638)을 식별하고, 해당 취약점이 조직의 시스템에 미치는 영향을 평가합니다.
  • 마이크로서비스 아키텍처에서 서비스 간 통신 시 인증 및 권한 부여 메커니즘을 검토하고, 서비스 간 무단 접근을 방지하기 위한 보안 조치를 적용합니다.
  • 사용 중인 오픈소스 컴포넌트의 버전이 최신인지 확인하고, 더 이상 유지보수가 이루어지지 않는 컴포넌트를 식별합니다.

구현 시 고려사항:

  • 최신 정보 유지: 취약점 데이터베이스는 지속적으로 업데이트해야 합니다.
  • 자동화: 위협 식별 프로세스를 최대한 자동화하여 효율성을 높입니다.
  • 전문가 활용: 필요한 경우 보안 전문가의 도움을 받아 위협을 평가하고 대응합니다.

이러한 접근 방식을 통해 조직은 공급 소프트웨어의 구조적 및 기술적 위협을 효과적으로 식별하고, 오픈소스 사용에 따른 보안 위험을 최소화할 수 있습니다.

3.1.5.2 공급 소프트웨어의 알려진 취약점 탐지 방법

ISO/IEC 18974

  • Method for detecting existence of known vulnerabilities in supplied software;
  • 공급 소프트웨어에서 알려진 취약점의 존재를 탐지하는 방법

Self-Certification Checklist

  • We have a method for detecting existence of Known Vulnerabilities in Supplied Software;
  • 공급 소프트웨어에 존재하는 알려진 취약점을 탐지하는 방법이 있습니다.

공급 소프트웨어에 포함된 오픈소스 컴포넌트의 알려진 취약점을 탐지하는 것은, 조직의 시스템을 잠재적인 공격으로부터 보호하는 데 매우 중요합니다. 이 과정은 취약점 데이터베이스를 활용하여, SBOM에 포함된 각 컴포넌트의 알려진 취약점 정보를 확인하고, 취약점의 심각도를 평가하며, 적절한 대응 조치를 취하는 것을 포함합니다. 효과적인 취약점 탐지 방법은 다음과 같습니다.

구현 방법 및 고려사항:

  • 자동화된 취약점 스캔:
    • CI/CD 파이프라인에 SCA 도구를 통합하여, 코드 변경 시 자동으로 취약점 스캔을 수행합니다.
    • 스캔 결과는 개발팀, 보안팀, 그리고 법무팀과 공유하고, 필요한 경우 즉시 대응 조치를 취합니다.
  • 취약점 데이터베이스 연동:
    • SCA 도구를 NVD (National Vulnerability Database), CVE (Common Vulnerabilities and Exposures), 그리고 기타 신뢰할 수 있는 취약점 데이터베이스와 연동합니다.
    • 취약점 데이터베이스는 최신 정보로 지속적으로 업데이트해야 합니다.
  • 심각도 기반 분류:
    • CVSS (Common Vulnerability Scoring System) 점수를 활용하여 취약점의 심각도를 자동으로 분류합니다.
    • 심각도에 따라 취약점 대응 우선순위를 결정하고, 필요한 조치를 취합니다.
  • 수동 검증:
    • 자동화 도구로 탐지된 고위험 취약점에 대해서는 보안 전문가가 수동으로 검증합니다.
    • 수동 검증은 오탐을 줄이고, 자동화 도구에서 발견하지 못한 취약점을 식별하는 데 도움이 됩니다.

예시:

  • SCA 도구를 사용하여 Apache Struts 2 프레임워크의 취약점을 탐지하고, CVSS 점수를 확인하여 심각도를 평가합니다.
  • 고위험 취약점에 대해서는 보안 전문가가 직접 코드를 검토하고, 공격 가능성을 분석합니다.
  • 취약점이 발견된 경우, 개발팀은 즉시 패치를 적용하거나, 완화 조치를 취합니다.

구현 시 고려사항:

  • 정확도: 오탐을 줄이고, 실제 보안 위협을 정확하게 탐지할 수 있도록 도구를 선택하고 설정해야 합니다.
  • 자동화: 개발 프로세스에 통합되어 자동으로 실행될 수 있도록 구성해야 합니다.
  • 최신 정보 유지: 취약점 데이터베이스는 최신 정보로 지속적으로 업데이트해야 합니다.

이러한 접근 방식을 통해 조직은 공급 소프트웨어에 포함된 오픈소스 컴포넌트의 알려진 취약점을 효과적으로 탐지하고, 시스템을 잠재적인 공격으로부터 보호할 수 있습니다.

3.1.5.3 식별된 알려진 취약점에 대한 후속 조치 방법

ISO/IEC 18974

  • Method for following up on identified known vulnerabilities;
  • 식별된 알려진 취약점에 대한 후속 조치 방법

Self-Certification Checklist

  • We have a method for following up on identified Known Vulnerabilities;
  • 식별된 알려진 취약점에 대한 추적 방법이 있습니다.

오픈소스 컴포넌트에서 취약점이 발견되었다면, 신속하고 체계적인 후속 조치를 통해 조직의 시스템과 데이터를 보호해야 합니다. 이는 단순히 패치를 적용하는 것 이상의 의미를 가지며, 취약점의 심각도를 평가하고, 대응 우선순위를 결정하며, 적절한 해결 방안을 선택하고, 그 결과를 검증하는 일련의 과정을 포함합니다. 효과적인 후속 조치 방법은 다음과 같습니다.

구현 방법 및 고려사항:

  1. 취약점 심각도 평가 기준 수립:
    • CVSS (Common Vulnerability Scoring System) 점수를 활용하여 취약점의 심각도를 평가합니다.
    • 심각도는 높음, 중간, 낮음 등으로 분류하고, 각 심각도에 따른 대응 기한을 설정합니다.
    • 예시:
      • CVSS 7.0 이상: 높음 (24시간 이내 대응)
      • CVSS 4.0 ~ 6.9: 중간 (7일 이내 대응)
      • CVSS 0.1 ~ 3.9: 낮음 (30일 이내 대응)
  2. 취약점 대응 프로세스 정의:
    • 취약점 발견 시 보고, 평가, 해결, 그리고 검증 단계를 포함한 명확한 대응 프로세스를 정의합니다.
    • 각 단계별 담당자를 지정하고, 책임과 권한을 명확하게 명시합니다.
    • 프로세스는 문서화하고, 모든 관련 구성원에게 공유합니다.
  3. 취약점 해결 우선순위 지정 방법 수립:
    • 취약점의 심각도, 영향 범위, 그리고 악용 가능성 등을 고려하여 해결 우선순위를 결정합니다.
    • 비즈니스 중요도가 높은 시스템에 영향을 미치는 취약점은 우선적으로 해결합니다.
    • 공개적으로 알려진 익스플로잇 코드가 존재하는 취약점은 즉시 대응합니다.
  4. 취약점 해결 방법:
    • 패치 적용: 가능하다면, 해당 취약점을 해결하는 최신 버전의 오픈소스 컴포넌트로 업그레이드합니다.
    • 완화 조치: 당장 패치를 적용할 수 없는 경우, 임시적인 완화 조치를 통해 위험을 줄입니다. (예: WAF 설정 변경, 접근 제한)
    • 컴포넌트 교체: 취약점이 심각하고, 패치 적용이 어렵다면, 다른 컴포넌트로 교체하는 것을 고려합니다.

예시:

  • SCA 도구를 통해 발견된 Apache Struts 2 프레임워크의 고위험 취약점(CVE-2017-5638)에 대해, 보안팀은 즉시 심각도를 평가하고, 개발팀은 24시간 이내에 최신 버전으로 업그레이드합니다.
  • 만약 업그레이드가 불가능한 경우, WAF (Web Application Firewall) 설정을 변경하여 해당 취약점을 악용한 공격을 차단합니다.
  • 발견된 모든 취약점은 이슈 트래킹 시스템(Jira 등)에 등록하여 관리하고, 해결 과정을 추적합니다.

구현 시 고려사항:

  • 자동화: 취약점 탐지부터 해결까지의 과정을 최대한 자동화하여 효율성을 높입니다.
  • 협업: 개발팀, 보안팀, 그리고 운영팀 간의 긴밀한 협업을 통해 신속하게 대응합니다.
  • 지속적인 모니터링: 취약점 해결 후에도 지속적으로 모니터링하여, 재발생을 방지합니다.

이러한 접근 방식을 통해 조직은 식별된 알려진 취약점에 대해 체계적으로 후속 조치를 취하고, 시스템을 안전하게 유지할 수 있습니다.

3.1.5.4 식별된 알려진 취약점의 고객 전달 방법

ISO/IEC 18974

  • Method to communicate identified known vulnerabilities to customer base when warranted;
  • 필요한 경우 식별된 알려진 취약점을 고객들에게 전달하는 방법

Self-Certification Checklist

  • We have a method to communicate identified Known Vulnerabilities to customer base when warranted;
  • 필요 시 고객에게 식별된 알려진 취약점을 통지하는 방법이 있습니다.

오픈소스 컴포넌트에서 식별된 알려진 취약점이 고객에게 미치는 영향을 최소화하기 위해서는, 투명하고 신속한 정보 전달이 필수적입니다. 조직은 취약점 정보, 영향 범위, 그리고 대응 방안을 고객에게 명확하고 시기적절하게 전달할 수 있는 체계를 구축해야 합니다. 이는 고객의 신뢰를 유지하고, 브랜드 이미지를 보호하며, 법적 책임을 줄이는 데 기여합니다.

구현 방법 및 고려사항:

  1. 고객 커뮤니케이션 프로세스 수립:
    • 취약점 발생 시 고객에게 정보를 전달하는 절차를 명확하게 정의합니다.
    • 절차에는 정보 공개 결정 기준, 정보 전달 방법, 그리고 담당자 지정 등이 포함되어야 합니다.
  2. 취약점 공개 기준 정의:
    • 어떤 수준의 심각도를 가진 취약점을 고객에게 공개할 것인지에 대한 기준을 명확하게 정의합니다.
    • 일반적으로 CVSS (Common Vulnerability Scoring System) 점수를 기준으로 공개 여부를 결정합니다.
  3. 고객 연락처 데이터베이스 유지 관리:
    • 취약점 정보를 신속하게 전달할 수 있도록 최신 고객 연락처 정보를 유지 관리합니다.
    • 고객 분류를 통해, 영향 받는 고객에게만 정보를 전달할 수 있도록 합니다.

정보 전달 방법:

  • 이메일: 가장 일반적인 방법으로, 신속하게 정보를 전달할 수 있습니다.
  • 고객 포털: 고객이 직접 취약점 정보를 확인하고, 대응 방안을 다운로드할 수 있도록 제공합니다.
  • 웹사이트 공지: 일반적인 취약점 정보를 공개하고, 자세한 내용은 고객 포털에서 확인하도록 안내합니다.

정보 내용:

  • 취약점 요약: 이해하기 쉬운 용어로 취약점을 설명합니다.
  • 영향: 취약점이 고객 시스템에 미치는 잠재적인 영향을 명확하게 설명합니다.
  • 해결 방법: 가능한 경우, 패치 적용, 완화 조치, 또는 기타 해결 방법을 제공합니다.
  • 문의처: 추가적인 질문이나 지원이 필요한 경우, 고객이 연락할 수 있는 담당자 또는 부서를 명시합니다.

구현 시 고려사항:

  • 시기 적절성: 가능한 한 빨리 고객에게 정보를 전달합니다.
  • 정확성: 정확하고 신뢰할 수 있는 정보를 제공합니다.
  • 투명성: 취약점의 심각도와 영향을 솔직하게 공개합니다.
  • 일관성: 모든 고객에게 일관된 정보를 제공합니다.

예시:

  • Apache Struts 2 프레임워크에서 원격 코드 실행 취약점이 발견된 경우, 영향을 받는 고객에게 이메일을 보내고, 해당 취약점에 대한 패치를 적용하도록 안내합니다.
  • 고객 포털에 해당 취약점에 대한 자세한 정보를 게시하고, 자주 묻는 질문에 대한 답변을 제공합니다.
  • 필요한 경우, 고객에게 직접 전화하여 상황을 설명하고, 패치 적용을 지원합니다.

이러한 접근 방식을 통해 조직은 식별된 알려진 취약점에 대한 정보를 고객에게 효과적으로 전달하고, 고객의 신뢰를 유지하며, 브랜드 이미지를 보호할 수 있습니다.

3.1.5.5 공급 소프트웨어 출시 후 새로 발견된 취약점 분석 방법

ISO/IEC 18974

  • Method for analyzing supplied software for newly published known vulnerabilities post release of the supplied software;
  • 공급 소프트웨어 릴리스 후 새로 게시된 알려진 취약점에 대해 공급 소프트웨어를 분석하는 방법

Self-Certification Checklist

  • We have a method for analyzing Supplied Software for newly published Known Vulnerabilities post release of the Supplied Software;
  • 공급 소프트웨어가 출시된 후 새로 게시된 알려진 취약점을 분석하는 방법이 있습니다.

공급 소프트웨어가 출시된 이후에도 새로운 취약점이 발견될 수 있습니다. 이러한 취약점은 예기치 않은 공격 경로를 통해 시스템에 침투하거나, 기존의 보안 조치를 우회할 수 있습니다. 따라서, 조직은 공급 소프트웨어 출시 후에도 새로운 취약점을 지속적으로 모니터링하고 분석하는 체계를 갖추어야 합니다. 이는 신속한 대응을 통해 잠재적인 피해를 최소화하고, 고객의 신뢰를 유지하는 데 필수적입니다.

구현 방법 및 고려사항:

  1. 취약점 모니터링 시스템 구축:
    • NVD (National Vulnerability Database), CVE (Common Vulnerabilities and Exposures), 그리고 기타 신뢰할 수 있는 취약점 정보 소스를 지속적으로 모니터링합니다.
    • 자동화된 도구를 활용하여 새로운 취약점 정보를 수집하고, 조직의 시스템에 영향을 미칠 수 있는 취약점을 식별합니다.
  2. 초기 분류 및 영향 분석:
    • 새로운 취약점 정보를 확인한 후, 해당 취약점이 조직의 시스템에 사용되는 오픈소스 컴포넌트에 존재하는지 확인합니다.
    • 취약점의 심각도, 익스플로잇 가능성, 그리고 시스템에 미치는 잠재적인 영향을 평가합니다.
  3. 상세 분석 및 재현:
    • 영향을 미칠 가능성이 높은 취약점에 대해서는 상세 분석을 수행하고, 실제 공격 시나리오를 기반으로 취약점을 재현해 봅니다.
    • 재현 결과는 취약점의 실제 위험도를 파악하고, 적절한 대응 방안을 마련하는 데 활용합니다.
  4. 대응 계획 수립:
    • 취약점 분석 결과를 바탕으로, 패치 적용, 완화 조치, 또는 기타 대응 방안을 결정합니다.
    • 대응 계획은 기술적인 측면뿐만 아니라, 비즈니스 영향도, 법적 요구사항, 그리고 고객과의 커뮤니케이션 전략 등을 고려해야 합니다.
  5. 대응 실행 및 검증:
    • 수립된 대응 계획에 따라, 즉시 필요한 조치를 실행합니다.
    • 패치를 적용하거나, 완화 조치를 취한 후에는 반드시 취약점을 재검증하여, 문제가 해결되었는지 확인합니다.
  6. 고객 통보 (필요 시):
    • 취약점이 고객에게 미치는 영향이 큰 경우, 고객에게 해당 사실을 알리고, 필요한 조치를 안내합니다.
    • 고객과의 커뮤니케이션은 투명하고 신속하게 이루어져야 합니다.

구현 시 고려사항:

  • 자동화: 취약점 모니터링, 초기 분류, 그리고 영향 분석 프로세스를 최대한 자동화하여 효율성을 높입니다.
  • 전문가 활용: 상세 분석, 재현, 그리고 대응 계획 수립에는 보안 전문가의 전문적인 지식과 경험이 필요합니다.
  • 협업: 개발팀, 보안팀, 운영팀, 그리고 법무팀 간의 긴밀한 협업을 통해 신속하고 효과적인 대응이 가능하도록 합니다.
  • 문서화: 취약점 분석 결과, 대응 계획, 그리고 실행 결과는 상세하게 기록하여, 향후 유사한 문제가 발생했을 때 참고할 수 있도록 합니다.

예시:

  • NVD에서 Apache Struts 2 프레임워크의 새로운 취약점(예: CVE-2025-XXXX)이 발견되었다는 정보를 확인합니다.
  • SCA 도구를 사용하여, 해당 취약점이 조직의 시스템에 사용되는 Struts 2 버전에 존재하는지 확인합니다.
  • 취약점의 CVSS 점수를 확인하고, 심각도를 평가합니다.
  • 보안 전문가가 해당 취약점을 재현하고, 실제 공격 가능성을 분석합니다.
  • 개발팀과 협의하여 패치 적용 시점을 결정하고, 운영팀과 함께 시스템에 패치를 적용합니다.
  • 취약점 스캐너를 다시 실행하여, 취약점이 해결되었는지 확인합니다.
  • 해당 취약점으로 인해 고객에게 영향을 미칠 가능성이 높은 경우, 고객에게 이메일을 보내고, 필요한 조치를 안내합니다.

이러한 접근 방식을 통해 조직은 공급 소프트웨어 출시 후 새로 발견된 취약점에 대해 신속하게 대응하고, 시스템을 안전하게 유지할 수 있습니다.

3.1.5.6 출시 전 지속적이고 반복적인 보안 테스트 방법

ISO/IEC 18974

  • Method for continuous and repeated security testing to be applied for all supplied software before release;
  • 릴리스 전에 모든 공급 소프트웨어에 적용할 지속적이고 반복적인 보안 테스트 방법

Self-Certification Checklist

  • We have a method for continuous and repeated Security Testing is applied for all Supplied Software before release;
  • 모든 공급 소프트웨어에 대해 출시 전 지속적이고 반복적인 보안 테스트가 적용됩니다.

안전한 소프트웨어를 제공하기 위해서는, 릴리스 전에 보안 테스트를 단 한 번 수행하는 것으로는 충분하지 않습니다. 지속적이고 반복적인 보안 테스트는 소프트웨어 개발 라이프사이클(SDLC) 전반에 걸쳐 보안을 강화하고, 릴리스 전에 잠재적인 취약점을 식별하고 해결하는 데 필수적입니다. 특히, 오픈소스 컴포넌트를 사용하는 경우, 이러한 테스트는 오픈소스 라이선스 준수 여부와 잠재적인 보안 취약점을 확인하는 데 중요한 역할을 합니다.

구현 방법 및 고려사항:

  1. CI/CD 파이프라인에 통합:
    • 보안 테스트를 CI/CD 파이프라인에 통합하여, 코드 변경이 있을 때마다 자동으로 테스트가 실행되도록 합니다.
    • 이를 통해 개발 초기 단계부터 보안 문제를 발견하고, 해결할 수 있습니다.
  2. SCA 도구 활용:
    • SCA (Software Composition Analysis) 도구를 사용하여 오픈소스 컴포넌트의 취약점을 스캔하고, 라이선스 준수 여부를 확인합니다.
    • SCA 도구는 CI/CD 파이프라인에 통합하여, 빌드 프로세스 중에 자동으로 실행되도록 구성합니다.
  3. 정기적인 수동 검토:
    • 자동화된 도구만으로는 모든 보안 문제를 발견하기 어려울 수 있으므로, 정기적으로 수동 보안 검토를 수행합니다.
    • 수동 검토는 코드 리뷰, 아키텍처 검토, 그리고 침투 테스트 등을 포함할 수 있습니다.
  4. 테스트 결과 분석 및 개선:
    • 보안 테스트 결과를 분석하고, 발견된 취약점을 해결하기 위한 계획을 수립합니다.
    • 테스트 결과는 개발팀, 보안팀, 그리고 운영팀과 공유하고, 협업을 통해 문제를 해결합니다.
    • 테스트 프로세스를 지속적으로 개선하여, 더 효과적인 테스트를 수행할 수 있도록 합니다.

구체적인 예시:

  • 취약점 스캔 자동화: CI/CD 파이프라인에 OWASP Dependency-Check와 같은 취약점 스캔 도구를 통합하여, 빌드 프로세스 중에 자동으로 오픈소스 컴포넌트의 취약점을 스캔합니다.
  • 라이선스 검사 자동화: CI/CD 파이프라인에 FOSSology와 같은 라이선스 검사 도구를 통합하여, 빌드 프로세스 중에 자동으로 오픈소스 컴포넌트의 라이선스 준수 여부를 검사합니다.
  • 코드 리뷰 의무화: 모든 코드 변경 사항에 대해 코드 리뷰를 의무화하고, 보안 취약점을 찾기 위한 노력을 기울입니다.
  • 침투 테스트 수행: 릴리스 전에 외부 보안 전문가에게 의뢰하여 시스템에 대한 침투 테스트를 수행하고, 잠재적인 보안 취약점을 식별합니다.

구현 시 고려사항:

  • 테스트 범위: 모든 오픈소스 컴포넌트 및 사용자 정의 코드에 대해 보안 테스트를 수행해야 합니다.
  • 테스트 주기: 코드 변경이 있을 때마다, 그리고 릴리스 전에 보안 테스트를 수행해야 합니다.
  • 테스트 환경: 실제 운영 환경과 유사한 테스트 환경을 구축하여, 테스트 결과의 신뢰도를 높여야 합니다.

이러한 접근 방식을 통해 조직은 릴리스 전에 잠재적인 보안 취약점을 식별하고 해결함으로써, 보다 안전한 소프트웨어를 제공할 수 있습니다.

3.1.5.7 공급 소프트웨어 출시 전 식별된 위험 해결 확인 방법

ISO/IEC 18974

  • Method to verify that identified risks will have been addressed before release of supplied software;
  • 공급 소프트웨어 릴리스 전에 식별된 위험이 해결되었는지 확인하는 방법

Self-Certification Checklist

  • We have a method to verify that identified risks will have been addressed before release of Supplied Software;
  • 출시 전 식별된 위험이 해결되었음을 확인하는 방법이 있습니다.

공급 소프트웨어를 릴리스하기 전에 SCA(Software Composition Analysis) 도구로 발견한 알려진 취약점을 해결하는 것은 최종 제품의 보안 수준을 보장하는 데 매우 중요합니다. 이는 취약한 오픈소스 컴포넌트를 패치하거나 제거하는 활동을 포함하며, 향후 유사한 문제가 발생하지 않도록 예방하는 것을 목표로 합니다.

구현 방법 및 고려사항:

  1. SCA 도구를 통한 취약점 식별:
    • CI/CD 파이프라인에 SCA 도구를 통합하여 지속적으로 취약점을 스캔합니다.
    • 릴리스 전 최종 스캔을 수행하여 모든 알려진 취약점을 식별합니다.
  2. 취약점 해결 프로세스 정의:
    • 식별된 각 취약점에 대해 패치 적용 또는 컴포넌트 제거 등의 해결 방법을 결정합니다.
    • 심각도에 따라 우선순위를 설정하고, 고위험 취약점부터 해결합니다.
  3. 해결 검증 절차 수립:
    • 패치 적용 후 재스캔을 통해 취약점이 해결되었는지 확인합니다.
    • 컴포넌트 제거 시, 해당 기능이 정상적으로 대체되었는지 확인합니다.
  4. 최종 보안 승인 절차:
    • 모든 고위험 취약점이 해결되었음을 확인한 후, 보안 책임자의 최종 승인을 받습니다.
    • 잔존 위험에 대해서는 문서화하고 관리 계획을 수립합니다.

구체적인 예시:

  • Apache Struts 2 프레임워크의 알려진 취약점(예: CVE-2017-5638)이 SCA 도구로 발견된 경우, 해당 버전을 최신 패치된 버전으로 업그레이드합니다.
  • 더 이상 유지보수되지 않는 오픈소스 라이브러리가 발견된 경우, 해당 라이브러리를 제거하고 대체 라이브러리로 교체합니다.

구현 시 고려사항:

  • 자동화: SCA 도구의 스캔 및 결과 분석을 자동화하여 효율성을 높입니다.
  • 지속적인 모니터링: 릴리스 후에도 새로운 취약점을 지속적으로 모니터링하고 대응합니다.
  • 문서화: 취약점 해결 과정과 결과를 상세히 문서화하여 추후 참조할 수 있도록 합니다.

이러한 접근 방식을 통해 조직은 공급 소프트웨어 릴리스 전에 알려진 취약점을 효과적으로 해결하고, 최종 제품의 보안 수준을 크게 향상시킬 수 있습니다.

3.1.5.8 식별된 위험의 제3자 전달 방법

ISO/IEC 18974

  • Method to export information about identified risks to third parties as appropriate.
  • 식별된 위험에 대한 정보를 제3자에게 적절하게 내보내는 방법

Self-Certification Checklist

  • We have a method to export information about identified risks to third parties as appropriate.
  • 식별된 위험 정보를 제3자에게 전달하는 방법이 있습니다.

조직의 공급 소프트웨어에 존재하는 보안 위험은 조직 자체뿐만 아니라, 해당 소프트웨어를 사용하는 고객, 협력사, 그리고 오픈소스 커뮤니티 등 다양한 이해관계자에게 영향을 미칠 수 있습니다. 따라서, 조직은 식별된 위험을 적절하게 제3자에게 전달하여, 함께 위험을 관리하고, 전체적인 소프트웨어 공급망의 보안을 강화해야 합니다. 이 과정은 투명하고 책임감 있는 자세로 수행되어야 하며, 관련 법규 및 계약 조건을 준수해야 합니다.

구현 방법 및 고려사항:

  1. 위험 평가 및 분류:
    • 식별된 위험의 심각도, 영향 범위, 그리고 전파 가능성 등을 평가하여, 어떤 제3자에게 정보를 전달해야 하는지 결정합니다.
    • 개인 정보 유출, 시스템 장애, 그리고 금전적 손실 등을 초래할 수 있는 고위험 취약점에 대해서는 즉시 정보를 공유해야 합니다.
  2. 정보 공유 기준 정의:
    • 어떤 정보를 어떤 방식으로 공유할 것인지에 대한 기준을 명확하게 정의합니다.
    • 정보는 간결하고 명확하게 작성되어야 하며, 기술적인 내용과 함께 비기술적인 설명도 제공해야 합니다.
    • 취약점 설명, 영향, 해결 방법, 그리고 문의처 등을 포함합니다.
  3. 커뮤니케이션 채널 구축:
    • 제3자와 안전하게 정보를 공유할 수 있는 커뮤니케이션 채널을 구축합니다.
    • 이메일, 고객 포털, 그리고 보안 게시판 등을 활용할 수 있습니다.
    • 정보 보안을 위해 암호화 통신, 접근 권한 관리, 그리고 데이터 유출 방지 기술 등을 적용합니다.
  4. 법적 및 계약적 의무 준수:
    • 정보 공유 시 관련 법규(예: 개인정보보호법) 및 계약 조건(예: 기밀 유지 조항)을 준수합니다.
    • 법무팀과 협의하여 정보 공유에 대한 법적 검토를 수행합니다.
  5. 책임자 지정:
    • 위험 정보 공유 프로세스를 총괄하는 책임자를 지정합니다.
    • 책임자는 정보 공유 결정, 정보 내용 검토, 그리고 제3자와의 커뮤니케이션 등을 담당합니다.

구체적인 예시:

  • 오픈소스 커뮤니티:
    • 자체 개발 코드에서 발견한 취약점을 해당 오픈소스 프로젝트에 보고하고, 패치 개발에 협력합니다.
    • 사이버 보안 취약점 정보 공유 프로그램(Cybersecurity Vulnerability Information Sharing Program) 활용을 고려합니다.
  • 고객:
    • 사이버 보안 취약점 발생 시 고객에게 즉시 통지하고, 취약점의 영향과 해결 방안을 안내합니다.
    • 필요한 경우, 고객 시스템에 대한 원격 지원을 제공하여, 패치 적용을 지원합니다.
  • 공급업체:
    • 자신들이 제공한 소프트웨어 또는 하드웨어에서 취약점이 발견된 경우, 해당 사실을 고객에게 알리고, 패치 또는 업데이트를 제공합니다.

구현 시 고려사항:

  • 시기 적절성: 가능한 한 빨리 정보를 공유하여, 제3자가 적절한 조치를 취할 수 있도록 합니다.
  • 정확성: 정확하고 신뢰할 수 있는 정보를 제공합니다.
  • 투명성: 취약점의 심각도와 영향을 솔직하게 공개합니다.

이러한 접근 방식을 통해 조직은 식별된 위험을 제3자와 효과적으로 공유하고, 공급망 전반의 보안을 강화할 수 있습니다. 책임감 있는 정보 공유는 조직의 신뢰도를 높이고, 장기적인 비즈니스 관계를 구축하는 데 기여할 것입니다.

2.3.2 - 3.2 Relevant Tasks Defined and Supported

오픈소스 보안 보증 프로그램이 효과적으로 운영되기 위해서는, 관련된 모든 작업이 명확하게 정의되고, 필요한 자원이 적절하게 할당되어야 합니다. 이는 프로그램 운영에 필요한 인력, 예산, 그리고 기술적인 전문 지식을 확보하고, 프로그램의 지속적인 개선을 지원하는 데 필수적입니다.

3.2.1 Access (접근성)

타사에서 조직의 소프트웨어에 영향을 미치는 알려진 취약점에 대해 문의할 수 있는 접근성을 제공하는 것은, 투명성을 높이고, 커뮤니티와의 협력을 강화하며, 잠재적인 보안 문제를 신속하게 해결하는 데 매우 중요합니다.

3.2.1.1 공개적으로 볼 수 있는 취약점 문의 방법

ISO/IEC 18974

  • 4.2.1.1: Publicly visible method to allow third parties to make known vulnerability or newly discovered vulnerability enquires (e.g., via an email address or web portal that is monitored by program participants);
  • 4.2.1.1 제3자가 알려진 취약점 또는 새로 발견된 취약점에 대한 문의를 할 수 있도록 공개적으로 볼 수 있는 방법 (예: 프로그램 참여자가 모니터링하는 이메일 주소 또는 웹 포털)

Self-Certification Checklist

  • We have a method to allow third parties to make Known Vulnerability or Newly Discovered Vulnerability enquires (e.g., via an email address or web portal that is monitored by Program Participants);
  • 제3자가 알려진 취약점 또는 새로 발견된 취약점에 대한 문의를 할 수 있는 방법(예: 이메일 주소 또는 웹 포털)이 있습니다.

조직은 누구나 쉽게 접근할 수 있는 방법으로, 소프트웨어의 취약점에 대한 정보를 제공할 수 있도록 해야 합니다. 이는 조직의 웹사이트, 보안 관련 페이지, 또는 별도의 버그 바운티 플랫폼 등을 통해 구현할 수 있습니다. 중요한 것은, 정보 제공 방법이 명확하고, 쉽게 찾을 수 있어야 하며, 지속적으로 모니터링되어야 한다는 점입니다.

구현 방법 및 고려사항:

  • 전용 이메일 주소:
    • security@example.com과 같이, 취약점 보고를 위한 전용 이메일 주소를 생성하고, 웹사이트에 공개합니다.
    • 이메일 주소는 보안팀 또는 관련 담당자가 지속적으로 모니터링해야 합니다.
  • 웹 기반 보고 양식:
    • 취약점 보고에 필요한 정보(예: 소프트웨어 이름, 버전, 취약점 설명, 재현 방법)를 입력할 수 있는 웹 기반 보고 양식을 제공합니다.
    • 보고 양식은 사용하기 쉽고, 명확한 안내 문구를 포함해야 합니다.
  • 보안 페이지:
    • 조직의 보안 정책, 취약점 보고 절차, 그리고 관련 연락처 정보를 포함하는 보안 페이지를 웹사이트에 게시합니다.
    • 보안 페이지는 쉽게 찾을 수 있도록, 웹사이트 메인 페이지에 링크를 제공합니다.
  • 버그 바운티 프로그램:
    • 외부 보안 전문가에게 조직의 시스템을 테스트하고, 취약점을 발견하도록 장려하는 버그 바운티 프로그램을 운영합니다.
    • 버그 바운티 프로그램은 취약점 보고에 대한 보상을 제공하고, 연구자들의 참여를 유도합니다.

예시:

  • “저희 회사의 제품에서 보안 취약점을 발견하신 경우, security@example.com으로 연락주시기 바랍니다. 자세한 내용은 보안 페이지를 참조하십시오.” 와 같은 문구를 웹사이트에 게시합니다.
  • 취약점 보고 웹 양식에는 다음과 같은 항목을 포함합니다.
    • 보고자 정보 (이름, 이메일 주소)
    • 영향 받는 제품 및 버전
    • 취약점 설명
    • 재현 단계
    • 증거 자료 (스크린샷, 로그 파일 등)

3.2.1.2 취약점 문의 대응 내부 절차

ISO/IEC 18974

  • 4.2.1.2: An internal documented procedure for responding to third party known vulnerability or newly discovered vulnerability inquiries.
  • 4.2.1.2 제3자의 알려진 취약점 또는 새로 발견된 취약점 문의에 응답하기 위한 내부 문서화된 절차가 존재합니다.

Self-Certification Checklist

  • We have an internal documented procedure for responding to third party Known Vulnerability or Newly Discovered Vulnerability inquiries.
  • 외부 문의에 대한 내부 대응 절차가 문서화되어 있습니다.

외부에서 취약점 문의가 접수되었을 때, 조직 내부에서 체계적이고 효율적으로 대응하기 위한 절차를 마련하는 것은 매우 중요합니다. 이 절차는 문의 접수, 분석, 해결, 그리고 보고 과정 전반을 아우르며, 각 단계별 책임자와 기한을 명확히 정의해야 합니다. 또한, 정보 보안 및 법적 책임을 고려하여, 민감한 정보를 안전하게 처리하고 공유할 수 있도록 해야 합니다.

구현 방법 및 고려사항:

  • 대응 팀 구성:
    • 취약점 문의를 접수하고 처리할 책임 있는 팀 또는 담당자를 지정합니다.
    • 대응 팀은 보안 전문가, 개발자, 그리고 법률 담당자 등을 포함할 수 있습니다.
  • 프로세스 정의:
    • 취약점 문의 접수, 분류, 분석, 해결, 그리고 보고 단계를 포함한 전체 프로세스를 문서화합니다.
    • 각 단계별 책임자와 기한을 명확하게 정의합니다.
  • 심각도 평가 기준:
    • 취약점의 심각도를 평가하기 위한 기준을 마련합니다.
    • CVSS (Common Vulnerability Scoring System) 점수를 활용하여 취약점의 심각도를 객관적으로 평가할 수 있습니다.
  • 대응 절차:
    • 취약점의 심각도에 따라 다른 대응 절차를 마련합니다.
    • 고위험 취약점에 대해서는 즉시 대응하고, 저위험 취약점에 대해서는 모니터링 또는 장기적인 해결 방안을 고려합니다.
  • 커뮤니케이션 가이드라인:
    • 취약점을 보고한 사람에게 진행 상황을 알리고, 필요한 정보를 요청하는 방법에 대한 가이드라인을 마련합니다.
    • 고객과의 소통은 투명하고 신속하게 이루어져야 합니다.

구체적인 절차 예시:

  1. 접수: security@example.com으로 접수된 취약점 문의는 보안팀에서 확인하고, 접수 번호를 부여합니다.
  2. 분류: 보안팀은 취약점의 유형과 영향을 받는 시스템을 분석하고, 심각도를 평가합니다.
  3. 분석: 개발팀은 취약점의 원인을 분석하고, 해결 방안을 모색합니다.
  4. 해결: 개발팀은 취약점을 해결하기 위한 코드를 수정하고, 테스트를 수행합니다.
  5. 검증: QA팀은 수정된 코드에 새로운 취약점이 없는지 확인하고, 기존 취약점이 해결되었는지 검증합니다.
  6. 보고: 보안팀은 취약점 해결 결과를 보고하고, 관련 문서를 업데이트합니다.
  7. 통보: 보안팀은 취약점을 보고한 사람에게 해결 결과를 통보합니다.

3.2.2 Effectively Resourced (효과적인 자원 할당)

오픈소스 보안 보증 프로그램을 성공적으로 운영하기 위해서는, 단순히 정책과 절차를 수립하는 것만으로는 충분하지 않습니다. 이러한 정책과 절차가 실제로 효과를 발휘하기 위해서는, 프로그램에 필요한 인력, 예산, 그리고 기술적인 전문 지식을 적절하게 확보하고 할당해야 합니다. 이는 프로그램의 지속 가능성을 보장하고, 변화하는 위협 환경에 효과적으로 대응할 수 있도록 하는 데 매우 중요합니다.

3.2.2.1 프로그램 역할 식별 문서

ISO/IEC 18974

  • 4.2.2.1: Document with name of persons, group or function in program role(s) identified;
  • 4.2.2.1 프로그램 역할에 지정된 개인, 그룹 또는 기능의 이름이 포함된 문서.

Self-Certification Checklist

  • We have documented the people, group or functions related to the Program.
  • 프로그램 관련 인물, 그룹, 또는 기능을 문서화했습니다.

프로그램 역할 식별 문서는 오픈소스 보안 보증 프로그램의 성공적인 운영을 위한 초석과 같습니다. 이 문서는 프로그램에 참여하는 모든 이해관계자들이 각자의 역할과 책임을 명확히 이해하도록 돕고, 효율적인 협업과 의사소통을 가능하게 합니다. 또한, 책임 소재를 명확히 함으로써, 프로그램 운영 과정에서 발생할 수 있는 혼란과 책임을 회피하는 상황을 방지합니다.

구현 방법 및 고려사항:

  1. 포괄적인 역할 정의:
    • 프로그램 운영에 필요한 모든 역할을 식별하고, 각 역할의 목표, 책임, 그리고 권한을 명확하게 정의합니다.
    • 프로그램 관리자, 보안 전문가, 법률 담당자, 개발자, 그리고 운영 담당자 등 다양한 역할을 고려합니다.
  2. 책임 할당:
    • 각 역할에 적합한 담당자 또는 팀을 지정하고, 책임과 권한을 명확하게 부여합니다.
    • 담당자는 해당 역할에 필요한 전문 지식과 경험을 갖추고 있어야 합니다.
  3. RACI 매트릭스 활용 (선택 사항):
    • RACI (Responsible, Accountable, Consulted, Informed) 매트릭스를 활용하여 각 역할의 책임을 더욱 명확하게 정의할 수 있습니다.
    • RACI 매트릭스는 각 작업에 대해 누가 책임을 지고, 누가 실행하며, 누가 협의하고, 누가 정보를 제공받는지 명확하게 보여줍니다.
  4. 문서화:
    • 역할 정의, 책임 할당, 그리고 RACI 매트릭스 (선택 사항) 등을 문서화하여, 프로그램 참여자들이 쉽게 접근할 수 있도록 합니다.
    • 문서는 조직의 내부 위키, 공유 문서 저장소, 또는 기타 협업 도구에 게시할 수 있습니다.
  5. 정기적인 검토 및 업데이트:
    • 프로그램의 역할 정의는 조직의 구조, 운영 방식, 그리고 기술 환경 변화에 따라 변경될 수 있습니다.
    • 따라서, 역할 정의 문서를 정기적으로 검토하고 업데이트하여, 최신 상태를 유지해야 합니다.

예시:

역할책임설명
오픈소스 프로그램 매니저 (OSPM)프로그램 총괄 관리- 오픈소스 정책 수립 및 관리
- 오픈소스 사용 요청 검토 및 승인
- 보안 취약점 및 라이선스 위반 관리
보안 전문가보안 취약점 분석 및 대응- 오픈소스 컴포넌트의 취약점 스캔
- 취약점 심각도 평가 및 대응 방안 수립
- 보안 사고 발생 시 대응
법률 담당라이선스 준수 및 법적 위험 관리- 오픈소스 라이선스 검토 및 분석
- 법적 위험 평가 및 관리
- 분쟁 해결 지원
개발팀안전한 코드 개발 및 오픈소스 사용- 오픈소스 정책 및 가이드라인 준수
- 보안 취약점 수정 및 패치 적용
- 새로운 오픈소스 컴포넌트 사용 시 검토 요청

구현 시 고려사항:

  • 문서는 간결하고 명확하게 작성되어야 하며, 모든 프로그램 참여자가 쉽게 이해할 수 있어야 합니다.
  • 문서는 접근 권한을 적절하게 관리하여, 기밀 정보를 보호해야 합니다.
  • 문서는 정기적으로 검토하고 업데이트하여, 최신 상태를 유지해야 합니다.

3.2.2.2 프로그램 역할의 적절한 인력 배치 및 자금 제공

ISO/IEC 18974

  • 4.2.2.2: The identified program roles have been properly staffed and adequate funding provided;
  • 4.2.2.2 식별된 프로그램 역할이 적절히 인력 배치되었으며 충분한 예산이 제공되었음을 나타내는 문서.

Self-Certification Checklist

  • We have ensured the identified Program roles have been properly staffed and adequate funding has been provided.
  • 식별된 프로그램 역할이 적절히 인력 배치되고 충분한 자금이 제공되었음을 확인했습니다.

프로그램 역할이 아무리 잘 정의되어 있어도, 해당 역할을 수행할 인력이 부족하거나, 필요한 자금이 제대로 지원되지 않는다면 프로그램은 제대로 운영될 수 없습니다. 따라서, 조직은 각 역할에 필요한 인력을 적절하게 배치하고, 프로그램 운영에 필요한 충분한 자금을 제공해야 합니다. 이는 프로그램의 성공적인 운영을 위한 필수적인 조건입니다.

구현 방법 및 고려사항:

  1. 인력 계획 수립:
    • 각 역할별로 필요한 인력 수를 정확하게 산정합니다.
    • 인력 산정 시에는 역할의 책임 범위, 업무량, 그리고 필요한 기술 수준 등을 고려해야 합니다.
    • 장기적인 관점에서 인력 수요를 예측하고, 채용 또는 내부 인력 재배치 계획을 수립합니다.
  2. 예산 계획 수립:
    • 프로그램 운영에 필요한 모든 비용 항목(인건비, 교육비, 도구 구매비, 컨설팅 비용 등)을 식별하고, 각 항목별 예산을 산정합니다.
    • 예산은 현실적으로 집행 가능하도록, 충분한 근거를 바탕으로 산정해야 합니다.
    • 예산 확보 계획을 수립하고, 경영진의 승인을 받습니다.
  3. 자원 확보 및 배분:
    • 인력 채용 또는 내부 인력 재배치를 통해 필요한 인력을 확보합니다.
    • 확보된 예산을 각 항목별로 적절하게 배분합니다.
    • 자원 배분 시에는 프로그램의 우선순위와 목표를 고려해야 합니다.
  4. 정기적인 검토 및 조정:
    • 인력 및 예산 계획의 적절성을 정기적으로 검토하고, 필요에 따라 조정합니다.
    • 프로그램 운영 상황, 예산 집행 현황, 그리고 외부 환경 변화 등을 고려하여 계획을 업데이트합니다.

예시:

  • 인력:
    • 보안팀에 오픈소스 보안 전문가 2명을 채용하여, 오픈소스 컴포넌트의 취약점 분석 및 대응을 담당하도록 합니다.
    • 법무팀에 오픈소스 라이선스 전문가 1명을 지정하여, 오픈소스 사용 시 법적 검토를 지원하도록 합니다.
  • 예산:
    • 오픈소스 보안 도구(SCA, SAST 등) 구매에 연간 5천만원의 예산을 배정합니다.
    • 오픈소스 보안 교육 프로그램 운영에 연간 1천만원의 예산을 배정합니다.
    • 외부 보안 컨설팅 비용으로 연간 2천만원의 예산을 배정합니다.

3.2.2.3 알려진 취약점 해결을 위한 전문 지식 식별

ISO/IEC 18974

  • 4.2.2.3: Identification of expertise available to address identified known vulnerabilities;
  • 4.2.2.3 식별된 알려진 취약점을 해결하기 위해 이용 가능한 전문성을 명시한 문서.

Self-Certification Checklist

  • We have ensured expertise available is to address identified Known Vulnerabilities;
  • 식별된 알려진 취약점을 해결하기 위한 전문 지식이 확보되어 있음을 확인했습니다.

오픈소스 컴포넌트에서 알려진 취약점이 발견되었을 때, 이를 신속하고 효과적으로 해결하기 위해서는 해당 취약점에 대한 전문 지식을 가진 인력이 필요합니다. 이러한 전문 지식은 내부 인력으로부터 확보할 수도 있고, 외부 전문가의 도움을 받을 수도 있습니다. 중요한 것은, 필요한 전문 지식을 적시에 확보하고 활용할 수 있는 체계를 구축하는 것입니다.

구현 방법 및 고려사항:

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

구체적인 예시:

  • 취약점 분석:
    • 특정 오픈소스 컴포넌트에서 SQL Injection 취약점이 발견된 경우, 웹 보안 전문가에게 분석을 의뢰하고, 공격 경로와 영향 범위를 파악합니다.
  • 라이선스:
    • 특정 오픈소스 라이선스의 의무사항에 대한 해석이 필요한 경우, 오픈소스 라이선스 전문가에게 법적 검토를 의뢰합니다.

3.2.2.4 보안 보증에 대한 내부 책임 할당 절차

ISO/IEC 18974

  • 4.2.2.4: A documented procedure that assigns internal responsibilities for security assurance.
  • 4.2.2.4 보안 보증을 위해 내부 책임을 할당하는 절차를 문서화한 자료.

Self-Certification Checklist

  • We have a documented procedure that assigns internal responsibilities for Security Assurance.
  • 보안 보증에 대한 내부 책임을 할당하는 절차가 문서화되어 있습니다.

오픈소스 보안 보증 프로그램의 효과적인 운영을 위해 내부 책임을 명확히 할당하는 절차를 수립합니다. 이 절차는 다음과 같습니다:

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

2.3.3 - 3.3 Open Source Software Content Review and Approval

오픈소스 소프트웨어는 현대 소프트웨어 개발에 있어 필수적인 요소가 되었지만, 동시에 보안 및 법적 위험을 수반하기도 합니다. 따라서, 조직은 공급 소프트웨어에 포함된 오픈소스 컴포넌트를 체계적으로 검토하고 승인하는 프로세스를 구축하여, 이러한 위험을 효과적으로 관리해야 합니다.

3.3.1 Software Bill of Materials (소프트웨어 자재 명세서)

SBOM(Software Bill of Materials)은 소프트웨어를 구성하는 모든 컴포넌트, 라이브러리, 그리고 종속성을 나열한 목록입니다. 이는 소프트웨어의 “재료 목록"과 같으며, 소프트웨어 공급망의 투명성을 확보하고, 잠재적인 보안 취약점과 라이선스 관련 문제를 식별하는 데 매우 중요한 역할을 합니다.

3.3.1.1 SBOM 생성 및 유지 절차

ISO/IEC 18974

  • 4.3.1.1: A documented procedure ensuring all open source software used in the supplied software is continuously recorded across the lifecycle of the supplied software. This includes an archive of all open source software used in the supplied software;
  • 4.3.1.1 공급 소프트웨어에 사용되는 모든 오픈 소스 소프트웨어가 공급 소프트웨어의 수명 주기 동안 지속적으로 기록되도록 보장하는 문서화된 절차. 여기에는 공급 소프트웨어에 사용되는 모든 오픈 소스 소프트웨어의 아카이브가 포함됩니다.

Self-Certification Checklist

  • We have a documented procedure ensuring all Open Source Software used in the Supplied Software is continuously recorded across the lifecycle of the Supplied Software. This includes an archive of all Open Source Software used in the Supplied Software.
  • 공급 소프트웨어에 사용된 모든 오픈소스 소프트웨어가 공급 소프트웨어의 수명 주기 전반에 걸쳐 지속적으로 기록되는 절차가 있습니다. 이 절차는 모든 오픈소스 소프트웨어의 아카이브를 포함합니다.

SBOM은 단순히 한 번 생성하는 것으로 끝나는 것이 아니라, 소프트웨어의 라이프사이클 전반에 걸쳐 지속적으로 업데이트되고 관리되어야 합니다. 소프트웨어가 변경됨에 따라 새로운 컴포넌트가 추가되거나, 기존 컴포넌트가 업데이트될 수 있기 때문입니다. 따라서, 조직은 SBOM을 생성하고 유지하는 절차를 명확하게 정의하고, 이를 문서화해야 합니다.

구현 방법 및 고려사항:

  1. SBOM 생성 도구 선정:
    • SBOM을 자동으로 생성하고 관리할 수 있는 도구를 선정합니다.
    • SPDX, CycloneDX, 그리고 SWID Tag 등과 같은 표준화된 SBOM 형식을 지원하는 도구를 선택하는 것이 좋습니다. 아래 “주요 SBOM 생성 도구 비교” 표를 참고하세요.
    • 도구는 CI/CD 파이프라인에 통합하여, 빌드 프로세스 중에 자동으로 SBOM을 생성할 수 있도록 구성합니다.
  2. SBOM 생성 및 업데이트 주기 정의:
    • SBOM을 언제 생성하고 업데이트할 것인지에 대한 주기를 정의합니다.
    • 일반적으로 소프트웨어의 새로운 버전이 릴리스될 때마다 SBOM을 생성하고 업데이트합니다.
    • 또한, 오픈소스 컴포넌트의 변경 사항이 있을 때마다 SBOM을 업데이트해야 합니다.
  3. SBOM 검증 프로세스 수립:
    • 생성된 SBOM의 정확성과 완전성을 검증하는 프로세스를 수립합니다.
    • 검증 프로세스에는 SBOM에 포함된 모든 컴포넌트가 정확하게 식별되었는지 확인하고, 누락된 컴포넌트가 없는지 확인하는 작업이 포함됩니다.
    • 자동화된 도구를 사용하여 SBOM을 검증할 수도 있습니다.
  4. SBOM 저장 및 버전 관리:
    • 생성된 SBOM을 안전하게 저장하고, 버전 관리를 수행합니다.
    • SBOM은 조직의 내부 저장소 또는 클라우드 기반 저장소에 저장할 수 있습니다.
    • 버전 관리를 통해, 특정 시점의 소프트웨어를 구성하는 컴포넌트를 정확하게 파악할 수 있습니다.
  5. SBOM 접근 권한 및 공유 정책 수립:
    • 누가 SBOM에 접근할 수 있는지, 그리고 SBOM을 어떻게 공유할 것인지에 대한 정책을 수립합니다.
    • SBOM은 조직 내부의 관련 부서(예: 개발팀, 보안팀, 법무팀)와 공유해야 합니다.
    • 또한, 고객 또는 규제 기관의 요청이 있는 경우, SBOM을 제공해야 할 수도 있습니다.

표 : 주요 SBOM 생성 도구 비교

도구 이름지원 언어/패키지CI/CD 통합출력 형식오픈소스 여부기타
SPDX Tools다양함가능SPDXSPDX 형식에 특화
FOSSLight다양함가능SPDX, CycloneDX, Excel, Text다양한 스캐너 연동, FOSSLight Hub를 통한 통합 관리 기능 제공
SW360다양함제한적SPDX오픈소스 컴플라이언스 관리 기능, 대규모 조직에 적합
OSV-SCALIBR다양함제한적JSON라이브러리 형태로 제공, 직접 통합 필요
Tern (컨테이너 특화)컨테이너 이미지가능SPDX, CycloneDX컨테이너 이미지 레이어 분석
Syft (컨테이너 특화)컨테이너 이미지, 파일 시스템, 다양한 아티팩트쉬움SPDX, CycloneDX, Text, Table다양한 아티팩트 유형 지원, 사용하기 쉬운 CLI 제공

이들 도구의 설치 및 사용 가이드는 부록에서 제공됩니다.

구체적인 예시:

  • CI/CD 파이프라인에 OWASP Dependency-Track을 통합하여, 빌드 프로세스 중에 자동으로 SBOM을 생성하고, 취약점을 분석합니다.
  • 새로운 버전의 소프트웨어가 릴리스될 때마다, SBOM을 생성하고 조직의 내부 저장소에 저장합니다.
  • SBOM은 보안팀, 개발팀, 그리고 법무팀과 공유하고, 필요에 따라 고객에게 제공합니다.

구현 시 고려사항:

  • SBOM 생성 및 유지 절차는 조직의 규모, 소프트웨어 개발 프로세스, 그리고 규제 요구사항 등을 고려하여 맞춤화되어야 합니다.
  • SBOM 생성 프로세스를 최대한 자동화하여 효율성을 높여야 합니다.
  • SBOM에 포함되는 정보의 정확성과 완전성을 보장하기 위해 노력해야 합니다.

3.3.1.2 SBOM 관리 절차 준수 증거

ISO/IEC 18974

  • 4.3.1.2: open source software component records for the supplied software that demonstrates the documented procedure was properly followed.
  • 4.3.1.2 문서화된 절차가 올바르게 수행되었음을 입증하는 공급 소프트웨어에 대한 오픈 소스 소프트웨어 컴포넌트 기록.

Self-Certification Checklist

  • We have open source component records for the Supplied Software which demonstrate the documented procedure was properly followed.
  • 공급 소프트웨어에 대한 오픈소스 컴포넌트 기록이 문서화된 절차가 적절히 수행되었음을 입증합니다.

효과적인 SBOM 관리는 단순히 SBOM을 생성하는 것을 넘어, 지속적으로 관리하고, 최신 정보를 유지하며, 필요한 경우 활용할 수 있는 체계를 갖추는 것을 의미합니다. SBOM 관리 절차 준수 증거는 조직이 이러한 체계를 제대로 운영하고 있다는 것을 입증하는 데 사용됩니다.

구현 방법 및 고려사항:

  1. 자동화된 SBOM 생성 프로세스:
    • CI/CD 파이프라인에 SBOM 생성 도구를 통합하여, 소프트웨어 빌드 시 자동으로 SBOM이 생성되도록 합니다.
    • 자동화된 프로세스는 SBOM 생성의 일관성과 효율성을 높이고, 휴먼 에러를 줄이는 데 기여합니다.
    • 자동화 도구는 SBOM 생성 로그를 기록하고, 결과 파일을 지정된 위치에 저장해야 합니다.
  2. SBOM 검증 프로세스:
    • 자동 또는 수동 검증 프로세스를 통해 SBOM의 정확성과 완전성을 확인합니다.
    • 검증 프로세스에는 SBOM에 포함된 컴포넌트 목록과 실제 소프트웨어에 사용된 컴포넌트 목록을 비교하고, 누락되거나 잘못된 정보가 없는지 확인하는 작업이 포함됩니다.
    • 검증 결과는 문서화하고, 필요한 경우 수정 조치를 취합니다.
  3. SBOM 저장 및 접근 관리:
    • SBOM을 안전하게 저장하고, 접근 권한을 적절하게 관리합니다.
    • SBOM은 내부 저장소, 버전 관리 시스템, 또는 SBOM 관리 플랫폼 등에 저장할 수 있습니다.
    • 접근 권한은 역할 기반으로 관리하고, 필요한 사람에게만 접근 권한을 부여합니다.
  4. SBOM 업데이트 및 버전 관리:
    • 소프트웨어가 변경될 때마다 SBOM을 업데이트하고, 버전 관리를 수행합니다.
    • 각 버전별 SBOM을 유지하여, 특정 시점의 소프트웨어를 구성하는 컴포넌트를 정확하게 파악할 수 있도록 합니다.
  5. 정기적인 감사 및 검토:
    • SBOM 관리 프로세스의 효과성을 정기적으로 감사하고 검토합니다.
    • 감사 결과는 프로세스 개선에 활용하고, 필요한 경우 정책 및 절차를 업데이트합니다.

증거 자료 예시:

  • SBOM 생성 로그:
    • SBOM 생성 도구 실행 로그, 생성 일시, 그리고 생성 결과 등을 기록합니다.
  • SBOM 파일:
    • 생성된 SBOM 파일을 안전하게 보관하고, 버전 관리를 수행합니다.
  • SBOM 검증 보고서:
    • SBOM 검증 방법, 검증 결과, 그리고 발견된 문제점 및 해결 방안 등을 기록합니다.
  • SBOM 변경 이력:
    • SBOM 변경 이유, 변경 내역, 그리고 변경 일시 등을 기록합니다.

구현 시 고려사항:

  • SBOM 관리 절차는 조직의 규모, 소프트웨어 개발 프로세스, 그리고 규제 요구사항 등을 고려하여 맞춤화되어야 합니다.
  • SBOM 관리를 위한 도구 및 시스템을 효과적으로 활용해야 합니다.
  • SBOM 관리 프로세스를 지속적으로 개선하고, 최신 기술 및 위협 동향을 반영해야 합니다.

이러한 접근 방식을 통해 조직은 SBOM 관리 절차를 효과적으로 준수하고, 소프트웨어 공급망의 투명성을 확보하며, 잠재적인 보안 위협과 법적 위험에 효과적으로 대응할 수 있습니다.

이 가이드에서는 ISO/IEC 18974 요구사항을 모두 충족하는 오픈소스 프로세스 템플릿을 제공합니다. : 오픈소스 프로세스 템플릿

3.3.1 Security assurance (보안보증)

오픈소스 소프트웨어의 사용이 증가함에 따라, 보안 보증은 소프트웨어 개발 및 관리 프로세스에서 핵심적인 부분이 되었습니다. 보안 보증은 오픈소스 컴포넌트의 취약점을 식별하고 관리하여 전체 시스템의 보안을 강화하는 과정을 의미합니다. 이는 단순히 취약점을 찾아내는 것을 넘어, 지속적인 모니터링, 신속한 대응, 그리고 체계적인 관리를 통해 소프트웨어의 전체 수명 주기에 걸쳐 보안을 보장하는 것을 목표로 합니다.

효과적인 보안 보증 프로그램은 다음과 같은 요소를 포함해야 합니다:

  1. 취약점 탐지 및 해결 절차
  2. 지속적인 모니터링 체계
  3. 보안 업데이트 및 패치 관리
  4. 보안 위험 평가 및 관리
  5. 보안 인식 제고 및 교육

이러한 요소들을 통합적으로 관리함으로써, 조직은 오픈소스 사용에 따른 보안 위험을 최소화하고 안전한 소프트웨어 개발 환경을 구축할 수 있습니다.

3.3.2.1 취약점 탐지 및 해결 절차

ISO/IEC 18974

  • 4.3.2.1: A documented procedure for handling detection and resolution of known vulnerabilities for the open source software components of the supplied software;
  • 4.3.2.1 공급 소프트웨어의 오픈 소스 소프트웨어 컴포넌트에 대해 알려진 취약점의 탐지 및 해결을 처리하기 위한 문서화된 절차.

Self-Certification Checklist

  • We have a documented procedure for handling detection and resolution of Known Vulnerabilities for the Open Source Software components of the Supplied Software.
  • 오픈소스 소프트웨어 컴포넌트의 알려진 취약점 탐지 및 해결을 위한 문서화된 절차가 있습니다.

효과적인 보안 보증을 위해서는, 오픈소스 컴포넌트에서 발견된 취약점을 체계적으로 탐지하고 해결하기 위한 명확하고 문서화된 절차가 필요합니다. 이 절차는 취약점 탐지, 심각도 평가, 대응 계획 수립, 해결 조치 실행, 그리고 결과 검증 단계를 포함해야 하며, 각 단계별 책임자와 기한을 명확하게 정의해야 합니다.

구현 방법 및 고려사항:

  1. 문서화된 절차:
    • 취약점 탐지 및 해결 절차를 명확하게 문서화합니다.
    • 문서에는 절차의 각 단계, 책임자, 기한, 그리고 필요한 도구 및 시스템 등이 명시되어야 합니다.
    • 문서는 프로그램 참여자들이 쉽게 접근할 수 있도록, 공유 문서 저장소, 위키, 또는 기타 협업 도구에 게시합니다.
  2. 취약점 탐지:
    • SCA (Software Composition Analysis) 도구를 활용하여, SBOM에 포함된 각 오픈소스 컴포넌트의 알려진 취약점을 탐지합니다.
      • 예시: OWASP Dependency-Check, Black Duck
    • 취약점 데이터베이스 (예: NVD, CVE)를 주기적으로 업데이트하고, 새로운 취약점 정보를 확인합니다.
      • NVD (National Vulnerability Database, 미국 국립 취약점 데이터베이스): 미국 NIST(National Institute of Standards and Technology, 미국 국립표준기술연구소)에서 관리하는 취약점 데이터베이스입니다. CVE(Common Vulnerabilities and Exposures) ID를 기준으로 취약점 정보를 제공합니다.
      • CVE (Common Vulnerabilities and Exposures, 공통 취약점 및 노출): MITRE Corporation에서 관리하는 공개적으로 알려진 정보 보안 취약점 목록입니다. 각 취약점에 고유한 ID (CVE ID)를 할당합니다.
    • 자동화된 취약점 스캔을 정기적으로 수행하고, 필요한 경우 수동 검토를 수행합니다.
    • 추천 오픈소스 취약점 스캐닝 도구는 다음과 같습니다. 이러한 도구의 설치, 구성, 사용법에 대한 상세 가이드는 부록에서 제공됩니다.
      • OWASP Dependency-Check: 오픈소스 종속성 취약점 검사
      • Trivy: 컨테이너 이미지 및 파일시스템 취약점 스캐너
  3. 심각도 평가:
    • 탐지된 각 취약점의 심각도를 평가합니다.
    • CVSS (Common Vulnerability Scoring System) 점수를 활용하여 취약점의 심각도를 객관적으로 평가할 수 있습니다.
    • 취약점의 익스플로잇 가능성, 영향 범위, 그리고 시스템에 미치는 잠재적인 영향 등을 고려하여 심각도를 조정합니다.
  4. 대응 계획 수립:
    • 취약점의 심각도에 따라 적절한 대응 계획을 수립합니다.
    • 대응 계획에는 패치 적용, 업그레이드, 완화 조치, 또는 컴포넌트 교체 등이 포함될 수 있습니다.
    • 대응 계획은 기술적인 측면뿐만 아니라, 비즈니스 영향도, 비용, 그리고 시간 제약 등을 고려하여 결정해야 합니다.
  5. 해결 조치 실행:
    • 수립된 대응 계획에 따라, 즉시 필요한 조치를 실행합니다.
    • 패치를 적용하거나, 컴포넌트를 업그레이드하는 경우, 충분한 테스트를 거쳐 시스템에 미치는 영향을 최소화해야 합니다.
    • 완화 조치를 취하는 경우, 장기적인 해결 방안을 마련해야 합니다.
  6. 결과 검증:
    • 해결 조치가 완료된 후에는, 취약점이 실제로 해결되었는지 검증합니다.
    • 취약점 스캐너를 다시 실행하여, 취약점이 더 이상 탐지되지 않는지 확인합니다.
    • 수동 검토를 통해, 자동화된 도구에서 발견하지 못한 취약점을 추가적으로 확인합니다.
  7. 문서화 및 보고:
    • 취약점 탐지, 심각도 평가, 대응 계획 수립, 해결 조치 실행, 그리고 결과 검증 등 각 단계별 활동 내역을 문서화합니다.
    • 문서에는 취약점 정보, 담당자, 실행 일시, 그리고 결과 등이 기록되어야 합니다.
    • 취약점 관리 현황을 정기적으로 보고하고, 필요한 경우 경영진에 보고합니다.

구현 시 고려사항:

  • 취약점 탐지 및 해결 절차는 조직의 규모, 소프트웨어 개발 프로세스, 그리고 보안 정책 등을 고려하여 맞춤화되어야 합니다.
  • 자동화된 도구를 적극적으로 활용하여 효율성을 높여야 합니다.
  • 보안 전문가, 개발자, 그리고 운영자 간의 긴밀한 협력이 필요합니다.

3.3.2.2 취약점 기록 유지

ISO/IEC 18974

  • 4.3.2.2: For each open source software component a record is maintained of the identified known vulnerabilities and action(s) taken (including even if no action was required).
  • 4.3.2.2 각 오픈소스 소프트웨어 컴포넌트에 대해 식별된 알려진 취약점 및 취해진 조치(조치가 필요하지 않은 경우도 포함)에 대한 기록이 유지 관리되어야 함.

Self-Certification Checklist

  • We have open source component records for the Supplied Software which track identified Known Vulnerabilities and action(s) taken (including even if no action was required).
  • 공급 소프트웨어에 대한 오픈소스 컴포넌트 기록이 식별된 알려진 취약점과 취해진 조치(조치가 필요하지 않은 경우도 포함)를 추적합니다.

각 오픈소스 컴포넌트에 대해 식별된 알려진 취약점과, 그에 대해 취해진 조치를 기록하는 것은, 효과적인 취약점 관리를 위한 핵심적인 요소입니다. 이러한 기록은 과거의 취약점 발생 이력을 추적하고, 유사한 문제가 발생했을 때 신속하게 대응할 수 있도록 돕습니다. 또한, 감사 및 보고 목적으로도 활용될 수 있습니다.

구현 방법 및 고려사항:

  1. 취약점 데이터베이스 구축:
    • 식별된 모든 취약점을 체계적으로 관리할 수 있는 데이터베이스를 구축합니다.
    • 데이터베이스는 다음과 같은 정보를 포함해야 합니다.
      • 컴포넌트 이름 및 버전
      • 취약점 ID (예: CVE)
      • 취약점 설명
      • 심각도 (예: CVSS 점수)
      • 발견 일시
      • 대응 상태 (예: 해결됨, 보류 중, 무시됨)
      • 대응 조치 내역
      • 관련 담당자
  2. 자동화된 도구 활용:
    • SCA (Software Composition Analysis) 도구와 연동하여 취약점 정보를 자동으로 수집하고, 데이터베이스에 저장합니다.
    • 취약점 데이터베이스를 주기적으로 업데이트하고, 새로운 취약점 정보를 반영합니다.
  3. 수동 검토 및 업데이트:
    • 자동화된 도구에서 탐지하지 못한 취약점은 수동으로 검토하고, 데이터베이스에 추가합니다.
    • 취약점에 대한 대응 조치가 완료되면, 데이터베이스를 업데이트하고, 관련 정보를 기록합니다.
  4. 정기적인 보고서 생성:
    • 취약점 데이터베이스를 기반으로 정기적인 보고서를 생성합니다.
    • 보고서에는 다음과 같은 정보가 포함될 수 있습니다.
      • 전체 취약점 수
      • 심각도별 취약점 분포
      • 미해결 취약점 목록
      • 취약점 해결 추이
  5. 데이터 보안 및 접근 제어:
    • 취약점 데이터베이스는 민감한 정보를 포함하고 있으므로, 데이터 보안에 각별히 유의해야 합니다.
    • 접근 권한을 적절하게 관리하고, 필요한 사람에게만 접근 권한을 부여합니다.

구체적인 예시:

  • 취약점 추적 시스템: Jira, Bugzilla, 또는 YouTrack과 같은 이슈 추적 시스템을 활용하여 취약점 정보를 관리합니다.
  • 스프레드시트: 간단한 프로젝트의 경우, 엑셀 또는 구글 시트와 같은 스프레드시트를 활용하여 취약점 정보를 관리할 수 있습니다.
  • 보안 대시보드: 취약점 데이터베이스와 연동된 보안 대시보드를 구축하여, 취약점 현황을 실시간으로 모니터링합니다.

구현 시 고려사항:

  • 취약점 데이터베이스는 최신 정보를 유지해야 합니다.
  • 취약점 데이터베이스는 안전하게 보관해야 합니다.
  • 취약점 데이터베이스는 접근 권한을 적절하게 관리해야 합니다.
  • 취약점 데이터베이스는 정기적으로 백업해야 합니다.

이러한 접근 방식을 통해 조직은 오픈소스 컴포넌트의 취약점을 체계적으로 관리하고, 소프트웨어의 보안 수준을 높일 수 있습니다.

2.3.4 - 3.4 Adherence to the specification requirements

조직이 오픈소스 보안 보증 프로그램을 운영하고 있다고 주장하기 위해서는, 해당 프로그램이 ISO/IEC 18974 표준의 모든 요구사항을 준수해야 합니다. 이 단원에서는 조직이 표준 준수를 어떻게 확인하고, 유지할 수 있는지에 대한 지침을 제공합니다.

4.4.1 Completeness (완전성)

프로그램이 ISO/IEC 18974 표준을 준수한다고 선언하기 위해서는, 조직은 프로그램이 표준에 제시된 모든 요구사항을 충족한다는 것을 공식적으로 확인해야 합니다. 일부 요구사항만 충족하는 것으로는 충분하지 않습니다.

4.4.1.1 요구사항 충족 증거

ISO/IEC 18974

  • 4.4.1.1: Documented evidence affirming the program specified in 4.1.4 satisfies all the requirements of this document.
  • 4.4.1.1: 4.1.4에 명시된 프로그램이 이 문서의 모든 요구 사항을 충족함을 확인하는 문서화된 증거

Self-Certification Checklist

  • We have documentation confirming that the Program meets all the requirements of this specification.
  • 프로그램이 이 표준의 모든 요구사항을 충족한다는 문서화된 확인이 있습니다.

조직은 프로그램이 ISO/IEC 18974 표준의 모든 요구사항을 충족한다는 것을 입증하는 문서화된 증거를 제시해야 합니다. 이 증거는 프로그램 운영의 모든 측면을 포괄해야 하며, 객관적이고 신뢰할 수 있어야 합니다.

구현 방법 및 고려사항:

  1. 요구사항 매핑:
    • ISO/IEC 18974 표준의 각 요구사항을 조직의 프로그램의 특정 정책, 절차, 또는 활동에 매핑합니다.
    • 매핑 결과는 문서화하고, 프로그램 참여자들이 쉽게 접근할 수 있도록 합니다.
  2. 준수 증거 수집:
    • 각 요구사항에 대한 준수 여부를 입증하는 증거를 수집합니다.
    • 증거는 문서, 기록, 로그, 그리고 테스트 결과 등 다양한 형태가 될 수 있습니다.
    • 증거는 객관적이고 신뢰할 수 있어야 하며, 최신 정보를 반영해야 합니다.
  3. 내부 감사:
    • 독립적인 감사팀이 프로그램의 운영 실태를 평가하고, ISO/IEC 18974 표준 준수 여부를 확인합니다.
    • 감사 결과는 문서화하고, 경영진에게 보고합니다.
    • 감사 결과에 따라 필요한 시정 조치를 취합니다.
  4. 경영진 검토:
    • 경영진은 프로그램의 운영 현황과 감사 결과를 검토하고, ISO/IEC 18974 표준 준수 여부를 최종적으로 확인합니다.
    • 경영진은 프로그램의 지속적인 개선을 위한 지침을 제공합니다.

예시 증거 자료:

  • 정책 문서:
    • 오픈소스 정책, 보안 정책, 그리고 라이선스 관리 정책 등
  • 절차 문서:
    • 취약점 관리 절차, 사고 대응 절차, 그리고 SBOM 관리 절차 등
  • 기록:
    • 취약점 스캔 결과, 코드 리뷰 결과, 그리고 보안 테스트 결과 등
  • 로그:
    • 시스템 접근 로그, 변경 로그, 그리고 감사 로그 등
  • 테스트 결과:
    • 기능 테스트 결과, 보안 테스트 결과, 그리고 성능 테스트 결과 등

구현 시 고려사항:

  • 증거는 객관적이고 신뢰할 수 있어야 합니다.
  • 증거는 최신 정보를 반영해야 합니다.
  • 증거는 체계적으로 관리하고, 접근 권한을 적절하게 제어해야 합니다.

이러한 접근 방식을 통해 조직은 프로그램이 ISO/IEC 18974 표준의 모든 요구사항을 충족한다는 것을 입증하고, 대외적으로 신뢰를 확보할 수 있습니다.

4.4.2 Duration (기간)

ISO/IEC 18974

  • 4.4.2.1: A document affirming the program meets all the requirements of this specification, within the past 18 months of obtaining conformance validation.
  • 4.4.2.1: 프로그램이 적합성 검증을 획득한 후 지난 18개월 이내에 이 규격의 모든 요구 사항을 충족함을 확인하는 문서.

Self-Certification Checklist

  • We have documentation confirming that Program conformance was reviewed within the last 18 months.
  • 프로그램의 준수 여부가 최근 18개월 내에 검토된 기록이 있습니다.

ISO/IEC 18974 표준 준수는 일회성 이벤트가 아니라, 지속적인 과정입니다. 따라서, 조직은 표준 준수를 획득한 후에도, 해당 상태를 유지하기 위해 지속적으로 노력해야 합니다. 이 섹션에서는 표준 준수 기간과 관련된 요구사항을 설명합니다.

4.4.2.1 준수 기간 확인 문서

ISO/IEC 18974 표준을 준수하는 프로그램은 준수 검증을 받은 날로부터 18개월 동안 유효합니다. 따라서, 조직은 프로그램이 준수 검증을 받은 후 18개월 이내에, 해당 프로그램이 여전히 표준의 모든 요구사항을 충족한다는 것을 확인하는 문서를 제시해야 합니다. 이는 프로그램이 시간이 지남에 따라 표준에서 벗어나지 않고, 지속적으로 개선되고 있다는 것을 입증하는 데 중요합니다.

구현 방법 및 고려사항:

  1. 준수 검증 일자 기록:
    • 프로그램이 ISO/IEC 18974 표준 준수 검증을 받은 날짜를 정확하게 기록합니다.
    • 준수 검증 인증서 또는 관련 문서 등을 증거 자료로 보관합니다.
  2. 준수 갱신 계획 수립:
    • 준수 기간 만료 전에, 준수 상태를 재검증하고, 필요한 경우 갱신하기 위한 계획을 수립합니다.
    • 계획에는 준수 상태 자체 평가, 내부 감사, 그리고 외부 심사 등의 활동이 포함될 수 있습니다.
  3. 정기적인 준수 상태 검토:
    • 준수 기간 동안 프로그램이 여전히 ISO/IEC 18974 표준의 모든 요구사항을 충족하는지 정기적으로 검토합니다.
    • 검토는 최소 6개월에 1회 이상 수행하고, 검토 결과를 문서화합니다.
    • 검토 결과, 표준을 준수하지 않는 부분이 발견되면, 즉시 시정 조치를 취합니다.
  4. 갱신 전 전체 요구사항 재검토:
    • 준수 기간 만료 전에, 프로그램이 ISO/IEC 18974 표준의 모든 요구사항을 다시 한번 충족하는지 전체적으로 재검토합니다.
    • 재검토는 독립적인 감사팀 또는 외부 전문가에 의해 수행될 수 있습니다.
    • 재검토 결과는 문서화하고, 경영진에게 보고합니다.

예시 증거 자료:

  • 준수 검증 인증서: ISO/IEC 18974 표준 준수 검증을 받았음을 증명하는 공식 문서.
  • 준수 갱신 계획: 준수 상태를 유지하고 갱신하기 위한 구체적인 계획을 기술한 문서.
  • 정기 검토 보고서: 준수 상태를 정기적으로 검토한 결과를 기록한 보고서.
  • 전체 요구사항 재검토 보고서: 준수 갱신 전에 프로그램이 표준의 모든 요구사항을 충족하는지 재검토한 결과를 기록한 보고서.

구현 시 고려사항:

  • 준수 상태 유지는 지속적인 노력과 자원 투입이 필요합니다.
  • 조직은 ISO/IEC 18974 표준의 변경 사항을 주시하고, 프로그램에 필요한 조정을 수행해야 합니다.
  • 프로그램 참여자들에게 표준 준수의 중요성을 강조하고, 책임을 부여해야 합니다.

이러한 접근 방식을 통해 조직은 ISO/IEC 18974 표준 준수 상태를 지속적으로 유지하고, 고객에게 안전하고 신뢰할 수 있는 오픈소스 소프트웨어를 제공할 수 있습니다.

2.4 - 4. ISO/IEC 5230과의 비교 및 통합

이 단원에서는 오픈소스 컴플라이언스 관리를 위한 ISO/IEC 5230과 오픈소스 보안 보증을 위한 ISO/IEC 18974를 비교 분석하고, 두 표준을 통합하여 보다 효과적인 오픈소스 관리 체계를 구축하는 방안을 제시합니다.

4.1 공통점과 차이점

ISO/IEC 5230과 ISO/IEC 18974는 모두 오픈소스 관리를 위한 국제 표준이지만, 주요 목표, 적용 범위, 핵심 요구사항 등에서 차이가 있습니다. 두 표준을 이해하고, 조직의 상황에 맞게 적용하는 것이 중요합니다.

표 4.1: ISO/IEC 5230과 ISO/IEC 18974의 주요 공통점

공통점설명
오픈소스 관리를 위한 국제 표준두 표준 모두 오픈소스 소프트웨어의 효과적인 관리를 목표로 합니다.
Linux Foundation의 OpenChain 프로젝트 기반두 표준 모두 OpenChain 프로젝트의 결과물을 기반으로 개발되었습니다.
조직의 오픈소스 프로세스 개선두 표준 모두 조직이 오픈소스 관리 프로세스를 개선하고 성숙도를 높이는 데 기여합니다.
자체 인증 옵션 제공두 표준 모두 조직이 자체 평가를 통해 표준 준수 여부를 확인할 수 있습니다.
지속적인 개선 강조두 표준 모두 오픈소스 관리 프로세스의 지속적인 개선을 장려합니다.

표 4.2: ISO/IEC 5230과 ISO/IEC 18974의 주요 차이점

구분ISO/IEC 5230ISO/IEC 18974
주요 초점오픈소스 라이선스 준수오픈소스 보안 보증
적용 범위라이선스 의무, 고지 사항, 저작권 표시, 소스 코드 공개 의무 등취약점 관리, SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) 관리, 패치 관리, 보안 검토 등
주요 대상법무팀, 컴플라이언스 담당자, 라이선스 관리자보안팀, 개발팀, OSPO(Open Source Program Office, 오픈소스 프로그램 오피스)
핵심 요구사항- 라이선스 식별 및 분석
- 라이선스 의무 준수
- 고지 의무 이행
- 저작권 표시
- 취약점 식별 및 평가
- 취약점 대응 계획 수립 및 실행
- 보안 정책 수립 및 준수
- SBOM 관리
관리 대상오픈소스 라이선스, 저작권, 특허오픈소스 컴포넌트의 보안 취약점, 악성코드, 오래된 종속성
주요 활동- 라이선스 검토 및 분석
- 라이선스 의무 준수 확인
- 고지 의무 이행
- 법적 위험 관리
- 취약점 스캔 및 분석
- 보안 업데이트 및 패치 적용
- 침해 사고 대응
- 오픈소스 보안 감사
목표법적 책임 감소, 라이선스 분쟁 예방, 컴플라이언스 유지보안 리스크 감소, 소프트웨어 신뢰성 향상, 안전한 소프트웨어 개발
관리 도구- 라이선스 검사 도구 (예: FOSSology, ScanCode)
- 컴플라이언스 관리 시스템
- 취약점 스캐너 (예: OWASP Dependency-Check, Snyk)
- SBOM 관리 도구 (예: SPDX Tools, CycloneDX)
- 보안 정보 및 이벤트 관리 (SIEM) 시스템
라이선스 준수 보장 방법- 오픈소스 라이선스 검토 프로세스 구축
- 오픈소스 사용 가이드라인 제공
- 라이선스 의무 준수 교육
- 라이선스 위반 시 해결 절차 마련
해당 사항 없음
보안 취약점 관리 방법해당 사항 없음- 취약점 스캐닝 도구 활용
- 취약점 평가 및 우선순위 지정
- 패치 적용 또는 완화 조치 실행
- 취약점 관리 프로세스 정기 검토

ISO/IEC 5230은 라이선스 준수를 어떻게 보장하는가?

ISO/IEC 5230은 오픈소스 라이선스 준수를 보장하기 위해 다음 사항을 요구합니다.

  • 라이선스 식별 프로세스: 조직은 사용하는 모든 오픈소스 컴포넌트의 라이선스를 정확하게 식별해야 합니다. 이를 위해 라이선스 식별 도구를 활용하거나, 수동으로 코드를 검토할 수 있습니다.
  • 라이선스 의무 준수: 조직은 식별된 라이선스의 모든 의무 사항을 준수해야 합니다. 예를 들어, GPL(GNU General Public License) 라이선스를 사용하는 경우, 소스 코드를 공개해야 할 수 있습니다.
  • 고지 의무 이행: 조직은 오픈소스 컴포넌트의 라이선스 정보를 사용자에게 고지해야 합니다. 이는 소프트웨어 제품 내에 고지 문구를 포함하거나, 별도의 라이선스 파일을 제공하는 방식으로 이루어질 수 있습니다.

ISO/IEC 18974는 보안 취약점을 어떻게 관리하는가?

ISO/IEC 18974는 오픈소스 보안 취약점을 관리하기 위해 다음 사항을 요구합니다.

  • 취약점 스캐닝 도구 활용: 조직은 자동화된 취약점 스캐닝 도구를 활용하여 오픈소스 컴포넌트의 알려진 취약점을 주기적으로 검사해야 합니다.
  • 취약점 평가 및 우선순위 지정: 발견된 취약점에 대해 심각도, 영향도, 악용 가능성 등을 평가하고, 대응 우선순위를 결정해야 합니다.
  • 패치 적용 또는 완화 조치 실행: 우선순위에 따라 취약점에 대한 패치를 적용하거나, 완화 조치 (예: 방화벽 설정 변경, 코드 수정)를 실행해야 합니다.
  • 취약점 관리 프로세스 정기 검토: 취약점 관리 프로세스의 효과성을 정기적으로 검토하고, 필요한 경우 개선해야 합니다.

4.2 두 표준의 상호 보완적 관계

ISO/IEC 5230 (오픈소스 라이선스 준수)과 ISO/IEC 18974 (오픈소스 보안 보증)는 독립적인 표준이지만, 조직이 함께 구현할 경우 오픈소스 관리의 시너지 효과를 창출할 수 있습니다. 각 표준이 다루는 영역을 이해하고, 상호 보완적인 관계를 활용하여 보다 강력한 오픈소스 관리 체계를 구축할 수 있습니다.

  1. 통합적 오픈소스 관리 체계 구축
    • 법적 리스크 관리 (ISO/IEC 5230): 오픈소스 라이선스 준수를 통해 저작권 침해, 특허 침해 등 법적 분쟁 발생 가능성을 줄입니다.
    • 보안 리스크 관리 (ISO/IEC 18974): 오픈소스 컴포넌트의 취약점과 악성코드 감염 위험을 관리하여 보안 사고 발생 가능성을 줄입니다.
    • 통합 관리: 법적 리스크와 보안 리스크를 개별적으로 관리하는 대신, 통합된 체계를 구축하여 효율성을 높입니다.
  2. 프로세스 시너지 효과
    • SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) 활용: SBOM을 활용하여 라이선스 정보와 보안 취약점 정보를 통합 관리할 수 있습니다. SBOM에 라이선스 정보와 취약점 정보를 함께 기록하면, 각 컴포넌트의 법적 및 보안적 위험을 동시에 파악할 수 있습니다.
    • 문서화 및 교육 프로그램 통합: 오픈소스 정책, 라이선스 준수 절차, 보안 가이드라인 등을 하나의 문서로 통합하고, 교육 프로그램을 공동으로 운영하여 효율성을 높일 수 있습니다.
  3. 조직 구조 최적화
    • OSPO(Open Source Program Office, 오픈소스 프로그램 오피스) 활용: OSPO를 통해 두 표준의 요구사항을 통합 관리할 수 있습니다. OSPO는 오픈소스 관련 정책 수립, 프로세스 관리, 도구 도입 등을 총괄하며, 법무팀과 보안팀의 협력을 촉진합니다.
    • 법무팀과 보안팀의 협력 강화: 법무팀은 오픈소스 라이선스 관련 법적 위험을 평가하고, 보안팀은 오픈소스 컴포넌트의 보안 취약점을 분석합니다. 두 팀이 협력하여 오픈소스 사용에 대한 종합적인 위험 평가를 수행하고, 적절한 대응 방안을 마련합니다.
  4. 공급망 관리 강화
    • 공급업체 평가 시 두 표준 동시 고려: 소프트웨어를 공급받을 때 공급업체의 오픈소스 관리 체계를 평가하는 기준으로 ISO/IEC 5230과 ISO/IEC 18974를 모두 활용합니다. 이를 통해 공급망 전체의 오픈소스 관리 수준을 높일 수 있습니다.
    • 계약 조건 명시: 공급 계약서에 오픈소스 라이선스 준수 및 보안 관련 요구사항을 명시하고, 공급업체가 이를 준수하도록 요구합니다.

표 4.3: ISO/IEC 5230과 ISO/IEC 18974의 상호 보완적 관계

영역ISO/IEC 5230 (라이선스 준수)ISO/IEC 18974 (보안 보증)시너지 효과
위험 관리법적 리스크 관리보안 리스크 관리법적 & 보안 리스크 통합 관리
정보 관리라이선스 정보취약점 정보SBOM을 통한 통합 정보 관리
조직 구조법무팀 주도보안팀 주도OSPO를 통한 협업 강화
공급망 관리라이선스 준수 계약보안 요구사항 계약공급망 전체의 관리 수준 향상

4.3 통합 구현 전략

ISO/IEC 5230(오픈소스 라이선스 준수)과 ISO/IEC 18974(오픈소스 보안 보증)는 각각 다른 측면을 다루지만, 조직은 두 표준을 통합적으로 구현하여 시너지 효과를 창출할 수 있습니다. 이 섹션에서는 두 표준을 효과적으로 통합하기 위한 구체적인 전략과 실행 방안을 제시합니다.

  1. 단계별 접근 방식 채택
    • ISO/IEC 5230 우선 구현: 먼저 ISO/IEC 5230을 구현하여 기본적인 라이선스 준수 체계를 구축합니다. 이는 오픈소스 사용에 대한 법적 리스크를 줄이고, 조직 내 컴플라이언스 문화를 정착시키는 데 도움이 됩니다.
    • ISO/IEC 18974 추가 구현: ISO/IEC 5230 구현 후 ISO/IEC 18974를 도입하여 보안 관리 체계를 강화합니다. 이는 오픈소스 컴포넌트의 취약점을 효과적으로 관리하고, 소프트웨어 공급망의 보안을 강화하는 데 기여합니다.
    • 통합 로드맵 수립: 두 표준을 동시에 고려하여 통합 로드맵을 수립하고 병렬적으로 구현할 수도 있습니다. 이 경우, 초기 단계부터 법적 및 보안적 측면을 모두 고려하여 균형 잡힌 오픈소스 관리 체계를 구축할 수 있습니다.
  2. 공통 요소 활용
    • 정책 및 프로세스 통합: 오픈소스 사용 정책, SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) 관리 프로세스, 교육 프로그램 등 두 표준에서 공통적으로 요구하는 요소를 통합하여 관리합니다. 이는 중복 작업을 줄이고, 관리 효율성을 높이는 데 도움이 됩니다.
    • 도구 통합: 라이선스 검사 도구와 취약점 스캐닝 도구를 통합하거나, SBOM 데이터를 공유할 수 있는 도구를 활용하여 정보 공유를 용이하게 합니다.
  3. 조직 구조 및 역할 통합
    • OSPO(Open Source Program Office, 오픈소스 프로그램 오피스) 활용: OSPO를 중심으로 오픈소스 관련 활동을 통합 관리합니다. OSPO는 법무, 보안, 개발 등 다양한 부서의 전문가로 구성되어, 오픈소스 사용에 대한 종합적인 의사 결정을 지원합니다.
    • 책임 및 권한 명확화: 각 역할 (예: 법무팀, 보안팀, 개발팀)의 책임과 권한을 명확히 정의하고, 협업 체계를 구축합니다.
  4. 지속적인 협력 및 정보 공유
    • 정기적인 회의: 법무팀, 보안팀, 개발팀 간의 정기적인 회의를 통해 오픈소스 관련 최신 정보, 위협 동향, 문제점 등을 공유합니다.
    • 정보 공유 플랫폼: 오픈소스 관련 정보를 공유하고 토론할 수 있는 플랫폼 (예: 사내 위키, 협업 도구)을 구축합니다.
    • 교육 및 훈련: 오픈소스 라이선스 및 보안 관련 교육 프로그램을 공동으로 개발하고, 전 직원을 대상으로 교육을 실시합니다.

표 4.4: ISO/IEC 5230 및 ISO/IEC 18974 통합 구현 전략

전략설명실행 방안
단계별 접근 방식ISO/IEC 5230 먼저 구현 후 ISO/IEC 18974 구현1단계: ISO/IEC 5230 요구사항 충족
2단계: ISO/IEC 18974 요구사항 추가
공통 요소 활용정책, 프로세스, 도구 공유SBOM 생성 프로세스 통합, 교육 프로그램 통합
조직 구조 통합OSPO 중심으로 관리법무, 보안, 개발 전문가로 OSPO 구성
지속적인 협력 및 정보 공유정기적인 회의, 정보 공유 플랫폼 구축팀 간 협업 강화, 정보 접근성 향상

2.5 - 5. 조직 특성별 구현 고려사항

ISO/IEC 18974 표준을 효과적으로 구현하기 위해서는 조직의 특성을 고려한 맞춤형 접근이 필요합니다. 이 섹션에서는 대기업, 중소기업, 스타트업별 접근 방식과 기존 보안 프로세스와의 통합, 그리고 교육 및 인식 제고 프로그램에 대해 상세히 설명합니다.

5.1 대기업, 중소기업, 스타트업별 접근 방식

5.1.1 대기업

대기업은 복잡한 조직 구조, 다양한 프로젝트, 그리고 넓은 범위의 기술 스택을 관리해야 하므로 체계적이고 포괄적인 접근 방식이 필수적입니다. 또한, 법적/규제적 요구사항 준수, 공급망 관리, 그리고 브랜드 평판 보호에도 더욱 신경 써야 합니다.

  • 전담 오픈소스 프로그램 오피스(OSPO, Open Source Program Office) 설립: OSPO는 조직 전체의 오픈소스 전략을 수립하고 관리하는 중앙 조직으로 기능합니다. OSPO는 다음 역할을 수행하며, 이는 일관된 정책과 프로세스를 보장하는 데 중요합니다.

    • 오픈소스 정책 수립 및 관리: 조직 전체의 오픈소스 사용 및 기여에 대한 정책을 수립하고 관리합니다. 정책은 법적 요구사항, 보안 가이드라인, 그리고 조직의 비즈니스 목표를 반영해야 합니다.
    • 오픈소스 컴플라이언스 관리: 오픈소스 라이선스 준수 여부를 확인하고, 관련 문제를 해결합니다.
    • 보안 취약점 관리: 오픈소스 컴포넌트의 취약점을 식별하고, 평가, 그리고 패치하는 프로세스를 관리합니다.
    • 오픈소스 커뮤니티 참여: 오픈소스 프로젝트에 기여하고, 커뮤니티와의 관계를 구축합니다.

    성공 사례: Google, Microsoft, Facebook 등 대규모 기술 기업은 OSPO를 통해 오픈소스 전략을 체계적으로 관리하고 있습니다. 이들 기업은 OSPO를 통해 오픈소스 사용을 장려하고, 커뮤니티에 기여하며, 동시에 법적/보안적 위험을 관리하고 있습니다.

  • 부서별 오픈소스 담당자 지정: 각 부서 또는 프로젝트 팀에 오픈소스 담당자를 지정하여 OSPO와의 원활한 소통을 보장합니다. 담당자는 OSPO에서 제공하는 가이드라인을 준수하고, 부서 내 오픈소스 사용 현황을 파악하여 보고하는 역할을 수행합니다.

  • 고도화된 도구 및 프로세스 도입: 대규모 코드베이스와 복잡한 의존성을 관리하기 위해 고급 SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) 생성 도구와 취약점 스캐닝 솔루션을 도입합니다.

    • 예시: WhiteSource, Black Duck, Snyk 등 상용 도구를 활용하여 자동화된 오픈소스 관리를 구현합니다. 이러한 도구들은 대규모 코드베이스를 빠르게 스캔하고, 정확한 SBOM을 생성하며, 다양한 취약점 정보를 제공합니다.
  • 복잡한 공급망 관리: 다양한 공급업체와 협력 업체의 오픈소스 사용을 추적하고 관리하기 위한 체계적인 프로세스를 구축합니다.

    • 공급업체 계약 시 오픈소스 보안 요구사항을 명시하고, 정기적인 감사를 통해 준수 여부를 확인합니다. 계약 조건에는 SBOM 제공 의무, 취약점 정보 공유, 그리고 보안 사고 발생 시 책임 소재 등이 포함될 수 있습니다.

표 5.1: 대기업을 위한 ISO/IEC 18974 구현 핵심 요소

요소설명예시
OSPO 설립오픈소스 전략 및 관리를 위한 중앙 조직Google, Microsoft, Facebook
부서별 담당자 지정OSPO와 각 부서 간의 소통 채널 확보각 팀에 오픈소스 Champion 지정
고도화된 도구 활용SBOM 생성, 취약점 스캔 자동화WhiteSource, Black Duck, Snyk
공급망 관리공급업체 보안 요구사항 명시계약 조건에 SBOM 제공 의무 포함

5.1.2 중소기업

중소기업은 대기업에 비해 제한된 리소스를 가지고 있으므로 효율적인 구현 전략이 필요합니다. 핵심은 비용 효율적인 솔루션을 선택하고, 기존 팀의 역량을 활용하며, 필요한 경우 외부 전문가의 도움을 받는 것입니다.

  • 기존 팀 내 오픈소스 책임자 지정: 전담 OSPO 대신 기존 개발 또는 보안 팀 내에 오픈소스 보안 책임자를 지정합니다. 책임자는 오픈소스 정책 준수, SBOM 관리, 취약점 점검 등의 역할을 수행합니다.
  • 클라우드 기반 오픈소스 관리 도구 활용: 초기 투자 비용을 줄이고 유연성을 확보하기 위해 클라우드 기반 솔루션을 고려합니다.
    • 예시: GitHub, GitLab 등의 클라우드 기반 협업 플랫폼에서 제공하는 오픈소스 관리 기능을 활용합니다. 이러한 플랫폼은 소스 코드 관리, 협업, 빌드 자동화, 그리고 기본적인 보안 검사 기능을 제공합니다.
  • 외부 전문가 자문 고려: 필요에 따라 외부 컨설턴트나 전문가의 조언을 받아 효율적인 구현을 도모합니다.
    • 오픈소스 보안 전문 컨설팅 업체를 활용하여 단기적인 기술 지원 및 교육을 받습니다. 외부 전문가들은 SBOM 생성, 취약점 스캐닝, 라이선스 준수 등에 대한 전문적인 지식을 제공할 수 있습니다.
  • 비용 효율적인 솔루션 선택: 오픈소스 도구나 저비용 상용 솔루션을 활용하여 비용을 최적화합니다.
    • 예시: OWASP Dependency-Check, Snyk Open Source 등의 무료 또는 저렴한 도구를 활용합니다. 이러한 도구들은 기본적인 SBOM 생성 및 취약점 스캐닝 기능을 제공하며, 중소기업의 예산으로도 충분히 활용할 수 있습니다.

표 5.2: 중소기업을 위한 ISO/IEC 18974 구현 핵심 요소

요소설명예시
기존 팀 활용전담 조직 대신 기존 인력 활용개발팀 또는 보안팀에 책임자 지정
클라우드 기반 도구초기 비용 절감 및 유연성 확보GitHub, GitLab 오픈소스 관리 기능
외부 전문가 자문필요시 단기 기술 지원 및 교육컨설팅 업체를 활용한 SBOM 구축
비용 효율적 솔루션무료 또는 저렴한 도구 활용OWASP Dependency-Check, Snyk Open Source

5.1.3 스타트업

스타트업은 빠른 성장과 변화에 대응할 수 있는 유연한 접근 방식이 필요합니다. 핵심은 개발 프로세스에 보안을 통합하고, 자동화 도구를 적극 활용하며, 빠른 의사 결정을 통해 효율성을 높이는 것입니다.

  • 애자일 방식의 간소화된 프로세스 적용: 복잡한 프로세스 대신 핵심 요구사항에 집중한 간소화된 접근 방식을 채택합니다.
    • 오픈소스 사용 승인 절차를 간소화하고, 개발자가 자율적으로 오픈소스를 선택할 수 있도록 합니다. 다만, 중요한 보안 또는 라이선스 관련 사항은 반드시 검토하도록 합니다.
  • 오픈소스 보안 관리를 개발 프로세스에 통합: 별도의 프로세스가 아닌 기존 개발 워크플로우에 보안 검사를 통합합니다 (DevSecOps).
    • CI/CD 파이프라인에 SBOM 생성 및 취약점 스캐닝 단계를 추가합니다. 이를 통해 개발 과정에서 자동으로 보안 취약점을 검사하고, 코드 배포 전에 문제를 해결할 수 있습니다.
  • 자동화 도구 적극 활용: 제한된 인력으로 효율적인 관리를 위해 자동화 도구를 최대한 활용합니다.
    • 예시: GitHub Actions, GitLab CI 등의 자동화 도구를 활용하여 SBOM 생성 및 취약점 스캔을 자동화합니다. 이러한 도구들은 설정이 비교적 간단하고, 개발 워크플로우에 쉽게 통합할 수 있습니다.
  • 빠른 의사 결정 및 실행: 유연한 조직 구조를 활용하여 신속한 의사 결정과 정책 구현을 추진합니다.
    • 오픈소스 관련 의사 결정은 개발팀 리더 또는 CTO(Chief Technology Officer, 최고 기술 책임자)가 담당하여 신속하게 결정합니다. 의사 결정 과정에서 법무팀 또는 보안팀의 자문을 구할 수 있지만, 의사 결정 속도를 늦추지 않도록 합니다.

표 5.2: 스타트업을 위한 ISO/IEC 18974 구현 핵심 요소

요소설명예시
애자일 프로세스핵심 요구사항 집중, 빠른 의사 결정간소화된 사용 승인 절차
DevSecOps개발 워크플로우에 보안 통합CI/CD 파이프라인에 보안 검사 추가
자동화 도구제한된 인력으로 효율적인 관리GitHub Actions, GitLab CI
빠른 의사 결정유연한 조직 구조 활용개발팀 리더 또는 CTO 책임

성공 사례:

  • Netflix: 넷플릭스는 “Security Monkey"라는 오픈소스 도구를 개발하여 클라우드 환경의 보안을 자동화했습니다. 이는 개발자가 보안을 더 쉽게 고려하도록 장려하고, 보안 팀의 부담을 줄이는 데 기여했습니다.
  • Spotify: 스포티파이는 지속적인 배포 파이프라인에 보안 검사를 통합하여 개발 속도를 유지하면서도 보안을 강화하는 데 성공했습니다.

주요 고려 사항:

  • 위험 기반 접근 방식: 모든 오픈소스 컴포넌트에 동일한 수준의 보안 관리를 적용하는 대신, 위험도가 높은 컴포넌트에 우선순위를 두는 것이 좋습니다.
  • 지속적인 학습: 오픈소스 보안 위협은 끊임없이 변화하므로, 최신 동향을 지속적으로 학습하고, 보안 관행을 업데이트해야 합니다.
  • 커뮤니티 참여: 오픈소스 커뮤니티에 참여하고, 다른 조직과 협력하여 오픈소스 보안을 강화하는 데 기여하는 것도 좋은 방법입니다.

5.2 기존 보안 프로세스와의 통합

ISO/IEC 18974를 성공적으로 구현하기 위해서는 기존 보안 프로세스와의 원활한 통합이 필수적입니다. 오픈소스 보안 관리를 기존 보안 체계에 통합함으로써 중복 투자를 줄이고, 효율성을 높이며, 일관된 보안 관리를 실현할 수 있습니다.

  1. 현행 보안 정책 분석

    • 기존 정책 검토: 조직의 정보 보안 정책, 개인정보보호 정책, 위험 관리 정책 등 기존 보안 정책을 검토하여 ISO/IEC 18974 요구사항과 관련된 부분을 식별합니다.
    • 갭 분석 수행: 기존 정책과 ISO/IEC 18974 요구사항 간의 차이점을 분석하고, 보완해야 할 부분을 파악합니다.
    • 정책 통합: 기존 정책에 오픈소스 보안 관련 조항을 추가하거나, 별도의 오픈소스 보안 정책을 신설하여 기존 정책과 통합합니다.

    예시:

    • 기존 정보 보안 정책에 “오픈소스 소프트웨어 사용 시 보안 검토 절차를 준수해야 한다"는 조항을 추가합니다.
    • 개인정보보호 정책에 “개인정보를 처리하는 오픈소스 컴포넌트 사용 시 암호화 및 접근 제어 조치를 강화해야 한다"는 조항을 추가합니다.
  2. DevSecOps 프레임워크 활용

    • CI/CD 파이프라인 통합: 오픈소스 보안 관리를 CI/CD(Continuous Integration/Continuous Delivery, 지속적인 통합/지속적인 제공) 파이프라인에 통합하여 개발 초기 단계부터 보안을 고려하는 DevSecOps 환경을 구축합니다.
    • 자동화된 보안 검사: CI/CD 파이프라인에 SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) 생성, 라이선스 검사, 취약점 스캔 등의 단계를 자동화합니다.
    • 피드백 루프: 보안 검사 결과를 개발팀에 신속하게 피드백하여 수정할 수 있도록 지원합니다.

    예시:

    • Jenkins, GitLab CI, CircleCI 등 CI/CD 도구를 활용하여 SBOM 생성 및 취약점 스캐닝 단계를 자동화합니다.
    • SonarQube, Veracode 등 SAST(Static Application Security Testing, 정적 분석) 도구를 CI/CD 파이프라인에 통합하여 코드 품질 및 보안 취약점을 검사합니다.
  3. 위험 관리 프로세스 연계

    • 위험 식별: 오픈소스 사용으로 인한 위험 (예: 취약점 악용, 라이선스 위반)을 식별하고, 위험 관리 대장에 기록합니다.
    • 위험 평가: 식별된 위험의 심각도, 발생 가능성, 그리고 비즈니스에 미치는 영향 등을 평가합니다.
    • 위험 대응: 평가된 위험에 따라 적절한 대응 방안 (예: 패치 적용, 완화 조치, 사용 중단)을 마련하고 실행합니다.
    • 위험 모니터링: 위험 관리 계획의 효과성을 지속적으로 모니터링하고, 필요한 경우 계획을 수정합니다.

    예시:

    • 위험 관리 대장에 “Log4Shell과 같은 심각한 취약점을 가진 오픈소스 컴포넌트 사용"이라는 위험 항목을 추가합니다.
    • 해당 위험에 대한 발생 가능성을 “중간”, 심각도를 “높음"으로 평가하고, “취약점 발견 시 24시간 이내 패치 적용"이라는 대응 계획을 수립합니다.
  4. 인시던트 대응 계획 업데이트

    • 오픈소스 관련 시나리오 추가: 기존 인시던트 대응 계획에 오픈소스 관련 시나리오(예: 취약점 악용, 라이선스 위반)를 추가합니다.
    • 대응 절차 및 책임자 지정: 각 시나리오별 대응 절차와 책임자를 명확히 정의합니다.
    • 훈련 및 시뮬레이션: 오픈소스 관련 보안 사고 발생 시 대응 능력을 향상시키기 위해 정기적인 훈련 및 시뮬레이션을 실시합니다.
    • 보험 가입 검토: 오픈소스 관련 법적 책임 (예: 저작권 침해 소송)에 대비하기 위해 사이버 공격 보험 가입을 검토합니다.

    예시:

    • 인시던트 대응 계획에 “오픈소스 컴포넌트에서 제로데이 취약점이 발견된 경우"라는 시나리오를 추가하고, 대응 절차 및 책임자를 명확히 정의합니다.
    • 모의 해킹 훈련 시 오픈소스 취약점을 악용하는 시나리오를 포함하여 대응 능력을 점검합니다.

표 5.3: 기존 보안 프로세스와의 통합 방법

통합 영역설명실행 예시
정책오픈소스 관련 조항 추가 또는 별도 정책 신설“오픈소스 소프트웨어 사용 시 보안 검토 절차 준수” 조항 추가
DevSecOpsCI/CD 파이프라인에 보안 검사 통합Jenkins에 OWASP Dependency-Check 플러그인 설치
위험 관리오픈소스 관련 위험을 위험 관리 대장에 기록“Log4Shell과 같은 심각한 취약점” 위험 항목 추가
인시던트 대응오픈소스 관련 시나리오 추가“오픈소스 제로데이 취약점 발견 시” 시나리오 추가

5.3 교육 및 인식 제고 프로그램

효과적인 ISO/IEC 18974 구현을 위해서는 조직 전체의 이해와 참여가 필수적입니다. 교육 및 인식 제고 프로그램을 통해 조직 구성원들이 오픈소스 보안의 중요성을 인식하고, 자신의 역할과 책임을 다할 수 있도록 지원해야 합니다.

  1. 대상별 맞춤형 교육 프로그램 개발
    • 개발자: 안전한 코딩 방법, 주요 오픈소스 라이선스, 취약점 대응 방법 등에 대한 교육을 제공합니다.
      • 예시: OWASP Top 10, SANS Top 25 등의 보안 교육 과정을 제공하고, 코드 리뷰 시 보안 취약점을 발견하는 방법을 훈련합니다.
    • 보안팀: 오픈소스 보안 감사, 사고 대응 절차, 최신 보안 위협 동향 등에 대한 교육을 제공합니다.
      • 예시: 모의 해킹 훈련, 침해 사고 분석 워크샵 등을 통해 실무 역량을 강화합니다.
    • 법무팀: 오픈소스 라이선스 종류, 법적 책임 및 의무, 관련 법규 등에 대한 교육을 제공합니다.
      • 예시: GPL(GNU General Public License), Apache License, MIT License 등 주요 오픈소스 라이선스에 대한 법률 강의를 제공합니다.
    • 경영진: 오픈소스 보안 투자의 필요성, ROI(Return on Investment, 투자 수익률), 위험 관리 등에 대한 교육을 제공합니다.
      • 예시: 오픈소스 보안 관련 워크샵 또는 세미나 참여를 지원하고, 투자 효과 분석 보고서를 제공합니다.
  2. 다양한 교육 방식 활용
    • 온라인 학습 플랫폼 구축: 시간과 장소에 구애받지 않는 학습 환경을 제공합니다.
      • 예시: Coursera, Udemy 등의 온라인 교육 플랫폼을 활용하거나, 사내 LMS(Learning Management System, 학습 관리 시스템)를 구축합니다.
    • 워크샵 및 핸즈온 세션 운영: 실제 사례를 통한 실습 중심의 학습 기회를 제공합니다.
      • 예시: OWASP ZAP, Burp Suite 등의 도구를 활용한 웹 애플리케이션 보안 취약점 진단 워크샵을 진행합니다.
    • 외부 전문가 초청 세미나: 최신 동향 및 모범 사례를 공유하고, 전문적인 지식을 습득할 수 있는 기회를 제공합니다.
  3. 지속적인 인식 제고 활동
    • 내부 뉴스레터 또는 블로그 운영: 오픈소스 보안 관련 최신 뉴스, 취약점 정보, 성공 사례 등을 정기적으로 공유합니다.
    • 사내 보안 캠페인 실시: 오픈소스 보안의 중요성을 강조하고, 구성원들의 참여를 유도하는 캠페인을 실시합니다.
    • ‘Security Champions’ 프로그램 운영: 각 팀에서 보안 문화를 선도할 인력을 양성하고, 보안 관련 활동을 장려합니다.
  4. 평가 및 피드백 체계 구축
    • 교육 효과성 측정: 교육 프로그램의 효과성을 측정하기 위해 KPI(Key Performance Indicator, 핵심 성과 지표)를 설정하고, 정기적으로 평가합니다. (예: 교육 이수율, 보안 지식 향상도 평가)
    • 피드백 수집: 교육 프로그램에 대한 피드백을 수집하고, 분석하여 프로그램 개선에 활용합니다.
    • 개선 사항 반영: 평가 결과 및 피드백을 바탕으로 교육 프로그램의 내용, 방법, 빈도 등을 지속적으로 개선합니다.

표 5.4: 교육 및 인식 제고 프로그램 요소

요소설명예시
대상별 교육개발자, 보안팀, 법무팀, 경영진 맞춤형 교육 제공개발자를 위한 안전한 코딩 교육
다양한 교육 방식온라인 강의, 워크샵, 세미나 등 활용모의 해킹 훈련, 법률 자문
지속적인 인식 제고뉴스레터, 사내 캠페인, Security Champions월간 보안 뉴스레터 발행
평가 및 피드백교육 효과 측정, 피드백 반영교육 만족도 조사, KPI 달성률 평가

2.6 - 6. ISO/IEC 18974 자체 인증 절차

ISO/IEC 18974 자체 인증 절차는 조직이 오픈소스 소프트웨어의 보안 보증 프로그램을 효과적으로 구현하고 있음을 스스로 확인하는 과정입니다. 이 절차는 준비 및 갭 분석, 구현 및 프로세스 개선, 자체 평가 및 인증 선언, 유지 및 갱신 단계로 구성됩니다.

6.1 준비 및 갭 분석

준비 및 갭 분석 단계는 ISO/IEC 18974 표준의 요구사항을 이해하고, 조직의 현재 오픈소스 보안 관리 수준을 평가하여 개선해야 할 부분을 식별하는 과정입니다. 이 단계는 다음과 같은 세부 작업으로 구성됩니다.

6.1.1 ISO/IEC 18974 표준 문서 상세 검토

  1. 핵심 요구사항 목록 작성
    • ISO/IEC 18974 표준 문서를 철저히 검토합니다.
    • 각 섹션별로 핵심 요구사항을 추출하여 목록화합니다.
    • 요구사항의 우선순위를 정합니다.
  2. 용어 및 개념 이해
    • 표준에서 사용되는 전문 용어와 개념을 정리합니다.
    • 필요한 경우 용어집을 작성하여 조직 내에서 공유합니다.
  3. 자체 인증 체크리스트 확보
    • OpenChain Project 웹사이트에서 최신 버전의 자체 인증 체크리스트를 다운로드합니다.
    • 체크리스트의 구조와 내용을 숙지합니다.

표 6.1: ISO/IEC 18974 핵심 요구사항 예시

영역요구사항우선순위
정책오픈소스 보안 정책 수립높음
SBOMSBOM 생성 및 관리 프로세스 구축높음
취약점 관리취약점 스캐닝 및 대응 절차 수립중간
교육직원 대상 오픈소스 보안 교육 실시중간

이 표는 ISO/IEC 18974의 주요 요구사항과 그 우선순위를 보여줍니다. 조직은 이를 바탕으로 구현 계획을 수립할 수 있습니다.

6.1.2 현행 오픈소스 보안 관리 프로세스 분석

  1. 기존 정책, 절차, 도구 목록화
    • 현재 사용 중인 오픈소스 관련 정책, 절차, 도구를 식별합니다.
    • 각 항목의 목적, 범위, 책임자를 명확히 합니다.
  2. 강점과 약점 식별
    • 현재 프로세스의 효과적인 부분과 개선이 필요한 부분을 분석합니다.
    • SWOT 분석을 수행하여 내부 강점과 약점, 외부 기회와 위협을 파악합니다.
  3. 프로세스 흐름도 작성
    • 주요 오픈소스 관리 프로세스(예: 오픈소스 사용 승인, 취약점 대응)에 대한 흐름도를 작성합니다.
    • 각 단계별 책임자와 소요 시간을 명시합니다.

표 6.2: 현행 오픈소스 보안 관리 프로세스 SWOT 분석 예시

구분내용
강점(S)- 개발팀의 높은 오픈소스 활용도
  • 기존 보안팀의 전문성 | | 약점(W) | - 체계적인 SBOM 관리 부재
  • 오픈소스 보안 교육 프로그램 미흡 | | 기회(O) | - 오픈소스 커뮤니티와의 협력 가능성
  • 클라우드 기반 보안 도구의 발전 | | 위협(T) | - 증가하는 오픈소스 취약점
  • 복잡해지는 라이선스 요구사항 |

이 SWOT 분석 표는 조직의 현재 오픈소스 보안 관리 상태를 종합적으로 보여줍니다. 이를 통해 개선이 필요한 영역을 파악할 수 있습니다.

6.1.3 갭 분석 수행

  1. 현재 상태와 요구사항 간 차이 파악
    • ISO/IEC 18974 요구사항과 현재 프로세스를 항목별로 비교합니다.
    • 각 요구사항에 대한 준수 여부를 ‘완전 준수’, ‘부분 준수’, ‘미준수’로 평가합니다.
  2. 개선 필요 영역 우선순위 지정
    • 식별된 차이점을 바탕으로 개선이 필요한 영역의 우선순위를 결정합니다.
    • 비즈니스 영향도, 구현 난이도, 자원 요구사항 등을 고려하여 우선순위를 정합니다.
  3. 구체적인 개선 목표 설정
    • 각 개선 영역에 대해 구체적이고 측정 가능한 목표를 설정합니다.
    • 목표 달성을 위한 시간표를 작성합니다.

표 6.3: 갭 분석 및 개선 계획 예시

요구사항현재 상태개선 목표우선순위완료 예정일
SBOM 관리부분 준수자동화된 SBOM 생성 부재SBOM 자동 생성 도구 도입높음3개월 후
취약점 관리미준수체계적인 취약점 스캐닝 부재주간 취약점 스캔 프로세스 수립높음2개월 후
보안 교육부분 준수정기적인 교육 프로그램 부재분기별 오픈소스 보안 교육 실시중간6개월 후

이 표는 갭 분석 결과와 그에 따른 개선 계획을 보여줍니다. 조직은 이를 바탕으로 구체적인 액션 플랜을 수립할 수 있습니다.

6.1.4 OpenChain Project 체크리스트 활용

OpenChain Project에서 제공하는 자체 인증 체크리스트는 ISO/IEC 18974 준수 여부를 평가하는 데 매우 유용한 도구입니다. 체크리스트 활용 방법은 다음과 같습니다:

  1. 체크리스트 다운로드 및 검토
    • OpenChain Project 웹사이트에서 최신 버전의 체크리스트를 다운로드합니다.
    • 체크리스트의 각 항목을 검토하고, 필요한 경우 조직의 상황에 맞게 용어를 조정합니다.
  2. 자체 평가 수행
    • 체크리스트의 각 항목에 대해 ‘예’, ‘아니오’, ‘해당 없음’ 중 하나로 응답합니다.
    • ‘아니오’ 또는 ‘해당 없음’ 응답에 대해서는 반드시 이유를 기록합니다.
  3. 증거 자료 수집
    • 각 ‘예’ 응답에 대해 이를 뒷받침할 수 있는 증거 자료를 수집합니다.
    • 증거 자료는 문서, 스크린샷, 로그 등 다양한 형태가 될 수 있습니다.
  4. 개선 계획 수립
    • ‘아니오’ 응답 항목에 대해 개선 계획을 수립합니다.
    • 각 개선 계획에 대해 책임자와 완료 예정일을 지정합니다.

표 6.4: OpenChain Project 체크리스트 예시

항목질문응답증거개선 계획
1.1오픈소스 정책이 문서화되어 있는가?정책문서.pdf-
1.2모든 소프트웨어 직원이 정책을 인지하고 있는가?아니오-전사 교육 실시 (3개월 내)
1.3SBOM을 생성하고 관리하는 프로세스가 있는가?부분SBOM_관리_절차.docxSBOM 자동화 도구 도입 (6개월 내)

이 표는 OpenChain Project 체크리스트의 일부 항목과 그에 대한 자체 평가 결과를 보여줍니다. 이를 통해 조직은 현재의 준수 상태를 파악하고 개선 계획을 수립할 수 있습니다.

준비 및 갭 분석 단계를 통해 조직은 ISO/IEC 18974 구현을 위한 기초를 마련할 수 있습니다. 이 단계에서 수집된 정보와 수립된 계획은 다음 단계인 ‘구현 및 프로세스 개선’의 기반이 됩니다.

6.2 구현 및 프로세스 개선

이 단계에서는 갭 분석 결과를 바탕으로 오픈소스 보안 정책을 수립/개정하고, 관련 프로세스와 절차를 개선하며, 필요한 도구를 도입하고 구성합니다. 목표는 ISO/IEC 18974 요구사항을 충족하는 효과적인 오픈소스 보안 관리 체계를 구축하는 것입니다.

6.2.1 오픈소스 보안 정책 수립 또는 개정

  1. ISO/IEC 18974 요구사항 반영:
    • 갭 분석 결과를 바탕으로 ISO/IEC 18974의 모든 요구사항이 정책에 반영되었는지 확인합니다.
    • 특히, SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) 관리, 취약점 관리, 라이선스 준수 등 핵심 요구사항을 빠짐없이 포함해야 합니다.
  2. 조직 특성에 맞는 세부 지침 개발:
    • 조직의 규모, 산업, 기술 스택, 그리고 위험 관리 정책을 고려하여 정책을 구체화합니다.
    • 예를 들어, 금융 회사의 경우 개인정보보호 및 금융 관련 규제를 준수하기 위한 추가적인 보안 조치를 정책에 명시해야 합니다.
  3. 최고 경영자 승인:
    • 정책의 실행력을 확보하기 위해 최고 경영자(CEO) 또는 최고 정보 보안 책임자(CISO)의 승인을 받습니다.
    • 승인된 정책은 공식 문서로 관리하고, 조직 내 모든 관련자에게 공유합니다.

표 6.5: 오픈소스 보안 정책 포함 내용

영역세부 내용예시
적용 범위정책이 적용되는 대상 시스템, 프로젝트, 컴포넌트모든 내부 개발 프로젝트, 외부 공급망
역할 및 책임오픈소스 관리 관련 역할별 책임개발자: 안전한 코딩, 보안팀: 취약점 스캔
SBOM 관리SBOM 생성, 업데이트, 저장 절차주기적인 SBOM 생성 및 버전 관리
취약점 관리취약점 스캔, 평가, 대응 절차CVSS 점수 기반 우선순위 지정 및 패치 적용
라이선스 준수라이선스 검토, 고지 의무 준수 절차오픈소스 사용 전 라이선스 검토 의무화
예외 처리정책 예외 상황 발생 시 처리 절차긴급 상황 시 예외 승인 절차

6.2.2 프로세스 및 절차 개선

  1. SBOM 생성 및 관리 프로세스 구축:
    • SBOM 생성: 소프트웨어 빌드 과정에서 SBOM을 자동으로 생성하는 프로세스를 구축합니다.
    • SBOM 저장 및 관리: 생성된 SBOM을 안전하게 저장하고, 버전 관리 시스템과 연동하여 관리합니다.
    • SBOM 배포: 필요한 경우 (예: 고객 요청 시, 보안 사고 발생 시) SBOM을 신속하게 배포할 수 있는 체계를 마련합니다.
    • 도구 활용: SPDX Tools, FOSSLight, SW360 등 SBOM 생성 도구를 활용하여 프로세스를 자동화합니다.
  2. 취약점 모니터링 및 대응 체계 수립:
    • 취약점 스캔: 오픈소스 컴포넌트의 취약점을 주기적으로 스캔하는 프로세스를 구축합니다.
      • 도구 활용: OWASP Dependency-Check, Snyk, Black Duck 등 취약점 스캐닝 도구를 활용합니다.
      • 스캔 주기: 프로젝트의 중요도와 변경 빈도를 고려하여 스캔 주기를 설정합니다.
    • 취약점 평가 및 우선순위 지정: 발견된 취약점에 대해 심각도, 영향도, 악용 가능성 등을 평가하고, 대응 우선순위를 결정합니다.
    • 취약점 대응: 평가 결과에 따라 패치 적용, 완화 조치, 또는 컴포넌트 교체 등 적절한 대응 조치를 취합니다.
    • 대응 기한 설정: 취약점의 심각도에 따라 대응 기한을 설정하고, 기한 내에 해결되지 않는 경우 예외 처리 절차를 따릅니다.
  3. 사고 발생 시 보고 체계 구축:
    • 보고 절차: 오픈소스 관련 보안 사고 (예: 취약점 악용, 라이선스 위반) 발생 시 보고 절차를 명확히 정의합니다.
    • 보고 대상: 보고해야 할 대상 (예: 보안팀, 법무팀, 경영진)을 지정합니다.
    • 보고 양식: 보고에 필요한 정보 (예: 사고 발생 시점, 영향 범위, 관련 컴포넌트)를 포함하는 보고 양식을 마련합니다.

표 6.6: 프로세스 및 절차 개선 내용

프로세스개선 내용도구/방법
SBOM 생성자동 SBOM 생성SPDX Tools, FOSSLight, SW360 등 CI/CD 연동
취약점 스캔주기적 스캔 및 평가OWASP Dependency-Check, Snyk, CVSS
사고 보고명확한 보고 절차 및 책임자 지정보고 양식 작성, 보고 대상 지정

6.2.3 필요 도구 도입 및 구성

  1. 오픈소스 검색 및 취약점 스캐닝 도구 선정:
    • 조직의 개발 환경, 기술 스택, 예산 등을 고려하여 적절한 도구를 선정합니다.
    • 무료 오픈소스 도구와 상용 도구를 비교하고, 필요한 기능을 갖춘 도구를 선택합니다.
    • 무료 도구: OWASP Dependency-Check, Bandit, Trivy 등
    • 상용 도구: Snyk, Black Duck, WhiteSource 등
  2. 기존 개발 환경과의 통합:
    • 선정된 도구를 IDE(Integrated Development Environment, 통합 개발 환경), CI/CD(Continuous Integration/Continuous Delivery, 지속적인 통합/지속적인 제공) 파이프라인 등 기존 개발 환경과 통합합니다.
    • 통합을 통해 개발자들이 쉽게 도구를 사용하고, 보안 검사를 자동화할 수 있도록 지원합니다.
  3. 자동화 기능 활용:
    • 도구의 자동화 기능을 최대한 활용하여 SBOM 생성, 취약점 스캔, 라이선스 검사 등의 작업을 자동화합니다.
    • 자동화를 통해 인적 자원을 절약하고, 휴먼 에러 발생 가능성을 줄일 수 있습니다.

표 6.7: 오픈소스 보안 도구 선정 기준

기준설명고려 사항
기능필요한 기능 제공 여부SBOM 생성, 취약점 스캔, 라이선스 검사
정확도오탐 및 미탐 최소화최신 취약점 데이터베이스 연동
사용 편의성쉬운 설치 및 사용법사용자 인터페이스, 문서화
호환성기존 개발 환경과의 통합IDE, CI/CD 도구 연동
비용예산 범위 내에서 합리적인 가격무료 오픈소스 도구, 상용 도구 가격 비교

6.2.4 문서화 작업

  1. 정책, 프로세스, 절차에 대한 상세 문서 작성:
    • 수립/개정된 정책, 개선된 프로세스, 관련 절차에 대한 상세 문서를 작성합니다.
    • 문서는 명확하고 이해하기 쉬운 언어로 작성해야 하며, 조직 내 모든 관련자가 쉽게 접근할 수 있어야 합니다.
  2. 역할 및 책임 명확화:
    • 각 프로세스 단계별 책임자와 담당자를 명확히 정의하고 문서화합니다.
    • RACI(Responsible, Accountable, Consulted, Informed) 매트릭스를 활용하여 역할과 책임을 명확하게 정의할 수 있습니다.
  3. 문서 버전 관리:
    • 문서의 변경 이력을 관리하고, 최신 버전을 유지하기 위해 문서 버전 관리 시스템을 구축합니다.
    • Git, Subversion 등 버전 관리 도구를 활용하거나, SharePoint, Confluence 등 협업 도구를 활용할 수 있습니다.

표 6.8: 문서화 작업 내용

문서내용예시
오픈소스 보안 정책오픈소스 사용 규칙, 책임, 제약 사항- 오픈소스 사용 승인 절차
- 라이선스 준수 가이드라인
SBOM 관리 절차SBOM 생성, 저장, 배포 방법- SBOM 생성 도구 사용법
- SBOM 저장 위치 및 접근 권한
취약점 관리 절차취약점 스캔, 평가, 대응 방법- 취약점 심각도별 대응 기한
- 패치 적용 방법
사고 대응 계획오픈소스 관련 보안 사고 발생 시 대응 절차- 사고 보고 양식
- 비상 연락망

이 단계를 통해 조직은 ISO/IEC 18974 구현에 필요한 체계적인 기반을 마련하고, 지속적인 개선을 위한 준비를 마칠 수 있습니다. 다음은 자체 평가 및 인증 선언 단계입니다.

6.3 자체 평가 및 인증 선언

이 단계에서는 앞서 준비하고 개선한 내용을 바탕으로 조직 스스로 ISO/IEC 18974 요구사항을 충족하는지 평가하고, OpenChain Project 웹사이트에서 자체 인증을 선언합니다. 자체 평가는 객관적이고 체계적으로 수행되어야 하며, 인증 선언은 조직의 최고 책임자가 승인해야 합니다.

6.3.1 OpenChain Project 자체 인증 체크리스트 활용

  1. 최신 버전 체크리스트 다운로드:
    • OpenChain Project 웹사이트(https://www.openchainproject.org/security-assurance)에서 ISO/IEC 18974 자체 인증을 위한 최신 버전의 체크리스트를 다운로드합니다.
    • 체크리스트는 스프레드시트(.xlsx) 또는 문서(.pdf) 형식으로 제공될 수 있습니다.
  2. 체크리스트 항목 이해 및 해석:
    • 체크리스트의 각 항목을 주의 깊게 읽고, 조직의 상황에 맞게 해석합니다.
    • 체크리스트 항목은 일반적으로 ISO/IEC 18974 표준의 특정 요구사항을 반영하며, 조직이 해당 요구사항을 어떻게 충족하는지 평가하는 데 사용됩니다.
  3. 관련 증거 자료 준비:
    • 각 체크리스트 항목에 대해 조직이 해당 요구사항을 충족하고 있음을 입증할 수 있는 증거 자료를 준비합니다.
    • 증거 자료는 정책 문서, 절차서, 감사 보고서, 교육 자료, 시스템 로그 등 다양한 형태를 가질 수 있습니다.

6.3.2 체계적인 자체 평가 수행

  1. 각 요구사항에 대한 준수 여부 확인:
    • 준비된 증거 자료를 검토하고, 체크리스트의 각 항목에 대해 조직이 해당 요구사항을 준수하고 있는지 여부를 판단합니다.
    • 각 항목에 대해 “예”, “아니오”, “해당 없음” 중 하나로 응답합니다.
  2. 객관적인 시각 유지:
    • 자체 평가 과정에서 주관적인 판단을 배제하고, 객관적인 근거에 기반하여 평가합니다.
    • 평가 결과의 신뢰성을 높이기 위해 독립적인 감사팀 또는 외부 전문가의 도움을 받는 것을 고려합니다.
  3. 평가 결과 기록:
    • 각 체크리스트 항목에 대한 평가 결과와 근거를 상세하게 기록합니다.
    • 특히, “아니오” 또는 “해당 없음"으로 응답한 항목에 대해서는 그 이유와 개선 계획을 명확하게 기록합니다.

표 6.9: OpenChain Project 자체 인증 체크리스트 예시

No.요구사항준수 여부증거 자료설명개선 계획
1.1오픈소스 정책이 문서화되어 있는가?opensource_policy.pdf조직의 오픈소스 정책이 문서화되어 있으며, 관련 이해관계자에게 공유되고 있다.-
1.2SBOM 생성 프로세스가 구축되어 있는가?sbom_generation_procedure.pdf소프트웨어 빌드 과정에서 SBOM을 자동으로 생성하는 프로세스가 구축되어 있다.-
1.3취약점 관리 프로세스가 운영되고 있는가?아니오-현재 취약점 스캐닝은 수동으로 진행되고 있으며, 자동화된 프로세스가 구축되어 있지 않다.자동 취약점 스캐닝 도구 도입 (6개월 이내)

6.3.3 미충족 항목 식별 및 개선 계획 수립

  1. 부족한 부분에 대한 원인 분석:
    • 자체 평가 결과 “아니오” 또는 “해당 없음"으로 응답한 항목에 대해 그 원인을 분석합니다.
    • 원인 분석 시 기술적인 문제, 예산 부족, 인력 부족, 프로세스 미비 등 다양한 요인을 고려합니다.
  2. 단기 및 중장기 개선 방안 도출:
    • 분석된 원인을 해결하기 위한 단기 및 중장기 개선 방안을 도출합니다.
    • 단기 개선 방안은 비교적 쉽게 실행할 수 있는 것부터 시작하고, 중장기 개선 방안은 조직 전체의 역량 강화를 목표로 합니다.
  3. 개선 일정 및 책임자 지정:
    • 각 개선 방안에 대한 실행 일정과 책임자를 명확하게 지정합니다.
    • 책임자는 개선 계획의 진행 상황을 추적하고, 필요한 자원을 확보하며, 계획을 완료할 책임을 가집니다.

표 6.10: 미충족 항목에 대한 개선 계획 예시

항목미충족 사유개선 방안책임자완료 예정일
1.3자동 취약점 스캐닝 도구 미비자동 취약점 스캐닝 도구 도입 및 CI/CD 파이프라인 통합보안팀2025년 6월 30일
2.1오픈소스 보안 교육 프로그램 부재전 직원 대상 오픈소스 보안 교육 프로그램 개발 및 시행HR팀2025년 3월 31일

6.3.4 OpenChain Project 웹사이트에서 인증 선언

  1. 자체 인증 페이지 접속:
  2. 필요 정보 입력:
    • 조직 이름, 주소, 연락처 등 조직 기본 정보를 입력합니다.
    • 자체 평가 결과, 개선 계획 등 인증 관련 정보를 입력합니다.
    • 인증 책임자 이름, 직책, 연락처 등 담당자 정보를 입력합니다.
  3. 선언문 동의 및 제출:
    • OpenChain Project의 자체 인증 선언문에 동의합니다.
    • 입력된 정보를 확인하고, 조직의 최고 책임자(예: CISO, 법무팀장)의 승인을 받아 제출합니다.
  4. 인증 배지 획득:
    • 인증 선언이 완료되면 OpenChain Project에서 제공하는 ISO/IEC 18974 인증 배지를 획득합니다.
    • 획득한 인증 배지를 웹사이트, 마케팅 자료 등에 활용하여 조직의 오픈소스 보안 역량을 홍보할 수 있습니다.

이 단계를 완료함으로써 조직은 ISO/IEC 18974 요구사항 준수를 공식적으로 선언하고, 자체적인 오픈소스 보안 관리 체계를 구축했음을 대외적으로 알릴 수 있습니다. 다음은 인증 유지 및 갱신 단계입니다.

6.4 유지 및 갱신

ISO/IEC 18974 자체 인증은 일회성 이벤트가 아니라 지속적인 프로세스입니다. 이 단계를 통해 조직은 인증을 유지하고, 오픈소스 보안 관리 체계를 지속적으로 개선하며, 변화하는 위협 환경에 효과적으로 대응할 수 있습니다.

6.4.1 정기적인 내부 감사 실시

  1. 감사 계획 수립:
    • 연간 또는 반기별로 내부 감사를 실시할 계획을 수립합니다.
    • 감사 범위, 감사 주기, 감사 대상 부서 및 시스템, 그리고 감사 담당자를 명확하게 정의합니다.
  2. 감사 수행:
    • 체크리스트, 인터뷰, 문서 검토, 시스템 로그 분석 등 다양한 방법을 활용하여 감사를 수행합니다.
    • 감사 과정에서 ISO/IEC 18974 요구사항 준수 여부, 정책 및 절차의 효과성, 그리고 개선 기회 등을 평가합니다.
  3. 감사 결과 보고:
    • 감사 결과를 문서화하고, 발견된 문제점, 개선 사항, 그리고 권고사항을 명확하게 제시합니다.
    • 감사 보고서는 관련 이해관계자(예: CISO, 법무팀, 개발팀)에게 공유되어야 합니다.
  4. 개선 활동 추적:
    • 감사 결과에 따라 시정 조치 계획을 수립하고, 실행합니다.
    • 시정 조치 계획의 진행 상황을 정기적으로 추적하고, 완료 여부를 확인합니다.

표 6.11: 내부 감사 점검 항목 예시

점검 항목설명점검 내용
정책 준수오픈소스 보안 정책 준수 여부 확인정책 준수율, 정책 위반 사례
SBOM 관리SBOM 생성, 업데이트, 관리 프로세스 점검SBOM 생성 주기, SBOM 정확도, SBOM 관리 시스템
취약점 관리취약점 스캔, 평가, 대응 프로세스 점검스캔 주기, 패치 적용률, 미해결 취약점 수
라이선스 준수라이선스 검토 및 고지 의무 준수 여부 확인라이선스 위반 사례, 라이선스 검토 프로세스

6.4.2 새로운 요구사항 및 업데이트 사항 추적

  1. 정보 획득:
    • OpenChain Project 웹사이트, 뉴스레터, 커뮤니티 포럼 등을 통해 ISO/IEC 18974 관련 최신 정보를 수집합니다.
    • 오픈소스 보안 관련 컨퍼런스, 세미나, 워크샵 등에 참여하여 최신 기술 동향과 모범 사례를 학습합니다.
    • 보안 관련 법규 및 규제 (예: GDPR, CCPA, DORA, EU Cyber Resilience Act)의 변경 사항을 주시합니다.
  2. 영향 평가:
    • 새로운 요구사항 또는 업데이트 사항이 조직의 오픈소스 보안 관리 체계에 미치는 영향을 평가합니다.
    • 기존 정책, 절차, 도구 등을 변경해야 할 필요성이 있는지 확인합니다.
  3. 프로세스 반영:
    • 평가 결과에 따라 필요한 변경 사항을 정책 및 절차에 반영합니다.
    • 조직 구성원들에게 변경된 내용에 대해 교육하고, 새로운 도구를 도입합니다.

6.4.3 18개월 주기 공식 재검토 (권장)

  1. 전면적인 재평가:
    • OpenChain Project에서 제공하는 최신 체크리스트를 사용하여 ISO/IEC 18974 요구사항 준수 여부를 다시 평가합니다.
    • 이전 평가 대비 개선된 부분과 추가 개선이 필요한 영역을 식별합니다.
  2. 개선 계획 수립:
    • 재평가 결과를 바탕으로 개선 계획을 수립하고, 실행합니다.
    • 이 과정은 앞서 설명한 갭 분석 및 구현 단계를 반복하는 것과 같습니다.
  3. 문서 업데이트:
    • 재평가 및 개선 활동 결과를 반영하여 정책, 절차, 그리고 관련 문서를 최신 상태로 유지합니다.

6.4.4 지속적 개선 활동

  1. 피드백 수집:
    • 조직 내부 및 외부 이해관계자로부터 오픈소스 보안 관리 체계에 대한 피드백을 수집합니다.
    • 설문 조사, 인터뷰, 워크샵 등 다양한 방법을 활용할 수 있습니다.
  2. 데이터 분석:
    • 수집된 피드백과 함께 SBOM 데이터, 취약점 분석 결과, 감사 결과 등 다양한 데이터를 분석하여 개선 기회를 식별합니다.
  3. 개선 실행:
    • 식별된 개선 기회에 대해 구체적인 실행 계획을 수립하고, 실행합니다.
    • 새로운 기술 도입, 프로세스 개선, 교육 프로그램 개발 등 다양한 활동을 수행할 수 있습니다.
  4. 성과 측정:
    • 개선 활동의 효과를 측정하기 위해 KPI(Key Performance Indicator, 핵심 성과 지표)를 설정하고, 정기적으로 측정합니다.
    • 측정 결과를 분석하여 개선 활동의 효과성을 평가하고, 필요한 경우 계획을 수정합니다.
  5. 지식 공유:
    • 개선 활동의 성공 사례와 실패 사례를 조직 내에 공유하여 학습 효과를 높입니다.
    • 사내 위키, 블로그, 뉴스레터 등을 활용하여 지식을 공유하고, 커뮤니케이션을 활성화합니다.

2.7 - 7. 사례 연구 및 성공 전략

이 섹션에서는 ISO/IEC 18974 인증 획득 사례를 분석하고, 성공적인 구현을 위한 핵심 전략을 제시합니다. 다양한 기업 규모별 사례를 통해 실제 적용 방법을 이해하고, 조직에 맞는 최적의 전략을 수립하는 데 도움이 될 것입니다.

7.1 다양한 기업 규모별 인증 획득 사례

7.1.1 글로벌 소프트웨어 기업: openEuler

openEuler는 중국의 주요 오픈소스 운영 체제 프로젝트로, 2024년 6월 ISO/IEC 18974 인증을 획득했습니다. 이 사례는 대규모 오픈소스 프로젝트에서 ISO/IEC 18974를 구현하는 방법을 보여줍니다.

  • 인증 획득 배경 및 목표: openEuler는 안전하고 규정을 준수하며 지속 가능한 운영 체제 커뮤니티를 구축하는 것을 목표로 했습니다.
  • 구현 과정에서의 주요 도전 과제: 대규모 오픈소스 프로젝트에서 일관된 보안 관행을 구현하는 것이 주요 과제였습니다.
  • 인증 획득 후 비즈니스 영향 및 이점: openEuler의 개발 프로세스, 소프트웨어 공급망, 위험 평가, 관리 및 개발자 보안 능력에 대한 최고 수준의 표준을 인정받았습니다.
  • 성공 요인 분석: 커뮤니티 전체의 협력과 헌신, 그리고 보안을 핵심 가치로 삼은 것이 주요 성공 요인이었습니다.

핵심 교훈: 대규모 오픈소스 프로젝트에서는 커뮤니티의 참여와 협력이 ISO/IEC 18974 구현의 핵심 성공 요소입니다.

7.1.2 대기업: KT

KT는 2024년 10월 ISO/IEC 18974 인증을 획득했습니다. 이 사례는 대기업이 기존 보안 체계에 ISO/IEC 18974를 통합하는 방법을 보여줍니다.

  • 인증 획득 배경 및 목표: KT는 오픈소스 소프트웨어 보안 관리 체계를 강화하고 공급망 내 신뢰성을 높이기 위해 인증을 추진했습니다.
  • 구현 과정에서의 주요 도전 과제: 오픈소스 컴플라이언스 준수를 위한 체계적인 관리 시스템 구축이 필요했습니다.
  • 인증 획득 후 비즈니스 영향 및 이점:
    • 체계적이고 일관성 있는 오픈소스 소프트웨어 보안 관리 역량을 인정받았습니다.
    • 오픈소스 보안 및 컴플라이언스 준수 기업으로서의 위상을 강화했습니다.
    • 공급망 내 참여자 간의 신뢰성을 높였습니다.
  • 성공 요인 분석:
    • 오픈소스 관리 포털을 통한 체계적인 라이선스 및 보안 점검 시스템 구축
    • 사내 ‘OSRB’ (OpenSource Review Board, 오픈소스 검토 위원회) 구성을 통한 신속한 법무 및 보안 이슈 해결
    • 지속적인 임직원 교육을 통한 올바른 오픈소스 사용 문화 정착

핵심 교훈: 대기업은 기존 보안 체계와 ISO/IEC 18974를 통합하고, 사내 전문가 그룹을 활용하여 효율적인 오픈소스 관리를 달성할 수 있습니다.

7.1.3 금융 기업: 카카오뱅크

카카오뱅크는 2023년 11월, 국내 금융사 최초로 오픈소스 보안 보증 국제 표준인 ISO/IEC 18974 인증을 획득했습니다. 이 사례는 높은 수준의 보안이 요구되는 금융 기업에서 ISO/IEC 18974를 구현하는 방법을 보여줍니다.

  • 인증 획득 배경 및 목표: 세계적인 수준의 금융 서비스를 빠르고 효율적으로 제공하기 위해 오픈소스를 적극적으로 활용하면서, 체계적인 관리 체계 구축의 필요성이 대두되었습니다.
  • 구현 과정에서의 주요 도전 과제: 오픈소스 정책과 프로세스 수립, 컴플라이언스 시스템 구축, 담당 조직과 인력의 전문성 확보, 사내 구성원의 교육 수행 등 30여 개 보안인증 요건을 충족해야 했습니다.
  • 인증 획득 후 비즈니스 영향 및 이점: 오픈소스 활용 및 보안 관리 역량을 국제적으로 인정받았으며, 체계적이고 일관성 있는 오픈소스 보안 관리 역량을 갖춘 기업으로 인정받았습니다. 고객들에게 더욱 안전한 금융 서비스를 제공할 수 있다는 신뢰를 주었습니다.
  • 성공 요인 분석: 오픈소스 전문 협의체(OSRB)를 구성하여 오픈소스 관련 문제를 공동으로 논의하고, 라이선스 및 보안 취약점 등을 사전에 관리하는 체계를 구축했습니다.

핵심 교훈: 금융 기업은 높은 수준의 보안 요구사항을 충족하기 위해 체계적인 오픈소스 관리 체계를 구축하고, 전문가 협의체를 활용하여 전문성을 확보해야 합니다.

7.1.4 중소기업: (가상 사례) IT 솔루션 제공 기업 “TechSolution”

TechSolution은 중소규모 IT 솔루션 제공 기업으로, 클라우드 기반 서비스를 개발하고 있습니다. TechSolution은 고객 데이터를 안전하게 보호하고, 경쟁 우위를 확보하기 위해 ISO/IEC 18974 인증을 추진했습니다.

  • 인증 획득 배경 및 목표: TechSolution은 클라우드 기반 서비스의 보안을 강화하고, 고객 신뢰도를 높이며, 새로운 비즈니스 기회를 창출하기 위해 ISO/IEC 18974 인증을 목표로 설정했습니다.
  • 구현 과정에서의 주요 도전 과제: 제한된 예산과 인력으로 ISO/IEC 18974 요구사항을 충족하는 것이 주요 과제였습니다.
  • 인증 획득 후 비즈니스 영향 및 이점:
    • 클라우드 기반 서비스의 보안 수준을 향상시키고, 고객 데이터를 안전하게 보호할 수 있었습니다.
    • 고객 신뢰도가 향상되어 기존 고객과의 관계를 강화하고, 새로운 고객을 유치하는 데 성공했습니다.
    • ISO/IEC 18974 인증 획득을 홍보하여 기업 이미지를 개선하고, 경쟁 우위를 확보했습니다.
  • 성공 요인 분석:
    • 기존 개발팀과 보안팀의 협력을 강화하고, 오픈소스 보안 책임자를 지정하여 책임과 역할을 명확히 했습니다.
    • 클라우드 기반 SBOM 생성 및 취약점 스캐닝 도구를 활용하여 초기 투자 비용을 절감하고, 관리 효율성을 높였습니다.
    • 외부 컨설팅 업체의 도움을 받아 ISO/IEC 18974 요구사항을 체계적으로 구현하고, 인증 획득을 위한 노하우를 전수받았습니다.

핵심 교훈: 중소기업은 제한된 자원을 효율적으로 활용하고, 외부 전문가의 도움을 받아 ISO/IEC 18974 인증을 성공적으로 획득할 수 있습니다.

7.1.5 스타트업: (가상 사례) AI 기반 서비스 개발 스타트업 “AIBrain”

AIBrain은 AI 기반 서비스를 개발하는 초기 단계의 스타트업입니다. AIBrain은 혁신적인 기술과 빠른 개발 속도를 강점으로 내세우고 있지만, 보안 문제에 대한 우려도 가지고 있습니다.

  • 인증 획득 배경 및 목표: AIBrain은 ISO/IEC 18974 인증을 통해 개발 프로세스 전반에 걸쳐 보안을 강화하고, 투자 유치 및 파트너십 체결에 긍정적인 영향을 미치기를 기대했습니다.
  • 구현 과정에서의 주요 도전 과제: 초기 단계의 스타트업으로서 보안 관련 전문 인력이 부족하고, 개발 속도를 늦추지 않으면서 ISO/IEC 18974 요구사항을 충족하는 것이 어려웠습니다.
  • 인증 획득 후 비즈니스 영향 및 이점:
    • 보안을 고려한 개발 문화가 정착되어 제품의 보안성이 향상되었습니다.
    • 투자자 및 파트너에게 보안 역량을 입증하여 투자 유치 및 파트너십 체결에 성공했습니다.
    • ISO/IEC 18974 인증 획득을 홍보하여 기업 이미지를 개선하고, 경쟁 우위를 확보했습니다.
  • 성공 요인 분석:
    • 개발 프로세스에 보안 검사를 통합하고, 자동화된 보안 도구를 적극 활용하여 개발 속도를 유지하면서도 보안을 강화했습니다.
    • 클라우드 기반 개발 환경을 활용하여 보안 인프라 구축 비용을 절감했습니다.
    • OpenChain Project에서 제공하는 자료와 가이드라인을 활용하여 ISO/IEC 18974 요구사항을 효과적으로 구현했습니다.

핵심 교훈: 스타트업은 개발 프로세스에 보안을 통합하고, 클라우드 기반 환경을 활용하여 비용 효율적으로 ISO/IEC 18974를 구현할 수 있습니다.

표 7.1: 기업 규모별 ISO/IEC 18974 인증 획득 사례 요약

기업 규모기업주요 특징핵심 성공 요인
글로벌 소프트웨어 기업openEuler대규모 오픈소스 프로젝트커뮤니티 협력, 보안 중심 문화
대기업KT기존 보안 체계 통합사내 전문가 활용, 체계적인 관리 시스템
금융 기업카카오뱅크높은 보안 요구사항전문가 협의체 활용, 체계적인 관리 체계
중소기업 (가상)TechSolution제한된 자원클라우드 기반 도구, 외부 전문가 활용
스타트업 (가상)AIBrain빠른 개발 속도개발 프로세스에 보안 통합, 클라우드 활용

이 표는 다양한 기업 규모별 ISO/IEC 18974 인증 획득 사례를 요약하여 보여줍니다. 조직은 자신의 규모와 특성에 맞는 사례를 참고하여 구현 전략을 수립할 수 있습니다.

7.2 성공적인 구현을 위한 핵심 전략

ISO/IEC 18974 구현을 성공적으로 이끌기 위한 핵심 전략은 다음과 같습니다. 이러한 전략들은 앞서 살펴본 사례 연구들을 통해 검증되었으며, 조직의 상황에 맞게 적용하여 효과를 극대화할 수 있습니다.

7.2.1 경영진의 적극적인 지원 확보

  1. 보안 투자의 ROI(Return on Investment, 투자 수익률) 제시:
    • 오픈소스 보안 관리가 비즈니스 연속성, 고객 신뢰도, 법규 준수에 미치는 긍정적인 영향을 정량적으로 제시합니다.
    • 예: “ISO/IEC 18974 인증 획득 후 고객 이탈률 5% 감소”, “오픈소스 관련 보안 사고 발생 횟수 30% 감소” 등 구체적인 수치를 활용합니다.
  2. 정기적인 현황 보고 및 피드백:
    • 월간 또는 분기별로 오픈소스 보안 현황을 경영진에게 보고하고 피드백을 받습니다.
    • 보고서에는 SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) 현황, 취약점 발생 추이, 라이선스 준수 현황, 그리고 개선 활동 결과 등을 포함합니다.
  3. 오픈소스 보안 문화 조성:
    • 경영진이 앞장서서 오픈소스 보안의 중요성을 강조하고, 전사적인 인식을 제고합니다.
    • 오픈소스 보안 관련 교육 프로그램 참여를 장려하고, 우수 사례를 포상합니다.

실행 단계:

  1. 경영진에게 오픈소스 보안의 중요성을 설명하고, ISO/IEC 18974 도입의 필요성을 강조합니다.
  2. OSPO(Open Source Program Office, 오픈소스 프로그램 오피스) 설립 또는 오픈소스 보안 담당자 지정에 대한 승인을 얻습니다.
  3. 오픈소스 보안 관련 예산을 확보하고, 필요한 도구 및 인력 확보를 지원합니다.

7.2.2 단계적 접근 방식 채택

  1. 우선순위에 따른 점진적 구현:
    • 고위험 영역(예: 외부 공개 서비스, 핵심 비즈니스 로직)부터 시작하여 점진적으로 적용 범위를 확대합니다.
    • 낮은 위험 영역은 자동화 도구를 활용하여 효율적으로 관리합니다.
  2. 빠른 성과 창출을 통한 모멘텀 유지:
    • 단기간에 달성 가능한 목표를 설정하고, 성공 사례를 공유하여 조직 내 참여를 유도합니다.
    • 예: “3개월 내 SBOM 생성 및 관리 체계 구축”, “6개월 내 주요 프로젝트에 대한 취약점 스캐닝 완료” 등
  3. 위험 관리 및 통제:
    • 정기적인 위험 평가를 통해 새로운 위협을 식별하고, 적절한 대응 방안을 마련합니다.
    • 위험 관리 대장을 활용하여 오픈소스 관련 위험을 체계적으로 관리합니다.

실행 단계:

  1. 핵심 비즈니스 로직과 관련된 오픈소스 컴포넌트를 우선적으로 관리 대상으로 선정합니다.
  2. SBOM 생성 및 취약점 스캐닝 도구를 도입하여 초기 성과를 빠르게 창출합니다.
  3. 주기적인 보안 점검 및 감사 프로세스를 구축하여 지속적인 개선을 도모합니다.

7.2.3 자동화 도구 적극 활용

  1. CI/CD 파이프라인 통합:
    • SBOM 생성, 라이선스 검사, 취약점 스캔 등을 CI/CD(Continuous Integration/Continuous Delivery, 지속적인 통합/지속적인 제공) 파이프라인에 통합하여 개발 프로세스 전반에 걸쳐 자동화된 보안 검사를 수행합니다.
    • 이를 통해 개발자는 코드를 커밋할 때마다 자동으로 보안 검사를 수행하고, 문제를 신속하게 해결할 수 있습니다.
  2. 실시간 모니터링 및 알림 체계 구축:
    • 새로운 취약점 발견 시 즉시 알림을 받을 수 있는 시스템을 구축하여 신속한 대응을 지원합니다.
    • Slack, 이메일, SMS 등 다양한 채널을 통해 알림을 받을 수 있도록 설정합니다.
  3. 반복 작업 최소화:
    • 라이선스 검사, SBOM 생성, 취약점 스캔 등 반복적인 작업을 자동화하여 인적 자원을 보다 가치 있는 작업에 집중할 수 있게 합니다.
    • 스크립트 작성, API 활용, 그리고 자동화 도구 설정을 통해 반복 작업을 최소화할 수 있습니다.

표 7.2: 성공적인 ISO/IEC 18974 구현을 위한 핵심 전략

전략설명실행 단계
경영진 지원 확보보안 투자 필요성 강조, 전사적 인식 제고ROI 제시, 정기적인 현황 보고
단계적 접근우선순위 기반 점진적 구현고위험 영역부터 시작, 빠른 성과 창출
자동화 도구 활용CI/CD 파이프라인 통합, 실시간 모니터링반복 작업 최소화, 빠른 대응 체계 구축

성공적인 구현을 위해서는 경영진의 적극적인 지원, 단계적 접근 방식, 그리고 자동화 도구 활용이 필수적입니다.

2.8 - 8. 결론 및 향후 전망

8.1 ISO/IEC 18974 도입의 전략적 중요성

ISO/IEC 18974는 오픈소스 소프트웨어 보안 보증을 위한 국제 표준으로서, 현대 소프트웨어 개발 환경에서 그 중요성이 더욱 부각되고 있습니다. 이 섹션에서는 ISO/IEC 18974 도입의 전략적 중요성을 재확인하고, 이를 통해 얻을 수 있는 구체적인 이점을 살펴보겠습니다.

8.1.1 오픈소스 보안 관리의 글로벌 표준으로서의 역할

ISO/IEC 18974는 오픈소스 소프트웨어의 보안을 체계적으로 관리할 수 있는 프레임워크를 제공합니다. 이는 글로벌 차원에서 일관된 보안 관리 방식을 촉진하며, 다음과 같은 이점을 제공합니다:

  1. 국제적 신뢰성 확보: ISO/IEC 18974 인증을 통해 조직의 오픈소스 보안 관리 능력을 국제적으로 인정받을 수 있습니다.
  2. 글로벌 협업 촉진: 표준화된 프레임워크를 통해 국제적인 협업과 정보 공유가 용이해집니다.
  3. 규제 준수 용이성: 다양한 국가 및 산업의 규제 요구사항을 충족하는 데 도움이 됩니다.

8.1.2 소프트웨어 공급망 보안 강화

오픈소스 컴포넌트의 광범위한 사용으로 인해 소프트웨어 공급망 보안이 중요해졌습니다. ISO/IEC 18974는 이러한 공급망 전반의 보안을 강화하는 데 기여합니다:

  1. SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) 관리: SBOM을 통해 사용 중인 모든 오픈소스 컴포넌트를 투명하게 관리할 수 있습니다.
  2. 취약점 관리 프로세스 개선: 체계적인 취약점 스캐닝 및 패치 관리 프로세스를 구축할 수 있습니다.
  3. 공급업체 관리: 공급업체의 오픈소스 보안 관리 수준을 평가하고 개선할 수 있는 기준을 제공합니다.

8.1.3 디지털 전환 시대의 필수 요소

디지털 전환이 가속화되면서 오픈소스 사용이 증가하고 있습니다. ISO/IEC 18974는 이러한 디지털 혁신을 안전하게 추진할 수 있는 기반을 제공합니다:

  1. 혁신과 보안의 균형: 오픈소스를 활용한 빠른 혁신과 동시에 보안을 확보할 수 있습니다.
  2. 클라우드 네이티브 환경 대응: 컨테이너, 마이크로서비스 등 현대적인 아키텍처에서의 오픈소스 보안을 관리할 수 있습니다.
  3. DevSecOps 지원: 개발, 보안, 운영을 통합하는 DevSecOps 문화를 촉진합니다.

표 8.1: ISO/IEC 18974 도입의 주요 이점

영역이점구체적인 예시
비즈니스고객 신뢰도 향상보안 인증을 통한 신규 고객 유치 20% 증가
기술취약점 대응 시간 단축평균 패치 적용 시간 48시간에서 24시간으로 단축
법률규제 준수 비용 절감컴플라이언스 관련 법적 비용 30% 감소
운영개발 생산성 향상보안 관련 이슈로 인한 개발 지연 40% 감소

이 표는 ISO/IEC 18974 도입을 통해 얻을 수 있는 주요 이점을 영역별로 정리하고, 구체적인 예시를 제시합니다.

ISO/IEC 18974의 도입은 단순한 보안 강화를 넘어 조직의 전략적 경쟁력을 높이는 핵심 요소가 될 것입니다. 다음 섹션에서는 이러한 표준의 중요성을 바탕으로 향후 전망과 대비 방안을 살펴보겠습니다.

8.2 ISO/IEC 18974 도입의 주요 이점 요약

ISO/IEC 18974 구현을 통해 조직이 얻을 수 있는 주요 이점을 구체적인 사례와 함께 요약하여 제시합니다.

8.2.1 체계적인 오픈소스 보안 관리 체계 구축

  1. 일관된 보안 정책 및 프로세스 확립: 조직 전체에 적용되는 오픈소스 보안 정책을 수립하고, 이를 준수하기 위한 표준화된 프로세스를 구축합니다.
    • 예: 모든 개발팀이 동일한 오픈소스 사용 승인 절차를 따르고, 동일한 보안 도구를 사용하도록 정책화합니다.
  2. 오픈소스 컴포넌트의 체계적인 식별, 추적, 제어: SBOM(Software Bill of Materials, 소프트웨어 자재 명세서)을 활용하여 조직 내에서 사용되는 모든 오픈소스 컴포넌트를 식별하고 추적하며, 보안 취약점 및 라이선스 정보를 관리합니다.
    • 예: SBOM 관리 시스템을 구축하여 오픈소스 컴포넌트의 버전, 라이선스, 취약점 정보를 실시간으로 파악하고 관리합니다.
  3. SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) 관리를 통한 투명성 확보: SBOM을 생성하고 공유함으로써 소프트웨어 구성 요소에 대한 투명성을 확보하고, 공급망 내 위험을 관리합니다.
    • 예: 고객 또는 파트너에게 SBOM을 제공하여 소프트웨어 구성 요소에 대한 신뢰를 높이고, 보안 관련 문의에 신속하게 대응합니다.

8.2.2 고객 신뢰도 향상 및 비즈니스 경쟁력 강화

  1. 보안 인증을 통한 고객 신뢰 확보: ISO/IEC 18974 인증 획득을 통해 조직의 오픈소스 보안 관리 역량을 대외적으로 입증하고, 고객의 신뢰를 얻습니다.
    • 예: ISO/IEC 18974 인증 획득 사실을 홍보하여 신규 고객을 유치하고, 기존 고객과의 관계를 강화합니다.
  2. 공급망 내 신뢰성 향상으로 비즈니스 기회 확대: ISO/IEC 18974 준수를 통해 공급망 내 파트너들과의 신뢰를 구축하고, 새로운 비즈니스 기회를 창출합니다.
    • 예: 정부 또는 공공 기관의 프로젝트 입찰 시 ISO/IEC 18974 인증을 획득한 기업에 가점을 부여하는 경우, 경쟁 우위를 확보합니다.
  3. 보안 사고 예방을 통한 기업 평판 보호: 오픈소스 보안 취약점을 사전에 관리하고, 보안 사고 발생 가능성을 줄임으로써 기업의 평판을 보호합니다.
    • 예: 심각한 보안 취약점으로 인한 데이터 유출 사고 발생 시 기업 이미지 손상 및 법적 책임 발생 가능성을 최소화합니다.

8.2.3 보안 리스크 감소 및 사전 예방적 접근

  1. 취약점의 조기 발견 및 대응으로 보안 사고 예방: 자동화된 취약점 스캐닝 도구를 활용하여 오픈소스 컴포넌트의 알려진 취약점을 신속하게 식별하고, 패치를 적용하거나 완화 조치를 취합니다.
    • 예: 새로운 취약점이 공개되면 24시간 이내에 해당 취약점에 영향을 받는 시스템을 식별하고, 패치를 적용합니다.
  2. 지속적인 모니터링을 통한 새로운 위협에 대한 신속한 대응: 최신 보안 위협 정보를 수집하고 분석하여 새로운 위협에 대한 대응 체계를 구축합니다.
    • 예: 위협 인텔리전스 플랫폼을 구독하고, 새로운 취약점 정보가 공개되면 즉시 관련 팀에 알림을 전송합니다.
  3. 보안 비용의 효율적 관리: 사전 예방적인 보안 활동을 통해 보안 사고 발생 가능성을 줄이고, 사고 발생 시 복구 비용을 절감합니다.
    • 예: 보안 사고 발생 시 시스템 복구, 법적 대응, 그리고 고객 보상 등에 소요되는 비용을 절감합니다.

8.2.4 법적 책임 감소 및 규제 준수

  1. 오픈소스 라이선스 준수를 통한 법적 리스크 감소: 오픈소스 컴포넌트의 라이선스 조건을 준수하고, 저작권 침해 및 특허 침해 등의 법적 분쟁 발생 가능성을 최소화합니다.
    • 예: GPL(GNU General Public License) 라이선스를 사용하는 경우, 소스 코드 공개 의무를 준수하고, 관련 고지 사항을 명확하게 표시합니다.
  2. GDPR(General Data Protection Regulation, 일반 데이터 보호 규칙), CCPA(California Consumer Privacy Act, 캘리포니아 소비자 개인 정보 보호법) 등 데이터 보호 규정 준수 지원: ISO/IEC 18974를 통해 개인정보보호 규정을 준수하고, 데이터 유출 사고 발생 시 법적 책임을 줄일 수 있습니다.
    • 예: 개인정보를 처리하는 오픈소스 컴포넌트 사용 시 데이터 암호화 및 접근 제어 조치를 강화합니다.
  3. 산업별 규제 요구사항 충족: 금융, 의료 등 특정 산업에 적용되는 규제 (예: PCI DSS(Payment Card Industry Data Security Standard, 지불 카드 산업 데이터 보안 표준), HIPAA(Health Insurance Portability and Accountability Act, 건강 보험 이동성 및 책임에 관한 법률)) 준수를 지원합니다.
    • 예: 금융 회사의 경우 금융 보안 규정을 준수하기 위해 추가적인 보안 요구사항을 정책에 반영합니다.

표 8.2: ISO/IEC 18974 도입의 주요 이점 요약

이점설명기대 효과
체계적인 보안 관리일관된 정책, SBOM 관리, 취약점 대응오픈소스 컴포넌트 가시성 확보, 위험 감소
고객 신뢰도 향상인증 획득, 공급망 신뢰도 향상브랜드 이미지 개선, 경쟁 우위 확보
리스크 감소사전 예방적 접근, 위협 정보 활용보안 사고 발생률 감소, 비용 절감
법적 책임 감소라이선스 준수, 규제 대응법적 분쟁 예방, 컴플라이언스 비용 절감

이 표는 ISO/IEC 18974 도입을 통해 얻을 수 있는 주요 이점을 요약하여 보여줍니다. 조직은 이러한 이점을 바탕으로 ISO/IEC 18974 도입의 타당성을 평가하고, 구현 계획을 수립할 수 있습니다.

8.3 ISO/IEC 18974의 향후 전망 및 조직의 대비

오픈소스 보안의 중요성이 지속적으로 증가함에 따라 ISO/IEC 18974 표준의 역할과 중요성 또한 더욱 확대될 것으로 예상됩니다. 조직은 이러한 변화에 대비하여 오픈소스 보안 관리 체계를 강화하고, 미래 경쟁력을 확보해야 합니다.

8.3.1 오픈소스 사용 증가에 따른 표준의 중요성 확대

클라우드 네이티브 기술, 인공지능, 머신러닝 등 첨단 기술 분야에서 오픈소스 소프트웨어의 활용이 급증하고 있습니다. 이러한 추세에 따라 ISO/IEC 18974 표준의 적용 범위 또한 확대될 것으로 예상됩니다.

  1. 적용 범위 확대:
    • 기존의 웹 애플리케이션, 모바일 앱, 서버 시스템뿐만 아니라, IoT(Internet of Things, 사물 인터넷) 기기, 임베디드 시스템, 그리고 AI/ML 모델 등 다양한 영역에서 ISO/IEC 18974 준수가 요구될 수 있습니다.
  2. 산업 표준화:
    • 금융, 의료, 제조 등 특정 산업 분야에서 ISO/IEC 18974를 기반으로 한 산업별 오픈소스 보안 표준이 개발될 가능성이 높습니다.
    • 조직은 이러한 산업별 표준을 미리 파악하고, 준비해야 합니다.

8.3.2 AI/ML 등 신기술 적용에 따른 표준 진화

인공지능과 머신러닝 기술은 오픈소스 보안 관리에도 큰 영향을 미칠 것으로 예상됩니다. ISO/IEC 18974 표준 또한 이러한 변화에 발맞춰 진화할 것입니다.

  1. 자동화된 취약점 분석 및 대응:
    • AI/ML 기술을 활용하여 오픈소스 컴포넌트의 취약점을 자동으로 분석하고, 대응 방안을 제시하는 기능이 표준에 포함될 수 있습니다.
    • 예: AI 기반 취약점 스캐너가 자동으로 취약점의 심각도를 평가하고, 패치 적용 우선순위를 결정합니다.
  2. 위협 예측 및 예방:
    • AI/ML 기술을 활용하여 새로운 보안 위협을 예측하고, 사전에 예방하는 기능이 표준에 추가될 수 있습니다.
    • 예: AI 기반 위협 인텔리전스 시스템이 새로운 취약점 정보를 실시간으로 수집하고, 조직에 알려줍니다.

8.3.3 글로벌 규제 환경 변화와 표준의 역할 강화

각국 정부와 국제 기구들은 소프트웨어 공급망 보안 강화를 위한 규제를 강화하고 있습니다. ISO/IEC 18974는 이러한 규제 환경 변화에 대응하는 데 중요한 역할을 수행할 것입니다.

  1. 규제 준수 도구:
    • ISO/IEC 18974 인증은 DORA(Digital Operational Resilience Act, 디지털 운영 복원력 법안), EU Cyber Resilience Act 등 새로운 규제를 준수하고 있음을 입증하는 데 활용될 수 있습니다.
  2. 국제 협력:
    • ISO/IEC 18974는 국가 간 데이터 이동과 관련된 규제가 강화됨에 따라 국제 표준으로서의 중요성이 더욱 증가할 것입니다.
    • 조직은 ISO/IEC 18974 준수를 통해 글로벌 시장에서 경쟁력을 확보할 수 있습니다.

8.3.4 보안 위협의 고도화 및 지능화에 따른 대응 전략 필요

사이버 공격은 점점 더 고도화되고 지능화되고 있으며, 오픈소스 컴포넌트를 표적으로 하는 공격 또한 증가하고 있습니다. 조직은 이러한 위협에 대응하기 위해 ISO/IEC 18974를 기반으로 한 강력한 보안 전략을 수립해야 합니다.

  1. 실시간 위협 인텔리전스:
    • 최신 위협 정보를 실시간으로 수집하고 분석하여 공격에 대한 조기 경보 체계를 구축합니다.
  2. 자동화된 대응 메커니즘:
    • 사고 발생 시 자동으로 대응 조치를 실행하는 체계를 구축하여 피해를 최소화합니다.
  3. 침해 사고 대응 훈련 강화:
    • 정기적인 침해 사고 대응 훈련을 통해 조직 구성원들의 대응 역량을 강화합니다.

표 8.3: ISO/IEC 18974의 향후 전망 및 조직의 대비

전망조직의 대비
오픈소스 사용 증가ISO/IEC 18974 적용 범위 확대, 인력 및 예산 확보
AI/ML 기술 적용자동화된 보안 도구 도입, AI/ML 전문가 양성
규제 환경 변화관련 법규 및 규제 학습, 컴플라이언스 체계 구축
위협 고도화위협 인텔리전스 활용, 자동화된 대응 체계 구축

8.4 조직을 위한 권장 사항

ISO/IEC 18974를 효과적으로 구현하고, 오픈소스 보안을 지속적으로 강화하기 위해 조직이 고려해야 할 구체적인 권장 사항을 제시합니다.

  1. 선제적인 ISO/IEC 18974 도입 검토
    • 조직 규모 및 특성 분석: 조직의 규모, 산업, 기술 스택, 그리고 비즈니스 목표를 고려하여 ISO/IEC 18974 도입 여부를 신중하게 검토합니다.
    • 단계적 접근 방식: 한 번에 모든 요구사항을 구현하기보다는, 우선순위를 정하고 단계적으로 구현하는 것이 효과적일 수 있습니다. 초기 단계에서는 핵심적인 보안 정책 수립, SBOM(Software Bill of Materials, 소프트웨어 자재 명세서) 구축, 그리고 취약점 스캐닝 프로세스 구축에 집중합니다.
    • 자원 확보: ISO/IEC 18974 구현에 필요한 예산, 인력, 그리고 도구를 확보합니다. 필요하다면 외부 전문가의 도움을 받는 것도 고려합니다.
  2. 지속적인 개선 및 최신 동향 모니터링
    • 정기적인 내부 감사: 내부 감사 프로그램을 운영하여 ISO/IEC 18974 준수 여부를 정기적으로 점검하고, 개선이 필요한 부분을 식별합니다.
    • 외부 평가 활용: 외부 보안 전문가 또는 인증 기관으로부터 오픈소스 보안 관리 체계를 평가받고, 개선 방향에 대한 조언을 구합니다.
    • 최신 정보 습득: 오픈소스 보안 관련 최신 동향을 지속적으로 파악하고, 새로운 위협에 대한 대응 방안을 마련합니다.
      • OpenChain Project 웹사이트, 보안 관련 뉴스레터, 컨퍼런스 등을 활용합니다.
  3. 오픈소스 생태계 참여 및 기여 확대
    • 커뮤니티 참여: 오픈소스 프로젝트에 참여하고, 코드 기여, 버그 보고, 그리고 문서 작성 등을 통해 오픈소스 커뮤니티에 기여합니다.
    • 정보 공유: 오픈소스 보안 관련 경험, 지식, 그리고 도구를 조직 내외부와 공유합니다.
    • 협력: 다른 조직, 연구 기관, 그리고 정부 기관과 협력하여 오픈소스 보안 강화를 위한 공동 연구 및 개발을 추진합니다.
  4. 전문가 양성 및 협력 네트워크 구축
    • 사내 전문가 양성: 오픈소스 보안 전문가를 양성하기 위한 교육 프로그램을 개발하고, 직원들의 참여를 장려합니다.
    • 자격증 취득 지원: SANS, ISC2 등 보안 관련 자격증 취득을 지원하여 직원들의 전문성을 향상시킵니다.
    • 외부 네트워크 활용: 오픈소스 보안 전문가, 컨설턴트, 그리고 벤더와의 협력 네트워크를 구축합니다.

표 8.4: ISO/IEC 18974 구현을 위한 구체적인 권장 사항

권장 사항세부 내용실행 예시
선제적인 도입 검토조직 규모, 특성 분석, 단계적 접근 방식- 1단계: 핵심 정책 수립, SBOM 구축
- 2단계: 자동화 도구 도입, 교육 프로그램 운영
지속적인 개선내부 감사, 외부 평가, 최신 동향 파악- 분기별 내부 감사 실시
- 연간 외부 평가 진행
생태계 참여오픈소스 프로젝트 참여, 정보 공유- GitHub 프로젝트에 코드 기여
- 사내 블로그에 보안 관련 글 게시
전문가 양성교육 프로그램 개발, 자격증 취득 지원- 사내 보안 전문가 양성 프로그램 운영
- CISSP 자격증 취득 지원

3 - 기업 오픈소스SW 거버넌스 - OpenChain 해설서

오픈소스 컴플라이언스의 국제 표준인 OpenChain 규격을 준수하기 위한 가이드를 제공합니다.

정보통신산업진흥원(NIPA)이 주관하고 공개SW역량프라자에서 연구를 수행하여 기업이 오픈소스 컴플라이언스의 국제 표준인 OpenChain 규격을 준수하기 위해 필요한 사항들을 설명하는 해설서를 가이드 형태로 제작하였습니다. : 기업 공개SW 거버넌스 OpenChain 2.0 해설

기업 공개SW 거버넌스 Openchain 2.0 해설

여기서는 NIPA의 허락 하에 가이드 내용을 GitHub에 공개하고, 누구나 내용을 참고하고, 수정 / 개선할 수 있게 하였습니다. : GitHub Repository

References

이 가이드는 다음 자료를 참고하여 작성하였습니다.

3.1 - I. OpenChain 프로젝트란?

ISO 국제 표준에 기반하여 기업이 오픈소스를 효과적으로 관리하기 위한 방안을 소개합니다.

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

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

[OpenChain Open Source Software License Compliance General Public Guide]

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

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

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

[OpenChain Project Logo]

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

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

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

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

3.1.1 - 1. OpenChain 표준

ISO/IEC 5230

OpenChain 프로젝트는 2016년 OpenChain 규격 1.0을 제작하여 배포했다. OpenChain 규격은 오픈소스 컴플라이언스를 위한 핵심 요구사항을 정의한 12페이지 분량의 규격으로, 기업의 규모나 업종과 관계없이 모든 분야의 회사에 적합하도록 고안되었다. 2020년 12월 Openchain 규격 2.1은 ISO/IEC 5230 국제표준으로 등록되었다.

ISO/IEC 5230은 기업이 오픈소스 컴플라이언스 달성을 위해 꼭 수행해야 할 여섯 가지 주요 요구사항과 이를 입증하기 위해 필요한 자료 목록을 정의하고 있다.

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

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

< https://standards.iso.org/ittf/PubliclyAvailableStandards/c081039_ISO_IEC_5230_2020(E).zip >

ISO/IEC 18974

OpenChain 프로젝트는 ISO/IEC 5230에 이어 오픈소스 보안 보증을 위한 규격을 제작하였다. 이 규격은 2023년 말 ISO/IEC 18974로 등록되었다. : https://www.iso.org/standard/86450.html

이들 두 표준 내 각 요구사항의 준수 방법은 “3장. OpenChain 표준 준수 방법”에서 상세히 다룬다.

3.1.2 - 2. OpenChain 인증

OpenChain 규격에서의 요구 사항을 모두 준수한다면 OpenChain 적합한 오픈소스 프로그램을 보유했음을 인증받을 수 있다. 오픈소스 프로그램이란 정책, 프로세스, 인원 등 기업이 오픈소스 컴플라이언스 활동을 수행하기 위한 일련의 관리 체계를 의미한다. 이 장에서는 인증 방법과 적합성 선언에 관해 설명한다.

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

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

각각의 방법을 알아보자.

자체 인증

자체 인증은 OpenChain 프로젝트에서 제일 권장하는 방법이며, 비용이 발생하지 않는다는 장점이 있다. OpenChain 프로젝트는 기업이 자체적으로 OpenChain 규격을 충족하는지 확인할 수 있도록 온라인 자체 인증 웹사이트를 제공한다.

< https://www.openchainproject.org/checklist-iso-5230-2020 >

기업의 오픈소스 담당자는 OpenChain 자체 인증 웹사이트에 가입해 온라인 자체 인증을 시작할 수 있다.

< https://www.openchainproject.org/checklist-iso-5230-2020 >

기업은 자체 인증을 통해 부족한 부분이 무엇인지, 추가로 필요한 활동이 무엇인지 판단할 수 있다.

만약, 어떤 기업이 오픈소스 컴플라이언스 체계를 잘 구축하여 OpenChain 자체 인증 질문지의 모든 항목을 Yes로 대답할 수 있다면 이 결과를 웹사이트상에 제출할 수 있다(Conforming Submission). 그렇게 OpenChain 적합성 선언을 하게 되면, OpenChain 적합(Conformant) 프로그램을 가진 기업으로 인정됨과 동시에, OpenChain 프로젝트의 웹사이트에 기업의 로고를 등록할 수 있게 된다.

< https://www.openchainproject.org/community-of-conformance >

OpenChain 적합 기업에는 OpenChain 로고를 사용할 수 있는 자격이 주어진다. 이렇게 OpenChain 적합 프로그램을 갖췄다고 인정받은 기업은 소프트웨어 공급망 내에서 오픈소스 컴플라이언스를 충실하게 수행하고 있음을 보여줄 수 있게 된다.

< https://www.openchainproject.org/conformance-submission >

타사 인증

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

OpenChain의 공인 타사 인증 기관은 ORCRO1, PWC2, TÜV SÜD3 등이 있다.

< Third-Party Certifiers, 출처 - https://www.openchainproject.org/partners >

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

< PWC certification, 출처 - https://youtu.be/HslvXCM-4pQ >

유럽의 자동차 업계에서는 ISO/IEC 5230이 ASPICEAutomotive SPICE4 자동차 소프트웨어 개발을 위한 국제 표준 프로세스 모델)와 같이 자동차 소프트웨어 공급자에게 의무화될 날이 머지않을 것이라고 예측하는 전문가도 있다.

개별 평가 지원

개별 평가 지원은 기업 외부의 독립 기관이 공정한 관점에서 기업의 오픈소스 컴플라이언스 상태를 점검하고 평가한다. 어떤 인증서를 발급해주지는 않는다는 점이 자체 인증, 타사 인증과는 다른 점이다. 개별 평가 지원의 특징은 평가 보고서를 생성하는 것에 그치지 않고 도출된 미비점을 보완하기 위한 컨설팅을 제공한다.

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

< Independent Compliance Assessment, 출처 - https://youtu.be/DEBd-g0Ab8E >

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

개별 평가 지원을 제공하는 업체는 AlektoMetis5, Source Code Control6 등이 있다.

국내에서는 이와 유사한 프로그램을 NIPA의 오픈업7에서 국내 기업 대상으로 공개소프트웨어 활용지원 프로그램8을 통해 무료로 제공한다.

< OpenUp 주요 업무, 출처 - https://www.oss.kr/open_up_task >


  1. ORCRO- https://orcro.co.uk/ ↩︎

  2. PWC - https://www.pwc.de/en/opensource ↩︎

  3. TÜV SÜD - https://www.tuvsud.com ↩︎

  4. ASPICE : 자동차 소프트웨어 개발을 위한 국제 표준 프로세스 모델 - http://www.automotivespice.com ↩︎

  5. AlektoMetis - https://alektometis.com/↩︎

  6. Source Code Control - https://sourcecodecontrol.co/ ↩︎

  7. 오픈업 - https://www.oss.kr/open_up_intro ↩︎

  8. 공개소프트웨어 활용 지원 프로그램 - https://www.oss.kr/news/show/49e410fb-604d-4d35-ba25-8286b5f2c50d ↩︎

3.1.3 - 3. OpenChain 리소스

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

< https://www.openchainproject.org/resources >

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

2장에서는 두 OpenChain 표준의 각 요구사항을 어떻게 준수해야 할지에 대해 세부적으로 설명한다.

3.2 - II. OpenChain ISO 표준 준수 방법

기업 오픈소스 관리를 위한 두개의 ISO 표준은 ISO/IEC 5230과 ISO/IEC 18974이다. 이 두 표준을 모두 준수함을 선언한 기업은 소프트웨어 솔루션을 배포하는 공급망 내에서 신뢰를 제공할 수 있게 된다.

ISO/IEC 5230과 ISO/IEC 18974는 유사한 포맷의 표준으로 공통 요구사항을 다수 포함한다. 아래 표는 두 표준의 요구사항 중 공통 사항과 차이점을 보여준다.

  • 파란색 영역은 두 표준이 공통적으로 포함하는 요구사항이다.
  • 노란색 영역은 License Compliance를 위해 ISO/IEC 5230에서만 요구하는 항목이다.
  • 붉은색 영역은 Security Assurance를 위해 ISO/IEC 18974에서만 요구하는 항목이다.

여기에서는 기업이 이 두 표준을 모두 준수하기 위해 충족해야 하는 여섯 가지 주요 요구사항과 각각의 준수 방법을 세부적으로 설명한다.

3.2.1 - 1. 프로그램 설립

오픈소스를 이용하여 소프트웨어를 개발하고 배포하는 기업이라면 오픈소스를 관리하기 위한 정책과 프로세스를 만들고, 이를 위한 인력과 자원을 적절하게 할당해야 한다.

오픈소스 프로그램이란 정책, 프로세스, 인원 등 기업이 오픈소스 컴플라이언스 활동을 수행하기 위한 일련의 관리 체계를 의미하며, OpenChain 규격의 첫 번째 요구사항은 바로 이 오픈소스 프로그램을 설립하라는 것이다.

1.1 정책

그 첫 번째 요구사항으로 문서화된 오픈소스 정책이 있어야 한다. ISO/IEC 5230과 ISO/IEC 18984 표준에의 3.1.1항에서는 다음과 같이 정책에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230


3.1.1 Policy

배포용 소프트웨어의 오픈소스 라이선스 컴플라이언스를 관리하는 문서화된 오픈소스 정책이 있어야 한다. 이 정책은 조직 내부에 전파되어야 한다.

입증 자료:

3.1.1.1 문서화된 오픈소스 정책
3.1.1.2 프로그램 참여자가 오픈소스 정책의 존재를 알 수 있게 하는 문서화된 절차 (교육, 내부 위키, 혹은 기타 실질적인 전달 방법 등)


3.1.1 Policy

A written open source policy shall exist that governs open source license compliance of the supplied software. The policy shall be internally communicated.

Verification Material(s):

3.1.1.1 A documented open source policy.
3.1.1.2 A documented procedure that makes program participants aware of the existence of the open source policy (e.g., via training, internal wiki, or other practical communication method).

ISO/IEC 18974


3.1.1 정책

배포용 소프트웨어의 오픈소스 소프트웨어 보안 보증을 관리하는 문서화된 오픈소스 정책이 있어야 한다. 이 정책은 조직 내부에 전파되어야 한다. 정책과 전파 방법은 항상 유효하고 최신 상태를 유지하기 위한 검토 프로세스를 가져야 한다.

입증 자료:

3.1.1.1: 문서화된 오픈소스 소프트웨어 보안 보증 정책
3.1.1.2: 프로그램 참가자에게 보안 보증 정책을 알리기 위한 문서화된 절차.


3.1.1 Policy

A written policy will be created that governs Open Source Software Security Assurance of Supplied Software. The policy will be internally communicated. The policy and its method of communication will have a review process to ensure they are current and relevant.

Verification Material(s):

3.1.1.1: A documented Open Source Software Security Assurance policy;
3.1.1.2: A documented procedure to make Program Participants aware of the Security Assurance policy.

1.1.1 문서화된 정책

먼저 오픈소스 정책을 수립하고 문서화해야 한다. 오픈소스 정책은 다음을 포함한다.

  • 기업이 오픈소스를 사용하여 소프트웨어 제품과 서비스를 만들어서 배포하기 위한 정책
  • 외부 오픈소스 커뮤니티에 기여하기 위한 정책
  • 기업의 소프트웨어를 오픈소스로 공개하기 위한 정책

이 안내서에서는 참고를 위해 ISO/IEC 5230, ISO/IEC 18974 두 표준의 요구사항을 충족하는 샘플 오픈소스 정책 문서를 “[부록 1] 오픈소스 정책”에서 제공한다.

1.1.2 정책을 알리는 절차

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

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

이에 대한 예시는 [부록 1] 오픈소스 정책의 5. 교육 및 평가를 참고할 수 있다.

5. 교육 및 평가

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

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

1.2 역량

이 장은 프로그램 참여자가 갖추어야 할 역량에 대한 요구사항을 정의한다. ISO/IEC 5230과 ISO/IEC 18974 표준의 3.1.2항에서는 다음과 같이 역량에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230


3.1.2 역량

조직은 다음 사항을 수행해야 한다:

  • 프로그램의 성과와 효율에 영향을 미치는 역할이 무엇인지, 그 역할에 해당하는 책임은 무엇인지 확인한다.
  • 각 역할을 수행할 프로그램 참여자가 갖춰야 할 필요 역량을 결정한다.
  • 프로그램 참여자가 적절한 교육, 훈련 및/또는 경험을 바탕으로 자격을 갖춘 자임을 확인한다.
  • 해당되는 경우, 필요한 역량을 확보하기 위해 조치한다.
  • 역량 보유를 증명하기 위한 정보를 문서화하여 유지한다.

입증 자료:

3.1.2.1 프로그램의 여러 참여자에 대한 역할과 각 역할의 책임을 나열한 문서
3.1.2.2 각 역할을 위해 필요한 역량을 기술한 문서
3.1.2.3 각 프로그램 참여자의 역량을 평가한 문서화된 증거


3.1.2 Competence

The organization shall:

  • Identify the roles and the corresponding responsibilities of those roles that affects the performance and effectiveness of the program;
  • Determine the necessary competence of program participants fulfilling each role
  • Ensure that program participants are competent on the basis of appropriate education, training, and/or experience;
  • Where applicable, take actions to acquire the necessary competence; and
  • Retain appropriate documented information as evidence of competence.

Verification Material(s):

3.1.2.1 A documented list of roles with corresponding responsibilities for the different participants in the program.
3.1.2.2 A document that identifies the competencies for each role.
3.1.2.3 Documented evidence of assessed competence for each program participant.

ISO/IEC 18974


3.1.2 역량

조직은 다음 사항을 수행해야 한다:

  • 프로그램의 성과와 효율에 영향을 미치는 역할과 책임을 식별한다.
  • 각 역할을 수행하는 프로그램 참여자가 갖춰야 할 필요 역량을 결정한다.
  • 프로그램 참여자가 적절한 교육, 훈련 및/또는 경험을 가지고 있는지 확인한다.
  • 해당하는 경우, 프로그램 참여자가 필요한 역량을 확보하기 위한 조치를 취하도록 보장한다.
  • 프로그램에서 누가 현재 참여자인지 뿐만 아니라 역량 보유를 증명하기 위한 정보를 적절하게 문서화하여 유지한다.

입증 자료:

3.1.2.1: 여러 프로그램 참여자에 대한 각각의 책임을 나열한 문서
3.1.2.2: 각 역할을 위해 필요한 역량을 기술한 문서
3.1.2.3: 참여자 명단과 그들의 역할
3.1.2.4: 각 프로그램 참여자의 역량을 평가한 문서화된 증거
3.1.2.5: 프로세스를 주기적으로 검토하고 개선했음을 나타내는 문서화된 증거
3.1.2.6: 이러한 프로세스는 회사 내부 모범 사례를 반영하여 항상 현행화되어야 하고, 이를 누가 책임지고 수행해야 하는지를 명시한 문서화된 증거


3.1.2 Competence

The organization shall:

  • Identify the roles and responsibilities that impact the performance and effectiveness of the Program;
  • Determine the necessary competence of Program Participants fulfilling each role;
  • Ensure that Program Participants have appropriate education, training, and/or experience;
  • Where applicable, ensure Program Participants take actions to acquire the necessary competence;
  • Retain appropriate documented information as evidence of competence as well as who is currently a participant in the program.

Verification Material(s):

3.1.2.1: A documented list of roles with corresponding responsibilities for the different Program Participants;
3.1.2.2: A document that identifies the competencies for each role; 3.1.2.3: List of participants and their roles;
3.1.2.4: Documented evidence of assessed competence for each Program Participant;
3.1.2.5: Documented Evidence of periodic reviews and changes made to the process;
3.1.2.6: Documented verification that these processes are current with company internal best practices and who is assigned to accomplish them.

1.2.1 역할과 책임

오픈소스 프로그램이 효율적이고 성과를 내기 위해서 필요한 역할이 무엇인지와 그 역할이 담당해야 할 책임을 정의해야 한다. 오픈소스 프로그램에 필요한 일반적인 역할은 다음과 같다.

  • 오픈소스 프로그램 매니저
  • 법무 담당
  • 인프라 담당
  • 보안 담당
  • 개발 문화 담당
  • 품질 담당
  • 소프트웨어 개발부서
  • OSPO1
  • OSRB2

위의 모든 역할을 처음부터 구성해야 하는 것은 아니다. 처음 시작하는 기업이라면 오픈소스 프로그램 매니저 역할을 하는 인원 한 명으로 시작할 수도 있다.

각 역할에 대한 일반적인 책임을 명시한 문서를 [부록 1] 오픈소스 정책의 4. 역할, 책임 및 역량에서 제공한다.

1.2.2 역량

각 역할과 그에 대한 책임을 정의하였으면, 그 역할을 수행할 인원이 갖춰야 할 필요 역량이 무엇인지 정의해야 한다. 이 부분도 마찬가지로 [부록 1] 오픈소스 정책의 4. 역할, 책임 및 역량에 포함하였으니 참고하기 바란다.

1.2.3 평가

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

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

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

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

4. 역할, 책임 및 역량

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

각 역할의 담당 조직/담당자와 필요 역량 수준은 "Appendix 1. 담당자 현황"에서 정의한다. 

5. 교육 및 평가

4장에서 정의한 각 역할을 담당하는 모든 구성원은 [Learning Portal]에서 제공하는 오픈소스 교육을 수강해야 한다. 

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

1.2.4 프로세스 현행화

기업은 프로세스가 효과적인지 주기적으로 검토하여 개선하고, 이에 대한 근거를 문서화하여야 한다. 따라서, 프로세스 문서 상에 아래와 같은 내용을 포함할 수 있다.

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

1.3 인식

다음으로 ISO/IEC 5230과 ISO/IEC 18974 표준의 3.1.3항에서는 다음과 같이 인식에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230


3.1.3 인식

조직은 프로그램 참여자가 다음 사항을 인식하도록 보장해야 한다:

  • 오픈소스 정책
  • 오픈소스 관련 목표
  • 효과적인 프로그램이 되기 위한 참여자의 기여 방법
  • 프로그램 요구사항을 준수하지 않을 경우 미치는 영향

입증 자료:

3.1.3.1 다음 사항에 대한 프로그램 참여자의 인식을 평가하였음을 나타내는 문서화된 증거 : 프로그램의 목표, 프로그램 내에서의 참여자 기여 방법 및 프로그램을 준수하지 않을 경우 미치는 영향


3.1.3 Awareness

The organization shall ensure that the program participants are aware of:

  • The open source policy;
  • Relevant open source objectives;
  • Their contribution to the effectiveness of the program; and
  • The implications of not following the Program’s requirements.

Verification material(s):

  • 3.1.3.1 Documented evidence of assessed awareness for the program participants - which should include the program’s objectives, one’s contribution within the program, and implications of program non-conformance.

ISO/IEC 18974


3.1.3 인식

조직은 프로그램 참여자가 다음 사항을 인식하도록 보장한다.:

  • 오픈소스 소프트웨어 보안 보증 정책
  • 오픈소스 관련 목표
  • 효과적인 프로그램이 되기 위한 참여자의 기여 방법
  • 프로그램 요구사항을 준수하지 않을 경우 미치는 영향

입증 자료:

3.1.3.1: 다음 사항에 대한 프로그램 참여자의 인식을 평가하였음을 나타내는 문서화된 증거 : 프로그램의 목표, 프로그램 내에서의 참여자 기여 방법 및 프로그램을 준수하지 않을 경우 미치는 영향.


3.1.3 Awareness

The organization will ensure that the Program Participants are aware of:

  • The Open Source Software Security Assurance policy;
  • Relevant Program objectives;
  • Their contribution to the effectiveness of the Program;
  • The implications of not following the Program’s requirements.

Verification Material(s):

3.1.3.1: Documented Evidence of assessed awareness for the Program Participants - which should include the Program’s objectives, one’s contribution within the Program, and implications of Program non-conformance.

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

이를 위한 아래의 예와 같은 내용을 기업의 오픈소스 정책에 포함할 수 있다.

1. 목적

(1) 정책의 목적

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

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

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

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

(2) 미준수 시 영향

이 정책을 준수하지 않는다면 다음과 같은 상황이 발생할 수 있습니다.

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

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

(3) 구성원의 기여 방법

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

또, 프로그램 참여자가 오픈소스 정책을 인식하게 하기 위한 교육과 평가 방침도 수립해야 한다. 이에 대한 예시를 [부록 1] 오픈소스 정책의 5. 교육 및 평가에서 제공한다.

1.4 프로그램 범위

오픈소스 프로그램을 기업 내 어느 조직 혹은 어느 제품에 적용할지를 결정해야 하며 이를 위한 절차가 필요하다. ISO/IEC 5230과 ISO/IEC 18974 표준에서는 다음과 같이 프로그램의 적용 범위에 대한 요구사항과 입증 자료를 정의한다.

ISO/IEC 5230


3.1.4 프로그램 적용 범위

프로그램은 다양한 범위별로 적용하여 관리할 수 있다. 예를 들어, 한 프로그램을 단일 제품군에만 적용할 수도 있고, 전체 부서 또는 전체 조직에 적용하여 관리할 수 있다. 따라서 각 프로그램에서는 적용 범위를 정확히 명시해야 한다.

입증 자료:

  • 3.1.4.1 프로그램의 적용 범위와 한계를 명확하게 정의한 문서화된 진술

3.1.4 Program scope

Different programs may be governed by different levels of scope. For example, a program could govern a single product line, an entire department or an entire organization. The scope designation needs to be declared for each program.

Verification material(s):

  • 3.1.4.1 A written statement that clearly defines the scope and limits of the program.

ISO/IEC 18974


3.1.4 프로그램 적용 범위

프로그램은 전체 조직의 위험 관리 정책과 일치하는 기본 원칙과 범위를 정의해야 한다. 프로그램의 적용 범위가 특정 제품 라인인지, 하나의 부서인지 혹은 전체 조직인지 여부가 명확해야 한다. 또한 이 범위는 시간이 지남에 따라 변경될 수 있으며 지속적인 효과를 평가하기 위한 측정 기준이 사용될 수 있음을 이해해야 한다.

입증 자료:

3.1.4.1: 프로그램의 적용 범위와 한계를 명확하게 정의한 문서화된 진술
3.1.4.2: 프로그램 개선을 위해 달성해야 하는 일련의 측정 기준
3.1.4.3: 지속적인 개선을 위해 검토, 업데이트 또는 검사를 수행했음을 입증하는 문서화된 증거


3.1.4 Program scope

A Program should have defined guiding principles and scope that match the risk management policy of the entire organization. It should be clear whether the Program applies to a product line, a department, or the entire organization. It should also be understood that this scope may change over time and metrics may be used to assess its ongoing effectiveness.

Verification Material(s):

3.1.4.1: A written statement that clearly defines the scope and limits of the Program;
3.1.4.2: A set of metrics the program shall achieve to improve;
3.1.4.3: Documented Evidence from each review, update, or audit to demonstrate continuous improvement.

1.4.1 적용 범위와 한계 문서화

하나의 오픈소스 프로그램을 반드시 기업 전체에 적용해야 하는 것은 아니다. 기업 내 각 조직과 제품의 특성에 따라 적용 범위를 달리 지정할 수 있다. 조직별로, 제품별로 다른 오픈소스 프로그램을 적용할 수 있다. 마찬가지로, 소프트웨어를 전혀 배포하지 않는 조직이라면 오픈소스 프로그램의 적용 범위에서 제외할 수 있다. 기업은 조직과 제품의 특성을 고려하여 오픈소스 프로그램의 적용 범위와 한계를 명확히 정의하고, 이를 오픈소스 정책에 명시할 수 있다.

이를 위하여 다음의 예와 같은 내용을 오픈소스 정책에 포함한다.

1. 적용 범위

이 정책은 다음 세 부분에 적용됩니다.

1. 회사가 외부로 제공하거나 배포하는 모든 제품에 적용됩니다. 단, 오픈소스를 내부 사용 목적으로만 사용하는 것은 이 정책의 범위에 포함되지 않습니다.  
2. 구성원이 외부 오픈소스 프로젝트에 기여할 때 적용됩니다.
3. 내부 코드를 오픈소스로 공개할 때 적용됩니다.

1.4.2 적용 범위 결정 프로세스

기업의 조직과 제품 및 서비스가 비즈니스 환경에 맞추어 변화함에 따라 프로그램의 적용 범위를 결정하거나 수정해야 하는 상황이 발생할 수 있다. 가업은 이에 대응하기 위한 프로세스를 다음의 예와 같이 준비해야 한다.

  1. 오픈소스 프로그램 매니저는 새로운 프로젝트를 시작할 때 해당 프로젝트가 프로그램 적용 범위 내에 포함되는지 여부를 판단한다.
  2. 포함된다고 판단되는 경우, 해당 프로젝트를 프로그램 적용 범위에 포함 시키기 위한 제안을 OSRB2에 제출한다.
  3. OSRB에서 수락할 경우, 이에 맞게 프로그램의 적용 범위를 수정한다.
  4. 이외 오픈소스 프로그램 매니저는 프로그램 적용 범위에 대한 검토가 필요하다고 판단되는 경우, 동일한 프로세스에 따라 프로그램 적용 범위에 대한 검토를 시작할 수 있다.

이를 위하여 다음의 예와 같은 내용을 오픈소스 정책에 포함한다.

적용 범위는 회사의 비즈니스 환경에 맞추어 변경할 수 있습니다. 특히, 오픈소스 프로그램 매니저는 지속적인 효과를 보장하기 위해 이 정책의 적용되지 않고 사외로 배포 혹은 서비스되는 제품이 있는지 월 1회 이상 조사합니다. 이를 측정하여 1건이라도 발견 시 적용 범위를 변경해야 하는 기준으로 삼습니다.

적용 범위를 변경하기 위한 절차는 다음과 같습니다.

1. 오픈소스 프로그램 매니저는 신규사업, 조직개편 등 회사의 비즈니스 환경이 변화에 따라 정책의 적용 범위 변경이 필요하다고 판단할 경우, 이를 위한 제안을 OSRB에 제출합니다.
2. OSRB에서는 적절한 수준의 적용 범위 변경을 승인합니다.
3. OSRB는 오픈소스 정책을 수정하여 정책의 적용 범위를 변경합니다.

1.4.3 지속적인 개선 수행

기업은 적용 범위를 지속적으로 검토하여 개선하고, 이를 문서화하여야 한다. 이를 위하여 다음의 예와 같은 내용을 오픈소스 정책에 포함한다.


오픈소스 프로그램 매니저는 지속적으로 월 1회 이상 적용 범위를 개선하기 위해 검토, 업데이트 및 검사 이력을 Jira Issue Tracker를 활용하여 문서화합니다.

이 가이드에서는 프로그램 범위 지정에 대한 예시를 [부록 1] 오픈소스 정책의 2. 적용 범위에서 제공한다.

1.5 라이선스 의무

오픈소스를 사용하면 각 라이선스가 부과하는 의무를 준수해야 한다. ISO/IEC 5230의 3.1.5항에서는 다음과 같이 각 오픈소스 라이선스가 부과하는 의무를 알아내기 위한 검토 프로세스를 요구한다.

ISO/IEC 5230


3.1.5 라이선스 의무

각 라이선스에 의해 부과된 의무, 제한 및 권리를 알아내기 위해 식별된 라이선스를 검토하는 프로세스가 있어야 한다.

입증 자료

  • 3.1.5.1 각 식별된 라이선스에 의해 부여된 의무, 제한 및 권리를 검토하고 기록하기 위한 문서화된 절차

3.1.5 License obligations

A process shall exist for reviewing the identified licenses to determine the obligations, restrictions and rights granted by each license.

Verification material(s):

  • 3.1.5.1 A documented procedure to review and document the obligations, restrictions and rights granted by each identified license.

오픈소스의 사용 가능 여부를 판단하기 위해서는 먼저 사용하려는 오픈소스의 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무사항을 확인해야 한다. 오픈소스를 사용하였는지, 라이선스는 무엇인지, 각 라이선스가 부여하는 의무는 무엇인지 검토하고 기록해야 한다. 이를 위한 절차의 예는 다음과 같다.

  1. 오픈소스 프로그램 매니저는 오픈소스 정책에서 정의한 기준에 따라 라이선스를 예비 평가한다.
  2. 의문이 있는 경우, 오픈소스 프로그램 매니저는 외부 법률 전문가에게 자문을 요청한다.
  3. 모든 내외부의 결정 결과 및 관련 근거는 보관한다.

NIPA 산하 오픈소스 소프트웨어 통합지원센터인 오픈업에서 제공하는 “공개SW와 라이선스”(https://www.oss.kr/oss_license )에서는 주요 오픈소스 라이선스의 의무, 제한 및 권리를 설명하고 있다. 또한 SK텔레콤에서 공개한 오픈소스 가이드도 좋은 참고가 된다. : https://sktelecom.github.io/guide/use/license/

위에서 요구하는 “각 식별된 라이선스에 의해 부가된 의무, 제한 및 권리를 검토하고 기록하기 위한 문서화된 절차“는 [부록 2] 오픈소스 프로세스”의 오픈소스 식별 단계에 해당한다.

1.6 표준 사례 구현

ISO/IEC 18974의 3.1.5항에서는 다음과 같이 알려진 취약점 대응 및 강력한 보안 소프트웨어 개발을 위한 절차를 요구한다.

ISO/IEC 18974


3.1.5 표준 사례 구현

프로그램은 다음 절차를 정의하고 구현하여 알려진 취약점 및 보안 소프트웨어 개발을 건전하고 강력하게 처리하는 절차를 갖춘다.

  • 배포용 소프트웨어에 대한 구조적 및 기술적 위협을 식별하는 방법
  • 배포용 소프트웨어에서 알려진 취약점 존재 여부를 탐지하는 방법
  • 확인된 알려진 취약점에 대한 후속 조치 방법
  • 확인된 알려진 취약점을 보증 대상인 고객에게 알리는 방법
  • 배포용 소프트웨어의 릴리스 후 새롭게 알려진 취약점이 공개되었을 때 이미 배포된 소프트웨어에 존재하는지 확인하는 방법
  • 지속적이고 반복적인 보안 테스트가 출시 전에 모든 배포용 소프트웨어에 적용되기 위한 방법
  • 식별된 위험이 배포용 소프트웨어의 출시 전에 해결되었는지 확인하는 방법
  • 식별된 위험에 대한 정보를 제3자에게 적절하게 내보내는 방법

위에 나열된 보안 보증 방법에 대한 프로세스가 존재해야 한다.

입증 자료:

  • 3.1.5.1: 위에서 식별된 각 방법에 대한 문서화된 절차가 존재한다.

3.1.5 - Standard Practice Implementation

The Program demonstrates a sound and robust handling procedures of Known Vulnerabilities and Secure Software Development by defining and implementing following procedures:

  • Method to identify structural and technical threats to the Supplied Software is defined;
  • Method for detecting existence of Known Vulnerabilities in Supplied Software;
  • Method for following up on identified Known Vulnerabilities;
  • Method to communicate identified Known Vulnerabilities to customer base when warranted;
  • Method for analyzing Supplied Software for newly published Known Vulnerabilities post release of the Supplied Software;
  • Method for continuous and repeated Security Testing is applied for all Supplied Software before release;
  • Method to verify that identified risks will have been addressed before release of Supplied Software;
  • Method to export information about identified risks to third parties as appropriate.

A process shall exist for the Security Assurance methods listed above.

Verification Material(s):

  • 3.1.5.1: A documented procedure exists for each of the methods identified above.

따라서 기업은 제품/서비스를 개발하면서 오픈소스 보안 취약점을 탐지하고 해결하는 등 보안 보증을 위한 활동을 수행해야 한다. 이를 위해 기업은 배포용 소프트웨어에서 알려진 취약점 존재 여부를 탐지하고, 식별된 위험이 출시 전에 해결해야 할 뿐 아니라 출시 후 새롭게 알려진 취약점에 대응하기 위한 방법과 절차를 갖춰야 한다. 이에 대해서는 3.3 보안 보증 장에서 자세히 설명한다.


  1. OSPO - Open Source Program Office ↩︎

  2. OSRB - Open Source Review Board ↩︎ ↩︎

3.2.2 - 2. 관련 업무 정의 및 지원

오픈소스 프로그램이 효과적으로 운용되기 위해서는 충분한 리소스와 인력 할당이 필요하다. 여기에서는 이를 위한 요구사항을 정의한다.

2.1 접근성

ISO/IEC 5230과 ISO/IEC 18974의 3.2.1항에서는 다음과 같이 접근성에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230


3.2.1 외부 문의 대응 (Access)

외부의 오픈소스 문의에 효과적으로 대응하기 위한 프로세스를 유지해야 한다. 제 3자가 오픈소스 컴플라이언스에 대해 문의 할 수 있는 방법을 공개해야 한다.

입증 자료:

  • 3.2.1.1 제 3자가 오픈소스 라이선스 컴플라이언스에 대해 문의 할 수 있는 공개된 방법 (담당자 이메일 주소, 또는 Linux Foundation의 Open Compliance Directory 활용 등)
  • 3.2.1.2 제 3자의 오픈소스 라이선스 컴플라이언스 문의에 대응하기 위한 내부의 문서화된 절차

3.2.1 Access

Maintain a process to effectively respond to external open source inquiries. Publicly identify a means by which a third party can make an open source compliance inquiry.

Verification material(s):

  • 3.2.1.1 Publicly visible method that allows any third party to make an open source license compliance inquiry (e.g., via a published contact email address, or the Linux Foundation’s Open Compliance Directory).
  • 3.2.1.2 An internal documented procedure for responding to third party open source license compliance inquiries.

ISO/IEC 18974


3.2.1 - 외부 문의 대응

알려진 취약점에 대한 외부 문의에 효과적으로 대응하기 위한 프로세스를 유지해야 한다. 제3자가 특정 소프트웨어 제품과 관련하여 알려진 취약점에 대해 문의할 수 있는 방법을 공개해야 한다.

입증 자료:

  • 3.2.1.1: 제3자가 알려진 취약점 또는 새로 발견된 취약점에 대해 문의할 수 있는 공개된 방법 (예: 이메일 주소 또는 프로그램 참여자가 모니터링하는 웹 포털)
  • 3.2.1.2: 제3자에 의한 알려진 취약점 또는 새로 발견된 취약점 문의에 대응하기 위한 내부의 문서화된 절차

3.2.1 - Access

Maintain a process to effectively respond to Known Vulnerability external inquiries. Publicly identify a means by which a third party can inquire about a Known Vulnerability with respect to a given software offering.

Verification Material(s):

  • 3.2.1.1: Publicly visible method to allow third parties to make Known Vulnerability or Newly Discovered Vulnerability enquires (e.g., via an email address or web portal that is monitored by Program Participants);
  • 3.2.1.2: An internal documented procedure exists for responding to third party Known Vulnerability or Newly Discovered Vulnerability inquiries.

2.1.1 연락 담당자 지정

오픈소스를 사용하여 개발한 제품 혹은 서비스에 대해 고객 및 오픈소스 저작권자가 기업에 오픈소스 관련 문의, 요청 및 클레임을 제기하는 경우가 있다. 외부 문의 및 요청의 주된 내용은 다음과 같다.

  • 특정 제품 및 서비스에 오픈소스가 사용되었는지 문의
  • 서면 약정(Written Offer)에 언급된 GPL, LGPL 라이선스 하의 소스 코드 제공 요청
  • 오픈소스 고지문에 명시되지 않았지만, 제품에서 발견된 오픈소스에 대한 해명 및 소스 코드 공개 요청
  • GPL, LGPL 등의 의무로 공개된 소스 코드에 누락된 파일 및 빌드 방법 제공 요청
  • 저작권 표시 요청

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

2.1.2 연락 담당자 정보 공개

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

외부에서 기업에 오픈소스 관련된 문의를 할 수 있는 연락 방법은 (1) 기업 오픈소스 프로그램 매니저의 이메일 주소를 공개하거나, (2) Linux Foundation의 Open Compliance Directory1를 이용하는 것이다. 기업 오픈소스 프로그램 사무소의 대표 이메일 주소는 제품 및 서비스와 동봉하는 오픈소스 고지문에 포함하여 공개하는 것도 한 방법이다.

Linux Foundation은 기업이 오픈소스 담당자의 연락처를 공개할 수 있도록 Open Compliance Directory라는 공간을 마련하였다.

directory.png

< https://compliance.linuxfoundation.org/references/open-compliance-directory/ >


기업의 오픈소스 담당자는 “Add an Organization"을 이용하여 기업의 연락처를 등록한다. 외부 개발자는 “Request a Contact"에서 오픈소스 컴플라이언스 관련 문의 및 요청을 할 수 있다. 이를 통해 오픈소스 개발자들은 원하는 기업의 컨택 포인트 정보를 쉽게 확인할 수 있고, 법적 클레임까지 제기하기 이전에 기업의 오픈소스 담당자와 오픈소스 컴플라이언스 이슈를 논의하여 문제를 해결할 수 있다. Open Compliance Directory에 기업 정보 및 연락 방법을 등록하는 것이 소송 리스크를 줄일 수 있는 방법의 하나다.

2.1.3 문의 대응 절차 문서화

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

위의 내용은 다음의 예시 문장을 오픈소스 정책에 반영할 수 있다.

9. 외부 문의 대응

(1) 외부 문의 대응 책임
외부로부터 오픈소스에 대한 문의 및 요청에 대한 대응은 오픈소스 프로그램 매니저가 담당합니다.

- 오픈소스 프로그램 매니저는 회사 내의 적절한 인원에게 문의에 대한 전체 또는 일부의 처리를 할당할 수 있습니다. 필요할 경우 법률 담당자에게 문의하여 처리합니다.
- 외부로부터 오픈소스에 대한 문의를 받은 사람은 누구나 이를 오픈소스 프로그램 매니저에게 알려서 신속한 대응이 될 수 있게 합니다.

(2) 연락처 공개
오픈소스 프로그램 매니저는 외부에서 오픈소스 관련한 문의 및 요청을 할 수 있도록 담당자의 연락처를 공개적으로 제공합니다.

- 오픈소스 고지문에 연락받을 수 있는 이메일 주소 정보를 제공합니다.
- 오픈소스 웹사이트에 이메일 주소 정보를 제공합니다.
- Linux Foundation의 Open Compliance Directory에 연락처를 등록합니다.

(3) 외부 문의 대응 절차
외부로부터의 오픈소스 문의에 신속하고 정확하게 대응한다면 클레임이나 법적 소송 위험을 크게 줄일 수 있습니다. 이를 위해 회사는 외부의 오픈소스 문의에 대응하기 위해 회사의 오픈소스 프로세스에서 정의한 외부 문의 대응 절차를 준수합니다.

또한 이 가이드에서는 외부 문의에 대응하기 위한 일반적인 절차에 대한 예시를 [부록 2] 오픈소스 프로세스의 3. 외부 문의 대응 프로세스에서 제공한다.

2.2 효과적인 리소스 제공

ISO/IEC 5230과 ISO/IEC 18974의 3.2.2항에서는 다음과 같이 효과적인 오픈소스 프로그램의 운영을 위한 리소스 제공에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230


3.2.2 효과적인 리소스 제공

프로그램이 효과적일 수 있도록 다음과 같이 업무를 정의하고 리소스를 제공해야 한다:

  • 프로그램을 성공적으로 수행할 수 있도록 각 업무에 대한 책임을 할당한다.
  • 프로그램의 업무를 위한 충분한 리소스를 제공한다.
    • 업무 수행 시간을 할당한다.
    • 예산을 적절하게 지원한다.
  • 정책 및 지원 업무를 검토하고 개선하는 프로세스가 존재한다.
  • 오픈소스 라이선스 컴플라이언스와 관련된 전문 법률 자문을 이용 할 수 있게 한다.
  • 오픈소스 라이선스 컴플라이언스 문제를 해결하기 위한 프로세스가 존재한다.

입증 자료:

  • 3.2.2.1 프로그램 내 각 역할을 담당하는 인원, 그룹 또는 직무의 이름을 기재한 문서
  • 3.2.2.2 프로그램 내 각 역할을 담당하는 인원이 적합하게 배치되고, 예산이 적절하게 지원되어야 한다.
  • 3.2.2.3 오픈소스 라이선스 컴플라이언스 문제 해결을 위해 내부 또는 외부의 전문 법률 자문을 이용하는 방법
  • 3.2.2.4 오픈소스 컴플라이언스에 대한 내부 책임을 할당하는 문서화된 절차
  • 3.2.2.5 미준수 사례를 검토하고 이를 수정하기 위한 문서화된 절차

3.2.2 Effectively resourced

Identify and Resource Program Task(s):

  • Assign accountability to ensure the successful execution of program tasks.
  • Program tasks are sufficiently resourced:
    • Time to perform the tasks have been allocated; and
    • Adequate funding has been allocated.
  • A process exists for reviewing and updating the policy and supporting tasks;
  • Legal expertise pertaining to open source license compliance is accessible to those who may need such guidance; and
  • A process exists for the resolution of open source license compliance issues.

Verification material(s):

  • 3.2.2.1 Document with name of persons, group or function in program role(s) identified.
  • 3.2.2.2 The identified program roles have been properly staffed and adequate funding provided.
  • 3.2.2.3 Identification of legal expertise available to address open source license compliance matters which could be internal or external.
  • 3.2.2.4 A documented procedure that assigns internal responsibilities for open source compliance.
  • 3.2.2.5 A documented procedure for handling the review and remediation of non-compliant cases.

ISO/IEC 18974


3.2.2 - 효과적인 리소스 제공

프로그램이 효과적일 수 있도록 다음과 같이 업무를 정의하고 리소스를 제공해야 한다:

  • 프로그램을 성공적으로 수행할 수 있도록 각 업무에 대한 책임을 할당한다.
  • 프로그램의 업무를 위한 충분한 리소스를 제공한다.
  • 업무를 수행하기에 충분한 시간을 할당한다.
  • 예산을 적절하게 지원한다.
  • 정책 및 지원 업무를 검토하고 개선하는 프로세스가 존재한다.
  • 알려진 취약점과 관련된 전문 기술 자문을 이용할 수 있게 한다.

입증 자료:

  • 3.2.2.1: 프로그램 내 각 역할을 담당하는 인원, 그룹 또는 직무의 이름을 기재한 문서
  • 3.2.2.2: 프로그램 내 각 역할을 담당하는 인원이 적합하게 배치되고, 예산이 적절하게 지원되어야 한다.
  • 3.2.2.3: 식별된 알려진 취약점을 해결을 위해 전문 기술 자문을 이용할 수 있는 방법
  • 3.2.2.4: 보안 보증에 대한 내부 책임을 할당하는 문서화된 절차

3.2.2 - Effectively Resourced

Identify and Resource Program Task(s):

  • Assign accountability to ensure the successful execution of Program tasks;
  • Program tasks are sufficiently resourced;
  • Sufficient time to perform the tasks have been allocated;
  • Adequate funding has been allocated;
  • A process exists for reviewing and updating the policy and supporting tasks;
  • Technical expertise pertaining to Known Vulnerabilities is accessible to those who may need such guidance.

Verification Material(s):

  • 3.2.2.1: Document with name of persons, group or function in Program role(s) identified;
  • 3.2.2.2: The identified Program roles have been properly staffed and adequate funding provided;
  • 3.2.2.3: Identification of expertise available to address identified Known Vulnerabilities;
  • 3.2.2.4: A documented procedure that assigns internal responsibilities for Security Assurance.

2.2.1 각 역할 담당자 문서화

기업은 각 프로그램 참여자의 역할 및 그에 따른 책임을 나열하고, 각 역할을 담당하는 담당자 혹은 담당 조직을 지정해야 한다. 그리고 이를 문서화하고 오픈소스 정책 문서에 포함해서 누구나 열람할 수 있게 해야 한다. 다음의 예시를 참고하라.

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

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

- 오픈소스 프로그램 매니저는 회사의 비즈니스 상황에 맞추어 주기적으로 명단을 업데이트합니다.

2.2.2 인원과 예산 지원

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

4. 역할, 책임 및 역량

각 역할에 대한 담당 조직의 장은 조직 내 담당자를 지정하고, 담당자가 역할을 충실하게 수행할 수 있는 적절한 시간과 예산을 할당합니다.
- 각 역할의 담당자는 자신이 역할을 수행하면서 적절한 지원이 되지 않는다면 오픈소스 프로그램 매니저에게 문제를 제기해야 합니다.
- 오픈소스 프로그램 매니저는 해당 조직장과 문제 해결을 논의합니다. 적절하게 해결되지 않는다면, 오픈소스 프로그램 매니저는 OSRB에 문제 해결을 요청할 수 있습니다.
- OSRB는 상위 조직의 장에게 문제를 공유하고 해결을 요청합니다.

2.2.3 외부 전문 자문 이용 방법 제공

기업은 프로그램 참여자가 이슈 해결을 위해 법률적인 검토가 필요할 경우, 이에 대해 법률 자문을 요청할 수 있는 방법을 제공해야 한다. 회사 내의 법무팀을 통해 우선 제공하고, 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인을 이용할 수 있다. 이를 위한 오픈소스 정책의 예시는 다음과 같다.


4. 역할, 책임 및 역량

(2) 오픈소스 프로그램 매니저

- 구성원이 오픈소스 관련 자문을 받는 방법을 제공합니다.

참고로, OpenChain 프로젝트에서는 파트너 프로그램을 통해 오픈소스 관련 자문을 제공하는 글로벌 법무법인 리스트를 제공한다.

partners.png

< https://www.openchainproject.org/partners >

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

2.2.4 내부 책임 할당 절차 문서화

오픈소스 컴플라이언스와 보안 보증에 대한 내부 책임을 할당하는 절차가 있어야 한다. 오픈소스 프로그램 매니저와 보안담당자는 이슈를 파악하고 각 역할의 담당자에게 적절히 이슈를 할당해야 한다. 이를 위해 기업은 오픈소스 정책 문서에 이러한 내용을 아래와 같이 기술할 수 있다.

4. 역할, 책임 및 역량

(2) 오픈소스 프로그램 매니저

오픈소스 프로그램 매니저는 회사의 오픈소스 프로그램에 대한 총괄 책임을 담당합니다. 오픈소스를 사용한 제품과 서비스의 오픈소스 관리 활동을 보장하기 위해 다음 사항에 대한 책임이 있습니다.

- 오픈소스 컴플라이언스를 위해 필요한 역할을 정의하고, 각 역할을 책임질 담당 조직 및 담당자를 지정합니다. 필요 시 OSRB와 협의합니다. 오픈소스 보안 보증을 위한 내부 책임은 보안 담당자가 할당합니다.

2.2.5 미준수 사례 검토 및 수정 절차 문서화

기업은 오픈소스 정책 문서에 위의 내용을 기술하여 오픈소스 프로그램에 효과적인 리소스가 제공될 수 있도록 해야 한다.

컴플라이언스 미준수 문제가 제기된 경우, 기업은 이를 신속히 검토하고 대응하기 위한 절차를 문서화해야 한다. 다음의 예시를 참고하여 오픈소스 정책에 포함할 수 있다.

6. 오픈소스 사용

(5) 컴플라이언스 이슈 대응 절차
컴플라이언스 이슈가 제기될 경우, 오픈소스 프로그램 매니저는 다음의 절차를 수행하여 신속히 대응합니다.

1. 문의 접수를 확인하고 적절한 해결 시간을 명시합니다.
2. 이슈 내용이 실제 문제를 지적하고 있는지를 확인합니다. (아닐 경우, 이슈 제기자에게 문제가 아님을 알립니다.)
3. 실제 문제인 경우, 우선순위를 정하고 적절한 대응 방안을 결정합니다.
4. 대응을 수행하고, 필요할 경우, 오픈소스 프로세스를 적절하게 보완합니다.
5. 위의 내용은 Jira Tracker를 이용하여 보존합니다.

이 가이드에서는 효과적인 리소스 제공에 대한 예시를 [부록 01] 샘플 오픈소스 정책의 4. 역할, 책임 및 역량에서 제공한다.

3.2.3 - 3. 오픈소스 콘텐츠 검토 및 승인

3.1 SBOM (Software Bill of Materials)

ISO/IEC 5230과 ISO/IEC 18974의 3.3.1항에서는 다음과 같이 BOM(Bill of Materials)에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230


3.3.1 BOM

배포용 소프트웨어를 구성하는 오픈소스 컴포넌트(및 식별된 라이선스)에 대한 BOM(Bill of Materials)을 생성하고 관리하는 프로세스가 있어야 한다.

입증 자료:

  • 3.3.1.1 배포용 소프트웨어를 구성하는 오픈소스 컴포넌트에 대한 정보를 식별, 추적, 검토, 승인 및 보관하는 문서화된 절차
  • 3.3.1.2 문서화된 절차가 적절히 준수되었음을 보여주는 배포용 소프트웨어에 대한 오픈소스 컴포넌트 기록

3.3.1 Bill of Materials

A process shall exist for creating and managing a bill of materials that includes each open source component (and its identified licenses) from which the supplied software is comprised.

Verification Material(s):

  • 3.1.1.1 A documented procedure for identifying, tracking, reviewing, approving, and archiving information about the collection of open source components from which the supplied software is comprised.
  • 3.3.1.2 Open source component records for the supplied software that demonstrates the documented procedure was properly followed.

ISO/IEC 18974


3.3.1 - SBOM (Software Bill of Materials)

배포용 소프트웨어를 구성하는 각 오픈소스 소프트웨어 컴포넌트 내역을 포함하는 BOM(Bill of Materials)을 생성하고 이를 유지하는 프로세스가 있어야 한다.

입증 자료:

  • 3.3.1.1: 배포용 소프트웨어에 사용된 모든 오픈소스 소프트웨어가 배포용 소프트웨어의 수명 주기 동안 지속적으로 기록되도록 하는 문서화된 절차. 여기에는 배포용 소프트웨어에 사용된 모든 오픈소스 소프트웨어의 저장소도 포함된다.
  • 3.3.1.2: 문서화된 절차가 적절히 준수되었음을 보여주는 배포용 소프트웨어에 대한 오픈소스 소프트웨어 컴포넌트 기록

3.3.1 - Software Bill of Materials (SBOM)

A process shall exist for creating and maintaining a bill of materials that includes each Open Source Software component from which the Supplied Software is comprised.

Verification Material(s):

  • 3.3.1.1: A documented procedure ensuring all Open Source Software used in the Supplied Software is continuously recorded across the lifecycle of the Supplied Software. This includes an archive of all Open Source Software used in the Supplied Software;
  • 3.3.1.2: Open Source Software Component Records for the Supplied Software that demonstrates the documented procedure was properly followed.

3.1.1 SBOM 관리 절차 문서화

오픈소스 관리 활동의 가장 기본은 배포용 소프트웨어에 포함된 오픈소스 현황을 파악하는 것이다. 배포용 소프트웨어에 포함된 오픈소스와 그 라이선스를 식별하여 그 정보를 담고 있는 SBOM(Software Bill of Materials)을 작성하고 관리하는 프로세스를 구축해야 한다. 배포용 소프트웨어의 버전마다 어떤 오픈소스가 포함되어 있는지 알고 있어야 소프트웨어를 배포할 때 각 오픈소스의 라이선스가 요구하는 의무 사항을 준수할 수 있기 때문이다.

모든 오픈소스는 배포용 소프트웨어에 통합하기 전에 검토 및 승인되어야 한다. 오픈소스의 기능, 품질뿐만 아니라 출처, 라이선스 요건을 충족할 수 있는지 사전 검토가 되어야 한다. 이를 위해 검토 요청 → 리뷰 → 승인 과정이 필요하다. [부록 02] 오픈소스 프로세스에서는 기업의 오픈소스 관리를 위한 프로세스 모든 과정에 관해 설명하고 있다.

1. 오픈소스 식별부터 6. 등록까지의 과정을 통해 SBOM을 작성하고 관리하게 된다.

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

3.1.2 SBOM 기록

배포용 소프트웨어에 포함된 오픈소스 목록은 문서화하여 보관해야 한다. Eclipse 재단에서 후원하는 오픈소스 프로젝트인 SW3601은 배포용 소프트웨어별로 포함하고 있는 오픈소스 목록을 트래킹할 수 있는 기능을 제공한다. SW360 사용 방법은 부록 3. 오픈소스 도구을 참고할 수 있다.

이 가이드에서는 SBOM 사용 정책에 대한 예시를 “[부록 1] 샘플 오픈소스 정책의 6. 오픈소스 사용에서 제공한다.

3.2 라이선스 컴플라이언스

ISO/IEC 5230의 3.3.2항에서는 다음과 같이 라이선스 컴플라이언스에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230


3.3.2 라이선스 컴플라이언스

프로그램은 배포용 소프트웨어에 대해 프로그램 참여자가 접할 수 있는 일반적인 오픈소스 라이선스의 사용 사례를 관리할 수 있어야 한다. 여기에는 다음과 같은 사용 사례가 포함될 수 있다(아래 목록이 모든 사례를 다루는 것은 아니며, 또한 이 사례를 모두 다뤄야만 하는 것은 아님). :

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

입증 자료:

  • 3.3.2.1 배포용 소프트웨어 내의 오픈소스 컴포넌트에 대해 일반적인 오픈소스 라이선스 사용 사례를 처리하기 위한 문서화된 절차

3.3.2 License Compliance

The program shall be capable of managing common open source license use cases encountered by program participants for supplied software, which may include the following use cases (note that the list is neither exhaustive, nor might all of the use cases apply):

  • Distributed in binary form;
  • Distributed in source form;
  • Integrated with other open source such that it triggers additional licensing obligations;
  • Contains modified open source;
  • Contains open source or other software under an incompatible license interacting with other components within the Supplied Software; and/or
  • Contains open source with attribution requirements.

Verification Material(s):

  • 3.3.2.1 A documented procedure for handling the common open source license use cases for the open source components of the supplied software.

오픈소스 라이선스를 제대로 준수하기 위해서는 오픈소스 라이선스별로 요구하는 사항에 대해 정확히 알고 있어야 한다. 하지만 개별 소프트웨어 개발자가 이를 일일이 파악하는 것은 어려우므로 오픈소스 책임자는 자주 사용되는 오픈소스 라이선스에 대해 일반적인 사용 사례별 요구사항/주의사항을 정리하여 회사 내부에 공유하는 것이 좋다. 오픈소스 라이선스에 대한 일반적인 가이드와 라이선스 의무 요약 자료는 NIPA에서 제공하는 공개소프트웨어 라이선스 가이드2를 참고할 수 있다. 또한, 소프트웨어의 사용 사례별 라이선스 의무를 분석한 SK텔레콤의 오픈소스 라이선스 가이드3도 좋은 사례가 된다.

부록 2. 샘플 오픈소스 컴플라이언스 프로세스의 오픈소스 컴플라이언스 프로세스의 오픈소스 식별, 검사, 문제해결, 리뷰, 승인 단계를 통해 배포용 소프트웨어의 오픈소스 컴포넌트에 대해 일반적인 오픈소스 라이선스 사용 사례를 처리할 수 있다.

식별 및 검사 단계에서는 소스 코드 스캔 도구를 사용할 수 있다. 소스 코드 스캔 도구는 무료로 사용할 수 있는 오픈소스 기반 도구부터 상용 도구까지 다양하게 있는데, 각 도구는 특장점 들이 있지만 어떤 하나도 모든 문제를 해결할 수 있는 완벽한 기능을 제공하지 않는다. 따라서 기업은 제품의 특성과 요구사항에 맞는 적합한 도구를 선택해야 한다. 많은 기업이 이러한 자동화된 소스 코드 스캔 도구와 수동 검토를 병행하여 이용한다. Linux Foundation의 FOSSology4 프로젝트는 오픈소스로 공개된 소스 코드 스캔 도구로서 기업들이 손쉽게 무료로 사용할 수 있다. 사용 방법은 부록 3. 오픈소스 도구를 참고한다.

3.3 보안 보증

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

ISO/IEC 18974


3.3.2 - 보안 보증

  • 검토 중인 배포용 소프트웨어 릴리스에 대한 BOM의 각 오픈소스 소프트웨어 컴포넌트에 대해 다음 사항을 확인한다.
  • 알려진 취약점의 존재를 발견하기 위한 방법을 적용한다.
  • 각각의 발견된 취약점과 할당된 점수에 대해 소프트웨어의 사용 사례에 적합하게 필요한 수정 단계를 결정 및 문서화하고 이전에 결정된 수준 이상(즉, 심각도 점수 4.5 이상인 모든 경우 등)에서는 고객 동의를 얻는다.
  • 위험/영향 점수에 따라 적절한 조치를 취한다(예: 필요한 경우 고객에게 연락, 소프트웨어 컴포넌트 업그레이드, 추가 조치 없음 등).
  • 새로 발견된 취약점이 이전에 배포된 배포용 소프트웨어에 있는 경우 위험/영향 점수에 따라 적절한 조치를 취한다(예: 보증이 필요한 고객에게 연락).
  • 배포용 소프트웨어가 시장에 출시된 후 모니터링하고 알려진 취약점 또는 새로 발견된 취약점 노출에 대응하는 기능을 확보한다.

입증 자료:

  • 3.3.2.1: 배포용 소프트웨어의 오픈소스 소프트웨어 컴포넌트에 대한 알려진 취약점의 탐지 및 해결을 위한 문서화된 절차
  • 3.3.2.2: 각 오픈소스 소프트웨어 컴포넌트에 대해 식별된 알려진 취약점 및 수행된 조치에 대한 기록을 유지한다(조치가 필요하지 않은 경우도 포함).

3.3.2 - Security Assurance

  • For each Open Source Software component in the bill of materials for the Supplied Software release under review;
  • Apply method for detecting existence of Known Vulnerabilities;
  • For each identified Known Vulnerability assign a risk/impact score;
  • For each detection and assigned score determine and document necessary remediation steps suitable for the use-case of the software and get Customer Agreement at or above a previously determined level (i.e., all severity scores above 4.5 …);
  • Depending on the risk/impact score take the appropriate action (e.g., contact customers if necessary, upgrade software component, no further action, …);
  • If a Newly Discovered Vulnerability is present in previously distributed Supplied Software, depending on the risk/impact score take the appropriate action (e.g., contact customers if warranted);
  • An ability to monitor Supplied Software after their release to market and to respond to Known Vulnerability or Newly Discovered Vulnerability disclosures.

Verification Material(s):

  • 3.3.2.1: A documented procedure for handling detection and resolution of Known Vulnerabilities for the Open Source Software components of the Supplied Software;
  • 3.3.2.2: For each Open Source Software component a record is maintained of the identified Known Vulnerabilities and action(s) taken (including even if no action was required).

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

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

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


  1. SW360 - https://projects.eclipse.org/proposals/sw360 ↩︎

  2. NIPA 공개소프트웨어 라이선스 가이드 - https://www.oss.kr/oss_license ↩︎

  3. SK텔레콤 오픈소스 라이선스 가이드 - https://sktelecom.github.io/guide/use/obligation/gpl-2.0/ ↩︎

  4. FOSSology - http://fossology.org/ ↩︎

3.2.4 - 4. 컴플라이언스 산출물 생성 및 제공

4.1 컴플라이어스 산출물

ISO/IEC 5230의 3.4.1항에서는 다음과 같이 컴플라이언스 산출물에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230


3.4.1 컴플라이언스 산출물

배포용 소프트웨어에 대한 컴플라이언스 산출물을 생성하는 프로세스가 있어야 한다.

입증 자료:

  • 3.4.1.1 식별된 라이선스가 요구하는 컴플라이언스 산출물을 준비하고, 이를 배포용 소프트웨어와 함께 제공하기 위한 프로세스를 설명하는 문서화된 절차
  • 3.4.1.2 배포용 소프트웨어의 컴플라이언스 산출물 사본을 보관하기 위한 문서화된 절차
    • 산출물 사본은 배포용 소프트웨어의 마지막 배포 이후 합리적인 기간 동안 혹은 식별된 라이선스에서 요구하는 기간 동안 보관해야 한다(둘 중 더 긴 기간을 따름).
    • 이러한 절차가 올바르게 수행되었음을 입증하는 기록이 존재해야 한다.

3.4.1 Compliance artifacts

A process shall exist for creating the set of compliance artifacts for the supplied software.

Verification Materials(s):

  • 3.4.1.1 A documented procedure that describes the process under which the compliance artifacts are prepared and distributed with the supplied software as required by the identified licenses.
  • 3.4.1.2 A documented procedure for archiving copies of the compliance artifacts of the supplied software - where the archive is planned to exist for a reasonable period of time (determined by domain, legal jurisdiction and/or customer contracts) since the last offer of the supplied software; or as required by the identified licenses (whichever is longer). Records exist that demonstrate the procedure has been properly followed.

4.1.1 컴플라이언스 산출물 생성 / 제공 절차 문서화

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

컴플라이언스 산출물은 크게 두 가지로 구분된다.

  1. 오픈소스 고지문 : 오픈소스 라이선스 전문과 저작권 정보 제공을 위한 문서
  2. 공개할 소스 코드 패키지 : GPL, LGPL 등 소스 코드 공개를 요구하는 오픈소스 라이선스 의무 이행을 위해 공개할 소스 코드를 취합한 패키지

이 가이드에서는 컴플라이언스 산출물 생성을 위한 정책에 대한 예시를 “부록 1. 샘플 오픈소스 정책의 6. 오픈소스 사용”에서 제공한다.

컴플라이언스 산출물은 배포용 소프트웨어를 배포할 때 함께 제공해야 한다. “부록 2. 샘플 오픈소스 컴플라이언스 프로세스”의 고지, 배포 전 확인, 배포 단계를 통해 컴플라이언스 산출물을 생성하여 배포한다.

4.1.2 컴플라이언스 산출물 보관

배포용 소프트웨어를 배포 시, 공개할 소스 코드 패키지를 동봉하는 것이 곤란할 경우, 최소 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.

< https://www.softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.html >

따라서, 컴플라이언스 산출물은 3년 이상 보관해야 하며 이를 위한 프로세스가 구축되어야 한다. 일부 기업은 자체적인 웹사이트(예: http://opensource.lge.com/) 구축하여 외부 고객들이 배포용 소프트웨어에 대한 오픈소스 고지문과 공개할 소스 코드 패키지를 언제든지 다운받을 수 있도록 편의를 제공한다.

3.2.5 - 5. 오픈소스 커뮤니티 참여에 대한 이해

5.1 기여

ISO/IEC 5230의 3.5.1항에서는 다음과 같이 컴플라이언스 산출물에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230


3.5.1 기여

조직이 외부 오픈소스 프로젝트로의 기여를 허용하려고 한다면,

  • 외부 오픈소스 프로젝트로의 기여를 관리하는 문서화된 정책이 있어야 한다.
  • 이 정책이 내부에 전파되어야 한다.
  • 정책을 시행하는 프로세스가 있어야 한다.

입증 자료:

조직이 외부 오픈소스 프로젝트로의 기여를 허용하는 경우, 다음 사항이 있어야 한다.:

  • 3.5.1.1 문서화된 오픈소스 기여 정책
  • 3.5.1.2 오픈소스 기여를 관리하는 문서화된 절차
  • 3.5.1.3 모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식하도록 하는 문서화된 절차 (예: 교육, 내부 위키, 또는 기타 실질적인 전달 방법 등)

3.5.1 Contributions

If an organization considers contributions to open source projects, then

  • a written policy shall exist that governs contributions to open source projects;
  • the policy shall be internally communicated; and
  • a process shall exist that implements the policy

Verification Materials(s):

If an organization permits contributions to open source projects, then the following shall exist:

  • 3.5.1.1 A documented open source contribution policy;
  • 3.5.1.2 A documented procedure that governs open source contributions; and
  • 3.5.1.3 A documented procedure that makes all program participants aware of the existence of the open source contribution policy (e.g., via training, internal wiki, or other practical communication method).

5.1.1 오픈소스 기여 정책

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

이러한 오픈소스 기여에 대한 정책은 “부록 1. 샘플 오픈소스 정책의 7. 오픈소스 기여“를 참고할 수 있다.

5.1.2 오픈소스 기여 절차 문서화

외부 오픈소스 프로젝트에 기여를 허용하는 정책을 갖고 있다면, 사내 개발자들이 어떤 절차로 외부 프로젝트에 기여할 수 있을지 관리하는 문서화된 절차가 있어야 한다. SK텔레콤에서 공개한 오픈소스 기여 절차[^skt-contribution]는 좋은 예이다.

5.1.3 오픈소스 기여 정책 인식 절차 문서화

오픈소스 기여 정책을 만들었다 해도 사내 구성원이 이에 대한 존재를 알지 못한다면 무용지물이 되어버린다. 모든 사내 개발자가 오픈소스 기여 정책의 존재를 알 수 있게 하는 절차가 필요하다. 3.1.1.2에서의 오픈소스 정책 전파 활동과 병행하여 오픈소스 기여 정책을 전파하라.

3.2.6 - 6. 규격 요구사항 준수

6.1 적합성

ISO/IEC 5230의 3.6.1항과 과 ISO/IEC 18974의 3.4.1항에서는 다음과 같이 적합성에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230


3.6.1 적합성

프로그램이 OpenChain에 적합하다고 간주하기 위해서는 조직은 프로그램이 이 규격에서 제시한 모든 요구사항을 충족하는지 확인해야 한다.

입증 자료:

  • 3.6.1.1 3.1.4조에서 명시한 프로그램이 이 규격의 모든 요구사항을 충족함을 확인하는 문서

3.6.1 Conformance

In order for a program to be deemed OpenChain conformant, the organization shall affirm that the program satisfies the requirements presented in this document.

Verification Materials(s):

  • 3.6.1.1 A document affirming the program specified in §3.1.4 satisfies all the requirements of this document.

ISO/IEC 18974


3.4.1 - 완전성 프로그램이 이 규격을 준수하는 것으로 간주되기 위해서, 조직은 프로그램이 이 문서에 제시된 요구사항을 충족한다는 것을 확인해야 한다.

입증 자료:

  • 3.4.1.1: §3.1.4에 명시된 프로그램이 이 문서의 모든 요구 사항을 충족함을 확인하는 문서화된 증거.

3.4.1 - Completeness

For a Program to be deemed conformant with this specification, the organization shall affirm that the Program satisfies the requirements presented in this document.

Verification Material(s):

  • 3.4.1.1: Documented Evidence affirming the Program specified in §3.1.4 satisfies all the requirements of this document.

ISO/IEC 5230과 ISO/IEC 18974의 모든 요구사항을 충족하는 기업은 이를 Linux Foundation OpenChain Project의 Self Certification을 통해 자체 인증을 선언할 수 있다. 어느 하나의 요구사항이라도 충족하지 못한다면 각 표준에 적합하다고 할 수 없다.

두 표준의의 모든 요구사항을 충족한다면, 부록 1. 샘플 오픈소스 정책의 10. ISO 표준 준수 선언과 유지에서와 같이 ISO 표준을 준수한다고 정책 문서상에 명시할 수 있다.

10. ISO 표준 준수 선언과 유지

회사는 소프트웨어 공급망에서의 오픈소스 컴플라이언스 수준 향상을 위해 Linux Foundation의 OpenChain 프로젝트의 정신을 지지하며 적극적으로 참여합니다.

- 회사는 이 오픈소스 정책을 적용하여 2021년 10월 1일부로 ISO/IEC 5230:2020을 준수함을 보장합니다.

6.2 지속 기간

ISO/IEC 5230의 3.6.2항과 ISO/IEC 18974의 3.4.2항에서는 다음과 같이 지속 기간에 대한 요구사항과 입증 자료를 정의하고 있다.

ISO/IEC 5230


3.6.2 지속 기간

이 규격의 버전 2.1에 적합한 OpenChain 프로그램은 적합성 인증을 획득한 날로부터 18개월 동안 지속되어야 한다. 적합성 인증 등록 절차는 OpenChain 프로젝트의 웹사이트에서 확인할 수 있다.

입증 자료:

  • 3.6.2.1 프로그램이 적합성 인증을 획득한 후 지난 18개월 동안 이 규격 버전(v2.1)의 모든 요구사항을 충족하고 있음을 확인하는 문서

3.6.2 Duration

A program that is OpenChain conformant with this version of the specification shall last 18 months from the date conformance validation was obtained. The conformance validation registration procedure can be found on the OpenChain project’s website.

Verification Materials(s):

  • 3.6.2.1 A document affirming the program meets all the requirements of this document, within the past 18 months of obtaining conformance validation.

ISO/IEC 18974


3.4.2 - 지속 기간

이 버전의 규격을 준수하는 프로그램은 다음의 시기마다 다시 검토가 되어야 한다. : 1차 인증일로부터 18개월, 2차 인증일로부터 24개월, 3차 인증일로부터 36개월. 이후에는 36개월마다 검토가 필요하다.

입증 자료:

  • 3.4.2.1: 프로그램이 적합성 인증을 획득한 후 지난 18개월 동안 이 규격의 모든 요구사항을 충족하고 있음을 확인하는 문서

3.4.2 - Duration

A Program that is conformant with this version of the specification will have a review period as follows: 18 months from the first certification, 24 months from the second certification and 36 months from the third certification. It will require review every 36 months after this.

Verification Material(s):

  • 3.4.2.1: A document affirming the Program meets all the requirements of this specification, within the past 18 months of obtaining conformance validation.

기업은 ISO 표준을 준수한다고 선언한 이후에도 계속해서 유지하는 것이 중요하다. ISO 표준에서는 준수한다고 선언한 이후에도 최소 18개월 이상은 변함없이 ISO 표준의 모든 요구사항을 준수하고 있어야 함을 요구한다.

기업은 ISO 표준을 준수한다고 선언한 이후 적어도 18개월 이상 계속해서 준수하는 상태를 유지하여야 하며, 그렇게 하고 있다면, 부록 1. 샘플 오픈소스 정책의 10. ISO 표준 준수 선언과 유지에서와 같이 ISO표준을 18개월 이상 계속하여 충족하고 있음을 문서상에 명시할 수 있다.

10. ISO 표준 준수 선언과 유지

- 회사는 적합성 인증을 획득한 후 18개월 이상 ISO/IEC 5230:2020의 모든 요구사항을 충족함을 보장합니다.
- 회사는 최소 18개월 간격으로 적합성을 검토하고 필요에 따라 정책을 변경 및 갱신합니다.

여기까지 완료하면 기업은 드디어 ISO/IEC 5230, ISO/IEC 18974의 모든 요구사항을 충족하게 된다.

4 - Templates

여기에서는 오픈소스 정책, 오픈소스 프로세스 등 기업이 오픈소스 관리를 위해 필요한 문서 템플릿을 제공합니다.

Author : 장학성 (Haksung Jang) / CC BY 4.0

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. 책임 할당 절차:

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

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

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

  2. 책임과 권한의 균형:

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

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

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

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

3.4 담당자 현황

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

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

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

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

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

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

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

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

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

4.4 SBOM 생성 및 관리

  1. SBOM 생성:
    • 공급 소프트웨어를 구성하는 모든 오픈소스 컴포넌트의 SBOM(Software Bill of Materials)을 생성합니다.
    • SBOM에는 각 컴포넌트의 이름, 버전, 라이선스 정보, 다운로드 위치 등이 포함됩니다.
  2. SBOM 유지 및 업데이트:
    • SBOM은 소프트웨어 릴리스마다 업데이트되며, 최신 상태를 유지합니다.
    • SBOM은 내부 저장소에서 안전하게 관리되며, 외부 요청 시 제공할 수 있도록 준비됩니다.
  3. 오픈소스 컴포넌트 기록 관리:
    • 각 오픈소스 컴포넌트에 대해 상세한 기록을 유지합니다. 이 기록에는 다음 정보가 포함됩니다:

      a. 컴포넌트 식별 정보 (이름, 버전, 출처)

      b. 라이선스 정보 및 의무사항

      c. 사용 목적 및 방식

      d. 수정 여부 및 수정 내용

      e. 취약점 분석 결과 및 대응 조치

    • 이 기록은 정기적으로 검토 및 업데이트되며, 문서화된 절차에 따라 관리됩니다.

  4. 기록 검증 절차:
    • 분기별로 오픈소스 컴포넌트 기록의 정확성과 완전성을 검증합니다.
    • 검증 결과는 문서화하여 보관하며, 필요시 개선 조치를 수행합니다.

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

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

5. 오픈소스 보안 보증

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

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

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

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

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

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

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

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

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

6. 교육 및 인식 제고

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

6.1 오픈소스 교육

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

6.2 역량 평가

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

6.3 인식 제고 활동

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

6.4 기록 보관

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

6.5 전문 지식 식별 및 활용

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

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

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

7.1 기여 절차

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

7.2 CLA 서명 주의

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

7.3 저작권 표시

  1. 저작권 표기:

    • 프로그램 참여자가 외부 오픈소스 프로젝트에 코드를 기여할 때, 회사의 저작권을 명시해야 합니다.

    • 파일 상단에 다음과 같이 저작권과 라이선스를 표기합니다:

      textCopyright (c) [Year] [Company Name] SPDX-License-Identifier: [SPDX_license_name]

  2. 회사 이메일 사용:

    • 오픈소스 프로젝트에 기여할 때는 개인 이메일을 사용하지 말고, 회사 이메일을 사용해야 합니다.
    • 이를 통해 회사를 대표하여 커뮤니티와 소통한다는 책임감을 갖게 됩니다.

7.4 기여 기록 유지

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

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

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

8.1 승인 절차

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

8.2 공개 준비

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

8.3 공개 후 관리

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

8.4 기록 보관

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

9. 외부 문의 대응

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

9.1 외부 문의 대응 책임

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

9.2 연락처 공개

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

9.3 외부 문의 대응 절차

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

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

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

10.1 성과 지표 정의

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

10.2 정기적인 프로그램 평가

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

10.3 지속적 개선 계획

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

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

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

10.5 인력 및 자원 평가

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

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

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

11.1 ISO 표준 준수 선언

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

11.2 준수 상태 유지

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

4.1.1 - Appendix

Appendix 1. 담당자 현황

No역할책임필요 역량담당 조직담당자
1오픈소스 프로그램 매니저 (OSPM)회사의 오픈소스 프로그램에 대한 총괄 책임을 담당합니다.소프트웨어 개발 프로세스 이해
저작권 및 특허 이해
오픈소스 라이선스 컴플라이언스 전문 지식
커뮤니케이션 스킬
오픈소스 관리팀[이름]
2법무 담당오픈소스 라이선스와 관련된 법적 위험을 평가하고 법적 자문을 제공합니다.오픈소스 생태계 이해
소프트웨어 저작권 전문 지식
오픈소스 라이선스 전문 지식
법적 위험 평가 능력
법무팀[이름]
3IT 담당오픈소스 분석 도구를 운영하고 자동화합니다.오픈소스 라이선스 컴플라이언스 프로세스 이해
오픈소스 분석 도구 이해
IT 인프라 전문 지식
자동화 및 CI/CD 파이프라인 이해
IT팀[이름]
4보안 담당오픈소스 보안 취약점 분석 도구를 운영합니다.DevSecOps 이해
오픈소스 보안 취약점 분석 도구 이해
알려진 취약점 및 새로 발견된 취약점 전문 지식
위험 평가 및 관리 능력
보안팀[이름]
5개발 문화 담당사내 개발자들이 오픈소스를 적극적으로 활용하도록 지원합니다.소프트웨어 개발 프로세스 이해
오픈소스 라이선스 컴플라이언스 기본 지식
교육 및 트레이닝 설계 능력
오픈소스 커뮤니티 참여 경험
개발팀[이름]
6품질 담당공급 소프트웨어 배포 시 오픈소스 라이선스 의무를 확인합니다.소프트웨어 개발 프로세스 이해
오픈소스 라이선스 컴플라이언스 기본 지식
오픈소스 정책 이해
오픈소스 라이선스 기본 지식
품질보증팀[이름]
7OSRB (Open Source Review Board)오픈소스 관리를 위한 정책과 프로세스를 수립 및 개선합니다.오픈소스 정책 및 프로세스 전문 지식
협의체 운영 경험
OSRB[이름]
8OSPO (Open Source Program Office)외부 오픈소스 프로젝트로의 기여와 사내 프로젝트 오픈소스 공개를 지원합니다.오픈소스 커뮤니티 참여 경험
오픈소스 프로젝트 관리 능력
OSPO[이름]

4.2 - 오픈소스 프로세스

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

1. 오픈소스 프로세스

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

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

process

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

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

(1) 오픈소스 식별

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

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

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

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

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

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

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

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

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

(2) 소스 코드 검사

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

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

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

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

(3) 문제 해결

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

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

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

(4) 검토

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

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

(5) 승인

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

(6) 등록

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

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

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

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

(7) 고지

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

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

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

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

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

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

(8) 배포 전 확인

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

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

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

(9) 배포

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

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

(10) 최종 확인

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

(11) 모니터링

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

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

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

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

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

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

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

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

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

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

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

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

(3) 취약점 평가 및 대응

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

위험CVSS 3.0조치 권고 일정
Low0.0 - 3.90.0 - 3.9
Medium4.0 - 6.94.0 - 6.9
Hgh7.0 - 10.07.0 - 8.9
Critical-9.0 - 10.0

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

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

(4) 취약점 해결 및 검증

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

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

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

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

(6) 취약점 기록 관리

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

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

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

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

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

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

(8) 고객 및 제3자 통지

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

  1. 고객 통지:

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

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

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

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

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

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

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

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

general-inquiry-process

(1) 접수 알림

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

주요 문의 및 요청 내용:

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

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

(2) 조사 알림

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

(3) 내부 조사

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

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

(4) 요청자에게 보고

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

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

(5) 문제 보완 / 알림

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

(6) 문제 해결 알림

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

(7) 프로세스 개선

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

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

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

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

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

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

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

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

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

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

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

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

5 - Tools

여기에서는 오픈소스 관리를 위해 필요한 오픈소스 도구를 소개하고 사용법을 안내합니다.

Author : 장학성 (Haksung Jang) / CC BY 4.0

5.1 - FOSSology

오픈소스 컴플라이언스를 위해 소프트웨어 내에 포함된 오픈소스와 라이선스 정보를 검출하기 위해 소스코드 스캔 도구를 사용할 수 있다.

https://www.fossology.org/

< https://www.fossology.org/ >

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에 대한 정보를 수집 및 추적하기 위한 웹 애플리케이션 및 저장소를 제공한다.

https://www.eclipse.org/sw360/

< https://www.eclipse.org/sw360/ >

주요 특징

SW360은 웹 기반의 UI를 제공하며 주요 기능은 다음과 같다.

  • 제품에 사용된 컴포넌트 추적
  • 보안 취약점 평가
  • 라이선스 의무 관리
  • 고지문 등 법적 문서 생성

https://www.eclipse.org/sw360/

설치

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 설정

설정을 위해 다음 계정으로 로그인한다.

로그인을 하면 아래와 같이 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에 진입하여 JQueryFont 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 CONTENTUse 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 등록을 자동화시켜서 관리한다면 효율성이 크게 증가될 것이다.

6 - SOFTWARE BILL OF MATERIALS (SBOM)에 대한 기술 가이드라인 (인도 정부 발간)

Technical Guidelines on Software Bill of Materials (SBOM)

본 문서는 인도 컴퓨터 비상대응팀(CERT-In)이 2023년 10월에 발표한 “Technical Guidelines on Software Bill of Materials (SBOM)“의 한국어 번역본입니다.

원문은 인도의 공공 부문, 정부, 필수 서비스, 소프트웨어 수출 및 서비스 산업 관련 조직을 대상으로 SBOM 도입에 대한 기술적 지침을 제공하며, SBOM의 가치와 모범 사례를 중점적으로 다루고 있습니다.: DOWNLOAD

이 가이드라인은 한국 기업에도 다음과 같은 시사점을 제공합니다:

  1. 경쟁력 강화: SBOM 도입은 소프트웨어 공급망 보안을 강화하고 글로벌 시장에서 신뢰성을 높이는 데 기여할 수 있습니다.
  2. 사이버 보안 향상: SBOM은 취약점 관리와 사고 대응 능력을 개선하는 데 중요한 역할을 합니다.
  3. 규제 대비: 인도와 거래하거나 협력하는 기업들은 해당 지침을 숙지하고 준수할 필요가 있습니다.
  4. 국제 협력 촉진: 글로벌 표준 준수를 통해 국제 거래에서 투명성과 신뢰성을 확보할 수 있습니다.

이 번역본이 한국의 소프트웨어 개발 및 보안 전략 수립에 실질적인 도움이 되기를 기대합니다.

Author : 장학성 (Haksung Jang) / CC BY 4.0

image.png

1. Executive Summary

소프트웨어 제품은 다양한 구성 요소로 이루어져 있으며, 이 중 일부는 외부 소스에서 가져옵니다. 이러한 외부 구성 요소와 의존성에는 취약점이 있을 수 있어, 공격자가 이를 악용해 보안 사고나 침해로 이어질 수 있습니다. 주요 위협으로는 악성 코드 삽입, 오래된 구성 요소의 취약점 이용, 공급업체 침해 등이 있습니다. 이로 인해 데이터 유출, 운영 중단, 평판 손상 등의 문제가 발생할 수 있습니다. 이러한 위협에 대응하려면 소프트웨어 구축이나 개발에 사용되는 구성 요소에 대한 가시성과 투명성을 확보해야 합니다. 소프트웨어 부품 명세서(Software Bill of Materials, SBOM)는 조직이 소프트웨어나 자산에 포함된 구성 요소를 정확히 파악하여 취약점을 식별하고 수정하는 데 도움을 줍니다. SBOM을 활용하면 조직은 소프트웨어 보안을 개선하고 잠재적 위협으로부터 보호할 수 있습니다.

소프트웨어 부품 명세서(SBOM) 는 소프트웨어를 구성하는 모든 요소, 라이브러리, 모듈의 목록으로, 소프트웨어 구성에 대한 투명성을 제공합니다. 소프트웨어가 더욱 복잡해지고 외부 구성 요소에 대한 의존도가 높아짐에 따라 소프트웨어 구성을 이해하는 것이 중요해졌습니다. 사이버 보안 측면에서 소프트웨어를 공격으로부터 보호하려면 소프트웨어 구축에 사용된 의존성과 구성 요소를 파악해야 합니다. 따라서 SBOM은 현대 사이버 보안 절차에서 핵심적인 도구입니다.

SBOM은 소프트웨어 보안 유지에 필수적입니다. 이를 통해 조직은 소프트웨어의 구성 요소를 이해하고, 잠재적 위험을 관리하며, 보안 문제에 대응하고, 규정을 준수할 수 있습니다. 다음은 조직이 SBOM을 구현함으로써 얻을 수 있는 주요 이점입니다:

  1. 보안 관리 강화: 소프트웨어의 구성 요소를 파악함으로써 조직은 보안 위협에 취약할 수 있는 요소를 식별하고 대응할 수 있습니다.
  2. 효과적인 사고 대응: 사이버 보안 사고 발생 시 SBOM은 상세한 구성 요소 정보를 제공하여 신속한 대응을 가능하게 합니다.
  3. 취약점 식별 및 패치 관리: 모든 구성 요소를 나열함으로써 조직은 소프트웨어의 알려진 취약점을 빠르게 발견하고 패치할 수 있습니다.
  4. 공급망 보안: 소프트웨어 제작에 사용된 외부 구성 요소에 대한 가시성을 확보함으로써 공급망 위험을 크게 줄일 수 있습니다.
  5. 규정 준수 지원: SBOM은 소프트웨어 구성의 투명성을 제공하여 조직이 보안 규정, 지침 및 모범 사례를 준수하는 과정을 간소화합니다.
  6. 운영 효율성 향상: 소프트웨어 구성 요소에 대한 명확한 이해를 통해 조직은 취약점 관리 프로세스를 간소화하여 시간과 자원을 절약할 수 있습니다.

인도 컴퓨터 비상 대응팀(CERT-In)은 특히 공공 부문, 정부, 필수 서비스, 소프트웨어 수출 및 서비스 산업 관련 조직을 위한 기술적 SBOM 지침을 발표했습니다. 부서와 조직은 보안을 강화하고 사이버 위협의 위험을 줄이기 위해 소프트웨어 조달 및 개발 과정에서 SBOM의 생성과 제공을 의무적인 표준 관행으로 삼도록 권장됩니다.

다음 장에서는 SBOM의 다양한 기술적 측면을 살펴보고 그 목적과 소프트웨어 공급망 생태계에서의 중요성이 증가하는 이유를 설명합니다. 두 번째 장에서는 SBOM의 개요와 범위 및 구현에 대해 논의하고, 이어서 SBOM 생태계에 대한 장에서는 SBOM의 다양한 수준과 분류에 대해 설명합니다. 그 다음 장에서는 SBOM 정보를 표현하는 데 사용되는 다양한 표준과 데이터 형식을 살펴보고, 최소 요소, 데이터 필드 및 자동화 지원에 대해 자세히 설명합니다. SBOM과 관련된 모든 프로세스와 관행의 목표, 안전한 SBOM 공유 및 배포에 대해 이 문서에서 상세히 다루며, SBOM의 취약점 추적 및 분석을 위한 접근 방식도 포함됩니다. 마지막으로, 문서의 마지막 장에서는 SBOM 구현을 위한 권장 사항과 모범 사례를 소개합니다.

2. SBOM 개요

2.1 필요성 및 활용

소프트웨어가 점점 복잡해짐에 따라 SBOM의 필요성이 더욱 커지고 있습니다. SBOM은 소프트웨어 구성 분석(SCA) 도구의 기반이 되며, 취약점 탐지, 라이선스 준수 지원, 공급업체 위험 관리에 중요한 역할을 합니다.

소프트웨어 정의 시스템의 증가로 사이버 위협 환경이 크게 확대되었습니다. 공격자들은 민감한 시스템과 데이터에 침투하기 위해 소프트웨어 공급망을 점점 더 많이 노리고 있습니다.

부서와 조직은 소프트웨어 개발 및 조달 과정에서 소프트웨어 부품 명세서(SBOM)의 생성과 제공을 표준 관행으로 삼도록 권장됩니다. 이를 통해 보안, 규정 준수, 위험 관리, 공급망 투명성, 품질 보증, 상호 운용성, 공급업체 관리를 개선할 수 있습니다.

조직은 소프트웨어 수명 주기의 모든 단계(설계, 개발, 분석, 배포, 유지 관리, 업데이트 포함)와 관련된 중요 구성 요소를 철저히 분석하고 SBOM 사용을 의무화해야 합니다.

SBOM은 다음 세 가지 주요 목적을 달성하는 데 도움을 줍니다:

  1. 정부 부서와 조직이 소프트웨어 구매에 대해 정보에 기반한 사전 결정을 내릴 수 있도록 지원합니다.
  2. 정부 기관 및 필수 서비스 조직 전반에 걸쳐 취약점 관리, 자산 추적, 규정 준수를 촉진합니다.
  3. 조직의 소프트웨어 개발 및 제품 유지 관리를 지원합니다.

모든 정부, 공공 부문, 필수 서비스 조직은 소프트웨어와 솔루션 구매/조달 요구 사항에 SBOM을 포함해야 합니다. 또한 사용자 조직의 보안 팀은 취약점 관리 작업 과정에 SBOM 목록을 반드시 포함해야 합니다.

2.2 적용 & 범위

이 가이드라인은 인도 컴퓨터 비상 대응팀(CERT-In)에서 다음과 같은 기관, 특히 정부, 공공 부문, 필수 서비스 조직 및 소프트웨어 수출과 서비스 산업 관련 조직을 위해 발행되었습니다:

  1. 소프트웨어 소비자 - 운영 지원, 생산성 향상, 비즈니스 목표 달성을 위해 소프트웨어 애플리케이션을 구매하는 조직.
  2. 소프트웨어 개발자 - 맞춤형 소프트웨어 솔루션을 개발하는 조직.
  3. 시스템 통합업체/소프트웨어 재판매업체 - 소프트웨어 제품을 배포하고 맞춤화, 통합, 지원, 교육 등 부가가치 서비스를 제공하는 조직.

SBOM은 가시성 확보, 취약점 패치, 노출 감소, 신속한 대응을 위한 필수 도구가 되고 있습니다. 예를 들어, 일반적인 조직은 상호 연결된 시스템, 엔드포인트, 제어 시스템, 자동화 소프트웨어, 운영 기술(OT) 구성 요소의 방대한 네트워크에 의존합니다. 이러한 복잡한 IT 및 OT 환경에 대한 정확한 SBOM을 유지하면 보안 팀이 공격 표면을 더 잘 이해하고 취약점에 더 효과적으로 대응할 수 있습니다. 이러한 사전 예방적 접근 방식은 조직이 운영을 보호하고 사이버 위협에 대한 복원력을 확보하는 데 도움이 됩니다.

예를 들어, 금융 기관에서 SBOM은 사이버 보안 관점에서 매우 중요합니다. 은행과 핀테크 기업은 디지털 서비스와 백엔드 시스템을 운영하기 위해 다양한 상용 제품(COTS) 소프트웨어, 오픈 소스 라이브러리, 맞춤 개발 구성 요소를 활용합니다. 이러한 다양한 소프트웨어 환경에 대해 최신 SBOM을 유지하면 보안 팀이 취약점을 신속하게 식별하고 완화하며, 산업 규정을 준수하고, 공급망 위험을 더 잘 관리할 수 있습니다.

소프트웨어 개발, 공급망 관리, 사이버 보안, 규제 준수와 관련된 SBOM의 사용 사례는 다음과 같습니다:

2.2.1 소프트웨어 개발 및 유지 관리

SBOM은 소프트웨어 시스템을 구성하는 요소와 의존성의 상세한 목록을 제공합니다. 이 정보를 통해 개발자는 취약점을 더 효과적으로 관리하고, 라이선스를 추적하며, 소프트웨어의 출처를 모니터링할 수 있습니다. 정확하고 최신 상태의 SBOM을 유지하는 것은 조직이 소프트웨어 공급망 위험을 이해하고 애플리케이션의 보안과 무결성을 보장하기 위한 사전 조치를 취하는 데 중요합니다.

2.2.2 공급망 관리

SBOM은 소프트웨어 공급망에 대한 투명성을 제공하여 조직이 외부 구성 요소의 보안과 신뢰성을 평가할 수 있게 합니다. 이는 외부 라이브러리나 구성 요소 사용과 관련된 잠재적 위험을 식별하는 데 도움이 되며 조달 및 공급업체 관리에 대한 정보에 기반한 의사 결정을 용이하게 합니다.

2.2.3 사이버 보안

SBOM은 기존 보안 도구와의 통합, 자동화된 취약점 탐지, 복구를 지원하며 사이버 보안 관행에서 중요한 역할을 합니다. SBOM은 소프트웨어 구성 요소와 그 의존성에 대한 가시성을 제공하여 조직이 보안 취약점을 효과적으로 식별하고 완화할 수 있게 합니다. 소프트웨어 구성에 대한 포괄적인 이해를 통해 조직은 보안 사고에 신속하게 대응하고, 취약점을 패치하며, 소프트웨어 시스템의 무결성과 보안을 보장할 수 있습니다.

2.2.4 규제 준수

SBOM은 특히 의료, 금융, 정부와 같은 필수 서비스를 다루는 산업에서 규제 준수를 위한 요구 사항이 되고 있습니다. 전 세계적으로 규제 기관들은 SBOM을 유망한 도구로 인식하고 있으며 EU 사이버 복원력 법(Cyber Resilience Act)과 같은 규정을 통해 SBOM 채택을 강조하고 있습니다.

2.2.5 위험 관리

SBOM은 소프트웨어 공급망에 대한 통찰력을 제공함으로써 위험 관리 노력을 지원합니다. 조직은 알려진 취약점, 라이선스 충돌, 더 이상 사용되지 않는 라이브러리와 같은 특정 소프트웨어 구성 요소와 관련된 잠재적 위험을 평가할 수 있습니다. 이러한 위험을 사전에 관리함으로써 조직은 소프트웨어 시스템의 복원력을 향상시키고 보안 침해나 규정 준수 문제의 가능성을 최소화할 수 있습니다.

2.2.6 상호 운용성 및 호환성

SBOM은 소프트웨어 구성 요소와 그 버전에 대한 상세한 정보를 제공함으로써 상호 운용성 및 호환성 테스트를 용이하게 합니다. 이는 서로 다른 소프트웨어 시스템이 호환성 문제 없이 원활하게 작동할 수 있도록 보장하는 데 도움이 되며, 따라서 소프트웨어 제품의 전반적인 품질과 신뢰성을 향상시킵니다.

2.3 SBOM 구현

SBOM은 모든 새로운 소프트웨어 구성 요소 출시에 대해 구현되어야 하며, 업데이트, 업그레이드, 출시, 패치 등 변경 사항이 있을 때마다 신속하게 갱신되어야 합니다. SBOM의 정확성은 구성 요소 자체가 변경되지 않았더라도 포함된 구성 요소에 대한 새로운 정보가 있을 때마다 업데이트하여 유지됩니다. 기존 구성 요소를 수정할 때는 일관된 접근 방식을 선택하세요. 변경 사항을 새로운 구성 요소로 취급하거나 기존 구성 요소를 업데이트하는 방식 중 하나를 선택하세요. 명확성을 위해 전체적으로 표준화된 버전 관리 방법을 사용하세요.

다음과 같은 조직의 시나리오를 고려해 보겠습니다:

A. 정부 조직 GovInsights는 소프트웨어 개발 회사 TechGenius를 고용하여 데이터 분석 애플리케이션 DataAnalyzer를 개발합니다.

B. DataAnalyzer 제품을 개발하기 위해 TechGenius 회사는 다음 구성 요소를 사용합니다:

  1. MessageMaster 회사의 Postfix & Twilio SDK라는 SMS 및 이메일 서비스
  2. DataVault 회사의 데이터베이스 구성 요소: PostgreSQL
  3. ServerSolutions 회사에서 제공하는 Apache Tomcat Server (이 서버는 많은 오픈 소스 라이브러리를 사용했습니다)

앞서 언급한 시나리오의 다양한 구성 요소/소프트웨어와 해당 SBOM 유형 및 상태는 아래 표에 제공되어 있습니다:

Table 1: 소프트웨어 구성 요소와 SBOM 작성자 현황

번호이름SBOM 작성자 현황
1DataAnalyzer 애플리케이션에 대한 SBOMTechGenius 회사에서 개발하여 제품/애플리케이션인 DataAnalyzer와 함께 GovInsights 조직에 제공될 예정
2PostgreSQL에 대한 SBOMDataVault가 이 구성 요소에 대한 SBOM을 생성하지 않았기 때문에 TechGenius가 최상위 수준 SBOM을 개발
3Apache Tomcat Server 플랫폼에 대한 SBOMServerSolutions 회사가 배포 SBOM을 생성하여 TechGenius가 플랫폼을 조달했을 때 TechGenius와 공유
4Postfix & Twilio SDK에 대한 SBOMMessageMaster가 SBOM을 제공하지 않았기 때문에 TechGenius 회사가 전이적 SBOM을 생성

이 시나리오에서 이해관계자와 구성 요소 간의 상호 관계는 Figure 1에 시각적으로 표현되어 있습니다. 묘사된 바와 같이, SBOM 생태계 내의 수많은 주체는 소프트웨어의 제공자와 소비자 역할을 모두 수행합니다. 이는 다른 주체가 제공한 SBOM의 정보를 활용할 뿐만 아니라 새로 개발된 구성 요소에 대한 SBOM을 생성하고 이를 다른 주체와 공유하는 것을 포함합니다. 이상적으로는 소프트웨어 구성 요소의 제작자가 해당 SBOM의 작성자가 되어야 합니다.

Figure 1: 시나리오 흐름도 Figure 1: 시나리오 흐름도

  • SBOM 소비자: 완전한 SBOM을 요청해야 합니다.
  • 소프트웨어 개발자: 정확하고 완전한 SBOM이 소비자에게 제공되도록 해야 합니다.

3. 생태계

SBOM 생태계는 소프트웨어 공급망 전반에 걸쳐 SBOM의 생성, 배포, 분석, 활용에 관여하는 이해관계자, 도구, 표준, 프로세스의 네트워크를 포함합니다. 이 섹션에서는 소프트웨어 소비자/개발자/시스템 통합업체 조직이 조직 수준에서 SBOM 생태계를 개발하기 위한 접근 방식을 설명합니다. 또한 SBOM의 다양한 분류에 대해 설명합니다.

3.1 SBOM 수준

SBOM의 다양한 수준은 각각 다른 정도의 세부성과 복잡성을 제공하며, 특정 요구 사항과 각 소프트웨어 환경의 복잡성을 반영합니다. 조직은 투명성, 위험 관리, 운영 효율성의 효과적인 균형을 달성하기 위해 하나 이상의 SBOM 수준을 구현하도록 선택해야 합니다.

SBOM 수준설명
Top-Level SBOM제품에 통합되거나 직접 사용되는 소프트웨어 요소의 일반적인 요약을 제공합니다. 구성 요소 이름, 버전, 소프트웨어 내 상호 작용과 같은 필수 세부 정보를 포함합니다.
n-Level SBOM최상위 개요를 넘어 더 깊은 세부사항과 복잡성을 포함합니다. “N"은 임의의 깊이 수준을 나타내며, SBOM이 여러 계층 또는 세분화 수준에서 정보를 포함함을 의미합니다.
Delivery SBOM소프트웨어 출시 또는 배포 패키지의 일부인 모든 부분, 라이브러리, 의존성을 설명합니다. 이는 공급되는 소프트웨어의 구성에 대한 명확성을 제공합니다.
Transitive SBOM소프트웨어 구성 요소의 직접적인 의존성뿐만 아니라 간접적이거나 전이적인 의존성도 포함합니다.
Complete SBOM소프트웨어 시스템에 존재하는 모든 부분, 의존성, 관련 메타데이터의 완전하고 철저한 목록을 제공합니다.

Figure 2: SBOM 수준

다중 SBOM 접근 방식을 채택하면 조직의 사이버 복원력을 크게 향상시킬 수 있습니다. 조직은 민감한 데이터를 노출하지 않고 보안 요구 사항을 해결하는 맞춤형 SBOM을 소비자를 위해 생성해야 합니다. 동시에 “완전한” 수준의 내부 SBOM을 유지하여 해당 소프트웨어와 관련된 취약점 업데이트를 식별하고 주기적으로 의무적으로 소비자와 상세히 공유해야 합니다. 이 접근 방식은 특히 조직이 완전한 소프트웨어 및 의존성 세부 정보를 공유함으로써 발생하는 데이터 유출 및 지적 재산 도용에 대한 제약이나 우려에 직면한 상황에서 생태계 전반에 걸쳐 사이버 복원력, 데이터 기밀성, 협력적 보안의 균형을 맞춥니다.

Table 2: SBOM을 작성한 조직의 시나리오에 따른 수준 매핑

번호이름SBOM 수준SBOM 작성자 현황
1DataAnalyzer 애플리케이션에 대한 SBOMComplete SBOMTechGenius 회사에서 개발하여 제품/애플리케이션인 DataAnalyzer와 함께 GovInsights 조직에 제공될 예정
2PostgreSQL에 대한 SBOMTop-Level SBOMDataVault가 이 구성 요소에 대한 SBOM을 생성하지 않았기 때문에 TechGenius가 최상위 수준 SBOM을 개발
3Apache Tomcat Server 플랫폼에 대한 SBOMDelivery SBOMServerSolutions 회사가 배포 SBOM을 생성하여 TechGenius가 플랫폼을 조달했을 때 TechGenius와 공유
4Postfix & Twilio SDK에 대한 SBOMTransitive SBOMMessageMaster가 SBOM을 제공하지 않았기 때문에 TechGenius 회사가 Transitive SBOM을 생성

3.2 SBOM의 분류

SBOM 분류는 소프트웨어 개발 생명주기 단계와 일치하며, 각각 고유한 데이터와 통찰력을 제공합니다. SBOM의 다양한 분류는 다음과 같습니다:

Figure 3: SDLC 단계와 일치하는 SBOM 분류

Figure 3: SDLC 단계와 일치하는 SBOM 분류

  • 3.2.1 Design SBOM: 계획된 구성 요소를 포착하며, 실제로 존재하기 전에도 이를 기록합니다.
  • 3.2.2 Source SBOM: 개발 환경을 반영하며, 소스 파일과 의존성을 포함합니다.
  • 3.2.3 Build SBOM: 빌드 과정 중에 생성되며, 소스 파일, 의존성 및 사전 빌드된 구성 요소에 대한 세부 정보를 포함합니다.
  • 3.2.4 Analyzed SBOM: 빌드 후 최종 소프트웨어 결과물을 검사하여 생성됩니다.
  • 3.2.5 Deployed SBOM: 특정 시스템에 설치 및 구성된 소프트웨어의 목록을 제공합니다. 다양한 SBOM 유형의 정보를 결합하고 배포 환경을 고려합니다.
  • 3.2.6 Runtime SBOM: 실행 중인 소프트웨어 구성 요소를 모니터링하여 생성됩니다. 외부 상호작용과 동적으로 로드된 의존성을 포함하여 런타임 실행 중의 정보를 캡처합니다.

3.3 조직의 SBOM 개발 및 채택을 위한 로드맵

조직 내 SBOM 생태계 구축은 단계적 접근이 필요합니다. 기본 토대(START)를 시작으로 발전(PROGRESS)시키고 최종적으로 성숙하고 확장 가능한 SBOM 구현(ADVANCE)에 도달해야 합니다. 활동 순서는 예시일 뿐이며, 조직의 보안 요구사항, 프로젝트 일정, 리소스 가용성에 따라 조정할 수 있습니다.

단계활동
START (기초 활동)• 중요 자산 식별 및 프로젝트 계획 수립
• SBOM 형식 및 최소 요구사항 결정
• 보안 요구사항, 안전한 저장소 및 도구 식별
• 조달 과정의 일부로 SBOM 획득
PROGRESS (발전)• 안전한 설치 및 운영 지침 개발
• 각 구성 요소에 고유 식별자 할당
• 공급업체의 SBOM과 소비자의 내부 SBOM 매핑
• SBOM 준비
• 보안 소프트웨어 개발 수명주기의 각 단계에 SBOM 통합
• 안전한 구성 관리 수립
ADVANCE (성숙 & 확장 가능한 SBOM)• 취약점 추적 프로세스 강화
• 사고 대응 프로세스 강화
• 기존 SBOM의 주기적 분석 및 검토 업데이트
• 새로운 소프트웨어 구성 요소 및 산업 발전에 대한 인식 유지
Figure 4: Steps & its Activities for Developing SBOM Ecosystem at Organizational Level

3.3.1 PHASE-1 (START): 기초 활동

이 단계의 기초 활동들은 SBOM 프로그램의 기반을 마련합니다. 첫 SBOM은 조달 과정에서 공급업체로부터 획득할 가능성이 높습니다. 소프트웨어는 아키텍처, 기존 리소스, 예산, 인력 가용성 측면에서 다양할 수 있으므로, 이 단계의 목적은 조직 내 SBOM 생태계 구축 방법을 수립하는 것입니다.

  • 3.3.1.1 중요 자산 식별 및 프로젝트 계획 수립: 역할, 책임, 일정, 리소스 요구사항을 정의하는 종합적인 프로젝트 계획을 수립합니다. 새로운 SBOM 프로세스에 대한 이해관계자의 동의를 얻기 위한 변경 관리 요구사항도 식별합니다.

  • 3.3.1.2 SBOM 형식 및 최소 요구사항 결정: SBOM 생성 전에 형식과 최소 데이터 요구사항을 정의합니다. 이는 공급망 전반에 걸쳐 일관된 공유와 처리가 가능한 표준화된 기계 판독 가능 구조를 보장합니다.

  • 3.3.1.3 보안 요구사항, 안전한 저장소 및 도구 식별: 사이트 보안 정책에 맞는 적절한 분류 및 처리 절차를 결정합니다. SBOM을 위한 안전한 저장소를 구축하고, 초기에는 개별 SBOM을 전용 저장소에 분리 저장합니다. SBOM 프로그램이 성숙해지면 자산 관리 애플리케이션과 통합하고 취약점 데이터 등 다른 보안 관련 정보와 연결합니다.

  • 3.3.1.4 조달 과정의 일부로 SBOM 획득: 구매 주문서나 계약서에 공급업체의 SBOM 제공 요구사항을 명시하고, SBOM 요소, 제공 시기 및 방법을 지정하여 투명성을 보장하고 SBOM 통합 프로세스를 용이하게 합니다.

3.3.2 PHASE – 2 (PROGRESS)

이 단계는 안전한 설치 및 구성 관리를 확립하고, 공급업체 및 구성 요소 네임스페이스 문제를 해결하기 위해 고유한 구성 요소 식별을 통합하는 지속적인 활동을 포함합니다. 소프트웨어 개발 조직에 의한 보안 소프트웨어 개발 수명주기(SSDLC)와의 통합은 빌드 단계에서 소프트웨어를 보호하기 위한 실행 가능한 보안 정보를 제공하기 시작할 것입니다.

  • 3.3.2.1 안전한 설치 및 운영 지침 개발: 공급업체는 소비자 조직과 협력하여 대상 소비자의 기술 분야와 사용 요구에 맞춘 포괄적인 안전한 소프트웨어 설치 및 운영 체크리스트를 작성해야 합니다. 안전한 운영을 보장하기 위해 안전한 애플리케이션 설계, 개발, 구현 및 운영 지침에서 핵심 체크리스트 항목을 도출할 수 있으며, 이는 애플리케이션 수명 주기의 배포 및 운영 단계에서 다루어야 할 필수 고려 사항을 강조합니다.

  • 3.3.2.2 각 구성 요소에 고유 식별자 할당: 소비자가 리브랜딩을 인식하지 못하면 보안 업데이트나 취약점을 간과할 수 있어 악용에 취약해질 수 있습니다. 이로 인해 소비자가 자체 SBOM에 포함할 정확한 데이터 필드(예: 현재 공급업체 및 구성 요소 이름)를 조사하기 어려워집니다. 공급업체 및 구성 요소 이름 변경은 SBOM 수정과 이전 SBOM에서 후속 버전으로의 링크를 통해 수정 이력을 유지해야 합니다. 이를 해결하기 위해 고유 식별자를 생성해야 합니다.

Table 3: 고유 식별자의 구문 및 예시

필드설명예시
scheme식별자의 형식을 나타냄, 이 경우 Package URL (PURL) 형식의 pkgpkg
type식별자의 유형을 지정, 이 경우 소프트웨어 구성 요소의 공급업체를 나타내는 suppliersupplier
namespace소프트웨어 구성 요소의 공급업체인 조직 또는 주체의 이름을 식별Apache Software Foundation
name소프트웨어 구성 요소 자체의 이름을 제공Apache Tomcat
version소프트웨어 구성 요소의 특정 버전을 나타냄9.0.71
qualifiers (선택사항)아키텍처, 운영 체제 또는 기타 메타데이터와 같은 소프트웨어 구성 요소에 대한 추가 맥락 정보 포함 가능arch=x86_64&os=linux
subpath (선택사항)해당되는 경우 소프트웨어 구성 요소 내의 하위 경로 또는 위치를 지정하는 데 사용 가능#server/webapps

위 시나리오에 대한 고유 식별자는 다음과 같습니다: pkg:supplier/ApacheSoftwareFoundation/ApacheTomcat@9.0.71?arch=x86_64&os=linux#server/webapps

Table 4: 고유 식별자의 유용성

문제Apache Tomcat 예시고유 식별자가 도움이 되는 방법
소유권 및 브랜딩 변경• 초기에 Apache Tomcat은 Apache Software Foundation에서 개발 및 유지 관리했습니다.
• 시간이 지나면서 소유권이 변경될 수 있고, 새 소유자가 프로젝트를 리브랜딩할 수 있습니다(예: “TomcatX” 또는 “Acme Tomcat”).
• pkg:supplier/Apache Software Foundation/Apache Tomcat@9.0.71?arch=x86_64&os=linux 식별자는 소유권 및 브랜딩 변경에도 여전히 유효합니다.
• 소비자는 SBOM을 새 식별자 pkg:supplier/Acme Corp/TomcatX@9.0.71?arch=x86_64&os=linux로 업데이트하여 이전 및 새 구성 요소 이름 간의 연결을 유지할 수 있습니다.
버전 모호성• 공급업체가 Apache Tomcat의 새 버전(예: 10.0.0)을 출시하지만 동일한 구성 요소 이름을 유지합니다.• 고유 식별자 pkg:supplier/Apache Software Foundation/Apache Tomcat@9.0.71?arch=x86_64&os=linux는 특정 버전(9.0.71)을 명확히 나타냅니다.
• 새 버전이 출시되면 소비자는 SBOM을 pkg:supplier/Apache Software Foundation/Apache Tomcat@10.0.0?arch=x86_64&os=linux로 업데이트하여 버전 모호성을 제거할 수 있습니다.
  • 3.3.2.3 공급업체의 SBOM과 소비자의 내부 SBOM 매핑: 소비자 조직은 공급업체가 제공한 SBOM을 기반으로 내부 SBOM을 매핑하고 개발해야 합니다. 또한 내부 SBOM 개발자의 무결성과 효율적인 업데이트를 추적하기 위해 작성자 이름(소비자 조직의 담당자)과 타임스탬프를 포함해야 합니다.

  • 3.3.2.4 SBOM 준비: SBOM은 공급업체와 소비자 조직 모두에서 준비해야 합니다. 알려진 취약점 데이터와 공급업체 취약점 증명을 상호 연관시켜 취약점이 있는 설치된 구성 요소를 식별합니다. 이를 바탕으로 조직 내부적으로 또는 소프트웨어 공급업체에 의해 외부적으로 complete-level SBOM을 생성하여 공급망 공격에 대한 보안과 가시성을 향상시켜야 합니다.

  • 3.3.2.5 보안 소프트웨어 개발 수명주기의 각 단계에 SBOM 통합: 소프트웨어 개발 조직은 SSDLC의 각 단계에 SBOM을 통합할 수 있습니다. 설계 단계에서 SBOM은 구성 요소 선택 및 잠재적 보안 위험에 대한 결정을 알려야 합니다. 소프트웨어 개발 중 SBOM 사용은 효율성을 향상시키고 개발자와 사용자 모두에게 빌드 및 소스 구성 요소뿐만 아니라 제품 기능에 대한 더 큰 통찰력을 제공할 수 있습니다.

  • 3.3.2.6 안전한 구성 관리 수립: SBOM의 안전한 구성 관리를 보장하기 위해 엄격한 접근 제어, 암호화, 주기적인 소프트웨어 감사 및 보안 프레임워크와의 통합을 구현합니다.

3.3.3 PHASE-3 (ADVANCE):

취약점 모니터링과 취약점 관리 및 사고 대응을 위한 security orchestration tool과 SBOM의 원활한 통합 관련 활동 강화

  • 3.3.3.1 취약점 추적 프로세스 강화: SBOM과 연관된 취약점 정보를 수집합니다. 과거 취약점 정보는 SBOM 생태계에 통합되어야 하며, 전문가들은 SBOM repository에 나열된 component와 식별된 취약점을 상호 참조하고 관련 구성 데이터에 대한 장비 데이터베이스를 확인하여 알려진 취약점의 추적 및 분석을 위한 영향과 잠재적 완화 조치를 평가하는 절차를 보유해야 합니다.

  • 3.3.3.2 사고 대응 프로세스 강화: CERT-In은 다양한 위협에 대한 경고, 취약점 노트 및 권고사항을 발행합니다. 이러한 위협은 주로 새롭게 공개된 소프트웨어 취약점과 관련이 있습니다. 조직은 threat hunting team을 구성하여 이 정보를 활용해 새로 발견된 위협에 대해 조직이 취약한지, 그리고 이미 침해당했는지 여부를 판단해야 합니다.

  • 3.3.3.3 기존 SBOM 업데이트를 위한 정기적 분석 및 검토: 소프트웨어 component와 그 dependency가 최신 기록과 일치하는지 확인하고 적시에 업데이트를 보장하는 작업을 포함합니다.

  • 3.3.3.4 새로운 소프트웨어 component와 산업 발전에 대한 인식 유지: 조직은 SBOM 실무자들이 직면한 과제를 준수하면서 조직 내 구현, 새로운 SBOM 형식, 데이터 요소에 대한 정보를 공유하기 위해 독립적으로 또는 third-party 조직과 협력하여 SBOM 인식 프로그램을 유지하도록 권장됩니다.

3.4 라이선스 관리

라이선스 관리는 SBOM의 초기 활용 사례 중 하나입니다. 이는 복잡한 소프트웨어 포트폴리오를 가진 큰 조직이 다양한 소프트웨어 구성 요소의 라이선스와 조건을 추적하는 데 도움을 줍니다. 특히 오픈 소스 소프트웨어에 대해 중요합니다. SBOM은 각 구성 요소의 라이선스 정보를 제공할 수 있어, 사용자가 법적 위험 없이 해당 소프트웨어를 다른 애플리케이션의 구성 요소로 사용할 수 있는지 판단할 수 있게 합니다. 소프트웨어에 포함된 구성 요소의 라이선스 정보를 확인하면 규정 준수 실수를 방지하고, 라이선스 위반 위험과 관리에 필요한 노력을 줄일 수 있습니다.

다음은 라이선스 관리 과정을 간소화하고 규정 미준수 위험을 줄이는 데 도움이 되는 방법들입니다:

  1. 사용자가 평가 중인 제품의 라이선스와 모든 개별 구성 요소의 라이선스를 볼 수 있어야 합니다. 이를 통해 사용자는 제품 선택과 비즈니스 요구에 맞는 라이선스 계약 결정에 더 나은 판단을 할 수 있습니다.

  2. SPDX 식별자와 같은 식별자로 각 소프트웨어 라이선스를 구분합니다. 이 식별자들은 특정 라이선스 조건을 나타내는 고유 코드 역할을 합니다. 조직은 이를 활용해 소프트웨어 자산의 라이선스 의무를 효과적으로 관리하고 이해해야 합니다.

  3. 주요 데이터베이스에서 라이선스 식별자를 찾을 수 없다면, Scancode, LicenseDB, AboutCode 같은 다른 라이선스 데이터베이스를 살펴봐야 합니다. 이런 대체 식별자에는 출처를 나타내는 접두사(예: “LicenseRef-scancode-")를 붙여 쉽게 파악하고 이해할 수 있게 해야 합니다.

  4. SPDX 같은 잘 알려진 목록에 없는 라이선스를 만나면, 조직은 고유한 식별자를 부여해야 합니다. 이렇게 하면 시스템 내에서 알려지지 않은 라이선스를 제대로 식별하고 추적할 수 있습니다.

  5. 라이선스를 자리 표시자나 템플릿으로 수정할 때는 기본 조건이 바뀌지 않도록 주의해야 합니다. 대신 SPDX 라이선스 표현 같은 고유 식별자로 구분되는 원본 라이선스의 일부로 봐야 합니다. 이는 라이선스 관리의 명확성과 일관성을 유지하는 데 도움이 됩니다.

  6. 소프트웨어에 여러 라이선스가 적용될 때는 연산자(예: SPDX 연산자)를 사용해 올바르게 조합하는 것이 중요합니다. 이 연산자들은 서로 다른 라이선스 식별자를 연결해 라이선스 표현의 명확성과 일관성을 보장합니다. 이를 통해 소프트웨어에 적용되는 라이선스 조건을 정확히 나타낼 수 있습니다.

  7. 라이선스 관리 시 라이선스 텍스트에 붙은 예외 조항은 “WITH” 같은 적절한 연산자를 써서 주 라이선스 식별자와 연결해야 합니다. 또한 예외 조항 이름은 라이선스 식별에 대한 정해진 요구 사항에 따라 식별자로 설명되어야 합니다.

  8. 라이선스 텍스트를 조금 바꿀 때, 수정 내용이 원본 라이선스의 의미를 크게 바꾸지 않는다면 원본 라이선스와 같은 식별자를 쓰는 것이 좋습니다.

4. SBOM 준비

4.1 SBOM의 최소 요소

SBOM의 최소 요소는 소프트웨어 구성 요소와 관련된 필수 정보인 “Data Fields"를 규정합니다. “Automation Support” 탐지 및 관리는 보안 오케스트레이션 도구와 조직의 SBOM 구현을 위한 “Process 및 Practice"와 통합하여 개선될 수 있습니다. “Minimum Elements"의 범주와 정의는 다음과 같습니다.

Table 5: SBOM의 최소 요소

최소 요소개요정의
Data Fields추적해야 할 각 구성 요소에 대한 기본 정보를 문서화이 기본 구성 요소 정보는 다음을 포함합니다:
• Component Name
• Component Version
• Component Description
• Component Supplier
• Component License
• Component Origin
• Component Dependencies
• Vulnerabilities
• Patch Status
• Release Date
• End-of-Life (EOL) Date
• Criticality
• Usage Restrictions
• Checksums or Hashes
• Comments or Notes
• Author of SBOM Data
• Timestamp
• Executable Property
• Archive Property
• Structured Property
• Unique Identifier
Automation Support소프트웨어 생태계 전반에 걸쳐 확장할 수 있도록 자동 생성 및 기계 판독성을 포함한 자동화 지원SBOM을 생성하고 사용하는 데 활용되는 데이터 형식은 다음을 포함합니다:
• Software Package Data Exchange (SPDX)
• CycloneDX
Practices and ProcessesSBOM 요청, 생성 및 사용의 운영을 정의조직의 SBOM 운영 절차 정의는 다음을 기반으로 해야 합니다:
• Frequency
• Depth
• Known Unknowns
• Distribution and Delivery
• Access Control
• Accommodation of Mistakes

4.2 Data Fields

Data fields는 추적하고 유지해야 하는 각 구성 요소에 대한 기본 정보를 포함합니다. 조직은 소프트웨어 구성 요소, dependency, 관련 메타데이터의 포괄적인 목록을 만들어 소프트웨어 개발 수명 주기 전반에 걸쳐 더 나은 투명성, 보안 및 위험 관리를 가능하게 할 수 있습니다.

Data fields의 목적은 이러한 구성 요소를 적절히 식별하는 것입니다. 이를 통해 소프트웨어 공급망 전반에 걸쳐 추적이 쉬워지고 취약점이나 라이선스 데이터베이스 같은 다른 유용한 데이터 소스와 연결할 수 있습니다. 기본 구성 요소 정보는 다음을 포함합니다:

  1. Component Name: SBOM에 포함된 소프트웨어 구성 요소나 library의 이름
  2. Component Version: 소프트웨어 구성 요소의 버전 번호나 식별자
  3. Component Description: 소프트웨어 구성 요소의 기능과 목적에 대한 간단한 설명
  4. Component Supplier: vendor, third-party supplier 또는 오픈소스 프로젝트와 같이 소프트웨어 구성 요소를 제공한 주체나 조직
  5. Component License: 소프트웨어 구성 요소가 배포되는 라이선스로, 라이선스 유형, 조건 및 제한 사항과 같은 세부 정보 포함
  6. Component Origin: 소프트웨어 구성 요소의 출처나 기원(독점, 오픈소스 또는 third-party vendor에서 획득)
  7. Component Dependencies: 현재 구성 요소가 의존하는 다른 소프트웨어 구성 요소나 library(이름과 버전 포함)
  8. Vulnerabilities: 소프트웨어 구성 요소와 관련된 알려진 보안 취약점이나 약점에 대한 정보(심각도 등급 및 보안 권고 또는 CVE 식별자에 대한 참조 포함)
  9. Patch Status: 알려진 취약점이나 문제를 해결하기 위한 패치나 업데이트의 가용성을 나타내는 소프트웨어 구성 요소의 패치 또는 업데이트 상태
  10. Release Date: 소프트웨어 구성 요소가 출시되거나 사용 가능하게 된 날짜
  11. End-of-Life (EOL) Date: 소프트웨어 구성 요소에 대한 지원이나 유지보수가 종료되도록 예정된 날짜로, 수명 주기의 종료를 나타냄
  12. Criticality: 애플리케이션의 전반적인 기능이나 보안에 대한 소프트웨어 구성 요소의 중요도(주로 critical, high, medium, low로 분류)
  13. Usage Restrictions: 수출 통제 제한이나 지적 재산권과 같이 소프트웨어 구성 요소와 관련된 사용 제한이나 제약 사항
  14. Checksums or Hashes: 무결성과 신뢰성을 보장하기 위한 소프트웨어 구성 요소 파일의 암호화 체크섬이나 해시
  15. Comments or Notes: 소프트웨어 구성 요소나 SBOM 포함과 관련된 추가 설명, 메모 또는 주석
  16. Author of SBOM Data: 이 구성 요소에 대한 SBOM 데이터를 생성하는 주체의 이름
  17. Timestamp: SBOM 데이터 조립의 날짜와 시간 기록
  18. Executable Property: SBOM 내의 구성 요소가 실행 가능한지를 나타내는 속성
  19. Archive Property: SBOM 내의 구성 요소가 아카이브나 압축 파일로 저장되어 있는지를 나타내는 특성
  20. Structured Property: SBOM에 나열된 구성 요소 내 데이터의 구성된 형식을 정의하는 설명자
  21. Unique Identifier: 각 소프트웨어 구성 요소에 할당된 고유 코드로, “pkg:supplier/OrganizationName/ComponentName@Version?qualifiers&subpath” 형식으로 구성되어 소유권 변경과 버전 업데이트를 추적하여 정확하고 일관된 소프트웨어 구성 요소 관리를 보장

Table 6: 조직별 시나리오에서 활용된 Component의 Data Fields

Component NameApache TomcatPostgreSQLPostfixTwilio SDK
Version9.0.4113.33.5.67.17.0
Description오픈소스 Java 웹 서버오픈소스 관계형 데이터베이스 관리 시스템오픈소스 메일 전송 에이전트(MTA)SMS 송수신을 위한 Twilio API SDK
SupplierApache Software FoundationPostgreSQL Global Development GroupPostfix Development TeamTwilio Inc.
LicenseApache Software FoundationPostgreSQL LicenseIBM Public License v1.0Apache License 2.0
OriginApache License 2.0Open-source communityOpen-source communityVendor
DependenciesOpen-source communityNoneNoneNone
VulnerabilitiesJava Runtime Environment (JRE)None reportedNone reportedNone reported
Patch StatusNone reportedUp to dateUp to dateUp to date
Release DateUp to dateMay 7, 2021October 15, 2020January 10, 2022
End of Life DateMarch 22, 2021May 7, 2026October 15, 2025January 10, 2027
CriticalityMarch 22, 2025HighHighMedium
Usage RestrictionsHighNoneNoneTwilio 계정이 필요한 API 접근
ChecksumsNoneSHA-256: d7f5a6b198e75c1f38d0fa158a9bc92SHA-256: 3bd5a7f02a81022a47a7e6cb9cb5e2b8SHA-256: 9f3b2e5ab24a5e68a3bda6a12c1febd1
HashesSHA-256: 7f87a8b8ed5c23546789b8d758621 9a1MD5: b8c78139eef440fb3cb074e199b1e923MD5: e57cb8d0ae875fda9d60291f10689e4bMD5: 6a8c4db98ce5f0c3a92416727bc80a5e
CommentsMD5: 8937d8b1a947f45d79e457b91c2e6543SQL 쿼리와 ACID 트랜잭션을 지원메일 서버 간 이메일 전송을 용이하게 함Twilio의 클라우드 통신 플랫폼을 통해 애플리케이션에 SMS 기능을 통합
Executable PropertyYes - catalina.sh와 startup.bat 같은 실행 가능한 바이너리 포함No - postgres와 같은 바이너리는 직접 실행할 수 없음No - postfix와 같은 바이너리는 직접 실행할 수 없음No - SDK 자체는 직접 실행할 수 없으나, 애플리케이션에서 사용할 수 있는 library와 module 포함
Archive PropertyNo - 디렉토리 구조로 배포No - postgresql.conf를 포함한 설치 파일 세트로 배포No - main.cf를 포함한 설치 파일 세트로 배포Yes - twilio-python.tar.gz 또는 twilio-java.jar와 같은 패키지나 library 아카이브 파일로 배포
Structured PropertyYes - server.xml과 같은 설정 파일에 정의된 요소 있음Yes - schema.sql과 같은 파일에 구조화된 데이터베이스 스키마 포함Yes - main.cf와 master.cf와 같은 설정 파일에 구조화된 형식 포함Yes - twilio.py 또는 twilio.xml과 같은 API 메소드와 설정을 정의하는 구조화된 파일 포함
Unique Identifierpkg:supplier/ApacheSoftwareFoundation/ApacheTomcat@9.0.71?arch=x86_64&os=linux#server/webappspkg:supplier/PostgreSQLGlobalDevelopmentGroup/PostgreSQL@13.5?arch=x86_64&os=linuxpkg:supplier/PostfixFoundation/Postfix@3.6.2?arch=x86_64&os=linuxsupplier/TwilioInc/TwilioSDK@1.20.0?arch=x86_64&os=linux

4.3 Automation Support

자동 생성 및 기계 판독성과 같은 자동화 지원은 소프트웨어 생태계와 조직 경계를 넘어 확장을 가능하게 합니다. SBOM 데이터를 다양한 도구와 프로세스에 원활하게 통합하여 소프트웨어 공급망 전반에 걸친 협업과 가시성을 촉진합니다.

자동화 기능설명
Component Discovery자동화된 도구는 소프트웨어 패키지, repository 및 소스 코드를 스캔하여 구성 요소를 식별하고 카탈로그화할 수 있습니다. 이는 수동 개입 없이 구성 요소의 초기 목록을 생성하는 데 도움이 됩니다.
Version Tracking자동화 도구는 소프트웨어 repository와 패키지 관리자를 모니터링하여 소프트웨어 구성 요소의 변경 사항과 업데이트를 추적할 수 있습니다. 이는 SBOM이 구성 요소의 최신 버전으로 유지되도록 보장하여 오래되거나 취약한 소프트웨어를 사용할 위험을 줄입니다.
Dependency Analysis자동화된 dependency 분석 도구는 소프트웨어 구성 요소 간의 dependency를 자동으로 식별하고 문서화할 수 있습니다. 이는 복잡한 관계를 이해하고 변경이나 취약점의 잠재적 영향을 평가하는 데 도움이 됩니다.
Vulnerability Assessment자동화된 취약점 스캐닝 도구는 소프트웨어 구성 요소를 NVD(National Vulnerability Database) 또는 CVE(Common Vulnerabilities and Exposures)와 같은 알려진 취약점 데이터베이스와 대조하여 분석할 수 있습니다.
License Compliance자동화된 라이선스 스캐닝 도구는 소프트웨어 구성 요소를 분석하여 배포되는 라이선스를 식별할 수 있습니다. 이는 라이선스 요구사항 compliance를 보장하고 독점 또는 오픈소스 소프트웨어의 무단 사용과 관련된 법적 문제를 방지하는 데 도움이 됩니다.
SBOM Generation자동화된 SBOM 생성 도구는 소프트웨어 repository, 패키지 매니페스트 및 취약점 데이터베이스와 같은 다양한 소스에서 정보를 수집하여 포괄적인 SBOM을 자동으로 생성할 수 있습니다. 이는 SBOM 생성 과정을 간소화하고 여러 프로젝트에 걸쳐 일관성과 정확성을 보장합니다.
Integration with DevOps Pipelines자동화 도구는 SBOM 생성과 분석을 DevOps pipeline에 통합하여 개발 수명 주기 전반에 걸쳐 소프트웨어 구성 요소의 지속적인 모니터링과 평가를 가능하게 할 수 있습니다. 이를 통해 보안 위험과 compliance 문제를 사전에 식별하고 완화할 수 있습니다.
Reporting and Visualization자동화된 보고 및 시각화 도구는 SBOM 데이터에서 실행 가능한 통찰력을 생성할 수 있습니다. 예를 들어 고위험 구성 요소 식별, compliance 상태 추적 및 dependency 그래프 시각화가 있습니다. 이는 이해관계자가 위험 완화 및 개선을 위한 정보에 입각한 결정을 내리고 우선순위를 정하는 데 도움이 됩니다.
Integration with Security Orchestration Platforms자동화 도구는 보안 오케스트레이션 플랫폼과 통합하여 SBOM 분석 결과를 기반으로 수정 워크플로우를 자동화할 수 있습니다. 이를 통해 보안 취약점을 완화하기 위한 패치, 업데이트 또는 구성 변경의 자동 배포가 가능합니다.
Monitoring and Maintenance자동화 도구는 구성 요소 정보 업데이트, 변경 사항 추적 및 이상이나 compliance 위반에 대한 경고 생성을 통해 SBOM의 지속적인 모니터링과 유지 관리를 용이하게 할 수 있습니다.

Figure 5: SBOM의 Automation Support 이점

SBOM 데이터를 활용하기 위해서는 일관된 데이터 형식과 구현이 필요한 도구가 필요합니다. 자동화는 SBOM의 생성, 유지 관리 및 활용의 여러 측면을 지원할 수 있습니다. 이는 일관성 있는 변경 사항 구현, 시간 절약, 취약점 관리 개선 등 다양한 이점을 제공합니다. 자동화된 SBOM 생성은 감사 및 규정 준수 절차를 간소화하고 보안 취약점에 대한 대응 시간을 단축시킵니다. 조직은 이 기능을 현재의 취약점 관리 절차와 보안 정책의 실시간 감사 compliance에 포함할 수 있습니다. 두 가지 모두 표준화된 기계 판독 가능한 데이터 형식을 필요로 하는 자동화에 크게 의존합니다. SBOM을 생성하고 사용하는 데 사용되는 표준 형식은 다음과 같습니다:

  1. Software Package Data eXchange (SPDX)
  2. CycloneDX

5. 소프트웨어 Consumer/Developer/Integrator 조직을 위한 SBOM 프로세스와 관행

이 섹션에서는 실무자들이 SBOM을 어떻게 인식해야 하며, 실제로 이를 다루기 위해 어떤 프로세스를 수립해야 하는지 논의합니다. 이 장에서 언급된 주제들은 SBOM 생성, 배포 및 공유, 검증 및 확인, 취약점 및 악용 가능성 관리와 같은 SBOM 관행의 분석에서 도출되었습니다.

5.1 역할과 책임 수립

SBOM을 구현하기 위해서는 필요한 역할과 책임을 식별해야 합니다. 여기에는 관리 후원자, 프로젝트 리더, 시스템 엔지니어, 설계 엔지니어, 조달 전문가 및 운영 담당자가 포함되어야 합니다. 프로젝트 일정과 보안 요구사항에 따라 IT, 사이버보안 및 유지보수 인력과 같은 추가 지원을 포함시켜야 합니다. 이러한 역할들 간의 명확한 소유권과 협력을 보장하여 SBOM 구현과 기존 프로세스와의 통합을 추진해야 합니다.

image.png

Figure 6: 역할 및 책임 수립 단계

  1. 주요 이해관계자 식별: SBOM 프로그램의 주요 이해관계자를 식별하기 위해 조직은 소프트웨어 개발, IT 운영, 보안, 조달, 비즈니스 리더십, compliance 팀 및 규제 기관의 대표자를 고려해야 합니다. 보안 데이터 처리, 취약점 관리 및 위험 평가에 대한 전문 지식을 제공하기 위해 사이버보안 전문가를 포함해야 합니다.

  2. SBOM 관련 책임 정의: SBOM 생성, 소비, 취약점 모니터링, supplier 참여 및 보안 데이터 관리와 같은 작업을 설명합니다. 다음과 같은 사이버보안 중심의 책임을 할당합니다: 민감도와 위험에 따른 SBOM 데이터 분류, 보안 SBOM 저장소 및 접근 제어 구현, 취약점 관리 및 사고 대응 프로세스와 SBOM 데이터 통합.

  3. 역할 및 소유권 할당: 사이버보안 전문가를 SBOM 프로그램 소유자 또는 공동 소유자로 지정하여 전반적인 보안이 보장되도록 합니다. 사이버보안 팀이 핵심 역할을 수행하면서 이해관계자의 전문성을 기반으로 SBOM 책임을 할당합니다.

  4. 거버넌스 수립: 거버넌스 구조는 첫 번째 포인트에서 논의된 대로 조직 전반의 주요 이해관계자를 포함해야 합니다. 이 거버넌스 기구는 SBOM 관련 정책, 표준, 프로세스를 개발하고 명확한 책임을 할당하며, SBOM 데이터를 보호하기 위한 통제를 구현합니다.

  5. 협업 활성화: 소프트웨어, IT 및 사이버보안 팀 간의 부서 간 협업을 촉진하여 SBOM 보안 과제를 해결합니다. 보안 SBOM 관행, 새로운 위협 및 최고 수준의 보안 통제에 대한 지식 공유를 장려합니다.

  6. 교육 및 리소스 제공: SBOM 보안 요구사항, 보안 데이터 처리 및 SSDLC의 각 단계와 SBOM 통합에 대한 전문 교육을 제공합니다. 팀에 보안 SBOM 생성, 저장 및 소비 도구와 취약점 관리 및 위협 인텔리전스 리소스를 제공합니다.

  7. 모니터링 및 개선: 조직은 정기적인 감사와 평가를 수행해야 합니다. 여기에는 SBOM 프로그램의 보안 태세를 지속적으로 평가하고 진화하는 위협과 compliance 요구사항을 해결하기 위한 조정이 포함되어야 합니다.

5.2 SBOM 기능 탐색을 위한 로드맵

이 섹션에서는 SBOM의 세 가지 주요 측면인 관행, 도구 지원 및 관련 문제의 목표를 탐구합니다. 이를 통해 소프트웨어 Developer/Consumer/Integrator 조직에게 다양한 기능을 탐색하고 SBOM의 특정 측면에서 실제로 달성해야 할 사항에 대한 로드맵을 제공합니다.

Table 7: SBOM 개념의 목표

SBOM Functions목표
Benefits• SBOM의 주요 이점은 소프트웨어 제품에 대한 향상된 투명성과 가시성이어야 하며, 이는 잠재적인 SBOM 중심 생태계의 기반이 됩니다.
• SBOM의 장점은 SBOM과 지원 도구의 학습 및 관리와 관련된 비용보다 커야 합니다.
Adoption• third-party(오픈소스 또는 독점) component에는 SBOM이 갖춰져 있어야 합니다.
• 조직 내의 모든 소프트웨어 제품(생산/사용)에 대해 SBOM이 생성되어야 합니다.
Generation Points• SBOM은 소프트웨어 개발 수명 주기의 다양한 단계에서 생성되어야 합니다.
• 소프트웨어 산출물에 변경이 있을 때마다 새로운 SBOM이 항상 재생성되어야 합니다.
Data Fields & standardization• SBOM은 기존의 최소 요소 수와 표준 형식 외에도 데이터 필드와 형식 측면에서 조직별 특정 사용 사례로 사용자 정의되어야 합니다.
Distribution• 내부 사용을 위한 SBOM을 생성하고 적절한 접근 제어를 보장하며, 독점 소프트웨어나 component를 배포할 때는 부분 SBOM 공유를 위한 콘텐츠 조정을 고려합니다.
Validation• supplier는 SBOM의 무결성을 보장하기 위해 검증해야 합니다.
Vulnerability & Exploitability• supplier는 consumer 조직에 Vulnerability Exchange Document를 제공해야 합니다.
Tools• SBOM 소비를 취약점 또는 구성 관리 시스템과 같은 현재 도구와 통합합니다.

5.3 보안 SBOM 배포: 접근 제어와 Public/Private SBOM

SBOM 데이터를 안전하게 통합하고 관리하려면 명확한 조건이 정의되어야 합니다. 이러한 조건은 라이선싱, 계약, 또는 소프트웨어 사용 및 권한 관리를 위한 기존 메커니즘을 통해 수립될 수 있습니다. supplier(오픈소스 관리자 포함)는 public SBOM 데이터를 선호할 수 있지만, 일부는 기밀성을 유지하며 특정 사용자에게만 접근을 제한할 수 있습니다. 이러한 단계를 통해 조직은 SBOM의 안전하고 통제된 배포를 구현하여 민감한 정보가 승인된 당사자에게만 접근 가능하도록 하면서도 소프트웨어 공급망의 투명성과 신뢰를 유지할 수 있습니다.

5.3.1 접근 제어

  • 5.3.1.1 SBOM 데이터에 대한 접근을 관리하기 위한 role-based access control (RBAC) 시스템을 정의합니다.
  • 5.3.1.2 다양한 이해관계자(예: developer, security team, supply chain partner)와 각자의 접근 요구사항을 식별합니다.
  • 5.3.1.3 각 역할에 적합한 권한과 특권을 할당합니다(예: 일반 사용자를 위한 읽기 전용 접근, SBOM 관리자를 위한 편집 및 업데이트 접근, 민감하거나 기밀인 SBOM 데이터에 대한 제한된 접근).

5.3.2 Public 및 Private SBOM

  • 5.3.2.1 SBOM의 두 가지 버전을 유지:
    • a) Public SBOM: 모든 이해관계자와 공유 가능한 비민감 정보를 포함합니다.
    • b) Private SBOM: 승인된 당사자만 접근할 수 있는 취약점과 같은 민감하거나 기밀 정보를 포함합니다.

5.3.3 보안 배포 메커니즘

  • 5.3.3.1 HTTPS와 같은 보안 통신 프로토콜을 활용하여 당사자 간 SBOM 데이터를 전송합니다.
  • 5.3.3.2 디지털 서명이나 암호화를 구현하여 SBOM 데이터의 무결성과 기밀성을 보장합니다.
  • 5.3.3.3 접근 제어 및 감사 기능을 제공하는 보안 파일 공유 플랫폼이나 도구를 사용합니다.

5.3.4 자동화된 SBOM 생성 및 업데이트

  • 5.3.4.1 최신 상태와 정확성을 유지하기 위해 SBOM 생성 프로세스를 software development lifecycle (SDLC)에 통합합니다.
  • 5.3.4.2 소프트웨어 구성 요소나 dependency에 변경이 발생할 때 SBOM 업데이트 프로세스를 자동화합니다.

5.3.5 SBOM 소비 및 검증

  • 5.3.5.1 SBOM 데이터를 소비하고 검증하는 방법에 대한 명확한 지침과 문서를 제공합니다.
  • 5.3.5.2 이해관계자가 특정 요구사항과 보안 정책에 따라 SBOM을 검증할 수 있는 프로세스와 도구를 개발합니다.

5.3.6 모니터링 및 감사

  • 5.3.6.1 SBOM 데이터에 대한 접근과 변경을 추적하기 위한 로깅 및 감사 메커니즘을 구현합니다.
  • 5.3.6.2 정의된 접근 제어 정책의 compliance를 보장하기 위해 접근 로그와 감사 추적을 정기적으로 검토합니다.

5.3.7 사고 대응 및 복구

  • 5.3.7.1 SBOM 데이터와 관련된 보안 사고나 침해를 처리하기 위한 사고 대응 절차를 수립합니다.
  • 5.3.7.2 취약점이나 사고의 영향을 신속히 평가하고 관련 이해관계자와 복구 노력을 조율하기 위한 프로세스를 구현합니다.

5.4 SBOM 공유

소프트웨어 공급망의 투명성, 보안 및 compliance를 높이기 위해서는 supplier와 사용자 간에 SBOM을 공유하는 것이 필요합니다.

조직 내부에서 SBOM 문서를 공유하면 development, security, operations 및 법률 팀이 프로젝트에서 사용되는 소프트웨어 구성 요소와 dependency에 대한 통찰력을 얻을 수 있습니다. 이는 투명성을 촉진하고 협업을 강화하며 라이선싱 및 보안 요구사항의 compliance를 용이하게 합니다.

SBOM 문서 공유는 외부 partner, supplier 및 vendor 간의 신뢰를 높이는 데도 기여하며, 소프트웨어 제품이나 시스템 내에서 구현된 구성 요소, 라이선싱, 보안 조치에 대한 감사 가능한 증거를 제공합니다.

SBOM 문서 공유는 다음과 같은 채널과 형식을 통해 촉진됩니다:

  1. Secure File Sharing Platform: 승인된 당사자와 안전하게 문서를 공유할 수 있는 환경 제공.
  2. API Integration: 시스템 간 자동화되고 안전한 데이터 교환 지원.
  3. Collaboration Tool: 프로젝트 관리 플랫폼이나 문서 공유 애플리케이션을 활용하여 팀 내부 또는 조직 간 안전한 공유 촉진.
  4. Industry Platform and Repository: 특정 산업이나 커뮤니티 내에서 문서의 공유와 배포를 촉진하기 위해 구축된 플랫폼 활용.

문서를 공유할 때는 클라이언트가 진위성을 확인하고 변조 여부를 검증할 수 있도록 디지털 서명을 첨부하는 것이 권장됩니다. 또한, 어떤 정보를 public 또는 private으로 설정해야 하는지 명확히 식별하는 것이 중요합니다.

6. SBOM의 취약점 추적 및 분석

이 챕터에서는 Software Bill of Materials (SBOM)를 사용한 취약점 추적 및 분석에 대해 Vulnerability Exchange Document (VEX)와 Common Security Advisory Framework (CSAF)를 통해 설명합니다. VEX는 취약점 정보의 표준화된 공유를 용이하게 하고, CSAF는 보안 권고사항을 설명하기 위한 구조화된 프레임워크를 제공합니다.

a) VEX Document 설계: Vulnerability Exchange Document (VEX)는 취약점이 발견된 후 소프트웨어 공급망 관리를 담당하는 조직이나 주체(예: supplier)가 설계해야 합니다. VEX는 consumer가 수정 작업의 우선순위를 정할 수 있도록 취약점의 악용 가능성 상태를 알리는 역할을 합니다. 여기에는 소프트웨어 developer, vendor 또는 조달 및 compliance 관련 조직으로 구성된 팀이 포함되어야 하며, 이들은 소프트웨어의 취약점 추적과 분석을 담당합니다. VEX document는 supplier가 수행한 시간과 함께 수정, 해결 방법, 재시작/다운타임 요구사항, 점수 및 위험을 포함하여 취약점의 각 업데이트마다 반복적으로 업데이트됩니다. VEX document는 특정 소프트웨어 제품의 취약점 상태에 대해 다음 사항을 포함해야 합니다:

  • Not affected - 이 취약점에 대한 수정이 필요하지 않음
  • Affected - 이 취약점을 수정하거나 해결하기 위한 조치가 권장됨
  • Fixed - 이러한 제품 버전에 취약점에 대한 수정사항이 포함되어 있음을 나타냄
  • Under Investigation - 이러한 제품 버전이 취약점의 영향을 받는지 여부가 아직 확인되지 않음. 추후 릴리스에서 업데이트가 제공될 예정

b) Common Security Advisory Framework (CSAF) 채택: VEX document 이후에 supplier는 취약점에 대한 설명, 영향을 받는 제품 버전, 심각도 평가 및 권장되는 완화 단계와 같은 자세한 정보가 포함된 CSAF 권고사항을 제공해야 합니다. 이는 다음 예시를 통해 이해할 수 있습니다:

image.png Figure 7: SBOM의 취약점 추적 및 분석 단계 시퀀스 예시

Log4j 취약점은 위 그림에 설명된 개념을 매핑하고 설명하는 예시로 사용됩니다:

  1. Vulnerability Discovery: 2021년 12월, 널리 사용되는 Log4j logging library에서 심각한 취약점이 발견되었습니다.
  2. VEX Publication (1주): 일주일 내에 Apache Software Foundation(Log4j의 관리자)은 취약점이 “Exploitable"이라고 명시한 VEX document를 발행했습니다.
  3. CSAF Publication (3주): 최초 발견 약 3주 후, Apache Software Foundation은 Log4j 취약점에 대한 상세 정보가 포함된 CSAF 권고사항을 발표했습니다. CSAF 권고사항에는 취약점 설명, 영향을 받는 버전, CVSS 점수 10.0(심각도 위험), 완화 단계가 포함되었습니다.
  4. Patch/Mitigation Instructions: CSAF 권고사항은 사용자가 Log4j의 패치된 버전으로 업데이트하거나 취약점을 해결하기 위한 다른 완화 조치를 구현하는 방법에 대한 지침을 제공했습니다.
  5. Ongoing Updates: Apache Software Foundation은 상황을 계속 모니터링하고 새로운 정보나 추가 완화 전략이 가용해짐에 따라 업데이트를 제공했습니다.
  6. SBOM Integration: Log4j library가 소프트웨어 구성 요소에 포함된 조직은 VEX와 CSAF 데이터를 자신의 SBOM에 통합하여 시스템의 영향을 받는 부분을 식별할 수 있었습니다. 이를 통해 수정 작업의 우선순위를 정하고 시스템이 Log4Shell 취약점으로부터 보호되도록 할 수 있었습니다.

c) 다양한 취약점 데이터베이스 및 권고사항과의 통합: supplier와 consumer는 SBOM 데이터를 취약점 데이터베이스, CERT-In 취약점 노트, 경고, 위협 인텔리전스 플랫폼 및 vendor별 권고사항과 통합하여 소프트웨어의 보안 상태에 대한 포괄적인 가시성을 확보할 수 있습니다. supplier는 SBOM 데이터를 직접 통합하여 구성 요소를 알려진 취약점에 매핑한 다음 향상된 SBOM을 customer에게 제공합니다. consumer는 API, 데이터 피드 또는 수동 프로세스를 활용하여 SBOM을 취약점 데이터와 통합함으로써 수정 작업을 식별하고 우선순위를 정할 수 있습니다.

d) Shift-left 접근 방식 및 취약점 스캐닝 구현: supplier는 보안 도구를 소프트웨어 개발 pipeline에 통합하여 shift-left 취약점 스캐닝을 구현해야 합니다. 이는 빌드 및 패키징 단계와 같은 SDLC의 초기 단계에서 소프트웨어 구성 요소의 취약점을 식별하기 위해 SBOM 데이터를 자동으로 분석하는 것을 포함합니다.

7. 권장사항 및 모범 사례

이 챕터에서는 소프트웨어 공급망 보안을 강화하기 위해 SBOM을 효과적으로 관리하기 위한 실용적인 권장사항과 모범 사례를 다룹니다.

7.1 권장사항

  • 7.1.1 모든 정부, 공공 부문, 필수 서비스 조직 및 소프트웨어 수출과 서비스 산업 관련 조직은 모든 소프트웨어와 솔루션 구매/조달에 SBOM 요구사항을 포함해야 합니다.

  • 7.1.2 정부, 공공 부문 및 필수 서비스 조직/부서에 공급되는 모든 소프트웨어는 complete SBOM이 동반되어야 합니다.

  • 7.1.3 모든 정부, 공공 부문 및 필수 서비스 조직/부서는 사용, 조달 및 개발 중인 소프트웨어의 SBOM을 유지해야 합니다.

  • 7.1.4 정부 및 공공 부문 조직/부서에 공급되는 소프트웨어의 SBOM은 이 문서의 4.2장에서 언급된 데이터 필드를 포함해야 합니다.

  • 7.1.5 정부 및 공공 부문 조직/부서에 공급되는 소프트웨어의 SBOM을 생성하는 형식은 Software Package Data eXchange (SPDX) 또는 CycloneDX여야 합니다.

  • 7.1.6 정부 및 공공 부문 조직/부서에 소프트웨어를 공급하는 소프트웨어 developer/integrator 조직은 취약점이 발견된 후 Vulnerability Exchange Document (VEX)를 설계하여 consumer가 수정 작업의 우선순위를 정할 수 있도록 악용 가능성 상태를 알려야 합니다. VEX document는 특정 소프트웨어 제품의 취약점 상태에 대해 다음을 포함해야 합니다:

    • Not affected - 이 취약점에 대한 수정이 필요하지 않음
    • Affected - 이 취약점을 수정하거나 해결하기 위한 조치가 권장됨
    • Fixed - 이러한 제품 버전에 취약점에 대한 수정사항이 포함되어 있음
    • Under Investigation - 이러한 제품 버전이 취약점의 영향을 받는지 여부가 아직 확인되지 않음. 추후 릴리스에서 업데이트가 제공될 예정

    VEX document 이후에 supplier는 취약점에 대한 설명, 영향을 받는 제품 버전, 심각도 평가 및 권장되는 완화 단계와 같은 상세 정보가 포함된 CSAF 권고사항을 제공해야 합니다.

  • 7.1.7 Software Developer/Consumer/Integrator 조직은 SBOM 데이터를 취약점 데이터베이스, CERT-In 취약점 노트, 경고, threat intelligence platform 및 vendor별 권고사항과 통합하여 소프트웨어의 보안 상태에 대한 포괄적인 가시성을 확보해야 합니다.

  • 7.1.8 Consumer 조직은 적용된 패치나 완화조치를 반영하기 위해 자체 SBOM을 업데이트해야 합니다.

  • 7.1.9 각 소프트웨어 버전에 대해 별도의 SBOM을 유지하고, 추가 구성 요소 정보가 제공되거나 SBOM 오류가 수정될 때만 업데이트합니다.

  • 7.1.10 Consumer 조직(특히 정부 및 공공 부문 조직)은 supplier가 제공한 SBOM을 기반으로 내부 SBOM을 매핑하고 개발해야 합니다.

  • 7.1.11 소프트웨어 consumer 조직의 보안 팀은 취약점 관리 워크플로우에 SBOM 목록을 포함해야 합니다.

  • 7.1.12 SBOM 프로세스의 정확성과 완전성을 보장하기 위해 정기적인 감사와 평가를 수행해야 합니다.

  • 7.1.13 Consumer 조직은 VEX의 취약점 상태 정보와 SBOM의 구성 요소 데이터를 결합하여 소프트웨어 취약점을 식별하고 해결하기 위한 표적화된 접근 방식을 가능하게 하는 취약점 상태의 최신 뷰를 제공해야 합니다.

  • 7.1.14 SBOM 데이터는 암호화, 접근 제어 및 기타 보안 조치를 사용하여 민감한 정보를 보호하면서 안전하게 저장되고 전송되도록 보장해야 합니다.

  • 7.1.15 새로운 소프트웨어 구성 요소가 도입되거나 기존 구성 요소가 업데이트될 때 SBOM을 정기적으로 업데이트하기 위한 워크플로우를 수립해야 합니다.

7.2 모범 사례

  • 7.2.1 구성 요소 이름, 버전, 라이선스 및 고유 식별자와 같은 상세한 메타데이터를 SBOM에 포함하도록 보장합니다.

  • 7.2.2 SBOM의 정확성과 적시성을 유지하기 위해 secure software development lifecycle (SSDLC) 및 CI/CD pipeline에 SBOM 생성을 통합합니다.

  • 7.2.3 심각도, 악용 가능성 및 잠재적 비즈니스 영향과 같은 요소를 기반으로 취약점 수정의 우선순위를 정하기 위한 위험 기반 접근 방식을 구현합니다.

  • 7.2.4 SBOM 데이터의 처리, 공유 및 배포를 위한 명확한 정책과 절차를 수립합니다.

  • 7.2.5 소프트웨어 공급망 보안과 관련된 compliance를 입증하고 규제 보고 의무를 충족할 수 있도록 SBOM 데이터를 생성해야 합니다.

  • 7.2.6 중요한 보안 이벤트에 대해 관련 이해관계자에게 즉시 알림을 제공하여 적시에 수정할 수 있도록 경보 시스템을 구현합니다.

  • 7.2.7 SBOM 분석을 통해 식별된 취약점의 수정 관리와 보안 사고 대응을 위한 상세한 플레이북을 개발합니다.

  • 7.2.8 암묵적 신뢰 가정을 제거하여 보안을 강화하기 위해, 네트워크에 연결하려는 모든 사용자와 장치를 검증하는 zero-trust 보안 모델을 채택합니다.

  • 7.2.9 시스템과 데이터에 대한 무단 접근의 위험을 줄이기 위해 추가 보안 계층으로 Multi Factor Authentication (MFA) 메커니즘을 구현합니다.

  • 7.2.10 보안 취약점을 신속하게 식별하고 해결하기 위해 정기적인 취약점 평가와 측정을 수행합니다.

  • 7.2.11 취약점을 감지하고 신속하게 해결하기 위해 소프트웨어 구성 요소와 dependency에 대한 지속적인 모니터링을 구현합니다.

  • 7.2.12 제공된 SBOM의 정확성, 완전성 및 적시성에 대해 third-party 소프트웨어 vendor와 supplier로부터 보증을 받고, SBOM 요구사항 compliance를 보장하기 위한 계약 협약을 수립합니다.

  • 7.2.13 애플리케이션이나 소프트웨어 내의 모든 소프트웨어 구성 요소의 라이선스가 서로 호환되는지 확인하기 위한 철저한 분석을 수행합니다. 서로 다른 라이선스가 적용된 구성 요소를 결합할 때 발생할 수 있는 충돌이나 제한사항을 식별합니다.

  • 7.2.14 SBOM에 대한 변경, 추가 또는 업데이트와 함께 VEX document와 CSAF 기반 권고사항의 제공 및 정기적인 업데이트를 보장합니다.

  • 7.2.15 developer부터 security team까지 모든 직원에게 SBOM의 중요성과 소프트웨어 공급망 보안 강화에서의 역할에 대한 포괄적인 교육 및 인식 프로그램을 제공합니다.

  • 7.2.16 주요 구성 요소가 서로 다른 메타 정보를 가진 여러 인스턴스에 의존하는 경우, 각 인스턴스는 개별 메타 정보와 함께 별도로 나열되어야 합니다.

7 - (구) 국제표준(ISO/IEC 5230)에 기반한 기업 오픈소스 거버넌스 구축 가이드

오픈소스 국제 표준인 ISO/IEC 5230에 기반한 기업의 오픈소스 거버넌스 체계 구축 방법을 설명한다.

ISO/IEC 5230은 오픈소스 컴플라이언스를 위한 국제 표준으로 소프트웨어를 배포하는 기업이 올바른 오픈소스의 활용을 위해 준수해야 할 최소한의 핵심 요구사항을 정의하였다. 여기에서는 ISO/IEC 5230에 대해 간단히 소개하고, 이를 기반으로 기업이 어떻게 오픈소스 거버넌스 체계를 구축할 수 있을지에 대하여 설명한다.

Author : OpenChain Koera Work Group / CC BY 4.0

References

이 가이드는 다음 자료를 참고하였습니다.

  1. OpenChain Project Website
  2. OpenChain Open Source Policy Template
  3. Open Source Compliance In The Enterprise

7.1 - 1. ISO/IEC 5230 살펴보기

ISO/IEC 5230 이란?

ISO/IEC 5230은 Linux Foundation의 OpenChain Project에서 만든 규격으로 소프트웨어 공급망 내 신뢰할 수 있는 오픈소스 컴플라이언스를 보장하기 위한 최소한의 핵심 요구 사항을 정의하였다.

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

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

[OpenChain Open Source Software License Compliance General Public Guide]

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

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

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

[OpenChain Project Logo]

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

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

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

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

OpenChain 규격과 ISO/IEC 5230

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

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

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

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

< 출처 : https://github.com/OpenChain-Project/Specification/blob/master/Official/en/2.1/openchainspec-2.1.pdf>

이 OpenChain 규격은 2020년 12월 오픈소스 컴플라이언스에 대한 국제 표준4으로 정식 등록되었다.

< 출처 : https://www.iso.org/standard/81039.html>

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

ISO/IEC 5230 인증 방법

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

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

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

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

https://www.openchainproject.org/get-started/conformance >

각각의 방법을 알아보자.

1. 자체 인증 (Self Certification)

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

< 출처 : https://certification.openchainproject.org/>

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

<예: SK텔레콤 인증 선언 - 출처: https://www.openchainproject.org/featured/2021/09/08/sk-telecom>

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

< ISO/IEC 5230 적합 프로그램 보유 선언 기업, 출처 - https://www.openchainproject.org/ >

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

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

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

2. 독립 평가 (Independent Assessment)

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

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

< Independent Compliance Assessment, 출처 - https://youtu.be/DEBd-g0Ab8E >

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

독립 평가를 제공하는 업체는 AlektoMetis5, Source Code Control6 등이 있다.

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

3. 타사 인증 (Third-Party Certification)

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

2021년 10월 기준, OpenChain의 공인 타사 인증 기관은 ORCRO8, PWC9, TÜV SÜD10, Synopsys11, Bureau Veritas12이다.

< Third-Party Certifiers, 출처 - https://www.openchainproject.org/partners >

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

< PWC certification, 출처 - https://youtu.be/HslvXCM-4pQ >

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

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

OpenChain Resources

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

< OpenChain Curriculum, 출처 - https://www.openchainproject.org/resources >

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

ISO/IEC 5230 추세

2021년 초, 독일의 자동차 제조사가 부품 Supplier에게 ISO/IEC 5230 준수 계획을 요구하기 시작했다는 소식이 들렸고, 유럽의 한 오픈소스 분야 교수는 “앞으로 소프트웨어 공급망의 Buyer는 Supplier에게 ISO/IEC 5230 준수를 요구할 것은 명백하다"며, “자동차 업계로 보면 A-SPICE처럼 될 것이다"라고 말했다.

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

linkedin, May 2021

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

linkedin, July 2021

7.2 - 2. 필수 구성 요소

오픈소스 거버넌스 체계 필수 구성 요소

기업이 효율적인 오픈소스 거버넌스 체계를 구축하기 위해서는 다음과 같은 구성 요소가 필요하다.

Essential elements of an open source management program : https://www.linuxfoundation.org/wp-content/uploads/OpenSourceComplianceHandbook_2018_2ndEdition_DigitalEdition.pdf

이런 구성 요소 중 기업이 ISO/IEC 5230에서 요구하는 모든 항목에 적합한 오픈소스 거버넌스 체계 구축을 위해서는 기본적으로 아래의 다섯가지 사항을 갖추어야 한다. 여기서는 이에 대한 세부 사항을 설명한다.

  1. 조직 (담당자)
  2. 정책
  3. 프로세스
  4. 도구
  5. 교육/평가

7.3 - 3. 조직 (담당자)

역할과 책임 정의

기업의 오픈소스 거버넌스 체계를 구축하기 위해서는 먼저 이를 책임지고 수행할 책임자가 필요하다. 오픈소스 프로그램 매니저, 오픈소스 컴플라이언스 담당자 등의 명칭으로 불릴 수 있으며, 이 책임자는 기업의 오픈소스 컴플라이언스에 대한 총괄 책임을 담당한다.

아래의 역량을 가지고 있다면 이 역할에 적합하다고 할 수 있겠다.

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

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

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

기업은 오픈소스 거버넌스 체계를 구축하기 위해 각 역할의 필요성을 정의하고, 어떠한 책임을 할당하여야 하는가를 판단해야 한다. 소규모 기업의 경우, 오픈소스 프로그램 매니저 혼자서 모든 역할을 수행하는 것도 가능하다. 기업의 규모에 따라 오픈소스 도구를 운영하는 IT 담당자도 필요할 수 있고, 전문적인 법무 자문을 제공하기 위한 법무 담당의 역할이 요구될 수도 있다.

일반적으로 기업의 오픈소스 거버넌스 체계 구축을 위해서는 아래의 역할이 필요하다.

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

Individuals and teams involved in ensuring open source compliance : https://www.linuxfoundation.org/wp-content/uploads/OpenSourceComplianceHandbook_2018_2ndEdition_DigitalEdition.pdf

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.c프로그램의 성능과 효과에 영향을 미치는 역할과 그에 상응하는 책임을 확인했습니까?
Have you identified the roles and the corresponding responsibilities that affect the performance and effectiveness of the Program?

필요 역량 정의

각 역할과 그에 대한 책임을 정의하였다면 그 역할을 수행할 인원이 갖춰야 할 필요 역량이 무엇인지 파악해야 한다. 이를 통해 역할별 담당자에게 해당 역할을 수행할 수 있는 역량을 갖췄는지 평가하고, 필요시 교육을 제공해야 하기 때문이다.

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.d각 역할에 필요한 역량을 확인하고 문서화했습니까?
Have you identified and documented the competencies required for each role?

담당자 지정

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

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

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

https://sktelecom.github.io/about/osrb/

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 2.d프로그램 내 각 역할을 담당하는 인원, 그룹 또는 직무의 이름을 기재한 문서가 있습니까?
Have you documented the persons, group or function supporting the Program role(s) identified?

아래의 테이블은 오픈소스 관련 조직과 담당자의 역할 및 요구되는 필요 역량을 명시한 샘플 담당자 현황이다. 기업은 이를 참고하여 오픈소스 조직을 구성하여 문서화할 수 있다.

이 내용은 다음 페이지에서도 확인할 수 있다. : https://haksungjang.github.io/docs/openchain/#appendix-1-담당자-현황

이렇게 조직을 구성하면 ISO/IEC 5230의 요구 사항 중 아래와 같이 세가지 요구사항을 충족하게 된다.

7.4 - 4. 정책

오픈소스 정책 문서화

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

일반적인 오픈소스 정책은 다음을 포함한다.

  • 오픈소스를 사용하여 소프트웨어 제품과 서비스를 만들어서 배포하기 위한 원칙
  • 외부 오픈소스 커뮤니티에 기여하기 위한 원칙
  • 기업의 소프트웨어를 오픈소스로 공개하기 위한 원칙

다음 페이지에서 ISO/IEC 5230의 요구사항을 충족하는 샘플 오픈소스 정책 문서를 제공한다. : “부록 1. 샘플 오픈소스 정책

각 기업은 이 샘플 정책을 기반으로 회사의 비즈니스 전략과 환경에 맞게 수정하여 사용할 수 있다.

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.a배포용 소프트웨어의 배포를 위한 오픈소스 라이선스 컴플라이언스를 관리하는 문서화된 정책이 있습니까?
Do you have a documented policy that governs open source license compliance of the Supplied Software distribution?

적용 범위 지정

하나의 오픈소스 정책(프로그램)을 반드시 전체 조직에 적용해야 하는 것은 아니다. 기업 내 각 조직과 제품의 특성에 따라 적용 범위를 달리 지정할 수 있다. 조직별로, 제품별로 다른 오픈소스 프로그램을 적용할 수 있다. 마찬가지로, 소프트웨어를 전혀 배포하지 않는 조직이라면 오픈소스 프로그램의 적용 범위에서 제외할 수 있다. 기업은 조직과 제품의 특성을 고려하여 오픈소스 프로그램의 적용 범위와 한계를 명확히 정의하고, 이를 오픈소스 정책에 명시할 수 있다.

기업의 조직과 제품 및 서비스가 비즈니스 환경에 맞추어 변화함에 따라 프로그램의 적용 범위를 결정하거나 수정해야 하는 상황이 발생할 수 있다. 기업은 이에 대응하기 위한 절차를 다음의 예와 같이 준비해야 한다.

  1. 오픈소스 프로그램 매니저는 새로운 프로젝트를 시작할 때 해당 프로젝트가 프로그램 적용 범위 내에 포함되는지 여부를 판단한다.
  2. 포함되지 않는다고 판단되는 경우, 해당 프로젝트를 프로그램 적용 범위에 포함 시키기 위한 제안을 OSRB에 제출한다.
  3. OSRB에서 수락할 경우, 이에 맞게 프로그램의 적용 범위를 수정한다.
  4. 이외 오픈소스 프로그램 매니저는 프로그램 적용 범위에 대한 검토가 필요하다고 판단되는 경우, 동일한 프로세스에 따라 프로그램 적용 범위에 대한 검토를 시작할 수 있다.

다음의 예와 같은 내용을 오픈소스 정책에 포함할 수 있다.

2. 적용 범위
이 정책은 다음 세 부분에 적용한다.

1) 회사가 외부로 제공하거나 배포하는 모든 제품에 적용한다.
   단, 오픈소스를 내부 사용 목적으로만 사용하는 것은 이 정책의 범위에 포함되지 않는다.
2) 구성원이 외부 오픈소스 프로젝트로의 기여 시에 적용한다.
3) 내부 코드를 오픈소스로 공개할 때 적용한다.

적용 범위는 회사의 비즈니스 환경에 맞추어 변경할 수 있으며, 이를 위한 절차는 다음과 같다.

1) 오픈소스 프로그램 매니저는 신규사업, 조직개편 등 회사의 비즈니스 환경이 변화에 따라
   정책의 적용 범위 변경이 필요하다고 판단할 경우, 이를 위한 제안을 OSRB에 제출한다.
2) OSRB에서는 적절한 수준의 적용 범위 변경을 승인한다.
3) OSRB는 오픈소스 정책을 수정하여 정책의 적용 범위를 변경한다.

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.g프로그램의 적용 범위를 결정하는 프로세스가 있습니까?
Do you have a process for determining the scope of your Program?
자체 인증 1.h프로그램의 적용 범위와 한계를 명확하게 정의한 문서화된 진술이 있습니까?
Do you have a written statement clearly defining the scope and limits of the Program?

외부 문의 대응 담당자 지정 / 연락처 공개

오픈소스를 사용하여 개발한 제품 혹은 서비스에 대해 고객 및 오픈소스 저작권자가 기업에 오픈소스 관련 문의, 요청 및 클레임을 제기하는 경우가 있다. 외부 문의 및 요청의 주된 내용은 다음과 같다.

  • 특정 제품 및 서비스에 오픈소스가 사용되었는지 문의
  • 서면 약정(Written Offer)에 언급된 GPL, LGPL 라이선스 하의 소스 코드 제공 요청
  • 오픈소스 고지문에 명시되지 않았지만, 제품에서 발견된 오픈소스에 대한 해명 및 소스 코드 공개 요청
  • GPL, LGPL 등의 의무로 공개된 소스 코드에 누락된 파일 및 빌드 방법 제공 요청
  • 저작권 표시 요청

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

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

외부에서 기업에 오픈소스 관련된 문의를 할 수 있는 연락 방법은 (1) 기업 오픈소스 프로그램 매니저의 이메일 주소를 공개하거나, (2) Linux Foundation의 Open Compliance Directory를 이용하는 것이다.

기업 오픈소스 프로그램 사무소의 대표 이메일 주소는 제품 및 서비스와 동봉하는 오픈소스 고지문에 포함하여 공개하는 것도 좋은 방법이다.

이러한 내용은 아래의 예시와 같이 오픈소스 정책에 반영할 수 있다.

1. 외부 문의 대응
(1) 외부 문의 대응책임
외부로부터 오픈소스 컴플라이언스에 대한 문의 및 요청에 대한 대응은 오픈소스 프로그램
매니저가 담당한다.

오픈소스 프로그램 매니저는 [회사] 내의 적절한 인원에게 문의에 대한 전체 또는 일부의
처리를 할당할 수 있다. 필요할 경우 법률 담당에게 문의하여 처리한다.
외부로부터 오픈소스 컴플라이언스에 대한 문의를 받은 사람은 누구나 이를 오픈소스
프로그램 매니저에게 알려서 신속한 대응이 될 수 있게 한다.

(2) 연락처 공개
오픈소스 프로그램 매니저는 외부에서 오픈소스 관련한 문의 및 요청을 할 수 있도록
담당자의 연락처를 공개적으로 제공한다.

* 오픈소스 고지문에 연락받을 수 있는 이메일 주소 정보를 제공한다.
* Linux Foundation의 Open Compliance Directory에 연락처를 등록한다.

(3) 외부 문의 대응 절차
외부로부터의 오픈소스 컴플라이언스 문의에 신속하고 정확하게 대응한다면 소송까지
진행되는 위험을 크게 줄일 수 있다. 이를 위해 회사는 외부의 오픈소스 컴플라이언스
문의에 대응하기 위해 오픈소스 컴플라이언스 프로세스에서 정의한 외부 문의 대응 절차를
준

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 2.a외부 오픈소스 컴플라이언스 문의를 받을 담당자(오픈소스 연락담당자)를 지정했습니까?
Have you assigned individual(s) responsible for receiving external open source compliance inquiries (“Open Source Liaison”)?
자체 인증 2.b오픈소스 연락 담당자 정보가 외부에 공개되어 있습니까(예: 이메일 주소 또는 Linux Foundation의 Open Compliance Directory 활용)?
Is the Open Source Liaison function publicly identified (e.g. via an email address and/or the Linux Foundation’s Open Compliance Directory)?

인원, 예산 등 지원

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

4. 역할, 책임 및 역량

각 역할에 대한 담당 조직의 장은 조직 내 담당자를 지정하고, 담당자가 역할을 충실하게
수행할 수 있는 적절한 사간과 예산을 할당한다. 각 역할의 담당자는 자신이 역할을
수행하면서 적절한 지원이 되지 않는다면 오픈소스 프로그램 매니저에게 문제를 제기해야
한다. 오픈소스 프로그램 매니저는 해당 조직장과 문제 해결을 논의한다. 적절하게
해결되지 않는다면, 오픈소스 프로그램 매니저는 OSRB에 문제 해결을 요청할 수 있다.
OSRB는 상위 조직의 장에게 문제를 공유하고 해결을 요청한다.

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 2.e프로그램 내 각 역할을 담당하는 인원이 적합하게 배치되고, 예산이 적절하게 지원되었습니까?
Have the identified Program roles been properly staffed and has adequate funding provided?

법률 자문 제공

기업은 각 역할의 담당자가 오픈소스 컴플라이언스 이슈 해결을 위해 법률적인 검토가 필요할 경우, 이에 대해 법률 자문을 요청할 수 있는 방법을 제공해야 한다. 회사 내의 법무팀을 통해 우선 제공하고, 이슈가 첨예한 경우, 오픈소스 전문 변호사를 보유한 외부 법무 법인을 이용할 수 있다. 이를 위한 오픈소스 정책의 예시는 다음과 같다.

4. 역할, 책임 및 역량

(2) 오픈소스 프로그램 매니저
* 오픈소스 프로그램 매니저는 구성원이 오픈소스 관련 법률 자문을 받을 수 있는 방법을
  제공한다.
* 오픈소스 프로그램 매니저는 외부 법무 법인을 참여시켜야 하는지 여부를 결정한다.
  외부 법률 고문의 효과와 적절성은 오픈소스 프로그램 매니저가 매년 평가하고 검토한다.

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 2.f오픈소스 컴플라이언스와 관련된 문제 해결을 위해 내부 또는 외부의 법률 전문 자문을 이용하는 방법이 있습니까?
Is legal expertise pertaining to internal and external open source compliance identified?

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

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

내부 책임 할당 절차

오픈소스 컴플라이언스를 위한 내부 책임을 할당하는 절차가 있어야 한다. 이는 오픈소스 프로그램 매니저의 역할이다. 오픈소스 프로그램 매니저는 이슈를 파악하고 각 역할의 담당자에게 적절히 이슈를 할당해야 한다. 이를 위해 기업은 오픈소스 정책 문서에 이러한 내용을 아래와 같이 기술할 수 있다.

4. 역할, 책임 및 역량

(2) 오픈소스 프로그램 매니저

오픈소스 프로그램 매니저는 회사의 오픈소스 프로그램에 대한 총괄 책임을 담당한다. 
오픈소스를 사용한 제품과 서비스의 오픈소스 컴플라이언스를 보장하기 위해 다음 사항에 
대한 책임이 있다.

* 오픈소스 컴플라이언스를 위해 필요한 역할을 정의하고, 각 역할을 책임질 담당 조직 
및 담당자를 지정한다. 필요 시 OSRB와 협의한다.

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 2.g오픈소스 컴플라이언스에 대한 내부 책임을 할당하는 문서화된 절차가 있습니까?
Do you have a documented procedure assigning internal responsibilities for Open Source compliance?

미준수 사례 대응

기업은 컴플라이언스 미준수 사례를 신속히 검토하고 대응하기 위한 절차를 문서화해야 한다. 다음의 예시를 참고하여 오픈소스 정책에 포함할 수 있다.

1. 오픈소스 사용

(5) 컴플라이언스 이슈 수정 절차
컴플라이언스 이슈가 제기될 경우, 오픈소스 프로그램 매니저는 다음의 절차를 수행하여
신속히 대응한다.

1. 문의 접수를 확인하고 적절한 해결 시간을 명시한다.
2. 이슈 내용이 실제 문제를 지적하고 있는지를 확인한다. (아닐 경우, 이슈 제기자에게
   문제가 아님을 알린다.)
3. 실제 문제인 경우, 우선순위를 정하고 적절한 대응 방안을 결정한다.
4. 대응을 수행하고, 필요할 경우, 오픈소스 컴플라이언스 프로세스를 적절하게 보완한다.
5. 위의 내용은 Jira Tracker를 이용하여 보존한다.

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 2.h미준수 사례를 검토하고 이를 수정하기 위한 문서화된 절차가 있습니까?
Do you have a documented procedure for handling review and remediation of non-compliant cases?

오픈소스 기여 정책

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

이러한 오픈소스 기여에 대한 정책은 NIPA OpenChain 해설서 부록 1. 샘플 오픈소스 정책의 7. 오픈소스 기여를 참고할 수 있다.

이와 같이 수행한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 5.a조직을 대신하여 오픈소스 프로젝트에 기여하는 것을 관리하는 정책이 있습니까?
Do you have a policy that governs contributions to open source projects on behalf of the organization?

위와 같은 내용을 포함하는 오픈소스 정책까지 수립하게 되면 ISO/IEC 5230 요구사항 중 다음의 사항을 만족하게 된다.

7.5 - 5. 프로세스

프로세스는 소프트웨어 개발 / 배포 과정에서 기업이 오픈소스 정책을 준수할 수 있게 하는 실행 가능한 절차이다. 오픈소스 컴플라이언스 프로세스는 간단히 말해 소프트웨어를 개발하고 배포하면서 사용한 오픈소스에 대해 각 라이선스가 요구하는 조건을 준수하기 위한 활동이고, 오픈소스 고지문(Notice), 공개할 소스 코드 (Source Code) 등의 산출물을 생성하게 된다.

Simplified view of the compliance end-to-end process : https://www.linuxfoundation.org/wp-content/uploads/OpenSourceComplianceHandbook_2018_2ndEdition_DigitalEdition.pdf

오픈소스 컴플라이언스 프로세스를 세분화하여 도식화하면 아래 그림과 같다.

End-to-end compliance process : https://www.linuxfoundation.org/wp-content/uploads/OpenSourceComplianceHandbook_2018_2ndEdition_DigitalEdition.pdf

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

이에 대한 자세한 내용은 다음 페이지를 참고할 수 있다. : https://haksungjang.github.io/docs/openchain/#부록-2-샘플-오픈소스-컴플라이언스-프로세스

이 장에서는 오픈소스 컴플라이언스 프로세스가 포함해야 할 구성 요소에 대해 설명한다.

오픈소스 식별 및 검사

오픈소스의 사용 가능 여부를 판단하기 위해서는 먼저 사용하려는 오픈소스의 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무사항을 확인해야 한다. 오픈소스를 사용하였는지, 라이선스는 무엇인지, 각 라이선스가 부여하는 의무는 무엇인지 검토하고 기록해야 한다. 이를 위한 절차의 예는 다음과 같다.

  1. 개발 부서는 오픈소스 정책에서 정의한 기준에 따라 라이선스를 예비 평가한다.
  2. 의문 사항은 오픈소스 프로그램 매니저에게 문의하고, 필요할 경우 오픈소스 프로그램 매니저는 외부 법률 전문가에게 자문을 요청한다.
  3. 모든 내외부의 결정 결과 및 관련 근거는 보관한다.

부록 2. 샘플 오픈소스 컴플라이언스 프로세스”의 1. 오픈소스 식별, 검사, 문제 해결, 리뷰, 승인 단계는 각 식별된 라이선스가 부가하는 의무, 제한을 검토하고 기록하기 위한 문서화된 절차의 한 예이다.

이와 같은 절차를 마련한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.i오픈소스 라이선스 의무, 제한 및 권리를 검토하는 프로세스가 있습니까?
Do you have a process for reviewing open source license obligations, restrictions and rights?

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

오픈소스 BOM 식별, 검토, 보관

오픈소스 컴플라이언스 활동의 가장 기본은 배포용 소프트웨어에 포함된 오픈소스 현황을 파악하는 것이다. 배포용 소프트웨어에 포함된 오픈소스와 그 라이선스를 식별하여 그 정보를 담고 있는 BOM(Bill of Materials)을 작성하고 관리하는 프로세스를 구축해야 한다. 배포용 소프트웨어의 버전마다 어떤 오픈소스가 포함되어 있는지 알고 있어야 소프트웨어를 배포할 때 각 오픈소스의 라이선스가 요구하는 의무 사항을 준수할 수 있기 때문이다.

모든 오픈소스는 배포용 소프트웨어에 통합하기 전에 검토 및 승인되어야 한다. 오픈소스의 기능, 품질뿐만 아니라 출처, 라이선스 요건을 충족할 수 있는지 사전 검토가 되어야 한다. 이를 위해 검토 요청 → 리뷰 → 승인 과정이 필요하다. 

부록 2. 샘플 오픈소스 컴플라이언스 프로세스에서는 기업의 오픈소스 컴플라이언스를 위한 프로세스 모든 과정에 관해 설명하고 있다. 1. 오픈소스 식별부터 6. 등록까지의 과정을 통해 BOM을 작성하고 관리하게 된다.

오픈소스 BOM 관리를 위한 도구에 대해서는 “6. 도구“에서 자세히 설명한다.

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

이와 같은 절차를 마련한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 3.a배포용 소프트웨어를 구성하는 오픈소스 컴포넌트에 대한 정보를 식별, 추적, 검토, 승인 및 보관하는 문서화된 절차가 있습니까?
Do you have a documented procedure for identifying, tracking and archiving information about the collection of open source components from which a Supplied Software release is comprised?

오픈소스 컴플라이언스 산출물 생성

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

컴플라이언스 산출물은 크게 두 가지로 구분된다.

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

    • 도구를 활용하여 취합한 오픈소스 BOM에 해당하는 오픈소스 고지문을 생성하는 방법에 대해 “6. 도구“에서 추가로 설명한다.
  2. 공개할 소스 코드 패키지 : GPL, LGPL 등 소스 코드 공개를 요구하는 오픈소스 라이선스 의무 이행을 위해 공개할 소스 코드를 취합한 패키지

컴플라이언스 산출물은 배포용 소프트웨어를 배포할 때 함께 제공해야 한다. “부록 2. 샘플 오픈소스 컴플라이언스 프로세스”의 고지 단계부터 배포 단계를 통해 컴플라이언스 산출물을 생성하여 배포한다.

배포용 소프트웨어를 배포 시, 공개할 소스 코드 패키지를 동봉하는 것이 곤란할 경우, 최소 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년 이상 보관해야 하며 이를 위한 프로세스가 구축되어야 한다. 이를 위해 기업은 오픈소스 웹사이트 구축을 고려해야 하며, 이에 대한 자세한 내용은 “6. 도구“에서 설명한다.

이와 같은 절차를 마련한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 4.a식별된 라이선스가 요구하는 컴플라이언스 산출물을 준비하고, 이를 배포용 소프트웨어와 함께 제공하기 위한 프로세스를 설명하는 문서화된 절차가 있습니까?
Do you have a documented procedure that describes a process that ensures the Compliance Artifacts are distributed with Supplied Software as required by the Identified Licenses?

외부 문의 대응

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

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

https://haksungjang.github.io/docs/openchain/#2-외부-문의-대응-프로세스

“부록 2. 샘플 오픈소스 컴플라이언스 프로세스의 2. 외부 문의 대응 프로세스”에서 세부 내용을 확인할 수 있다.

이와 같은 절차를 마련한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 2.c오픈소스 컴플라이언스 문의를 받고 대응하기 위한 책임을 할당하는 문서화된 절차가 있습니까?
Do you have a documented procedure that assigns responsibility for receiving and responding to open source compliance inquiries?

오픈소스 기여 프로세스

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

SK텔레콤에서 공개한 오픈소스 기여 절차는 좋은 예이다.

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

이와 같은 절차를 마련한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 5.b오픈소스 기여를 관리하는 문서화된 절차가 있습니까?
Do you have a documented procedure that governs Open Source contributions?

여기까지 프로세스를 구축하게 되면 ISO/IEC 5230 요구사항을 아래와 같이 준수하게 된다.

7.6 - 6. 도구

소스 코드 스캔 도구

오픈소스 컴플라이언스 프로세스의 오픈소스 식별 및 검사 단계에서는 소스 코드 스캔 도구를 사용할 수 있다. 소스 코드 스캔 도구는 무료로 사용할 수 있는 오픈소스 기반 도구부터 상용 도구까지 다양하게 있는데, 각 도구는 특장점 들이 있지만 어떤 하나도 모든 문제를 해결할 수 있는 완벽한 기능을 제공하지 않는다. 따라서 기업은 제품의 특성과 요구사항에 맞는 적합한 도구를 선택해야 한다.

많은 기업이 이러한 자동화된 소스 코드 스캔 도구와 수동 검토를 병행하여 이용한다. Linux Foundation의 FOSSology 프로젝트는 오픈소스로 공개된 소스 코드 스캔 도구로서 기업들이 손쉽게 무료로 사용할 수 있다.

https://www.fossology.org/

FOSSology의 설치 및 사용 방법은 부록 3. 오픈소스 도구를 참고한다.

https://haksungjang.github.io/docs/openchain/#1-fossology

Dependency 분석 도구

근래의 소프트웨어 개발 시에는 Gradle, Maven 등 Package Manager를 지원하는 빌드 환경을 사용한다. 이런 빌드 환경에서는 소스 코드가 없어도 빌드 타임에 필요한 Dependency 라이브러리를 원격의 공간으로부터 받아와서 배포용 소프트웨어를 구성한다. 이때의 Dependency 라이브러리는 배포용 소프트웨어에는 포함되지만 소스 코드 스캔 도구로는 검출되지 않는다. 따라서 Dependency 분석을 위한 도구를 활용하는 것도 중요하다.

오픈소스인 OSS Review Toolkit은 Analyzer라는 Dependency 분석 도구를 제공한다.

https://github.com/oss-review-toolkit/ort#analyzer

또한 LG전자는 FOSSLight Dependency Scanner를 오픈소스로 공개하였다. FOSSLight Dependency Scanner는 Gradle, Maven, NPM, PIP, Pub, Cocoapods 등 다양한 Package Manager를 지원한다.

https://fosslight.org/ko/scanner/

오픈소스 BOM 관리 도구

ISO/IEC 5230 규격의 3.3.1.2에서는 배포용 소프트웨어에 포함된 오픈소스 BOM 목록은 문서화하여 보관할 것을 요구한다. 오픈소스 BOM을 Excel과 같은 Spreadsheet 프로그램으로 관리할 수도 있다. 하지만, 배포용 소프트웨어의 개수와 버전이 수백개가 넘어갈 경우, 이를 수동으로 관리하는 것은 쉽지 않다. 이를 위한 오픈소스 자동화 도구를 도입하는 것이 좋다.

Eclipse 재단에서 후원하는 오픈소스 프로젝트인 SW360은 배포용 소프트웨어별로 포함하고 있는 오픈소스 목록을 트래킹할 수 있는 기능을 제공한다.

SW360의 설치 및 사용 방법은 부록 3. 오픈소스 도구를 참고할 수 있다.

https://haksungjang.github.io/docs/openchain/#부록-3-오픈소스-도구

그리고 위에서 언급한 LG전자가 공개한 오픈소스인 FOSSLight도 오픈소스 BOM 관리를 위한 기능을 제공한다.

https://fosslight.org/fosslight-guide/started/2_try/4_project.html

LG전자는 FOSSLight를 자체 개발하여 지난 수년간 전체 사업부의 배포용 소프트웨어에 대한 오픈소스 BOM을 관리해왔으며, 2021년 6월, 이를 누구나 사용할 수 있도록 오픈소스로 공개하였음을 발표하였다.

자세한 설치 및 사용 방법을 한국어 가이드로 제공하고 있어서 국내 기업에게 큰 도움이 될 것으로 기대한다.

https://fosslight.org/

이와 같은 도구를 도입한다면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 3.b문서화된 절차가 적절히 준수되었음을 보여주는 배포용 소프트웨어에 대한 오픈소스 컴포넌트 기록이 있습니까?
Do you have open source component records for each Supplied Software release which demonstrates the documented procedure was properly followed?

오픈소스 컴플라이언스 산출물 생성

오픈소스 컴플라이언스 산출물 중 오픈소스 고지문을 수작업으로 작성하기 보다는 자동으로 생성하는 도구를 활용하는 것이 좋다.

FOSSLight에 오픈소스 BOM을 등록하면 자동으로 오픈소스 고지문을 생성할 수 있다. FOSSLight가 생성한 오픈소스 고지문에는 공개할 소스 코드에 대한 Written Offer (서면약정서)도 포함된다.

https://fosslight.org/fosslight-guide/started/2_try/4_project.html

또한 SK텔레콤은 사내에서 사용하는 오픈소스 고지문 자동 생성 도구를 오픈소스로 공개할 예정이어서 추후 이를 활용하는 것도 좋은 방법이다.

오픈소스 산출물 보관

기업은 오픈소스 웹사이트를 만들고, 오픈소스 컴플라이언스 산출물을 등록하여 외부 고객들이 배포용 소프트웨어에 대한 오픈소스 고지문과 공개할 소스 코드 패키지를 언제든지 다운받을 수 있도록 편의를 제공하는 것이 좋다.

SK텔레콤의 오픈소스 웹사이트를 참고할 수 있다.

https://sktelecom.github.io/compliance/

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

https://github.com/sktelecom/sktelecom.github.io

이와 같은 도구 환경을 구축하면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 4.b배포용 소프트웨어의 컴플라이언스 산출물 사본을 보관합니까?
Do you archive copies of the Compliance Artifacts of the Supplied Software?
자체 인증 4.c컴플라이언스 결과물 사본은 적어도 배포용 소프트웨어가 제공되는 중이거나 식별된 라이선스가 요구하는 기간 중 더 긴 시간 동안 보관됩니까?
Are the copies of the Compliance Artifacts archived for at least as long as the Supplied Software is offered or as required by the Identified Licenses (whichever is longer)?

이렇게 도구 환경까지 구축하게 되면 ISO/IEC 5230 요구사항을 아래와 같이 준수하게 된다.

7.7 - 7. 교육/평가

교육

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

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

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

1. 교육 및 평가

모든 소프트웨어 배포 참여자는 매년 [Learning Portal]에서 제공하는 오픈소스 의무
교육을 수강해야 한다.
이를 통해 오픈소스 정책, 관련 교육 정책 및 조회 방법을 숙지한다. 교육 이력은
[Learning Portal]에 보존한다.

이와 같은 교육 환경을 구축하면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.b오픈소스 정책의 존재를 모든 프로그램 참여자에게 알리는 문서화된 절차가 있습니까? (예: 교육, 내부 위키 혹은 기타 실질적인 전달 방법)
Do you have a documented procedure that communicates the existence of the open source policy to all Software Staff? (e.g., via training, internal wiki, or other practical communication method)

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

이를 위한 아래의 예와 같은 내용을 기업의 오픈소스 정책에 포함할 수 있다.

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

    1) 오픈소스 라이선스를 고려한 컴플라이언스 수행 원칙
    2) 외부 오픈소스 프로젝트로의 기여 원칙
    3) 사내 프로젝트를 오픈소스로 공개하기 위한 원칙

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

  (2) 미준수 시 영향
   이 정책을 준수하지 않는다면 다음과 같은 상황이 발생할 수 있다.
   * 외부로부터 오픈소스 라이선스 준수 요구를 받게 된다.
   * 회사가 개발한 소스 코드를 원하지 않게 공개해야 한다.
   * 오픈소스 저작권자로부터 법적 소송을 제기당하게 된다.
   * 저작권 침해 및 계약 위반으로 벌금을 부과 당하거나, 제품 판매 중지 명령을 받게 된다.
   * 회사 평판이 손실된다.
   * 공급업체와의 계약 위반이 되어 손해배상 청구를 당하게 된다.
  이러한 이유로 회사는 오픈소스 정책의 위반을 심각하게 간주하며, 이를 위반하는
  구성원이나 조직은 징계 절차에 처할 수 있다.

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

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

이와 같은 교육에 대한 내용을 정책에 포함하면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.f다음 주제에 대한 프로그램 참여자의 인식을 문서화 한 증거가 있습니까?
i. 오픈소스 정책 및 이를 찾을 수 있는 위치
ii. 오픈소스 관련 목표
iii. 효과적인 프로그램이 되기 위한 참여자의 기여 방법
iv. 프로그램 요구사항을 준수하지 않을 경우 미치는 영향
Do you have evidence documenting the awareness of your personnel of the following topics?
i - The open source policy and where to find it;
ii - The relevant open source objectives;
iii - The contributions expected to ensure the effectiveness of the Program;
iv - The implications of failing to follow the Program requirements.

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

이와 같이 기여 정책에 대한 교육을 제공하면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 5.c모든 프로그램 참여자가 오픈소스 기여 정책의 존재를 인식하도록 하는 문서화된 절차가 있습니까?
Do you have a documented procedure that makes all Software Staff aware of the existence of the Open Source contribution policy?

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

https://github.com/ncsoft/oss-basic-training

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

http://t1.kakaocdn.net/olive/assets/opensource_guide_kakao.pdf

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

평가

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

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

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

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

4. 역할, 책임 및 역량
이 정책의 효과를 보장하기 위해 다음과 같이 역할과 책임 및 각 역할의 담당자가 갖추어야
할 역량을 정의한다.
각 역할의 담당 조직/담당자와 필요 역량 수준은 "Appendix 1. 담당자 현황"에서 정의한다.

5. 교육 및 평가
4장에서 정의한 각 역할을 담당하는 모든 구성원은 [Learning Portal]에서 제공하는
오픈소스 교육을 수강해야 한다.
교육 이력과 평가 결과는 [Learning Portal]에서 최소 3년간 보존한다.

이러한 교육과 평가 체계를 갖추면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 1.e각 프로그램 참여자의 역량을 평가한 증거를 문서화했습니까?
Have you documented evidence of assessed competence for each Program participant?

오픈소스 라이선스 가이드

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

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

오픈소스 라이선스에 대한 일반적인 가이드와 라이선스 의무 요약 자료는 한국저작권위원회에서 제공하는 라이선스 가이드을 참고할 수 있다.

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

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

이러한 오픈소스 라이선스 가이드를 제공함으로써 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 3.c각 배포용 소프트웨어 릴리스 내의 오픈소스 컴포넌트에 대해 적어도 다음과 같은 일반적인 오픈소스 라이선스 사용 사례를 처리하는 절차를 구현했습니까?
i - 바이너리 형태로 배포;
ii - 소스 형태로 배포;
iii - Copyleft 의무를 발생시킬 수 있는 다른 오픈 소스와 통합;
iv - 수정된 오픈소스 포함;
v - 배포용 소프트웨어 내의 다른 컴포넌트와 서로 호환되지 않는 라이선스 하의 오픈소스 또는 다른 소프트웨어를 포함
Have you implemented a procedure that handles at least the following common open source license use cases for the open source components of each supplied Supplied Software release?
i - distributed in binary form;
ii - distributed in source form;
iii - integrated with other open source such that it may trigger copyleft obligations;
iv - contains modified open source;
v - contains open source or other software under an incompatible license interacting with other components within the Supplied Software;
vi - contains open source with attribution requirements.

이와 같이 교육, 평가와 가이드 제공 환경까지 구축하게 되면 ISO/IEC 5230 요구사항을 아래와 같이 준수하게 된다.

7.8 - 8. 준수 선언

ISO/IEC 5230 규격의 6조를 제외한 모든 요구사항을 준수하는 오픈소스 프로그램(오픈소스 정책 / 프로세스 / 도구 / 조직)을 구축한 기업은 다음 두가지를 명시하는 문서를 작성하여 게시할 수 있다.

  1. 기업의 오픈소스 프로그램이 OpenChain 규격 2.1의 모든 요구사항을 충족함
  2. 기업의 오픈소스 프로그램이 적합성 인증을 획득한 후 18개월 이상 OpenChain 규격 2.1의 모든 요구 사항을 충족하는 상태 유지를 보장함

기업은 위의 내용을 오픈소스 정책에 포함시킬 수도 있고, 외부에 공개되어 있는 웹사이트를 통해 게재할 수도 있다.

아래 이미지와 같이 SK텔레콤에서 오픈소스 포털사이트에 이에 대한 내용을 게재한 것을 참고할 수 있다. https://sktelecom.github.io/compliance/iso5230/

이렇게 ISO/IEC 5230의 모든 요구사항을 충족함을 보장한다고 문서화하면 ISO/IEC 5230에서 요구하는 다음 입증 자료를 준비할 수 있다.

자체 인증 6.a프로그램이 이 규격의 모든 요구사항을 충족함을 확인하는 문서가 있습니까?
Do you have documentation confirming that your Program meets all the requirements of this specification?
자체 인증 6.b지난 18개월 이내에 프로그램 적합성을 검토했음을 확인하는 문서가 있습니까?
Do you have documentation confirming that your Program conformance was reviewed within the last 18 months?

여기까지 완료하면 기업은 드디어 ISO/IEC 5230의 모든 요구사항을 충족하게 된다.

7.9 - Appendix

7.9.1 - 1. 오픈소스 정책 (샘플)

1. 목적

(1) 정책의 목적(3.1.3.1)

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

  1. 오픈소스 라이선스를 고려한 컴플라이언스 수행 원칙
  2. 외부 오픈소스 프로젝트로의 기여 원칙
  3. 사내 프로젝트를 오픈소스로 공개하기 위한 원칙

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

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

(2) 미준수 시 영향

이 정책을 준수하지 않는다면 다음과 같은 상황이 발생할 수 있다.

  • 외부로부터 오픈소스 라이선스 준수 요구를 받게 된다.
  • 회사가 개발한 소스 코드를 원하지 않게 공개해야 한다.
  • 오픈소스 저작권자로부터 법적 소송을 제기당하게 된다.
  • 저작권 침해 및 계약 위반으로 벌금을 부과 당하거나, 제품 판매 중지 명령을 받게 된다.
  • 회사 평판이 손실된다.
  • 공급업체와의 계약 위반이 되어 손해배상 청구를 당하게 된다.

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

(3) 구성원의 공헌 방법

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

2. 적용 범위(3.1.4.1)

이 정책은 다음 세 부분에 적용한다.

  1. [회사가 외부로 제공하거나 배포하는 모든 제품]에 적용한다. 단, 오픈소스를 내부 사용 목적으로만 사용하는 것은 이 정책의 범위에 포함되지 않는다.
  2. 구성원이 외부 오픈소스 프로젝트로의 기여 시에 적용한다.
  3. 내부 코드를 오픈소스로 공개할 때 적용한다.

적용 범위는 회사의 비즈니스 환경에 맞추어 변경할 수 있으며, 이를 위한 절차는 다음과 같다.

  1. 오픈소스 프로그램 매니저는 신규사업, 조직개편 등 회사의 비즈니스 환경이 변화에 따라 정책의 적용 범위 변경이 필요하다고 판단할 경우, 이를 위한 제안을 OSRB에 제출한다.
  2. OSRB에서는 적절한 수준의 적용 범위 변경을 승인한다.
  3. OSRB는 오픈소스 정책을 수정하여 정책의 적용 범위를 변경한다.

3. 용어

  • BOM (Bill of Materials)
  • 소프트웨어 배포 참여자 : 회사가 소프트웨어를 개발하고 배포, 기여하는 데 관여하는 모든 직원을 의미하며, 소프트웨어 개발자, 배포 엔지니어, 품질 엔지니어 등을 포함한다.

4. 역할, 책임 및 역량(3.1.2.1)

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

각 역할의 담당 조직/담당자와 필요 역량 수준은 [Appendix 1. 담당자 현황]에서 정의한다.(3.1.2.2)

  • 오픈소스 프로그램 매니저는 회사의 비즈니스 상황에 맞추어 주기적으로 명단을 업데이트한다.(3.2.2.1)
  • 각 역할에 대한 담당 조직의 장은 조직 내 담당자를 지정하고, 담당자가 역할을 충실하게 수행할 수 있는 적절한 사간과 예산을 할당한다.(3.2.2.2)
    • 각 역할의 담당자는 자신이 역할을 수행하면서 적절한 지원이 되지 않는다면 오픈소스 프로그램 매니저에게 문제를 제기해야 한다.
    • 오픈소스 프로그램 매니저는 해당 조직장과 문제 해결을 논의한다. 적절하게 해결되지 않는다면, 오픈소스 프로그램 매니저는 OSRB에 문제 해결을 요청할 수 있다.
    • OSRB는 상위 조직의 장에게 문제를 공유하고 해결을 요청한다.

(1) OSRB

OSRBOpen Source Review Board는 회사의 오픈소스 컴플라이언스 위해 오픈소스 프로그램 매니저와 법무팀, 특허팀, 개발팀, 인프라팀 등 관련 조직의 책임자로 구성된 협의체이다.

  • 오픈소스 컴플라이언스를 위한 정책과 프로세스를 만들고, 이를 수행하기 위한 회사 내의 역할과 책임을 정의한다.
  • 회사 내 오픈소스 컴플라이언스 이슈 발생 시, 해결 방안을 논의하고, 대응책을 마련한다.
  • 필요 시, 임원진에 이슈를 보고하여 리스크 완화 방안에 대한 피드백을 받는다.

(2) 오픈소스 프로그램 매니저

오픈소스 프로그램 매니저는 회사의 오픈소스 프로그램에 대한 총괄 책임을 담당한다. 오픈소스를 사용한 제품과 서비스의 오픈소스 컴플라이언스를 보장하기 위해 다음 사항에 대한 책임이 있다.(3.2.2.4)

  • 오픈소스 컴플라이언스를 위해 필요한 역할을 정의하고, 각 역할을 책임질 담당 조직 및 담당자를 지정한다. 필요 시 OSRB와 협의한다.
  • 오픈소스 컴플라이언스 교육을 주관하고 평가한다.
  • OSRB의 의장을 맡아서 활동을 지휘한다.
  • 외부로부터의 오픈소스 사용 및 컴플라이언스 관련 문의 및 요청에 대응한다.
  • 오픈소스 사용 요청을 검토하고 승인한다.
  • 오픈소스 BOM 기록을 유지한다.
  • 구성원에게 오픈소스 관련 법률 자문 받는 방법을 제공한다.(3.2.2.3)
  • 오픈소스 고지 및 소스 코드 공개를 위한 저장소를 유지한다.

(3) OSPO

OSPOOpen Source Program Office는 회사 안팎으로 오픈소스 활동의 성장을 위해 지원, 육성하는 역할을 한다.

  • 오픈소스 정책을 수립, 개선 및 전파한다.
  • 외부 오픈소스 프로젝트로의 코드 기여를 위한 가이드를 제공한다.
  • 사내 프로젝트를 오픈소스로 공개하기 위한 가이드를 제공한다.
  • 오픈소스 포털을 개발 및 운영한다.
  • 오픈소스 도구를 개발 및 선택한다.
  • 오픈소스 프로젝트 이벤트를 후원한다.
  • 오픈소스 커뮤니티와의 관계를 관리한다.

(4) 법무 담당

법무 담당은 오픈소스 라이선스와 의무를 해석하는 등 오픈소스 활용 과정에서 발생할 수 있는 법적 위험과 완화 방안에 대한 자문을 제공한다.

  • 호환되지 않는 오픈소스 라이선스로 인한 충돌을 포함하여 라이선스 및 지식재산권 문제에 대해 자문을 제공한다.
  • 외부 오픈소스 프로젝트로의 기여 시 오픈소스 라이선스, CLAContributor License Agreement 등 필요한 법적 사항을 검토한다.

(5) IT 담당

IT 담당은 오픈소스 분석 도구를 운영하고 자동화하여 모든 배포용 소프트웨어에 대해 라이선스 분석이 원활히 수행되도록 시스템을 구축한다.

  • 오픈소스 라이선스 분석 도구를 운영한다.
  • DevOps 환경과 통합하여 라이선스 분석을 자동화한다.
  • 모든 배포용 소프트웨어를 대상으로 라이선스 분석이 수행되도록 시스템과 프로세스를 구축한다.
  • 모든 배포용 소프트웨어에 대한 오픈소스 BOM을 확보하고 유지한다.

(6) 보안 담당

보안 담당은 오픈소스 보안취약점 분석 도구를 운영하여 모든 배포용 소프트웨어에 대해 보안취약점 분석이 원활히 수행되도록 시스템을 구축한다.

  • 오픈소스 보안취약점 분석 도구를 운영한다.
  • DevSecOps 환경과 통합하여 오픈소스 보안취약점 분석을 자동화한다.
  • 모든 배포용 소프트웨어를 대상으로 오픈소스 보안취약점 분석이 수행되도록 시스템과 프로세스를 구축한다.

(7) 개발 문화 담당

개발 문화 담당은 사내 개발자들이 오픈소스를 적극적으로 활용하고 사내외 커뮤니티에 참여하여 선진 개발 문화를 습득할 수 있도록 지원한다.

  • 오픈소스 커뮤니티로의 참여를 장려한다.
  • 활발한 외부 오픈소스 프로젝트 활동을 사내 성과로 인정할 수 있는 문화를 조성한다.
  • 오픈소스 개발자들에게 매력 있는 회사로 인식될 수 있는 개발 문화를 만들어간다.

(8) 품질 담당

QA 등 품질을 담당하는 조직은 소프트웨어 배포 시 오픈소스 라이선스 의무를 적절히 수행하였는지 확인한다.

  • 개발 프로세스 단계에 맞추어 오픈소스 컴플라이언스 활동이 수행되었는지 확인한다.
  • 오픈소스 라이선스가 요구하는 대로 산출물을 생성하였는지 확인한다.
  • 소프트웨어 배포 시 오픈소스 고지문과 공개할 소스 코드를 함께 제공하는지 확인한다.
  • 이슈가 있으면 소프트웨어 개발/배포 조직에 통보하여 즉시 이슈를 수정하도록 안내한다.

5. 교육 및 평가

모든 소프트웨어 배포 참여자는 매년 [Learning Portal]에서 제공하는 오픈소스 의무 교육을 수강해야 한다. 이를 통해 오픈소스 정책, 관련 교육 정책 및 조회 방법을 숙지한다. 교육 이력은 [Learning Portal]에 보존한다.(3.1.1.2)

4장에서 정의한 각 역할을 담당하는 모든 구성원은 [Learning Portal]에서 제공하는 오픈소스 교육 고급 과정을 수강해야 한다. 교육 이력과 평가 결과는 [Learning Portal]에 최소 3년간 보존한다.(3.1.2.3)

6. 오픈소스 사용

오픈소스를 사용하여 제품 및 서비스를 개발하고 배포하려면 각 오픈소스 라이선스가 요구하는 의무 사항을 준수해야 한다. 이를 위한 활동을 오픈소스 컴플라이언스라고 한다.

올바른 오픈소스 컴플라이언스 활동을 위해 소프트웨어 개발/배포 조직은 다음 사항을 준수해야 한다.(3.3.1.1)

  • 오픈소스 컴플라이언스 프로세스의 모든 과정은 Jira Tracker에 기록하여 보존한다.

(1) 오픈소스 식별 및 라이선스 의무 사항 검토

오픈소스를 제품 / 서비스 개발에 도입 시, 먼저 오픈소스 라이선스가 무엇인지 식별하고, 라이선스가 요구하는 의무 사항을 검토하고 확인한다.

회사의 [오픈소스 라이선스 가이드]에는 주요 오픈소스 라이선스 목록이 포함되어 있으며, 라이선스마다 다음의 배포 형태별 요구하는 의무사항을 구분하여 설명한다.(3.3.2.1)

  • 바이너리 형태
  • 소스 형태
  • 강한/약한 Copyleft
  • SaaS 기반 제공
  • 수정 여부
  • 저작자 표시 요구 오픈소스 포함 등.

소프트웨어 개발/배포 조직은 오픈소스 라이선스 의무 검토 시 이 가이드를 참고할 수 있다. 이 가이드에서 언급하지 않는 오픈소스 라이선스의 검토가 필요할 경우, 오픈소스 프로그램 매니저에게 문의한다.

(2) 오픈소스 라이선스 고려 설계

오픈소스의 결합 관계를 파악하여 자사의 코드가 오픈소스 라이선스의 영향을 받지 않도록 소프트웨어 아키텍처를 설계한다.

회사의 [오픈소스 라이선스 가이드]에서는 오픈소스 라이선스별 소스 코드 공개 범위 및 자사 코드의 공개를 방지하기 위한 설계 방법을 설명한다.

(3) 오픈소스 컴플라이언스 산출물 생성

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

오픈소스 컴플라이언스 산출물은 크게 두 가지로 구분된다.

  1. 오픈소스 고지문 : 오픈소스 라이선스 전문과 저작권 정보 제공을 위한 문서
  2. 공개할 소스 코드 패키지 : GPL, LGPL 등 소스 코드 공개를 요구하는 오픈소스 라이선스 의무 이행을 위해 공개할 소스 코드를 취합한 패키지

이러한 컴플라이언스 산출물을 취합, 배포, 보관하기 위해 다음 사항을 준수한다.(3.4.1.2)

  • 오픈소스 고지문이나 공개할 소스 코드 패키지는 각 라이선스가 요구하는 조건대로 취합한다. 예를 들어, 라이선스가 라이선스 전체 텍스트의 동봉을 요구하는데, 링크만을 제공해서는 안 된다.
  • 취합한 산출물은 별도의 저장소에 보관한다.
  • 공개할 소스 코드를 서면 약정서로 제공할 경우, 취합한 산출물의 저장소를 외부에서 접근할 수 있도록 다운로드 링크를 공개한다.

회사의 오픈소스 컴플라이언스 프로세스를 통해 오픈소스 고지문을 발급하고, 공개할 소스 코드 패키지를 취합할 수 있다.

(4) 오픈소스 BOM (Bill of Materials) 생성

배포용 소프트웨어에 포함된 오픈소스 현황(BOM : Bill of Materials)을 생성하고 관리해야 한다.(3.3.1.2)

회사의 오픈소스 컴플라이언스 프로세스를 통해 오픈소스 도구를 활용하여 오픈소스 BOM을 생성하고 보존할 수 있다.

(5) 컴플라이언스 이슈 수정 절차

컴플라이언스 이슈가 제기될 경우, 오픈소스 프로그램 매니저는 다음의 절차를 수행하여 신속히 대응한다.(3.2.2.5)

  1. 문의 접수를 확인하고 적절한 해결 시간을 명시한다.
  2. 이슈 내용이 실제 문제를 지적하고 있는지를 확인한다. (아닐 경우, 이슈 제기자에게 문제가 아님을 알린다.)
  3. 실제 문제인 경우, 우선순위를 정하고 적절한 대응 방안을 결정한다.
  4. 대응을 수행하고, 필요할 경우, 오픈소스 컴플라이언스 프로세스를 적절하게 보완한다.
  5. 위의 내용은 Jira Tracker를 이용하여 보존한다.

7. 오픈소스 기여

회사는 오픈소스에서의 비즈니스 가치 창출을 위해 외부 오픈소스 프로젝트로의 참여와 기여를 권장한다. 그러나 이 과정에서 의도하지 않은 회사의 지식 재산 노출 혹은 제 3자의 권리 침해에 주의해야 한다. 이를 위해 회사의 구성원이 외부 오픈소스 프로젝트로의 기여를 위해서는 다음 사항을 준수해야 한다.(3.5.1.1)

(1) 리뷰 요청 및 승인

오픈소스 기여는 저작권 관점에서 저작자가 저작물을 수정/사용/배포할 수 있는 권한을 오픈소스 프로젝트에 부여하는 것이다. 때에 따라서는 오픈소스 프로젝트에 여러분의 저작권을 양도해야 하기도 한다. 그런데 일반적으로 고용 기간에 만든 저작물의 저작권은 고용주가 소유한다. 즉, 회사 구성원이 만든 저작물은 회사가 소유한다. 구성원이 임의로 저작물을 오픈소스에 기여하는 행위는 불필요한 저작권 침해 이슈를 유발할 수 있다.

따라서, 기여하고자 하는 오픈소스 프로젝트가 있다면 오픈소스 기여 프로세스에 따라 최초 기여하기 전에 리뷰 요청 및 승인 절차를 준수한다.

단, 다음과 같이 단순한 내용일 경우, 저작권 침해 리스크가 크지 않기 때문에 리뷰 절차 없이 구성원의 판단에 따라 기여할 수 있다.

  • 10 라인 이하의 작은 코드 조각
  • Stack Overflow에서의 문의 / 답변
  • GitHub에서의 관리 활동 : Issue 생성, Pull Request Review / Approve 등

(2) 기여할 권리가 있는 코드만 기여

기여할 권리가 있는 코드만 기여해야 한다. 즉, 직접 작성한 코드를 기여한다. 제 3자의 코드를 임의로 기여해서는 안 된다.

(3) 지식 재산 노출 주의

민감한 정보, 특허 등 회사의 지식재산 노출이 우려되는 코드, 문서는 기여하지 않는다.

  • 기여하려는 코드에 회사의 특허가 포함되어 있다면, 이 특허를 오픈소스 라이선스로 프로젝트에 기여해도 되는지 확인해야 한다. 모호한 부분이 있다면 OSPO에 문의한다.

(4) CLA 서명 주의

어떤 오픈소스 프로젝트는 모든 기여자에게 CLAContributor License Agreement에 서명할 것을 요구한다. 이는 프로젝트가 여러 기여자의 저작물을 관리하면서 발생할 수 있는 저작권 분쟁을 줄이기 위해 기여자들에게 동의를 구하는 약정서이다. 보통 대기업이 주도하는 프로젝트에서 CLA에 서명할 것을 요구한다.

CLA는 프로젝트마다 다르지만 주로 다음 사항을 동의한다는 내용을 담고 있다.

  • 나(또는 소속 회사)는 내가 기여하려고 하는 기여물을 프로젝트에 기여할 권리가 있다. (즉, 이 기여물의 저작자이다.)
  • 나(또는 소속 회사)는 나의 기여물을 프로젝트가 수정, 배포, 관리할 수 있는 권한을 프로젝트에 부여한다.
  • 나(또는 소속 회사)는 부여한 권한을 철회하지 않는다.
  • 나(또는 소속 회사)는 프로젝트가 향후 필요에 따라 라이선스를 변경할 수 있는 권한을 프로젝트에 부여한다.

또한, 드문 경우지만, 어떤 CLA는 다음과 같은 조건에 대해서도 동의를 요구한다.

  • 나(또는 소속 회사)는 나의 기여물을 기여함과 동시에 나의 저작권을 프로젝트 또는 프로젝트 관리 조직으로 양도한다.

회사는 자사의 지식재산 보호를 위해 저작권 양도를 요구하는 오픈소스 프로젝트로의 기여는 허용하지 않는다. 이러한 판단을 위해 회사의 구성원은 기여하려는 오픈소스 프로젝트에서 CLA 서명을 요구할 경우, 서명하기 전에 반드시 OSPO에 리뷰를 요청한다.

(5) 저작권 표시

구성원이 재직 기간에 생성한 저작물의 지식재산은 기본적으로 회사가 소유한다. 따라서, 구성원은 외부 오픈소스 프로젝트에 코드를 기여할 때 회사의 저작권을 표기해야 한다.

하나 이상의 파일을 기여할 때, 다음과 같이 파일 상단에 저작권과 라이선스를 표기한다.

Copyright (c) {$year} {$Company}
SPDX-License-Identifier: {$SPDX_license_name}

여기서 $SPDX_license_name은 해당 오픈소스 프로젝트의 라이선스 정책에 따라 작성한다.

단, 버그 수정 등의 목적으로 기존 코드를 수정하는 정도라면 해당 코드 수정에 대해 저작권을 표기할 필요는 없다.

(6) 회사 이메일 사용

오픈소스 프로젝트에 기여 시 개인 이메일을 사용하지 말고, 회사 이메일을 사용한다. 이를 통해 (1) 구성원은 회사를 대표하여 커뮤니티와 커뮤니케이션한다는 책임감을 갖게 되고, (2) 회사가 오픈소스 커뮤니티에 기여 활동을 활발히 하는 회사로 인지도를 개선할 수 있다.

8. 오픈소스 공개

회사는 오픈소스 커뮤니티와의 협업의 가치를 존중하고, 이를 내부 소프트웨어를 오픈소스 프로젝트로의 공개를 장려한다. 하지만, 회사의 지식재산 보호와 의도치 않은 저작권 침해를 방지하기 위해 준수해야 할 몇 가지 규칙이 있다.

(1) 승인

오픈소스 공개는 저작권 관점에서 저작자가 저작물을 누구나 수정/사용/배포할 수 있는 권한을 오픈소스 라이선스를 통해 부여하는 것이다. 일반적으로 고용 기간에 만든 저작물의 저작권은 고용주가 소유한다. 즉, 회사 구성원이 만든 저작물은 회사가 소유한다. 구성원이 임의로 저작물을 오픈소스로 공개하는 행위는 불필요한 저작권 침해 이슈를 유발할 수 있다.

따라서, 소프트웨어를 오픈소스로 공개하고자 한다면 회사 오픈소스 공개 정책에 따라 리뷰 요청 및 승인 절차를 따른다.

공개하는 과정에서 어느 것이라도 무언가 바람직하지 않아 보이는 상황이 있다면 주저하지 말고 OSPO에 문의한다.

(2) 공개할 권리가 있는 코드만 공개

오픈소스 프로젝트에서 발생할 수 있는 최악의 상황 중 하나는 법적으로 문제가 있는 코드가 프로젝트에 포함되는 것이다. 회사가 배포할 권리가 없는 코드이거나, 다른 회사의 특허와 같은 IP를 침해하는 코드가 법적인 문제를 유발할 수 있다. 따라서, 공개할 코드를 준비하면서 모든 코드의 출처를 확인하고 문제 소지가 있는 코드는 삭제한다.‌

(3) 지식 재산 노출에 주의

민감한 정보, 특허 등 기업의 지식재산 노출이 우려되는 코드, 문서는 공개하지 않는다.

공개하려는 코드에 회사의 특허가 포함되어 있다면, 이 특허를 오픈소스 라이선스로 공개해도 되는지 확인한다. 모호한 부분이 있다면 OSPO에 문의한다.

(4) 유용한 코드 공개

성공적인 프로젝트가 되기 위해서는 다른 사람들에게도 유용해야 한다. 만약, 유사한 프로젝트가 이미 존재한다면, 새로운 프로젝트를 만드는 것보다 기존의 프로젝트에 참여한다.

공개하려는 오픈소스가 (1) 오픈소스 커뮤니티에 차별화된 가치를 제공하고, (2) 커뮤니티가 해결되지 못했던 문제를 해결하며, (3) 우리의 기술력을 공개함으로 긍정적인 관심을 끌 수 있는 프로젝트가 되기를 기대할 수 있어야 한다.

  • 실제 제품이나 서비스에 사용하지 못한 코드라면 오픈소스로도 공개하지 않는다.
  • 오픈소스 커뮤니티에서 이미 해결한 문제를 다루는 코드는 공개하지 않는다. 이런 경우라면, 기존의 오픈소스 프로젝트에 기여한다.

(5) 리소스 확보

개발자를 포함해서 프로젝트에 투입해야 할 리소스를 확보한다.‌

  • 초기에는 일반적인 사내 프로젝트와 비슷한 수준의 개발자가 필요하다.
  • 외부의 기여를 신속하게 리뷰 할 수 있는 개발자가 필요하다.
  • 법무팀, 마케팅팀의 역할도 필요하다.
  • 프로젝트를 유지, 관리하는데 요구되는 인프라에 대한 예산을 확보한다. 여기에는 Github와 같은 프로젝트 호스팅을 위한 도구가 포함된다.

충분한 리소스가 지원되는 환경을 조성할 수 없다면, 오픈소스로 공개하지 않는다.

(6) 회사 이메일 사용

오픈소스 공개 활동 시 개인 이메일을 사용하지 말고, 회사 이메일을 사용한다. 이를 통해 (1) 구성원은 회사를 대표하여 커뮤니티와 커뮤니케이션한다는 책임감을 갖게 되고, (2) 회사가 오픈소스 커뮤니티에 공개 활동을 활발히 하는 기업으로 인지도를 개선할 수 있다.

9. 외부 문의 대응

(1) 외부 문의 대응책임

외부로부터 오픈소스 컴플라이언스에 대한 문의 및 요청에 대한 대응은 오픈소스 프로그램 매니저가 담당한다.(3.2.1.2)

  • 오픈소스 프로그램 매니저는 회사 내의 적절한 인원에게 문의에 대한 전체 또는 일부의 처리를 할당할 수 있다. 필요할 경우 법률 담당에게 문의하여 처리한다.
  • 외부로부터 오픈소스 컴플라이언스에 대한 문의를 받은 사람은 누구나 이를 오픈소스 프로그램 매니저에게 알려서 신속한 대응이 될 수 있게 한다.

(2) 연락처 공개

오픈소스 프로그램 매니저는 외부에서 오픈소스 관련한 문의 및 요청을 할 수 있도록 담당자의 연락처를 공개적으로 제공한다.(3.2.1.1)

  • 오픈소스 고지문에 연락받을 수 있는 이메일 주소 정보를 제공한다.
  • Linux Foundation의 Open Compliance Directory에 연락처를 등록한다.

(3) 외부 문의 대응 절차

외부로부터의 오픈소스 컴플라이언스 문의에 신속하고 정확하게 대응한다면 소송까지 진행되는 위험을 크게 줄일 수 있다. 이를 위해 회사는 외부의 오픈소스 컴플라이언스 문의에 대응하기 위해 회사의 오픈소스 컴플라이언스 프로세스에서 정의한 외부 문의 대응 절차를 준수한다.(3.2.1.2)

10. OpenChain

회사는 소프트웨어 공급망에서의 오픈소스 컴플라이언스 수준 향상을 위해 Linux Foundation의 OpenChain 프로젝트의 정신을 지지하며 적극적으로 참여한다.

  • 회사는 이 오픈소스 정책을 적용하여 2021년 10월 1일부로 ISO/IEC 5230:2020을 준수함을 보장한다.(3.6.1.1)
  • 회사는 적합성 인증을 획득한 후 18개월 이상 OpenChain 규격 버전 2.1, ISO/IEC 5230:2020의 모든 요구사항을 충족함을 보장한다.(3.6.2.1)
  • 회사는 최소 18개월 간격으로 적합성을 검토하고 필요에 따라 정책을 변경 및 갱신한다.

Appendix 1. 담당자 현황

No역할책임필요 역량담당 조직담당자
1Open Source Program Manager회사의 오픈소스 프로그램에 대한 총괄 책임을 담당한다.1. 소프트웨어 개발 프로세스 이해
2. 저작권, 특허 등 오픈소스 라이선스와 관련한 지식재산 이해
3. 오픈소스 컴플라이언스에 대한 전문 지식
4. 오픈소스 개발 경험
5. 커뮤니케이션 스킬
CTOOOO
2Legal오픈소스 라이선스와 의무를 해석한다. 이러한 의무를 실제 이행하는 등 오픈소스 활용을 위해 발생할 수 있는 법적 위험의 완화를 위한 자문을 제공한다.1. 오픈소스 생태계에 대한 기본 지식
2. 소프트웨어 저작권에 대한 전문 지식
3. 오픈소스 라이선스에 대한 전문 지식
법무팀OOO
3Infrastructure오픈소스 분석 도구를 운영하고 자동화하여 모든 배포용 소프트웨어에 대해 라이선스 분석이 원활히 수행되도록 시스템을 구축한다.1. 오픈소스 컴플라이언스 프로세스에 기본 지식
2. 오픈소스 라이선스 분석 도구에 대한 이해
3. IT 인프라에 대한 전문 지식
IT 인프라팀OOO
4Security오픈소스 보안취약점 분석 도구를 운영하여 모든 배포용 소프트웨어에 대해 보안취약점 분석이 원활히 수행되도록 시스템을 구축한다.1. 오픈소스 컴플라이언스 프로세스에 기본 지식
2. 오픈소스 라이선스 분석 도구에 대한 이해
3. 보안에 대한 전문 지식
보안팀OOO
5Development culture사내 개발자들이 오픈소스를 적극적으로 활용하고 사내외 커뮤니티에 참여하여 선진 개발 문화를 습득할 수 있도록 지원한다.1. 소프트웨어 개발 프로세스 이해
2. 오픈소스 컴플라이언스에 대한 기본 지식
3. 오픈소스 정책에 대한 이해
DROOO
6Development team소프트웨어 개발/배포 조직은 올바른 오픈소스 활용을 위해 오픈소스 정책 및 프로세스를 준수한다.1. 소프트웨어 개발 프로세스 이해
2. 오픈소스 컴플라이언스에 대한 기본 지식
3. 오픈소스 정책에 대한 이해
4. 오픈소스 라이선스에 대한 기본 지식
개발팀전원

7.9.2 - 2. 오픈소스 컴플라이언스 프로세스 (샘플)

OOO 주식회사(이하 “회사"라 함)는 소프트웨어를 포함하는 제품과 서비스를 개발하면서 오픈소스 소프트웨어(이하 “오픈소스"라 함)를 적극적으로 활용한다. 회사는 소프트웨어를 배포하면서 오픈소스 라이선스가 부과하는 의무사항을 준수하기 위한 활동을 수행해야 하며 이를 오픈소스 컴플라이언스라고 한다.

1. 소프트웨어 제품 개발/배포를 위한 프로세스

오픈소스 컴플라이언스 프로세스는 회사가 소프트웨어 제품 및 서비스를 개발하고 배포하기 위한 각 개발 단계에 맞게 오픈소스 라이선스 의무 준수를 위해 수행해야 할 절차를 정의한다. 소프트웨어 제품 개발/배포에 관여하는 모든 구성원은 다음의 오픈소스 컴플라이언스 프로세스 10단계를 준수한다.

general-osc-process

1. 오픈소스 식별Identification of Open Source

개발 부서는 소프트웨어 설계 단계에서 다음 사항을 준수한다.

  • 소프트웨어를 설계하면서 예측 가능한 오픈소스 사용 현황을 파악하고 라이선스를 확인한다.
  • 오픈소스 라이선스별 의무 사항을 확인한다. 라이선스별 의무 사항은 회사의 오픈소스 라이선스 가이드에서 확인할 수 있다.
  • 각 오픈소스 라이선스의 소스 코드 공개 범위를 고려하여 소프트웨어를 설계한다.

오픈소스 프로그램 매니저는 주요 오픈소스 라이선스 의무, 제한, 권리에 대한 가이드를 작성하고 공개하여 전사의 개발 부서에서 참고하게 한다.

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

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

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

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

2. 소스 코드 검사Auditing Source Code

개발 부서는 IT 담당의 안내에 따라 소스 코드를 제공하여 오픈소스 점검을 요청한다.

IT 담당은 오픈소스 분석 도구를 사용하여 오픈소스 점검을 하고, 오픈소스 BOM을 생성한다.

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

3. 문제 해결Resolving Issues

개발 부서는 소스 코드 검사 단계에서 발견된 모든 문제를 해결한다. 이슈가 된 오픈소스를 제거하거나, 다른 라이선스 하의 오픈소스로 교체하는 등 조치를 한다.

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

4. 검토Reviews

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

5. 승인Approval

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

6. 등록Registration

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

IT 담당은 확정된 BOM을 시스템에 등록한다. BOM에는 배포용 소프트웨어에 포함된 오픈소스 목록과 다음과 같은 정보를 포함한다.

  • 배포용 소프트웨어의 제품(혹은 서비스) 이름과 버전
  • 오픈소스 목록
    • 오픈소스 이름 / 버전
    • 오픈소스 라이선스

7. 고지Notices

오픈소스 프로그램 매니저는 고지 의무를 준수하기 위한 오픈소스 고지문을 생성한다. 오픈소스 고지문에는 다음 사항을 포함한다.

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

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

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

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

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

8. 배포 전 확인Pre-Distribution Verifications

개발 부서는 오픈소스 컴플라이언스 활동이 적절히 수행되었음을 입증하는 다음의 산출물을 제출한다.

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

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

9. 배포Distribution

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

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

10. 최종 확인Final Verifications

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

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

외부로부터의 오픈소스 컴플라이언스 문의에 신속하고 정확하게 대응한다면 소송까지 진행되는 위험을 크게 줄일 수 있다. 이를 위해 기업은 외부의 오픈소스 컴플라이언스 문의에 대응하기 위해 다음과 같은 프로세스를 준수한다.

general-inquiry-process

1. 접수 알림Acknowledge

오픈소스 프로그램 매니저는 문의를 받은 즉시 요청자에게 문의가 접수되었음을 알린다. 이때 조치 예정일을 함께 알린다. 요청자의 의도가 무엇인지 정확히 파악하는 것이 중요하기 때문에 문의가 불명확한 경우 추가 설명을 요청한다.

대응이 필요한 문의 및 요청의 주요 내용은 아래와 같다.

  • 특정 제품 및 서비스에 오픈소스가 사용되었는지 문의
  • 서면 약정(Written Offer)에 언급된 GPL, LGPL 라이선스 하의 소스 코드 제공 요청
  • 오픈소스 고지문에 명시되지 않았지만, 제품에서 발견된 오픈소스에 대한 해명 및 소스 코드 공개 요청
  • GPL, LGPL 등의 의무로 공개된 소스 코드에 누락된 파일 및 빌드 방법 제공 요청
  • 저작권 표시 요청

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

2. 조사 알림Inform

오픈소스 프로그램 매니저는 요청자에게 오픈소스 컴플라이언스를 충실히 수행하고 있음과 요청자의 문의를 조사하고 있음을 알린다. 내부 조사 진행 상황이 업데이트될 때마다 알리는 것이 좋다.

3. 내부 조사Investigate

오픈소스 프로그램 매니저는 요청 사항에 대한 내부 조사를 진행한다. 문제가 된 제품의 버전에 대하여 컴플라이언스 프로세스가 적절하게 수행되었는지 BOM 및 문서화된 검토 이력을 통해 확인한다. 필요 시 법무 담당에 자문을 요청한다.

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

4. 요청자에게 보고Report

오픈소스 컴플라이언스 담당은 조치 예정일 내에 내부 조사를 마치고, 요청자에게 결과를 알린다.

  • 요청자의 문의가 오해로 인한 잘못된 지적이었다면 추가 조치 없이 요청자에게 이를 알리고 처리를 종료한다.
  • 문제가 맞는다면 요청자에게 해당 오픈소스 라이선스의 의무를 이행하기 위한 정확한 방법과 시기를 알린다.

5. 문제 보완 / 알림Rectify

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

6. 문제 해결 알림Report

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

7. 프로세스 개선Improve

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

7.9.3 - 3. Tools (FOSSology, SW360)

오픈소스 컴플라이언스 활동을 위해서는 정책, 프로세스나 교육자료뿐만 아니라 소스코드 스캔, Dependency 분석, 오픈소스 BOM 관리 등을 위한 다양한 도구와 시스템도 요구된다. 때문에 다수의 기업이 이러한 도구와 시스템을 도입하고 활용하는 데 많은 리소스를 투입하고 있다. 특히 오픈소스 컴플라이언스를 처음 시작하는 기업은 프로세스뿐 아니라 비용 측면에서도 어려움을 겪고 있다.

이런 어려움을 해결하기 위해, 2019년 6월, OpenChain 프로젝트에 참여하고 있는 지멘스, 보쉬, 도시바, 후지쓰, 히타치 등의 오픈소스 컴플라이언스 도구 전문가들을 주축으로 OpenChain Tooling Work Group이 시작되었다.

OpenChain Tooling Work Group은 여러 기업의 오픈소스 전문가들이 이슈를 함께 해결하고 결과물을 공유해 오픈소스 컴플라이언스 비용을 절감하고 양질의 컴플라이언스 결과물을 만들어 내기 위해 구성되었다.

구체적으로는 FOSSology, SW360, Software Heritage, ClearlyDefined, SPDX 등의 기존 오픈소스 프로젝트를 활용하여 통합(turn-key) 오픈소스 툴 체인을 만들고, 모든 기업이 이를 자유롭게 사용할 수 있도록 하는 것을 목표로 삼고 있다. (https://groups.io/g/oss-based-compliance-tooling)

여기서는 FOSSology와 SW360에 대해 소개 및 간단한 사용 방법에 대해 알아본다.

7.9.3.1 - FOSSology

오픈소스 컴플라이언스를 위해 소프트웨어 내에 포함된 오픈소스와 라이선스 정보를 검출하기 위해 소스코드 스캔 도구를 사용할 수 있다.

https://www.fossology.org/

< https://www.fossology.org/ >

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 정보는 어떻게 되는지를 간단히 확인할 수 있다.

7.9.3.2 - SW360

(Updated on August 29, 2023.)

오픈소스를 포함하는 제품을 개발하고 배포하는 기업이라면 각 제품과 릴리스 버전마다 사용한 오픈소스의 버전, 라이선스 등의 정보를 수집하고 추적해야 한다. 이를 통해 기업은 올바른 오픈소스 컴플라이언스 활동을 수행할 수 있다.

특히, NVD (https://nvd.nist.gov/vuln)에서 특정 오픈소스 버전에 보안 취약점이 보고 되었을때, 해당 버전을 사용하고 있는 제품이 무엇인지 추적을 할 수 없다면, 그 기업은 어느 제품에 보안 패치를 적용해야 할 지 알 수 없는 상황에 처하게 되고, 그 기업의 제품들은 보안취약점에 그대로 노출이 될 수 밖에 없다.

이렇듯, 오픈소스 정보를 추적하는 활동은 꼭 필요하다. 기업들은 이를 위해 자체 시스템을 구축하거나, 상용 서비스를 구매하여 사용하기도 한다. SW360은 Eclipse 재단에서 후원하는 오픈소스로서 소프트웨어 BOM에 대한 정보를 수집 및 추적하기 위한 웹 애플리케이션 및 저장소를 제공한다.

https://www.eclipse.org/sw360/

< https://www.eclipse.org/sw360/ >

주요 특징

SW360은 웹 기반의 UI를 제공하며 주요 기능은 다음과 같다.

  • 제품에 사용된 컴포넌트 추적
  • 보안 취약점 평가
  • 라이선스 의무 관리
  • 고지문 등 법적 문서 생성

https://www.eclipse.org/sw360/

설치

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 설정

설정을 위해 다음 계정으로 로그인한다.

로그인을 하면 아래와 같이 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에 진입하여 JQueryFont 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 CONTENTUse 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 등록을 자동화시켜서 관리한다면 효율성이 크게 증가될 것이다.