고객 SBOM 요청에 답하는 방법

제조사에 구성 요소나 임베디드 소프트웨어를 공급하시나요? 계약, VEX, 납품 소프트웨어 버전별 SBOM을 다루는 공급업체를 위한 SBOM 가이드를 참조하세요.

지금 고객이 SBOM을 요청하는 이유

• EU Cyber Resilience Act. EU에서 판매하는 제조사는 자사 제품의 SBOM이 필요하고 외부에서 들여오는 구성 요소에도 주의를 기울여야 하므로, 이 질문이 공급망 아래로 내려옵니다.
• NIS2. 필수 기관과 중요 기관은 공급망 보안을 다뤄야 합니다. 이 지침은 SBOM을 명시하지 않지만, SBOM은 구매자가 공급업체가 출시하는 내용을 확인하는 한 가지 방법입니다. NIS2, ISO 27001, SOC 2 증거로서의 SBOM을 참조하세요.
• 분야별 규정. FDA 524B조는 사이버 기기에 SBOM을 요구하며, 다른 분야에도 자체 규정이 있습니다.
• 고객 자신의 취약점 대응. 제품에 무엇이 들어 있는지 아는 고객은 지원 티켓을 열지 않고도 새로운 CVE가 자신에게 영향을 주는지 판단할 수 있습니다.

무엇이든 보내기 전에 합의할 사항

질문	중요한 이유
어떤 제품의 어떤 버전인가?	SBOM은 하나의 릴리스를 설명합니다. 최신 빌드가 아니라 고객이 실행하는 버전의 SBOM을 보내세요.
어떤 형식인가?	대부분의 요청은 CycloneDX 또는 SPDX를 받아들입니다. 특정 버전이 필요한지 물어보세요.
어느 깊이까지인가?	최상위 종속성만으로는 부족할 수 있습니다. 전이적 종속성도 요청받을 것으로 예상하세요.
한 번인가, 릴리스마다인가?	계약에서 릴리스마다 새 SBOM을 기대할 수 있으며, 그러면 수작업으로는 감당할 수 없습니다.
어떤 조건으로 제공하는가?	SBOM은 제품이 어떻게 만들어졌는지 보여 줍니다. 기밀 유지 조건과 파일 전달 방법을 합의하세요.

좋은 답변에 담겨야 할 것

• 고객이 실행하는 바로 그 릴리스에 대한, 합의한 형식의 SBOM.
• 이름, 버전, 공급자, 라이선스, 패키지 식별자를 갖춘 모든 구성 요소.
• 전이적 패키지가 무엇 때문에 들어왔는지 추적할 수 있도록 하는 종속성 관계.
• 생성 날짜, 생성한 도구, 출처가 된 빌드.
• SBOM이 다루지 않는 부분에 대한 솔직한 설명(SBOM 완전성 참고).

파일이 어떻게 생겼는지는 SBOM 예시를, 두 형식에 대해서는 CycloneDX vs SPDX를 참고하세요. 고객이 수신 시 확인할 가능성이 높은 내용은 SBOM 품질 체크리스트에 있습니다.

나중에 문제로 돌아오는 실수

• 출시한 빌드 대신 최신 빌드를 보내는 것. 빌드는 기본적으로 재현 가능하지 않으므로, 같은 커밋을 다시 빌드해도 같은 SBOM이 나온다는 보장이 없습니다. 릴리스를 만든 빌드의 SBOM만이 고객이 받은 것을 보여 줍니다.
• 그때그때 수작업으로 만드는 것. 한 번은 요청을 충족하지만, 다음 고객과 다음 릴리스 때 또 반복해야 합니다. SBOM 자동화를 참고하세요.
• 반복할 수 없는 것을 약속하는 것. "릴리스마다 보내 드리겠습니다"는 계약서에 쓰기는 쉽지만 자동화 없이는 지키기 어렵습니다.
• SBOM으로 끝났다고 생각하는 것. 다음 질문은 "이 CVE의 영향을 받습니까?"이며, 다음 대형 취약점이 나올 때 함께 도착합니다.

다음 요청에 대비하는 방법

SBOM이 이미 있으면 요청에 답하기가 쉬워집니다. 릴리스를 빌드하는 파이프라인에서 모든 릴리스의 SBOM을 생성하고, 릴리스와 함께 보관하며, 새로운 취약점을 모니터링하세요. 그러면 요청에는 다운로드 한 번과 짧은 메모로 답할 수 있고, 후속 질문에도 같은 기록으로 답할 수 있습니다.

CRACI의 처리 방식

CRACI는 자체 러너에서 실행되는 모든 GitHub Actions 빌드의 SBOM을 기록하므로, 누군가 요청할 때 각 릴리스에는 이미 SBOM이 있습니다.

• CycloneDX 또는 SPDX로 내보내기. 전이적 종속성과 구성 요소에서 발견된 취약점을 포함합니다.
• 빌드 자체에서 나온 증거. SBOM의 모든 구성 요소는 실제로 빌드에 있었던 것이며, 잠금 파일 기반 도구가 놓치는 숨은 종속성도 기록됩니다.
• 모든 작업에 완전성 상태 표시. 보내기 전에 무엇을 보내는지 알 수 있습니다.
• 빌드 이력. 보존 기간 내에서 과거 빌드와 그 SBOM, 그리고 취약한 종속성을 포함한 빌드를 확인할 수 있습니다.
• 후속 질문에 대한 답변. CRACI는 모니터링 중인 SBOM을 계속 재평가하고, VEX를 지원하며, 인벤토리 뷰에서 어떤 제품이 어떤 버전을 실행하는지 보여 줍니다.

고객 SBOM 요청: 자주 묻는 질문

고객에게 SBOM을 제공할 의무가 있나요?

시장과 계약에 따라 다릅니다. EU Cyber Resilience Act는 SBOM을 기술 문서의 일부로 규정하며, 기술 문서는 요청 시 시장 감시 당국에 제출하는 것이고 공개는 요구하지 않습니다. 고객이 SBOM을 받을 권리는 대개 계약에서 나오므로, 합의한 내용을 확인하세요.

어떤 SBOM 형식을 보내야 하나요?

고객이 요청하는 쪽에 따라 CycloneDX 또는 SPDX를 보냅니다. 선호하는 형식이 없다면 어느 쪽이든 괜찮습니다. 고객의 도구에 특정 버전이 필요한지 물어보세요.

전이적 종속성을 포함해야 하나요?

EU Cyber Resilience Act는 최소한 최상위 종속성을 요구하지만, 많은 구매자는 전체 트리를 기대하며 취약점은 전이적 패키지에 있는 경우가 많습니다. 전체 SBOM이 더 안전한 답입니다.

SBOM은 NDA를 맺고 고객에게 보내야 하나요?

그것은 귀사와 고객이 결정할 일입니다. SBOM은 제품이 무엇으로 이루어져 있는지 보여 주므로, 많은 공급업체가 공개하는 대신 기존 계약이나 NDA에 따라 공유합니다.

업데이트된 SBOM은 얼마나 자주 보내야 하나요?

합의한 만큼 자주 보냅니다. 종속성은 릴리스마다 바뀌므로 릴리스마다 새 SBOM을 보내는 것이 정직한 기본값이며, 이는 SBOM이 빌드에서 나올 때만 현실적입니다.

고객이 이전 릴리스에 대해 묻는다면요?

해당 릴리스를 만든 빌드의 SBOM이 필요합니다. CRACI는 보존 기간 내에서 빌드 이력을 보관하며, 기본값은 180일이고 Enterprise에서는 맞춤 보존 기간을 설정할 수 있으므로, 더 오래 보관해야 하는 자료는 내보내 두세요.

SBOM을 한 번도 만들어 본 적이 없습니다. 어디서부터 시작해야 하나요?

고객이 실행하는 릴리스와 실제 빌드를 바탕으로 작동하는 도구에서 시작하세요. GitHub Actions를 사용한다면 빌드를 CRACI 러너로 옮기는 것만으로 첫 실행부터 기록된 SBOM을 얻을 수 있습니다.