SBOM(소프트웨어 자재명세서) 구현을 위한 개방형 표준

SBOM(Software Bill Of Materials; 소프트웨어 자재명세서)은 최종 배포·활용되는 소프트웨어를 구성하는 모든 컴포넌트 명세서를 말한다. 최종 ‘소프트웨어’의 사용자가 누구냐에 따라 그 규모와 활용 형태는 천차만별이다. 수억 명 이상이 쓰는 서비스, 기업용으로 SaaS 형태의 서비스, 개별 장치에 직접 설치해 쓰는 수많은 애플리케이션이 여기에 포함된다.

1. SBOM 개요

사용자가 ‘개발자’일 경우, 최종 제품 개발을 위해 활용하는 제3자가 제공하는 라이브러리나 프레임워크 등도 ‘소프트웨어’ 범주에 포함된다. 이러한 각 소프트웨어를 구성하는 또 다른 모든 소프트웨어의 목록 및 이력을 기록한 것이 SBOM이다. 최종 제품으로서 소프트웨어가 일반 제품처럼 다양한 부품으로 이루어져 있는 것과 같은 개념으로 소프트웨어 공급망 관리(Software SCM)의 일환으로 다뤄지기도 한다.

전체 소프트웨어를 구성하는 수많은 제3의 소프트웨어 중 하나만 해킹당해도 전체 소프트웨어의 보안에 구멍이 뚫리기 때문에 모든 구성 소프트웨어의 무결성이 매우 중요하다. 반대로 해커는 이렇게 겉으로 드러나지 않는 제3의 소프트웨어를 해킹함으로써 이를 활용하는 수많은 소프트웨어를 동시에 공격할 수 있다. 이에, 사이버 보안 분야에서 SBOM이 큰 주목을 받고 있다. 특히 클라우드 컴퓨팅이 일반화되며 데브옵스(DevOps), 마이크로서비스, 컨테이너와 같은 클라우드에 최적화된 개발 방식에서 소프트웨어 공급망 관리(SCM: Supply Chain Management)은 더욱 중요하게 여겨지고 있다. 관련 내용은 이전 리포트에서 다룬 바 있다.

앞으로 대부분 상용 애플리케이션 및 서비스 도입 시 SBOM은 필수 요구사항으로 제시될 것으로 전망되며, 이미 활용 중인 애플리케이션에 대해서도 SBOM을 생성하여 이 안에 포함된 각 모듈을 상시 모니터하는 것은 사이버 보안에서의 중요한 한 축이 될 것이다. 따라서 사용자든 공급자든 SBOM에 대한 준비가 필요하다. SBOM은 미국 정부의 사이버 보안 개선을 위해 매우 중요한 요소로 여겨지고 있으며 정보통신국(NTIA)을 통해 상세히 소개하고 있다. NTIAsms SBOM 표준 관련 상세한 조사연구 자료를 발간하기도 했다.

2. SBOM 표준 포맷

SBOM에 들어가는 정보는 소프트웨어 라이프사이클의 각 단계에서 사용되는 프로세스와 도구를 통해 생성할 수 있다. 여기서 말하는 라이프사이클은 일반적인 소프트웨어 개발 사이클뿐만 아니라 관련 구매/조달, 인증/승인 과정, 그리고 소프트웨어를 공급받은 사용자의 운영도 포함하고 있다.

지식재산권 검토, 조달 검토 및 라이선스 관리 워크플로우 도구, 소프트웨어 공급망 위험 관리, 코드 스캐너, 전처리기, 코드 생성기, 소스 코드 관리 시스템, 바이너리 코드 분석 도구, 버전 관리 시스템, 컴파일러/빌드 도구, 지속적 통합/패키징, 규정 준수 테스트, 패키지 배포, 그리고 앱 스토어 등록 등 전 과정에서 SBOM에 수록될 정보를 생성하거나 수정할 수 있다.

위 그림에서 소프트웨어 패키지 결과물은 “+”로 표시된 부분, 그리고 생성되는 메타 정보는 “>”로 표시한 부분이다. “>”로 표시한 메타 정보가 이 라이프사이클을 통해 만들어지는 SBOM을 구성하는 정보이다. 추가로 제3의 패키지 혹은 라이브러리가 빌드/통합 과정에서 사용되면 해당 제3의 소프트웨어에 대한 명세서(BOM)도 필요하다. 이 경우 “￫”로 표시한 레퍼런스 정보를 생성한다.

단계별 생성되는 메타 정보의 성격도 다양한데, 예를 들어 빌드 단계에서는 컴파일러에 대한 레퍼런스 정보, 테스트 단계에서는 각종 인증 정보가 생성되며, 최종 배포 또는 사용자 설치 단계에서는 공급자 정보, 제품명, 버전, 적용 라이선스, 고유 아이디, 디지털 서명 등을 생성한다. 설치 운영 중 유지보수 단계에서는 소프트웨어의 잠재 혹은 이미 확인한 위험 요소에 대해 기록할 수도 있다. 예를 들면 “CVE-nnnn” 형태의 공통 취약점 노출 정보(Common Vulnerabilities and Exposure)를 기록함으로써 추후 전체 시스템을 안전하게 관리하는 데 도움을 줄 수 있다.

가장 널리 알려진 세 가지의 대표적인 SBOM 포맷은 SPDX(Software Package Data Exchange), CycloneDX, 그리고 SWID(Software Identification)이다.

2.1 SPDX(Software Package Data Exchange)

SPDX는 SBOM을 교환하기 위한 개방형 표준으로 소프트웨어 개발, 보안, 소프트웨어 SCM 커뮤니티의 업계 전문가들이 협력하는 SPDX 오픈소스 프로젝트이다. 리눅스 파운데이션에 지원하는 가장 오랫동안 발전해온 SBOM 형식이며 다양한 도구와 소프트웨어 개발 환경을 지원하는 국제 개방형 표준이다(ISO/IEC 5962:2021). 마이크로소프트, 인텔, 구글, SAP 등 주요 기업들이 지원하고 있다.

SPDX 정보는 최종 소프트웨어 제품, 컴포넌트, 혹은 여러 컴포넌트의 집합, 개별 파일, 심지어 코드 스니펫과도 연관될 수 있다. 즉, 활용할 수 있는 가능한 형태의 모든 소프트웨어에 대해 SBOM 정보를 생성해 서로 교환할 수 있게 한 것이다. 파일 형식도, XML, RDF, XLSX, JSON, YAML 등 여러 타입을 활용할 수 있다. SPDX 사양의 특징은 사람이 읽을 수 있으면서 기계도 판독할 수 있다는 것이다.

2023년 4월 현재 SPDX 버전 2.3까지 나와 있으며 다른 어떤 표준보다도 소프트웨어와 연관된 매우 포괄적인 정보를 담은 사양을 정의하고 있다. SPDX 문서는 다음과 같은 정보로 구성된다.

• 생성정보(Creation Information): SPDX 문서에 최소한 하나 이상 포함해야 하는 정보이다. SPDX 문서 버전 정보, 데이터 라이선스, 작성자 등 필수적인 정보를 포함하며 SPDX 도구의 호환성을 확인하는 데 필요하다.
• 패키지 정보(Package Information): 제품, 컨테이너, 컴포넌트, 업스트림 프로젝트 소스, 아카이브 내 파일 리스트 정보 등을 말한다. 업스트림 프로젝트 소스는 이 패키지에 직접 포함되어 있지는 않지만, 패키지 구성에 영향을 미치는 다른 프로젝트 정보를 말한다. 누군가에 의해 업스트림 프로젝트가 수정되면 이 패키지도 영향을 받게 되기 때문에, 업스트림 프로젝트 변화를 모니터할 수 있어야 한다. 지금처럼 수많은 공개된 오픈소스를 다양하게 활용하는 경우 특히 중요하다.
• 파일 정보(File Information): 해당 파일의 이름, 체크섬(Checksum), 라이선스 및 저작권과 같은 메타 정보를 담고 있다.
• 스니펫 정보(Snippet Information): 다른 소스에 있던 일부 코드 “스니펫”을 “인라인(In-line)” 복사해 그대로 쓰는 경우 이 스니펫 정보도 기록해야 한다.
• 기타 라이선스 정보(Other Licensing Information): SPDX 사양에서 알려진 거의 모든 소프트웨어 라이선스를 망라하고 있지만, 패키지, 파일, 혹은 일부 스니펫에 이런 라이선스로 커버되지 않는 경우가 발생할 수 있다. 이 경우, 기존 리스트에서 지원하지 않는 라이선스 정보를 여기에 기록하면 된다.
• 관계(Relationships): SPDX 문서, 패키지, 파일, 스니펫이 다양한 방식으로 서로 연계될 수 있다. 즉, 두 SPDX 요소 간 관계를 정의할 수 있다. 예를 들어, SPDX의 a 문서가 SPDX x 요소를 설명하는 관계라면 a “DESCRIBES” x라는 관계가 설정된다. “CONTAINS”, “CONTAINED_BY”, “DEPEDENCY_OF” 등 40여 개의 다양한 관계를 정의하고 있다.
• 주석(Annotations): SPDX 문서를 검토하는 중 주로 생성되는 정보이며 검토 결과와 함께 검토한 당사자, 기관, 혹은 검토할 때 사용된 도구 정보 등을 문서의 저작자에게 전달한다. 한편 문서 저작자가 추가정보를 문서에 포함하려 하는데 SPDX 사양에 정의된 어떠한 카테고리에도 부합하지 않을 때도 주석을 활용하여 저장할 수 있다.

새로운 유즈케이스가 계속 나오면서 SPDX는 진화를 거듭하고 있다. 위에서 살펴본 바와 같이 매우 포괄적이며 가능한 많은 경우를 수용할 수 있도록 설계했다. 또한, 생성 및 분석 자동화가 가능하도록 다양한 표현 언어를 지원한다. SPDX의 강점인 포괄성과 유연성이 한편으로는 이를 신속하게 도입하는 데에는 걸림돌이 되기도 한다. 이에 좀 더 보안 및 규정 준수(compliance)에 초점을 맞춰 설계된 CycloneDX가 등장했다.

2.2 CycloneDX

CycloneDX는 사이버 보안을 위한 소프트웨어 공급망 구성 요소 분석에 사용하도록 설계한 SBOM 사양이다. 소프트웨어를 구성하는 컴포넌트 인벤토리 정보, 외부 서비스, 그리고 이들 간의 관계를 명시함으로써, “풀-스택(Full-Stack)” SBOM을 지향한다. 소프트웨어 보안, 특히 웹 애플리케이션 보안 강화를 위해 설립된 OWASP(Open Web Application Security Project)의 오픈소스 프로젝트이다. 이 사양은 다음과 같은 유즈케이스를 지원한다.

• 서비스형 소프트웨어 자재 명세서(SaaSBOM: Software as a Service Bill of Materials)
• 하드웨어 자재 명세서(HBOM: Hardware Bill of Materials)
• 운영 자재 명세서(OBOM: Operations Bill of Materials)
• 취약점 공개 보고서(VDR: Vulnerability Disclosure Reports)
• 취약점 악용 가능성 교환(VEX: Vulnerability Exploitability eXchange)

소프트웨어 보안을 주목적으로 설계되었기 때문에 SPDX보다 상대적으로 가볍고 유즈케이스가 매우 명확한 편이다. 이에 많은 기업과 프로젝트가 CycloneDX의 프로젝트를 지원하고 있다. SPDX를 지원하는 대부분 주요 기업이 CycloneDX를 지원하고 있으며, 깃랩, 깃헙, 레드햇, CNCF(Cloud Natvie Computing Foundation) 등 오픈소스 진영의 전폭적인 지지를 받고 있다. (그림18)

CycloneDX BOM은 다음과 같은 정보로 구성된다.

• BOM 메타데이터 정보: 공급자, 제조사, BOM에서 명시되는 타겟 컴포넌트 정보, BOM 생성에 활용될 수 있는 도구 명세가 포함되어 있다. 또한, BOM 문서 자체의 라이선스 정보도 있다.
• 컴포넌트 정보: 소프트웨어에 포함된 제3자가 개발한 모든 컴포넌트 정보를 포함한다. 작성자 이름, 그룹, 버전 정보는 물론, 패키지 URL, CPE(Common Platform Enumeration), SWID, 암호화 해시 함수로 구성된다. 패키지 URL(PURL)은 해당 컴포넌트의 고유 아이디 및 다운로드 혹은 설치할 수 있는 위치정보를 갖다. CPE는 URI(Uniform Resource Identifier)의 문법을 기반으로 IT 시스템, 소프트웨어 패키지, 운영체제 등 컴퓨팅 자산을 식별하는 표준화된 네이밍 체계다. SWID는 SBOM에 널리 사용되는 표준 소프트웨어 식별정보이며 뒤에서 별도로 설명한다. 암호화 해시 함수로는 SHA 계열 및 BLAKE를 사용한다.
• 서비스 정보: 소프트웨어에서 호출하는 외부 API와 관련된 정보를 말한다. 해당 URI, 인증 요구사항, API 호출을 신뢰할 수 있는 네트워크상의 경계, 그리고 데이터의 흐름 정보 등이 해당한다.
• 종속성(Dependencies): 소프트웨어에 포함된 컴포넌트의 다른 컴포넌트에 대한 종속 정보를 말한다. 종속성 그래프를 통해 직접 종속되는 컴포넌트 간의 관계뿐만 아니라 여러 단계를 거친 종속성을 파악할 수 있다.
• 컴포지션(Compositions): 컴포지션은 구성 요소(컴포넌트, 서비스 및 종속성 관계 포함)와 그 완전성 정도를 나타낸다. 각 컴포지션 합(aggregate)의 상태를 완전, 불완전, 퍼스트 파티만 불완전, 써드 파티만 불완전 또는 알 수 없음으로 표시한다.
• 취약점(Vulnerabilities): 타사 및 오픈소스 소프트웨어로부터 상속된 알려진 취약점과 이의 악용 가능성을 말한다. 구성 요소와 서비스 모두에 영향을 미치는 이전에는 알려지지 않은 취약점도 CycloneDX를 사용하여 공개할 수 있으므로 VEX 및 보안 사례 적용에 적합하다.
• 확장프로그램(Extensions): CycloneDX 오브젝트 모델 자체의 높은 확장성으로 인해 다양한 확장프로그램 개발이 가능하다. 오픈소스 커뮤니티의 적극적인 참여를 통하거나, 또는 특정 산업 도메인에 특화된 프로토타이핑을 통해 신규 유즈케이스에 신속하게 대응할 수 있도록 한다.

CycloneDX 오브젝트 모델은 JSON, XML, 프로토콜 버퍼로 정의하고 있다. 따라서 CycloneDX 생성 또는 분석하려는 조직에서는 이 셋 중 자신들에게 가장 적합한 형식을 활용하면 된다. JSON이나 XML과 같이 널리 사용되는 기술에 기반하기 때문에, 관련 도구도 매우 풍부하다. 2023년 4월 현재 CycloneDX 공식 사이트에 191개의 도구가 소개되어 있다.

2.3 SWID(Software Identification)

SWID는 OASIS(Organization for the Advancement of Structured Information Standards)의 ISO/IEC (19770-2:2015) 표준으로 정의한 소프트웨어 식별정보이다. 소프트웨어 컴포넌트의 라이프사이클에 따라 네 가지 타입의 SWID 태그를 정의하고 있다.

• 프라이머리 태그(Primary Tag): 컴퓨터에 소프트웨어 제품이 설치될 때 이를 식별하고 설치되었음을 알리는 태그이다.
• 패치 태그(Patch Tag): 소프트웨어 패치가 설치될 때 이 패치를 식별하고 패치 했음을 알려주는 태그이다.
• 코퍼스 태그(Corpus Tag): 설치 전 상태의 설치 가능한 소프트웨어 제품을 식별하고 설명하는 태그이다. 코퍼스 태그는 소프트웨어 제품의 설치 패키지 또는 설치 관리자, 소프트웨어 업데이트 또는 패치에 대한 메타데이터를 나타내는 데 사용할 수 있다.
• 추가 태그(Supplemental Tag): 참조된 SWID 태그에 추가정보를 연결할 수 있는 태그이다. 컴퓨터의 소프트웨어 관리 도구가 새로운 소프트웨어 제품을 설치하고 혹은 패치를 적용하는 과정에서 기존 프라이머리 태그, 또는 패치 태그 정보를 손상하지 않고 추가 태그를 연결할 수 있도록 하는 것이다. 이렇게 함으로써 소프트웨어 관리 도구는 자유롭게 기존 태그를 건드리지 않고 필요한 메타데이터를 생성/제공할 수 있다.

SWID 태그 활용은 SBOM에서 소프트웨어 구성 정보 및 이력 관리를 위해 매우 중요하다. CycloneDX의 컴포넌트 정보에도 SWID 태그는 필수 정보로 포함되는 이유이다.

3. SBOM 표준 선택 기준

SPDX, CycloneDX, SWID는 모두 소프트웨어 자재 명세서(SBOM) 정보 교환을 위한 개방형 표준이다. 모두 고유한 장단점이 있으므로 원론적으로는 특정 요구사항에 따라 가장 적합한 표준을 선택해야 한다. 몇 가지 기준으로 이들을 비교 나열한다면 다음과 같다. 물론 이는 필자의 개인적인 의견이다.

• 기술 성숙도 측면: SPDX > SWID > CycloneDX
  SPDX가 가장 오래되었으므로 기술 성숙도가 제일 높다고 볼 수 있다. CycloneDX 사양에 SWID가 들어가 있다. 따라서 기술 성숙도만 놓고 보면 SWID가 CycloneDX보다 더 높다고 보는 것이 타당하다.
• 포괄성(Comprehensiveness): SPDX > CycloneDX > SWID
  적용할 수 있는 유즈케이스 관점에서 SPDX가 가장 포괄적이다. SWID는 SPDX나 CycloneDX에서 활용할 수 있는 소프트웨어 식별 표준이므로 포괄성 측면에서는 가장 낮다고 볼 수 있다.
• 유연성: SPDX > CycloneDX > SWID
  포괄성과 거의 동일하다고 볼 수 있다.
• 적용 대상(유즈케이스)
  SPDX가 가장 포괄적인 범용이라면, CycloneDX는 보안 및 규정 준수에 초점을 두고 있다. SWID는 SBOM의 기본 요건은 갖추고 있으므로 최소한의 유즈케이스에 효율적으로 적용할 수 있다. 다만 SWID는 소프트웨어 식별정보에 국한되어 있으므로 이를 활용한 좀 더 큰 규모의 유즈케이스에서는 SPDX나 CycloneDX 적용이 더 바람직할 수 있다.
• 경량성: SPDX < CycloneDX < SWID
  당연히 범용성이 높은 SPDX가 가장 무겁고 상대적으로 비효율적이다. 여기서 비효율적이란 말은 SBOM 구축 시 더 많은 시간과 노력이 필요할 수도 있다는 뜻이다. SWID는 소프트웨어 식별이라는 기본 기능에 중점을 두고 있으므로 가장 가볍게 구현할 수 있다.
• 도구 및 산업계 지원: 모두 비슷
  SBOM의 중요성에 대한 인식, 그리고 모두 개방형 표준 및 최신 유행 기술 스택을 활용하기 때문에 많은 기업과 프로젝트에서 지원하고 있다.

그렇다면 ‘새로 SBOM을 구현하려 하는데 세 가지 표준 중 무엇을 사용하는 것이 좋겠는가?’라는 질문의 가장 바람직한 답은 무엇일까? 누구나 원론적으로 내릴 수 있는 답인 ‘요구사항을 명확하게 정의하고 이에 맞는 표준을 사용해야 한다.’ 말고 좀 더 현실적인 제안은 할 수 없을까? 만일 한 기업이 SBOM 도입을 적극적으로 검토하고 있다면 내 생각엔 아마도 90% 이상 소프트웨어 보안 강화를 목적으로 할 것이다. 따라서 이 경우라면 우선 CycloneDX를 검토해 보는 것이 현실적이다. CycloneDX의 오브젝트 모델은 앞서 설명한 것처럼 가장 많이 쓰는 기술(JSON, XML) 기반으로 만들어져 있으며, 따라서 활용할 수 있는 도구의 선택폭도 넓다. 상용 도구를 사용하는 경우 비용 지출이 있을 수 있으나 결과물인 SBOM 자체는 개방형 표준이기 때문에, 이를 어떻게 활용하든 제약이 거의 없다는 것도 주요 장점이다.

다수의 보안 전문 회사 중 선택해야 한다면 이들 회사에서 지원하는 SBOM 사양을 상세하게 검토하여 가능한 개방형 표준 범위에서 충분히 지원 가능한가를 살펴보는 것이 중요하다. 솔루션/서비스 벤더가 내세우는 차별화 포인트가 개방형 표준을 조금이라도 벗어난다면 이런 차별화 포인트가 회사의 요구사항 충족을 위한 핵심 요건인지 아닌지를 잘 따져보고 결정해야 한다. 가능한 특정 솔루션에 종속되지 않도록 개방형 표준에 기반을 둔 SBOM 호환성을 최우선 요구 조건으로 하는 전략이 중장기적으로는 바람직하다.

 

참고문헌

• SOFTWARE BILL OF MATERIALS
• NTIA, “Survey of Existing SBOM Formats and Standards”, 2021년
• SPXD
• CycloneDX