EU 사이버복원력법(Cyber Resilience Act, 이하 CRA)은 2027년 12월 11일부터 EU 시장에 출시되는 디지털 요소 포함 제품에 SBOM 작성 의무를 부과합니다. 기한이 다가오면서 “SBOM을 준비해야 한다”는 이야기는 많아졌지만, 정작 조문이 무엇을 요구하는지를 원문으로 확인한 자료는 드뭅니다. 확인해보니 요구 수준이 예상보다 훨씬 낮았고, 그 사실이 SBOM을 받는 쪽에는 오히려 더 중요한 문제였습니다.
조문이 실제로 요구하는 것
근거 조항은 Regulation (EU) 2024/2847의 ANNEX I, Part II, point (1)입니다. SBOM을 언급하는 부분의 원문은 다음과 같습니다.
identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products
Regulation (EU) 2024/2847, ANNEX I, Part II, point (1) — EUR-Lex 공식 영문본
핵심은 마지막 구절입니다. “covering at the very least the top-level dependencies” — 최소한 최상위 의존성은 포함하라는 뜻입니다. 바꿔 말하면 직접 의존성만 나열한 깊이 1짜리 SBOM도 CRA 관점에서는 완전한 준수입니다. 조문 어디에도 전이 의존성(transitive dependency)을 요구하는 문구는 없습니다.
CISA 2026은 더 많이 요구하지만, 하한선은 두지 않습니다
다른 기준은 어떨까요. 2026년 7월 공개된 CISA의 2026 Minimum Elements for a Software Bill of Materials는 Coverage 항목에서 이렇게 씁니다. 두 문장을 함께 읽어야 합니다.
An SBOM should include information for all components that make up the target software, including transitive dependencies. There is no minimum depth.
CISA, 2026 Minimum Elements for a Software Bill of Materials — Coverage
앞 문장은 CRA보다 더 많이 요구합니다. 전이 의존성까지 포함하라고 명시하니까요. 그런데 뒤 문장이 그 요구에서 강제력을 뺍니다. 몇 단계까지 내려가야 충족인지를 정하지 않으면, 받는 쪽은 “이 문서는 기준 미달”이라고 말할 근거가 없습니다.
정리하면 두 문서의 성격이 다릅니다. CRA는 바닥선을 낮게 정했고, CISA는 더 높은 것을 권고하되 바닥선을 정하지 않았습니다. 방향은 반대지만 결과는 같습니다 — 어느 쪽도 수신자에게 “깊이가 부족하다”고 거절할 근거를 주지 않습니다. “규제가 전체 의존성 트리를 요구한다”는 설명을 본 적이 있다면, 그 근거를 원문에서 직접 확인해보시길 권합니다.
그래서 2027년 12월 이후에 벌어질 일
규제는 물량을 만들지만 품질을 만들지는 않습니다. 미준수에 제재가 뒤따르는 의무이므로 공급사는 SBOM을 발행할 것입니다. 다만 발행 동기가 규제 준수라면, 합리적인 선택은 법적 최소선을 정확히 충족하는 문서입니다. 그 이상을 만들 이유가 조문에는 없습니다.
받는 쪽 입장에서는 이것이 문제가 됩니다. 유럽사이버보안청(ENISA)이 334개 조직의 응답을 받아 2026년 6월 펴낸 SBOM Adoption State of Play 2026 보고서가 그 상태를 보여줍니다. 보고서 기준 공급사 SBOM의 품질 격차 1위는 완성도로 27%였습니다. 같은 보고서에서 식별자 정확성이 17%, 취약점 참조가 12%로 뒤를 이었습니다.
깊이는 그 격차가 직접 드러납니다. 같은 보고서 기준 전체 깊이 분석이 필요하다는 응답은 24%입니다. 반면 실제로 받고 있다는 응답은 같은 보고서에서 14%에 그쳤습니다. 필요한 만큼 깊은 문서를 받지 못하는 조직이 이미 존재한다는 뜻입니다.
기한 쪽도 여유롭지 않습니다. 같은 보고서 조사에서 CRA가 요구하는 성숙도까지 걸릴 기간을 묻자 33%가 12개월 이내라고 답했습니다. 보고서 기준 추가 6개월이 24%, 2년 이상이 30%였고, 나머지 12%는 추정하지 못했습니다.
보고서 자체는 “기한을 놓칠 것”이라고 쓰지 않습니다. 다만 2026년 6월 시점에서 “2년 이상”은 2028년 중반 이후를 가리키므로, 응답자의 약 3분의 1은 2027년 12월 이후에야 목표 성숙도에 도달하게 되는 셈입니다. 이 계산은 보고서의 서술이 아니라 제가 응답 분포에서 끌어낸 추론입니다.
정리하면 이렇습니다. 앞으로 SBOM은 늘어나지만, 그중 상당수는 법적 기준을 통과하면서 취약점 전파를 추적하는 데는 쓸 수 없는 문서일 가능성이 큽니다. 그리고 받는 쪽은 그 차이를 구분할 도구를 아직 갖고 있지 않습니다.
실제 문서로 확인해보기
추상적인 우려가 아닙니다. 널리 쓰이는 오픈소스 프로젝트의 공개 릴리스 SBOM에서 이미 관찰됩니다. 컨테이너 서명 도구 cosign이 릴리스 자산으로 함께 배포하는 SPDX 문서를 직접 내려받아 측정한 결과는 다음과 같았습니다.
- 컴포넌트 255개가 나열되어 있습니다.
- 의존성 관계도 252건 기록되어 있습니다.
- 그런데 루트에서 측정한 최대 깊이는 1입니다. 직접 의존성만 있고 그 아래가 없습니다.
이 문서는 CRA 요건을 충족합니다. 기계 판독 가능한 표준 포맷이고, 컴포넌트가 문서화되어 있고, 최상위 의존성이 포함되어 있습니다. 동시에 이 문서로는 전이 의존성에 발생한 취약점이 제품에 도달하는지 판단할 수 없습니다. 그 정보 자체가 문서에 없기 때문입니다.
cosign만의 특성은 아닙니다. 직접 내려받아 측정한 공개 SBOM 51건 기준으로, 직접 의존성만 있는 평면 구조가 45%였습니다.
판정을 분리해서 출력하기
이 문제를 다루는 방법을 도구로 구현해봤습니다. 핵심 설계는 단순합니다. 규제 준수 판정과 보안 실효성 판정을 절대 하나의 점수로 합치지 않는 것입니다.
합치면 어떻게 되는지 생각해보면 이유가 분명해집니다. 준수 여부와 실효성을 평균 내면, 법적으로만 통과한 얕은 문서와 실제로 쓸 수 있는 깊은 문서가 중간 어딘가에서 같은 숫자를 받습니다. 그 순간 구분하려던 대상이 사라집니다.
앞서 본 cosign 문서를 넣으면 출력은 이렇게 나옵니다.
EU CRA — MEETS the CRA SBOM floor, but 3 security gap(s) remain
machine-readable format met — SPDX SPDX-2.3 [...]
components documented met — 255 component(s) listed
top-level dependencies met — depth 1 from the in-degree-zero root — direct
dependencies, nothing below them
Meeting this floor is not evidence of a usable SBOM. The clause sets a
minimum [...] so a document can satisfy it and still be unusable for
tracing vulnerabilities. [...]
What this document cannot support:
- Vulnerability propagation cannot be traced past direct dependencies — a
flaw in a transitive component will not appear here at all (verdict FLAT,
depth 1)
- 2 of 255 components cannot be matched against a vulnerability database
(no PURL and no CPE)
- 2 component(s) are listed but never appear in the dependency graph, so
their route into the product is unstated (orphans)실제 출력을 [...]로 표시한 곳에서만 줄여 옮긴 것입니다. 전체 원문은 저장소 README에 있습니다.
준수 판정은 요건별로 근거와 함께 제시하고, 그 아래에 이 문서로 할 수 없는 일을 따로 나열합니다. 두 결과는 JSON 출력에서도 별도 키로 분리되어 있어서, CI 파이프라인이 준수 여부만 보고 게이팅하더라도 무엇이 누락되었는지는 같은 응답 안에서 확인할 수 있습니다.
구현하면서 조심한 부분
준수 판정에는 조문에 없는 요구사항을 넣지 않았습니다. 예를 들어 컴포넌트에 PURL이나 CPE 같은 식별자가 있는지는 취약점 조회에 필수적이지만, 조문은 식별자를 요구하지 않습니다. 그래서 식별자 부족은 준수 판정이 아니라 실효성 항목으로 분류했습니다. 도구가 규제 해석을 임의로 확장하면 그 출력을 감사 근거로 쓸 수 없게 됩니다.
반대 방향의 절제도 필요했습니다. 이 판정은 문서에 적힌 내용만 검사합니다. 최상위 의존성이 전부 나열되었는지, 즉 공급사가 무언가를 빠뜨렸는지는 원본 빌드 산출물을 다시 스캔해야만 알 수 있습니다. 그래서 준수 판정 아래에는 그 한계를 항상 함께 출력하도록 했습니다. “통과”라는 단어만 잘라서 인용되는 상황을 막기 위한 장치입니다.
정리
- CRA ANNEX I은 SBOM에 대해 최상위 의존성까지만 요구합니다. 깊이 1짜리 문서도 준수입니다.
- CISA 2026은 전이 의존성까지 포함하라고 하면서도 최소 깊이는 규정하지 않습니다. 방향은 CRA와 반대지만, 어느 쪽도 “깊이가 부족하다”고 거절할 근거는 주지 않습니다.
- 따라서 2027년 12월 이후 “CRA 준수”라는 표현만으로는 그 SBOM이 보안 업무에 쓸 수 있는지 판단할 수 없습니다.
- SBOM을 받는 입장이라면 준수 여부와 실효성을 분리해서 확인하고, 공급사에 요청할 때도 두 가지를 구분해서 요구하는 편이 낫습니다.
규제는 바닥선을 정할 뿐입니다. 그 위를 채우는 일은 여전히 받는 쪽의 몫으로 남습니다.
📌 함께 보시면 좋은 글
이직·퇴사·연봉 협상을 혼자 판단하기 어렵다면
1:1 개발자 커리어 상담 신청하기 →
※ 본 글은 AI(Claude)의 초안을 기반으로 편집자 검수를 거쳐 발행되었습니다. (한국 AI기본법 대응 고지)
이직·퇴사, 지금 움직여도 될지 헷갈리시나요?
막연히 불안한 건지, 정말 시점이 온 건지 판단이 어려울 때가 있습니다.
5분 체크리스트로 지금 상태를 먼저 정리해보세요.
결론을 대신 내리기보다, 스스로 판단할 기준을 잡는 데 도움을 드립니다.
아직 확신이 없다면, 지금이 ‘고민 단계’인지부터 먼저 점검해보세요