목차
주제> SW공급망 보안을 위한 SBOM 규격의 취약점 정보 속성에 대하여
* 최근 과학기술정보통신부(한국인터넷진흥원), 국가정보원, 디지털플랫폼정부위원회가 합동으로 '소프트웨어(SW) 공급망 보안 가이드라인 1.0'을 공개하여 많은 기업과 기관들이 공급망보안과 함께 SBOM에 대한 내부 논의가 이뤄지고 있을 것으로 생각한다.
* 그러나 공개된 SW공급망 보안 가이드라인 1.0에 정의된 SBOM 표준 규격에 취약점 정보속성을 통합하는 것은 SW개발사, 공급사, 운영가들 모두가 잘 이해해야 하는 부분이 있다.
* 이를 참고하여 개발사, 공급사, 운영자가 효율적인 SW공급망 보안이 우리나라에 정착되길 기원한다.
SBOM 규격> 국제 및 국내 SBOM 표준 포멧의 규격
* SBOM은 SW에 존재하는 오픈소스에 대한 정보들을 담고 있으며, 국제적으로 알려진 표준 포멧으로는 CycloneDX, SPDX, SWID가 대표적이다.
* 우리나라에서는 TTA(정보통신단체표준)에서 오픈소스 SBOM 거버넌스 관리 지침”(TTAK.KO-11.0322)을 통해 SBOM규격을 표준화하고 NIS(국가정보원)가 SW공급망 보안 가이드라인 1.0을 통해 NIS-SBOM 규격을 공개하고 있다.
* TTA가 제시하는 SBOM의 속성규격은 20개로 구성되어 있으며, (19), (20) 항목으로 취약점 정보를 표시하고 있으며, NIS SBOM속성 규격은 15개로 구성되어 있으며, (13), (14), (15)항목에 취약점 정보를 표시하는 속성 규격이 명시되어 있다.
이슈 사항> SBOM 속성규격에 취약점 정보를 포함시키는 것은 SBOM을 운영하는데 비효율적일 수 있다.
* SBOM의 규격에 취약점 속성을 고정으로 규격화하는 것은 SBOM을 운영관리하는 단계에서 약간의 문제점을 발생시킬수 있다.
* SBOM의 생성 및 변경관리 주기와 취약점 정보가 알려지는 주기를 비교해볼 때, 대부분의 SBOM 생성은 SW의 최초 개발시가 대부분이며 그나마 SBOM을 업데이트 하는 기업이나 기관이 얼마나 될 것인가?
* 즉, SBOM 규격에 취약점 속성을 넣는 다는 것은, 어떤 취약점이 알려질때 마다 보유하고 있는 모든 SBOM을 업데이트하겠다는 얘기다.
* 또는, 운영하는 모든 SW의 SBOM 정보와 취약점 정보를 실시간으로 생성 및 변경관리 할수 있는 환경이라면 SBOM규격에 취약점 속성을 넣는 것은 바람직할수 있다. (그래야 알려진 오픈소스 또는 3'rd Party SW의 보안 취약점 존재 여부를 수시로 알수 있을테니까 말이다)
* 그렇다면, 모든 기업과 기관이 모든 SW에대한 SBOM의 생성 및 유지관리를 실시간으로 할수 있겠는가? 하는 현실적인 문제를 생각해볼 수 필요가 있다.
* 따라서, SBOM규격에는 오픈소스에 대해 가능한 정보를 가능한 많이 담을 수 있는 속성들로 구성하고 수시로 알려지는 취약점에 대한 정보는 별도의 정보 저장소를 이용하여 SBOM과 취약점 정보를 분리하는 것이 SW공급망 보안을 위한 SBOM운영관리를 효과적으로 할수 있다고 판단된다.
선진 사례> 그렇다면, 선진사례의 SBOM규격은 어떻게 구성되어 있는가?
2011년 개발이 시작된 SPDX, 2017년 개발시작된 CycloneDX
* 국제적으로 잘 알려진 SBOM포멧은 SPDX와 CycloneDX가 대표적인데, SPDX는 리눅스재단이 2011 개발시작하여 현재 2.2버전까지 개선작업이 이뤄졌으며, CycloneDX는 OWASP에서 2017년 프로젝트로 시작하여 개발되어 현재 1.5버전이 공개되어 있다.
* SPDX와 CycloneDX의 SBOM 규격은 약간 다른면이 있지만, SW공급망보안의 구심점 역할을 한 미국 상무부 산하의 NTIA(National Telecommunications and Information Administration)가 제시한 SBOM의 필수 요소 7가지를 기본적으로 포함하고 있으며 목적에 따라 SBOM 명세에 다양한 속성들을 추가하고 있다.
* NTIA가 제시한 SBOM의 필수요소 7가지 사항은 아래표와 같다.
| 속성명 | 속성 설명 |
|---|---|
| Component Name | 소프트웨어 구성 요소의 이름 |
| Version of the Component | 구성 요소의 버전 |
| Unique Identifier | 구성 요소의 고유 식별자 |
| Dependency Relationship | 구성 요소 간의 의존 관계 |
| Author of the SBOM Data | SBOM 데이터를 작성한 사람 또는 조직 |
| Supplier of the Component | 구성 요소의 공급업체 |
| Timestamp | SBOM 데이터가 생성된 시간 |
CycloneDX와 SPDX의 SBOM 규격
* CycloneDX와 SPDX의 최신 버전을 기준으로 SBOM 규격을 살표 보면 아래와 같다.
* 서로 다른 조직이 SBOM규격을 만들다보니 자신들의 목적에 부합되도록 발전시키고 있으며 기본적인 사항만 비교하면 아래와 같다.
| 구분 | SPDX | CycloneDX |
|---|---|---|
| 주관 | 리눅스 재단(The Linux Foundation) | OWASP(Open Web Application Security Project) |
| 중점 | 라이선스 컴플라이언스 중심의 SBOM 표준 | 보안 중심의 SBOM 표준으로, 보안 취약점 정보와 의존성 정보를 포함 |
| 형식 | RDF, Tag-Value, JSON, YAML 등 | JSON, XML, Protocol Buffers 등 |
| 취약점 정보 | 보안 취약점 정보를 직접 포함하지 않으며 외부 참조를 통해 취약점 정보를 간접적으로 제공 가능하게 규격을 구성 | 취약점 정보 섹션을 포함하여 보안 취약점을 직접 문서화 하거나 자동화된 도구와 연계하여 지속적으로 갱신가능 하도록 규격을 구성 |
SBOM 규격과 취약점 정보의 분리구성이 SBOM 운영관리에 효과적이다.
* SBOM의 생성주체와 생성시점을 생각해볼때, SBOM규격에 취약점 정보 속성을 포함시키는 것은 수시로 알려지는 취약점 정보에 따라 SBOM을 갱신하지 않으면, 해당 SBOM의 취약점 속성은 신규로 알려진 취약점이 반영되지 않은 SBOM을 보유하게 된다.
* 따라서, SBOM을 실시간으로 생성 및 유지관리할수 없는 환경이라면 SBOM의 규격에서 취약점 정보 속성을 분리한 구성이 SBOM 유지관리 관점에서 효과적이다.
* CycloneDX SBOM는, 1.5버전에서는 외부참조(Compononts > External References)를 지원하여 SBOM 내에 취약점 정보를 직접 포함하지 않고도, 최신 취약점 데이터를 가리키는 링크를 제공하기도 한다.
* SPDX SBOM의 경우도, 외부참조(External References)를 제공하여 취약점 데이터를 연동할수 있도록 하고 있다.