SBOM
SBOM이란 무엇입니까?
SBOM(소프트웨어 자재 명세서)은 소프트웨어 안에 있는 구성 요소, 즉 모든 라이브러리, 패키지, 종속성을 버전, 제작자, 라이선스와 함께 기계가 읽을 수 있게 나열한 목록입니다. 식품의 성분 표시처럼 소프트웨어의 성분을 보여 줍니다. 새 취약점이 공개되면 SBOM으로 영향을 받는 구성 요소를 출시했는지 몇 분 만에 알 수 있습니다.
업데이트
SBOM은 무엇의 약자입니까?
SBOM은 software bill of materials(소프트웨어 자재 명세서)의 약자입니다. 이 용어는 제품에 들어가는 부품을 나열하는 자재 명세서(bill of materials)라는 제조업 용어에서 왔습니다. CISA는 SBOM을 소프트웨어 구성 요소를 이루는 성분 목록, 즉 중첩된 인벤토리로 설명합니다.
최신 애플리케이션의 코드는 대부분 다른 사람이 작성한 것이며, 그중 대부분은 간접적으로 들어옵니다. 패키지 하나를 추가하면 수십 개의 전이적 종속성이 함께 들어옵니다. SBOM은 이 모든 것을 기록하므로, 리포지토리를 하나도 읽지 않고도 "우리가 영향을 받는가?"라는 질문에 답할 수 있습니다.
SBOM에는 무엇이 담깁니까?
유용한 SBOM은 두 부분으로 이루어집니다. SBOM 자체에 대한 데이터와 각 구성 요소에 대한 데이터입니다. CISA, NSA, FBI가 국제 파트너와 함께 2026년 7월 29일 발표한 2026 Minimum Elements는 2021년 NTIA 목록을 대체하며, 현재 대부분의 구매자가 참조하는 기준을 정합니다.
| 구분 | 필드 |
|---|---|
| SBOM 자체 | 작성자와 작성자 서명, 타임스탬프, 데이터 형식 이름과 버전, 도구 이름과 버전, SBOM 버전, 생성 맥락 |
| 각 구성 요소 | 이름, 버전, 제작자, 패키지 URL이나 CPE 같은 식별자, 해시 값과 알고리즘, 라이선스, 종속성 관계 |
생성 맥락은 보기보다 중요합니다. SBOM이 언제 만들어졌는지, 즉 빌드 전, 빌드 중, 완성된 아티팩트에서, 또는 그 이후인지를 알려 줍니다. 같은 릴리스의 두 SBOM이 바로 이 이유로 다를 수 있습니다. 실제 파일에서 이 필드들이 어떻게 보이는지는 SBOM 예시를 참조하고, 받은 파일은 SBOM 품질 체크리스트로 확인하세요.
SBOM 형식
사용 중인 SBOM은 거의 모두 두 형식 중 하나입니다. OWASP의 CycloneDX는 보안 분야에서 시작되었으며 취약점과 서비스도 기술합니다. Linux Foundation의 SPDX는 라이선스 컴플라이언스 분야에서 시작되었습니다. 둘 다 최소 요소를 담을 수 있으며, 대부분의 도구가 두 형식을 모두 출력합니다. 선택 방법은 CycloneDX vs SPDX를 참조하세요.
SBOM이 중요한 이유
- 더 빠른 사고 대응. Log4Shell 같은 취약점이 나오면, 질문은 어떤 제품에 그것이 들어 있느냐입니다. SBOM이 있으면 검색 한 번이면 되지만, 없으면 하나의 프로젝트가 됩니다.
- 출시 후 취약점 모니터링. 출시할 때 깨끗했던 소프트웨어도 내일은 취약할 수 있습니다. 저장된 SBOM을 새 보안 권고와 다시 대조하면 아무것도 다시 빌드하지 않고 이를 잡아낼 수 있습니다.
- 라이선스 위험. 각 구성 요소의 선언된 라이선스를 보면 카피레프트나 상용 조건이 제품에 들어가기 전에 알 수 있습니다.
- 고객과 규제 기관의 질문. 구매자들은 조달 과정에서 점점 더 SBOM을 요구하며, 여러 프레임워크가 구성 요소 인벤토리를 기대합니다.
누구에게 SBOM이 필요합니까?
소프트웨어를 출시하는 모든 사람, 그리고 그 안에 무엇이 있는지 책임져야 하는 모든 사람입니다. 요구 사항은 대개 다음 중 하나를 통해 다가옵니다.
- 의료 기기. FDA 524B조는 사이버 기기의 시판 전 제출 서류에 SBOM을 요구합니다.
- EU에서 판매되는 제품. Cyber Resilience Act는 제조사에 SBOM을 요구합니다. CRA SBOM 요구 사항과 도구를 참조하세요.
- 미국 연방 조달. 2026년 1월의 OMB 메모 M-26-05는 SBOM 요구 여부를 각 기관이 결정하도록 하므로, 사례별로 요구될 것으로 예상하세요.
- 결제 소프트웨어. PCI DSS 4.0 요구 사항 6.3.2는 맞춤형 소프트웨어와 그 서드파티 구성 요소의 인벤토리를 요구합니다. SBOM을 명시하지는 않지만, SBOM으로 이 요구를 충족할 수 있습니다.
SBOM을 생성하는 방법
SBOM을 만드는 방법은 세 가지이며, 방법에 따라 파일에 담기는 내용이 결정됩니다.
| 방법 | 읽는 대상 | 흔한 공백 |
|---|---|---|
| 소스 스캔 | 리포지토리의 매니페스트와 잠금 파일 | 어떤 잠금 파일에도 나열되지 않았는데 빌드가 가져오는 모든 것 |
| 결과물 스캔 | 완성된 컨테이너 이미지 또는 바이너리 | 컴파일된 코드는 모호하고, 빌드 도구는 흔적을 남기지 않음 |
| 빌드 기록 | 빌드가 실행 중에 실제로 가져온 것 | 기록기를 우회한 트래픽(표시되어야 함) |
Syft, Trivy, cdxgen 같은 오픈 소스 생성기는 처음 두 방법을 사용합니다. 각 도구마다 무엇을 읽을지에 대한 규칙이 있어서, 같은 커밋에 대해서도 결과가 서로 다릅니다. 옵션을 나란히 비교하려면 최고의 SBOM 도구를 참조하세요.
SBOM vs SCA vs VEX
- SBOM은 인벤토리입니다. 무엇이 있는지를 말할 뿐, 안전한지는 말하지 않습니다.
- 소프트웨어 구성 분석은 분석입니다. 구성 요소를 찾아 위험을 점검하며, 많은 SCA 도구가 그 과정에서 SBOM을 생성합니다.
- VEX는 영향에 대한 진술입니다. 알려진 취약점이 실제로 제품에 영향을 미치는지를 밝혀, SBOM만으로 생기는 노이즈를 줄입니다.
SBOM 생성은 쉬운 부분입니다
아무도 읽지 않는 파일은 아무것도 바꾸지 못합니다. 가치는 릴리스마다 SBOM을 하나씩 보관하고, 모니터링하며, 필요할 때 찾을 수 있는 데서 나옵니다. 이 작업이 SBOM 관리이며, 운영 방법은 SBOM 모범 사례에서 다룹니다.
CRACI가 SBOM을 만드는 방법
CRACI는 각 작업이 가져오는 모든 패키지를 트리의 모든 깊이에서, CI 캐시에서 복원된 패키지까지 포함해 기록하는 GitHub Actions 러너입니다. 그 결과는 릴리스를 만든 빌드의 SBOM이며, 작업이 볼 수 없었던 것을 알려 주는 완전성 상태가 함께 담깁니다. CycloneDX 또는 SPDX로 내보낼 수 있으며, CRACI는 새 취약점이 공개될 때마다 이를 계속 재평가합니다. 빌드 시점 SBOM 생성을 참조하세요.
SBOM: 자주 묻는 질문
SBOM을 간단히 설명하면 무엇입니까?
SBOM은 소프트웨어의 성분 목록입니다. 제품에 들어 있는 모든 구성 요소를 버전, 제작자, 라이선스와 함께 기계가 읽을 수 있는 형식으로 나열합니다.
SBOM은 무엇의 약자입니까?
SBOM은 software bill of materials(소프트웨어 자재 명세서)의 약자입니다.
SBOM이 왜 필요합니까?
새로 공개된 취약점이 출시한 제품에 영향을 미치는지 빠르게 파악하고, 출시 전에 라이선스 위험을 확인하며, 제품에 무엇이 들어 있는지 묻는 고객과 규제 기관에 답하기 위해서입니다.
주요 SBOM 형식 두 가지는 무엇입니까?
CycloneDX와 SPDX입니다. CycloneDX는 OWASP에서 나왔으며 보안 분야에서 시작되었습니다. SPDX는 Linux Foundation에서 나왔으며 라이선스 컴플라이언스 분야에서 시작되었습니다. 둘 다 최소 요소를 담을 수 있습니다.
SBOM은 법적으로 의무입니까?
제품과 시장에 따라 다릅니다. FDA 524B조는 사이버 기기에 SBOM을 요구하며, EU Cyber Resilience Act는 제조사에 SBOM을 요구합니다. 미국 연방 조달에서는 이제 각 기관이 결정합니다. 그 밖의 많은 기업에게는 법적 요구보다는 고객의 요구 사항입니다.
SBOM은 얼마나 자주 업데이트해야 합니까?
빌드마다 다른 버전을 가져올 수 있으므로 릴리스마다 새 SBOM을 생성하세요. 릴리스의 SBOM은 이후 바뀌지 않지만, 새 취약점과 계속 대조해야 합니다.
SBOM은 누가 만듭니까?
대개 소프트웨어를 빌드하는 팀이 만들며, 릴리스마다 자동으로 생성되도록 CI에서 만드는 것이 이상적입니다. 구매하는 소프트웨어는 공급업체가 제공하는 SBOM과 함께 받아야 합니다.