Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
SBOM 생성 도구들이 소프트웨어 구성 요소를 식별하는 방식의 모호성과 한계를 분석합니다. cdxgen, syft 등 주요 도구들을 다양한 언어 환경에서 테스트한 결과, 모든 구성 요소를 완벽히 커버하지 못하는 공통적인 격차가 발견되었습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 arXiv Codex (cs.SE)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기소프트웨어 자재 명세서 (Software Bills of Materials, SBOMs)는 애플리케이션에 포함된 구성 요소 (components)를 나열함으로써, 취약한 구성 요소를 적시에 식별하고 소프트웨어 공급망 (software supply chain)의 보안을 보장하는 것을 목적으로 합니다. 그러나 우리는 SBOM에 나열될 구성 요소에 대해 합의가 이루어져 있다는 가정과, 현재의 기술이 소프트웨어 공급망을 보호하기에 충분하다는 근본적인 가정에 의문을 제기합니다. 먼저, 우리는 소프트웨어 개발 생명 주기 (development lifecycle) 내의 구성 요소 포함 메커니즘 (Component Inclusion Mechanisms, CIM)에 대한 기초부터 시작하는 분석을 제안합니다. 그다음, 우리는 cdxgen, syft, trivy, ORT, 그리고 Microsoft sbom-tool라는 네 가지 대중적인 SBOM 생성 도구들을 체계적으로 분석하여, 이들이 관련 구성 요소를 어떻게 정의하고 식별하는지 이해하고자 합니다. 마지막으로, 우리는 Python, Java, Go, PHP, Rust, C 프로그래밍 언어 전반에 걸친 정답 (ground truth)을 사용하여 이들을 평가합니다. 오늘날의 도구들이 구성 요소를 식별하는 데 한 단계 나아간 것은 사실이지만, 우리의 결과는 어떤 도구도 식별된 모든 CIM을 커버하지 못하며 도구 전반에 걸쳐 공통적인 격차 (gaps)가 존재함을 보여줍니다. 우리는 현재의 모호한 정의와 도구 환경 하에서, SBOM이 구성 요소 포함에 있어 모호성과 사각지대 (blind spots)를 나타낸다는 것을 입증합니다. 따라서 평가된 도구들로는 보안 등급의 SBOM을 달성할 수 없으며, 소프트웨어 공급망 보안을 보장하기 위해서는 추가적인 진전이 필요합니다. 우리는 어떤 구성 요소가 SBOM에 포함되어야 하는지를 명확히 하고, 그에 따라 SBOM 생성기를 수정하기 위해 원점으로 돌아가 재검토해야 합니다. 구성 요소가 무엇인지에 대한 공유된 이해가 없다면, SBOM을 통해 소프트웨어 공급망을 보호하려는 모든 노력은 실패할 것입니다.