SBOM 작성은 권장 사항이 아니라 법적 의무입니다. 부속서 I 제2부(취약점 처리 요구사항) 제1항은 제조업체에게 다음을 요구합니다.
CRA의 여러 조항은 해석의 여지를 남겨 두지만, 이 조항은 그렇지 않습니다. “기계판독 가능한 형식”과 “최소한 최상위 종속성”은 반드시 지켜야 하는 최저 기준이며, 다른 수단으로 대신할 수 없습니다.
법이 정한 최저 기준은 최상위 종속성입니다. 다만 이것은 출발점일 뿐, 목표로 삼을 수준은 아닙니다. 최상위 종속성만 담은 SBOM으로도 법 조문은 충족할 수 있지만, 실제 취약점 관리에는 부족한 경우가 대부분입니다. 가능한 범위까지 전이(간접) 종속성을 포함하시기를 권합니다.
CRA 부속서 I 제2부 (1)이 직접 요구하는 내용은 두 가지입니다. SBOM은 통용되는 기계판독 가능한 형식이어야 하고, 최소한 최상위 종속성을 포함해야 합니다. 세부 필드는 집행위원회가 이행법으로 정할 수 있습니다(제13조). 그 전까지 아래 표의 나머지 항목은 업계 기준(NTIA 최소 요소, BSI TR-03183 등)을 참고한 실무 권장 사항입니다.
| 항목 | 구분 | 설명 |
|---|---|---|
| 구성요소명 | 명문 요건 충족의 전제 | 라이브러리 · 패키지 · 모듈의 고유 식별자 |
| 버전 | 명문 요건 충족의 전제 | 정확한 버전 문자열. 버전 범위만으로는 취약점을 식별할 수 없습니다. |
| 종속 관계 | 최상위 종속성은 명문 요건 | 직접 · 전이 종속성 구분, 가능하면 종속성 그래프까지 |
| 공급자 · 출처 | 실무 권장 | 배포자, 벤더 또는 오픈소스 프로젝트명 |
| 암호학적 해시 | 실무 권장 | 구성요소별 SHA-256 이상의 무결성 값 |
| 라이선스 식별자 | 실무 권장 | SPDX 라이선스 표현식 (예: Apache-2.0, MIT) |
groupId:artifactId 형태가 아니면 조회 결과가 0건으로 나오는데, 이것이 오류가 아니라 “취약점 없음”처럼 보인다는 점이 문제입니다. 대부분의 생성 도구가 purl을 자동으로 넣어 주지만, 결과 파일에서 직접 확인하시기 바랍니다.
최신 빌드 환경은 대부분 별도 비용 없이 빌드 시점에 SBOM을 자동으로 생성할 수 있습니다.
소스 디렉터리, 파일시스템, 컨테이너 이미지로부터 SPDX와 CycloneDX를 생성하는 오픈소스 CLI입니다. 가장 범용적으로 쓸 수 있는 도구입니다.
# 소스 디렉터리에서 syft scan dir:. -o spdx-json > sbom.json # 컨테이너 이미지에서 (OS 패키지 포함) syft scan registry.example.com/app:1.2.3 -o cyclonedx-json > sbom.json
SBOM을 확정하기 전에 모든 구성요소를 알려진 취약점 데이터와 대조하십시오. 부속서 I 제1부 (2)(a)는 제품을 알려진 악용 가능한 취약점이 없는 상태로 출시하도록 요구합니다. 수정 버전이 나와 있는 취약점을 그대로 둔 채 출시하면 이 요건을 위반할 가능성이 큽니다.
웹·모바일 환경에서는 SBOM 생성이 사실상 자동화되어 있습니다. 하지만 한국의 산업용·차량용·임베디드 제조사가 실제로 다루는 환경은 사정이 다릅니다.
| 환경 | 대응 방법 |
|---|---|
| Yocto · OpenEmbedded | create-spdx 클래스를 쓰면 빌드 시 SPDX가 생성됩니다. 이미지 레시피에 INHERIT += "create-spdx"를 추가하십시오. |
| Buildroot | 구버전에는 내장 기능이 없습니다. legal-info 출력물을 변환하거나, 빌드된 이미지에 Syft를 실행하십시오. |
| Conan | conan graph info 결과를 CycloneDX로 변환해 주는 플러그인이 있습니다. |
| vcpkg | 설치 시 SPDX가 생성됩니다 (vcpkg install 산출물에 포함). |
| 수동 통합 코드 · 벤더 제공 바이너리 | 자동 생성 방법이 없습니다. 구성요소 목록을 직접 관리하고, 공급업체에 SBOM 제출을 요구하십시오. |
SBOM은 한 번 만들고 끝나는 산출물이 아니라, 제품 지원 기간 내내 계속 갱신해야 하는 문서입니다. 패치된 구성요소, 새로 추가된 종속성, 제거된 지원종료 구성요소, 공급망 변경 사항을 반영해야 합니다.
SBOM을 포함한 기술문서는 모든 버전을 최초 시장 출시 후 최소 10년간 보관해야 합니다.
갱신된 SBOM은 지속적 모니터링의 기초 자료가 됩니다. 이 내용은 두 번째 가이드에서 다룹니다.
An SBOM is a legal requirement, not a best practice. Annex I Part II (vulnerability handling requirements), point 1, requires manufacturers to:
Unlike several CRA provisions that leave room for interpretation, this one does not. “Machine-readable format” and “at the very least the top-level dependencies” are floors, not aspirations.
The legal floor is top-level dependencies — but treat it as a floor, not a target. An SBOM that stops there satisfies the letter of the law while usually being insufficient for real vulnerability management. Map transitive dependencies wherever feasible.
What Annex I Part II (1) of the CRA requires in terms is an SBOM in a commonly used, machine-readable format covering at the very least the top-level dependencies. The Commission may specify the elements by implementing act (Article 13); until then, the remaining rows below are good practice drawn from industry baselines such as the NTIA minimum elements and BSI TR-03183.
| Field | Basis | Description |
|---|---|---|
| Component name | Needed to meet the stated requirement | Unique identifier for the library, package or module |
| Version | Needed to meet the stated requirement | Exact version string; version ranges are insufficient |
| Supplier / origin | Good practice | Publisher, vendor or open-source project name |
| Dependency relationships | Top level: stated requirement | Direct vs transitive; dependency graph where feasible |
| Cryptographic hash | Good practice | SHA-256 or stronger integrity value per component |
| Licence identifier | Good practice | SPDX licence expression (e.g. Apache-2.0, MIT) |
groupId:artifactId returns zero results — and that reads as “no vulnerabilities”, not as an error. Most generators emit purls automatically; verify it in the output.
Most modern build environments can produce an SBOM at build time at no extra cost.
Open-source CLI producing SPDX and CycloneDX from source directories, filesystems and container images. The most general-purpose option.
# from a source directory syft scan dir:. -o spdx-json > sbom.json # from a container image (includes OS packages) syft scan registry.example.com/app:1.2.3 -o cyclonedx-json > sbom.json
Before finalising any SBOM, screen every component against known-vulnerability data. Annex I Part I (2)(a) requires products to be placed on the market without known exploitable vulnerabilities. Shipping a component with a known vulnerability for which a fix exists is very likely to breach that requirement.
On web and mobile stacks SBOM generation is effectively solved. In the environments Korean industrial, automotive and embedded manufacturers actually work in, it is not.
| Environment | Approach |
|---|---|
| Yocto · OpenEmbedded | The create-spdx class emits SPDX at build time. Add INHERIT += "create-spdx" to your image recipe. |
| Buildroot | No built-in support on older versions. Convert from legal-info output, or run Syft against the resulting image. |
| Conan | A plugin converts conan graph info output to CycloneDX. |
| vcpkg | Emits SPDX on install, included in the vcpkg install output. |
| Hand-integrated or vendor binaries | No automated path. Maintain the component list manually and require SBOMs from your suppliers. |
An SBOM is a living artefact, not a one-off deliverable. It is updated across the product's supported lifecycle to reflect patched components, new dependencies, removed end-of-life components and supply-chain changes.
All versions of the technical documentation, SBOMs included, must be retained for at least 10 years from first market placement.
The updated SBOM is the input to continuous monitoring — covered in the second guide.
제14조는 서로 다른 두 가지 사안을 다루며, 마감 시한도 다릅니다.
두 경우 모두 “인지한 시점(becoming aware)”부터 시계가 작동합니다. 사내 확인 절차가 끝난 시점이 아닙니다.
인지 시각을 넣으면 위 두 시계를 그대로 적용해 마감 시각을 계산합니다. 계산은 브라우저 안에서만 이루어지며, 입력값은 저장되거나 전송되지 않습니다.
보고는 ENISA가 운영하는 단일 보고 플랫폼(Single Reporting Platform)을 통해 제출하며, 지정된 조정 CSIRT와 ENISA에 동시에 전달됩니다. 두 곳에 따로 제출할 필요는 없습니다.
제출 이후에는 해당 CSIRT가 관련 회원국의 CSIRT 및 시장감시당국으로 배포합니다.
EU 역내에 사업장이 있는 제조자는 주된 사업장(main establishment)이 있는 회원국의 조정 CSIRT에 보고합니다. 주된 사업장은 사이버보안 관련 의사결정이 주로 이루어지는 곳이며, 판단이 어려운 경우 종업원 수가 가장 많은 회원국을 기준으로 합니다.
EU 역내에 사업장이 없는 한국 제조자에게는 제14조 제7항이 다음 순서를 적용합니다.
| 순위 | 기준 |
|---|---|
| 1 | 가장 많은 제품에 대해 활동하는 공인대리인이 설립된 회원국 |
| 2 | 공인대리인이 없는 경우, 가장 많은 제품을 출시하는 수입자의 회원국 |
| 3 | 그다음, 가장 많은 제품을 공급하는 유통업자의 회원국 |
| 4 | 위 어느 것도 확정할 수 없는 경우, 이용자 수가 가장 많은 회원국 |
아닙니다. 제18조는 “제조자는 서면 위임을 통해 공인대리인을 지정할 수 있다”고 규정합니다. 선택 사항입니다.
다만 위 순위 규정을 고려하면, 지정 여부는 규제 창구를 스스로 정할 것인지 아니면 공급망 구성에 맡길 것인지의 문제가 됩니다. 다수의 EU 수입자를 통해 공급하는 기업이라면 지정하는 편이 실무적으로 유리합니다.
플랫폼 운영 방식에서 가장 간과되기 쉬운 부분입니다.
ecas.ec.europa.eu) 인증을 사용합니다.초기에는 API가 제공되지 않으므로, 제출은 웹 인터페이스를 통한 수동 작업으로 이루어집니다.
24시간 시계는 “인지한 시점”부터 작동합니다. 따라서 실무의 핵심은 보고 절차 자체가 아니라, 자사 구성요소에 영향을 주는 취약점을 얼마나 빨리 인지하는가입니다.
주간 다이제스트 메일이나 분기별 점검으로는 이 요건을 충족하기 어렵습니다. 필요한 것은 SBOM의 구성요소 목록을 취약점 데이터베이스와 지속적으로 대조하고, 신규 등재 시 담당자에게 즉시 알리는 체계입니다.
특히 실제 악용 여부는 KEV(Known Exploited Vulnerabilities) 목록과 같은 자료로 확인되므로, 자사 SBOM 구성요소와 KEV 등재 항목의 교차 지점은 제14조 보고 필요성을 우선 검토할 대상입니다. 다만 KEV 는 모든 악용 사례를 담지 않으므로 미등재가 악용되지 않았다는 뜻은 아니며, KEV 등재만으로 보고 의무가 확정되지도 않습니다. 보고 여부는 자사 제품에 대한 실제 영향, 실제 악용 증거, 인지 시각을 근거로 판단하고, 그 판단 근거를 기록해 두십시오. SBOM 취약점 분석기가 이 교차 지점을 계산해 KEV 등재 항목을 결과 최상단에 표시합니다. 다만 한 번의 조회이므로, 지속적 모니터링 체계를 대체하지는 않습니다.
Article 14 covers two distinct things, on different clocks:
In both cases the clock starts when you become aware — not when your internal review concludes.
Enter the moment you became aware and this applies the two clocks above. Everything is computed in your browser; nothing is stored or sent.
Reports are submitted through ENISA's Single Reporting Platform, which routes them simultaneously to your designated coordinating CSIRT and to ENISA. You do not file twice.
From there the CSIRT disseminates to the CSIRTs and market surveillance authorities of affected Member States.
A manufacturer established in the Union reports to the coordinating CSIRT of the Member State of its main establishment — where cybersecurity decisions are predominantly taken, or failing that, where it has the most employees.
For a Korean manufacturer with no EU establishment, Article 14(7) applies this waterfall:
| Order | Test |
|---|---|
| 1 | Member State where the authorised representative acting for the highest number of products is established |
| 2 | Failing that, Member State of the importer placing the highest number of products |
| 3 | Then the Member State of the distributor making available the highest number |
| 4 | Failing all of the above, the Member State with the highest number of users |
No. Article 18 says a manufacturer may, by written mandate, appoint one. It is optional.
But read against the waterfall above, the real question is whether you choose your regulatory counterparty or let your supply chain choose it for you. For anyone shipping through several EU importers, appointing one is the practical option.
This is the most-missed part of how the platform actually works.
ecas.ec.europa.eu).No APIs are provided initially, so submission is manual through the web interface.
The 24-hour clock starts on awareness. So the operative question is not the reporting procedure — it is how quickly you find out that a vulnerability affects your components.
A weekly digest email or a quarterly review does not meet that bar. What it takes is continuously matching the component list in your SBOM against vulnerability data, and alerting a named person the moment something lands.
Actual exploitation is signalled by sources such as the KEV (Known Exploited Vulnerabilities) catalogue, so the intersection of your SBOM components with KEV entries is where to assess Article 14 reporting first. KEV does not list every exploited vulnerability, so absence from it does not mean no exploitation, and a KEV listing does not by itself settle the obligation. Decide on the actual impact on your product, the evidence of active exploitation and when you became aware, and record the basis for that decision. The SBOM Vulnerability Analyzer computes that intersection and sorts listed vulnerabilities to the top of its results — though it is a one-shot check, and does not substitute for continuous monitoring.
Regulation (EU) 2024/2847이 제조업체에게 지우는 의무를 조항별로 정리했습니다. 조항 번호는 관보 원문에서 직접 확인한 것입니다. What Regulation (EU) 2024/2847 puts on a manufacturer, clause by clause. Every reference was checked against the Official Journal text itself.
체크 상태는 이 화면에만 유지되며 저장되거나 전송되지 않습니다. 새로고침하면 초기화되므로, 기록이 필요하면 내려받으십시오. Tick state lives only in this page while it is open — nothing is stored or sent. It resets on reload, so download it if you need a record.
SBOM을 만들었다면 취약점 분석기로 바로 대조해 볼 수 있습니다. 아직 적용 여부가 불확실하다면 적용 진단부터 시작하십시오.
SBOM 취약점 분석기 → CRA 적용 진단 → 문의하기Once you have an SBOM, run it straight through the analyzer. If you are not yet sure the CRA applies to you, start with the scope check.
SBOM Vulnerability Analyzer → CRA Fast Check → Get in touch근거: Regulation (EU) 2024/2847 (사이버복원력법) 부속서 I 제2부, 제14조, 제16조, 제18조 · 제품 분류 기술설명 — 집행위원회 이행규정 (EU) 2025/2392 · ENISA 단일 보고 플랫폼 공개 자료 · 시행일자는 유럽집행위원회 공식 요약 기준. 본 가이드는 참고용이며 법률 자문이 아닙니다. Basis: Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex I Part II and Articles 14, 16 and 18 · category technical descriptions — Commission Implementing Regulation (EU) 2025/2392 · ENISA Single Reporting Platform published material · dates per the European Commission's official summary. Indicative only; this guide does not constitute legal advice.