[기고] 소프트웨어 소비자를 위한 SBOM 검증의 중요성
소프트웨어 소비자를 위한 SBOM 검증의 중요성
- 고려대 SW·AI융합대학원 최윤성 교수 -
※ 목차
- Ⅰ. SW 공급망 보안의 배경
- Ⅱ. 공급망 사이버보안 위험관리(C-SCRM) 개요
- 1. C-SCRM을 위한 SBOM 생성 방안
- 2. SW 소비자와 SBOM 자동화 도구
- 3. SW 소비자 관점에서 SBOM의 이점
- 4. SW 생명 주기에 따른 SBOM 활용 방안
- Ⅲ. 맺음말 : SBOM 검증의 중요성
Ⅰ. SW 공급망 보안의 배경
지난 몇 년간 소프트웨어(SW) 공급망에 대한 사이버 침해가 급격히 증가하면서 각국 정부 및 인프라에 사용되는 SW 공급망의 복원력에 대한 강화 조치가 필요해졌다. 특히 미국 내 여러 정책과 실무 그룹에서는 SW 제품의 진위성(Authenticity), 무결성(Integrity), 신뢰성(Trustworthiness)을 보장하는 방안에 초점을 두었으며, ‘공급망 사이버보안 위험관리(Cybersecurity Supply Chain Risk Management, C-SCRM)’ 전략의 일환으로 ‘SW 자재 명세서(Software Bill of Materials, SBOM)* ’를 관리하는 방안이 연구되었다.(1)
* 미국 NTIA는 SBOM을 ‘SW 재료의 목록’이며 "SW 구축에 사용되는 다양한 구성요소의 세부 사항과 공급망 관계를 포함하는 공식적인 기록"으로 정의
전통적으로 SW 공급망 침해는 주로 패치되지 않은 채 방치된 취약점을 표적으로 삼았다. 위협 행위자들은 여전히 패치되지 않은 시스템을 표적으로 삼고 있지만, 더 이상 취약점 공개를 기다리지 않고 선제적으로 디지털 제품과 서비스에 악성 코드를 삽입한 다음 글로벌 SW 공급망을 통해 합법적으로 다운스트림에 배포하고 있다. 지난 몇 년 동안 오픈소스 및 상용 SW 제품 모두에서 차세대 SW 공급망 침해가 증가했으며, 이러한 공격 벡터(Vector)의 확장은 SW 공급망에 새로운 위협을 가하고 레거시(Legacy) 시스템 방어에 중요한 패치 시스템 자체에 대한 신뢰를 약화한다.
Supply chain attacks are increasing exponentially.
In 2021 the world witnessed a 650% increase in software supply chain attacks, aimed at exploiting weaknesses in upstream open source ecosystems. For perspective, the same statistic was 430% in the 2020 version of the report.(2)
참고로 SW 공급망에 사용되는 일반적인 침해 방법에는 1) SW 설계 결함의 악용, 2) 상용 SDK, 오픈소스 라이브러리 등 취약한 타사 구성 요소를 SW 제품에 통합, 3) 최종 SW 제품이 제공되기 전에 공급업체의 네트워크에 침투, 4) 고객이 배포하는 SW에 악성 코드 삽입 등이 있다.(3)
Ⅱ. 공급망 사이버보안 위험관리(C-SCRM) 개요
美 NSA(National Security Agency)의 C-SCRM 전략은 SW 제품 소비자에 도래할 수 있는 사이버 위험을 파악하고, 완화하기 위해 SBOM을 활용하는 것이다. SBOM 데이터와 SBOM 관리 시스템은 위험 식별 및 조치의 격차를 해소하고, 기업의 사이버보안 태세를 개선하는 데도 도움이 될 수 있다. 다만, SW 소비자는 아래와 같은 활동에 필요한 사이버보안 도구의 일부로써 SBOM을 활용하는 것이지, SBOM 자체가 공급망 사이버보안의 만능 도구가 아니라는 사실을 염두에 두어야 한다.
- SW 구입 및 배포에 대한 위험관리
- SW 배포 및 지속적인 운영에 대한 취약성 관리
- 새로운 SW 취약성을 탐지하고 대응하기 위한 침해사고(Incident) 관리
SBOM을 활용한 C-SCRM의 핵심은 SW 위험관리, 보안 취약성 및 침해사고 관리이다. 위험관리의 예를 들면, 오픈소스 SW 라이선스의 충돌이나 위반, 알려진 보안 취약점 등의 위험을 식별하고 해당 정보를 바탕으로 SW의 적합성을 판단하는 것이다. 또한 IT 보안팀은 취약점 관리를 통해 취약점이 악용되기 전에 취약점을 식별하고 수정함으로써 보다 선제적인 보안 태세를 취할 수 있다. 마지막으로 침해사고 관리의 목표는 SW 구매 절차의 일부로 또는 SW 공급망을 통한 운영 시스템 침해가 발생하면 전반적인 조직 위험 노출을 줄이고 최대한 신속하게 대응하는 것이다.
1. C-SCRM을 위한 SBOM 생성 방안
SBOM은 SW의 구성 요소를 기술하는 일종의 메타데이터 문서로, SW 구성 요소의 세부 사항과 의존성을 형식화하여 기술한 것을 의미한다. SBOM을 C-SCRM에서 활용하기 위해서는 SW 설계 단계부터 빌드 환경, 바이너리 파일 분석, 시스템 레지스트리 쿼리(Query) 등 다양한 형태의 SW 개발 프로세스 산출물로부터 SBOM을 생성하는 것이 필요하다. 이상적으로는 SW 개발 초기부터 생성하여, 지속적으로 보강 및 업데이트하는 것이 바람직하다.(4)
[그림 1] 두 개의 SW 공급망이 표현된 SBOM 그래프 예시

다만, C-SCRM을 위한 SBOM은 해당 SW의 모든 구성 요소에 대한 의존 관계를 설명해야 한다. 예를 들어 사용자 SW가 독점 애플리케이션 A와 타사 라이브러리 B로 구성되어 있고, 여기에 다시 독점 애플리케이션 C와 타사 라이브러리 D가 포함된 경우 SBOM은 SW에 포함된 모든 요소인 A, B, C, D 간의 종속성과 식별 정보를 자세히 기록해야 한다.(5)
NSA는 국가 보안 시스템(National Security System, NSS)용 가이드에서 최소한 각 구성 요소에 대한 NTIA 필수 필드를 SBOM에 포함하고, 공급업체의 제품에 통합된 모든 오픈소스 및 상용 SW의 타사 SW 종속성을 열거할 것을 요구하였다. 또한 오픈소스 SW 항목에 대해 NTIA 필수 필드를 포함하기 어려울 때는 파생된 구성 요소가 무엇인지 공개하는 것을 모범 사례로 제시했다.
Inclusion of software component information containing, at a minimum, the NTIA required field for each component in all delivered software. Additional component details should be requested and required as the state of the industry matures. This requirement includes the expectation that a supplier enumerate third-party software dependencies (both open source and proprietary) incorporated into the supplier’s product. Where the NTIA required information is not available or verifiable for open source items, derived components must be disclosed.
2. SW 소비자와 SBOM 자동화 도구
SBOM 필수 필드 외에도 누락된 데이터 필드 정보에 대한 참조 소스 보강, 디지털 서명, 컴포넌트 해시(Hash), PURL/CPE 포인터 등의 유효성 검사, SBOM의 자체적인 무결성 검증 및 위험평가 기능을 위한 출처 데이터에 대한 링크 등 추가적인 정보가 요구된다. 따라서, SBOM 기반 위험관리의 구현을 위해서는 SW 개발자와 보안 분석가의 수고를 줄여주는 SW 구성 분석(SW Composition Analysis, SCA)과 같은 기술을 통한 SBOM 관리 자동화가 필수적이다.
SCA 도구는 SBOM을 자동으로 생성하는 데 활용할 수 있다. 분석가는 SCA 도구가 수행하는 과정을 수동으로 모두 수행할 수 있으며, SCA 도구를 사용하는 것과 수동 분석 프로세스 간 근본적인 차이는 존재하지 않는다. 다만 SCA 도구는 자동화된 과정을 통해 결과를 도출하므로 그 속도가 수작업에 비해 빠르다는 장점이 있다.
일부 SCA 도구는 분석 대상의 소스 코드에 액세스할 수 없는 경우에도 컴파일된 바이너리 파일만 분석하여 SBOM을 생성할 수 있다. 바이너리 SCA 접근법은 소스 코드 및 빌드 정보에 대한 액세스 없이도 SBOM으로 레거시 SW의 위험을 관리할 방법을 제공한다. 다만, 모든 바이너리 파일을 분석할 수 있는 것은 아니고, 사전에 지원 여부가 확인된 바이너리 형식에 대해 분석을 제공한다. 또한 SBOM 관리 시스템은 다양한 위협 소스를 SW 취약점 및 약점 데이터베이스와 통합하여 공급망 위험관리 인텔리전스에 대한 포괄적인 뷰를 제공하는 것이 목표이다.
3. SW 소비자 관점에서 SBOM의 이점
소비자 입장에서 SBOM은 사이버보안 위험을 관리하는 데 도움이 될 수 있다. 예를 들어 소비자는 SW 제품의 생명 주기 전반에 걸친 도입, 통합, 설정, 사용 관리 등에서 SBOM을 활용할 수 있다. 앞서 소개한 세 가지 사용례의 세부적인 이점은 다음과 같다.
(1) 위험 관리 (Risk Management)
소비자는 HW/SW 획득 시점부터 SBOM을 위험관리에 이용할 수 있다. SBOM은 대상의 SW에 무엇이 포함되어 있는지에 대한 투명한 정보를 제공한다. 따라서 소비자가 대상의 도입에 따라 얻게 되는 이득과 위험에 대해 보다 잘 이해할 수 있게 되고, 위험을 더욱 효율적으로 제어하는 방법을 알게 된다.
(2) 취약점 관리 (Vulnerability Management)
HW/SW에서 새로운 취약점은 항상 발견되고 있고, 소비자는 이에 대응해 적절한 조처를 할 수 있어야 한다. 이러한 과정에서도 SBOM은 취약점을 관리하는 데 도움을 줄 수 있다. 몇 가지 예를 들면 다음과 같다.
- 새로운 취약점이 발견되었을 때, 취약점 정보와 함께 SBOM을 사용함으로써 각각의 HW/SW가 새로운 취약점에 의해 어떻게 영향을 받는지를 파악할 수 있다.
- 제조사가 취약점에 대해 조처를 하기 전까지 소비자가 어떻게 취약점에 대처해야 하는지를 SBOM을 통해 파악할 수 있다.
- SBOM은 현재 사용 중인 HW/SW 중 지원 기간이 남아있는 것과 그렇지 않은 것을 사전에 파악하고, 그에 따른 대책을 사전에 마련하는 데 유용하게 쓰일 수 있다.
- 임베디드 기기와 같이 취약점 스캔이 쉽지 않은 경우, SBOM은 이를 보완하기 위한 용도로 사용될 수 있다.
(3) 침해사고 관리 (Incident Management)
SBOM은 침해사고가 발생했을 때 대처하는 데도 사용될 수 있다. 특히 소비자 입장에서 SBOM이 초기 대응을 수행하는 데 유용하다. 침해사고 대응에 있어 체계적인 자료 수집, 연관, 탐지 및 평가 과정 전반에 SBOM이 활용됨으로써 결과적으로는 사고 대응 과정의 전반을 향상할 뿐만 아니라, 초기 대처 미숙에 따른 증거 유실 등을 방지할 수 있다.
위와 같은 방식을 사용하기 위해서는 소비자가 적절히 SBOM을 획득하고 관리할 수 있는 능력을 갖추어야 한다. 이를 위해서 고려해야 할 사항들은 다음과 같다.
- HW/SW 획득(Procurement) 시점에서부터 소비자는 SBOM을 활용할 수 있어야 한다. 이는 소비자가 HW/SW의 도입에 따른 이득과 위험을 평가할 수 있어야 하기 때문이다.
- SBOM은 표준 형식으로 전달되어야 소비자 입장에서 자동화된 배포와 처리가 용이해진다. 이를 위한 주요 표준 형식은 SPDX와 CycloneDX가 있다.
- SBOM과 SW 제품은 유일한 식별자를 통해 정확히 연결되어야 한다. 유일한 제품 식별자는 제품명, 제조사, 버전 넘버 등이 포함된다.
- SBOM에는 필수적인 메타데이터가 포함되어야 한다. (SBOM 생성 방안 참고)
- SBOM에서 알려진 취약점이 발견되었을 때 소비자는 제조사와 소통해 취약점에 적절히 대처할 수 있어야 한다.
- 소비자는 SBOM을 적절히 관리하기 위해 다음과 같은 능력을 갖추어야 한다.
- 검색 : 알려진 취약점 등의 위험을 정확히 식별하고 관리하기 위해 SBOM을 검색할 수 있어야 한다.
- 업데이트 및 관리 : HW/SW의 생명 주기 동안 정확한 최신 정보를 유지할 수 있어야 한다. 관리 용이성을 위해서 이는 자동화되는 것이 바람직하다.
- 안전한 저장소 : SBOM이 악의적인 사용자에 의해 변조되거나 사이버 공격을 위해 악용되는 경우를 방지하기 위해 접근 제어 등 적절한 조치가 이루어져야 한다.
마지막으로, SBOM 관리 측면에서도 부담을 경감시키기 위해 자동화 시스템을 구축하는 것을 권장한다. 예를 들어, 소비자는 SBOM을 ‘보안 정보 및 이벤트 관리(Security information and event management, SIEM)’와 같은 자동화된 도구에 결합해서 활용하거나 커스텀 스크립트 등을 작성해서 분석할 수 있다.
4. SW 생명 주기에 따른 SBOM 활용 방안
SW 생명 주기 전반에 걸쳐 SBOM을 활용한다면 공급망 보안을 강화하는 데 도움이 될 수 있다. 소비자 입장에서의 SW 생명 주기는 획득(Procurement and Acquisition), 계약(Contract), 배포(Deployment), 통합(Integration), 출시(Roll-out), 업그레이드(Upgrade), 수명 종료(End-of-life) 등을 포괄하는 과정이다. 각 과정은 고유한 공급망 보안 위협과 고려 사항이 존재하는데, 이를 해결하는 데 SBOM을 활용할 수 있다. 아래에서는 각 생명 주기별로 발생 가능한 공급망 보안 위협과 SBOM의 활용 방법을 설명한다.(6)
(1) 획득 (Procurement and Acquisition)
SW 획득 과정에서는 위협 평가(Threat Evaluation)가 이루어진다. 위협 평가는 특정 SW와 연계된 위협의 관리뿐만 아니라 전반적인 SW 공급망 관리에 있어서 핵심적인 역할을 수행한다. 그러나 평가 과정 자체에도 위협이 발생할 수 있다.
- 발생할 수 있는 보안 위협
- 위협 평가한 SW와 실제 획득한 SW가 다를 수 있다.
- 최초 위협 평가 시 모든 취약점을 발견하지 못할 수 있다.
- 평가자가 전문성이 부족할 수 있다.
- 평가 결과가 외부 요인에 의해 부정확하거나 불완전할 수 있다.
- SW에 숨겨진 기능을 전부 평가하지 못할 수 있다.
- 임베디드된 요소, 라이브러리, 모듈, 애드온(add-on) 등을 전부 식별하지 못할 수 있다.
- 보안 위협을 해결하기 위한 SBOM의 활용 방법
- SW 위협 평가 시 SBOM의 내용을 실제 평가 대상이 되는 SW와 비교한다. 이 과정을 통해 실제 SW와 SBOM을 통해 평가하는 SW가 동일한지 확인한다.
- 가급적 많은 취약점을 식별하기 위해 SBOM에 명시된 써드파티(third-party) 공급업체를 대상으로도 같은 평가 사항을 적용한다.
(2) 계약 (Contract)
계약 과정에서 보안 위협과 관련된 사항을 명시함으로써 공급망 보안을 강화할 수 있다. 또한 이 과정에서 전달받는 SW의 해시 및 서명 등을 명시함으로써 소비자는 구체적으로 어떤 제품을 전달받는지에 대한 무결성 보장을 요구할 수 있게 된다. 이 과정에서 SW 공급망 보안에 관련된 사항이 불충분하게 명시된다면 소비자 입장의 보안 위험이 증가하는 원인으로 작용한다.
- 발생할 수 있는 보안 위협
- SBOM이 누락된 상태로 SW가 공급될 수 있다.
- SW의 무결성(Integrity)을 검증하기 위한 수단이 명시되지 않을 수 있다.
- 공급자의 침해로 인해 해시, 서명, 제품 등의 무결성이 손상될 수 있다.
- 제품에 포함된 요소가 패키지 서명 및 해시 과정 이전에 변조될 수 있다.
- 보안 위협을 해결하기 위한 SBOM의 활용 방법
- 공급자가 요소별 해시 또는 서명과 같은 방법을 사용해 SW 무결성을 보장한 후, 소비자에게 무결성 검증에 대한 방법을 제공하도록 한다.
- 표준 형식 SBOM을 공급자가 제공하도록 한다.
- 모든 업그레이드에 대해서도 SBOM을 공급자가 제공하도록 한다.
- SW의 변경 사항에 대해서도 SBOM에 포함되도록 한다.
(3) 배포 (Deployment)
배포 과정은 제품 수령(Acceptance of Product), 기능 시험(Functional Testing), 보안 평가(Assurance; Security Testing and Validation) 등의 세부 과정으로 구성된다. 즉, 실제 SW가 현장에 도입되기 이전에 진행되는 테스트 과정과 실제 도입을 포괄하는 단계이다.
- 발생할 수 있는 보안 위협
- (제품 수령) 잘못된 제품이 도착하거나 다른 버전의 제품이 도착할 수 있다.
- (제품 수령) 변조된 제품이 도착할 수 있다.
- (제품 수령) 문서 등 제품의 부가물이 누락될 수 있다.
- (기능 시험) 제품의 기능이 공지 없이 변경될 수 있다.
- (기능 시험) 제품에 알려지지 않거나 검증되지 않은 요소가 포함될 수 있다.
- (보안 평가) 보안 평가 이후 제품의 기능 및 보안에 알려지지 않은 변화가 발생할 수 있다.
- (보안 평가) 보안 평가 과정에서 모든 위협 요소를 식별하지 못할 수 있다.
- 보안 위협을 해결하기 위한 SBOM의 활용 방법
- (제품 수령) 수령한 제품의 무결성을 SBOM을 활용해 검증한다. 검증하기 위한 방법은 SBOM에 명시된 해시, 서명, 인증서 뿐만 아니라 다른 방법 또한 포함할 수 있다.
- (기능 시험) SBOM의 내용을 실제 시험 대상이 되는 제품과 비교 및 검증한다. 검증된 내용은 추후 참고를 위해 저장한다.
- (보안 평가) SBOM에 명시된 데이터 보호, 구현, 지정학적 요구사항 등이 소비자의 요구사항과 일치하는지 검증한다.
(4) 통합 (Integration)
통합 과정에서는 수령한 제품을 실제 운영 환경에 적합하게 변경하는 작업이 수반될 수 있다. 또한, 단순히 운영 환경에 제품을 로딩하기 위해서 뿐만이 아니라 소비자의 요구사항을 충족하기 위해 제품 기능상의 변화가 필요할 수도 있다. 이 과정에서 변경된 부분에 대해 적절한 감사가 누락된다면 SW 공급망 보안상의 문제가 발생하게 된다. 특히 최초 제품 개발 시의 보안상 가정(Security assumption)이 통합 과정에서 변한다면 취약점이 발생할 수 있는 원인이 될 수 있다.
- 발생할 수 있는 보안 위협
- 소비자가 변경한 부분에 대해 문서화가 불충분하거나 공급자가 알지 못할 수 있다.
- 소비자가 변경한 부분에 대해서 테스트가 적절히 이루어지지 않을 수 있다.
- 보안 위협을 해결하기 위한 SBOM의 활용 방법
- 통합 과정에서 변경된 요소에 대해서도 SBOM을 통한 추적이 이루어지도록 한다. 또한 표준화된 SBOM을 통해 공급자에게도 변경된 부분에 대한 정보가 전달될 수 있도록 한다.
(5) 출시 (Roll-out)
출시 과정에서는 최종적으로 변경을 마친 SW가 실제 환경에서 사용될 수 있도록 설치(Install)하는 작업이 이루어진다. 설치 후 성공적으로 실제 환경에 통합이 이루어졌는지를 평가 및 문서화하게 된다. 다른 과정과 마찬가지로, 출시 과정에서도 공급망 보안 문제가 발생할 수 있다.
- 발생할 수 있는 보안 위협
- 의도했던 설정 및 환경과 다른 버전의 SW가 출시될 수 있다.
- 설치 후 평가 및 문서화가 누락되거나 올바르지 않은 내용으로 작성될 수 있다.
- 보안 위협을 해결하기 위한 SBOM의 활용 방법
- 출시되는 SW의 무결성을 보장하기 위해 개발자나 공급자가 무결성을 검사할 방법을 제공한다 (예: 설정 파일 해시 등). 이는 SBOM에 포함되어 전달될 수 있다.
- 제품의 자체 평가 기능(Self-reporting) 외에도 독립적인 수단으로 검증을 수행할 수 있어야 한다. 이 과정에서 표준 형식 SBOM의 내용을 활용할 수 있다.
(6) 업그레이드 (Upgrade)
SW 생명 주기 동안 새로운 버전의 SW가 개발되어 소비자에게 전달될 수 있다. SW가 새로운 버전으로 업그레이드될 때마다 통합, 보안, 상호운용성(Interoperability) 테스트가 수반되어야 한다. 특히, 테스트 과정에서 새로운 기능 또는 보안상 가정(security assumption) 등에 변화가 발생했는지를 식별할 수 있어야 한다.
- 발생할 수 있는 보안 위협
- 의도했던 설정 및 환경과 다른 SW 업그레이드가 제공되거나, 업그레이드 과정 자체에 침해가 발생할 수 있다.
- 업그레이드 이후 불충분한 테스트에 의해 새로 추가된 악성 기능 등이 발견되지 않을 수 있다.
- 업그레이드에 의해 기존의 보안 기능이 변경되거나 비활성화될 수 있다.
- 보안 위협을 해결하기 위한 SBOM의 활용 방법
- SBOM에 포함된 해시 등의 검증 수단을 활용해 전달되는 업그레이드의 무결성을 검사한다.
- 업그레이드 시 제품의 자체 평가 기능 외에 표준 형식 SBOM 등을 활용한 독립적인 보안 평가가 이루어지도록 한다.
- SBOM을 이용해 SW 업그레이드 전과 후의 차이를 비교할 수 있도록 한다 (예: 추가/삭제된 파일, 기본 설정 파일의 변경 등).
(7) 수명 종료 (End-of-Life)
소비자는 다른 SW 공급자로의 이동, 필요 없어짐, 공급자의 수명 종료 정책, 위험관리, 다른 이유 등의 사유로 SW를 시스템에서 제거하고자 할 수 있다. 이 과정에서 단순히 SW가 삭제되는 것뿐만이 아니라, 크리덴셜(Credential) 및 접근 권한 조정과 같은 보안 정책상의 변화가 수반된다.
- 발생할 수 있는 보안 위협
- SW가 완전히 제거되지 않아 관리되지 않는 보안 위험이 발생할 수 있다.
- SW 자체 외에도 크리덴셜 등이 제거되지 않고 남아있을 수 있다.
- 다른 시스템 요소에 대해 제거되는 SW가 가진 의존성으로 인해 보안상의 노출이나 시스템 동작 불능이 발생할 수 있다.
- 보안 위협을 해결하기 위한 SBOM의 활용 방법
- 제거되는 SW가 포함한 구성 요소를 SBOM으로 파악하고, 정상적으로 모든 구성 요소가 제거되었는지 검증할 수 있도록 한다.
- 크리덴셜 등 제거가 필요한 부가 요소가 시스템에 설치된 경로를 SBOM을 통해 분석 및 삭제할 수 있도록 한다.
- SBOM을 통해 설치되었던 SW 패키지가 시스템 전체에 미치는 의존성 영향을 파악하고, SW 제거로 인해 시스템에 생기는 변화가 정상적인 서비스 및 보안에 지장을 주지 않도록 사전 및 사후 점검을 실시한다.
Ⅲ. 맺음말 : SBOM 검증의 중요성
종합하면 SW 개발사, 공급업체, 소비자를 아우르는 SW 공급망 보안 문제를 해결하려면 참여자 모두가 각각 SBOM을 검증하여 결함의 전달자가 되지 않도록 노력하는 것이 중요하다. 최근 미국의 자가 증명(Self Attestation) 제도의 시행과 EU의 사이버 복원력 법이 통과되는 등 주요국의 정책 동향을 감안하면, 침해사고 및 규제에 대한 책임 규명을 위해 앞으로는 제3자 협력사뿐만 아니라 오픈소스 SW에도 SBOM을 통한 SW 구성 요소의 투명성을 요구할 수 있다.
SBOM으로 먼저 검증할 대상은 라이선스 위반이나 취약점의 전이와 같은 제3자 위험이며, 계약 등을 통해 소스 코드나 빌드 SBOM 등을 확보하면 좋겠지만, 그러지 못하는 경우에는 바이너리 분석을 통해서라도 위험을 식별해야 한다. 다만 개별 업무의 특성과 향후 체계 발전을 고려하여 SBOM을 통한 관리체계 자동화는 개발자의 몫으로, SBOM을 통해 식별된 보안 취약점에 대한 검증은 보안 전문가로 분장하는 것을 추천한다.
당장은 오픈소스 프로젝트가 아닌 상용 SW 제품의 경우 SBOM 제공에 따른 간접적인 정보 공개가 SW 제조자의 지식재산권 보호 등의 측면에서 부담될 수 있다. 하지만, SBOM 적용으로 인한 이득이 점차 일반화되면 점점 더 많은 공급자가 알려진 위험이 식별된 상용 SDK 및 오픈소스 라이브러리 등을 제공할 것은 자명하다. 이를 통해 앞으로 우리 SW 소비자와 공급자는 더 나은 신뢰 관계로 발전할 것이다.
※ Reference
- Recommendations for Software Bill of Materials Management (NSA, 2023)
- State of the Software Supply Chain (Sonatype, 2021)
- Recommended Practices Guide for Customer (ESF, 2022)
- An Empirical Study on Software Bill of Materials (Boming 외, 2023)
- Framing Software Component Transparency 3rd Edition (CISA, 2024)
- Software Bill Of Materials (SBOM) 기초 자료 조사 (KAIST 임창일 외, 2023)
![]() |
최윤성 교수 現 고려대학교 SW·AI융합대학원 SW보안학과 교수(강사) 現 경기대학교 AI컴퓨터학부 SW안전보안전공 교수(겸임) 現 민관합동 SW공급망보안 TF 그룹장 (위험관리 및 교육·훈련) 現 과기정통부 SW공급망보안 포럼 정책·산업분과 위원장 現 국가보안기술연구소 미래 보안기술 포럼 전문위원 現 미국 CISA, Member of SBOM Community Working Group ※ SW공급망보안 가이드라인 1.0 저자 (과기정통부, 국정원, 디플정위) |
0개 댓글