[기고]SBOM을 효율적으로 관리하기 위한 방안

1. 한국 및 미국, EU 외 국가들의 SBOM 관련 법안과 규정

1.1 한국

2024년 5월, 확산되고 있는 SW 공급망 사이버 보안 위험과 미국, 유럽 등 해외 주요국의 소프트웨어 구성요소 목록(Software Bill of Materials, SBOM)제출 의무화 등에 대응하여 정부·공공 기관 및 기업들이 자체적인 SW 공급망 보안 관리역량을 갖출 수 있도록 지원하기 위해 과기정통부, 국정원, 디플정위에서 소프트웨어 공급망 보안 가이드라인(지침) 1.0을 발표했다. 가이드라인에는 정부·공공 기관 및 기업들이 SBOM 기반 SW 공급망 보안 관리체계를 도입하는 과정에서 시행착오를 줄일 수 있도록 SBOM 유효성 검증, SW 구성요소 관리 요령 및 SBOM 기반 SW 공급망 보안 관리방안 등을 상세하게 수록하였다.

1.2 미국

1) 국가 사이버 보안 전략(National Cybersecurity Strategy)

2023년 3월 공표된 NCS는 사이버 보안 발전을 위한 기본 문서로서 미국과 해외 여러 국가들의 사이버 보안 강화의 시급성을 강조하고 있다. SolarWinds 해킹과 NotPetya 렌섬웨어 사건과 관련된 인프라 개선, 행정명령(EO) 14028에 따른 SBOM에 이르기 가지 광범위한 영역을 다루고 있고 특히, 소프트웨어 설계에서 보안의 중요성이 커지고 있음을 강조하면서 소프트웨어 제조업체에 대한 책임을 강조하고 있다.

2) 오픈소스 소프트웨어 보안법 (Securing Open Source Software Act of 2023)

2023년 3월, 미국 의회는 오픈소스 보안 문제를 법적으로 규정하고 보안 문제를 방지하기 위한 연방정부의 역할과 책임을 규정하는 오픈소스 소프트웨어 보안법을 제정했다. 해당 법률에서는 "오픈소스 소프트웨어 보안과 기타 목적에 관한 사이버 보안 및 인프라 보안국(CISA) 국장의 의무“를 설정하고 있다. 이 법안은 로그4J 보안취약점 사태 이후 추진되었으며 미국 CISA에서 오픈소스 소프트웨어를 연방정부와 중요 인프라 및 기타 기관에서 안전하게 사용한다는 것을 보증하도록 돕게 해야 한다는 의지를 담고 있다. 오픈소스 소프트웨어 보안법은 그동안 정책과 규제 영역에 있던 오픈소스 소프트웨어를 연방 법의 영역으로 이동시켰으며, 이 법안에 따라 CISA는 오픈소스 소프트웨어의 위험을 완화하는 방법을 식별하고 보안 문제를 해결할 오픈소스 개발자를 고용해야 한다. 또, 일부 연방 기관에서 '오픈소스 프로그램 오피스(OPSO)'를 시작할 것을 제안하고, 미국 예산관리국(OMB)이 CISA 소프트웨어 보안 소위원회에 자금을 지원하며, 사용자의 오픈소스 소프트웨어 보호 방법에 대한 연방 지침을 발행해야 한다고 명시했다.

3) 증권거래위원회(Securities and Exchange Commission,SEC) 규정

2023년 10월, 미국 증권거래위원회(SEC)는 SEC의 규제 범위 내에 있는 상장 기업, 증권 시장, 고문, 펀드 및 기타 기관에 대한 여러 규정을 제안했다. 새로운 규정에는 조직이 취약성 관리, 탐지, 완화 및 수정을 위한 강력한 프로세스 및 절차의 개발을 입증해야 하는 요구사항과 함께 조직이 중요한 사이버 보안 사고를 공개하고 연간 사이버 보안 위험 관리, 전략 및 거버넌스 정보를 제공하도록 강제하는 새로운 규칙을 채택했다.

4) 보안 소프트웨어 자체 증명 공통 양식 (Secure Software Self-Attestation Common Form)

2023년 4월, 미국 정부 예산 관리국(Office of Management and Budget, OMB)은 연방 기관이 미국 정부에 소프트웨어 제품을 공급하는 소프트웨어 제조업체로부터 정보를 수집하도록 요구하는 지침을 설정했다. 소프트웨어 제조업체는 NIST에서 개발한 보안 소프트웨어 개발 프레임워크인 SSDF(Secure Software Development Framework)를 사용했음을 자체적으로 증명하도록 요청하고 있다.

1.3 유럽연합(EU)

1) 사이버 복원력법 (Cyber Resilience Act)

2022년 9월 제안된 사이버 복원력법(CRA)은 EU 전역에서 판매되는 하드웨어 및 소프트웨어 제품 모두에 대한 사이버 보안 프로세스 구축을 목적으로 공개되었다. 인터넷에 연결된 모든 제품의 제조업체가 모든 최신 패치 및 보안 업데이트를 최신 상태로 유지하도록 했으며, 이를 준수한 제품에는 CE 마크가 부여된다. 취약점 등에 대해서도 처벌 조항을 두고 있다. 만약 이 법을 준수하지 않을 경우는 최대 1,500만 유로 또는 전 세계 매출의 2.5%에 해당하는 벌금이 부과된다. 표면적으로는 제조업체에게 소프트웨어 제품에 대한 보안에 대한 책임을 묻는 것이지만 잠재적으로 오픈소스 프로젝트와 개발자들 또한 책임에서 자유로울수 없어 논란이 되기도 했다. 논란의 핵심은 “어떻게 오픈소스를 개발해 ‘업스트림’한 개발자가 이를 ‘다운스트림’해서 만든 제품의 보안 결함까지 책임을 져야 하는가”라는 것이었다. 이에 다시 법 조항 일부에 대해 상업적 변경이 이루어졌고 개정된 법안에서는 처벌이 면제되는 오픈소스 프로젝트 사항을 좀 더 명확히 했다. 새로운 법안은 이미 확정되었지만 2027년까지는 발효되지 않는다.

2) 제조물 책임 지침(Product Liability Directive)

제조물 책임 지침(PLD)은 결함이 있는 제품의 제조업체와 해당 제품의 결함 부품 공급업체의 책임과 책임에 대한 규칙과 지침을 제공한다. 2022년 9월에 제안된 업데이트는 이전에 제외되었던 소프트웨어 및 디지털 제품을 포괄하고 있다. 이러한 업데이트는 오픈소스 소프트웨어 및 모든 관련 프로젝트 또는 활동에 대한 결함(즉, 취약성)과 관련된 잠재적인 책임을 정의하고 있다. 오픈소스를 활용하여 개발한 소프트웨어 제품을 고객에게 판매하여 취약점으로 인해 손실을 초래하거나 어려움을 초래하는 경우 책임을 질 수 있다.

3) 네트워크 및 정보 보안 지침 (Network and Information Security Directive)

2022년 12월, 유럽 의회는 네트워크 및 정보 보안 지침(NIS)에 대한 업데이트를 승인했으며, 이를 NIS2로 지칭하고 있다. NIS2는 사이버 보안에 대한 EU 회원국의 접근 방식을 현대화하기 위한 방안으로서 소프트웨어 공급망 보안 개선, 중요 취약점에 대한 관심 강화, 악의적인 위협을 통한 공격 증가, 조정된 취약성 공개 (CVD, Coordinated Vulnerability Disclosure)와 같은 공개 및 커뮤니케이션 프로세스의 필요성에 대한 설명이 포함되어 있다. 업데이트된 네트워크 및 정보 보안 지침(NIS2)은 2024년 10월까지 새로 정의된 비즈니스 부문 범주(매우 중요, 중요 및 필수 엔터티)를 기반으로 엄격한 규정 준수 요구사항을 부과하고 있으며, NIS2에 설정된 요구사항을 충족하지 못하면 여러 가지 제재를 받을 수 있다.

1.4 캐나다

1) 국가 사이버 위협 평가(National Cyber Threat Assessment 2023-2024)

2022년 10월, 캐나다 사이버 보안 센터(사이버 센터)는 국가 사이버 위협 평가 2023-2024를 발표하여 국가가 후원하는 사이버 위협 및 범죄 사이버 위협이 캐나다인에게 영향을 미칠 가능성이 점점 더 높아지고 있다고 경고했다.

2) 소프트웨어 공급망 위협으로부터 조직 보호(Protecting your organization from software supply chain threats)

2023년 2월, 사이버 보안 센터는 소프트웨어 공급망 보안을 위한 지침과 모범 사례를 제공하는 "소프트웨어 공급망 위협으로부터 조직 보호"를 발표했다. 이 문서에서는 업데이트를 손상시키는 맬웨어의 능력과 오픈소스 구성요소의 취약성 수정의 중요성을 포함하여 소프트웨어 공급망 위험을 최소화하는 것의 중요성을 설명하고 있으며 권장 사항에는 공급업체를 조사하고, 지속적으로 모니터링하고, 공급망 위험 관리를 보안 프로그램에 통합하는 것이 포함되어 있다. 마지막으로, 조직은 소프트웨어 공급망 공격이 발생할 때 비즈니스 연속성을 보장하기 위한 복구 계획을 수립해야 한다고 강조하고 있다.

1.5 일본

2023년 7월, 경제산업성(METI)은 소프트웨어 공급망이 복잡해짐에 따라 위협이 급증하고 있는 소프트웨어 보안성 확보를 위한 소프트웨어 관리방안 중 하나로 SBOM에 주목하고, 기업이 SBOM을 도입할 때의 장점과 SBOM을 실제로 도입할 때 인식하고 수행해야 할 핵심 사항을 정리하여 소프트웨어 공급업체를 대상으로 소프트웨어 관리를 위한 SBOM 수행 가이드 (A Guide to Implementing the Software Bill of Materials (SBOM) for Software Management)를 발표했다.

1.6 시사점

앞서 살펴본 한국을 포함해서 미국, EU, 캐나다, 일본과 같은 주요 국가에서 제정한 법과 규정들은 사이버 보안에 대한 인프라를 개선하고 보호하기 위한 노력들이다. 무엇보다 소프트웨어 개발에 있어 보안에 대한 중요성과 함께 소프트웨어 개발(제조 및 생산)사에 대한 책임과 사이버 보안 사고를 해결하기 위한 강력하고도 강제적인 프로세스의 필요성을 강조하고 있다.

2. 효율적인 SBOM 관리 방안

2.1 SBOM 관리 목적 및 개요

SBOM 관리의 궁극적인 목적은 안전한 소프트웨어의 사용을 위해 효율적으로 소프트웨어 공급망을 관리하기 위해서이다. 그러기 위해서는 각 조직의 사업환경과 비즈니스 모델에 적합한 SBOM 요구사항을 도출하고 필요한 SBOM을 생성, 관리, 유지하기 위한 제반 정책과 절차를 구축하고 이행하기 위한 지침을 준비해야 한다.

본 글에서는 조직환경에 부합한 SBOM을 효과적으로 관리하기 위해서 다음과 같은 프로세스를 제시한다.

• 첫째, 개별 공급망 환경에서 소프트웨어 공급망 이해관계자들의 요구사항을 기반으로 SBOM 관리영역을 도출하여야 한다.
• 둘째, 분석된 공급망 환경에 따른 비즈니스 모델 전개시 위험요인을 파악하여야 한다.
• 셋째, 공급망 환경과 관리영역에 따른 SBOM 속성을 정의하고 자동화된 SBOM을 생성 및 관리하여야 한다.
• 넷째, SBOM을 지속적으로 관리하기 위한 정책 및 R&R과 절차를 수립하여야 한다.

2.2 SBOM 관리 프로세스

1) SBOM 공급망 환경 분석 및 관리영역 도출

고객이 요구하는 명확한 SBOM을 생성 및 관리하기 위해서는 조직 내․외부의 소프트웨어 개발 및 공급에 대한 환경분석과 대상 소프트웨어의 비즈니스 모델 분석을 통해 SBOM 관리영역을 도출하여야 한다.

[그림 1] SBOM 공급망 환경과 관리영역

현재의 소프트웨어는 여러 조직 및 저작권자들의 복합지적재산권으로 구성되어 개발되고 있다. 소프트웨어를 구성하고 있는 소스코드는 내부 개발자들에 의한 자체개발 코드, 외부에 공개되어 있는 오픈소스 소프트웨어 코드, 구매 및 아웃소싱을 통해 개발한 코드, 구매 및 아웃소싱을 통해 개발한 코드에 포함된 오픈소스 소프트웨어 코드 등으로 구성되어 있으며 이러한 소스코드는 다양한 라이브러리 혹은 오브젝트 코드와 연결되어 실행될 수 있다.

따라서, 현재 조직의 소프트웨어 개발에 포함되어 있는 다양한 공급망 환경분석을 통해 관리영역을 도출할 수 있다.

• 전체 자체 개발 코드
  외부 오픈소스 소프트웨어 및 출처를 알 수 없는 소스코드를 사용하지 않고 전체 소프트웨어를 자체 개발한 경우이다.
• 오픈소스 소프트웨어 코드 사용
  내부 개발자이던 외부 아웃소싱 개발자이던, 공급받은 구매 코드이던 오픈소스 소프트웨어를 사용하여 개발한 경우이다.
• 바이너리 코드 사용
  아웃소싱 개발 혹은 구매한 소프트웨어로서 소스코드 없이 바이너리만을 사용하여 개발한 경우이다.

2) 비즈니스 모델에 따른 위험분석

소프트웨어 개발에 대한 공급망 환경분석이 완료되었으면 공급망 환경에 따른 소프트웨어의 비즈니스 모델 전개 시에 발생 될 수 있는 위험 요인을 분석하여 관리영역을 도출하여야 한다.

3) SBOM 환경분석을 통한 관리 속성 정의 및 SBOM 생성

SBOM 공급망 환경 분석을 통해 고객의 요구사항에 부합한 위험요인 식별과 관리영역 도출이 완료되었으면 해당 위험요인에 대한 다양한 데이터에 대한 속성을 정의하고 데이터 생성을 위한 도구를 정의하여 자동화된 도구를 통한 지속적인 SBOM 생성 및 업데이트가 필요하다.

[그림 2] SBOM 환경분석을 통한 관리 속성 정의 및 SBOM 생성

다양한 공급망 환경에 따른 소프트웨어 개발 유형과 자원, 비즈니스 모델별 위험요인을 식별하고 위험요인 예방을 위한 관리영역 도출 및 관리 데이터 속성을 정의하여야 한다.

① SBOM 속성 정의

[표 1] 공급망 환경에 따른 비즈니스 모델 전개 시 위험요인과 같이 SBOM을 구성하는 다양한 구성요소들에 대한 데이터 속성 정의는 조직의 소프트웨어 개발 공급망 환경과 비즈니스 모델에 따라 상이할 수 있다. SBOM 필요 속성 정의를 위해서는 먼저 공급망 환경을 분석하고 비즈니스 모델에 따른 소프트웨어 공급유형을 파악하여 위험요인을 도출하고 최종적으로 고객의 요구사항에 부합되는지를 확인하여 속성을 정의한다.

본 글에서는 2022년 12월 7일 재정한 ‘오픈소스 소프트웨어 공급망 관리를 위한 소프트웨어 목록 구성(SBOM) 속성 규격(TTAK.KO-11.0309)’을 예를 들어 소개한다. [표 2] SBOM 표준 속성 규격을 참고하여 각 조직의 환경에 따라 해당 속성 규격을 차별적으로 적용, 관리할 수 있다. 예를 들어 소프트웨어 공급망 환경 분석결과 오픈소스 소프트웨어를 사용하지 않고 전체 자체개발 코드라면 SBOM 검증 도구를 통해 오픈소스 소프트웨어의 사용 여부만 확인하면 되며 컴포넌트, 라이선스 명, 라이선스 결합형태 등의 속성이 필요 없다.

② SBOM 생성 도구 정의 및 자동화 지원 SBOM 생성

SBOM 환경분석을 통해 SBOM 관리 속성이 정의되었으면 SBOM을 통한 관리영역별 데이터 필드를 도출하여 생성 가능한 자동화 지원 도구를 식별하고 활용하여야 한다.
관리영역별 자동화 지원 SBOM 생성 도구는 정적분석 도구, 오픈소스 소프트웨어 종속성 분석 도구, 오픈소스 소프트웨어 컨테이너 분석 도구, 소스코드 분석 도구, 바이너리 분석 도구 등이 있다.

• 정적분석 도구
  취약점 관점에서 자체개발 코드 혹은 오픈소스 소프트웨어 코드 구분 없이 기존에 알려진 취약점을 가진 코딩 규칙을 통해 소프트웨어가 개발되지 않도록 검증하는 도구이다. 일반적으로 자체개발 코드, 오픈소스 소프트웨어 사용 코드 등에 활용될 수 있다.
• 오픈소스 소프트웨어 종속성 분석 도구
  오픈소스 소프트웨어 라이브러리 링크나 오브젝트 코드 포함 여부를 식별하여 오픈소스 소프트웨어 명, 버전, 라이선스 및 보안취약점을 검증하는 도구이다. 주로 오픈소스 소프트웨어 검증에 활용될 수 있다.
• 오픈소스 소프트웨어 컨테이너 분석 도구
  컨테이너에 오픈소스 소프트웨어 사용 여부, 오픈소스 소프트웨어 명, 버전, 라이선스 및 보안취약점을 검증하는 도구이다. 컨테이너 기반 오픈소스 소프트웨어 검증에 활용될 수 있다.
• 소스코드 분석 도구
  소스코드를 분석하여 오픈소스 소프트웨어 사용 여부, 오픈소스 소프트웨어 명, 버전, 라이선스 및 보안취약점을 검증하는 도구이다. 도구별로 소스 코드 라인별로 사용된 오픈소스 소프트웨어를 식별할 수 있는 도구도 있으며 파일별로 복제 사용된 오픈소스 소프트웨어 파일만 식별할 수 있는 도구도 있다. 파일별로 복제 사용된 오픈소스 소프트웨어만 식별하는 도구의 경우 오픈소스 소프트웨어 파일을 변경하여 사용할 경우 식별이 불가능하다.
• 바이너리 분석 도구
  소스코드 분석이 불가능한 경우 바이너리 파일만을 가지고 분석하여 오픈소스 소프트웨어 사용 여부, 오픈소스 소프트웨어 명, 버전, 라이선스 및 보안취약점을 검증하는 도구이다. 주로 계약관계 상 바이너리만을 공급받을 경우 오픈소스 소프트웨어 검증용으로 활용될 수 있으며, 오픈소스 소프트웨어 라이선스 의무사항은 배포와 동시에 발생 됨에 따라 소스코드 분석을 하더라도 최종 배포되는 바이너리 파일을 대상으로 확인 검증의 목적으로 활용될 수 있다.
• 기타
  라이선스 및 저작권 문구 등으로 오픈소스 소프트웨어 사용 여부를 확인하거나 기타 특정 환경에서의 라이선스 및 취약점 분석에 활용될 수 있는 도구들이다.

4) SBOM 관리정책 수립

① 오픈소스 소프트웨어 라이선스 관리 정책의 적용 범위

• 사용 범위 : 오픈소스 소프트웨어 라이선스는 오픈소스 소프트웨어 사용 범위에 의해 의무사항이 적용되는데 조직 내에서 수취 및 실행을 목적으로만 사용할 경우에는 라이선스 준수 의무가 없고 고객, 관계사 대상 배포 및 서비스의 경우 라이선스 의무사항이 적용된다.
• 배포 및 서비스 유형 : 고객, 관계사에 배포 시에는 어떠한 오픈소스 소프트웨어를 사용하더라도 해당 오픈소스 소프트웨어 라이선스에 따라 퍼미시브 계열의 경우 사용/변경 사항 고지의무, 경우에 따라 무상 특허 허용에 대한 준수 의무사항이 발생되고, 위크 카피레프트 계열의 경우 추가적으로 제한된 범위에서의 소스코드 공개의무, 스트롱 카피레프트 계열의 경우 모든 소스코드 공개의무가 발생된다. 각각의 라이선스 계열별 배포 및 서비스 유형에 따라 반드시 조직 오픈소스 소프트웨어 사용 분류기준에 따른 허용정책을 준수하며 사용하여야 한다. 반면, 고객, 관계사에 소프트웨어 배포 없이 네트워크를 통한 서비스를 제공하는 경우에는 AGPL-3.0, SSPL-1.0만 검토 대상이 된다.

[그림 3] 오픈소스 소프트웨어 라이선스 의무사항 발생 시점 및 사용 라이선스 계열

② 오픈소스 소프트웨어 라이선스 관리 정책

• 라이선스 분류 : 조직에서는 오픈소스 소프트웨어를 사용할 경우 오픈소스 소프트웨어의 사용방식(복제, 수정), 결합형태, 통신방식 등과 밀접하게 관련되어 이행 의무사항이 발생되는 오픈소스 소프트웨어 라이선스 특성을 반영하여 오픈소스 소프트웨어 라이선스를 분류하여 검토해야 한다.
• 오픈소스 소프트웨어 사용 범위 및 사용 기준 준수 : 오픈소스 소프트웨어가 배포에 해당되는 경우와 서비스에 해당되는 경우를 분류하여 사용 기준을 검토해야 한다.

③ 오픈소스 소프트웨어 보안취약점 관리정책 및 절차

• 오픈소스 소프트웨어 보안취약점 관리정책 : 오픈소스 소프트웨어의 유입에서부터 폐기 전 과정에 사용된 오픈소스 소프트웨어를 추적하고 관리할 수 있도록 제반 점검과 절차 및 R&R에 대한 정책을 수립, 관리해야 한다.
• 오픈소스 소프트웨어 보안취약점 관리절차 : 소스코드 단위의 오픈소스 소프트웨어 사용에 대한 점검 및 조치 절차와 패키지 단위의 오픈소스 소프트웨어 사용에 대한 저장소 점검 및 조치 절차에 대한 절차를 수립, 관리해야 한다.

④ 오픈소스 소프트웨어 보안취약점 조치 우선순위 설정

• 자산 중요도 및 보안취약점 등급에 따른 보안취약점 조치 우선순위를 구분해서 정책에 반영해야 수없이 탐지되는 보안취약점을 효율적으로 관리할 수 있다.
• 조치 우선순위별로 조치 방법과 점검 시기를 결정하여 취약점 발생 여부를 확인하여야 한다.

5) SBOM 관리 R&R

SBOM 관리를 위해서는 조직내․외부에 소프트웨어 개발 및 공급에 참여하는 부서 및 구성원에 대한 적절한 역할과 책임을 부여하여야 한다.

6) SBOM 관리 절차

SBOM 관리를 위해서는 조직내에 소프트웨어 개발 및 공급을 위한 기획, 구현, 검증, 제품화 절차에 부합되게 관련 부서 및 구성원에 대한 적절한 프로세스를 구축, 운영하여야 한다.

3. 결론

현재 사이버 보안에 대한 인프라 개선과 보호를 위해 한국은 물론, 미국, EU, 캐나다와 같은 주요 국가들은 다양한 법과 규정들을 제정하고 있다. 그 핵심에는 무엇보다 소프트웨어 개발에 있어 보안에 대한 중요성과 함께 소프트웨어 개발(제조 및 생산)사에 대한 책임과 사이버 보안 사고를 해결하기 위한 강력하고도 강제적인 프로세스의 필요성을 강조하고 있다는 것이다. 현재 안전한 소프트웨어 사용을 위한 소프트웨어 공급망 관리는 전 세계적으로 IT 거버넌스의 핵심을 구성하고 있고 소프트웨어를 개발 및 공급, 유통하는 기업들에게 있어 SBOM 관리는 소프트웨어 개발 프로세스의 주요 관리 항목이 되었다.

본 글에서는 이러한 SBOM을 효율적으로 관리하기 위한 절차와 방법을 2023년 제정된 TTA 단체 표준인 SBOM 관리 지침을 기반으로 다음과 같이 세 가지로 정리하여 제시하였다.

• 첫째, 개별 공급망 환경에서 소프트웨어 공급망 이해관계자들의 요구사항을 기반으로 조직에 적합한 SBOM 관리영역을 도출하여야 한다. SBOM은 공급망 환경에서 안전한 소프트웨어 사용을 위해 공급자와 수요자가 정한 요구사항에 대한 확인서이다. 따라서, 무엇보다도 공급망 환경의 특성과 요구사항을 반영한 관리영역을 도출하는 것이 선행되어야 한다.
•  
• 둘째, 분석된 공급망 환경에 따른 비즈니스 모델 전개 시 위험요인을 파악하여야 한다. 소프트웨어에 대한 라이선스와 보안취약점은 소프트웨어를 공급하고 사용되는 비즈니스 모델에 따라 적용 범위와 위험에 대한 영향성이 다를 수 있다. 따라서, 해당 소프트웨어로 인해 발생될 수 있는 위험을 예방하기 위해 최적화된 SBOM을 생성하고 관리하기 위해서는 해당 소프트웨어의 비즈니스 모델에 따른 위험요인을 파악하는 것이 선행되어야 한다.
•  
• 셋째, 공급망 환경과 관리영역 및 비즈니스 모델에 따른 위험을 예방하고 효율적으로 유지관리 하기 위한 SBOM 속성을 정의하고 자동화된 SBOM을 생성 및 관리하여야 한다. 공급망 환경에 따른 관리영역과 비즈니스 모델에 따른 위험요인이 파악되었으면 해당 위험을 예방하고 확인하기 위한 SBOM 속성을 정의하고 자동화 도구를 선정할 수 있다. 관리영역과 비즈니스 모델에서 분석된 위험요인을 파악하고 예방하기 위한 소프트웨어 구성요소 목록에 대한 데이터 필드를 정의하고 이를 효과적으로 식별 및 생성할 수 있는 자동화된 도구를 선정하여 관리하여야 한다.
•  
• 넷째, SBOM을 지속적으로 관리하기 위한 정책 및 R&R과 절차를 수립하여야 한다. 일반적인 품질개선과 예방을 위한 관리방안과 마찬가지로 지속적인 SBOM 관리를 위해서는 소프트웨어 개발 생명 주기와 프로세스에 적합한 관리 정책을 기반으로 한 R&R과 절차를 수립하여 운영하여야 한다.

본 글에서 제시한 전 세계적인 SBOM 관련 현황과 SBOM 관리 방안이 SBOM의 필요성을 보다 쉽게 인지하고 조직의 공급망 환경과 특성에 부합된 최적화된 SBOM을 생성 및 관리하는데 실무적인 도움이 되길 바란다.

※ Reference

• 2022, 한국정보통신기술협회(TTA), “TTAK.KO-11.0309”, 오픈소스 소프트웨어 공급망 관리를 위한 소프트웨어 목록 구성(SBOM) 속성 규격
• 2023 한국정보통신기술협회(TTA), “TTAK.KO-11.0322”, 오픈소스 SBOM 거버넌스 관리 지침
• 2023 Sonatype- 9th Annual State of the Software Supply Chain