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

• 1: 1. 오픈소스 보안, 왜 중요한가?
• 2: 2. ISO/IEC 18974의 주요 요구사항
• 3: 3. ISO/IEC 18974 구현 방법
• 3.1: 3.1 Program Foundation
• 3.2: 3.2 Relevant Tasks Defined and Supported
• 3.3: 3.3 Open Source Software Content Review and Approval
• 3.4: 3.4 Adherence to the specification requirements
• 4: 4. ISO/IEC 5230과의 비교 및 통합
• 5: 5. 조직 특성별 구현 고려사항
• 6: 6. ISO/IEC 18974 자체 인증 절차
• 7: 7. 사례 연구 및 성공 전략
• 8: 8. 결론 및 향후 전망

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. ISO/IEC 18974의 주요 요구사항

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

2.1 프로그램 기반

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

2.1.1 정책 (Policy)

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

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

정책 수립 시 고려사항

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

2.1.2 역량 (Competence)

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

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

역량 강화를 위한 고려사항

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

2.1.3 인식 (Awareness)

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

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

인식 제고를 위한 활동

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

2.1.4 자원 (Resources)

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

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

자원 제공을 위한 고려사항

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

2.1.5 측정 (Measurement)

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

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

측정을 위한 고려사항

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

2.2 관련 업무 정의 및 지원

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

2.2.1 접근성 (Access)

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

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

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

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

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

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

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

자원 배분을 위한 고려사항

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

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

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

2.3.1 SBOM (Software Bill of Materials)

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

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

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) 요구사항 및 검증 자료

보안 보증을 위한 고려사항

• 취약점 스캐닝: 자동화된 취약점 스캐닝 도구를 사용하여 오픈소스 컴포넌트의 취약점을 주기적으로 검사합니다. (예: 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) 요구사항 및 검증 자료

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

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

2.4 규격 요구사항 준수

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

2.4.1 프로그램 준수 (Program Conformance)

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

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

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

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

2.4.2 지속적 개선 (Continuous Improvement)

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

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

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

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

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

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

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.
• 프로그램의 성능과 효과에 영향을 미치는 역할과 책임을 식별하고 문서화했습니다.

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

구현 방법 및 고려사항

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

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

세부 사례는 오픈소스 정책 템플릿 Appendix 1. 담당자 현황에서 확인하세요.

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.
• 각 역할에 필요한 역량을 식별하고 문서화했습니다.

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

구현 방법 및 고려사항

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

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

세부 사례는 오픈소스 정책 템플릿 Appendix 1. 담당자 현황에서 확인하세요.

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

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.
• 프로그램 참여자 목록과 각자의 역할을 문서화했습니다.

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

구현 방법 및 고려사항

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

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

세부 사례는 오픈소스 정책 템플릿 Appendix 1. 담당자 현황에서 확인하세요.

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

예시 증거 자료

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

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

개선 계획 예시

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

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

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.
• 프로그램 참여자가 다음 주제에 대한 인식을 갖추고 있습니다:
  • 오픈소스 보안 보증 정책 및 위치
  • 관련 오픈소스 목표
  • 프로그램의 효과성을 보장하기 위한 기대되는 기여
  • 프로그램 요구사항을 따르지 않을 경우의 영향

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

구현 방법 및 고려사항

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

예시 증거 자료

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

예시 (담당자 현황 기반)

개선 계획 예시

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

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

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

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의 사전 승인을 받아야 합니다.”
• 소규모 조직:
  • 적용 범위: “회사의 주력 제품에 포함된 오픈소스 컴포넌트에 적용됩니다.”
  • 예외: “내부 관리 시스템에 사용되는 오픈소스는 본 프로그램의 적용 범위에서 제외됩니다.”

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

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

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(시간 제한적)해야 합니다.
• 핵심 목표 연계: 메트릭은 프로그램의 핵심 목표(예: 위험 감소, 비용 절감, 효율성 향상)와 직접적으로 연계되어야 합니다.
• 데이터 수집 및 분석: 메트릭을 측정하기 위한 데이터 수집 및 분석 시스템을 구축해야 합니다.
• 정기적인 검토: 메트릭의 적절성을 정기적으로 검토하고, 필요한 경우 조정해야 합니다.

예시 메트릭

데이터 수집 방법

• 자동화된 도구 활용: 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.
• 검토, 업데이트, 또는 감사에서 지속적인 개선을 입증하는 문서화된 증거가 있습니다.

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

구현 방법 및 고려사항

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

예시 증거 자료

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

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

개선 계획 예시

• 자동화 도구 도입: 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)을 식별하고, 해당 취약점이 조직의 시스템에 미치는 영향을 평가합니다.
• 마이크로서비스 아키텍처에서 서비스 간 통신 시 인증 및 권한 부여 메커니즘을 검토하고, 서비스 간 무단 접근을 방지하기 위한 보안 조치를 적용합니다.
• 사용 중인 오픈소스 컴포넌트의 버전이 최신인지 확인하고, 더 이상 유지보수가 이루어지지 않는 컴포넌트를 식별합니다.

구현 시 고려사항

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

자동화 도구 활용 방안

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

• FOSSLight
• SW360
• OSV-SCALIBR

문서화 방안

오픈소스 프로세스 내 아래 내용을 포함합니다. (참고 : 오픈소스 프로세스 템플릿)

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

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 점수를 확인하여 심각도를 평가합니다.
• 고위험 취약점에 대해서는 보안 전문가가 직접 코드를 검토하고, 공격 가능성을 분석합니다.
• 취약점이 발견된 경우, 개발팀은 즉시 패치를 적용하거나, 완화 조치를 취합니다.

구현 시 고려사항

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

자동화 도구 활용 방안

취약점 데이터베이스와 연동하여 자동화된 취약점 스캔 기능을 제공하는 도구 중 오픈소스로 공개된 도구로는 FOSSLight, SW360, OSV-SCALIBR 등이 있습니다. 이러한 도구의 설치 및 사용 방법은 아래 가이드를 참고하세요.

• FOSSLight
• SW360
• OSV-SCALIBR

문서화 방안

오픈소스 프로세스 내 아래 내용을 포함합니다. (참고 : 오픈소스 프로세스 템플릿)

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

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

구현 시 고려사항

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

자동화 도구 활용 방안

출시 전 지속적이고 반복적인 보안 테스트를 가능하게 하는 도구 중 오픈소스로 공개된 도구로는 FOSSLight, SW360, OSV-SCALIBR 등이 있습니다. 이러한 도구의 설치 및 사용 방법은 아래 가이드를 참고하세요.

• FOSSLight
• SW360
• OSV-SCALIBR

문서화 방안

오픈소스 프로세스 내 아래 내용을 포함합니다. (참고 : 오픈소스 프로세스 템플릿)

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

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자와 효과적으로 공유하고, 공급망 전반의 보안을 강화할 수 있습니다. 책임감 있는 정보 공유는 조직의 신뢰도를 높이고, 장기적인 비즈니스 관계를 구축하는 데 기여할 것입니다.

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. 정기적인 검토 및 업데이트:
   • 프로그램의 역할 정의는 조직의 구조, 운영 방식, 그리고 기술 환경 변화에 따라 변경될 수 있습니다.
   • 따라서, 역할 정의 문서를 정기적으로 검토하고 업데이트하여, 최신 상태를 유지해야 합니다.

예시

구현 시 고려사항

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

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

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. 교육 및 인식 제고:
   • 새로 할당된 책임자에 대해 필요한 교육을 제공합니다.
   • 전체 조직을 대상으로 책임 할당 결과를 공유하여 인식을 제고합니다.

문서화 방안

오픈소스 정책 내 아래 내용을 포함합니다. (참고 : 오픈소스 정책 템플릿)

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

구체적인 예시

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

구현 시 고려사항

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

문서화 방안

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

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

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 표준 준수 상태를 지속적으로 유지하고, 고객에게 안전하고 신뢰할 수 있는 오픈소스 소프트웨어를 제공할 수 있습니다.

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의 주요 공통점

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

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의 상호 보완적 관계

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 통합 구현 전략

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 구현 핵심 요소

5.1.2 중소기업

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

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

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

5.1.3 스타트업

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

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

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

성공 사례:

• 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: 기존 보안 프로세스와의 통합 방법

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: 교육 및 인식 제고 프로그램 요소

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 핵심 요구사항 예시

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

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

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

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

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

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

6.1.3 갭 분석 수행

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

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

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

6.1.4 OpenChain Project 체크리스트 활용

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

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

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

이 표는 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: 오픈소스 보안 정책 포함 내용

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: 프로세스 및 절차 개선 내용

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: 오픈소스 보안 도구 선정 기준

6.2.4 문서화 작업

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

표 6.8: 문서화 작업 내용

이 단계를 통해 조직은 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 자체 인증 체크리스트 예시

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

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

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

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

1. 자체 인증 페이지 접속:
   • OpenChain Project 웹사이트(https://www.openchainproject.org/security-assurance)의 ISO/IEC 18974 자체 인증 페이지에 접속합니다.
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: 내부 감사 점검 항목 예시

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. 지식 공유:
   • 개선 활동의 성공 사례와 실패 사례를 조직 내에 공유하여 학습 효과를 높입니다.
   • 사내 위키, 블로그, 뉴스레터 등을 활용하여 지식을 공유하고, 커뮤니케이션을 활성화합니다.

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 인증 획득 사례 요약

이 표는 다양한 기업 규모별 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 구현을 위한 핵심 전략

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

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 도입의 주요 이점

이 표는 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 도입의 주요 이점 요약

이 표는 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의 향후 전망 및 조직의 대비

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 구현을 위한 구체적인 권장 사항