SBOM 모범 사례

이를 여러 팀에 도입하는 방법은 엔지니어링 팀 전반의 SBOM 생성을 참고하세요.

SBOM 생성

1. 모든 릴리스에 대해 CI에서 생성합니다

수작업으로 만든 SBOM은 누군가 읽기도 전에 낡습니다. 릴리스를 빌드하는 파이프라인의 한 단계로 만들거나, 단계 없이도 SBOM을 생성하는 러너를 사용해 SBOM 없이 출시되는 릴리스가 없도록 하세요. GitHub Actions의 경우 GitHub Actions에서 SBOM을 생성하는 방법을 참고하세요.

2. 출시된 빌드를 기술합니다

빌드는 기본적으로 재현 가능하지 않습니다. 같은 커밋을 두 번 빌드해도 같은 종속성이 보장되지 않습니다. 버전은 빌드 시점에 해석되고 단계가 달라질 수 있기 때문입니다. 노트북에서 만든 SBOM이나 나중에 스캔한 SBOM은 출시한 빌드가 아니라 비슷한 빌드를 기술합니다. 릴리스를 생성한 CI 빌드에서 나온 SBOM만이 그 안에 무엇이 있는지 증명합니다. 빌드 시점 SBOM을 참고하세요.

3. 잠금 파일 이상을 다룹니다

잠금 파일은 출시된 내용의 기록이 아닙니다. 설치 스크립트는 코드를 내려받고, Rust 빌드 스크립트는 파일을 가져오며, 컨테이너 빌드는 자체 운영체제 패키지가 담긴 베이스 이미지를 들여옵니다. SBOM이 무엇을 다뤄야 하는지 정한 다음 테스트하세요. SBOM에서 베이스 이미지의 패키지와 빌드 도구를 검색해 보세요.

4. 전이적 종속성과 관계를 포함합니다

취약점은 대개 직접 종속성 아래에 있습니다. 평면 목록은 구성 요소가 있다는 것은 보여 주지만, 무엇을 업그레이드해야 하는지는 보여 주지 않습니다. SBOM에 종속성 그래프를 유지해, 발견 사항이 그것을 끌어오는 패키지와 함께 나오도록 하세요.

5. 볼 수 없었던 것을 명시합니다

2026년 최소 요소(Minimum Elements)는 SBOM 작성자에게 알 수 없는 정보를 명시적으로 표시할 것을 요구합니다. 불완전하다고 밝히는 SBOM이 완성된 것처럼 보이는 불완전한 SBOM보다 가치가 있습니다. 도구, 도구 버전, 생성 맥락도 기록해 읽는 사람이 파일이 다루는 범위를 판단할 수 있게 하세요. SBOM 완전성도 참고하세요.

SBOM 보관

6. 릴리스마다 아티팩트에 연결된 SBOM을 하나씩 보관합니다

구버전을 쓰는 고객이 노출 여부를 물으면, 최신 SBOM이 아니라 그 버전의 SBOM이 필요합니다. 각 SBOM을 그것이 기술하는 빌드 및 아티팩트와 함께 저장하고, 릴리스를 지원하는 기간에 맞춰 보관 기간을 정하세요. SBOM의 해시는 SBOM을 정확한 아티팩트에 연결하는 데 도움이 됩니다.

7. 형식과 식별자를 정하고 일관되게 사용합니다

CycloneDX 또는 SPDX, 형식 버전, 식별자로서의 패키지 URL을 표준으로 정하세요. SBOM을 비교할 때 겪는 어려움의 대부분은 도구마다 같은 것을 다르게 부르는 데서 옵니다. 파이프라인에서 각 파일을 검증하고, 공급업체에도 같은 형식을 요구하세요. 무엇을 확인하고 어떤 도구가 그 일을 하는지는 SBOM 품질 체크리스트에 정리되어 있습니다.

SBOM 활용

8. 빌드 중인 것만이 아니라 출시된 것을 모니터링합니다

SBOM이 가장 가치 있는 순간은 작년에 출시한 소프트웨어에 대한 보안 권고가 나온 다음 날입니다. 그때는 풀 리퀘스트의 스캔이 도움이 되지 않습니다. 지원 중인 릴리스의 저장된 SBOM을 새로운 취약점 데이터와 대조해 재평가하면, 새로운 보안 권고가 영향받는 릴리스 목록으로 바뀝니다.

9. 발견 사항을 담당자에게 배정하고 결정을 기록합니다

일치하는 취약점이 천 개인 SBOM은 계획이 아니라 목록일 뿐입니다. 우선순위 지정 방법으로 발견 사항의 순위를 정하고, 각각을 수정 책임 팀에 보내며, 나머지에 조치하지 않은 이유를 예를 들어 VEX 문서에 기록하세요.

10. 고객과 감사인에게 같은 SBOM을 사용합니다

고객, 감사인, 규제 기관은 비슷한 질문을 합니다. 시간이 지나며 어긋나는 별도의 문서를 만들기보다, 사내 팀이 사용하는 SBOM으로 답하세요. SBOM을 공유한다면 누가 볼 수 있는지와 업데이트를 어떻게 받는지 정하고, 공급업체에도 같은 것을 요구하세요.

흔한 실수

실수	문제가 되는 이유	대안
리포지토리당 SBOM 하나	특정 릴리스에 대해 아무것도 알려 주지 않음	릴리스당 하나, 아티팩트에 연결
감사 때만 생성	아무도 출시하지 않은 빌드를 기술함	모든 릴리스마다 CI에서
SBOM을 완료된 것으로 취급	출시 후에도 새로운 보안 권고가 나옴	계속 모니터링
구성 요소 수만 비교	항목이 틀렸다면 많다고 좋은 것이 아님	있다고 알고 있는 특정 패키지를 확인

CRACI의 처리 방식

CRACI는 빌드에 달린 사례들을 다룹니다. CRACI는 어떤 잠금 파일에도 나열되지 않는 숨은 종속성을 포함해 각 작업이 가져오는 모든 패키지를 완전성 상태가 포함된 CycloneDX 또는 SPDX SBOM으로 기록하는 GitHub Actions 러너입니다. 플랜의 보관 기간 내에서 과거의 모든 빌드와 그 SBOM을 보관하고, 새로운 취약점이 나타날 때마다 모니터링 중인 SBOM을 재평가하며, 어떤 빌드에 취약한 종속성이 포함되었는지 보여 줍니다. 보안 팀은 발견 사항을 분류해 수정 책임 팀에 보냅니다. 관리 도구 비교는 SBOM 관리를, 또는 최고의 SBOM 도구를 참고하세요.

SBOM 모범 사례: 자주 묻는 질문

SBOM은 언제 생성해야 합니까?

릴리스를 생성하는 CI 빌드 중에, 매번 생성해야 합니다. 그 시점에 만든 SBOM은 출시된 것을 기술하지만, 나중에 만든 SBOM은 재빌드나 스캔을 기술합니다.

SBOM은 얼마나 오래 보관해야 합니까?

최소한 릴리스를 지원하는 기간에 규제 기관이나 계약이 요구하는 기간을 더한 만큼입니다. 구버전 사용자가 새로운 취약점의 영향을 받는지 판단하려면 그 버전의 SBOM이 필요합니다.

SBOM은 자동화해야 합니까?

그렇습니다. 수작업 SBOM은 다음 릴리스 때 이미 낡습니다. 파이프라인에서 SBOM을 생성하고 검증하며, 빌드와 함께 저장하세요.

SBOM을 고객과 공유해야 합니까?

고객이나 규제 기관이 요청하면, 수용할 수 있는 조건으로 공유하세요. SBOM은 사용하는 것을 드러내므로, 많은 기업이 공개하기보다 요청 시 공유합니다.

SBOM과 SBOM 관리의 차이는 무엇입니까?

SBOM은 하나의 파일입니다. SBOM 관리는 SBOM을 릴리스별로 저장하고, 새로운 취약점에 대해 모니터링하며, 필요한 사람이 사용할 수 있게 하는 지속적인 작업입니다.