이 시대에 보안 소프트웨어 제품이나 애플리케이션을 구축하려면 구축 중인 애플리케이션의 정확한 구성 요소에 대한 완전한 지식이 필요합니다. 소프트웨어 패키지를 구성하는 종속성, 라이센스, 파일 및 기타 자산은 악의적인 행위자가 공급망의 라인 아래에서 소프트웨어 및 기타 응용 프로그램에 대한 공격을 시작할 수 있는 잠재적인 취약 지점입니다.
최근 증가하는 빈도와 영향에 대처하기 위한 노력의 일환으로 소프트웨어 공급망에 대한 공격, 연방 정부는 NTIA와 협력하여 사이버 보안을 개선하고 소프트웨어 패키지에 사용되는 타사 구성 요소의 무결성을 보장하기 위한 다양한 조치를 자세히 설명하는 행정 명령을 발표했습니다. 그러한 조치 중 하나는 소프트웨어 재료 명세서.
이는 소프트웨어 패키지의 모든 구성 요소와 이러한 구성 요소 간의 공급망 관계를 포함하는 공식 문서입니다. 포괄적인 소프트웨어 BOM을 준비하는 것은 표준 관행일 뿐만 아니라 법적으로도 요구됩니다. 이 게시물은 소프트웨어 BOM의 범위와 최소 요소 이는 종합 자재 명세서에 포함되어야 합니다.
NTIA의 SBOM 최소 구성요소는 무엇을 제공합니까?
SBOM은 소프트웨어를 구축, 구매 또는 운영하는 기업을 위한 공식 가이드 역할을 하며 소프트웨어 공급망에 대한 이해를 높이는 데 필요한 모든 정보를 제공합니다. 또한 새로운 취약점이 발생할 경우 이를 쉽게 추적하는 데 도움이 됩니다. 소프트웨어 공급망 위험 감소. 그러나 SBOM이 연방정부가 규정한 요구사항을 충족하기 위해서는 반드시 포함해야 할 몇 가지 기본 요소가 있습니다. 이러한 요소는 종종 세 가지 범주로 분류됩니다.
- 데이터 필드: SBOM은 구성 요소 이름, 공급자 이름, 소프트웨어 버전 및 기타 고유 식별자와 같은 소프트웨어 구성 요소에 대한 중요한 데이터를 제공할 것으로 예상됩니다. 또한 종속성 간의 관계를 자세히 설명해야 합니다. 이 데이터를 통해 모든 소프트웨어 구성 요소를 정확하게 식별하고 소프트웨어 공급망 전체에서 추적할 수 있습니다.
- 자동화 지원: 소프트웨어 BOM은 기계 판독이 가능해야 하며 자동 생성도 가능해야 합니다. 이를 통해 SBOM에 포함된 데이터를 지속적으로 추적할 수 있습니다. 일반적으로 이러한 문서는 SPDX, CycloneDX 및 SWID 태그와 같은 표준 형식으로 되어 있어 사람도 읽을 수 있습니다.
- 관행 및 프로세스: SBOM 문서에는 SBOM 준비 및 업데이트를 위한 표준 관행과 프로세스도 자세히 설명되어 있습니다. 또한 SBOM 배포 및 액세스 방법과 부수적 오류 처리 방법도 포함되어야 합니다.
SBOM 문서의 NTIA 최소 필수 요소는 취약성 관리, 소프트웨어 구성 요소 목록 작성, 소프트웨어 라이선스 관리 등 소프트웨어 BOM의 기본 사용 사례에 대해 SBOM 지침에서 예상되는 사항에 대한 명확한 기준을 제공합니다. 프레임워크는 업데이트되고 있으며 가까운 시일 내에 유용성을 확장하는 추가 요소가 포함될 수 있습니다. 이 페이지의 다음 섹션에서는 소프트웨어 BOM의 주요 구성 요소에 대해 더 자세히 설명합니다. 소프트웨어 BOM의 최소 필수 요소에는 아래에 지정된 7개의 데이터 필드가 포함됩니다.
데이터 필드: 최소 요구 사항
소프트웨어 BOM의 목적은 사용자와 기타 이해관계자가 소프트웨어 구성 요소를 쉽게 식별하는 데 도움이 되는 정보를 제공하는 것입니다. 예상대로 SBOM의 첫 번째이자 가장 중요한 요소 중 하나는 문서에 자세히 설명된 모든 구성 요소에 대해 포함되어야 하는 데이터입니다. 개별 구성 요소를 식별하는 데 도움이 되는 것 외에도 데이터를 사용하면 소프트웨어 공급망의 다양한 위치에서 구성 요소를 쉽게 추적할 수 있습니다.
- 공급 업체 이름: 공급업체는 문제의 소프트웨어 구성 요소의 작성자 또는 제조업체입니다. 이는 소프트웨어 구성 요소를 생성, 정의 및 식별하는 개인 또는 조직의 이름입니다.
- 구성 요소 이름: 원래 공급자나 제조업체가 정의한 대로 소프트웨어에 할당된 지정 이름을 나타냅니다. 소프트웨어에 여러 이름과 별칭이 있는 경우 해당 내용도 함께 표시될 수 있습니다.
- 구성 요소 버전: SBOM에는 공급업체 또는 제조업체가 지정한 릴리스 번호 또는 카테고리 번호가 포함되어야 합니다. 버전 데이터는 이전에 식별된 소프트웨어 후속 릴리스 버전의 소프트웨어 변경 사항을 지정하는 식별자 역할을 합니다.
- 기타 고유 식별자: 이는 구성 요소 이름 및 버전 이외의 추가 식별자를 나타냅니다. 이러한 추가 식별자는 구성 요소에 대한 추가 식별 계층을 제공하며 관련 데이터베이스에서 구성 요소를 찾기 위한 조회 키로 사용될 수도 있습니다.
- 종속 관계: SBOM은 소프트웨어 구성 요소가 어떻게 결합되는지 자세히 설명하기 때문에 이는 소프트웨어 BOM의 가장 중요한 데이터 구성 요소 중 하나입니다. 종속 관계는 애플리케이션 내에서 사용되는 소프트웨어 X와 해당 업스트림 구성 요소 간의 관계를 지정합니다.
- SBOM 데이터 작성자: 이는 SBOM 데이터를 생성한 개인을 나타냅니다. 때로는 소프트웨어 공급업체가 작성자 역할을 겸할 수도 있습니다. 그러나 저자가 다른 개인이나 집단인 경우가 많다.
자동화 지원: 최소 요구 사항
소프트웨어 BOM의 사용은 조직의 경계를 넘어서는 경우가 많습니다. 이는 SBOM에 포함된 데이터가 조직 내의 여러 부서와 여러 조직에서 자주 사용된다는 것을 의미합니다. 이 문서의 사용 편의성을 보장하기 위해 NTIA는 SBOM이 기계와 사람이 모두 읽을 수 있는 형식이어야 한다고 권장합니다. 이와 같은 표준 자동화 형식으로 SBOM을 준비하고 전송하면 다양한 의도된 목적에 대해 이 문서의 상호 운용성이 향상됩니다.
NTIA는 SBOM 생성 및 전송을 위한 세 가지 전달 형식을 인식합니다. 귀하의 소프트웨어 BOM은 다음 형식 중 하나와 일치해야 다음 표준을 준수할 수 있습니다. 정부의 사이버보안 행정명령. 이러한 표준 형식은 다음과 같습니다.
- SPDX (소프트웨어 패키지 데이터 교환)
- 소프트웨어 식별(SWID) 태그
- 사이클론DX
SPDX (소프트웨어 패키지 데이터 교환)
SPDX는 SBOM 데이터 전달을 위한 개방형 표준입니다. 구성 요소, 출처, 라이센스 및 저작권을 포함하여 소프트웨어에 대한 중요한 정보를 캡처합니다. 또한 보안 참조도 제공합니다. 그만큼 SPDX 버전 2.2는 최신 버전이며 YAML 1.2 파일 형식, JavaScript Object Notation 및 Resource Description Framework(RDF/XML)을 지원합니다. 태그: 값 일반 텍스트 파일 및 .xls 스프레드시트
소프트웨어 식별(SWID) 태그
SWID 태그는 모든 소프트웨어 제품의 구성 요소를 식별하고 맥락화하는 데 도움이 되도록 설계되었습니다. 소프트웨어 식별 태그 프로젝트(SWID 태그)는 소프트웨어의 식별 태그를 생성하고 검증하기 위한 도구 세트입니다. 이러한 Java 기반 도구는 ISO/IEC 19770-2:2015에 정의된 표준화된 형식과 CBOR(Concise Binary Object Representation)을 기반으로 하는 XML SWID 태그를 지원합니다. 그만큼 NIST에는 웹사이트가 있습니다 다음에 대한 유용한 리소스 목록이 포함되어 있습니다.
- SWID 및 CoSWID 태그 구축
- 특정 스키마 요구 사항 및 모범 사례 지침을 기반으로 SWID 및 CoSWID 태그 유효성 검사
- Java 애플리케이션 서버에 배포할 수 있는 SWID 태그 유효성 검사 서비스를 제공하는 웹 앱
- 국가 취약성 데이터베이스에 태그를 게시하기 위한 SWID 저장소 클라이언트
사이클론DX
사이클론DX "경량 소프트웨어 재료 명세서(SBOM) 표준"이라고 주장합니다. 공급망 구성 요소 분석 및 애플리케이션 보안에 유용합니다. CycloneDX를 채택하는 조직은 최소 SBOM 요구 사항을 완벽하게 충족하고 시간이 지남에 따라 SBOM 문서의 보다 정교한 사용 사례로 발전할 수 있습니다.
CycloneDX SBOM은 일반적으로 XML, JSON 또는 프로토콜 버퍼 형식으로 제공됩니다. 사양에는 다음과 같은 5개 필드가 포함되는 경우가 많습니다.
- BOM 메타데이터: 여기에는 애플리케이션이나 소프트웨어 제품 자체에 대한 일반 정보가 포함됩니다.
- 구성 요소: 이는 소프트웨어의 모든 독점 및 오픈 소스 구성 요소를 포괄하는 포괄적인 인벤토리입니다.
- 서비스 정보: 애플리케이션이 작동 중에 호출할 가능성이 있는 모든 외부 API에 대해 자세히 설명합니다. 여기에는 모든 엔드포인트 URL, 인증 요구 사항 및 신뢰 경계 순회가 포함됩니다.
- 종속성: 설명서에는 소프트웨어 패키지 내의 모든 구성 요소와 서비스도 자세히 설명되어 있습니다. 여기에는 직접적 관계와 전이적 관계가 모두 포함됩니다.
- 구성(Compositions): 개별 구성 요소, 서비스 및 종속 관계를 포함한 모든 구성 부분의 완전성을 나타냅니다. 각 구성 요소는 일반적으로 완전한지, 불완전한지, 불완전한 자사 전용인지, 불완전한 타사 전용인지, 완전히 알려지지 않았는지 여부로 설명됩니다.
관행 및 프로세스: 최소 요구 사항
소프트웨어 BOM의 마지막 요소는 SBOM 사용 자체의 메커니즘에 중점을 둡니다. 관행과 프로세스는 SBOM 생성 및 사용에 대한 운영 세부 사항을 다루며 이를 요청하는 모든 정책이나 계약에 포함되어야 합니다. 다음은 소프트웨어 BOM의 실무 및 프로세스 섹션에 자세히 설명되어야 하는 주요 요구 사항입니다.
- 주파수 : 이 섹션에서는 조직이 새로운 소프트웨어 자재 청구서를 생성해야 하는 빈도를 자세히 설명합니다. 일반적으로 NTIA에서는 소프트웨어 구성 요소가 업데이트되거나 새 버전이 출시될 때마다 새 SBOM을 생성할 것을 권장합니다. 또한 공급업체는 원본 버전에서 오류를 발견하거나 초기 문서에 포함되지 않은 소프트웨어 구성 요소에 대한 새로운 세부 정보를 배울 때마다 새로운 SBOM을 생성해야 합니다.
- 깊이 SBOM의 깊이는 문서에 포함된 내용에 따라 다릅니다. 규정을 준수하려면 SBOM에 모든 최상위 구성 요소와 모든 전이적 종속성이 포함되어야 합니다. 작성자가 전이적 종속성을 모두 포함할 수 없는 상황에서는 문서에서 소비자에게 해당 종속성을 찾을 수 있는 위치를 알려주어야 합니다.
- SBOM 작성자가 어떤 이유로든 전체 종속성 그래프를 제공할 수 없는 경우가 있습니다. 이는 구성 요소에 추가 종속성이 없거나 이러한 종속성이 존재하는지 여부를 모르기 때문일 수 있습니다. SBOM 작성자는 이 이유를 지정해야 합니다.
- 배포 및 배송: 이 요구 사항의 목표는 SBOM이 쉽게 소화할 수 있는 형식으로 신속하게 전달되도록 하는 것입니다. 이 요구 사항에는 SBOM이 전달되어야 하는 일수 또는 주 수가 명시되어 있지 않지만 가능한 한 빨리 제출해야 합니다. 또한 SBOM은 제공 시 적절한 역할과 액세스 권한이 설정되어 있어야 합니다. 마지막으로, 요구 사항은 SBOM이 제품의 각 인스턴스와 함께 배포되거나 공개 웹 사이트를 통해 쉽게 액세스할 수 있는 방식으로 제공될 수 있도록 규정합니다.
- 액세스 제어: 공급업체가 SBOM 데이터에 대한 액세스를 특정 사용자나 고객으로 제한하기로 결정한 경우 작성자는 액세스 제어 조건을 지정해야 합니다. 또한 SBOM 데이터를 자신의 보안 도구에 통합하려는 소비자를 위해 특정 허용 사항을 제공할 필요도 있습니다.
- 실수에 대한 조정: SBOM은 소프트웨어 보증을 개선하고 소프트웨어 공급망 위험 관리. 그러나 아직 완벽함과는 거리가 멀다. 따라서 소비자는 SBOM을 준비할 때 가끔 발생할 수 있는 의도하지 않은 오류나 누락을 허용해야 합니다.
NTIA의 최소 요구 사항을 넘어서는 생각
지금까지 소프트웨어 BOM에 필요한 최소 요소에 대해 논의했습니다. 이러한 최소 요소는 특히 이 문서의 가장 기본적인 사용 사례에 대한 권장 요구 사항을 나타냅니다. 이는 소프트웨어 출처 및 보안을 위한 좋은 기반을 마련하지만 이러한 요구 사항 이상을 살펴봐야 합니다. 다음은 고급 SBOM 사용 사례에 대해 고려해야 할 몇 가지 권장 사항입니다.
추가 데이터 필드
최소 요구 사항 문서에서 다루는 데이터 필드 외에도 더 높은 수준의 보안이 필요한 경우에 권장되는 추가 데이터 필드가 있습니다. 이러한 추가 데이터 필드 중 일부는 다음과 같습니다.
- 소프트웨어 구성요소의 암호화 해시
- 소프트웨어 라이프사이클 단계 데이터
- 다른 구성 요소 간의 관계
- 라이센스 정보
클라우드 기반 소프트웨어 및 SaaS(Software-as-a-Service)
SBOM 요구 사항이 기본 사항을 넘어설 수 있는 또 다른 잠재적 영역은 SaaS(Software-as-a-Service) 제품 관리입니다. 이러한 유형의 소프트웨어 제품은 SBOM 데이터와 관련하여 고유한 과제를 안고 있습니다. 우선, 클라우드 환경의 보안 위험은 고유합니다. 또한, 이러한 위험에 대한 처리 책임은 서비스 제공자에게 있습니다. 클라우드 기반 소프트웨어에 대한 SBOM 문서를 준비하는 것은 릴리스 주기가 더 짧은 경향이 있기 때문에 더 복잡합니다.
SBOM 무결성 및 진정성
주목할만한 또 다른 문제는 SBOM 데이터 자체의 소스를 인증하는 프로세스입니다. 현재 서명과 공개 키 인프라는 오늘날의 디지털 세계에서 소프트웨어의 무결성을 확인하기 위한 솔루션입니다. SBOM 작성자 및 공급업체는 SBOM 데이터의 신뢰성을 향상시키기 위해 이러한 기존 소프트웨어 서명을 활용해야 할 수도 있습니다.
종속성의 취약성과 악용 가능성
SBOM의 목적은 취약성을 더 쉽게 감지하도록 하는 것이지만, 종속성의 모든 취약성이 이에 의존하는 소프트웨어에 주요 위험을 초래하는 것은 아니라는 점에 유의하는 것이 중요합니다. 시간과 자원 낭비를 피하기 위해 소프트웨어 공급업체는 다운스트림을 사용하는 소프트웨어에 대한 종속성 취약성의 잠재적 영향을 확인하고 SBOM 사용자에게 위험 수준(또는 이 경우 위험 수준이 없음)을 전달하는 조치를 취해야 합니다. 데이터 다운스트림.
구현의 유연성과 균일성
소프트웨어 보안을 논의할 때마다 유연성과 통일성에 대한 문제가 항상 대두됩니다. 이는 SBOM의 고급 사용 사례에도 적용됩니다. SBOM을 성공적으로 구현하려면 유연성이 필요한 특정 사례뿐만 아니라 모든 영역에 적용되는 광범위한 정책이 필요합니다.