ISO 27001·SOC 2·NIS2 증거로서의 SBOM

증거는 컴플라이언스가 아닙니다

통제는 제대로 작동하는 프로세스로 충족됩니다. 증거는 그것이 작동한다는 것을 보여 줍니다. SBOM이 보여 주는 것은 단 하나, 특정 릴리스에 무엇이 들어 있었는지입니다. 접근 제어, 사고 대응, 누군가 발견 사항에 조치했는지에 대해서는 아무것도 보여 주지 않습니다.

아무도 눈치채지 못하게 틀릴 수도 있습니다. 엉뚱한 파일을 읽은 생성기는 제품의 절반이 빠진 유효한 SBOM을 만듭니다. 그 SBOM의 취약점 스캔 결과는 깨끗하고, 컴플라이언스 플랫폼은 스캔이 실행된 것을 확인하며, 모든 검사가 초록색으로 표시됩니다. 초록색 SOC 2 SBOM 검사가 검증하는 것에서 이 실패를 자세히 다룹니다.

SBOM에서 나온 증거가 유효하려면 다음 조건을 갖춰야 합니다.

릴리스와 연결되어 있을 것. 저장소당 하나가 아니라 출시한 버전마다 하나의 SBOM.
완전하거나, 빠진 것을 밝힐 것. 빈틈을 밝힌 SBOM은 나열한 내용을 믿을 수 있습니다.
감사 대상 기간 동안 보관될 것. 작년 3월을 표본으로 삼는 감사인에게는 작년 3월의 SBOM이 필요합니다.
새 취약점이 나오면 다시 확인할 것. 아무도 새 보안 권고와 비교하지 않는 목록은 취약점 관리에 대해 거의 아무것도 증명하지 못합니다.

SBOM에 무엇이 들어 있는지는 SBOM이란을 참조하세요. 산업용 제품과 미국 연방 소프트웨어의 보안 개발 프레임워크는 IEC 62443-4-1과 NIST SSDF를 참조하세요.

ISO/IEC 27001:2022

ISO/IEC 27001은 정보보호 관리체계를 인증하는 기준 표준입니다(용어집). Annex A에는 93개 통제가 있으며, 조직은 위험 평가에 따라 필요한 통제를 선택하고 적용성 보고서(Statement of Applicability)에 기록합니다. ISO/IEC 27002:2022는 구현 지침을 제공합니다. 둘 다 SBOM을 언급하지 않습니다. 아래 표는 통제 제목만 영어 원문으로 인용하고 각 통제의 내용을 간단히 설명합니다.

통제	내용	SBOM 또는 빌드 기록이 증거가 되는 방식	다루지 않는 것
5.9 "Inventory of information and other associated assets"	어떤 자산이 있고 누가 소유하는지 파악	출시하고 운영하는 소프트웨어도 자산입니다. 릴리스별 구성 요소 목록은 그 안에 무엇이 있는지에 대한 목록입니다.	하드웨어, 데이터, 사람, 서비스
5.19 "Information security in supplier relationships", 5.20 "Addressing information security within supplier agreements", 5.21 "Managing information security in the ICT supply chain", 5.22 "Monitoring, review and change management of supplier services"	공급업체와 ICT 공급망에 따르는 위험 관리	두 방향이 있습니다. 구매자로서 공급업체에 SBOM을 요구하고 모니터링할 수 있습니다. 공급업체로서는 인증받은 고객의 공급망 프로세스가 요구하는 것이 바로 SBOM입니다. 오픈소스 구성 요소는 ICT 공급망의 일부이지만 공급 계약이 없으며, 그렇기 때문에 이들의 목록이 중요합니다.	계약, 공급업체 평가와 검토
8.8 "Management of technical vulnerabilities"	취약점 정보를 입수하고, 노출을 평가하고, 조치하는 것	보안 권고와 매칭되고 새 권고가 나올 때 재평가되는 최신 구성 요소 목록, 그리고 어떤 릴리스에 취약한 버전이 언제부터 들어 있었는지에 대한 기록	인프라 패치, 호스트 스캔, 그리고 의사 결정 자체
8.25 "Secure development life cycle"	소프트웨어와 시스템을 안전하게 개발하기 위한 규칙	기록되고 반복 가능한 릴리스 프로세스: 모든 릴리스를 같은 파이프라인에서 SBOM과 함께 빌드	통제의 대부분: 교육, 환경, 설계, 리뷰
8.26 "Application security requirements", 8.27 "Secure system architecture and engineering principles", 8.28 "Secure coding"	요구 사항, 설계, 코드	직접적이지 않습니다. 가져오는 것이 아니라 직접 작성하는 것에 관한 통제입니다.	전부: 여기서는 코드 리뷰, SAST, 설계 기록이 증거입니다
8.29 "Security testing in development and acceptance"	릴리스 전 보안 테스트	취약점 발견 시 빌드를 차단하는 정책 게이트는 결과가 있는 기록된 테스트입니다	기능적 보안 테스트, 침투 테스트
8.30 "Outsourced development"	외주 개발의 지시와 모니터링	자사 파이프라인에서 빌드되는 외주 코드는 자체 코드와 같은 SBOM과 검사를 받습니다	계약, 공급업체 자체의 관행

8.25~8.30에 대해서는 솔직해야 합니다. 이 통제들이 요구하는 것의 대부분은 SBOM 밖에 있습니다. 더 많이 주장하는 것은 나머지 부분에 대한 감사인의 신뢰를 잃는 가장 빠른 길입니다.

예시: 감사인이 8.8에 대해 묻는 경우

"이미 출시한 제품에 새 취약점이 영향을 주는지 어떻게 압니까?" 보안 권고 하나에 대한 증거 사슬과 각 단계를 누가 제공하는지는 다음과 같습니다.

단계	증거	출처
1. 릴리스 내용	버전 4.2를 만든 빌드가 기록한 그 버전의 SBOM	빌드 도구
2. 보안 권고 매칭	해당 SBOM에 있는 라이브러리에 대해 새로 공개된 CVE, package URL로 매칭	취약점 모니터링
3. 노출 기간	취약한 버전이 들어 있던 모든 빌드와 첫 빌드의 날짜	빌드 이력
4. 결정	누가 언제 평가했는지, 그리고 결과: 수정, 완화 또는 not affected와 그 이유	자체 프로세스와 그 기록
5. 수정	SBOM에 더 이상 취약한 버전이 없는 버전 4.2.1	빌드 도구

도구는 1, 2, 3, 5단계를 제공할 수 있습니다. 4단계는 조직의 프로세스이며, 감사인이 가장 꼼꼼히 보는 단계입니다.

SOC 2

SOC 2 보고서는 통제가 AICPA의 Trust Services Criteria(2017년, 중점 사항(points of focus)은 2022년 개정)를 충족하는지 기술합니다. 기준은 결과 중심으로 서술되어 있습니다. SBOM을 언급하지 않으며, 그중 두 가지 기준에서 SBOM이 도움이 됩니다.

CC7.1은 조직이 "(1) 새로운 취약점을 유발하는 구성 변경과 (2) 새로 발견된 취약점에 대한 취약성을 식별하기 위해 탐지 및 모니터링 절차를 사용"할 것을 요구합니다. 증거: 릴리스별 SBOM, 새 보안 권고에 대한 재평가, 각 발견 사항의 처리 기록.
CC8.1은 변경 관리를 다룹니다. 인프라, 데이터, 소프트웨어, 절차에 대한 변경이 어떻게 승인되고, 개발 또는 획득되고, 테스트되고, 승인되고, 구현되는지입니다. 증거: 기록된 파이프라인에서 빌드된 모든 릴리스, 빌드 간 종속성 변화의 가시성, 출시 가능한 것을 통제하는 정책 게이트.

기준은 개정 중입니다. 2026년 10월 AICPA는 기준을 부분적으로 재구성한 2027 Trust Services Criteria 공개 초안을 발표했으며, 의견 제출 기한은 2027년 1월 15일이고, 2027년 12월 31일 이후 시작하는 업무부터 적용하는 안이 제시되었습니다. 초안이므로 기준 번호가 바뀔 수 있습니다. 증거를 새 번호에 매핑하기 전에 최종 문서를 확인하세요.

이미 SOC 2 플랫폼을 쓰고 있다면 그대로 유지하세요. 문제는 그 검사 뒤에 있는 SBOM이 무엇을 보여 주는지입니다: SOC 2 SBOM 검사 비교.

NIS2

NIS2 Directive (EU) 2022/2555는 지침이 열거한 분야의 필수 기관과 중요 기관에 적용됩니다. 소프트웨어나 기기 공급업체로서 이 글을 읽고 있다면 대개 직접 적용 대상은 아닙니다. 적용 대상은 고객이며, 고객의 의무가 질문의 형태로 공급업체에 도달합니다. 제21조는 사이버보안 위험 관리 조치를 정하며, 그런 질문의 대부분은 다음 세 구절에서 나옵니다.

제21조 제2항 (d): "각 기관과 그 직접 공급업체 또는 서비스 제공자 간 관계의 보안 관련 측면을 포함한 공급망 보안".
제21조 제2항 (e): "취약점 처리 및 공개를 포함한 네트워크 및 정보 시스템의 획득, 개발 및 유지보수에서의 보안".
제21조 제3항: 기관은 "각 직접 공급업체 및 서비스 제공자에 고유한 취약점과, 보안 개발 절차를 포함한 공급업체 및 서비스 제공자의 제품 및 사이버보안 관행의 전반적인 품질"을 고려해야 합니다. 바로 이 문장이 여러분 책상 위의 설문지가 됩니다.

Implementing Regulation (EU) 2024/2690

2024년 10월 17일자 Commission Implementing Regulation (EU) 2024/2690은 DNS 서비스 제공자, TLD 이름 레지스트리, 클라우드 컴퓨팅 서비스 제공자, 데이터 센터 서비스 제공자, 콘텐츠 전송 네트워크 제공자, 관리형 서비스 제공자, 관리형 보안 서비스 제공자, 온라인 마켓플레이스, 온라인 검색 엔진, 소셜 네트워킹 플랫폼, 신뢰 서비스 제공자를 대상으로 제21조 제2항 조치의 기술적·방법론적 요구 사항을 정합니다. 다른 NIS2 분야를 구속하지는 않지만, "공급망 보안"이 무엇을 뜻하는지에 대한 가장 상세한 공개 문서이며 다른 구매자들도 이를 참고합니다. 공급업체에 닿는 항목은 다음과 같습니다.

부속서의 항목	내용	공급업체가 받는 질문
5.1.2(a)	공급업체 선정 시 "보안 개발 절차를 포함한 공급업체 및 서비스 제공자의 사이버보안 관행"을 고려	어떻게 안전하게 개발하며, 제품에 무엇이 들어가는지 어떻게 압니까?
5.1.4(e), (f)	계약에는 적절한 경우 감사를 하거나 감사 보고서를 받을 권리, 그리고 기관에 "위험을 초래하는 취약점을 처리할 공급업체 및 서비스 제공자의 의무"를 명시	납품하는 것의 취약점을 처리하겠습니까? 그 증거를 볼 수 있습니까?
5.2	각 직접 공급업체가 제공하는 "ICT 제품, ICT 서비스, ICT 프로세스 목록"을 포함한 직접 공급업체 등록부	저희에게 어떤 제품과 버전을 공급합니까?
6.1.2(c)	ICT 서비스 또는 ICT 제품 획득 시: "ICT 서비스 또는 ICT 제품에 사용된 하드웨어 및 소프트웨어 구성 요소를 기술하는 정보"	제품에 어떤 하드웨어와 소프트웨어 구성 요소가 들어 있습니까? 이 페이지의 어떤 문서보다 SBOM에 가깝지만, 여전히 SBOM이라는 말은 없습니다.
6.10	취약점 처리: CSIRT 공지나 "공급업체 또는 서비스 제공자가 제공한 정보" 같은 채널로 취약점 정보를 모니터링하고(6.10.2(a)), 조치가 필요 없는 취약점은 "그 이유를 문서화하고 입증"(6.10.3)	취약점을 저희에게 어떻게 알려 줄 것이며, 이 취약점은 왜 문제가 아닙니까?

마지막 항목은 이유를 갖춘 not affected 선언을 설명합니다. 규정이 형식을 지정하지는 않지만, 바로 VEX 문서가 담는 내용입니다.

예시: NIS2 고객이 보낸 설문

위 항목에서 고객이 도출하는 유형의 질문 다섯 가지와 공급업체가 첨부할 수 있는 증거입니다. 어떤 답은 도구가 보관하는 기록에서 나오고, 어떤 답은 직접 작성하는 정책입니다.

질문	첨부할 증거	기록 또는 정책
"저희에게 납품하는 제품 버전의 소프트웨어 구성 요소를 나열해 주십시오." (6.1.2(c))	해당 버전의 SBOM, CycloneDX 또는 SPDX, 완전성 명시	기록
"취약점 처리 절차와 일정을 설명해 주십시오." (5.1.4(f))	심각도 수준과 목표 시간이 포함된 취약점 처리 절차	정책
"저희가 운영하는 버전 중 어느 것에 취약한 라이브러리가 언제부터 들어 있었습니까?" (6.10)	해당 구성 요소가 들어 있던 모든 빌드를 날짜와 함께 보여 주는 빌드 이력	기록
"이 CVE는 왜 저희에게 영향을 주지 않습니까?" (6.10)	"취약한 코드가 존재하지 않음" 같은 근거를 갖춘 not affected 선언	평가에 기반한 기록
"연구자가 귀사 제품의 취약점을 어떻게 신고할 수 있습니까?" (5.1.2(a))	조정된 취약점 공개 정책	정책

구분해 둘 점이 하나 있습니다. EU에서 판매되는 디지털 요소를 포함한 제품에 대해서는 Cyber Resilience Act가 SBOM을 요구합니다. NIS2는 요구하지 않습니다.

금융 기관에 판매한다면: DORA

Digital Operational Resilience Act, Regulation (EU) 2022/2554는 금융 기관에 적용되며 공급업체에 직접 적용되지는 않습니다. 금융 기관은 ICT 자산과 그 상호 의존성을 식별하고 문서화하며 목록을 유지해야 하고(제8조 제1항, 제4항, 제6항), ICT 위험의 일부로 ICT 제3자 위험을 관리해야 하며(제28조 제1항), 모든 ICT 서비스 계약에 관한 정보 등록부를 유지하고(제28조 제3항), 계약에 최소 조항을 넣어야 합니다(제30조). DORA는 SBOM을 언급하지 않습니다. 은행에 소프트웨어를 공급하는 업체라면 릴리스별 구성 요소 목록이 고객의 제8조 이행을 돕습니다.

모든 프레임워크를 아우르는 증거 지도

행은 증거 항목이며, 각 셀은 그 증거가 뒷받침하는 통제, 기준 또는 항목을 나타내거나 "직접적이지 않음"으로 표시합니다.

증거	ISO/IEC 27001:2022	SOC 2	NIS2 및 2024/2690	DORA
1. 완전성을 명시한 릴리스별 SBOM	5.9, 5.21, 8.8	CC7.1	Art. 21(2)(d); 6.1.2(c)	Art. 8(고객의 목록)
2. 새 보안 권고에 대한 지속적 재평가	8.8	CC7.1	Art. 21(2)(e); 6.10	직접적이지 않음
3. 빌드 이력: 어떤 릴리스에 구성 요소가 언제부터 들어 있었는지	8.8	CC7.1, CC8.1	6.10	직접적이지 않음
4. 분류(트리아지)와 담당 배정 기록	8.8	CC7.1	Art. 21(2)(e); 6.10	직접적이지 않음
5. 이유를 갖춘 not affected 선언	8.8	CC7.1	6.10	직접적이지 않음
6. 빌드를 차단하는 정책 게이트	8.25, 8.29	CC8.1	Art. 21(2)(e)	직접적이지 않음
7. 자체 SBOM과 함께 모니터링하는 공급업체 SBOM	5.19, 5.21, 5.22	CC7.1	Art. 21(2)(d), 21(3); 5.2, 6.10	Art. 28(1)
8. 빌드의 이그레스 정책과 네트워크 기록	8.25	CC8.1	Art. 21(2)(d)	직접적이지 않음

SBOM이 증명하지 못하는 것

접근 제어, 사고 대응, 업무 연속성, 인적 보안, 암호화, 물리적 보안.
누군가 무엇을 수정했다는 사실. 그것은 조직의 프로세스와 그 기록이 증명합니다.
자체 코드에 결함이 없다는 사실. 코드 리뷰, SAST, 테스트가 그 증거입니다.
SBOM 없이 받은 바이너리 안에 무엇이 있는지.
인증을 받았다는 사실. SBOM은 인증서가 아니며, 도구 벤더가 보유한 인증서는 그 벤더 자신의 관리체계를 인증할 뿐 여러분을 인증하지 않습니다.

CRACI의 역할

CRACI는 GitHub 호스팅 러너를 대체하고 각 빌드가 가져온 것을 기록하므로, SBOM이 릴리스 빌드 자체에서 나오며 모든 작업에 완전성 상태가 붙습니다.

모니터링 중인 SBOM은 새 취약점이 공개될 때마다 지속적으로 재평가됩니다 (취약점 추적).
빌드 이력은 보존 기간 내에서 어떤 빌드에 취약한 종속성이 들어 있었는지, 즉 노출 기간을 보여 줍니다. 감사가 더 긴 기간을 다룬다면 각 릴리스의 SBOM을 내보내 릴리스와 함께 보관하세요.
보안 팀은 발견된 취약점을 분류(트리아지)해 수정을 담당하는 팀에 전달하며, CRACI는 VEX를 지원해 취약점의 영향을 받지 않는 제품을 기록할 수 있습니다.
정책 게이트는 특정 CVE가 포함된 빌드를 포함해, 발견 사항이 있는 빌드를 차단할 수 있습니다.
서드파티 SBOM을 추가할 수 있어, 구매한 구성 요소도 자체 빌드와 함께 모니터링됩니다.
SBOM은 CycloneDX 또는 SPDX로 내보내며, API는 SBOM, 네트워크 트레이스, 출처(provenance) 데이터를 반환합니다. 이그레스 정책은 각 빌드가 연결할 수 있는 대상을 기록하고 제한합니다.

CRACI는 이러한 통제의 증거를 제공합니다. ISO 27001이나 SOC 2 준수, NIS2 대비를 대신 이뤄 주지 않으며, 컴플라이언스 자동화 플랫폼도 아닙니다. CRACI 자체의 인증서는 별개의 사실입니다. CRACI 플랫폼의 개발과 운영에 대한 CRACI Corporation Oy의 정보보호 관리체계는 Into Certification이 발행한 ISO/IEC 27001 인증을 받았습니다. 이는 CRACI가 서비스를 운영하는 방식을 다루며, 여러분의 조직이나 제품을 다루지 않습니다. CRACI의 보안과 플랫폼 전체에 대한 CRACI 작동 방식을 참조하세요.

CRACI가 답이 아닌 경우

빌드가 GitHub Actions에서 실행되지 않는 경우. 현재 CRACI가 지원하는 CI는 GitHub Actions뿐이며, 다른 CI 시스템은 로드맵에 있습니다.
정책, 접근 검토, 감사인 워크플로를 위한 컴플라이언스 자동화 플랫폼이 필요한 경우. 기존 플랫폼을 유지하거나 도입하세요. SOC 2 SBOM 검사 비교를 참조하세요.
증거 공백이 주로 조직적인 경우: 정책, 교육, 사고 대응.
주요 공급업체 위험이 SBOM 없이 받는 바이너리인 경우. 이 경우는 바이너리 분석이 답입니다.

고객 한 곳의 요청에 답하고 있나요? 고객 SBOM 요청에 답하는 방법, 구성 요소 공급업체를 위한 가이드, 고객이 실행할 체크리스트를 참조하세요.

컴플라이언스 증거로서의 SBOM: 자주 묻는 질문

ISO 27001은 SBOM을 요구하나요?

아닙니다. ISO/IEC 27001:2022는 SBOM을 언급하지 않습니다. Annex A 통제 5.9(목록), 5.21(ICT 공급망), 8.8(기술적 취약점)은 SBOM이 뒷받침하는 결과를 요구하며, 어떤 증거가 충분한지는 조직과 감사인이 판단합니다.

SOC 2는 SBOM을 요구하나요?

아닙니다. Trust Services Criteria는 결과 중심으로 서술되며 SBOM을 언급하지 않습니다. 새 보안 권고에 대해 재평가되는 릴리스별 SBOM은 CC7.1의 증거이며, 기록된 빌드 파이프라인은 변경 관리에 관한 CC8.1을 뒷받침합니다.

NIS2는 SBOM을 요구하나요?

아닙니다. 제21조 제2항 (d)는 공급망 보안을, (e)는 취약점 처리를 요구하지만 SBOM을 언급하지 않습니다. 일부 디지털 서비스 제공자를 대상으로 하는 Implementing Regulation (EU) 2024/2690은 6.1.2(c) 항목에서 ICT 제품의 하드웨어와 소프트웨어 구성 요소 정보를 요구하지만, 여기에도 SBOM이라는 말은 없습니다.

SBOM은 ISO 27001 Annex A의 어떤 통제를 뒷받침하나요?

주로 5.9(정보 및 기타 관련 자산 목록), 5.19~5.22(공급업체와 ICT 공급망), 8.8(기술적 취약점 관리)입니다. 빌드 기록은 8.25, 8.29, 8.30에 부분적으로 관련됩니다. 8.26~8.28은 요구 사항, 설계, 코드에 관한 것으로 SBOM의 범위 밖입니다.

NIS2 고객은 소프트웨어 공급업체에 무엇을 요청하나요?

대개 보안 개발에 대한 설명, 납품 버전의 구성 요소, 취약점 처리 약속, 취약점 정보를 받는 방법, 취약점이 해당하지 않을 때의 이유입니다. 이러한 질문은 제21조 제3항과, 일부 분야의 경우 Implementing Regulation 2024/2690의 공급업체 관련 항목에서 나옵니다.

SBOM만으로 ISO 27001 통제 8.8의 증거가 충분한가요?

아닙니다. SBOM은 각 릴리스에 무엇이 들어 있는지 보여 줍니다. 통제 8.8은 취약점 정보를 입수하고, 노출을 평가하고, 조치한다는 증거도 요구합니다. SBOM에 지속적 재평가, 영향받은 릴리스 기록, 내린 결정을 함께 갖추세요.

컴플라이언스를 준수하는 것과 증거를 갖는 것은 어떻게 다른가요?

컴플라이언스는 감사인이나 고객이 판단하기에 프로세스가 프레임워크의 요구 사항을 충족한다는 뜻입니다. 증거는 그 프로세스가 작동함을 보여 주는 것입니다. SBOM은 몇몇 통제의 증거일 뿐, 어떤 프레임워크의 준수도 대신 이뤄 주지 않습니다.

컴플라이언스 증거로서의 SBOM: ISO 27001, SOC 2, NIS2