SBOM Work Group

• 1: SOFTWARE BILL OF MATERIALS (SBOM)에 대한 기술 가이드라인 (인도 정부 발간)
• 2: 2025-11-26 대규모 공급망에서 SBOM을 어떻게 운영 단계에 적용할 것인가?
• 3: 2025-10-27 SBOM 품질 가이드와 규제 대응의 구체화
• 4: 2024-11-27 취약점과 미래 - 다층적 소프트웨어 취약점과 대응 전략
• 5: 2024-10-29 SBOM 관련 다양한 규제와 가이드라인에 대한 개요
• 6: 2024-07-30 킥오프 웨비나: SBOM의 실제 활용 방안 모색

1 - SOFTWARE BILL OF MATERIALS (SBOM)에 대한 기술 가이드라인 (인도 정부 발간)

1. Executive Summary

소프트웨어 제품은 다양한 구성 요소로 이루어져 있으며, 이 중 일부는 외부 소스에서 가져옵니다. 이러한 외부 구성 요소와 의존성에는 취약점이 있을 수 있어, 공격자가 이를 악용해 보안 사고나 침해로 이어질 수 있습니다. 주요 위협으로는 악성 코드 삽입, 오래된 구성 요소의 취약점 이용, 공급업체 침해 등이 있습니다. 이로 인해 데이터 유출, 운영 중단, 평판 손상 등의 문제가 발생할 수 있습니다. 이러한 위협에 대응하려면 소프트웨어 구축이나 개발에 사용되는 구성 요소에 대한 가시성과 투명성을 확보해야 합니다. 소프트웨어 부품 명세서(Software Bill of Materials, SBOM)는 조직이 소프트웨어나 자산에 포함된 구성 요소를 정확히 파악하여 취약점을 식별하고 수정하는 데 도움을 줍니다. SBOM을 활용하면 조직은 소프트웨어 보안을 개선하고 잠재적 위협으로부터 보호할 수 있습니다.

소프트웨어 부품 명세서(SBOM) 는 소프트웨어를 구성하는 모든 요소, 라이브러리, 모듈의 목록으로, 소프트웨어 구성에 대한 투명성을 제공합니다. 소프트웨어가 더욱 복잡해지고 외부 구성 요소에 대한 의존도가 높아짐에 따라 소프트웨어 구성을 이해하는 것이 중요해졌습니다. 사이버 보안 측면에서 소프트웨어를 공격으로부터 보호하려면 소프트웨어 구축에 사용된 의존성과 구성 요소를 파악해야 합니다. 따라서 SBOM은 현대 사이버 보안 절차에서 핵심적인 도구입니다.

SBOM은 소프트웨어 보안 유지에 필수적입니다. 이를 통해 조직은 소프트웨어의 구성 요소를 이해하고, 잠재적 위험을 관리하며, 보안 문제에 대응하고, 규정을 준수할 수 있습니다. 다음은 조직이 SBOM을 구현함으로써 얻을 수 있는 주요 이점입니다:

1. 보안 관리 강화: 소프트웨어의 구성 요소를 파악함으로써 조직은 보안 위협에 취약할 수 있는 요소를 식별하고 대응할 수 있습니다.
2. 효과적인 사고 대응: 사이버 보안 사고 발생 시 SBOM은 상세한 구성 요소 정보를 제공하여 신속하게 대응하도록 돕습니다.
3. 취약점 식별 및 패치 관리: 모든 구성 요소를 나열함으로써 조직은 소프트웨어의 알려진 취약점을 빠르게 발견하고 패치할 수 있습니다.
4. 공급망 보안: 소프트웨어 제작에 사용된 외부 구성 요소에 대한 가시성을 확보함으로써 공급망 위험을 크게 줄일 수 있습니다.
5. 규정 준수 지원: SBOM은 소프트웨어 구성의 투명성을 제공하여 조직이 보안 규정, 지침 및 모범 사례를 준수하는 과정을 간소화합니다.
6. 운영 효율성 향상: 소프트웨어 구성 요소에 대한 명확한 이해를 통해 조직은 취약점 관리 프로세스를 간소화하여 시간과 자원을 절약할 수 있습니다.

인도 컴퓨터 비상 대응팀(CERT-In)은 특히 공공 부문, 정부, 필수 서비스, 소프트웨어 수출 및 서비스 산업 관련 조직을 위한 기술적 SBOM 지침을 발표했습니다. 부서와 조직은 보안을 강화하고 사이버 위협의 위험을 줄이기 위해 소프트웨어 조달 및 개발 과정에서 SBOM의 생성과 제공을 의무적인 표준 관행으로 삼도록 권장됩니다.

다음 장에서는 SBOM의 다양한 기술적 측면을 살펴보고 그 목적과 소프트웨어 공급망 생태계에서의 중요성이 증가하는 이유를 설명합니다. 두 번째 장에서는 SBOM의 개요와 범위 및 구현에 대해 논의하고, 이어서 SBOM 생태계에 대한 장에서는 SBOM의 다양한 수준과 분류에 대해 설명합니다. 그 다음 장에서는 SBOM 정보를 표현하는 데 사용되는 다양한 표준과 데이터 형식을 살펴보고, 최소 요소, 데이터 필드 및 자동화 지원에 대해 자세히 설명합니다. SBOM과 관련된 모든 프로세스와 관행의 목표, 안전한 SBOM 공유 및 배포에 대해 이 문서에서 상세히 다루며, SBOM의 취약점 추적 및 분석을 위한 접근 방식도 포함됩니다. 마지막으로, 문서의 마지막 장에서는 SBOM 구현을 위한 권장 사항과 모범 사례를 소개합니다.

2. SBOM 개요

2.1 필요성 및 활용

소프트웨어가 점점 복잡해짐에 따라 SBOM의 필요성이 더욱 커지고 있습니다. SBOM은 소프트웨어 구성 분석(SCA) 도구의 기반이 되며, 취약점 탐지, 라이선스 준수 지원, 공급업체 위험 관리의 토대가 됩니다.

소프트웨어 정의 시스템의 증가로 사이버 위협 환경이 크게 확대되었습니다. 공격자들은 민감한 시스템과 데이터에 침투하기 위해 소프트웨어 공급망을 점점 더 많이 노리고 있습니다.

부서와 조직은 소프트웨어 개발 및 조달 과정에서 소프트웨어 부품 명세서(SBOM)의 생성과 제공을 표준 관행으로 삼도록 권장됩니다. 이를 통해 보안, 규정 준수, 위험 관리, 공급망 투명성, 품질 보증, 상호 운용성, 공급업체 관리를 개선할 수 있습니다.

조직은 소프트웨어 수명 주기의 모든 단계(설계, 개발, 분석, 배포, 유지 관리, 업데이트 포함)와 관련된 중요 구성 요소를 철저히 분석하고 SBOM 사용을 의무화해야 합니다.

SBOM은 다음 세 가지 주요 목적을 달성하는 데 도움을 줍니다:

1. 정부 부서와 조직이 소프트웨어 구매에 대해 정보에 기반한 사전 결정을 내릴 수 있도록 지원합니다.
2. 정부 기관 및 필수 서비스 조직 전반에 걸쳐 취약점 관리, 자산 추적, 규정 준수를 촉진합니다.
3. 조직의 소프트웨어 개발 및 제품 유지 관리를 지원합니다.

모든 정부, 공공 부문, 필수 서비스 조직은 소프트웨어와 솔루션 구매/조달 요구 사항에 SBOM을 포함해야 합니다. 또한 사용자 조직의 보안 팀은 취약점 관리 작업 과정에 SBOM 목록을 반드시 포함해야 합니다.

2.2 적용 & 범위

이 가이드라인은 인도 컴퓨터 비상 대응팀(CERT-In)에서 다음과 같은 기관, 특히 정부, 공공 부문, 필수 서비스 조직 및 소프트웨어 수출과 서비스 산업 관련 조직을 위해 발행되었습니다:

1. 소프트웨어 소비자 - 운영 지원, 생산성 향상, 비즈니스 목표 달성을 위해 소프트웨어 애플리케이션을 구매하는 조직.
2. 소프트웨어 개발자 - 맞춤형 소프트웨어 솔루션을 개발하는 조직.
3. 시스템 통합업체/소프트웨어 재판매업체 - 소프트웨어 제품을 배포하고 맞춤화, 통합, 지원, 교육 등 부가가치 서비스를 제공하는 조직.

SBOM은 가시성 확보, 취약점 패치, 노출 감소, 신속한 대응을 위한 필수 도구가 되고 있습니다. 예를 들어, 일반적인 조직은 상호 연결된 시스템, 엔드포인트, 제어 시스템, 자동화 소프트웨어, 운영 기술(OT) 구성 요소의 방대한 네트워크에 의존합니다. 이러한 복잡한 IT 및 OT 환경에 대한 정확한 SBOM을 유지하면 보안 팀이 공격 표면을 더 잘 이해하고 취약점에 더 효과적으로 대응할 수 있습니다. 이러한 사전 예방적 접근 방식은 조직이 운영을 보호하고 사이버 위협에 대한 복원력을 확보하는 데 도움이 됩니다.

예를 들어, 금융 기관에서 SBOM은 사이버 보안 관점에서 중요합니다. 은행과 핀테크 기업은 디지털 서비스와 백엔드 시스템을 운영하기 위해 다양한 상용 제품(COTS) 소프트웨어, 오픈 소스 라이브러리, 맞춤 개발 구성 요소를 활용합니다. 이러한 다양한 소프트웨어 환경에 대해 최신 SBOM을 유지하면 보안 팀이 취약점을 신속하게 식별하고 완화하며, 산업 규정을 준수하고, 공급망 위험을 더 잘 관리할 수 있습니다.

소프트웨어 개발, 공급망 관리, 사이버 보안, 규제 준수와 관련된 SBOM의 사용 사례는 다음과 같습니다:

2.2.1 소프트웨어 개발 및 유지 관리

SBOM은 소프트웨어 시스템을 구성하는 요소와 의존성의 상세한 목록을 제공합니다. 이 정보를 통해 개발자는 취약점을 더 효과적으로 관리하고, 라이선스를 추적하며, 소프트웨어의 출처를 모니터링할 수 있습니다. 정확하고 최신 상태의 SBOM을 유지하는 것은 조직이 소프트웨어 공급망 위험을 이해하고 애플리케이션의 보안과 무결성을 보장하기 위한 사전 조치를 취하는 데 중요합니다.

2.2.2 공급망 관리

SBOM은 소프트웨어 공급망에 대한 투명성을 제공하여 조직이 외부 구성 요소의 보안과 신뢰성을 평가할 수 있게 합니다. 이는 외부 라이브러리나 구성 요소 사용과 관련된 잠재적 위험을 식별하는 데 도움이 되며 조달 및 공급업체 관리에 대한 정보에 기반한 의사 결정을 용이하게 합니다.

2.2.3 사이버 보안

SBOM은 기존 보안 도구와의 통합, 자동화된 취약점 탐지, 복구를 지원하여 사이버 보안 관행을 뒷받침합니다. SBOM은 소프트웨어 구성 요소와 그 의존성에 대한 가시성을 제공하여 조직이 보안 취약점을 효과적으로 식별하고 완화할 수 있게 합니다. 소프트웨어 구성에 대한 포괄적인 이해를 통해 조직은 보안 사고에 신속하게 대응하고, 취약점을 패치하며, 소프트웨어 시스템의 무결성과 보안을 보장할 수 있습니다.

2.2.4 규제 준수

SBOM은 특히 의료, 금융, 정부와 같은 필수 서비스를 다루는 산업에서 규제 준수를 위한 요구 사항이 되고 있습니다. 전 세계적으로 규제 기관들은 SBOM을 유망한 도구로 인식하고 있으며 EU 사이버 복원력 법(Cyber Resilience Act)과 같은 규정을 통해 SBOM 채택을 강조하고 있습니다.

2.2.5 위험 관리

SBOM은 소프트웨어 공급망에 대한 통찰력을 제공함으로써 위험 관리 노력을 지원합니다. 조직은 알려진 취약점, 라이선스 충돌, 더 이상 사용되지 않는 라이브러리와 같은 특정 소프트웨어 구성 요소와 관련된 잠재적 위험을 평가할 수 있습니다. 이러한 위험을 사전에 관리함으로써 조직은 소프트웨어 시스템의 복원력을 향상시키고 보안 침해나 규정 준수 문제의 가능성을 최소화할 수 있습니다.

2.2.6 상호 운용성 및 호환성

SBOM은 소프트웨어 구성 요소와 그 버전에 대한 상세한 정보를 제공함으로써 상호 운용성 및 호환성 테스트를 용이하게 합니다. 이는 서로 다른 소프트웨어 시스템이 호환성 문제 없이 원활하게 작동할 수 있도록 보장하는 데 도움이 되며, 따라서 소프트웨어 제품의 전반적인 품질과 신뢰성을 향상시킵니다.

2.3 SBOM 구현

SBOM은 모든 새로운 소프트웨어 구성 요소 출시에 대해 구현되어야 하며, 업데이트, 업그레이드, 출시, 패치 등 변경 사항이 있을 때마다 신속하게 갱신되어야 합니다. SBOM의 정확성은 구성 요소 자체가 변경되지 않았더라도 포함된 구성 요소에 대한 새로운 정보가 있을 때마다 업데이트하여 유지됩니다. 기존 구성 요소를 수정할 때는 일관된 접근 방식을 선택하세요. 변경 사항을 새로운 구성 요소로 취급하거나 기존 구성 요소를 업데이트하는 방식 중 하나를 선택하세요. 명확성을 위해 전체적으로 표준화된 버전 관리 방법을 사용하세요.

다음과 같은 조직의 시나리오를 고려해 보겠습니다:

A. 정부 조직 GovInsights는 소프트웨어 개발 회사 TechGenius를 고용하여 데이터 분석 애플리케이션 DataAnalyzer를 개발합니다.

B. DataAnalyzer 제품을 개발하기 위해 TechGenius 회사는 다음 구성 요소를 사용합니다:

1. MessageMaster 회사의 Postfix & Twilio SDK라는 SMS 및 이메일 서비스
2. DataVault 회사의 데이터베이스 구성 요소: PostgreSQL
3. ServerSolutions 회사에서 제공하는 Apache Tomcat Server (이 서버는 많은 오픈 소스 라이브러리를 사용했습니다)

앞서 언급한 시나리오의 다양한 구성 요소/소프트웨어와 해당 SBOM 유형 및 상태는 아래 표에 제공되어 있습니다:

Table 1: 소프트웨어 구성 요소와 SBOM 작성자 현황

이 시나리오에서 이해관계자와 구성 요소 간의 상호 관계는 Figure 1에 시각적으로 표현되어 있습니다. 묘사된 바와 같이, SBOM 생태계 내의 수많은 주체는 소프트웨어의 제공자와 소비자 역할을 모두 수행합니다. 이는 다른 주체가 제공한 SBOM의 정보를 활용할 뿐만 아니라 새로 개발된 구성 요소에 대한 SBOM을 생성하고 이를 다른 주체와 공유하는 것을 포함합니다. 이상적으로는 소프트웨어 구성 요소의 제작자가 해당 SBOM의 작성자가 되어야 합니다.

Figure 1: 시나리오 흐름도

• SBOM 소비자: 완전한 SBOM을 요청해야 합니다.
• 소프트웨어 개발자: 정확하고 완전한 SBOM이 소비자에게 제공되도록 해야 합니다.

3. 생태계

SBOM 생태계는 소프트웨어 공급망 전반에 걸쳐 SBOM의 생성, 배포, 분석, 활용에 관여하는 이해관계자, 도구, 표준, 프로세스의 네트워크를 포함합니다. 이 섹션에서는 소프트웨어 소비자/개발자/시스템 통합업체 조직이 조직 수준에서 SBOM 생태계를 개발하기 위한 접근 방식을 설명합니다. 또한 SBOM의 다양한 분류에 대해 설명합니다.

3.1 SBOM 수준

SBOM의 다양한 수준은 각각 다른 정도의 세부성과 복잡성을 제공하며, 특정 요구 사항과 각 소프트웨어 환경의 복잡성을 반영합니다. 조직은 투명성, 위험 관리, 운영 효율성의 효과적인 균형을 달성하기 위해 하나 이상의 SBOM 수준을 구현하도록 선택해야 합니다.

Figure 2: SBOM 수준

다중 SBOM 접근 방식을 채택하면 조직의 사이버 복원력을 크게 향상시킬 수 있습니다. 조직은 민감한 데이터를 노출하지 않고 보안 요구 사항을 해결하는 맞춤형 SBOM을 소비자를 위해 생성해야 합니다. 동시에 “완전한” 수준의 내부 SBOM을 유지하여 해당 소프트웨어와 관련된 취약점 업데이트를 식별하고 주기적으로 의무적으로 소비자와 상세히 공유해야 합니다. 이 접근 방식은 특히 조직이 완전한 소프트웨어 및 의존성 세부 정보를 공유함으로써 발생하는 데이터 유출 및 지적 재산 도용에 대한 제약이나 우려에 직면한 상황에서 생태계 전반에 걸쳐 사이버 복원력, 데이터 기밀성, 협력적 보안의 균형을 맞춥니다.

Table 2: SBOM을 작성한 조직의 시나리오에 따른 수준 매핑

3.2 SBOM의 분류

SBOM 분류는 소프트웨어 개발 생명주기 단계와 일치하며, 각각 고유한 데이터와 통찰력을 제공합니다. SBOM의 다양한 분류는 다음과 같습니다:

Figure 3: SDLC 단계와 일치하는 SBOM 분류

• 3.2.1 Design SBOM: 계획된 구성 요소를 포착하며, 실제로 존재하기 전에도 이를 기록합니다.
• 3.2.2 Source SBOM: 개발 환경을 반영하며, 소스 파일과 의존성을 포함합니다.
• 3.2.3 Build SBOM: 빌드 과정 중에 생성되며, 소스 파일, 의존성 및 사전 빌드된 구성 요소에 대한 세부 정보를 포함합니다.
• 3.2.4 Analyzed SBOM: 빌드 후 최종 소프트웨어 결과물을 검사하여 생성됩니다.
• 3.2.5 Deployed SBOM: 특정 시스템에 설치 및 구성된 소프트웨어의 목록을 제공합니다. 다양한 SBOM 유형의 정보를 결합하고 배포 환경을 고려합니다.
• 3.2.6 Runtime SBOM: 실행 중인 소프트웨어 구성 요소를 모니터링하여 생성됩니다. 외부 상호작용과 동적으로 로드된 의존성을 포함하여 런타임 실행 중의 정보를 캡처합니다.

3.3 조직의 SBOM 개발 및 채택을 위한 로드맵

조직 내 SBOM 생태계 구축은 단계적 접근이 필요합니다. 기본 토대(START)를 시작으로 발전(PROGRESS)시키고 최종적으로 성숙하고 확장 가능한 SBOM 구현(ADVANCE)에 도달해야 합니다. 활동 순서는 예시일 뿐이며, 조직의 보안 요구사항, 프로젝트 일정, 리소스 가용성에 따라 조정할 수 있습니다.

3.3.1 PHASE-1 (START): 기초 활동

이 단계의 기초 활동들은 SBOM 프로그램의 기반을 마련합니다. 첫 SBOM은 조달 과정에서 공급업체로부터 획득할 가능성이 높습니다. 소프트웨어는 아키텍처, 기존 리소스, 예산, 인력 가용성 측면에서 다양할 수 있으므로, 이 단계의 목적은 조직 내 SBOM 생태계 구축 방법을 수립하는 것입니다.

• 3.3.1.1 중요 자산 식별 및 프로젝트 계획 수립: 역할, 책임, 일정, 리소스 요구사항을 정의하는 종합적인 프로젝트 계획을 수립합니다. 새로운 SBOM 프로세스에 대한 이해관계자의 동의를 얻기 위한 변경 관리 요구사항도 식별합니다.

• 3.3.1.2 SBOM 형식 및 최소 요구사항 결정: SBOM 생성 전에 형식과 최소 데이터 요구사항을 정의합니다. 이는 공급망 전반에 걸쳐 일관된 공유와 처리가 가능한 표준화된 기계 판독 가능 구조를 보장합니다.

• 3.3.1.3 보안 요구사항, 안전한 저장소 및 도구 식별: 사이트 보안 정책에 맞는 적절한 분류 및 처리 절차를 결정합니다. SBOM을 위한 안전한 저장소를 구축하고, 초기에는 개별 SBOM을 전용 저장소에 분리 저장합니다. SBOM 프로그램이 성숙해지면 자산 관리 애플리케이션과 통합하고 취약점 데이터 등 다른 보안 관련 정보와 연결합니다.

• 3.3.1.4 조달 과정의 일부로 SBOM 획득: 구매 주문서나 계약서에 공급업체의 SBOM 제공 요구사항을 명시하고, SBOM 요소, 제공 시기 및 방법을 지정하여 투명성을 보장하고 SBOM 통합 프로세스를 용이하게 합니다.

3.3.2 PHASE – 2 (PROGRESS)

이 단계는 안전한 설치 및 구성 관리를 확립하고, 공급업체 및 구성 요소 네임스페이스 문제를 해결하기 위해 고유한 구성 요소 식별을 통합하는 지속적인 활동을 포함합니다. 소프트웨어 개발 조직에 의한 보안 소프트웨어 개발 수명주기(SSDLC)와의 통합은 빌드 단계에서 소프트웨어를 보호하기 위한 실행 가능한 보안 정보를 제공하기 시작할 것입니다.

• 3.3.2.1 안전한 설치 및 운영 지침 개발: 공급업체는 소비자 조직과 협력하여 대상 소비자의 기술 분야와 사용 요구에 맞춘 포괄적인 안전한 소프트웨어 설치 및 운영 체크리스트를 작성해야 합니다. 안전한 운영을 보장하기 위해 안전한 애플리케이션 설계, 개발, 구현 및 운영 지침에서 핵심 체크리스트 항목을 도출할 수 있으며, 이는 애플리케이션 수명 주기의 배포 및 운영 단계에서 다루어야 할 필수 고려 사항을 강조합니다.

• 3.3.2.2 각 구성 요소에 고유 식별자 할당: 소비자가 리브랜딩을 인식하지 못하면 보안 업데이트나 취약점을 간과할 수 있어 악용에 취약해질 수 있습니다. 이로 인해 소비자가 자체 SBOM에 포함할 정확한 데이터 필드(예: 현재 공급업체 및 구성 요소 이름)를 조사하기 어려워집니다. 공급업체 및 구성 요소 이름 변경은 SBOM 수정과 이전 SBOM에서 후속 버전으로의 링크를 통해 수정 이력을 유지해야 합니다. 이를 해결하기 위해 고유 식별자를 생성해야 합니다.

Table 3: 고유 식별자의 구문 및 예시

위 시나리오에 대한 고유 식별자는 다음과 같습니다: pkg:supplier/ApacheSoftwareFoundation/ApacheTomcat@9.0.71?arch=x86_64&os=linux#server/webapps

Table 4: 고유 식별자의 유용성

• 3.3.2.3 공급업체의 SBOM과 소비자의 내부 SBOM 매핑: 소비자 조직은 공급업체가 제공한 SBOM을 기반으로 내부 SBOM을 매핑하고 개발해야 합니다. 또한 내부 SBOM 개발자의 무결성과 효율적인 업데이트를 추적하기 위해 작성자 이름(소비자 조직의 담당자)과 타임스탬프를 포함해야 합니다.

• 3.3.2.4 SBOM 준비: SBOM은 공급업체와 소비자 조직 모두에서 준비해야 합니다. 알려진 취약점 데이터와 공급업체 취약점 증명을 상호 연관시켜 취약점이 있는 설치된 구성 요소를 식별합니다. 이를 바탕으로 조직이 내부적으로 또는 소프트웨어 공급업체가 외부적으로 complete-level SBOM을 생성하여 공급망 공격에 대한 보안과 가시성을 향상시켜야 합니다.

• 3.3.2.5 보안 소프트웨어 개발 수명주기의 각 단계에 SBOM 통합: 소프트웨어 개발 조직은 SSDLC의 각 단계에 SBOM을 통합할 수 있습니다. 설계 단계에서 SBOM은 구성 요소 선택 및 잠재적 보안 위험에 대한 결정을 알려야 합니다. 소프트웨어 개발 중 SBOM 사용은 효율성을 향상시키고 개발자와 사용자 모두에게 빌드 및 소스 구성 요소뿐만 아니라 제품 기능에 대한 더 큰 통찰력을 제공할 수 있습니다.

• 3.3.2.6 안전한 구성 관리 수립: SBOM의 안전한 구성 관리를 보장하기 위해 엄격한 접근 제어, 암호화, 주기적인 소프트웨어 감사 및 보안 프레임워크와의 통합을 구현합니다.

3.3.3 PHASE-3 (ADVANCE):

취약점 모니터링과 취약점 관리 및 사고 대응을 위한 security orchestration tool과 SBOM의 원활한 통합 관련 활동 강화

• 3.3.3.1 취약점 추적 프로세스 강화: SBOM과 연관된 취약점 정보를 수집합니다. 과거 취약점 정보는 SBOM 생태계에 통합되어야 하며, 전문가들은 SBOM repository에 나열된 component와 식별된 취약점을 상호 참조하고 관련 구성 데이터에 대한 장비 데이터베이스를 확인하여 알려진 취약점의 추적 및 분석을 위한 영향과 잠재적 완화 조치를 평가하는 절차를 보유해야 합니다.

• 3.3.3.2 사고 대응 프로세스 강화: CERT-In은 다양한 위협에 대한 경고, 취약점 노트 및 권고사항을 발행합니다. 이러한 위협은 주로 새롭게 공개된 소프트웨어 취약점과 관련이 있습니다. 조직은 threat hunting team을 구성하여 이 정보를 활용해 새로 발견된 위협에 대해 조직이 취약한지, 그리고 이미 침해당했는지 여부를 판단해야 합니다.

• 3.3.3.3 기존 SBOM 업데이트를 위한 정기적 분석 및 검토: 소프트웨어 component와 그 dependency가 최신 기록과 일치하는지 확인하고 적시에 업데이트를 보장하는 작업을 포함합니다.

• 3.3.3.4 새로운 소프트웨어 component와 산업 발전에 대한 인식 유지: 조직은 SBOM 실무자들이 직면한 과제를 준수하면서 조직 내 구현, 새로운 SBOM 형식, 데이터 요소에 대한 정보를 공유하기 위해 독립적으로 또는 third-party 조직과 협력하여 SBOM 인식 프로그램을 유지하도록 권장됩니다.

3.4 라이선스 관리

라이선스 관리는 SBOM의 초기 활용 사례 중 하나입니다. 이는 복잡한 소프트웨어 포트폴리오를 가진 큰 조직이 다양한 소프트웨어 구성 요소의 라이선스와 조건을 추적하는 데 도움을 줍니다. 특히 오픈 소스 소프트웨어에 대해 중요합니다. SBOM은 각 구성 요소의 라이선스 정보를 제공할 수 있어, 사용자가 법적 위험 없이 해당 소프트웨어를 다른 애플리케이션의 구성 요소로 사용할 수 있는지 판단할 수 있게 합니다. 소프트웨어에 포함된 구성 요소의 라이선스 정보를 확인하면 규정 준수 실수를 방지하고, 라이선스 위반 위험과 관리에 필요한 노력을 줄일 수 있습니다.

다음은 라이선스 관리 과정을 간소화하고 규정 미준수 위험을 줄이는 데 도움이 되는 방법들입니다:

1. 사용자가 평가 중인 제품의 라이선스와 모든 개별 구성 요소의 라이선스를 볼 수 있어야 합니다. 이를 통해 사용자는 제품 선택과 비즈니스 요구에 맞는 라이선스 계약 결정에 더 나은 판단을 할 수 있습니다.

2. SPDX 식별자와 같은 식별자로 각 소프트웨어 라이선스를 구분합니다. 이 식별자들은 특정 라이선스 조건을 나타내는 고유 코드 역할을 합니다. 조직은 이를 활용해 소프트웨어 자산의 라이선스 의무를 효과적으로 관리하고 이해해야 합니다.

3. 주요 데이터베이스에서 라이선스 식별자를 찾을 수 없다면, Scancode, LicenseDB, AboutCode 같은 다른 라이선스 데이터베이스를 살펴봐야 합니다. 이런 대체 식별자에는 출처를 나타내는 접두사(예: “LicenseRef-scancode-")를 붙여 쉽게 파악하고 이해할 수 있게 해야 합니다.

4. SPDX 같은 잘 알려진 목록에 없는 라이선스를 만나면, 조직은 고유한 식별자를 부여해야 합니다. 이렇게 하면 시스템 내에서 알려지지 않은 라이선스를 제대로 식별하고 추적할 수 있습니다.

5. 라이선스를 자리 표시자나 템플릿으로 수정할 때는 기본 조건이 바뀌지 않도록 주의해야 합니다. 대신 SPDX 라이선스 표현 같은 고유 식별자로 구분되는 원본 라이선스의 일부로 봐야 합니다. 이는 라이선스 관리의 명확성과 일관성을 유지하는 데 도움이 됩니다.

6. 소프트웨어에 여러 라이선스가 적용될 때는 연산자(예: SPDX 연산자)를 사용해 올바르게 조합하는 것이 중요합니다. 이 연산자들은 서로 다른 라이선스 식별자를 연결해 라이선스 표현의 명확성과 일관성을 보장합니다. 이를 통해 소프트웨어에 적용되는 라이선스 조건을 정확히 나타낼 수 있습니다.

7. 라이선스 관리 시 라이선스 텍스트에 붙은 예외 조항은 “WITH” 같은 적절한 연산자를 써서 주 라이선스 식별자와 연결해야 합니다. 또한 예외 조항 이름은 라이선스 식별에 대한 정해진 요구 사항에 따라 식별자로 설명되어야 합니다.

8. 라이선스 텍스트를 조금 바꿀 때, 수정 내용이 원본 라이선스의 의미를 크게 바꾸지 않는다면 원본 라이선스와 같은 식별자를 쓰는 것이 좋습니다.

4. SBOM 준비

4.1 SBOM의 최소 요소

SBOM의 최소 요소는 소프트웨어 구성 요소와 관련된 필수 정보인 “Data Fields"를 규정합니다. “Automation Support” 탐지 및 관리는 보안 오케스트레이션 도구와 조직의 SBOM 구현을 위한 “Process 및 Practice"와 통합하여 개선될 수 있습니다. “Minimum Elements"의 범주와 정의는 다음과 같습니다.

Table 5: SBOM의 최소 요소

4.2 Data Fields

Data fields는 추적하고 유지해야 하는 각 구성 요소에 대한 기본 정보를 포함합니다. 조직은 소프트웨어 구성 요소, dependency, 관련 메타데이터의 포괄적인 목록을 만들어 소프트웨어 개발 수명 주기 전반에 걸쳐 더 나은 투명성, 보안 및 위험 관리를 가능하게 할 수 있습니다.

Data fields의 목적은 이러한 구성 요소를 적절히 식별하는 것입니다. 이를 통해 소프트웨어 공급망 전반에 걸쳐 추적이 쉬워지고 취약점이나 라이선스 데이터베이스 같은 다른 유용한 데이터 소스와 연결할 수 있습니다. 기본 구성 요소 정보는 다음을 포함합니다:

1. Component Name: SBOM에 포함된 소프트웨어 구성 요소나 library의 이름
2. Component Version: 소프트웨어 구성 요소의 버전 번호나 식별자
3. Component Description: 소프트웨어 구성 요소의 기능과 목적에 대한 간단한 설명
4. Component Supplier: vendor, third-party supplier 또는 오픈소스 프로젝트와 같이 소프트웨어 구성 요소를 제공한 주체나 조직
5. Component License: 소프트웨어 구성 요소가 배포되는 라이선스로, 라이선스 유형, 조건 및 제한 사항과 같은 세부 정보 포함
6. Component Origin: 소프트웨어 구성 요소의 출처나 기원(독점, 오픈소스 또는 third-party vendor에서 획득)
7. Component Dependencies: 현재 구성 요소가 의존하는 다른 소프트웨어 구성 요소나 library(이름과 버전 포함)
8. Vulnerabilities: 소프트웨어 구성 요소와 관련된 알려진 보안 취약점이나 약점에 대한 정보(심각도 등급 및 보안 권고 또는 CVE 식별자에 대한 참조 포함)
9. Patch Status: 알려진 취약점이나 문제를 해결하기 위한 패치나 업데이트의 가용성을 나타내는 소프트웨어 구성 요소의 패치 또는 업데이트 상태
10. Release Date: 소프트웨어 구성 요소가 출시되거나 사용 가능하게 된 날짜
11. End-of-Life (EOL) Date: 소프트웨어 구성 요소에 대한 지원이나 유지보수가 종료되도록 예정된 날짜로, 수명 주기의 종료를 나타냄
12. Criticality: 애플리케이션의 전반적인 기능이나 보안에 대한 소프트웨어 구성 요소의 중요도(주로 critical, high, medium, low로 분류)
13. Usage Restrictions: 수출 통제 제한이나 지적 재산권과 같이 소프트웨어 구성 요소와 관련된 사용 제한이나 제약 사항
14. Checksums or Hashes: 무결성과 신뢰성을 보장하기 위한 소프트웨어 구성 요소 파일의 암호화 체크섬이나 해시
15. Comments or Notes: 소프트웨어 구성 요소나 SBOM 포함과 관련된 추가 설명, 메모 또는 주석
16. Author of SBOM Data: 이 구성 요소에 대한 SBOM 데이터를 생성하는 주체의 이름
17. Timestamp: SBOM 데이터 조립의 날짜와 시간 기록
18. Executable Property: SBOM 내의 구성 요소가 실행 가능한지를 나타내는 속성
19. Archive Property: SBOM 내의 구성 요소가 아카이브나 압축 파일로 저장되어 있는지를 나타내는 특성
20. Structured Property: SBOM에 나열된 구성 요소 내 데이터의 구성된 형식을 정의하는 설명자
21. Unique Identifier: 각 소프트웨어 구성 요소에 할당된 고유 코드로, “pkg:supplier/OrganizationName/ComponentName@Version?qualifiers&subpath” 형식으로 구성되어 소유권 변경과 버전 업데이트를 추적하여 정확하고 일관된 소프트웨어 구성 요소 관리를 보장

Table 6: 조직별 시나리오에서 활용된 Component의 Data Fields

4.3 Automation Support

자동 생성 및 기계 판독성과 같은 자동화 지원은 소프트웨어 생태계와 조직 경계를 넘어 확장할 수 있게 합니다. SBOM 데이터를 다양한 도구와 프로세스에 원활하게 통합하여 소프트웨어 공급망 전반에 걸친 협업과 가시성을 촉진합니다.

Figure 5: SBOM의 Automation Support 이점

SBOM 데이터를 활용하기 위해서는 일관된 데이터 형식과 구현이 필요한 도구가 필요합니다. 자동화는 SBOM의 생성, 유지 관리 및 활용의 여러 측면을 지원할 수 있습니다. 이는 일관성 있는 변경 사항 구현, 시간 절약, 취약점 관리 개선 등 다양한 이점을 제공합니다. 자동화된 SBOM 생성은 감사 및 규정 준수 절차를 간소화하고 보안 취약점에 대한 대응 시간을 단축시킵니다. 조직은 이 기능을 현재의 취약점 관리 절차와 보안 정책의 실시간 감사 compliance에 포함할 수 있습니다. 두 가지 모두 표준화된 기계 판독 가능한 데이터 형식을 필요로 하는 자동화에 크게 의존합니다. SBOM을 생성하고 사용하는 데 사용되는 표준 형식은 다음과 같습니다:

1. Software Package Data eXchange (SPDX)
2. CycloneDX

5. 소프트웨어 Consumer/Developer/Integrator 조직을 위한 SBOM 프로세스와 관행

이 섹션에서는 실무자들이 SBOM을 어떻게 인식해야 하며, 실제로 이를 다루기 위해 어떤 프로세스를 수립해야 하는지 논의합니다. 이 장에서 언급된 주제들은 SBOM 생성, 배포 및 공유, 검증 및 확인, 취약점 및 악용 가능성 관리와 같은 SBOM 관행의 분석에서 도출되었습니다.

5.1 역할과 책임 수립

SBOM을 구현하기 위해서는 필요한 역할과 책임을 식별해야 합니다. 여기에는 관리 후원자, 프로젝트 리더, 시스템 엔지니어, 설계 엔지니어, 조달 전문가 및 운영 담당자가 포함되어야 합니다. 프로젝트 일정과 보안 요구사항에 따라 IT, 사이버보안 및 유지보수 인력과 같은 추가 지원을 포함시켜야 합니다. 이러한 역할들 간의 명확한 소유권과 협력을 보장하여 SBOM 구현과 기존 프로세스와의 통합을 추진해야 합니다.

Figure 6: 역할 및 책임 수립 단계

1. 주요 이해관계자 식별: SBOM 프로그램의 주요 이해관계자를 식별하기 위해 조직은 소프트웨어 개발, IT 운영, 보안, 조달, 비즈니스 리더십, compliance 팀 및 규제 기관의 대표자를 고려해야 합니다. 보안 데이터 처리, 취약점 관리 및 위험 평가에 대한 전문 지식을 제공하기 위해 사이버보안 전문가를 포함해야 합니다.

2. SBOM 관련 책임 정의: SBOM 생성, 소비, 취약점 모니터링, supplier 참여 및 보안 데이터 관리와 같은 작업을 설명합니다. 다음과 같은 사이버보안 중심의 책임을 할당합니다: 민감도와 위험에 따른 SBOM 데이터 분류, 보안 SBOM 저장소 및 접근 제어 구현, 취약점 관리 및 사고 대응 프로세스와 SBOM 데이터 통합.

3. 역할 및 소유권 할당: 사이버보안 전문가를 SBOM 프로그램 소유자 또는 공동 소유자로 지정하여 전반적인 보안이 보장되도록 합니다. 사이버보안 팀이 핵심 역할을 수행하면서 이해관계자의 전문성을 기반으로 SBOM 책임을 할당합니다.

4. 거버넌스 수립: 거버넌스 구조는 첫 번째 포인트에서 논의된 대로 조직 전반의 주요 이해관계자를 포함해야 합니다. 이 거버넌스 기구는 SBOM 관련 정책, 표준, 프로세스를 개발하고 명확한 책임을 할당하며, SBOM 데이터를 보호하기 위한 통제를 구현합니다.

5. 협업 활성화: 소프트웨어, IT 및 사이버보안 팀 간의 부서 간 협업을 촉진하여 SBOM 보안 과제를 해결합니다. 보안 SBOM 관행, 새로운 위협 및 최고 수준의 보안 통제에 대한 지식 공유를 장려합니다.

6. 교육 및 리소스 제공: SBOM 보안 요구사항, 보안 데이터 처리 및 SSDLC의 각 단계와 SBOM 통합에 대한 전문 교육을 제공합니다. 팀에 보안 SBOM 생성, 저장 및 소비 도구와 취약점 관리 및 위협 인텔리전스 리소스를 제공합니다.

7. 모니터링 및 개선: 조직은 정기적인 감사와 평가를 수행해야 합니다. 여기에는 SBOM 프로그램의 보안 태세를 지속적으로 평가하고 진화하는 위협과 compliance 요구사항을 해결하기 위한 조정이 포함되어야 합니다.

5.2 SBOM 기능 탐색을 위한 로드맵

이 섹션에서는 SBOM의 세 가지 주요 측면인 관행, 도구 지원 및 관련 문제의 목표를 탐구합니다. 이를 통해 소프트웨어 Developer/Consumer/Integrator 조직에게 다양한 기능을 탐색하고 SBOM의 특정 측면에서 실제로 달성해야 할 사항에 대한 로드맵을 제공합니다.

Table 7: SBOM 개념의 목표

5.3 보안 SBOM 배포: 접근 제어와 Public/Private SBOM

SBOM 데이터를 안전하게 통합하고 관리하려면 명확한 조건이 정의되어야 합니다. 이러한 조건은 라이선싱, 계약, 또는 소프트웨어 사용 및 권한 관리를 위한 기존 메커니즘을 통해 수립될 수 있습니다. supplier(오픈소스 관리자 포함)는 public SBOM 데이터를 선호할 수 있지만, 일부는 기밀성을 유지하며 특정 사용자에게만 접근을 제한할 수 있습니다. 이러한 단계를 통해 조직은 SBOM의 안전하고 통제된 배포를 구현하여 민감한 정보가 승인된 당사자에게만 접근 가능하도록 하면서도 소프트웨어 공급망의 투명성과 신뢰를 유지할 수 있습니다.

5.3.1 접근 제어

• 5.3.1.1 SBOM 데이터에 대한 접근을 관리하기 위한 role-based access control (RBAC) 시스템을 정의합니다.
• 5.3.1.2 다양한 이해관계자(예: developer, security team, supply chain partner)와 각자의 접근 요구사항을 식별합니다.
• 5.3.1.3 각 역할에 적합한 권한과 특권을 할당합니다(예: 일반 사용자를 위한 읽기 전용 접근, SBOM 관리자를 위한 편집 및 업데이트 접근, 민감하거나 기밀인 SBOM 데이터에 대한 제한된 접근).

5.3.2 Public 및 Private SBOM

• 5.3.2.1 SBOM의 두 가지 버전을 유지:
  • a) Public SBOM: 모든 이해관계자와 공유 가능한 비민감 정보를 포함합니다.
  • b) Private SBOM: 승인된 당사자만 접근할 수 있는 취약점과 같은 민감하거나 기밀 정보를 포함합니다.

5.3.3 보안 배포 메커니즘

• 5.3.3.1 HTTPS와 같은 보안 통신 프로토콜을 활용하여 당사자 간 SBOM 데이터를 전송합니다.
• 5.3.3.2 디지털 서명이나 암호화를 구현하여 SBOM 데이터의 무결성과 기밀성을 보장합니다.
• 5.3.3.3 접근 제어 및 감사 기능을 제공하는 보안 파일 공유 플랫폼이나 도구를 사용합니다.

5.3.4 자동화된 SBOM 생성 및 업데이트

• 5.3.4.1 최신 상태와 정확성을 유지하기 위해 SBOM 생성 프로세스를 software development lifecycle (SDLC)에 통합합니다.
• 5.3.4.2 소프트웨어 구성 요소나 dependency에 변경이 발생할 때 SBOM 업데이트 프로세스를 자동화합니다.

5.3.5 SBOM 소비 및 검증

• 5.3.5.1 SBOM 데이터를 소비하고 검증하는 방법에 대한 명확한 지침과 문서를 제공합니다.
• 5.3.5.2 이해관계자가 특정 요구사항과 보안 정책에 따라 SBOM을 검증할 수 있는 프로세스와 도구를 개발합니다.

5.3.6 모니터링 및 감사

• 5.3.6.1 SBOM 데이터에 대한 접근과 변경을 추적하기 위한 로깅 및 감사 메커니즘을 구현합니다.
• 5.3.6.2 정의된 접근 제어 정책의 compliance를 보장하기 위해 접근 로그와 감사 추적을 정기적으로 검토합니다.

5.3.7 사고 대응 및 복구

• 5.3.7.1 SBOM 데이터와 관련된 보안 사고나 침해를 처리하기 위한 사고 대응 절차를 수립합니다.
• 5.3.7.2 취약점이나 사고의 영향을 신속히 평가하고 관련 이해관계자와 복구 노력을 조율하기 위한 프로세스를 구현합니다.

5.4 SBOM 공유

소프트웨어 공급망의 투명성, 보안 및 compliance를 높이기 위해서는 supplier와 사용자 간에 SBOM을 공유하는 것이 필요합니다.

조직 내부에서 SBOM 문서를 공유하면 development, security, operations 및 법률 팀이 프로젝트에서 사용되는 소프트웨어 구성 요소와 dependency에 대한 통찰력을 얻을 수 있습니다. 이는 투명성을 촉진하고 협업을 강화하며 라이선싱 및 보안 요구사항의 compliance를 용이하게 합니다.

SBOM 문서 공유는 외부 partner, supplier 및 vendor 간의 신뢰를 높이는 데도 기여하며, 소프트웨어 제품이나 시스템 내에서 구현된 구성 요소, 라이선싱, 보안 조치에 대한 감사 가능한 증거를 제공합니다.

SBOM 문서 공유는 다음과 같은 채널과 형식을 통해 촉진됩니다:

1. Secure File Sharing Platform: 승인된 당사자와 안전하게 문서를 공유할 수 있는 환경 제공.
2. API Integration: 시스템 간 자동화되고 안전한 데이터 교환 지원.
3. Collaboration Tool: 프로젝트 관리 플랫폼이나 문서 공유 애플리케이션을 활용하여 팀 내부 또는 조직 간 안전한 공유 촉진.
4. Industry Platform and Repository: 특정 산업이나 커뮤니티 내에서 문서의 공유와 배포를 촉진하기 위해 구축된 플랫폼 활용.

문서를 공유할 때는 클라이언트가 진위성을 확인하고 변조 여부를 검증할 수 있도록 디지털 서명을 첨부하는 것이 권장됩니다. 또한, 어떤 정보를 public 또는 private으로 설정해야 하는지 명확히 식별하는 것이 중요합니다.

6. SBOM의 취약점 추적 및 분석

이 챕터에서는 Software Bill of Materials (SBOM)를 사용한 취약점 추적 및 분석에 대해 Vulnerability Exchange Document (VEX)와 Common Security Advisory Framework (CSAF)를 통해 설명합니다. VEX는 취약점 정보의 표준화된 공유를 용이하게 하고, CSAF는 보안 권고사항을 설명하기 위한 구조화된 프레임워크를 제공합니다.

a) VEX Document 설계: Vulnerability Exchange Document (VEX)는 취약점이 발견된 후 소프트웨어 공급망 관리를 담당하는 조직이나 주체(예: supplier)가 설계해야 합니다. VEX는 consumer가 수정 작업의 우선순위를 정할 수 있도록 취약점의 악용 가능성 상태를 알리는 역할을 합니다. 여기에는 소프트웨어 developer, vendor 또는 조달 및 compliance 관련 조직으로 구성된 팀이 포함되어야 하며, 이들은 소프트웨어의 취약점 추적과 분석을 담당합니다. VEX document는 supplier가 수행한 시간과 함께 수정, 해결 방법, 재시작/다운타임 요구사항, 점수 및 위험을 포함하여 취약점의 각 업데이트마다 반복적으로 업데이트됩니다. VEX document는 특정 소프트웨어 제품의 취약점 상태에 대해 다음 사항을 포함해야 합니다:

• Not affected - 이 취약점에 대한 수정이 필요하지 않음
• Affected - 이 취약점을 수정하거나 해결하기 위한 조치가 권장됨
• Fixed - 이러한 제품 버전에 취약점에 대한 수정사항이 포함되어 있음을 나타냄
• Under Investigation - 이러한 제품 버전이 취약점의 영향을 받는지 여부가 아직 확인되지 않음. 추후 릴리스에서 업데이트가 제공될 예정

b) Common Security Advisory Framework (CSAF) 채택: VEX document 이후에 supplier는 취약점에 대한 설명, 영향을 받는 제품 버전, 심각도 평가 및 권장되는 완화 단계와 같은 자세한 정보가 포함된 CSAF 권고사항을 제공해야 합니다. 이는 다음 예시를 통해 이해할 수 있습니다:

Figure 7: SBOM의 취약점 추적 및 분석 단계 시퀀스 예시

Log4j 취약점은 위 그림에 설명된 개념을 매핑하고 설명하는 예시로 사용됩니다:

1. Vulnerability Discovery: 2021년 12월, 널리 사용되는 Log4j logging library에서 심각한 취약점이 발견되었습니다.
2. VEX Publication (1주): 일주일 내에 Apache Software Foundation(Log4j의 관리자)은 취약점이 “Exploitable"이라고 명시한 VEX document를 발행했습니다.
3. CSAF Publication (3주): 최초 발견 약 3주 후, Apache Software Foundation은 Log4j 취약점에 대한 상세 정보가 포함된 CSAF 권고사항을 발표했습니다. CSAF 권고사항에는 취약점 설명, 영향을 받는 버전, CVSS 점수 10.0(심각도 위험), 완화 단계가 포함되었습니다.
4. Patch/Mitigation Instructions: CSAF 권고사항은 사용자가 Log4j의 패치된 버전으로 업데이트하거나 취약점을 해결하기 위한 다른 완화 조치를 구현하는 방법에 대한 지침을 제공했습니다.
5. Ongoing Updates: Apache Software Foundation은 상황을 계속 모니터링하고 새로운 정보나 추가 완화 전략이 가용해짐에 따라 업데이트를 제공했습니다.
6. SBOM Integration: Log4j library가 소프트웨어 구성 요소에 포함된 조직은 VEX와 CSAF 데이터를 자신의 SBOM에 통합하여 시스템의 영향을 받는 부분을 식별할 수 있었습니다. 이를 통해 수정 작업의 우선순위를 정하고 시스템이 Log4Shell 취약점으로부터 보호되도록 할 수 있었습니다.

c) 다양한 취약점 데이터베이스 및 권고사항과의 통합: supplier와 consumer는 SBOM 데이터를 취약점 데이터베이스, CERT-In 취약점 노트, 경고, 위협 인텔리전스 플랫폼 및 vendor별 권고사항과 통합하여 소프트웨어의 보안 상태에 대한 포괄적인 가시성을 확보할 수 있습니다. supplier는 SBOM 데이터를 직접 통합하여 구성 요소를 알려진 취약점에 매핑한 다음 향상된 SBOM을 customer에게 제공합니다. consumer는 API, 데이터 피드 또는 수동 프로세스를 활용하여 SBOM을 취약점 데이터와 통합함으로써 수정 작업을 식별하고 우선순위를 정할 수 있습니다.

d) Shift-left 접근 방식 및 취약점 스캐닝 구현: supplier는 보안 도구를 소프트웨어 개발 pipeline에 통합하여 shift-left 취약점 스캐닝을 구현해야 합니다. 이는 빌드 및 패키징 단계와 같은 SDLC의 초기 단계에서 소프트웨어 구성 요소의 취약점을 식별하기 위해 SBOM 데이터를 자동으로 분석하는 것을 포함합니다.

7. 권장사항 및 모범 사례

이 챕터에서는 소프트웨어 공급망 보안을 강화하기 위해 SBOM을 효과적으로 관리하기 위한 실용적인 권장사항과 모범 사례를 다룹니다.

7.1 권장사항

• 7.1.1 모든 정부, 공공 부문, 필수 서비스 조직 및 소프트웨어 수출과 서비스 산업 관련 조직은 모든 소프트웨어와 솔루션 구매/조달에 SBOM 요구사항을 포함해야 합니다.

• 7.1.2 정부, 공공 부문 및 필수 서비스 조직/부서에 공급되는 모든 소프트웨어는 complete SBOM이 동반되어야 합니다.

• 7.1.3 모든 정부, 공공 부문 및 필수 서비스 조직/부서는 사용, 조달 및 개발 중인 소프트웨어의 SBOM을 유지해야 합니다.

• 7.1.4 정부 및 공공 부문 조직/부서에 공급되는 소프트웨어의 SBOM은 이 문서의 4.2장에서 언급된 데이터 필드를 포함해야 합니다.

• 7.1.5 정부 및 공공 부문 조직/부서에 공급되는 소프트웨어의 SBOM을 생성하는 형식은 Software Package Data eXchange (SPDX) 또는 CycloneDX여야 합니다.

• 7.1.6 정부 및 공공 부문 조직/부서에 소프트웨어를 공급하는 소프트웨어 developer/integrator 조직은 취약점이 발견된 후 Vulnerability Exchange Document (VEX)를 설계하여 consumer가 수정 작업의 우선순위를 정할 수 있도록 악용 가능성 상태를 알려야 합니다. VEX document는 특정 소프트웨어 제품의 취약점 상태에 대해 다음을 포함해야 합니다:

  • Not affected - 이 취약점에 대한 수정이 필요하지 않음
  • Affected - 이 취약점을 수정하거나 해결하기 위한 조치가 권장됨
  • Fixed - 이러한 제품 버전에 취약점에 대한 수정사항이 포함되어 있음
  • Under Investigation - 이러한 제품 버전이 취약점의 영향을 받는지 여부가 아직 확인되지 않음. 추후 릴리스에서 업데이트가 제공될 예정

  VEX document 이후에 supplier는 취약점에 대한 설명, 영향을 받는 제품 버전, 심각도 평가 및 권장되는 완화 단계와 같은 상세 정보가 포함된 CSAF 권고사항을 제공해야 합니다.

• 7.1.7 Software Developer/Consumer/Integrator 조직은 SBOM 데이터를 취약점 데이터베이스, CERT-In 취약점 노트, 경고, threat intelligence platform 및 vendor별 권고사항과 통합하여 소프트웨어의 보안 상태에 대한 포괄적인 가시성을 확보해야 합니다.

• 7.1.8 Consumer 조직은 적용된 패치나 완화조치를 반영하기 위해 자체 SBOM을 업데이트해야 합니다.

• 7.1.9 각 소프트웨어 버전에 대해 별도의 SBOM을 유지하고, 추가 구성 요소 정보가 제공되거나 SBOM 오류가 수정될 때만 업데이트합니다.

• 7.1.10 Consumer 조직(특히 정부 및 공공 부문 조직)은 supplier가 제공한 SBOM을 기반으로 내부 SBOM을 매핑하고 개발해야 합니다.

• 7.1.11 소프트웨어 consumer 조직의 보안 팀은 취약점 관리 워크플로우에 SBOM 목록을 포함해야 합니다.

• 7.1.12 SBOM 프로세스의 정확성과 완전성을 보장하기 위해 정기적인 감사와 평가를 수행해야 합니다.

• 7.1.13 Consumer 조직은 VEX의 취약점 상태 정보와 SBOM의 구성 요소 데이터를 결합하여 소프트웨어 취약점을 식별하고 해결하기 위한 표적화된 접근 방식을 뒷받침하는 취약점 상태의 최신 뷰를 제공해야 합니다.

• 7.1.14 SBOM 데이터는 암호화, 접근 제어 및 기타 보안 조치를 사용하여 민감한 정보를 보호하면서 안전하게 저장되고 전송되도록 보장해야 합니다.

• 7.1.15 새로운 소프트웨어 구성 요소가 도입되거나 기존 구성 요소가 업데이트될 때 SBOM을 정기적으로 업데이트하기 위한 워크플로우를 수립해야 합니다.

7.2 모범 사례

• 7.2.1 구성 요소 이름, 버전, 라이선스 및 고유 식별자와 같은 상세한 메타데이터를 SBOM에 포함하도록 보장합니다.

• 7.2.2 SBOM의 정확성과 적시성을 유지하기 위해 secure software development lifecycle (SSDLC) 및 CI/CD pipeline에 SBOM 생성을 통합합니다.

• 7.2.3 심각도, 악용 가능성 및 잠재적 비즈니스 영향과 같은 요소를 기반으로 취약점 수정의 우선순위를 정하기 위한 위험 기반 접근 방식을 구현합니다.

• 7.2.4 SBOM 데이터의 처리, 공유 및 배포를 위한 명확한 정책과 절차를 수립합니다.

• 7.2.5 소프트웨어 공급망 보안과 관련된 compliance를 입증하고 규제 보고 의무를 충족할 수 있도록 SBOM 데이터를 생성해야 합니다.

• 7.2.6 중요한 보안 이벤트에 대해 관련 이해관계자에게 즉시 알림을 제공하여 적시에 수정할 수 있도록 경보 시스템을 구현합니다.

• 7.2.7 SBOM 분석을 통해 식별된 취약점의 수정 관리와 보안 사고 대응을 위한 상세한 플레이북을 개발합니다.

• 7.2.8 암묵적 신뢰 가정을 제거하여 보안을 강화하기 위해, 네트워크에 연결하려는 모든 사용자와 장치를 검증하는 zero-trust 보안 모델을 채택합니다.

• 7.2.9 시스템과 데이터에 대한 무단 접근의 위험을 줄이기 위해 추가 보안 계층으로 Multi Factor Authentication (MFA) 메커니즘을 구현합니다.

• 7.2.10 보안 취약점을 신속하게 식별하고 해결하기 위해 정기적인 취약점 평가와 측정을 수행합니다.

• 7.2.11 취약점을 감지하고 신속하게 해결하기 위해 소프트웨어 구성 요소와 dependency에 대한 지속적인 모니터링을 구현합니다.

• 7.2.12 제공된 SBOM의 정확성, 완전성 및 적시성에 대해 third-party 소프트웨어 vendor와 supplier로부터 보증을 받고, SBOM 요구사항 compliance를 보장하기 위한 계약 협약을 수립합니다.

• 7.2.13 애플리케이션이나 소프트웨어 내의 모든 소프트웨어 구성 요소의 라이선스가 서로 호환되는지 확인하기 위한 철저한 분석을 수행합니다. 서로 다른 라이선스가 적용된 구성 요소를 결합할 때 발생할 수 있는 충돌이나 제한사항을 식별합니다.

• 7.2.14 SBOM에 대한 변경, 추가 또는 업데이트와 함께 VEX document와 CSAF 기반 권고사항의 제공 및 정기적인 업데이트를 보장합니다.

• 7.2.15 developer부터 security team까지 모든 직원에게 SBOM의 중요성과 소프트웨어 공급망 보안 강화에서의 역할에 대한 포괄적인 교육 및 인식 프로그램을 제공합니다.

• 7.2.16 주요 구성 요소가 서로 다른 메타 정보를 가진 여러 인스턴스에 의존하는 경우, 각 인스턴스는 개별 메타 정보와 함께 별도로 나열되어야 합니다.

2 - 2025-11-26 대규모 공급망에서 SBOM을 어떻게 운영 단계에 적용할 것인가?

source: https://openchainproject.org/news/2025/11/27/recording-openchain-sbom-work-group-monthly-meeting-2025-11-26

일시: 2025년 11월 26일 (수)

주제: 복잡한 대규모 공급망에서 SBOM을 어떻게 ‘운영(Production)’ 단계에 적용할 것인가?

발표자: Thomas Graf (Siemens)

들어가며: “만드는 것"을 넘어 “쓰는 것"으로

지난 11월 26일 열린 OpenChain SBOM Work Group 정기 미팅은 SBOM(Software Bill of Materials) 논의가 이제 새로운 국면에 접어들었음을 보여주는 중요한 자리였습니다. 그동안 업계의 논의가 “SBOM을 어떻게 생성할 것인가(How to generate)?“에 머물러 있었다면, 이번 미팅의 핵심 질문은 “생성된 SBOM을 실제 운영 환경(Production)과 복잡한 공급망에서 어떻게 활용할 것인가?“였습니다.

특히, 제조 및 산업 자동화 분야의 거인인 지멘스(Siemens)의 Thomas Graf가 연사로 나서, 이론이 아닌 현장의 SBOM 구현 사례를 공유해 큰 의미가 있었습니다. 이 글에서는 미팅의 핵심 내용을 상세히 정리하여, SBOM 도입을 고민하는 실무자들에게 실질적인 인사이트를 제공하고자 합니다.

1. Keynote: 지멘스(Siemens)의 실전 SBOM 구현 전략

이번 미팅의 하이라이트는 단연 Thomas Graf의 발표였습니다. 지멘스는 수만 개의 소프트웨어 컴포넌트와 하드웨어 제품을 다루는 복잡한 공급망을 가진 기업입니다. 그들이 어떻게 SBOM을 표준화하고 관리하는지에 대한 내용은 대규모 조직에게 훌륭한 레퍼런스가 됩니다.

1.1. ‘지멘스 표준 BOM(Siemens Standard BOM)‘의 정의

지멘스는 거대한 조직 특성상 수많은 부서가 각기 다른 도구와 언어를 사용합니다. 이를 통합하기 위해 그들은 ‘지멘스 표준 BOM’이라는 개념을 도입했습니다.

• CycloneDX의 부분집합(Subset) 활용: 지멘스는 OWASP CycloneDX 표준을 기반으로 하되, 모든 스펙을 다 쓰는 것이 아니라 자신들의 비즈니스 로직에 필요한 필수 필드를 정의하여 사용합니다. 이는 데이터의 일관성을 유지하고, 불필요한 복잡성을 줄이기 위함입니다.
• 기술 중립성(Technology Agnostic): Java, Python, .NET 등 특정 언어나 생태계에 종속되지 않는 독립적인 JSON 포맷을 유지합니다. 이를 통해 어떤 개발 환경에서든 동일한 방식의 SBOM 처리가 가능합니다.

1.2. SBOM은 ‘퍼즐(Puzzle)’ 맞추기다

Thomas Graf는 SBOM을 하나의 거대한 퍼즐에 비유했습니다. 하나의 완벽한 SBOM이 뚝딱 만들어지는 것이 아니라, 여러 출처의 데이터를 조립해야 비로소 전체 그림이 보인다는 것입니다.

• 다양한 소스 통합: 오픈소스 라이브러리, 컨테이너 이미지, 3rd Party 벤더가 제공하는 상용 소프트웨어, 그리고 파트너사의 컴포넌트 등 출처가 다른 데이터를 하나의 포맷으로 통합해야 합니다.
• 상호운용성(Interoperability) 확보: 결국 핵심은 ‘상호운용성’입니다. 내부적으로 생성한 데이터와 외부에서 수신한 데이터가 서로 대화할 수 있어야 하며, 이를 위해 지멘스는 자체 툴링을 개발하여 이 간극을 메우고 있습니다.

1.3. 자동화와 툴링의 중요성

“모든 팀은 다르다(Nearly every team is different).“라는 현실적인 문제 앞에서 지멘스는 ‘중앙집중식 강제’보다는 ‘도구 제공’에 초점을 맞춥니다.

• 개발자들이 쉽게 SBOM을 생성하고 라이선스를 검증할 수 있도록 내부(Inner Source) 또는 오픈소스 도구를 제공합니다.
• Thomas Graf는 이러한 도구들이 단순히 지멘스 내부용에 그치지 않고, 오픈소스 생태계에 기여(Upstream contribution)하거나 공개될 가능성도 열어두었습니다. 이는 생태계 전체의 성장을 도모하겠다는 의지입니다.

2. Open Q&A: 커뮤니티의 고민들

발표 이후 이어진 Q&A 세션에서는 전 세계 실무자들의 날카로운 질문들이 이어졌습니다. (미팅 영상 참조: YouTube 링크)

주요 논의 주제는 다음과 같았습니다:

• 레거시 시스템 대응: SBOM 생성이 고려되지 않았던 오래된 시스템(Legacy)에서 어떻게 데이터를 추출할 것인가?
• 데이터 품질(Quality): 벤더로부터 받은 SBOM의 품질이 낮을 때(예: 필수 필드 누락) 이를 어떻게 검증하고 보완할 것인가?
• VEX(Vulnerability Exploitability eXchange) 연동: 단순히 취약점이 있다는 사실을 넘어, 실제로 ‘영향을 받는지’ 여부를 판단하기 위해 VEX 정보를 SBOM과 어떻게 매핑할 것인가?

이러한 논의들은 SBOM이 단순한 ‘문서’가 아니라, 보안 및 컴플라이언스 대응을 위한 ‘살아있는 데이터’로 다뤄져야 함을 재확인시켜 주었습니다.

3. Study Group Updates & 참여 방법

미팅의 마지막 순서로 의장(Chair)의 업데이트가 있었습니다. OpenChain SBOM Work Group은 현재 “대규모 공급망에서의 SBOM 운영"이라는 난제를 해결하기 위해 스터디 그룹을 운영하고 있습니다.openchainproject

이 스터디 그룹은 단순히 이론을 공부하는 것이 아니라, 실제 기업들이 겪는 문제를 공유하고 해결책을 모색하는 실무 중심의 모임입니다. 누구나 참여할 수 있으며, 여러분의 경험이 생태계의 표준이 될 수 있습니다.

[참여 및 정보 확인 방법]

관심 있는 분들은 아래 채널을 통해 지난 자료를 확인하거나 향후 미팅에 참여할 수 있습니다.

• 미팅 다시보기: YouTube 영상 바로가기
• 공식 미팅 로그: OpenChain Project News
• 메일링 리스트 가입: https://lists..org/g/sbom
• GitHub 저장소: https://github.com/OpenChain-Project/SBOM-sg
• 향후 일정 확인: OpenChain Participate Page

맺음말

2025년 11월 미팅은 SBOM이 규제 준수를 위한 ‘숙제’에서, 소프트웨어 공급망 투명성을 확보하는 ‘핵심 인프라’로 진화하고 있음을 보여주었습니다. 지멘스의 사례처럼, 이제는 “어떻게 표준화된 포맷으로, 자동화된 파이프라인 안에서 SBOM을 굴릴 것인가"를 고민해야 할 때입니다.

by Gemini 3.0

3 - 2025-10-27 SBOM 품질 가이드와 규제 대응의 구체화

source: https://openchainproject.org/news/2025/10/27/recording-openchain-sbom-work-group-monthly-meeting-2025-10-22

작성일: 2025년 10월 27일

주제: OpenChain SBOM Work Group Monthly Meeting (2025-10-22) 상세 리뷰

안녕하세요. 오늘은 지난 10월 22일에 진행된 OpenChain SBOM 워크 그룹(OpenChain SBOM Work Group) 정기 미팅의 핵심 내용을 정리해 드립니다.

이번 미팅은 지난 9월 ‘스터디 그룹(Study Group)‘에서 ‘워크 그룹(Working Group)‘으로 승격된 이후 본격적으로 진행된 논의여서 큰 의미가 있었습니다. 특히, 현재 업계의 가장 큰 화두인 “단순히 SBOM을 만드는 것을 넘어, 어떻게 고품질의 SBOM을 만들고 규제에 대응할 것인가?“에 대한 구체적인 가이드라인 작업 현황이 공개되었습니다.

미팅에 직접 참석하지 못하셨더라도 이 글을 통해 현재 논의되고 있는 핵심 아젠다와 향후 방향성을 충분히 이해하실 수 있도록 상세히 정리했습니다.

1. 주요 안건 개요 (Executive Summary)

이번 10월 미팅의 핵심은 단연 ‘SBOM 품질 가이드(Guide to SBOM Quality)‘의 구체화였습니다. 단순히 이론적인 논의에 그치지 않고, 실제 법적 규제와 SBOM 데이터 요소를 매핑(Mapping)하는 실무적인 작업이 진행되고 있음을 확인할 수 있었습니다.

• 그룹 위상 변경: SBOM 스터디 그룹이 공식 ‘워크 그룹(Working Group)‘으로 명칭 및 위상이 변경됨에 따라 활동 범위가 확대되었습니다.
• 품질 가이드 업데이트: ‘Guide to SBOM Quality’ 문서의 챕터 6(규제 매핑 테이블)과 부록 1(환경 다이어그램)이 집중적으로 업데이트되었습니다.
• 앰배서더 프로그램: 워크 그룹 활동을 알릴 2명의 공식 앰배서더가 선정되었습니다.

2. 핵심 업데이트: SBOM 품질 가이드 (Guide to SBOM Quality)

미팅의 대부분은 현재 작성 중인 ‘OpenChain SBOM Document Quality Guide’의 진척 상황을 공유하고 토론하는 데 할애되었습니다. 현재 이 문서는 구글 닥스(Google Docs)를 통해 공동 편집되고 있으며, 추후 마크다운(Markdown) 포맷으로 변환되어 GitHub에 공식 배포될 예정입니다.

2.1. 챕터 6: 규제와 SBOM 요소의 매핑 (Mapping Regulations)

이번 미팅에서 가장 주목해야 할 부분은 Chapter 6의 업데이트입니다. 워크 그룹은 전 세계적으로 강화되고 있는 사이버 보안 규제와 가이드라인을 실제 SBOM 데이터 필드와 연결하는 작업을 진행했습니다.

• 배경: 기업들은 “미국 행정명령(EO 14028)이나 EU 사이버복원력법(CRA)을 준수하려면 SBOM에 정확히 어떤 필드가 있어야 하는가?“라는 질문을 끊임없이 던집니다.
• 업데이트 내용: 챕터 6에 ‘규제/가이드라인과 SBOM 요소 간의 매핑 테이블’이 추가되었습니다. 이는 특정 규제(예: NTIA 최소 요소, CRA 등)가 요구하는 사항을 만족시키기 위해 SBOM 내에 어떤 태그(Tag)나 데이터가 필수적으로 포함되어야 하는지를 일목요연하게 보여줍니다.
• 현재 상태: 이 작업은 아직 진행 중(Work in Progress)이며, 미팅에서는 3가지 주요 가이드라인을 우선적으로 선정하여 매핑 작업을 진행하고 있다고 밝혔습니다.

2.2. 부록 1: 환경 다이어그램 (Environment Diagram)

단순한 텍스트 나열을 넘어, 시각적인 이해를 돕기 위한 부록(Appendix 1) 업데이트도 있었습니다.

• 내용: 각 가이드라인을 준수하기 위해 “누가(Which entity)” SBOM 문서를 생성해야 하는지를 보여주는 환경 다이어그램(Environment Diagram)이 추가되었습니다.
• 의의: 공급망은 복잡합니다. 오픈소스 프로젝트 관리자, 패키지 배포자, 최종 제품 벤더 등 다양한 주체가 섞여 있습니다. 이 다이어그램은 각 주체가 공급망의 어느 단계에서 어떤 책임을 지고 SBOM을 생성해야 하는지를 명확히 하여, 책임 소재의 모호함을 줄이는 데 기여할 것입니다.

3. 워크 그룹 운영 및 기타 소식

3.1. 스터디 그룹에서 ‘워크 그룹’으로

지난 9월, OpenChain 이사회(Board)는 기존의 SBOM 스터디 그룹을 ‘워크 그룹(Working Group)‘으로 승격시켰습니다. 이는 해당 모임이 단순한 학습이나 정보 공유를 넘어, 실질적인 표준과 가이드라인을 생산하는 조직으로 인정받았음을 의미합니다. 이에 따라 10월 미팅부터는 공식적으로 변경된 그룹 명칭이 사용되었습니다.

3.2. 앰배서더(Ambassador) 프로그램

워크 그룹의 활동을 외부에 더 널리 알리고 참여를 독려하기 위해, OpenChain 프로젝트는 앰배서더 프로그램을 도입했습니다. 이번 미팅에서는 SBOM 워크 그룹을 위해 두 명의 앰배서더가 활동하게 되었음을 공지했습니다. 이들은 향후 메일링 리스트와 소셜 미디어를 통해 워크 그룹의 성과를 전파하는 역할을 맡게 됩니다.

3.3. 11월 자동차(Automotive) 관련 미팅 예고

다가오는 11월 중순에는 자동차 산업에 특화된 별도의 미팅이 예정되어 있습니다.

• 형식: 단순한 발표(Presentation) 형식이 아닌, 참여자 간의 활발한 토론(Discussion) 중심으로 진행될 예정입니다.
• 목표: 자동차 산업의 복잡한 공급망 특성을 반영하여 실질적인 문제를 해결하는 자리가 될 것으로 기대됩니다.

4. 참여 방법 및 리소스

OpenChain SBOM 워크 그룹은 모든 과정이 투명하게 공개되며, 누구나 참여할 수 있습니다. “대규모 공급망에서 SBOM을 어떻게 실제로 운영(Production)할 것인가?“라는 난제를 함께 풀어나가고 싶다면 아래 채널을 참고해 주세요.

• 메일링 리스트: https://lists.openchainproject.org/g/sbom (주요 공지 및 논의가 이루어지는 곳)
• GitHub 리포지토리: https://github.com/OpenChain-Project/SBOM-sg (회의록, 가이드 문서 초안 등 자료 아카이브)
• 미팅 참여: OpenChain 프로젝트의 참여 페이지(Participate Page)에서 향후 미팅 일정과 접속 정보를 확인할 수 있습니다.

5. 마치며: ‘양’에서 ‘질’로의 전환

이번 10월 미팅은 SBOM 논의가 ‘생성(Generation)‘의 단계를 지나 ‘품질(Quality)과 규제 준수(Compliance)‘의 단계로 깊어지고 있음을 보여주었습니다.

단순히 SBOM 파일을 만들어내는 것만으로는 충분하지 않습니다. 그 SBOM이 “규제가 요구하는 필수 요소를 포함하고 있는가?”, “누가 그 데이터의 정확성을 책임지는가?“에 대한 답을 내릴 수 있어야 합니다. 현재 워크 그룹이 작성 중인 ‘품질 가이드’는 바로 이 질문에 대한 해답이 될 것입니다.

by Gemini 3.0

4 - 2024-11-27 취약점과 미래 - 다층적 소프트웨어 취약점과 대응 전략

source: https://openchainproject.org/news/2024/12/04/sbom-study-group-2024-11-27

목차

1. 소개
2. 발표자 소개
3. 웨비나 개요
4. Software Bill of Materials (SBOM)의 중요성
5. 공급망 위험과 취약점
6. 오픈소스 소프트웨어의 보안 성숙도
7. 취약점 해결 전략
8. Software Heritage 프로젝트 소개
9. CycloneDX의 도전과제
10. 질의응답
11. 결론

1. 소개

이 블로그 포스트는 OpenChain Project의 SBOM Study Group 웨비나에서 발표된 “취약점과 미래 - 다층적 소프트웨어 취약점과 대응 전략"에 대한 내용을 다룹니다. 이 웨비나는 소프트웨어 공급망 보안과 취약점 관리의 중요성을 강조하며, 현재의 도전과제와 미래의 전략을 탐구합니다.

2. 발표자 소개

발표자인 Okada San은 OWASP Japan의 전문가로, 일본 기업에서 애플리케이션 보안 강화와 소프트웨어 생산성 팀을 지원하는 보안 연구원입니다. OWASP 재단의 평생 회원으로, 20년 이상 다양한 문서 번역 작업에 참여해 왔습니다.

3. 웨비나 개요

이 웨비나는 소프트웨어 취약점의 다층적 특성과 이에 대한 효과적인 대응 전략을 다룹니다. 특히 Software Bill of Materials (SBOM)의 중요성과 CycloneDX와 같은 표준의 역할에 초점을 맞춥니다. 또한 오픈소스 소프트웨어의 보안 성숙도와 공급망 위험에 대해 심도 있게 논의합니다.

4. Software Bill of Materials (SBOM)의 중요성

SBOM은 소프트웨어 구성 요소의 투명성을 제공하는 중요한 도구입니다. Okada San은 SBOM이 단순히 형식이 아닌 소프트웨어 구성과 투명성에 대한 정보를 교환하는 방법이라고 강조합니다. CycloneDX와 SPDX와 같은 표준은 이러한 정보 교환을 위한 프레임워크를 제공합니다.

5. 공급망 위험과 취약점

Okada San은 소프트웨어 공급망의 세 가지 주요 위험 지점을 설명합니다:

1. 공격 대상으로서의 오픈소스 소프트웨어
2. 오픈소스 의존성의 낮은 보안 성숙도
3. 업데이트를 맹목적으로 신뢰하는 사용자

이러한 위험은 typosquatting과 같은 공격 기법을 통해 악용될 수 있으며, 이는 오픈소스 저장소의 보안 중요성을 강조합니다.

6. 오픈소스 소프트웨어의 보안 성숙도

Open Source Security Foundation (OpenSSF)의 보고서에 따르면, 전문가의 약 3분의 1이 안전한 소프트웨어 개발 관행에 익숙하지 않다고 합니다. 이는 오픈소스 프로젝트의 보안 성숙도 향상이 시급함을 시사합니다.

7. 취약점 해결 전략

Okada San은 취약점 해결을 위한 여러 전략을 제시합니다:

1. 소프트웨어 구성 분석 (SCA) 수행
2. 프로젝트의 신뢰성 평가
3. 코드 품질과 업데이트 빈도 확인
4. OWASP Dependency-Track과 같은 도구 활용

8. Software Heritage 프로젝트 소개

Software Heritage 프로젝트는 다양한 저장소의 아카이브를 제공합니다. 이 프로젝트를 통해 개발자의 기여 이력과 패치의 품질을 추적할 수 있어, 프로젝트나 개발자의 신뢰성을 평가하는 데 유용합니다.

9. CycloneDX의 도전과제

Okada San은 CycloneDX의 주요 도전과제를 다음과 같이 설명합니다:

1. 공개 사례 연구의 부족
2. 호스팅된 250개 이상의 도구에 대한 재분류 필요
3. 하드웨어 제조업체의 제한적인 입력
4. 확장되는 생태계를 지원할 추가 유지 관리자 모집

10. 질의응답

Q: 일본 외 다른 지역의 OWASP 지부가 있나요? A: 네, 전 세계에 많은 OWASP 지부가 있습니다. 월간 또는 분기별 모임을 통해 애플리케이션 보안 전문가들과 쉽게 교류할 수 있습니다.

Q: Software Heritage를 어떻게 활용하고 있나요? A: 저는 주로 Protestware와 관련된 개발자를 추적하고, 그들이 다른 프로젝트에 기여하는지 확인하는 데 사용했습니다. 이를 통해 다른 위험 요소들도 발견할 수 있었습니다.

11. 결론

Okada San은 소프트웨어 투명성과 보안의 중요성을 강조하며 발표를 마무리합니다. 그는 모든 참가자들에게 CycloneDX 커뮤니티에 참여하고, 소프트웨어 투명성에 대한 논의에 기여할 것을 권장합니다.

요약 보고서

기업의 오픈소스 관리 담당자에게 주는 의미

1. 투명성의 중요성: SBOM을 통한 소프트웨어 구성 요소의 투명성 확보가 필수적입니다.
2. 보안 성숙도 향상: 오픈소스 프로젝트의 보안 성숙도를 평가하고 개선하는 노력이 필요합니다.
3. 공급망 위험 관리: 오픈소스 의존성에 대한 지속적인 모니터링과 관리가 중요합니다.
4. 커뮤니티 참여: CycloneDX와 같은 표준화 커뮤니티에 적극적으로 참여해야 합니다.
5. 도구 활용: Software Heritage, OWASP Dependency-Track 등의 도구를 활용한 프로젝트 평가가 필요합니다.

고려해야 할 Action Item

1. SBOM 생성 및 관리 프로세스 구축
2. 오픈소스 의존성에 대한 정기적인 보안 감사 실시
3. 개발자 대상 보안 교육 프로그램 강화
4. CycloneDX나 SPDX와 같은 표준 채택 및 구현
5. Software Heritage를 활용한 프로젝트 및 개발자 신뢰성 평가 체계 수립
6. OWASP Dependency-Track 등의 도구를 CI/CD 파이프라인에 통합
7. 오픈소스 커뮤니티 활동 참여 및 기여 장려
8. 내부 취약점 관리 정책 및 프로세스 개선
9. 공급업체 관리 정책에 SBOM 요구사항 포함
10. 정기적인 위험 평가 및 대응 전략 수립

이러한 액션 아이템을 실행함으로써, 기업은 소프트웨어 공급망 보안을 강화하고 잠재적인 취약점에 대한 대응 능력을 향상시킬 수 있습니다.

5 - 2024-10-29 SBOM 관련 다양한 규제와 가이드라인에 대한 개요

source: https://openchainproject.org/news/2024/10/29/openchain-sbom-study-group-october-2024-10-23-full-recording

목차

1. 세미나 개요
2. 발표 내용
3. 질의응답
4. 결론 및 향후 계획

1. 세미나 개요

제목

OpenChain SBOM 스터디 그룹 - 2024년 10월 세미나

발표자 소개

이번 세미나의 발표자는 도시바의 Ninjouji-san입니다. 도시바는 일본의 대표적인 다국적 전자 기업으로, 오픈소스 및 SBOM 관련 분야에서 풍부한 경험을 보유하고 있습니다.

웨비나 소개와 목적

이번 OpenChain SBOM 스터디 그룹 세미나는 다양한 규제와 가이드라인에 대한 개요를 제공하고, 향후 미팅에서 필요한 사항들에 대해 논의하는 것을 목적으로 합니다. SBOM(Software Bill of Materials)은 소프트웨어 구성 요소를 투명하게 관리하고 보안 취약점을 효과적으로 대응하기 위한 중요한 도구로 주목받고 있습니다.

2. 발표 내용

SBOM 관련 규제 및 가이드라인 개요

Ninjouji-san은 SBOM과 관련된 주요 규제 및 가이드라인에 대해 상세히 설명했습니다. 이는 다음과 같은 내용을 포함합니다:

1. 미국 사이버보안 및 기반시설 보안국(CISA)의 SBOM 요구사항
2. 유럽연합(EU)의 사이버 복원력 법안
3. 일본 경제산업성(METI)의 소프트웨어 관리 지침

각 규제와 가이드라인의 주요 특징, 적용 범위, 기업에 미치는 영향 등을 자세히 다루었습니다.

SBOM 도구 및 표준 포맷

발표자는 SBOM 생성 및 관리를 위한 다양한 도구들을 소개했습니다:

1. SPDX: 리눅스 재단에서 개발한 오픈소스 라이선스 및 보안 정보 교환 표준
2. CycloneDX: OWASP에서 개발한 경량화된 SBOM 표준
3. SWID: 소프트웨어 식별 태그 표준

각 도구의 특징, 장단점, 적용 사례 등을 비교 분석하여 참가자들의 이해를 도왔습니다.

SBOM 구현 전략

Ninjouji-san은 기업이 SBOM을 효과적으로 구현하기 위한 전략을 제시했습니다:

1. 소프트웨어 공급망 매핑
2. SBOM 생성 자동화 도구 선택
3. 지속적인 모니터링 및 업데이트 프로세스 수립
4. 보안 취약점 관리와 SBOM 연계

이러한 전략을 통해 기업은 규제 준수뿐만 아니라 소프트웨어 품질 및 보안 향상을 도모할 수 있습니다.

3. 질의응답

세미나 참가자들로부터 다양한 질문이 제기되었습니다:

Q: SBOM 구현 시 가장 큰 도전 과제는 무엇인가요? A: Ninjouji-san은 레거시 시스템에 대한 SBOM 생성과 서드파티 소프트웨어 컴포넌트의 정확한 추적이 주요 과제라고 답변했습니다.

Q: 중소기업도 SBOM을 도입해야 하나요? A: 발표자는 기업 규모와 관계없이 SBOM 도입이 중요하며, 오픈소스 도구를 활용하여 비용 효율적으로 시작할 수 있다고 조언했습니다.

Q: SBOM과 DevSecOps의 연계 방안은? A: SBOM을 CI/CD 파이프라인에 통합하여 지속적인 보안 검증을 수행할 수 있다고 설명했습니다.

4. 결론 및 향후 계획

Ninjouji-san은 SBOM이 소프트웨어 공급망 보안의 핵심 요소로 자리잡고 있음을 강조하며 세미나를 마무리했습니다. 향후 스터디 그룹 미팅에서는 다음과 같은 주제를 다룰 예정입니다:

1. SBOM 생성 자동화 사례 연구
2. 클라우드 네이티브 환경에서의 SBOM 관리
3. SBOM과 취약점 관리 연계 방안

참가자들은 이번 세미나를 통해 SBOM의 중요성과 실제 구현 방안에 대한 깊이 있는 이해를 얻을 수 있었습니다.

요약 보고서

기업의 오픈소스 관리 담당자에게 주는 의미

1. 규제 대응 필요성: SBOM은 미국, EU, 일본 등 주요국의 사이버보안 규제 대응에 필수적인 요소로 자리잡고 있습니다. 오픈소스 관리 담당자는 이러한 규제 동향을 주시하고 선제적으로 대응해야 합니다.

2. 소프트웨어 품질 향상: SBOM을 통해 사용 중인 오픈소스 컴포넌트를 정확히 파악하고 관리함으로써 전반적인 소프트웨어 품질을 향상시킬 수 있습니다.

3. 보안 취약점 관리 강화: SBOM은 사용 중인 오픈소스 컴포넌트의 취약점을 신속하게 식별하고 대응할 수 있게 해줍니다. 이는 기업의 사이버보안 태세를 강화하는 데 크게 기여합니다.

4. 공급망 투명성 확보: SBOM을 통해 소프트웨어 공급망의 투명성을 높일 수 있어, 고객 신뢰도 향상 및 리스크 관리에 도움이 됩니다.

5. DevSecOps 통합: SBOM을 개발 및 운영 프로세스에 통합함으로써 보안을 개발 초기 단계부터 고려하는 DevSecOps 문화를 촉진할 수 있습니다.

고려해야 할 Action Item

1. SBOM 생성 도구 평가 및 선택: SPDX, CycloneDX 등 다양한 SBOM 표준과 도구를 평가하고, 기업의 환경에 가장 적합한 솔루션을 선택합니다.

2. 자동화 프로세스 구축: CI/CD 파이프라인에 SBOM 생성 및 검증 과정을 자동화하여 통합합니다.

3. 교육 및 인식 제고: 개발자, 보안 팀, 법무 팀 등 관련 부서 직원들에게 SBOM의 중요성과 활용 방법에 대한 교육을 실시합니다.

4. 정책 및 가이드라인 수립: SBOM 관리에 대한 조직 내 정책과 가이드라인을 수립하고 이를 문서화합니다.

5. 취약점 관리 프로세스 개선: SBOM 정보를 활용하여 취약점 스캐닝 및 패치 관리 프로세스를 개선합니다.

6. 공급업체 관리 강화: 서드파티 소프트웨어 공급업체에 SBOM 제공을 요구하고, 이를 평가 기준에 포함시킵니다.

7. 규제 준수 모니터링: SBOM 관련 국내외 규제 동향을 지속적으로 모니터링하고, 필요시 신속히 대응합니다.

8. SBOM 공유 체계 구축: 고객 및 파트너사와 SBOM을 안전하게 공유할 수 있는 체계를 구축합니다.

이러한 액션 아이템을 체계적으로 이행함으로써, 기업은 SBOM을 효과적으로 도입하고 활용하여 소프트웨어 공급망 보안을 강화할 수 있을 것입니다.

6 - 2024-07-30 킥오프 웨비나: SBOM의 실제 활용 방안 모색

source: https://www.slideshare.net/slideshow/openchain-sbom-study-group-kick-off-call-2024-07-30/270623321

목차

1. 웨비나 소개
2. SBOM의 중요성과 OpenChain 프로젝트의 역할
3. SBOM 활용의 실제적 고려사항
4. SPDX Lite: SBOM 생성을 위한 간소화된 접근
5. 향후 계획 및 참여 방법

1. 웨비나 소개

제목

OpenChain SBOM Study Group 킥오프 웨비나

발표자 소개

• Shane Coughlan: OpenChain 프로젝트 총괄 매니저
• Kate Stewart: Linux Foundation의 오픈소스 기술 부사장
• Kobota San: Sony에서 근무하며, 2024년 SBOM Study Group의 의장

웨비나 소개와 목적

이 웨비나는 OpenChain 프로젝트의 새로운 SBOM Study Group의 킥오프 미팅입니다. 주요 목적은 대규모 및 복잡한 공급망에서 SBOM(Software Bill of Materials)을 실제로 어떻게 활용할 수 있는지에 대한 논의를 시작하는 것입니다. 이를 통해 SBOM의 실용적인 적용 방안과 공급망 내에서의 신뢰 구축 방법을 모색하고자 합니다.

2. SBOM의 중요성과 OpenChain 프로젝트의 역할

OpenChain 프로젝트는 2026년 설립 이후 지속적으로 컴플라이언스 및 보안 표준의 일환으로 SBOM을 요구해왔습니다. 프로젝트는 SBOM 분야에 다양한 방식으로 기여해왔으며, 특히 공급업체를 위한 간단한 SBOM 형식인 SPDX Lite의 개발과 SBOM 품질 평가 가이드 제작 등을 수행했습니다.

Shane Coughlan은 SBOM의 중요성을 강조하며, 이는 단순한 기술적 도구가 아닌 비즈니스 프로세스의 핵심 요소라고 설명합니다. SBOM은 소프트웨어 구성 요소의 투명성을 제공하여 보안, 라이선스 준수, 품질 관리 등 다양한 영역의 의사 결정을 뒷받침합니다.

3. SBOM 활용의 실제적 고려사항

Kate Stewart는 SBOM 활용에 있어 실제적인 고려사항들을 제시합니다:

SBOM 생성 및 소비의 주체

• 소프트웨어 개발자
• 제품 관리자
• 보안 전문가
• 법무 및 컴플라이언스 팀
• 구매 담당자
• 고객

SBOM의 주요 활용 사례

• 취약점 관리
• 라이선스 컴플라이언스
• 소프트웨어 구성 요소 추적
• 공급망 리스크 관리

SBOM 구현 시 고려사항

• 데이터 형식 (예: SPDX, CycloneDX)
• 생성 도구 및 프로세스
• 저장 및 배포 방식
• 업데이트 주기 및 버전 관리

4. SPDX Lite: SBOM 생성을 위한 간소화된 접근

Kate Stewart는 SPDX Lite에 대해 상세히 설명합니다. SPDX Lite는 전체 SPDX 규격의 간소화된 버전으로, SBOM 생성의 진입 장벽을 낮추고자 개발되었습니다.

SPDX Lite의 주요 특징

• 필수 필드 수를 줄여 간편한 SBOM 생성 가능
• 기본적인 소프트웨어 구성 요소 정보 제공
• 확장 가능성을 통해 필요에 따라 더 상세한 정보 추가 가능

SPDX Lite 활용 사례

• 소규모 프로젝트나 간단한 소프트웨어 패키지에 적합
• 대규모 SBOM 구현의 첫 단계로 활용 가능
• 공급업체와 고객 간의 기본적인 소프트웨어 구성 정보 교환에 유용

5. 향후 계획 및 참여 방법

Shane Coughlan은 SBOM Study Group의 향후 계획과 참여 방법에 대해 안내합니다:

• 정기적인 미팅을 통해 SBOM 관련 실제 사례와 도전 과제 논의
• 다양한 산업 분야의 전문가들과 협력하여 SBOM 활용 방안 개발
• OpenChain 커뮤니티를 통한 지식 공유 및 네트워킹 기회 제공

SBOM, 공급망에서의 SBOM 활용, 그리고 공급망 신뢰 증진에 관심 있는 모든 분들의 참여를 환영합니다. 특히 Sony의 Kobota San이 2024년 study group의 의장을 맡아 활동을 이끌어갈 예정입니다.

요약 보고서

기업의 오픈소스 관리 담당자에게 주는 의미

1. SBOM의 전략적 중요성 인식: SBOM은 단순한 기술적 도구를 넘어 비즈니스 프로세스의 핵심 요소로 자리잡고 있습니다. 오픈소스 관리 담당자는 SBOM을 통해 소프트웨어 공급망의 투명성을 확보하고, 보안 및 컴플라이언스 리스크를 효과적으로 관리할 수 있습니다.

2. 다양한 이해관계자와의 협업: SBOM은 개발자, 보안 전문가, 법무팀, 구매 담당자 등 다양한 부서와의 협업을 필요로 합니다. 오픈소스 관리자는 이러한 협업을 주도하여 조직 전체의 SBOM 활용을 촉진할 수 있습니다.

3. SBOM 표준 및 도구에 대한 이해: SPDX, CycloneDX 등 다양한 SBOM 표준과 관련 도구에 대한 이해가 필요합니다. 특히 SPDX Lite와 같은 간소화된 접근 방식은 SBOM 도입의 진입 장벽을 낮출 수 있습니다.

4. 공급망 관리 강화: SBOM을 통해 소프트웨어 구성 요소의 출처와 라이선스 정보를 명확히 파악할 수 있어, 공급망 리스크 관리와 라이선스 컴플라이언스를 강화할 수 있습니다.

고려해야 할 Action Item

1. SBOM 생성 및 관리 프로세스 수립: 조직 내 SBOM 생성, 유지보수, 공유를 위한 표준화된 프로세스를 개발하고 구현합니다.

2. SBOM 도구 선정 및 도입: 조직의 needs에 맞는 SBOM 생성 및 분석 도구를 선정하고 도입합니다. SPDX Lite와 같은 간소화된 접근부터 시작할 수 있습니다.

3. 교육 및 인식 제고: 개발자, 관리자, 법무팀 등 관련 부서 직원들을 대상으로 SBOM의 중요성과 활용 방법에 대한 교육을 실시합니다.

4. 공급업체 관리 정책 수립: 외부 공급업체로부터 SBOM을 요구하고 평가하는 정책을 수립합니다. 이를 통해 전체 소프트웨어 공급망의 투명성을 확보합니다.

5. SBOM 데이터 통합 및 분석: SBOM 데이터를 기존의 보안 및 컴플라이언스 도구와 통합하여 종합적인 리스크 분석을 수행합니다.

6. 지속적인 모니터링 및 개선: SBOM 관련 기술과 표준의 발전을 지속적으로 모니터링하고, 조직의 SBOM 프로세스를 지속적으로 개선합니다.

7. 커뮤니티 참여: OpenChain SBOM Study Group과 같은 커뮤니티에 참여하여 최신 동향을 파악하고 다른 조직의 best practices를 학습합니다.

이러한 action item들을 체계적으로 실행함으로써, 기업의 오픈소스 관리 담당자는 SBOM을 효과적으로 활용하여 조직의 소프트웨어 관리 및 보안 체계를 강화할 수 있을 것입니다.