AI가 생성한 SBOM은 빌드에 대한 추측입니다. 규제 기관은 기록을 요구합니다.

팀이 시도하는 이유

매력은 분명합니다. 리포지토리나 잠금 파일을 코딩 어시스턴트에 붙여 넣고 CycloneDX를 요청하면, 몇 초 만에 형식이 잘 갖춰진 문서가 돌아옵니다. 스캐너가 흔히 비워 두는 필드까지 채울 수 있습니다. 대표적인 예가 공급자 필드입니다. 대부분의 생성기에는 이 정보의 출처가 없어 비어 있는 채로 나옵니다. 완전한 문서를 요청받은 모델은 모든 필드에 무언가를 써 넣을 수 있습니다.

바로 이 마지막 점이 문제를 압축해 보여 줍니다. 공급자를 모르는 스캐너는 필드를 비워 둡니다. 공급자를 모르는 모델도 그럴듯한 답을 만들어 낼 수 있습니다. 문서는 더 완전해 보이지만 신뢰도는 더 낮습니다.

모델이 실제로 보는 것

SBOM을 생성하는 모델은 눈앞의 텍스트, 즉 매니페스트, 잠금 파일, 경우에 따라 Dockerfile로 작업합니다. 빌드를 관찰하지 않습니다. 따라서 다음을 볼 수 없습니다.

• 리포지토리에 잠금 파일이 커밋되어 있지 않을 때 패키지 관리자가 해석한 버전,
• CI 캐시에서 복원된 패키지,
• 빌드 단계가 직접 내려받는 도구, OS 패키지, 바이너리,
• 거의 비어 있는 매니페스트와 함께 출시되는 컴파일된 바이너리에 들어간 것.

두 리포지토리가 파일이 얼마나 빈약할 수 있는지 보여 줍니다. expressjs/express 5.2.1은 잠금 파일을 커밋하지 않으므로, package.json에는 종속성이 버전 범위로 나열되고 실제 버전은 설치 시점에 결정됩니다. v2.1.259의 anthropics/claude-code 리포지토리에는 어떤 종류의 종속성 매니페스트나 잠금 파일도 없으며, 게시된 npm 패키지는 사전 빌드된 네이티브 바이너리를 감싸면서 런타임 종속성을 하나도 선언하지 않습니다. 이 리포지토리를 대상으로 한 결정론적 스캐너에는 바이너리를 설명하는 읽을거리가 없습니다. 같은 파일을 받은 모델도 정보가 부족하기는 마찬가지이지만, 그 빈틈을 채울 자유는 더 많습니다.

환각은 문서화된 실패 유형입니다

언어 모델은 존재하지 않는 패키지의 이름을 댑니다. 가장 잘 측정된 사례는 SBOM 작성이 아니라 코드 생성이지만, 그것이 보여 주는 실패는 구성 요소 목록에도 똑같이 적용됩니다. USENIX Security 2025의 한 연구는 16개 모델로 576,000개의 코드 샘플을 생성했고, 상용 모델에서 평균 최소 5.2%, 오픈 소스 모델에서 21.7%의 환각 패키지 비율과 205,474개의 고유한 환각 패키지 이름을 발견했습니다. Copilot Autofix에 대한 GitHub 자체 문서도 이 기능이 "통계적으로 그럴듯한 이름으로 게시된 조작된 종속성을 제안할 수 있다"고 경고합니다.

모델은 같은 답을 두 번 내놓지도 않습니다. Anthropic 문서에는 "temperature를 0으로 설정하더라도 결과는 완전히 결정론적이지 않으며, 동일한 입력이 API 호출마다 다른 출력을 낼 수 있다"고 명시되어 있습니다. 같은 커밋에서 생성한 두 SBOM이 서로 다를 수 있으며, 어느 쪽도 자신이 옳은지 말해 주지 않습니다.

SBOM에서 환각된 항목은 무해한 오타가 아닙니다. 존재하지 않는 패키지나, 존재하는 패키지의 잘못된 버전은 취약점 조회를 엉뚱한 곳으로 보내며, 그 결과는 확신에 차 있지만 틀린 채로 돌아옵니다.

표준이 SBOM에 기대하는 내용

NTIA 최소 요소(2021)

NTIA 기준은 일곱 가지 데이터 필드를 정의했습니다. 공급자 이름, 구성 요소 이름, 구성 요소 버전, 기타 고유 식별자, 종속성 관계, SBOM 데이터 작성자, 타임스탬프입니다. 여기에 자동화 지원과 일련의 관행 및 프로세스가 함께 제시되었습니다. 모든 필드는 소프트웨어에 대한 의견이 아니라 사실을 기술합니다.

CISA 2026 최소 요소

2026년 7월 29일, CISA, NSA, FBI와 국제 파트너들은 2021년 기준을 대체하는 개정 최소 요소를 발표했습니다. 추가된 항목 중 몇 가지는 빌드를 관찰하지 않고는 충족하기 어렵습니다.

• SBOM Generation Context: "SBOM 작성자가 SBOM을 생성한 시점의 상대적인 소프트웨어 수명 주기 단계와 사용 가능한 데이터"이며, 예로 "빌드 전", "빌드", "빌드 후"가 제시됩니다. 리포지토리를 읽는 모델은 기껏해야 빌드 전입니다.
• Component Hash Value: "실행 가능한 구성 요소 아티팩트에 암호화 해시 알고리즘을 적용해 생성한 출력"입니다. 작성자에게 아티팩트가 없다면 "SBOM 작성자는 해당 값을 알 수 없음으로 표시해야 합니다". 아티팩트를 한 번도 다루지 않은 모델은 해시를 만들 수 없으며, 해시처럼 생긴 텍스트만 만들 수 있습니다.
• SBOM Tool Name and Version: SBOM 생성에 사용한 도구의 이름을 밝혀야 합니다.
• Coverage: "SBOM에는 전이적 종속성을 포함해 대상 소프트웨어를 구성하는 모든 구성 요소에 대한 정보가 포함되어야 합니다. 최소 깊이는 없습니다."
• 알 수 없는 정보의 명시적 식별: 작성자는 "정보를 알 수 없는지 여부를 명시적으로 밝혀야 합니다". 조작된 값은 그 정반대입니다.

EU Cyber Resilience Act

CRA는 디지털 요소가 있는 제품의 제조사에게 SBOM을 법적 의무로 만듭니다. 부속서 I 제II부는 제조사에게 "디지털 요소가 있는 제품에 포함된 취약점과 구성 요소를 식별하고 문서화할 것, 여기에는 최소한 제품의 최상위 종속성을 다루는, 일반적으로 사용되는 기계 판독 가능한 형식의 소프트웨어 자재 명세서를 작성하는 것이 포함된다"고 요구합니다. 부속서 VII는 SBOM을 기술 문서에 포함시키며, 시장 감시 당국은 필수 요구 사항 준수 여부를 확인하기 위해 이를 요청할 수 있습니다.

이 문서들 중 어느 것도 AI 도구를 금지하지 않습니다. 이들이 요구하는 것은 실제 제품을 기술하는 데이터와, 알 수 없는 것에 대한 정직한 진술입니다. 추론으로 작성한 SBOM은 두 가지 모두에 어려움을 겪습니다.

CRACI가 SBOM을 생성하는 방식

CRACI는 GitHub Actions 작업을 CRACI의 러너에서 실행합니다. runs-on을 craci로 바꾸면 되며, 실행은 여전히 GitHub에 표시됩니다. 작업이 실행되는 동안 패키지를 인식하는 프록시가 패키지 소스로 가는 트래픽을 관찰하므로, SBOM에는 전이적 종속성을 포함해 빌드가 실제로 가져온 것이 기록됩니다. 종속성 증거는 CI 캐시와 함께 전달되므로, 캐시에서 복원된 패키지도 기록에 남습니다.

• 생태계: npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, apt, apk, Git 소스와 다운로드 프리셋.
• 완전성: 모든 작업과 캐시는 Complete, Complete with connections, Incomplete, Unavailable 또는 Not recorded로 표시되므로, 알 수 없는 정보는 채워 넣는 대신 명시됩니다.
• 형식: CycloneDX와 SPDX, 내보내기에 선언된 라이선스 메타데이터 포함.
• 출처 증명: API는 SBOM, 네트워크 추적, 출처 증명을 반환합니다.

CRACI는 더 넓은 CRA 컴플라이언스 프로세스에 필요한 공급망 가시성과 증거의 상당 부분을 자동화합니다. 그 자체만으로 제품을 규정 준수 상태로 만들지는 않습니다. 자세한 내용은 빌드 시점 SBOM 생성에서, 일정은 CRA 개요에서 확인하세요.

AI가 SBOM에 도움이 되는 부분

기록된 SBOM이 있다면 모델은 그것을 다루는 데 능숙합니다. 어떤 구성 요소에 위험이 있는지 요약하고, 권고를 쉬운 말로 설명하며, 사람이 검토할 관련 문서의 초안을 작성할 수 있습니다. 원칙은 간단합니다. 기록은 빌드가 만들게 하고, 모델은 그것을 읽게 하세요.