SOC 2 플랫폼은 통제가 실행된다는 사실을 보여 줍니다. CRACI는 빌드에 무엇이 들어 있었는지 기록합니다.

이 페이지가 다루는 구성

많은 SaaS 팀이 결국 같은 구성에 이릅니다. Syft나 Trivy 같은 생성 도구가 CI에서 SBOM을 만들고, 취약점 스캐너가 리포지토리를 감시하며, 컴플라이언스 자동화 플랫폼이 GitHub와 클라우드 계정에 연결해 SOC 2용 증거를 수집합니다. 이 구성은 잘 작동합니다. 감사인도 이를 인정하고, 감사 전 일주일을 스크린샷 찍는 데 쓰는 사람도 없습니다.

이런 플랫폼은 이 일을 잘합니다. Vanta는 "클라우드, ID, 코드, 기기 도구에 읽기 전용으로 연결"하고 "증거를 자동으로 수집해 통제에 매핑"하며, 1,200개가 넘는 자동화 테스트를 매시간 실행한다고 설명합니다. Drata는 "클라우드 인프라, ID 제공업체, HR 시스템, 코드 리포지토리, 티켓팅 도구 등"에 연결해 증거를 수집하고 SOC 2 통제에 매핑합니다. 깔끔한 SOC 2 보고서가 목표라면 이 작업에 맞는 도구입니다.

이 페이지는 더 좁은 질문을 다룹니다. 그 증거가 SBOM 자체에 대해 무엇을 말해 주는가 하는 것입니다.

SOC 2 점검이 실제로 묻는 것

SOC 2 검토는 AICPA Trust Services Criteria를 기준으로 보고합니다. SBOM과 가장 가까운 기준은 CC7.1입니다.

"목표를 달성하기 위해 조직은 탐지 및 모니터링 절차를 사용하여 (1) 새로운 취약점을 유발하는 구성 변경과 (2) 새로 발견된 취약점에 대한 노출을 식별한다."

AICPA, 2017 Trust Services Criteria, CC7.1

이 기준은 결과를 기술합니다. 방법과 그 뒤에 있는 구성 요소 목록의 깊이는 조직과 감사인에게 맡깁니다. 그래서 자동화 테스트는 대개 통제가 갖춰져 운영되는지를 묻습니다. 스캐너가 연결되어 있는지, 실행되었는지, 발견 사항이 정책에 따라 처리되었는지입니다. 타당한 질문이며, 바로 이것이 체크박스입니다.

이 점검이 묻지 않는 것은 스캔의 근거가 된 SBOM이 릴리스에 포함된 모든 것을 나열했는가입니다. SBOM에 한 번도 나열되지 않은 구성 요소에 있는 취약점은 어떤 것과도 매칭될 수 없으므로, 스캔은 깨끗하게 나오고 통제는 여전히 녹색으로 표시됩니다.

녹색 점검과 완전한 SBOM이 갈라지는 지점

SBOM 생성 도구는 눈앞에 있는 파일을 바탕으로 작동하며, 그 때문에 생기는 공백은 각 도구의 문서에서도 드러납니다.

• 잠금 파일을 커밋하지 않는 expressjs/express 5.2.1에서는 잠금 파일로 종속성을 해석하는 생성 도구가 해석할 대상이 없습니다. 그래도 문서는 반환할 수 있으며, GitHub Actions나 워크플로 파일처럼 그 밖에 인식한 항목은 나열하지만 package.json에 선언된 npm 종속성은 하나도 나열하지 않습니다.
• 생성 도구마다 무엇을 구성 요소로 볼지 스스로 정하기 때문에, 같은 체크아웃에서도 서로 다른 목록을 반환합니다. GitHub의 종속성 그래프 내보내기는 그보다 더 멀리 있습니다. GitHub가 리포지토리에 대해 아는 정보로 만들어지며, 고정된 커밋이 아니라 기본 브랜치를 읽습니다.
• 대부분의 생성 도구에는 이 정보를 가져올 소스가 없으므로, 대부분의 문서에서 NTIA 공급자 필드는 비어 있습니다.

어느 도구도 고장 난 것은 아닙니다. 각 도구는 지정된 파일을 읽었고, 표준 형식의 유효한 문서를 일정대로 생성했습니다. 컴플라이언스 테스트 입장에서는 통제가 운영된 것입니다. 그래도 SBOM은 소프트웨어를 설명하지 못했습니다.

CRACI가 증거에 더하는 것

CRACI는 GitHub Actions 러너를 대체합니다. runs-on을 craci로 바꾸면 되고, 실행은 계속 GitHub UI에 표시됩니다. SBOM은 빌드가 진행되는 동안 그 러너 안에서 생성됩니다. 패키지를 인식하는 프록시가 패키지 소스로 가는 트래픽을 관찰하므로, 기록에는 파일상 가져와야 한다고 적힌 것이 아니라 작업이 실제로 가져온 것이 반영됩니다.

완전성은 가정하지 않고 명시합니다

모든 작업과 모든 캐시에는 Complete, Complete with connections, Incomplete, Unavailable, Not recorded의 5가지 완전성 상태 중 하나가 부여됩니다. 종속성 증거가 캐시와 함께 전달되므로, 웜 캐시에서 복원된 패키지도 조용히 빠지지 않고 이어집니다. 기록이 불완전하면 불완전하다고 표시합니다.

이는 표준이 향하는 방향과 일치합니다. CISA와 파트너 기관이 발표한 2026년 SBOM 최소 요소는 SBOM 작성자에게 필드를 조용히 비워 두지 말고 "해당 정보를 SBOM 작성자가 알지 못하는지 여부를 명시적으로 밝힐 것"을 요구합니다.

감사인이 받는 형식의 증거

SBOM은 구성 요소에서 발견된 취약점을 포함해 CycloneDX 또는 SPDX로 내보낼 수 있습니다. 공개 REST API는 SBOM, 작업의 네트워크 추적, 출처 증명 데이터를 반환하므로, 같은 기록을 감사 증거가 보관되는 어느 곳으로든 보낼 수 있습니다.

어디에 무엇이 배포되어 있는지 보여 주는 인벤토리

CRACI의 인벤토리 뷰는 어떤 소프트웨어 버전이 어떤 제품에 배포되어 있는지 전 세계 범위로 정확히 보여 줍니다. 새로운 취약점이 공개되면 릴리스 노트와 스프레드시트를 짜 맞추는 대신, 영향을 받는 버전을 실행하는 제품을 바로 확인할 수 있습니다.

SOC 2 플랫폼은 그대로 두세요

CRACI는 컴플라이언스 자동화 플랫폼이 아니며 이를 대체하지도 않습니다. 정책, 접근 권한 검토, 기기 점검, 공급업체 설문을 관리하지 않습니다. 두 도구는 서로 다른 질문에 답합니다. 컴플라이언스 플랫폼은 통제가 존재하고 실행된다는 사실을 보여 줍니다. CRACI는 빌드가 무엇을 가져왔는지, 그리고 그 기록이 완전한지를 기록합니다.

EU에 소프트웨어를 판매하기 시작하면 이 차이는 더 커집니다. EU Cyber Resilience Act는 제조사가 구성 요소를 식별하고 문서화하도록 요구하며, 그 방법으로 "최소한 제품의 최상위 종속성을 포함하는, 일반적으로 사용되고 기계가 읽을 수 있는 형식의 소프트웨어 자재 명세서를 작성"할 것을 규정합니다(부속서 I, 파트 II). 부속서 VII은 SBOM을 기술 문서에 포함시키고 시장 감시 당국이 이를 요청할 수 있도록 합니다. SOC 2 보고서는 조직이 통제를 어떻게 운영하는지를 증명합니다. CRA SBOM은 특정 제품을 설명합니다. CRA 개요에서 일정을, CRA 컴플라이언스 페이지에서 CRACI가 자동화하는 내용을 확인할 수 있습니다. CRACI는 더 넓은 CRA 컴플라이언스 프로세스에 필요한 공급망 가시성과 증거의 상당 부분을 자동화하지만, 그것만으로 규정을 준수하게 해 주지는 않습니다.

같은 증거는 ISO 27001과 NIS2에도 쓰입니다. 통제별 대응 관계는 ISO 27001, SOC 2, NIS2 증거로서의 SBOM을 참조하세요.

감사에 영향을 주지 않고 시험해 보는 방법

1. SBOM이 이미 SOC 2 증거로 쓰이고 있는 리포지토리 하나를 고릅니다.
2. runs-on을 craci로 바꿔 해당 릴리스 워크플로가 CRACI에서 실행되도록 합니다.
3. 기록된 SBOM을 지금 생성하는 SBOM과 구성 요소 단위로 비교하고, 작업의 완전성 상태를 확인합니다.
4. 그 차이를 증거에 포함할지 결정합니다.

빌드 시점 SBOM 생성과 CRA 증거에 대해 더 읽어 보시거나, 보안 페이지에서 저희가 자체 통제를 어떻게 문서화하는지 확인해 보세요.