Based on a survey of seven tool categories through their official repositories and documentation, this document lays out what to reuse from existing tools, what to extend or build new, in what order to build it, and what policy schema should define the matrix. The acquisition strategy was not fixed in advance but determined from the survey results, and the premise is that the organization already operates an existing SBOM platform (Dependency-Track).

1. Three Core Judgments

The standard path for generation, verification, storage, and model scanning already works with open source software. Theaibom command in cdxgen actually produces CycloneDX 1.6 AI BOMs, sbomqs and OPA check field conformance, Dependency-Track ingests the software layer, and ModelScan and sigstore model-signing reinforce model integrity. There is no need to build everything from scratch in-house.

Standardizing the format on CycloneDX 1.6 is the more realistic choice. The SPDX 3.0 AI Profile has richer expressive power, but no mature tool actually generates it, and Dependency-Track cannot ingest SPDX. SPDX 3.0 is kept as a standard to track, while CycloneDX is set as the primary operational format.

Where new construction is unavoidable is narrow and clear: the policy layer that checks AI-specific fields, an inventory that treats models and datasets as first-class objects, and the determination of license usage restrictions. Everything else is covered by reuse or extension.

2. Reuse Determinations by Area

In summary, of the thirteen areas, seven are reuse, three are extension, and three are new. The three new areas — AI- and role-specific conformance rules, the model/data inventory, and license usage-restriction determination — are where this project’s unique value is concentrated.

3. Build Priority

P0 — A Minimal Working Pipeline (Reuse-Focused)

The first step is to wire together off-the-shelf tools into an end-to-end pipeline. Generation produces CycloneDX 1.6 with cdxgenaibom, model files are scanned with ModelScan and signed with sigstore, and the results are uploaded to Dependency-Track to obtain software-layer vulnerabilities and impact analysis. Validation checks the presence of required fields with an sbomqs custom policy. Almost all of this stage is reuse, so it delivers value quickly.

P1 — Extending the AI-Specific Layer

The next step adds new value. Codify the matrix into a policy schema to implement role-specific conformance checking (Section 4), and carry models and datasets through CycloneDXproperties or external references to secure inventory traceability. Augment the license pipeline with an AI license dictionary (RAIL, OpenRAIL, Llama, Gemma, OpenMDW, CDLA), and receive model risk as huntr CVEs relayed through NVD.

P2 — New and Research Areas

Last are the parts where standards and research still need to mature. Automatic extraction of deep fields such as dataset statistics or bias, automatic determination of license usage restrictions, and data poisoning are handled through provenance and integrity traceability instead of detection. Bring SPDX 3.0 generation on board once the tool ecosystem matures, but for now keep it only as a standard to track. When Dependency-Track’s support for model/data classifiers (issue #4361) lands, promote P1’s workaround to a first-class inventory.

4. Policy Schema Design

Defining the matrix’s “element x required/optional x role” as a machine-readable policy is the core of this toolset. Since the survey found no tool that treats role-specific required sets as a first-class concept, this must be designed directly. It is split into two layers.

4.1 Field Registry

A table mapping each of the G7’s 50 elements to a CycloneDX path (and, eventually, an SPDX path) is kept in one place. TheAI BOM Field Requirements Matrix already contains an element-by-element source mapping, so moving it into a machine-readable form looks like this.

# field-registry.yaml — maps G7 elements to BOM pathsmodel_license:g7:Model licensecyclonedx:"components[?type=='machine-learning-model'].licenses"spdx:"Relationship(hasDeclaredLicense) from AIPackage"dataset_provenance:g7:Dataset provenancecyclonedx:"components[?type=='data'].data[].governance"spdx:"DatasetPackage.originatedBy / dataCollectionProcess"vulnerability_referencing:g7:Vulnerability referencingcyclonedx:"vulnerabilities[] or externalReferences[?type=='vcs']"spdx:"VulnAssessmentRelationship"

4.2 Role-Specific Policy Files

The required set for each of production, ingestion, and supplier is kept as a separate policy file. This simply carries over the role column of the matrix.

# policy/supplier.yaml — required elements for supplier submission (Section 4.6, 20 supplier-required elements)required:-sbom_author-sbom_data_format_name-sbom_data_format_version-sbom_timestamp-sbom_dependency_relationship-system_name-system_components-system_producer-system_version-model_name-model_identifier-model_version-model_producer-model_license-dataset_name-dataset_identifier-dataset_provenance-dataset_sensitivity-dataset_license-vulnerability_referencingrecommended:-model_timestamp-dataset_content-model_hash_value

4.3 Determination Engine

Two engines are recommended together. For a quick start, an sbomqs custom policy (YAML) puts the role-specific files into operation today with no engine to learn, converting the fulfillment rate into a score. Where expressiveness is needed, OPA/Rego (conftest) branches on the input BOM’s role value to determine the required set. Because Rego follows the field registry’s paths to evaluate presence, it can express conditional requirements and cross-field consistency as well.

# policy/aibom.rego — skeleton for role-specific required-field checkingpackageaibomdeny[msg]{role:=input.metadata.properties[_].value# e.g. "supplier"req:=data.policy[role].required[_]notfield_present(req)msg:=sprintf("Required element missing: %s (role: %s)",[req,role])}

OSCAL is a tool built for expressing security controls, which makes it more than SBOM fields need, and it does not execute validation on its own, so it is not adopted. It is worth considering only if there arises a need to produce upper-level artifacts for regulatory or audit purposes (a requirements catalog, an assessment result report) in a federal-friendly format.

5. Reference Architecture and Dependency-Track Integration

The BOM for an AI system splits into a software dependency layer and a model/dataset layer. Dependency-Track handles the former layer right now, and does not yet accept the latter as a first-class citizen (issue #4361 is open as of this research and may change later). Integration is therefore split by layer.

Figure 4. The common pipeline and the two layers it splits into after validation(compiled from the survey)

The software layer needs almost no extra work. cdxgen turns an ML project’s PyPI or npm dependencies into CycloneDX, which is uploaded to Dependency-Track, correlating vulnerabilities against OSV and NVD and even providing impact analysis for “which projects use this component?” CVEs that huntr issued for ML libraries are also caught, passing through NVD.

The model/dataset layer is routed around until classifier support arrives. In the short term, models and datasets are uploaded as generic components, while core model card fields are carried through CycloneDXproperties or external references to preserve them. Discoverability is limited, but traceability is preserved. Threats unique to model files (unsafe pickle, backdoored weights) don’t fit the CVE matching model, so they are checked separately with ModelScan and the results are linked to policy or tickets.

6. Limitations and Items Requiring Verification

The tool facts in this strategy were confirmed against each project’s official repository and documentation. The following require reconfirmation before adoption.

The licensing area carries the risk of a mismatch between what is declared and what is actually true. The so-called permissive-washing risk, in which the license declared on a platform diverges from the actual component license of the model or dataset, is well known, and it compounds an existing limitation: existing software license tools cannot parse model cards or dataset cards, or trace training data provenance. This toolset does not promise automatic detection for this and leaves verifying the match between declared license and actual output as a new-build target.

The timing of Dependency-Track’s support for model/data classifiers (#4361) is an external schedule outside our control. Because P1’s model/data inventory depends on this schedule, it should be designed with the workaround (preservingproperties) as the default, promoting to first-class inventory once classifier support lands.

GUAC’s AI-specific handling, OSV’s model-specific record scheme, and any connector letting Dependency-Track directly consume huntr Insights and ModelScan results are all confirmed absent or unverifiable. No standard yet links model risk feeds and SBOM inventories, so this connection has to be filled with custom glue code.

There is no production tool for data poisoning detection. This toolset does not promise automatic poisoning detection and limits itself to traceability and preventive controls that record data provenance, hashes, and whether verification passed.

7. References

The tool determinations in this article were confirmed against each project’s official repository and documentation as primary sources. All access dates are 2026-06.

A1. CycloneDX / cdxgen Project.cdxgen — AI/ML BOM generation and theaibom CLI,--spec-version.https://github.com/CycloneDX/cdxgen (accessed 2026-06). —Used for: basis that cdxgen’saibom automatically generates CycloneDX 1.6 AI BOMs.

A2. CycloneDX.Machine Learning Bill of Materials (ML-BOM) Capability Overview.https://cyclonedx.org/capabilities/mlbom/ (accessed 2026-06). —Used for: standard basis that CycloneDX 1.6 definesmachine-learning-model and modelCard.

A3. SPDX.SPDX 3.0.1 — AI Profile Specification.https://spdx.github.io/spdx-spec/v3.0.1/model/AI/AI/ (accessed 2026-06). —Used for: basis that the SPDX 3.0 AI Profile exists at the specification level (expressiveness comparison).

A4. SPDX.tools-python (spdx-tools) — 3.0 experimental write-only, not recommended for production.https://github.com/spdx/tools-python (accessed 2026-06). —Used for: basis that no mature tool exists to generate the SPDX 3.0 AI Profile.

A5. interlynk-io.sbomqs — Policy Guide (custom policy, required type, feature scoring).https://github.com/interlynk-io/sbomqs/blob/main/docs/guides/policy.md (accessed 2026-06). —Used for: basis that sbomqs enforces field presence via custom policy and converts it into a conformance score.

A6. Open Policy Agent.Conftest — OPA/Rego policy evaluation for configuration files.https://github.com/open-policy-agent/conftest (accessed 2026-06). —Used for: basis that CycloneDX/SPDX JSON can be evaluated with Rego to branch role-specific required sets.

A7. OWASP Dependency-Track.Policy Compliance Documentation (condition types, regex values).https://docs.dependencytrack.org/usage/policy-compliance/ (accessed 2026-06). —Used for: basis that the Dependency-Track policy engine centers on license, vulnerability, and component coordinates, with policies configurable per project/tag.

A8. DependencyTrack.Issue #4361 — Request to support CycloneDX 1.5/1.6 classifiers (machine-learning-model,data).https://github.com/DependencyTrack/dependency-track/issues/4361 (accessed 2026-06). —Used for: basis that Dependency-Track does not yet ingest the model/data classifiers or modelCard (open as of this research).

A9. Protect AI.ModelScan — Static Scanner for Model Serialization Attacks (JSON reports, exit codes).https://github.com/protectai/modelscan (accessed 2026-06). —Used for: basis that model file serialization scanning is mature enough to insert into CI.

A10. Sigstore / OpenSSF.model-transparency (model-signing) — DSSE + in-toto Model Signing.https://github.com/sigstore/model-transparency (accessed 2026-06). —Used for: basis that model signing and provenance attestation map onto BOM integrity and provenance fields.

A11. Z. Tian et al. (2025).Data Poisoning in Deep Learning: A Survey.https://arxiv.org/html/2503.22759v1 (accessed 2026-06). —Used for: basis that data poisoning detection remains at the research stage with no general-purpose production tool.

A12. AboutCode.ScanCode Toolkit — License and Copyright Text Matching Engine.https://github.com/aboutcode-org/scancode-toolkit/ (accessed 2026-06). —Used for: basis for reusing the license identification engine while noting that AI license text needs to be added.

A13. Responsible AI Licenses (RAIL).FAQ / BigScience OpenRAIL-M — Use-Based Restrictions That Propagate to Derivatives.https://www.licenses.ai/faq-2 (accessed 2026-06). —Used for: basis that no standard exists for machine-reading and automatically determining RAIL-family conduct restrictions.

A14. LF AI & Data.Simplifying AI Model Licensing with OpenMDW.https://lfaidata.foundation/blog/2025/07/22/simplifying-ai-model-licensing-with-openmdw/ (accessed 2026-06). —Used for: basis that OpenMDW, a permissive license bundling models, data, and weights, is listed with SPDX (a candidate for the AI license dictionary).

A15. Protect AI.huntr — Bug Bounty and CNA for AI and ML.https://huntr.com/ (accessed 2026-06). —Used for: basis that CVEs issued by huntr flow into Dependency-Track matching via NVD.

A16. Google and OpenSSF.OSV.dev — Open Source Vulnerability Database.https://osv.dev/ (accessed 2026-06). —Used for: basis that OSV includes ML library vulnerabilities but does not record model-weight-specific risks themselves.

A17. Trail of Bits.Fickling — Static Analysis Tool for Pickle.https://github.com/trailofbits/fickling (accessed 2026-06). —Used for: basis for a high-risk pickle deep-inspection tool.

A18. OSS Review Toolkit.ORT — License Compliance Orchestration.https://github.com/oss-review-toolkit/ort (accessed 2026-06). —Used for: basis for reusing the policy rule engine and SBOM reporter.

A19. OpenSSF.GUAC — SBOM Graph and Impact Analysis.https://guac.sh/ (accessed 2026-06). —Used for: basis that it is an option for reinforcing impact analysis, while AI-specific handling remains unverified.

This checklist sets the criteria for vetting transparency and risk, on the basis of the AI Bill of Materials (AI BOM), when an in-house development team brings in and uses an external AI model or dataset. The items to check are drawn from the ingestion column of theAI BOM Field Requirements Matrix.

Because the purpose of an ingestion check is to bring a model in rather than to build one, fields that feed directly into risk assessment are prioritized. Licensing is the basis for judging compliance risk, provenance and sensitivity for judging data lawfulness and privacy risk, and vulnerability references for judging security risk.

1. AI BOM Presence and Format

• Is an AI BOM provided for the object being ingested?
• Is the format SPDX 3.0 or later, or CycloneDX 1.6 or later?
• Does the AI BOM’s timestamp match the version of the object being ingested?

If no AI BOM is provided, or the format lacks an AI-specific profile, request one from the supplier before ingestion, or secure the minimum information independently.

2. Identification and Version (Required Check)

3. License Check (Required Check)

An empty license field, or one that conflicts with the intended use, is grounds to hold off on ingestion. Because the model license and the dataset license are separate matters, check each independently.

4. Data Lawfulness and Risk (Required Check)

If the dataset’s provenance is unclear, or whether it contains sensitive data is not stated, data lawfulness and privacy risk must be assessed separately.

5. Security Risk (Required Check)

Vulnerability references are directly required by the Cyber Resilience Act and by US Food and Drug Administration guidance, so this is checked as required during ingestion vetting.

6. Recommended Checks

The following are checked additionally when the risk level is high or the use case is subject to regulation.

• Model timestamp and producer
• Model properties, input/output properties, training properties
• Model hash value and algorithm (integrity verification)
• Dataset contents and hash
• System data flow and data usage
• Whether the intended application domain matches our intended use

7. Ingestion Determination

Figure 5. Ingestion determination flow(synthesized from research)

If all the required check items in Sections 1 through 5 above are satisfied, the determination is ingestion approved. If any one of a license conflict, unclear provenance, undisclosed sensitive data, or an unacceptable vulnerability applies, the determination is held, and the supplier is asked to remedy the gap or an alternative model is considered.

The determination result is recorded together with the ingested object’s AI BOM identifier, version, and determination date, for use in subsequent reassessment and supply chain tracing.

This document sets out the guidelines for the AI Bill of Materials (AI BOM) that in-house development teams must produce when building an AI model or AI system. Information accessibility is at its best at the point of production, so this document sets the required level at its highest. The required fields are drawn from the production column of theAI BOM Field Requirements Matrix.

Much of the information that the production team fails to record can never again be obtained by the adopting team or by parties further down the supply chain. For that reason, model and dataset details that the consensus baseline treats as optional are recommended for production-time authoring.

1. Authoring Principles

The AI BOM is generated after model training or system build completes. The lifecycle stage at the time of generation (pre-build, build, or post-build) is recorded in the metadata. Use SPDX 3.0 or later, or CycloneDX 1.6 or later, as the format, and where possible generate it automatically with a generation tool, then fill in the missing items by hand.

Fields whose value cannot be determined must be marked “unable to confirm” rather than left blank. Whenever a model or dataset is updated, the AI BOM version and timestamp are updated together.

2. Required Fields

The following must always be filled in. These are the items for which two or more standards in the matrix require presence.

3. Recommended Fields

The following are optional under the consensus baseline, but since they can only be recorded accurately at the point of production, authoring them is recommended. If model cards and data cards are maintained, their contents should in particular be linked to the AI BOM.

4. Model Hashes and Integrity

The model hash value and algorithm are optional under the consensus baseline, but the recommendation is strong. Recording the hash of the weight file or model artifact lets downstream parties verify model integrity. For the hash algorithm, use hash function names from the Internet Assigned Numbers Authority (IANA), and use algorithms approved by the National Institute of Standards and Technology (NIST).

5. Dataset Provenance and Sensitivity

The production team knows the provenance of the training dataset best. Record the source, the collection method, the preprocessing and labeling steps, and whether synthetic data was used, and indicate whether personally identifiable information, copyrighted data, or sensitive data is included. This information serves as the basis for meeting the training data documentation obligations of the AI Act and the training data overview requirements of Korea’s Framework Act on Artificial Intelligence.

6. Post-Authoring Checklist

• Are all the required fields in Section 2 filled in?
• Among the recommended fields in Section 3, have those obtainable from model cards or data cards been linked?
• Are licenses stated separately for the model weights and for the dataset?
• Is the lifecycle stage at the time of generation recorded?
• When the model or dataset is updated, are the version and timestamp updated as well?

This document defines the requirements for the AI Bill of Materials (AI BOM) that a supplier providing AI models or AI systems to your organization must submit. It extends the existing Software Bill of Materials (SBOM) submission requirements to models and datasets, and the required items were derived from the supplier column of theAI BOM Field Requirements Matrix.

1. Standard Data Format

The AI BOM must be submitted in a machine-readable standard format. The following two formats are accepted.

Both formats are accepted on equal terms, but SPDX 3.0, which enforces the required properties of models and datasets at the format level, is recommended. CycloneDX below 1.6 and SPDX 2.x have no AI-specific profile and are not accepted as submission formats.

2. Information That Must Be Included

The following items must be included in every submitted AI BOM. Items whose values cannot be confirmed must not be left blank; they must be marked explicitly as “unknown.”

2.1 Document Metadata

2.2 System-Level Information

2.3 Model Information

2.4 Dataset Information

2.5 Security Information

Vulnerability referencing is optional under the consensus criteria, but it is treated as required for supplier submissions because the Cyber Resilience Act and U.S. Food and Drug Administration (FDA) guidance require it directly.

3. Identifier Rules

Models and datasets must be identified with machine-readable standard identifiers.

• Model identifiers use a Package URL (PURL) or Common Platform Enumeration (CPE). Native identifiers such as a model repository path or commit hash may be provided alongside these.
• Dataset identifiers use an accessible URL or URI.
• If multiple identifiers exist, all of them must be included.

4. Strengthened Requirements for Licensing, Provenance, and Sensitivity

Unlike existing software SBOM requirements, the AI BOM enforces the following three items with particular strictness.

Licensing must be stated separately for the model weights and the dataset. The submission must distinguish whether the model is open weight, open architecture, or open data, and must provide a link to the license document. Dataset provenance must go beyond a simple source statement to include the collection method (web crawling versus a commercial agreement), preprocessing and labeling steps, and whether synthetic data was used. Dataset sensitivity must indicate whether personally identifiable information, copyrighted data, or sensitive data such as financial or medical data is included.

5. Sample Document

The following is a minimal AI BOM skeleton in CycloneDX 1.6 format. An actual submission must fill in all the required items from Section 2 above.

{"bomFormat":"CycloneDX","specVersion":"1.6","metadata":{"timestamp":"2026-06-29T09:00:00Z","authors":[{"name":"Supplier legal name"}],"component":{"type":"application","name":"Supplied AI system","version":"1.0.0"}},"components":[{"type":"machine-learning-model","name":"Supplied model name","version":"1.0","bom-ref":"pkg:huggingface/org/model@1.0","supplier":{"name":"Model producer"},"licenses":[{"license":{"id":"Apache-2.0"}}],"modelCard":{"modelParameters":{"datasets":[{"type":"dataset","name":"Training dataset name","classification":"public","governance":{"owners":[{"organization":{"name":"Data source"}}]}}]}}}],"vulnerabilities":[]}

6. Pre-Submission Verification Checklist

Suppliers must confirm the following before submission.

• Is the format SPDX 3.0 or later, or CycloneDX 1.6 or later?
• Are all required items from Section 2 filled in, or explicitly marked “unknown”?
• Are the model and dataset identified with standard identifiers?
• Is a license stated for both the model weights and the dataset?
• Are dataset provenance and sensitivity indicated?
• Is a vulnerability reference link provided?
• Was it generated at a point in time after the build or model release was complete?

For detailed inspection criteria, see theIngestion Vetting Checklist.

Citation and Commentary Notice. This article cites and comments on theSoftware Supply Chain Security Roadmap for the Age of Everyday AI (2026-06-24), publicly published by the Ministry of Science and ICT, the National Intelligence Service, and the Korea Internet & Security Agency, with attribution under Article 28 of the Copyright Act. The tables and diagrams in the original are not reproduced; the narrative and diagrams here are original work based on external primary sources. Attribution: Ministry of Science and ICT, National Intelligence Service, Korea Internet & Security Agency,Software Supply Chain Security Roadmap for the Age of Everyday AI, 2026-06-24.

Summary On June 24, 2026, the government released a roadmap outlining software supply chain security policy for the next three years. At its core are a transparency management model centered on the Software Bill of Materials (SBOM), a testbed and consulting program to help companies check their security, pilot certification to identify high-performing companies, and a rapid detection-and-response system. Notably, the roadmap places burden reduction for small and medium-sized enterprises throughout, reflecting an industry structure in which 81% of all software companies have fewer than 10 employees. Because the U.S. Food and Drug Administration (FDA)’s medical device approval process and the EU Cyber Resilience Act (CRA) have already made SBOMs a condition of market entry, this roadmap bears directly on the practical work of exporting companies, public-sector software vendors, and small and medium-sized software companies.

1. Nature of the Roadmap and Background to the Announcement

On June 24, 2026, the government released theSoftware Supply Chain Security Roadmap for the Age of Everyday AI at the Supply Chain Security Workshop held at the aT Center in Yangjae, SeoulA1·B-news-zdnet. The Ministry of Science and ICT, the National Intelligence Service, and the Korea Internet & Security Agency (KISA) prepared it jointly with related ministries, and KISA is the publisherA1. Rather than a law or notice, it is an administrative planning document setting out policy direction for the next three years; many of its individual tasks will gain normative force only after legal and institutional reform, guideline publication, and certification-system reorganizationA1.

The announcement followed an already-signaled path. When the government released theSW Supply Chain Security Guideline 1.0 in 2024, it stated that it would form a joint industry-academia-research task force in the second half of the year to discuss the direction of institutionalization and then prepare a roadmapD6; after the Ministry of Science and ICT and the National Intelligence Service agreed on December 24, 2025 to build a government-wide cooperation frameworkB-news-etnews, that process led to this announcement. The government has consistently described 2027 as its target for institutionalizationB-news-zdnet.

The roadmap declares its vision as “securing cyber resilience through a transition to a safe and responsible supply chain security system,” converging this into three pillars: prevention, recovery, and foundationA1. Beneath these sit three implementation strategies and nine detailed tasks.

Figure 1. The vision, the three strategies, and each strategy’s core tasks(compiled for this report; see §5 for external sources).

2. Prevention — Building In Security and SBOM Transparency

The prevention strategy starts from establishing standards and guidance that build security into the software lifecycle as a whole. The roadmap presents a “secure SW development methodology” that draws on the National Institute of Standards and Technology (NIST)’s Secure Software Development Framework (SSDF, SP 800-218), and states that it will place activities such as defining security requirements, secure coding, vulnerability re-verification, and code signing at each stage — planning and design, development, testing, and deploymentA1·B5. Its predecessor, theSW Supply Chain Security Guideline 1.0, will be upgraded to a practically usable 2.0. The direction is to broaden open source management, which had centered on licensing, to cover security as well; to extend development security, which had focused on self-developed code, across the full supply chain; and to newly add the use of automated security compliance toolsA1·A2.

SBOM is the core instrument of the transparency task. An SBOM is a specification that describes information about a software’s components; domestically it is also called a “software component specification,” among other names. The roadmap identifies exporting companies and high-impact sectors as the priority targets for applying the SBOM management modelA1. For exporting companies, the direct drivers are the U.S. FDA’s medical device approval process, the U.S. Department of Commerce’s SBOM management obligation for connected vehicles, and the EU CRA’s SBOM obligation for products with digital elementsA1·B7·B1; high-impact sectors include security software, socially foundational software such as finance and transportation, and software handling sensitive information such as health and medical dataA1.

The data format is effectively already settled. The International Organization for Standardization (ISO) standardized the Linux Foundation’s SPDX as ISO/IEC 5962:2021C4, and OWASP’s CycloneDX was standardized as ECMA-424, published in December 2025C5. The roadmap’s statement that it will “derive the minimum SBOM items so they do not function as dual regulation,” made with an eye to the National Telecommunications and Information Administration (NTIA)’sThe Minimum Elements For a Software Bill of Materials (2021) and the CRA’s requirements, is a design aimed at aligning with this international formatA1·C1. Format compatibility is only the starting point; the roadmap itself names verifying SBOM trustworthiness and safely distributing the vulnerability information it contains as remaining tasksA1. An SBOM raises transparency but can also reveal to attackers which components carry which vulnerabilities, so designing the right balance between generation and sharing is the key question for the follow-on guidelinesA1.

3. Recovery — Rapid Detection, Risk Management, and Reducing the Burden on Companies

The detection-and-response strategy centers on expanding the scope of KISA’s security vulnerability reward program (bug bounty), which it has run since October 2012D2, and on progressively expanding Coordinated Vulnerability Disclosure (CVD) and a Vulnerability Disclosure Policy (VDP)A1. To introduce security condition inspections for Internet of Things (IoT) appliances such as robot vacuums and IP cameras and for network-connected devices such as solar inverters, the government is pursuing an amendment to the Act on Promotion of Information and Communications Network Utilization and Information Protection, etc. (Network Act)A1.

The risk management system is split into public and private sectors. In the public sector, the government will develop an SBOM management framework that includes Vulnerability Exploitability eXchange (VEX) information at the reliability-assurance stage, and will build an integrated public-sector SBOM management system and a vulnerability information database in stagesA1. In the private sector, it will establish a standing management framework for high-risk vulnerabilities, and set a goal of shortening the response period “from an average of more than four months to within three days” through a cleaning service (C-Clean) that, once a vulnerability is found, requests a patch from the manufacturer and performs a mass removal via antivirus softwareA1.

The support companies actually feel is concentrated in inspection and diagnosis and in the distribution of tools and personnel. The roadmap states that it will expand testbeds where companies can use SBOM generation and vulnerability inspection tools, drawing on existing facilities such as the Development Security Hub and the National Cyber Security Center (NCSC) in Pangyo, and will add checks against global regulations such as medical device approval and the EU CRA to the menuA1. For small and medium-sized software development companies, it has placed consulting to analyze and diagnose development infrastructure and management systems starting in 2026, and the distribution of cloud-based development environments and security solutions starting in 2027A1. A defining feature of the roadmap overall is that it explicitly states the industry structure — 81% of all software companies have fewer than 10 employees (2023 Software Industry Survey, a total of 43,932 companies by employee-size bracket) — and designs its support accordinglyA1·D1.

4. Foundation — Policy Framework, Pilot Certification, and Global Cooperation

In the foundation-building strategy, the Ministry of Science and ICT and the National Intelligence Service will jointly chair a (tentatively named) government-wide SW Supply Chain Security Council, organized into five subcommittees: medical devices, automobiles, public information systems, finance, and securityA1. Pilot certification sits at the center of legal and institutional reform. The government states that it will verify software supply chain security management and issue certificates recognizing high-performing companies (tentatively named SSS Verified, Software Supply-Chain Security Verified), pursue Mutual Recognition Agreements (MRA) with countries that have institutionalized similar systems, and formally institutionalize the framework by incorporating supply chain security testing and evaluation elements into the Information Security Management System certification (ISMS), the Cloud Security Assurance Program (CSAP), and IoT security certificationA1. It is notable that the government chose to build on existing systems rather than create a separate new certification.

The changes on the public procurement side are also clear. SBOM submission and vulnerability response procedures, along with a supply chain cybersecurity risk management procedure document, have been added as tasks for informatization projects, and security conformity assessment will widen its scope in consideration of the National Network Security Framework (N2SF) while combining it with confirmation of SBOM submissionA1·D3. N2SF is a multi-tier security approach that applies differentiated security levels according to the importance of the work and data involved; its formal Security Guideline 1.0 was published on September 30, 2025, and reflected in the 2026 cybersecurity assessmentD3·D-news-boan.

The global cooperation task connects to two multilateral bodies. The Global Cybersecurity Labelling Initiative (GCLI), a coalition that discusses mutual recognition of IoT security certification labels and the establishment of a single standard, launched with 11 founding members at Singapore International Cyber Week on October 23, 2025, with Korea’s Ministry of Science and ICT and KISA participating as founding membersA10. Alongside this, the roadmap presents cooperation with the Global Government Expert Forum (GGEF), the U.S. Cybersecurity and Infrastructure Security Agency (CISA), the European Commission’s Directorate-General for Communications Networks, Content and Technology (DG CONNECT), and the UK Department for Science, Innovation and Technology (DSIT) as channels for supporting global expansionA1.

Figure 2. The correspondence between the global regimes the roadmap references and its policy tasks(compiled for this report; see §5 for external sources).

The roadmap separates its response to emerging technologies into a distinct research task. It places research on a supply chain security model that responds to the everyday normalization of emerging technologies such as AI as a task for 2027 and beyondA1, and the data layer of an SBOM for AI (training data, model weights, and the like) falls outside the direct scope of this roadmap, which centers on the general software supply chain.

5. The Background Shaped by Global Regulation

Behind the roadmap’s choice of SBOM, pilot certification, and mutual recognition as its core instruments lies the overseas regulation exporting companies face. A company interview the roadmap quotes shows this plainly. A digital medical device manufacturer struggled to respond to SBOM requirements during the FDA approval process; a security company that had entered the U.S. market was notified, while supplying software to the federal government, that failing to meet SBOM management requirements would make it ineligible for next year’s contract; and an AI solution developer lost a contract during preparations to supply a global financial company because it failed to meet cybersecurity requirementsA1.

Figure 3. The overseas regulation behind the roadmap and the deadlines ahead(compiled for this report; see §7 for sources).

Most of these regulations were finalized between 2021 and 2024. The EU Cyber Resilience Act (Regulation (EU) 2024/2847) is a regulation that imposes horizontal cybersecurity requirements on products with digital elements, and it entered into force on December 10, 2024B1·B2. The Article 14 reporting obligation applies from September 11, 2026, and the essential obligations as a whole, including conformity assessment and CE marking, apply from December 11, 2027B2. Manufacturers bear the obligation to produce an SBOM for products with digital elements, to handle vulnerabilities across the full lifecycle, and to issue an early warning within 24 hours and notify within 72 hours of becoming aware of an actively exploited vulnerability or a severe incidentB1. Penalties for violation run up to €15 million or 2.5% of worldwide annual turnover, whichever is higherB1. The roadmap’s recurring “scheduled for ‘27.12 implementation” refers to this date of full applicationA1.

U.S. supply chain regulation began with Executive Order 14028 (Improving the Nation’s Cybersecurity), signed on May 12, 2021, which led to institutionalizing SBOM as a federal procurement requirement and directed NIST to draw up the SSDFB3·B5. CISA finalized the Secure Software Development Attestation Common Form on March 11, 2024B4. Medical device regulation began when Section 3305 of the 2022 Consolidated Appropriations Act added a new Section 524B to the Federal Food, Drug, and Cosmetic Act (FD&C Act); the amended provision took effect on March 29, 2023B7. Manufacturers filing a premarket submission must submit a postmarket vulnerability management plan, secure-by-design documentation, and an SBOM covering commercial, open source, and off-the-shelf componentsB7. In the consumer IoT space, the U.S. Federal Communications Commission (FCC) adopted a voluntary labeling program (the U.S. Cyber Trust Mark) on March 14, 2024B8, and the UK brought the Product Security and Telecommunications Infrastructure Act 2022 (PSTI) into force on April 29, 2024B9. These are the “U.S. Cyber Trust Mark” and “UK PSTI (effective ‘24.4)” the roadmap cites in its post-market management taskA1.

6. Implications and Considerations

6.1 Exporting Companies — SBOM Is Already a Market Entry Condition

With the FDA’s medical device approval process and the EU CRA having effectively made SBOM management a condition of market entry, the government’s inspection support and its push for mutual recognition offer direct value to exporting companiesA1·B1·B7. Because the EU CRA’s reporting obligation begins September 11, 2026, and full application begins December 11, 2027B2, exporting companies are safer preparing their SBOM generation and vulnerability reporting systems ahead of time on the CRA’s own schedule, rather than waiting for Korea’s MRA to be concluded. An MRA requires the counterpart country to recognize Korean certification as equivalent, and the roadmap itself only describes the MRA as being “pursued,” without offering a timeline for agreementA1.

6.2 Public-Sector Software Vendors — SBOM Submission Becomes a Standing Requirement

In the public sector, SBOM submission and vulnerability response procedures for informatization projects have been explicitly set as tasks, and confirmation of SBOM submission is combined with security conformity assessment and the transition to N2SFA1·D3. Companies supplying software to the public sector need to prepare by integrating SBOM generation into their build pipeline. Since the policy is to derive public-sector SBOM items at a minimum so they do not become dual regulationA1, it is practically useful to check the follow-on guidelines for how alignment with overseas requirements is actually designed.

6.3 Small and Medium-Sized Software Companies — Whether Support Is Sufficient Is the Question

In an industry structure where 81% of all software companies have fewer than 10 employeesA1·D1, it is difficult for these companies to bear on their own the tools and personnel needed for SBOM generation and vulnerability management. The roadmap places consulting and the distribution of cloud-based development environments and security solutions as its support measures, but no figures are given for whether the scale of distribution and the budget will actually cover the majority of the roughly 40,000 companies involvedA1. Whether the support is sufficient is an area that future budget allocation will decide.

6.4 Remaining Risks

There is a risk from dependence on external infrastructure. The contract between MITRE, which operates the U.S. Common Vulnerabilities and Exposures (CVE) program, and CISA came within a day of expiring on April 16, 2025, before an 11-month extension patched things over, and the CVE Board confirmed on January 21, 2026 that “there will be no March funding cliff”E6·F-news-cso. The immediate crisis was averted, but the structural instability of a global vulnerability identification system that depends on the U.S. government’s budget remains unchanged, which makes the roadmap’s inclusion of finding an alternative program as a task a reasonable precautionA1.

The readiness of the development field is another variable. According to Black Duck’s survey of the state of DevSecOps, conducted among 1,001 professionals worldwide in July and August 2025, 45.56% still handle putting new code through security testing manuallyH1. Speed has become the standard while security automation has not kept pace, and this gap overlaps with the problem the roadmap identifies in its plan to shift from human-centered manual response to an AI-centered autonomous systemA1. If SBOM generation and vulnerability inspection are not integrated into an automated pipeline, mandating them risks becoming, on the ground, an added burden of manual work.

As a side note, the estimate of global damage from supply chain attacks that the roadmap attributes to “Gartner (‘24.6)” — $46 billion in 2023, projected to reach $138 billion by 2031 — is actually a Cybersecurity Ventures estimateE4.

7. References

This section lists the items cited in the text as[A1] and similar. All URLs were accessed on 2026-06-24. Government and institutional sites sometimes return a bot block to automated crawling tools; these are not dead links, and such items were cross-checked using existing verification assets or WebSearch.

Subject of Analysis and Domestic Prior Documents

A1. Ministry of Science and ICT, National Intelligence Service, and Korea Internet & Security Agency, joint (2026).Software Supply Chain Security Roadmap for the Age of Everyday AI. Published by the Korea Internet & Security Agency (Naju), 1st edition, 1st printing, 2026-06-24. 30 pages, CC BY-NC-ND 2.0 KR. Released on the day of the announcement (2026-06-24, Supply Chain Security Workshop, aT Center, Yangjae); a fixed direct PDF link was not yet available, but it can be found via the Ministry of Science and ICT press release (https://www.msit.go.kr/bbs/list.do?sCode=user&mId=307&mPid=208) and the KISA resource library. —Use: the publicly released government roadmap that is the subject of this article’s citation and commentary. Cited with attribution; the original’s tables and diagrams are not reproduced.↩

A2. Ministry of Science and ICT, National Intelligence Service, and Presidential Committee on Digital Platform Government (2024).SW Supply Chain Security Guideline 1.0 (summary, 2024-05-13). Published in the KISA resource library.https://www.kisa.or.kr/2060204/form?postSeq=15 (accessed 2026-06-24; publishing entity and SSDF, SBOM, and stage-by-stage inspection content cross-checked via WebSearch). —Use: the direct predecessor document the roadmap states it will upgrade to 2.0.↩

A10. Cyber Security Agency of Singapore et al. (2025).Joint Statement on the Global Cybersecurity Labelling Initiative (GCLI). Launched 2025-10-23.https://www.csa.gov.sg/news-events/press-releases/joint-statement-on-the-global-cybersecurity-labelling-initiative/ (accessed 2026-06-24; launch date, 11 founding members, and Korea’s participation cross-checked via WebSearch). —Use: confirms the GCLI’s launch, composition, and Korea’s participation.↩

Primary Texts of Global Laws and Regulations

B1. European Parliament and Council (2024).Regulation (EU) 2024/2847 — Cyber Resilience Act. Official Journal of the EU, OJ L, 2024/2847, 20.11.2024.https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng (accessed 2026-06-24; reconfirmed against theeu-cra-vulnerability-reporting workspace verification asset). —Use: primary basis for the CRA’s SBOM and vulnerability obligations, reporting deadlines (24h/72h), penalties, and effective dates.↩

B2. European Commission, DG CNECT (2026).Cyber Resilience Act — Shaping Europe’s digital future.https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act (accessed 2026-06-24). —Use: primary confirmation of the implementation schedule (entry into force 2024-12-10, reporting obligation 2026-09-11, full application 2027-12-11).↩

B3. The White House (2021).Executive Order 14028 — Improving the Nation’s Cybersecurity. Federal Register, 86 FR 26633, 2021-05-17.https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity (accessed 2026-06-24, 200 OK). —Use: primary basis for making SBOM a federal procurement requirement and directing NIST to draw up the SSDF.↩

B4. CISA (2024).Secure Software Development Attestation Common Form (Final). Released 2024-03-11.https://www.cisa.gov/secure-software-attestation-form (accessed 2026-06-24; cisa.gov returned a bot block, release date cross-checked via WebSearch). —Use: the U.S. federal procurement SSDF self-attestation obligation. The roadmap’s “‘23.6~” notation refers to when the policy was discussed; the form itself was released in 2024-03.↩

B5. NIST — Souppaya, M., Scarfone, K., Dodson, D. (2022).Secure Software Development Framework (SSDF) Version 1.1. NIST SP 800-218. DOI: 10.6028/NIST.SP.800-218.https://csrc.nist.gov/pubs/sp/800/218/final (accessed 2026-06-24). —Use: the framework the roadmap’s “secure SW development methodology” directly references.↩

B7. U.S. Food and Drug Administration / Federal Register (2023).Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (FD&C Act §524B, added by §3305 of the 2022 Consolidated Appropriations Act, effective 2023-03-29).https://www.federalregister.gov/documents/2023/09/27/2023-20955/cybersecurity-in-medical-devices-quality-system-considerations-and-content-of-premarket-submissions (accessed 2026-06-24, 200 OK). —Use: primary basis for the FDA’s medical device SBOM requirement.↩

B8. Federal Communications Commission (2024).Cybersecurity Labeling for Internet of Things — Report and Order (FCC 24-26) (U.S. Cyber Trust Mark). Adopted 2024-03-14.https://www.federalregister.gov/documents/2024/03/25/2024-06249/cybersecurity-labeling-for-internet-of-things (accessed 2026-06-24, 200 OK). Program hub:https://www.fcc.gov/CyberTrustMark. —Use: primary basis for the U.S. voluntary IoT labeling program.↩

B9. UK Government / DSIT (2022/2024).Product Security and Telecommunications Infrastructure (PSTI) Act 2022, Part 1 (effective 2024-04-29).https://www.gov.uk/government/publications/the-uk-product-security-and-telecommunications-infrastructure-product-security-regime (accessed 2026-06-24; effective date and penalty cap cross-checked via WebSearch). —Use: primary basis for the UK’s mandatory PSTI regulation.↩

Standards and Guidance

C1. U.S. Department of Commerce / NTIA (2021).The Minimum Elements For a Software Bill of Materials (SBOM). 2021-07-12.https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf (accessed 2026-06-24; ntia.gov blocked the crawler, reconfirmed against thesbom-guide andg7-sbom-for-ai workspace verification assets). —Use: the baseline for the roadmap’s “deriving minimum SBOM items.”↩

C4. The Linux Foundation / SPDX Project.SPDX Specifications (current version SPDX 3.0, standardized as ISO/IEC 5962:2021).https://spdx.dev/use/specifications/ (accessed 2026-06-24, 200 OK, verified againstsbom-guide). —Use: an SBOM standard format. Basis for global compatibility.↩

C5. OWASP Foundation / Ecma International (2025).CycloneDX Specification / ECMA-424 (published 2025-12-10).https://cyclonedx.org/specification/overview/ (accessed 2026-06-24, 200 OK, verified againstsbom-guide). —Use: an SBOM standard format.↩

Domestic Institutions and Statistics

D1. Ministry of Science and ICT and the Korea Association for ICT Promotion (KAIT) (2024).2023 Software Industry Survey (a nationally approved statistic). Statistics portal SWSTAT:https://stat.spri.kr/ (accessed 2026-06-24; publishing body and the nature of the statistic confirmed via WebSearch). —Use: basis for the publishing framework behind the roadmap’s statistic that “81% of software companies have fewer than 10 employees (43,932 companies in total).” The 81% figure and the 43,932 count are attributed to the roadmap’s citation, as direct comparison against the survey’s original tables was not completed.↩

D2. Korea Internet & Security Agency (KISA) / KrCERT (2012–).Security Vulnerability Reward Program (Bug Bounty).https://www.krcert.or.kr/kr/bbs/list.do?menuNo=205027 (accessed 2026-06-24; October 2012 program start and quarterly evaluation cross-checked via WebSearch). —Use: basis for the existing program the roadmap’s detection-and-response task expands.↩

D3. National Intelligence Service · National Cyber Security Center (2025).National Network Security Framework (N2SF) Security Guideline, formal edition 1.0 (published 2025-09-30).https://www.nis.go.kr/CM/1_4/view.do?seq=373 (accessed 2026-06-24; publication date and tiered security-level system cross-checked via WebSearch). —Use: basis for the roadmap’s expansion of the scope of security conformity assessment (N2SF).↩

D6. Presidential Committee on Digital Platform Government (2024).Government Announces ‘SW Supply Chain Security Guideline 1.0’ (press release, 2024-05-13).https://www.dpg.go.kr/DPG/contents/DPG02020000.do?schM=view&id=20240513105420991857&schBcid=press (accessed 2026-06-24; the announcement date of 2024-05-13 and the text’s plan for “preparing a roadmap through a government-wide joint task force in the second half of the year” cross-checked via WebSearch). —Use: primary announcement of the background to Guideline 1.0’s release and the “plan to prepare a roadmap through a second-half joint task force.”↩

Original Sources of Statistics Cited by the Roadmap

E4. Cybersecurity Ventures (2024).Software Supply Chain Attacks To Cost The World $60 Billion By 2025.https://cybersecurityventures.com/software-supply-chain-attacks-to-cost-the-world-60-billion-by-2025/ (accessed 2026-06-24; the $46 billion figure for 2023 and $138 billion for 2031 confirmed via WebSearch). —Use: the actual original source of the roadmap’s supply chain damage statistic. The roadmap’s attribution to “Gartner (‘24.6)” is inaccurate and is corrected here to Cybersecurity Ventures.↩

E6. MITRE / CISA (2025). Background on the CVE program’s contract expiration and extension. Cybersecurity Dive (2025-04):https://www.cybersecuritydive.com/news/cisa-extend-funding-cve/745531/ (accessed 2026-06-24; the $57.8 million contract, 2025-04-16 expiration, 11-month extension, and the founding of the CVE Foundation confirmed via WebSearch). Program site:https://www.cve.org/. —Use: background for the roadmap’s task of finding an alternative to the CVE program. Supplementary press source.↩

News and Industry Coverage

B-news-etnews. ETNews (2025-12-24).Ministry of Science and ICT and National Intelligence Service Join Hands on SW Supply Chain Security… Build Government-Wide Cooperation Framework.https://www.etnews.com/20251224000334 (accessed 2026-06-24). —Use: confirms the timing of the government-wide cooperation agreement (2025-12-24).↩

B-news-zdnet. ZDNet Korea (2026-06-16).Government to Release SW Supply Chain Security Roadmap on the 24th.https://zdnet.co.kr/view/?no=20260616111556 (accessed 2026-06-24). —Use: primary confirmation of the announcement date (2026-06-24), the responsible bodies (Ministry of Science and ICT, National Intelligence Service), the location (aT Center, Yangjae), and the 2027 institutionalization target.↩

D-news-boan. Boannews (2026).From NIS Security Conformity Assessment to N2SF… What’s Changed in the Paradigm?.https://m.boannews.com/html/detail.html?tab_type=1&idx=140209 (accessed 2026-06-24). —Use: coverage of the transition from security conformity assessment to N2SF and its incorporation into the 2026 cybersecurity assessment.↩

F-news-cso. CSO Online (2026).CVE program funding secured, easing fears of repeat crisis.https://www.csoonline.com/article/4142600/cve-program-funding-secured-easing-fears-of-repeat-crisis.html (accessed 2026-06-24). —Use: confirms the CVE Board’s January 21, 2026 statement of “no March funding cliff.”↩

Development-Field Trends

H1. Black Duck (2025).Balancing AI Usage and Risk in 2025: The Global State of DevSecOps (October 2025). The survey was conducted by Censuswide among 1,001 professionals worldwide in July–August 2025. —Use: the security automation gap in the development field (45.56% still handled manually).↩

What Is an SBOM

A Software Bill of Materials (SBOM) is a machine-readable list of all the components and libraries that make up a software product, along with the dependency relationships among them. It carries over the manufacturing concept of a Bill of Materials into software. Just as a finished vehicle has a specification sheet recording which parts came from which supplier, an SBOM records which open source and commercial components, at which versions, went into an application.

Most modern software is filled more with components brought in from outside than with code written in-house. Those external components can carry vulnerabilities, come with license obligations attached, and in turn depend on still other components. An SBOM makes this chain of dependencies visible, providing a common data layer that security, license management, and asset management can all reference.

Why It Matters: The Collapse of Supply Chain Trust

Two supply chain incidents raised the SBOM onto the policy agenda. In the SolarWinds incident that came to light in December 2020, attackers poisoned the legitimate update path of the Orion software itself. A backdoor spread along with that update to the many organizations that trusted and installed it. It was a structure in which a compromise at a single point upstream in the supply chain spread across the entire downstream.

A year later, in December 2021, a remote code execution vulnerability in the Java logging library Log4j (CVE-2021-44228, commonly known as Log4Shell) was disclosed. What this incident exposed was not a breach itself but an absence of visibility. Log4j was buried deep as an indirect dependency in countless products, so few organizations could give an immediate answer to the question, “where in our products does this library exist?” If every piece of software had already had a machine-readable component list in place, determining the scope of impact would have taken a single query. This experience gave direct momentum to the SBOM agenda.

After that, the SBOM moved beyond recommendation into regulation. The United States opened a path to requiring SBOMs for software delivered to the federal government through Executive Order 14028 in 2021, and the European Union made producing an SBOM a legal obligation through the Cyber Resilience Act (CRA). The detailed regulatory landscape is covered in3. Regulatory Landscape.

Benefits of an SBOM

The value of an SBOM is not limited to security alone. The same data — a component list — serves multiple purposes at once.

• Vulnerability management and incident response: When a new vulnerability is disclosed, affected components can be looked up immediately to set response priorities.
• Supply chain risk management: The provenance and trustworthiness of external components are assessed and reflected in procurement and supplier management.
• License compliance: Tracking the license of each component prevents obligation violations and conflicts in advance.
• Regulatory compliance: Meets transparency requirements and provides the evidence needed for regulatory reporting and audits.
• Asset management and operational efficiency: Knowing exactly what is in use makes lifecycle management easier.

Who Creates and Uses It

The value of an SBOM does not come from a single organization producing it alone; it is realized when it flows along the supply chain. The third edition of CISA’sFraming Software Component Transparency organizes the actors around an SBOM into three perspectives: producers (Produce) who make software, choosers (Choose) who select which software to use, and operators (Operate) who run it. It is common for a single organization to hold all three roles at once, as with a company that develops its own products while also bringing in external libraries and operating infrastructure.

The core of this structure is the chain of supplier-consumer relationships. When an upstream producer creates an SBOM and passes it downstream, the downstream chooser uses it to assess risk before adoption, and the operator looks up the scope of impact immediately when a new vulnerability is disclosed. What Log4Shell showed was precisely a break in this chain. Because producers had not passed along a component list, operators could not know what libraries existed in their own assets.

Interests diverge subtly across actors. Consumers want a deeper, more complete SBOM, while producers, concerned about trade secrets and attack surface exposure, want to narrow the scope of disclosure. Where regulation sets the floor of obligation, and how it adjusts the scope of disclosure, are the mechanisms that resolve this tension. Sharing and disclosure scope are covered in7. Sharing and Governance.

The next section looks atlevels and types according to the depth of information an SBOM carries.

Sources

The factual basis for this section is compiled in this guide’s background research materials. Executive Order 14028 (86 FR 26633, May 12, 2021), CVE-2021-44228 (NVD), and the third edition of CISA’sFraming Software Component Transparency (September 3, 2024) were used as primary sources. For the full set of sources, see3. Regulatory Landscape and the bottom of each section.