소프트웨어 자재 명세서(SBOM)란 무엇인가요?

소프트웨어 개발팀은 10여 년 전부터 오픈 소스 라이브러리와 서드파티 리포지토리를 관리하기 위해 SBOM을 사용하기 시작했습니다. 주요 공급망 공격으로 치명적인 약점이 노출된 후 SBOM은 사이버 보안에 대한 우려로 인해 큰 주목을 받게 되었습니다. 2020년 SolarWinds 침해에서 공격자들은 신뢰할 수 있는 소프트웨어 업데이트에 악성 코드를 삽입하여 여러 정부 조직을 포함한 18,000개 조직에 영향을 미쳤습니다. 얼마 지나지 않아 2021년 Log4j 취약점이 노출되어 전 세계 수억 대의 디바이스에 영향을 미치고 손상된 구성 요소가 전체 시스템을 어떻게 위협할 수 있는지 더욱 드러났습니다.

이러한 사이버 공격은 연방 정부 기관을 포함한 조직이 소프트웨어 시스템 내의 구성 요소와 종속성에 대한 가시성이 부족하다는 냉엄한 현실을 그대로 드러냈습니다. 이러한 가시성 부족으로 인해 사이버 보안 위험을 평가하고 위협에 효과적으로 대응하기가 어렵습니다. 위협의 긴급성은 백악관의 단호한 조치에 박차를 가했습니다. 행정 명령 14028은 2021년 5월에 모든 연방 소프트웨어 구매에 대해 SBOM을 의무화했습니다.

NTIA(National Telecommunications and Information Administration)는 소프트웨어 공급업체가 정부 기관에 판매할 때 따라야 하는 SBOM의 최소 요소를 설정했습니다. 2024년 9월, CISA는 "Framing Software Component Transparency"라는 제목의 문서를 게시하여, 이러한 최소 요구 사항을 확장하고 소프트웨어 에코시스템 전반의 SBOM 구현 및 관리에 대한 보다 자세한 지침을 제공했습니다.

이 연방 지침은 이제 산업 전반에 걸쳐 소프트웨어 투명성의 모델 역할을 합니다. 예를 들어, 금융 서비스 산업의 결제 카드 산업 데이터 보안 표준(PCI DSS) 버전 4.0에는 결제 시스템을 보호하고 취약점을 해결하기 위한 소프트웨어 재고 관리에 대한 요구 사항이 포함되어 있습니다. 의료 분야에서FDA는 의료 기기에 SBOM을 요구하는 반면, 국제 의료기기 규제기관 포럼(IMDRF)은 의료 기기 및 환자 데이터 시스템을 보호하기 위해 SBOM을 사용할 것을 권장합니다.

이러한 업계 가이드라인 및 권장 사항은 민간 부문 전반에 걸쳐 SBOM 채택을 향한 광범위한 변화를 반영합니다. Gartner는 중요 인프라 소프트웨어를 구축하거나 조달하는 조직의 60%가 2025년까지 SBOM을 의무화할 것으로 예측합니다(2022년에는 20% 미만). 최근 분석에 따르면 최신 소프트웨어 애플리케이션의 90% 이상이 오픈 소스 종속성을 포함하고 있으며, 74%는 고위험 종속성을 포함하고 있습니다. 규정 준수 요구 사항을 충족하고, 서드파티 구성 요소를 검증하며, 보안 취약점이 발견되면 해결하기 위해 SBOM을 사용하는 조직이 점점 더 많아지고 있습니다.

성분과 출처를 자세히 설명하는 식품 라벨과 마찬가지로 SBOM은 소프트웨어 구성 요소, 공급업체 및 종속성 간의 관계에 대한 문서를 제공합니다.

SBOM 요구 사항은 행정 명령 14028(2021년)에 도입된 이후 크게 발전했습니다. NTIA의 최소 요구 사항으로 시작한 것이 업계 채택 및 규제 개선을 통해 확대되었습니다. 2024년 9월 CISA에서 발표한 현재 프레임워크는 이러한 토대 위에 더 광범위한 구현을 위한 향상된 지침을 추가하여 구축되었습니다.

조직은 부문 및 연방 정부와의 관계에 따라 다른 SBOM 요구 사항에 직면합니다. 미국 정부 계약업체, 중요 인프라 제공업체 및 규제 대상 부문의 조직은 특정 SBOM 요구 사항을 준수해야 합니다. 정부는 공급업체에 SBOM 채택을 의무화하는 반면, 정부 계약 이외의 민간 조직은 자발적으로 채택하고 있지만, 공급망 보안과 고객 신뢰를 위해 SBOM 관행을 구현하는 것이 점점 더 중요해지고 있습니다.

CISA의 2024 프레임워크는 3단계 성숙도 모델을 도입하여 조직의 SBOM 관행을 점진적으로 개선하는 데 도움을 줍니다.

• 최소 기대치: 기본 SBOM 기능 및 규정 준수에 필요한 필수 요소
  
  
• 권장 사례: 더 광범위한 보안 및 규정 준수 사용 사례를 지원하는 향상된 문서
  
  
• 야심 찬 목표: 포괄적인 공급망 가시성을 지원하는 고급 기능

다음 속성은 완전한 SBOM에 필요한 필수 요소를 나타냅니다.

• SBOM 메타 정보: SBOM 데이터의 작성자, 생성 타임스탬프 및 문서화되는 기본 구성 요소를 포함하여 SBOM 문서 자체의 핵심 데이터
  
  
• 공급업체 이름: 소프트웨어 구성 요소를 생성, 정의 및 제조하는 업체
  
  
• 구성 요소 이름: 원래 공급자가 할당한 소프트웨어 구성 요소의 지정된 이름
  
  
• 구성 요소 버전: 버전별 변경 사항을 캡처하여 업데이트 및 수정 사항을 정확하게 추적
  
  
• 기타 고유 식별자: 정확한 구성 요소 추적을 위해 CPE(Common Platform Enumeration), SWID 태그 또는 PURL(Package URL)과 같은 참조 유형 포함.
  
  
• 암호화 해시: 무결성 및 정확한 식별을 확인할 수 있는 각 소프트웨어 구성 요소에 대한 고유한 지문
  
  
• 종속성 관계: 구성 요소가 상호 연결되는 방식을 보여주는 구조화된 맵으로, 직접 종속성과 전이 종속성을 모두 포함
  
  
• 라이선스 정보: 제공된 소프트웨어 구성 요소에 대한 법적 조항 문서
  
  
• 저작권 고지: 나열된 구성 요소에 대한 독점적이고 법적 권리를 보유한 주체

소프트웨어 종속성은 최신 애플리케이션 내에서 복잡한 상호 연결을 생성합니다. SBOM은 직접 종속성(소프트웨어에 명시적으로 포함된 구성 요소)과 전이 종속성(다른 종속성에 의해 가져온 구성 요소) 을 구분하여 이러한 관계를 명확하게 구분해야 합니다.

종속성을 문서화할 때 조직은 지식의 완성도를 명시적으로 표시해야 합니다. 기본 가정은 명시적으로 달리 표시하지 않는 한 종속성 정보가 불완전할 수 있다는 것입니다. 이러한 투명성은 다운스트림 사용자가 소프트웨어 공급망의 잠재적인 사각지대를 파악하는 데 도움이 됩니다.

또한 조직은 런타임 시 로드되는 동적 종속성과 외부 서비스에서 호출되는 원격 종속성을 고려해야 합니다. 이러한 관계는 기존 소프트웨어 빌드의 일부가 아닐 수 있지만, 이러한 관계를 이해하는 것은 포괄적인 보안 평가에 매우 중요합니다.

실제 구현에서는 모든 소프트웨어 구성 요소에 대한 완전한 지식이 항상 가능한 것은 아닙니다. 조직에서는 알려지지 않은 종속성과 불완전한 정보를 명확하게 문서화하여 이러한 차이를 투명하게 처리해야 합니다. 계약상의 의무나 기타 제약으로 인해 특정 구성 요소를 완전히 문서화할 수 없는 경우 SBOM은 전반적인 종속성 구조를 유지하면서 이러한 삭제 사항을 표시해야 합니다.

조직은 불확실한 정보를 생략하는 대신 이러한 영역을 알 수 없거나 불완전한 것으로 명시적으로 표시해야 합니다. 이 접근 방식은 다운스트림 사용자가 위험 관리 및 추가 조사 요구 사항에 대해 정보에 입각한 결정을 내리는 데 도움이 됩니다. 수정된 구성 요소의 경우 조직은 외부 공유를 위해 완전한 내부 SBOM과 적절하게 수정된 버전을 모두 유지 관리해야 합니다.

SBOM을 생성하고 유지 관리하는 프로세스에는 소프트웨어 개발 라이프사이클(SDLC) 전반에 걸쳐 여러 이해관계자가 참여합니다. 조직은 독점 및 오픈 소스 소프트웨어(OSS) 구성 요소 모두에 대해 SBOM을 생성해야 합니다. 소프트웨어 공급업체와 개발자는 주로 개발 프로세스 초기에 초기 SBOM을 생성하는 일을 담당합니다. 이러한 SBOM은 전체 코드베이스의 구성 요소에 대한 포괄적인 보기를 캡처합니다. 소프트웨어 구매자는 배포된 애플리케이션에 대해 이러한 문서를 검증하고 유지 관리하는 데 중요한 역할을 합니다.

소프트웨어 개발 팀은 SBOM 생성을 지속적 통합 및 지속적 제공 (CI/CD) 파이프라인에 직접 통합합니다. 빌드 프로세스 중에 자동화된 스캐닝 툴이 소스 코드를 분석하여 모든 구성 요소의 재고를 작성하고 직접적 종속성과 전이적 종속성을 모두 캡처합니다. 이러한 툴은 SPDX 및 CycloneDX와 같은 형식으로 표준화된 SBOM 파일을 생성합니다. (SWID 태그는 덜 사용되지만, 여전히 유효한 옵션입니다.) 각 구성 요소의 메타데이터, 버전 정보 및 라이선스 세부 정보를 문서화합니다.

버전 관리 시스템은 SBOM 변경 사항에 대한 기록 기록을 유지 관리하여 시간이 지남에 따라 소프트웨어 구성이 어떻게 발전하는지 추적합니다. 조직은 각 릴리스의 소프트웨어 구성 요소 내에서 버전 변경 및 보안 패치를 추적할 수 있으며, 이는 취약점을 관리하고 보안 사고를 처리하는 데 매우 중요합니다.

개발팀은 일반적으로 특정 이벤트(새 종속성이 추가되거나, 기존 구성 요소가 업데이트되거나, 보안 패치가 적용되는 경우)를 기반으로 SBOM 업데이트를 트리거하도록 파이프라인을 구성합니다. 이러한 지속적 업데이트 프로세스는 소프트웨어의 실제 구성과 문서 간의 조정을 유지합니다.

개발 파이프라인 전반의 품질 관리 체크포인트는 SBOM의 완전성과 정확성을 검증합니다. 이러한 검증 단계는 각 SBOM이 필요한 표준을 충족하고 소프트웨어 릴리스 전에 필요한 모든 구성 요소 정보를 포함하고 있는지 확인합니다. 자동화된 검증은 문서 격차를 줄이고 릴리스 전반에 걸쳐 일관성을 개선합니다.

SBOM 생성을 지원하는 툴링 에코시스템은 계속 확장되고 있습니다. SBOM 생성기는 소스 코드를 자동으로 스캔하여 구성 요소와 그 관계를 식별하는 기반을 형성합니다. 그런 다,음 검증 툴은 확립된 표준 및 사양에 대해 생성된 SBOM을 확인하여 누락되거나 잘못된 정보에 플래그를 지정합니다. 성공적인 SBOM 자동화는 확립된 모범 사례에 달려 있습니다. 즉, 팀 전체에서 형식을 표준화하고, 일관된 명명 규칙을 구현하고, 자동화 규칙에 대한 모범 사례 문서를 유지하고, 지속적인 개선을 위한 피드백 루프를 구축하는 것입니다.

관리 플랫폼은 이러한 기능을 기반으로 구축되어 조직 전반에 SBOM 스토리지, 분석 및 배포 기능을 제공합니다. 고급 플랫폼은 SBOM 데이터를 보다 광범위한 위험 및 규정 준수 워크플로에 통합하여 한 단계 더 나아갑니다.

예를 들어, 자동화 툴은 특정 소프트웨어 구성 요소에 취약점을 매핑하고, 심각도에 따라 수정 작업의 우선순위를 정하고, 시간 경과에 따른 변경 사항을 추적하여 새로 도입된 위험을 식별할 수 있습니다. 이러한 툴은 데이터를 통합하고 실시간 인사이트를 제공함으로써 개발, 보안 및 규정 준수 팀이 효과적으로 협업할 수 있도록 지원합니다.

효과적인 구현을 위해서는 올바른 SBOM 형식을 선택하는 것이 중요합니다. SBOM은 에코시스템 전반에 걸쳐 확장할 수 있도록 자동 생성과 기계 판독 기능을 지원해야 합니다. SBOM 프로세스를 자동화하면 생성 과정에서 발생하는 수동 입력 오류가 없어지고 보안 및 개발 툴과의 원활한 통합이 가능해집니다.

SBOM 데이터의 자동 생성, 검증 및 소비를 가능하게 하는 동시에 기존 보안 및 개발 툴과의 통합을 지원하는 데 사용되는 몇 가지 표준화된 형식이 있습니다. 조직은 CI/CD 파이프라인 내에서 자동화된 SBOM 생성을 구현하여 문서가 소프트웨어 변경 사항에 따라 최신 상태로 유지되도록 해야 합니다.

현재 CISA 프레임워크는 주로 SPDX와 CycloneDX의 두 가지 형식을 인식합니다. 각각은 소프트웨어 구성 요소 문서에 다르게 접근하여 다양한 수준의 세부 사항을 제공하고 소프트웨어 개발 라이프사이클 내의 특정 사용 사례에 중점을 둡니다.

SPDX(Software Package Data Exchange)는 Linux Foundation에서 개발했으며, 오픈 소스 에코시스템과 상용 소프트웨어 공급업체 전반에 걸쳐 널리 채택되었습니다. 이 형식은 암호화 패키지 검증을 지원하며 JSON, RDF, XML 및 YAML을 포함하여 컴퓨터가 읽을 수 있는 여러 형식 옵션을 제공합니다. 풍부한 메타데이터 지원을 통해 소프트웨어 공급망 전반에 걸쳐 상세한 보안 및 출처 추적을 가능하게 합니다.

SPDX는 오픈 소스 규정 준수 시나리오에서 탁월하며, 자세한 라이선스 정보를 제공하고 조직이 오픈 소스 구성 요소 사용을 효과적으로 관리할 수 있도록 지원합니다. 주요 소프트웨어 공급업체와 클라우드 서비스 제공업체는 강력한 사양과 광범위한 에코시스템 지원을 위해 SPDX를 채택했습니다.

OWASP Foundation에서 개발한 CycloneDX는 애플리케이션 보안 및 소프트웨어 공급망 위험 관리를 위해 특별히 설계되었습니다. VEX 통합 및 컨테이너 분석 지원에 중점을 두고 취약점 관리, 구성 요소 추적 및 공급망 보안을 위한 필수 기능을 제공합니다.

이 형식의 보안 중심 요소는 포괄적인 소프트웨어 공급망 보안 프로그램을 구현하는 조직에 특히 적합합니다. 보안 사용 사례에 대한 기본 지원은 보안 팀과 취약점 관리 워크플로 간의 채택을 주도했습니다.

SWID(Software Identification) 태그는 소프트웨어 식별 및 관리를 위한 표준화된 메커니즘을 제공합니다. 이 형식은 엔터프라이즈 환경에서 라이프사이클 관리, 패치 추적 및 인벤토리 제어 기능을 통해 포괄적인 소프트웨어 자산 추적을 지원합니다. 특히 SWID 태그는 속성 매핑에 대한 2024년 지침에서 더 이상 지원되는 형식으로 명시되지 않지만, SBOM 내에서는 고유 식별자로서 유효한 옵션으로 남아 있습니다.

소프트웨어 구성 분석(SCA)은 코드의 취약점을 스캔하는 능동적인 사이버 보안 프로세스(관련 툴 포함)이며, 소프트웨어 자재 명세서(SBOM)는 제품의 모든 소프트웨어 구성 요소에 대한 표준화된 재고를 제공합니다. 둘 다 소프트웨어 공급망 보안을 지원하지만 최신 개발 환경에서 고유한 용도로 사용됩니다.

두 가지 툴 모두 소프트웨어 구성 요소에 중점을 두는 반면, SCA 툴은 주로 오픈 소스 구성 요소 및 서드파티 종속성에 중점을 두고 개발 중에 코드를 적극적으로 스캔하고 분석합니다. 이러한 툴은 취약점 감지, 라이선스 규정 준수 및 보안 정책 시행에 대한 실시간 인사이트를 제공합니다.

SBOM은 독점 코드를 포함한 모든 소프트웨어 구성 요소를 캡처하는 표준화된 인벤토리 문서로 작동합니다. SBOM은 SPDX 및 CycloneDX와 같은 구조화된 형식을 통해 소프트웨어 구성에 투명성을 제공하지만 본질적으로 기능을 포함하지는 않습니다. SCA 툴은 일반적으로 내부 보안 관행을 지원하지만, SBOM은 점점 더 규정 및 업계 표준에 의해 의무화되고 있습니다.

조직은 일반적으로 두 솔루션을 함께 구현하여 개발 중에 보안을 적극적으로 모니터링하는 동시에 규정 준수 요구 사항 및 공급망 가시성을 위해 SBOM을 유지합니다. SCA 툴은 종종 SBOM을 자동으로 생성하고 검증하는 반면, SBOM 문서는 검증 정책을 알리는 데 도움이 됩니다.

현대 소프트웨어 공급망의 복잡성으로 인해 SBOM 채택은 포괄적인 위험 관리 및 보안 보증에 필수적입니다. 조직은 보다 효과적인 의사 결정을 위해 SBOM 데이터를 다른 보안 및 규정 준수 정보와 통합할 수 있는 자동화된 플랫폼을 사용하는 경우가 점점 더 많아지고 있습니다.

보안 팀은 실시간 취약점 탐지 및 대응을 가능하게 하는 자동화된 플랫폼을 통해 SBOM 데이터를 더 광범위한 애플리케이션 위험 관리 전략에 통합합니다. 새로운 공통 취약점 및 노출(CVE)이 나타나면 이러한 플랫폼은 SBOM 재고를 사용하여 전체 소프트웨어 포트폴리오의 영향을 받는 구성 요소에 이를 즉시 매핑할 수 있습니다. 이것은 조직이 안전한 소프트웨어 관행을 지원하는 데 도움이 됩니다.

이 통합을 통해 위험 우선순위를 정하기 위한 AI 기반 인사이트를 확보하여 팀이 가장 중요한 CVE를 먼저 해결할 수 있습니다. 인시던트 대응 중에 SBOM의 자세한 구성 요소 데이터는 잠재적으로 손상된 구성 요소에 대한 중요한 인텔리전스를 제공합니다. 이를 통해 표적 해결 노력과 보다 정확한 위험 평가가 가능합니다.

SBOM은 소프트웨어 구성 요소의 재고를 제공하고 새로운 취약점이 발견되면 영향을 받는 시스템을 신속하게 식별할 수 있도록 하여 취약점 관리에서 중요한 역할을 합니다.

그러나 모든 취약점이 동일한 위험을 초래하는 것은 아니며 악용 가능성을 판단하는 것이 어려울 수 있습니다. 이때 VEX(Vulnerability Exploitability eXchange)를 사용할 수 있습니다. VEX는 알려진 취약점에 대한 필수 컨텍스트를 제공하여 SBOM 유틸리티를 강화하는 보안 프레임워크입니다. SBOM은 소프트웨어 제품 내의 모든 구성 요소를 식별하지만 발견된 취약점이 악용 가능한지 여부는 나타내지 않습니다. VEX는 취약점의 실제 영향을 명확히 하여 이러한 격차를 해소합니다.

VEX는 제품 보안 사고 대응 팀(PSIRT) 및 보안 팀에 특정 취약점이 소프트웨어 환경에 영향을 미치는지 여부를 알립니다. VEX는 CSAF(Common Security Advisory Framework)를 사용하여 취약점 영향에 대해 컴퓨터가 읽을 수 있는 상태 업데이트를 제공합니다. 이 정보를 통해 보안 팀은 더 빠르고 정보에 입각한 의사 결정을 내릴 수 있습니다.

조직은 VEX 데이터를 SBOM과 통합함으로써 오탐을 줄이고, 실제 위험의 우선순위를 지정하고, 취약점 관리 워크플로를 최적화할 수 있습니다. 이러한 결합된 접근 방식은 자동화된 보안 위험 평가 및 표적 해결에서 상당한 발전을 의미합니다.

규제 요구 사항이 진화함에 따라 조직에는 복잡한 SBOM 요구 사항을 처리할 수 있는 정교한 규정 준수 관리 능력이 필요합니다. SBOM은 일종의 증명으로서 소프트웨어 구성 요소가 NIST 지침 및 행정 명령 14028과 같은 표준을 준수한다는 검증 가능한 문서를 제공합니다. SBOM은 소프트웨어 구성 및 보안에 대한 투명한 기록을 제공함으로써 감사를 간소화하고 산업 전반의 규제 조정을 입증합니다.

연방 기관 및 규제 대상 업계는 NIST 지침 및 행정 명령 14028을 비롯한 다양한 프레임워크를 준수하고 있음을 입증해야 합니다. 고급 규정 준수 플랫폼은 소프트웨어 구성 요소가 보안 표준을 충족하는지 자동으로 확인하고, 여러 프레임워크에서 규정 준수 상태를 추적하고, 구성 요소가 요구 사항을 벗어날 경우 실시간 경고를 제공할 수 있습니다. 이러한 기능을 통해 조직은 수작업 감독을 줄이면서 지속적인 규정 준수를 유지할 수 있습니다.

클라우드 네이티브 환경과 컨테이너화된 환경은 SBOM 관리에 고유한 문제를 제기합니다. 이러한 환경의 동적인 특성으로 인해 복잡한 마이크로서비스 아키텍처를 처리할 수 있는 전문적인 접근 방식이 필요하며, 여러 클라우드 제공업체 및 플랫폼에 걸쳐 컨테이너 이미지와 배포가 자주 변경됩니다.

조직은 컨테이너 오케스트레이션 플랫폼과 직접 통합되는 특수 SBOM 툴을 통해 이러한 문제를 해결합니다. 이러한 솔루션은 컨테이너 이미지가 구축 및 배포될 때 실시간 SBOM 생성을 가능하게 하는 동시에 하이브리드 클라우드 환경 전반에 걸쳐 통합된 가시성을 제공합니다.

구성 요소 추적을 자동화하고 기존 클라우드 보안 툴과 통합함으로써 조직은 전체 클라우드 인프라에서 정확한 소프트웨어 구성 요소 재고를 유지하고 보안 위협에 신속하게 대응할 수 있습니다. 이는 애플리케이션이 컨테이너에서 서버리스 기능으로 실행되는 경우나 기존 환경에서 실행되는 경우 모두 적용됩니다.

SBOM은 서드파티 소프트웨어에 대한 포괄적인 가시성을 제공하여 공급망 위험 관리의 기반 역할을 합니다. 조직은 종종 AI 기반 플랫폼을 사용하여 SBOM 데이터와 다른 보안 지표를 분석하고, 애플리케이션 건강과 위험 태세에 대한 전반적인 관점을 얻습니다.

이러한 플랫폼은 구성 요소 버전을 추적하고, 공급업체 위험을 평가하고, 라이선스 규정 준수를 강화하는 동시에 실행 가능한 인사이트를 제공하여 위험을 완화할 수 있습니다. SBOM 데이터를 광범위한 위험 관리 프로세스와 통합하면 조직은 소프트웨어 종속성에 대해 정보에 입각한 의사 결정을 내리고 보다 안전하고 규정을 준수하는 애플리케이션 환경을 유지할 수 있습니다.

조직은 소프트웨어 에코시스템 전반에 걸쳐 SBOM 관행을 구현할 때 여러 중요한 장애물에 직면할 수 있습니다. 이러한 과제를 이해하고 해결하는 것은 공급망 전반에 걸쳐 성공적인 데이터 보안을 도입하고 효과적으로 유지하는 데 중요한 부분입니다.

조직이 SBOM 관행을 구현할 때 종종 다음과 같은 과제가 발생합니다.

• 다양한 환경에서 수천 개의 소프트웨어 구성 요소 관리
  
  
• 다양한 개발 툴과 보안 플랫폼 간의 SBOM 데이터 통합
  
  
• 특히 레거시 소프트웨어 및 서드파티 구성 요소에 대한 데이터 품질 유지
  
  
• 빠른 배포 주기를 통해 클라우드 환경에서 종속성 추적
  
  
• 리소스 제약 조건과 정확한 최신 SBOM 데이터의 필요성 간의 균형 유지
  
  
• 구성 요소가 자주 변경되는 동적 클라우드 네이티브 아키텍처에 적응

SBOM을 성공적으로 구현하려면 업계 표준 및 조직의 요구에 부합하는 전략적 접근 방식이 필요합니다. 핵심 요소는 다음과 같습니다.

• 소프트웨어 개발 라이프사이클 전반의 프로세스 자동화
  
  
• 기존 워크플로 및 보안 툴과 원활하게 통합
  
  
• SBOM 관리를 위한 통합 플랫폼 사용

• 기본 SBOM 기능 및 규정 준수를 위한 필수 요소 구현
  
  
• 광범위한 보안 및 규정 준수 사용 사례를 위한 문서 개선
  
  
• 고급 기능을 통해 포괄적인 공급망 가시성 지원

• 특히 클라우드 네이티브 환경에서 SBOM을 실시간으로 생성 및 업데이트
  
  
• 알려지지 않은 정보를 생략하지 않고 투명하게 문서화
  
  
• 전체 내부 sBOM과 외부 공유를 위해 편집된 버전을 모두 관리
  

• 정기적인 감사와 자동화된 검증을 통해 명확한 SBOM 거버넌스 정책 수립
  
  
• SBOM 데이터를 VEX(Vulnerability Exploitability eXchange)와 연결하여 취약점 관리 개선

이러한 관행을 따르면 조직은 공급망 가시성을 개선하고 보안을 강화하며 규정 준수를 유지하는 동시에 SBOM 구현의 문제를 해결할 수 있습니다.

소프트웨어 공급망 보안의 환경은 계속 진화하면서 SBOM 기술 및 채택의 혁신을 주도하고 있습니다. 조직이 점점 더 정교해지는 위협에 직면함에 따라 소프트웨어 에코시스템의 보안에서 SBOM의 역할이 더욱 중요해지고 있습니다.

SBOM 구현 및 활용의 미래를 결정하는 몇 가지 주요 트렌드는 다음과 같습니다.

인공 지능의 발전은 조직이 SBOM을 관리하고 활용하는 방식을 변화시키고 있습니다. 이제 최신 AI 시스템은 SBOM 생성 및 분석을 자동화하는 동시에 보다 정확한 예측 위험 분석과 정교한 취약점 탐지를 제공합니다. 이러한 자동화는 소프트웨어 공급망 전반의 사전 예방적 보안 위험 식별로 확장됩니다.

중요한 발전은 AI 생성 코드 및 모델의 고유한 문제를 해결하는 특수 AI/ML BOM의 출현입니다. 이 개선된 BOM은 AI 모델 아키텍처, 교육 데이터 및 테스트 방법을 문서화하여 AI 개발 프로세스에 필요한 투명성을 제공합니다.

SBOM 관리를 위한 보안 환경은 계속 발전하고 있습니다. 블록체인 및 분산 원장 기술은 안전한 SBOM 스토리지 및 공유를 위한 새로운 솔루션을 제공하여 중요한 인프라 시스템에 특히 유용한 변경 불가능한 감사 추적을 생성합니다. 손상된 구성 요소를 신속하게 식별하고 문제를 간소화할 수 있는 실행 가능한 SBOM 데이터를 요구하는 조직이 점점 더 많아지고 있습니다.

블록체인은 위변조 방지 스토리지를 제공하고, 탈중앙화된 검증을 가능하게 하며, 엄격한 액세스 제어를 통해 조직 간 안전한 공유를 촉진함으로써 SBOM 보안을 강화할 수 있습니다.

이러한 기술적 융합은 기존 DevSecOps 사례와 통합되는 통합 플랫폼의 채택을 촉진합니다. 이러한 솔루션은 서로 다른 데이터 소스 병합부터 여러 소프트웨어 버전 및 브랜치에 걸친 승인 관리에 이르기까지, 전체 SBOM 라이프사이클을 자동화하는 동시에 위험 완화를 위한 인텔리전스를 제공합니다.