2021년 12월 세상을 발칵 뒤집어 놓은 제로데이 취약점이 공개되었습니다. JAVA 기반 로깅 라이브러리인 Log4에서 발견된 Log4Shell 제로데이 취약점입니다. CVE-2021-44228로 CVSS의 심각도 점수는 10점 만점에 10점입니다.

해당 취약점은 최신 버전 업데이트로 방어가 가능합니다. 이를 위해 log4j 사용 여부, 어떤 버전을 어디서 사용하고 있는지에 대한 인지가 필요하지만, 이를 제대로 인지하고 있는 기업은 드물었습니다. 해당 이슈는 소프트웨어 자재명세서(SBOM, Software Bill Of Materials)의 필요성을 보여주었습니다.

SBOM은 최종 고객이 사용하는 소프트웨어, 서비스를 완성하기 위해 활용되는 모든 소프트웨어 정보를 담고 있는 명세서입니다. 사용자가 직접 설치하여 사용하는 전통적인 개념의 패키지 소프트웨어, 운영체제, 다른 소프트웨어 개발을 위해 활용되는 프레임워크나 라이브러리도 포함됩니다. 공급되는 소프트웨어의 구성 목록을 표시하여 공급자와 사용자가 이를 기반으로 의사결정에 활용할 수 있는 환경을 조성하는 것이 목표입니다.

바이든 정부는 누구나 SW 개발 단계에서 사용되는 오픈소스와 라이선스 및 보안 취약점을 알 수 있도록 연방정부와 사업 계약을 맺은 기업이라면 SBOM을 제출하는 것을 의무화 했습니다. 국내 공공기관이나 국방 기업에서는 SBOM 작성을 위한 TF팀을 구성하거나 자체 SBOM 표준을 제정하는 등의 노력을 하고 있습니다. 또한 정부, 공공기관, 기업들이 자체적인 SW 공급망 보안 관리 역량을 갖출 수 있도록 과학기술정보통신부(한국 인터넷진흥원), 국가정보원, 디지털플랫폼정부위원회가 합동으로 “SW 공급망 보안 가이드라인”을 발표하였습니다.

미국의 NTIA(National Telecommunications and Information Administration)에서 발표한 SBOM의 최소 요건은 다음과 같습니다.

1. 데이터 필드
   1. 공급자명, 타임스탬프, 저작권자, 구성요소명, 버전, 고유 식별자, 종속성 관계가 포함되어야 합니다.

2. 자동화 지원

3. 관행 및 프로세스 영역 포함
   1. SBOM을 업데이트하고 제공해야 하는 방법과 시기와 관련된 6가지 요구사항을 정의합니다.

SBOM을 생성하기 위해 통합 구조를 정의하고 최종 사용자 또는 고객과 공유하기 위한 표준으로 공식적으로 인정된 SBOM 표준 2가지를 소개하겠습니다. 이는 SBOM 생성을 위한 구체적이고 통합된 구조를 정의하고 소프트웨어 공급망의 고객 및 사용자와 공유하는 방법도 결정합니다.

1. SPDX

2011년 오픈소스 라이선스 관리 도구로 개발된 리눅스 재단에서 운영하는 프로젝트입니다. 현재는 공유 및 수집을 위한 소프트웨어 패키지와 관련된 정보에 대해 공통 데이터 교환 포맷을 제공합니다. ISO 인증을 취득한 유일한 SBOM 표준으로 ISO에서 정의한 표준화 및 품질 보증 요건을 모두 충족합니다. 인텔, 마이크로소프트, 소니 같은 주요 기업들이 해당 표준을 채택하여 사용하고 있습니다.

해당 표준은 문서 생성 정보, 패키지 정보, 파일 정보, 스니펫 정보, 라이선스 정보, 관계성 정보 및 주석 등의 필드와 데이터로 구성될 수 있습니다.

• 문서 생성 정보: 분석 툴 사용 시 이전/이후 버전과의 호환성을 위해 사용

• 패키지 정보: 제품, 컨테이너 및 구성요소와 같은 개체 설명을 위해 사용

• 파일 정보: 이름, 라이선스, 저작권 정보 등과 같은 메타데이터 포함

또한, XML, RDF, XLSX, JSON, YAML 등 여러 파일 형식을 사용할 수 있으며, 사람이 읽을 수 있으면서 기계도 해석이 가능합니다. 분석 자동화가 가능하도록 다양한 언어를 지원합니다. 하지만 매우 포괄적이며 많은 경우를 수용할 수 있어 초기 설정이 복잡하다는 단점도 존재합니다.

2. 사이클론DX(CDX)

SPDX보다 좀 더 보안 및 규정 준수에 초점을 맞춰 설계되었습니다. 사이버 보안을 위한 소프트웨어 공급망 구성 요소 분석에 용이한 SBOM입니다. 소프트웨어를 구성하는 컴포넌트 인벤토리 정보, 외부 서비스와 관계를 명시합니다. 소프트웨어 보안 강화를 위해 설립된 OWASP의 오픈소스 프로젝트입니다. 소프트웨어 보안을 주목적으로 만들어져 상대적으로 가볍고 명확합니다.

해당 표준은 소프트웨어 구성요소, 버전, 라이선스 정보, 보안 취약점, 종속성이 포함됩니다.

• 보안 취약점: 타사 및 오픈소스 소프트웨어로부터 상속된 알려진 취약점과 악용 가능성

• 종속성: 소프트웨어에 포함된 컴퍼넌트에 대한 종속 정보, 컴포넌트 간의 관계뿐만 아니라 여러 단계를 거친 종속성 파악 가능

CDX를 사용하면 보안 취약점 관리와 라이선스 추적이 용이합니다. 예를 들어, 특정 오픈소스 라이브러리에서 새로운 보안 취약점이 발견되었을 때 해당 라이브러리를 포함하는 모든 소프트웨어 프로젝트를 식별할 수 있습니다. 이를 통해 해당 취약점에 노출된 모든 애플리케이션을 즉시 파악하고, 업데이트 등 필요한 보안 조치를 취할 수 있습니다. 또한 모든 구성 요소의 라이선스 정보를 제공해 주기 때문에 특정 라이선스 요건을 준수하고 있는지 파악할 수 있습니다. 필요한 정보만을 제공하여 사용자가 쉽게 이해하고 사용할 수 있습니다. 하지만 ISO 표준화를 받지 못하였고, SPDX에 비해 제공하는 정보의 범위가 제한적이라는 단점이 있습니다.

SBOM 표준마다 장단점이 명확하게 존재하므로 특정 요구사항에 따라 적합한 표준을 선택하는 것이 중요합니다. 기술 성숙도, 포괄성, 유연성, 적용 대상, 경량성 등 다양한 기준으로 요구사항을 명확하게 정의하고 이에 맞는 표준을 선택해야 합니다. 악의적인 행위자가 공격 벡터를 더욱 빠르고 활발하게 악용하고 있으므로 소프트웨어 공급망의 투명성과 보안을 관리하는 SBOM의 필요성이 지속적으로 대두되고 있습니다.