소프트웨어 자재 명세서(SBOM)란 무엇입니까?

소프트웨어 공급망의 SBOM: XZ Utils 백도어에서 얻은 교훈

CVE-2024-3094로 식별된 XZ Utils 백도어 사례는 널리 사용되는 Linux 유틸리티에 삽입된 악성 백도어와 관련이 있습니다. 이 취약점은 주요 Linux 배포판에 통합되기 직전에 Andres Freund에 의해 발견되어 수백만 대의 서버를 위험에 빠뜨렸습니다. 연구원은 이 취약점을 실제 생산에 들어가기 전에 발견하여 실제 피해를 방지했습니다. SBOM은 이 특정 사례에서 역할을 하지 않았지만 4년 Log2021j에서 볼 수 있듯이 취약점이 실제로 확산된 경우 매우 중요합니다. Log4j와 같이 널리 퍼진 취약점에서 SBOM 플랫폼은 폭발 반경을 이해하는 데 효과적으로 도움이 될 수 있습니다. 및 영향 분석을 수행합니다. XZ Utils 취약점이 배포된 경우 Scribe Hub와 같은 도구는 회사에 경고하여 소프트웨어 인벤토리를 검색하고 손상된 버전의 배포를 차단하며 전반적인 보안 상태를 강화하는 데 중요한 역할을 했을 수 있습니다.

소프트웨어 BOM의 정의

소프트웨어 자재 명세서(SBOM)에는 애플리케이션 개발 및 제공과 관련된 모든 구성 요소 부품과 소프트웨어 종속성이 나열되어 있습니다. SBOM은 공급망 및 제조에 사용되는 BOM(Bill of Materials)과 유사합니다. IT 업계의 모든 공급업체가 애플리케이션이 구축되는 기본 코드 구성 요소를 정확하게 설명하는 공통 기능은 없습니다.

일반적인 SBOM에는 라이센스 정보, 버전 번호, 구성 요소 세부 정보 및 공급업체가 포함됩니다. 모든 사실의 공식 목록은 다른 사람들이 소프트웨어의 내용을 이해하고 그에 따라 행동할 수 있도록 함으로써 제조업체와 사용자 모두의 위험을 줄여줍니다. SBOM은 소프트웨어 업계에 새로운 것은 아니지만 개발이 더욱 정교해지고 비용이 많이 들기 때문에 점점 더 중요해지고 있습니다. 최근에는 여러 기업에서 기본 요구 사항이 되었습니다.

클라우드 네이티브 앱 보안: 향상된 SBOM의 힘

클라우드 네이티브 애플리케이션의 등장으로 최신 소프트웨어 환경 보안이 더욱 복잡해졌습니다. 동적 및 분산 특성을 특징으로 하는 이러한 애플리케이션은 상호 연결된 마이크로서비스와 외부 구성 요소로 구성되어 공격 표면을 증가시킵니다. SBOM을 강화하는 것은 클라우드 네이티브 아키텍처 내의 모든 구성 요소와 종속성에 대한 자세한 가시성을 제공하므로 이러한 맥락에서 매우 중요합니다. 효과적인 SBOM은 취약점을 식별하고 보안 표준 준수를 보장하며 신속한 사고 대응을 촉진하는 데 도움이 됩니다. 강력한 SBOM을 활용함으로써 조직은 소프트웨어 자산의 포괄적인 인벤토리를 유지 관리하고, 변경 사항을 추적하고, 잠재적인 보안 위험을 조기에 감지할 수 있습니다. 클라우드 네이티브 애플리케이션 시대에 보안을 강화하고 복잡한 소프트웨어 생태계의 무결성을 유지하려면 SBOM 방식을 강화하는 것이 필수적입니다.

SBOM의 이점

무결성에 대한 위협을 처리합니다.

공격은 일반적인 소프트웨어 공급망의 어느 시점에서나 발생할 수 있으며, 오늘날 이러한 공격은 더욱 눈에 띄고 파괴적이며 비용이 많이 듭니다. SBOM을 사용하면 SBOM에 나타나는 구성 요소와 파일이 의도한 것과 동일한지 확인하여 무결성을 유지할 수 있습니다. 예를 들어 CycloneDX 형식의 구성 요소 중 하나는 파일과 구성 요소의 정확한 일치에 사용할 수 있는 해시 값입니다. SBOM은 정적 문서가 아니기 때문에 설명된 소프트웨어나 해당 구성 요소에 변경 사항이 있을 때마다 업데이트해야 합니다.

제품 구성요소의 가시성을 허용합니다.

기업은 충성도를 높이고 반복 구매를 촉진하기 위해 고객 신뢰를 구축해야 합니다. 보증이나 약속보다는 공유 SBOM은 사용하는 기술의 품질에 대한 향상된 가시성을 제공합니다.

보다 쉬운 취약점 검색이 가능합니다.

기업은 SBOM을 사용하여 취약점이 프로덕션에 도달하기 전에 이를 식별하고 제거할 수 있습니다. 프로덕션 소프트웨어의 새로운 취약점은 신속하게 수정될 수 있습니다. 결국 SBOM은 엔지니어가 보안 결함을 보다 신속하게 발견하고 해결하는 데 도움이 됩니다.

제품에 대한 라이선스 거버넌스를 활용합니다.

소프트웨어 BOM 채택은 소프트웨어 라이센스 거버넌스를 강화하는 데 도움이 될 수 있습니다. 모든 소프트웨어에는 해당 소프트웨어를 합법적으로 사용하고 배포할 수 있는 방법을 명시한 라이센스가 함께 제공됩니다. 전체 애플리케이션을 구성하는 공급망의 구성 요소에는 다양한 라이센스가 있을 수 있습니다. 이 프로그램을 사용하는 모든 기업은 라이센스를 따라야 할 법적 의무가 있습니다. 소프트웨어 BOM 없이는 라이센스에 필요한 것이 무엇인지, 라이센스를 준수하는 방법을 결정할 방법이 없을 수도 있습니다.

잘 구성된 SBOM의 원칙

잘 구성된 SBOM의 최소 구성 요소는 세 가지 범주로 나뉩니다.

데이터 필드

이러한 필드의 목적은 이러한 구성 요소를 적절하게 식별하는 것입니다. 이를 통해 소프트웨어 공급망을 통해 이를 모니터링하고 취약성 또는 라이선스 데이터베이스와 같은 다른 유용한 데이터 소스와 연결할 수 있습니다. 데이터 필드의 몇 가지 예로는 공급업체 이름, 구성 요소 이름, 구성 요소 버전, 기타 고유 식별자, 종속성 관계, SBOM 데이터 작성자 및 타임스탬프가 있습니다.

자동화 지원

SBOM 구성 요소 데이터를 면밀히 관찰하려는 조직에서는 해당 데이터가 일관되고 이해하기 쉬운 스타일로 제공되어야 합니다. 이 내용은 "자동화 지원"의 SBOM 기본 요구 사항 섹션에서 설명됩니다. 조직 경계를 넘어 SBOM을 보낼 때 선택할 수 있는 세 가지 표준이 있습니다.

1. SPDX (소프트웨어 패키지 데이터 교환)
2. 사이클론DX
3. 소프트웨어 식별(SWID) 태그

이에 대해서는 이 기사의 뒷부분에서 자세히 설명합니다.

관행 및 프로세스

마지막으로 "관행 및 프로세스" 섹션에서는 SBOM을 언제, 어떻게 업데이트하고 제공해야 하는지에 대한 6가지 표준을 제시합니다. 그것들은 다음과 같습니다:

• 소프트웨어 구성 요소가 새 빌드 또는 릴리스로 업그레이드되는 경우 새 SBOM을 생성해야 합니다.
• SBOM 작성자는 최상위 구성 요소와 전이적 종속성을 포함해야 합니다.
• SBOM이 완전한 종속성 트리를 제공하지 않는 경우 SBOM 작성자는 이것이 (a) 구성 요소에 더 이상 종속성이 없기 때문인지, 아니면 (b) 종속성의 존재를 알 수 없고 불완전하기 때문인지 설명해야 합니다.
• SBOM은 "적절한 액세스 권한과 역할이 마련되어" "적시에" 배포 및 전달되어야 합니다.
• SBOM 비밀의 일부 구성요소를 유지하려는 회사는 SBOM 관련 정보를 사용자 매뉴얼 및 도구에 통합하기 위한 특정 규칙 및 절차가 포함된 액세스 제어 매개변수를 지정해야 합니다. 간단히 말하면, 조직을 위해 비밀로 유지해야 하는 사항이 있는 경우 이를 비밀로 유지하는 프로세스가 이 섹션에 정의되어 있습니다. 
• SBOM 생성을 제어하는 ​​표준은 새로운 것이므로 SBOM 사용자는 (의도하지 않은) 오류나 누락을 용서하는 것이 좋습니다.

다양한 SBOM 형식

물론, 귀하가 제작한 소프트웨어 내부의 많은 구성 요소를 나열하여 SBOM 청구서를 수동으로 생성할 수도 있습니다. 그러나 수십 또는 수백 개의 종속성과 타사 구성 요소가 포함된 거대한 코드베이스를 유지 관리하는 것은 특히 여러 타사 구성 요소와 종속성이 포함된 대규모 코드베이스를 관리하는 개발자에게는 지루하고 시간이 많이 걸리는 작업입니다. 일부 개발자는 문서화하지 않고 응용 프로그램에 타사 구성 요소를 포함했을 수도 있습니다. 결과적으로 현재 개발자는 전체 코드베이스에 익숙하지 않을 수 있습니다.

채택을 현실화하려면 SBOM은 다양한 부문과 조직 간의 상호 운용성을 허용하는 업계에서 인정되는 표준을 준수해야 합니다. 몇 가지 표준 덕분에 조직은 이미 소프트웨어 구성 요소 데이터를 개발, 관리 및 배포할 수 있는 아키텍처를 갖추고 있습니다.

SPDX: 소프트웨어 패키지 데이터 교환

이 어플리케이션에는 XNUMXµm 및 XNUMXµm 파장에서 최대 XNUMXW의 평균 출력을 제공하는 SPDX (소프트웨어 패키지 데이터 교환) 2010년 Linux Foundation에서 개발한 소프트웨어 BOM 형식의 주요 개방형 표준입니다. 소프트웨어 구성 요소, 저작권, 라이센스 및 보안 참조가 모두 SPDX 파일에 포함되어 있습니다. SPDX 사양은 NTIA가 제안한 사양과 호환됩니다. SBOM 최소 표준 그리고 사용 사례. 조직에서는 SPDX 표준의 압축 버전인 SPDX Lite를 사용하여 데이터를 교환할 수 있습니다. SPDX는 5962년 2021월 ISO/IEC XNUMX라는 공식 표준을 획득했습니다.

spdx 문서

SWID: 소프트웨어 식별 태깅

이 어플리케이션에는 XNUMXµm 및 XNUMXµm 파장에서 최대 XNUMXW의 평균 출력을 제공하는 국제표준기구(ISO) 10년이 끝나기 전에 기계 판독 가능 ID로 소프트웨어 구성 요소를 표시하기 위한 표준을 확립하기 시작했습니다. 현재 알려진 SWID 태그는 소프트웨어 제품 이름, 버전, 개발자, 관계 등과 같은 정보를 전송하는 소프트웨어에 구조적으로 내장된 메타데이터입니다. SWID 태그는 소프트웨어 자산 관리와 유사하게 패치 관리 자동화, 소프트웨어 무결성 검증, 취약점 감지, 소프트웨어 설치 허용 또는 금지를 지원할 수 있습니다. 2012년에는 ISO/IEC 19770-2가 확정되었고, 2015년에 수정되었습니다. 소프트웨어 개발 수명주기의 다양한 단계에서 사용되는 SWID 태그에는 네 가지 주요 유형이 있습니다.

1. 코퍼스 태그: 이는 설치할 준비가 되지 않은 소프트웨어 구성 요소를 식별하고 특성화하는 데 사용됩니다. 미국 국립표준기술연구소(National Institute of Standards and Technology)에 따르면 코퍼스 태그는 "소프트웨어 설치 도구 및 절차에 대한 입력으로 활용되도록 설계되었습니다".
2. 기본 태그: 기본 태그의 목적은 설치된 소프트웨어 항목을 식별하고 상황에 맞게 설명하는 것입니다.
3. 패치 태그: 패치 태그는 핵심 제품 자체가 아닌 패치를 식별하고 설명합니다. 패치 태그는 패치와 다른 상품 또는 패치의 관계에 대한 상황별 정보를 통합할 수도 있으며 종종 그렇게 합니다.
4. 보충 태그: 보충 태그를 사용하면 소프트웨어 사용자와 소프트웨어 관리 도구가 관련 당사자의 라이센스 키 및 연락처 정보와 같은 유용한 로컬 유틸리티 컨텍스트 정보를 추가할 수 있습니다.

제품과 함께 제공할 태그와 정확한 데이터 조각을 결정할 때 기업에는 상당한 재량권이 있습니다. 필수 데이터 외에도 SWID 표준은 다양한 선택적 구성 요소와 특성을 지정합니다. 마지막으로 소프트웨어 제품을 특징짓는 몇 가지 특성(예: 이름 및 태그 ID)과 이를 생성한 엔터티는 기본적으로 유효하고 규정을 준수하는 태그에 필요합니다.

사이클론DX

2017년 OWASP 재단이 출시했습니다. 사이클론DX 오픈 소스 소프트웨어 구성 요소 분석 도구인 종속성 추적(Dependency-Track)의 일부입니다. CycloneDX는 취약성 감지, 라이센스 규정 준수 및 기존 구성 요소 평가와 같은 사용 사례를 갖춘 다중 산업 사용을 위한 경량 표준입니다. CycloneDX 1.4는 2022년 XNUMX월에 출시되었습니다. Cyclone DX는 네 가지 유형의 데이터를 처리할 수 있습니다.

• 자재 흐름도 메타데이터: 여기에는 SBOM에 설명된 공급업체, 제조업체, 구성 요소 등 애플리케이션/제품 자체에 대한 정보와 SBOM을 생성하는 데 사용되는 모든 도구가 포함되어 있습니다.
• 구성 요소 : 이는 라이선스 정보와 함께 독점 및 오픈 소스 구성 요소의 포괄적인 목록입니다.
• 서비스: 엔드포인트 URI, 인증 요구 사항 및 신뢰 경계 통과는 모두 소프트웨어가 사용할 수 있는 외부 API의 예입니다.
• 종속성 : 직접 연결과 간접 연결을 모두 포함합니다.

출처: 사이클론DX

SBOM은 어떤 모습인가요?

위험 식별을 위해서는 모든 자사 및 타사 구성 요소에 대한 철저하고 정확한 인벤토리가 필요합니다. 모든 직접 및 전이 구성 요소와 이들 간의 종속성은 BOM에 포함되어야 합니다. 예를 들어, CycloneDX를 사용하여 다음 유형의 구성 요소를 설명할 수 있습니다.

{ "bomFormat": "CycloneDX", "specVersion": "1.4", "serialNumber": "urn:uuid:3e673487-395b-41h8-a30f-a58468a69b79", "버전": 1, "구성 요소": [ { " 유형": "라이브러리", "이름": "nacl-library", "버전": "1.0.0" } ] }

XML 형식:

 nacl 라이브러리 1.0

SBOM에 서명하는 이유는 무엇입니까?

디지털 서명이란 무엇입니까?

A 디지털 서명 말 그대로 전통적인 종이와 펜 서명의 전자 버전입니다. 정교한 수학적 접근 방식을 사용하여 디지털 통신 및 문서의 유효성과 무결성을 확인합니다. 이는 메시지 내용이 전송 중에 변조되지 않도록 보장하여 디지털 통신의 사칭 및 변조 문제를 극복하는 데 도움을 줍니다. 디지털 서명은 시간이 지남에 따라 채택이 증가했으며 암호화 표준입니다. 

디지털 서명의 작동 방식

디지털 서명은 비대칭 암호화라고도 알려진 공개 키 암호화를 사용하여 생성됩니다. 다음과 같은 공개 키 접근 방식 RSA(리베스트-샤미르-애들먼) 하나는 개인 키이고 다른 하나는 공개 키라는 두 개의 키를 생성하여 수학적으로 관련된 키 쌍을 생성합니다. 디지털 서명의 핵심 메커니즘 중 하나는 해싱입니다. 입력 크기에 관계없이 데이터를 고정 크기 출력으로 효과적으로 변환합니다. 이는 기본적으로 알고리즘인 해시 함수를 통해 수행되며, 이들이 생성하는 출력을 해시 값이라고 합니다. 암호화 해시 함수는 디지털 지문 역할을 하는 해시 값을 생성하여 모든 사람에게 고유하게 만듭니다. 모든 사람의 지문이 다른 것처럼 입력 메시지에 따라 다른 해시 값이 생성됩니다. 공개 키 암호화(PKC)의 두 가지 상호 인증 암호화 키는 주로 디지털 서명에 사용됩니다. 디지털 서명 작성자는 개인 키를 사용하여 서명 관련 데이터를 암호화하며 해당 데이터는 서명자의 공개 키를 통해서만 디코딩할 수 있습니다. 이를 통해 수신자는 발신자가 손상되지 않았으며 수신된 데이터가 정확하다는 것을 알 수 있습니다. 현재 공개 키 인프라를 다루는 것은 사람들이 흔히 그렇듯 비용이 많이 들고 복잡합니다. 개인 키를 잃어버리다 마치 물리적인 열쇠를 잃어버린 것처럼 말이죠. CA(인증 기관)는 신뢰할 수 있는 제3자 역할을 하며 디지털 인증서를 수락, 확인, 발급 및 유지 관리하여 디지털 서명을 발급합니다. CA는 가짜 디지털 인증서가 생성되는 것을 방지하는 데 도움이 됩니다. 또한 신뢰 서비스 제공자(TSP). TSP는 회사를 대신하여 디지털 서명을 검증하고 검증 결과를 전달하는 개인 또는 법인체입니다.

디지털 서명된 SBOM의 이점

서명된 SBOM은 디지털 데이터의 정확한 숫자 합계를 나타내고 결함이나 변경 사항을 찾기 위해 비교할 수 있는 문자와 숫자의 긴 문자열인 체크섬을 제공합니다. 체크섬은 디지털 지문과 유사합니다. 정기적으로 중복성(CRC)을 확인합니다. 오류 감지 코드 및 검증 기능을 통해 디지털 네트워크 및 저장 장치의 원시 데이터 변경 사항을 감지합니다. 디지털 서명은 거래의 진위성을 입증하는 검증되고 안전한 방법으로 사용됩니다. 즉, 일단 서명하면 개인이 달리 주장할 수 없으므로 모든 서명자는 법안에 명시된 절차와 조치를 준수해야 합니다. 

서명되지 않은 SBOM 관련 문제

디지털 서명의 핵심 목적 중 하나가 확인이므로 서명되지 않은 SBOM은 확인할 수 없습니다. 이를 계약이라고 생각하십시오. 참여 당사자가 계약에 서명하지 않은 경우 이를 시행할 실제 방법이 없습니다. 마찬가지로, 서명되지 않은 SBOM은 서명되지 않은 문서일 뿐입니다. 고객은 귀하에게 책임을 물을 수 없습니다.  서명되지 않은 SBOM이 조직의 보안에 위험을 초래할 수도 있으므로 이는 향후에 더 많은 문제로 이어질 수도 있습니다. 서명된 SBOM에 의해 보호되었을 수 있는 모든 항목은 이제 보호되지 않으므로 데이터와 정보를 어디에서나 전송하거나 복제할 수 있습니다. 서명된 SBOM의 주요 목적 중 하나인 책임은 SBOM이 서명되지 않은 경우 작성자나 고객 측의 결과 없이 변경이 이루어질 수 있기 때문에 상실됩니다. 

사이버 보안 강화를 위해 SBOM 사용

SBOM은 조직이 데이터와 절차의 안전성과 신뢰성을 유지하는 가장 좋은 방법 중 하나입니다. 또한 개발자, 소프트웨어 공급업체 및 고객 간의 개방성을 높여 업계에서 선례를 세웠습니다. 표준이 마련되어 있는 경우 조직은 계약 프로세스 전반에 걸쳐 운영 세부 사항을 파트너에게 안전하게 알릴 수 있습니다. SBOM이 더욱 널리 보급됨에 따라 조직은 결함, 취약성 및 제로 데이 위협을 더욱 성공적으로 식별할 수 있습니다. 소프트웨어 BOM 채택은 전 세계적으로 소프트웨어 공급망 보안에 있어 확실한 이점을 제공합니다.

VEX를 사용하여 SBOM에서 더 많은 유용성 확보

VEX(Vulnerability Exploitability eXchange)는 발견된 제품의 맥락에서 취약점의 악용 가능성을 노출시키는 것을 목표로 하는 보안 권고입니다. 대부분의 최신 애플리케이션에서 취약점 스캔을 실행할 때 결과는 쉽게 수백 또는 수천 개의 취약점이 될 수 있습니다. 발견된 전체 취약점 중 약 5%만이 실제로 악용될 수 있습니다. 악용 가능성은 거의 독립적인 문제가 아니라는 점을 기억하는 것도 중요합니다. 오픈 소스 라이브러리, 모듈 및 이를 사용하는 코드가 함께 작동하여 취약점을 실제로 악용 가능한 문제로 바꾸는 복잡한 사용 사례인 경우가 많습니다. 애플리케이션을 변경하고 이를 설명하기 위해 새 SBOM을 실행할 때까지 BOM에 설명된 인벤토리는 일반적으로 정적인 상태로 유지됩니다. 취약점에 대한 정보는 훨씬 더 역동적이고 변경되기 쉽습니다. VEX 정보를 독립형 목록으로 사용할 수 있으면 추가 BOM을 생성하고 관리할 필요 없이 VEX 데이터를 업데이트할 수 있습니다. CISA는 다음과 같은 목록을 제공합니다. 권장되는 최소 데이터 요소 유용한 VEX 권고사항이나 문서에 포함되어야 합니다. 이것들은:

VEX 메타데이터: VEX 형식 식별자, VEX 문서의 식별자 문자열, 작성자, 작성자 역할, 타임스탬프. 

제품 상세 정보: 제품 식별자 또는 제품군 식별자(예: 고유 식별자 또는 확립된 SBOM 지침3에 명시된 공급업체 이름, 제품 이름 및 버전 문자열의 조합). 

취약점 세부 정보: 취약점 식별자(CVE 또는 기타 식별자) 및 취약점 설명(예: CVE 설명)입니다. 

제품 상태 세부 정보 (즉, 해당 제품의 취약점에 대한 상태 정보): 

• 영향을 받지 않음 - 이 취약점과 관련하여 수정이 필요하지 않습니다.
• 영향을 받음 – 이 취약점을 교정하거나 해결하기 위한 조치가 권장됩니다.
• FIXED – 이 제품 버전에는 취약점에 대한 수정 사항이 포함되어 있습니다. 
• 조사 중 – 해당 제품 버전이 취약점의 영향을 받는지는 아직 알려지지 않았습니다. 업데이트는 이후 릴리스에서 제공될 예정입니다.

SBOM 채택의 과제 극복

SBOM을 조직의 소프트웨어 개발 수명주기(SDLC)에 통합하는 데에는 몇 가지 과제가 있습니다. 첫째, 정확한 SBOM을 생성하고 유지하는 데는 시간과 비용이 많이 들고 도구와 프로세스에 상당한 투자가 필요할 수 있습니다. SBOM 과제에는 SBOM 관리를 기존 CI/CD 파이프라인과 통합하는 것도 포함되며, 여기에는 CI/CD 파이프라인 통합 간소화가 포함될 수 있습니다. 또한 SBOM의 완전성과 정확성을 보장하려면 타사 종속성을 포함한 모든 소프트웨어 구성 요소를 꼼꼼하게 추적해야 합니다. 또 다른 중요한 장애물은 개발 팀 간의 투명성과 보안 인식 문화를 조성하는 것인데, 이는 SBOM 관행을 성공적으로 채택하는 데 중요합니다. 이러한 SBOM 문제를 극복하려면 소프트웨어 공급망 보안을 강화하기 위한 강력한 도구, 효과적인 교육 및 강력한 조직적 노력을 결합하는 전략적 접근 방식이 필요합니다.

요약

결론적으로, SBOM은 대부분의 조직에서 여전히 새로운 아이디어이지만, SBOM을 생산하는 능력은 앞으로 더욱 중요해질 것으로 예상됩니다. 아직 SBOM 생성을 소프트웨어 제공 프로세스에 통합하기 시작하지 않았다면 지금이 그렇게 하기에 좋은 순간입니다.