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을 제공해야 할 수도 있습니다.

구체적인 예시

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

구현 시 고려사항

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

자동화 도구 활용 방안

SBOM 생성/관리를 위한 자동화 도구 중 오픈소스로 공개된 도구로는 FOSSLight, SW360, OSV-SCALIBR 등이 있습니다. 이러한 도구의 설치 및 사용 방법은 아래 가이드를 참고하세요.

• FOSSLight
• SW360
• OSV-SCALIBR

표 : 주요 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 생성 및 유지 절차를 포함합니다. (참고 : 오픈소스 프로세스 템플릿)

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

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

구현 시 고려사항

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

문서화 방안

오픈소스 프로세스 내 아래와 같이 보안 취약점 관리 프로세스를 포함합니다. (참고 : 오픈소스 프로세스 템플릿)

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