Published

SBOM / Supply-chain Manifest

vr.wm-sft-012 · wm-sft-012-sbom-supply-chain-manifest

Model the software bill of materials as a governed, versioned, signable manifest record: its own identity and specification binding, the component inventory and identifier sets it carries, the asserted relationship graph, declared licensing and completeness, authenticity bindings by reference, and the manifest's publication, access and retention lifecycle.

World Models Information and virtual systems INF.SFT.SBOM

Bundle → Layer → Finding → Questions Classifiers What it is Why it exists Distinguishing features What robots and AI may and may not do Moral aspects Owners Links to other meta-models Identity and identifiers Direct properties Recognition Capabilities and actions Hazards and failure modes Standards and interfaces Context of use Sources

Bundle → Layer → Finding → Questions Filled

6 bundles · 11 layers · 25 findings · 87 questions

Manifest Identity, Specification Binding and Subject Scope What this manifest instance is, how it is identified and revised, which specification and serialization express it, which released artifact it describes, and how it was generated.

Manifest identity and revision series

The manifest's own identifier, namespace, revision counter and immutability rules.

Manifest identifier, namespace and revision series

How a single SBOM instance is named, how its internal element identifiers are scoped, and when a change yields a new revision of the same identity rather than a new manifest identity.

Which identifier authoritatively designates this SBOM instance, and which system mints it? identity
When does a change produce a new revision of the same manifest identity rather than a new manifest identity? lifecycle
Which namespace or document IRI scopes the entry-local identifiers used inside this manifest? interoperability
Is a published manifest revision immutable once distributed, and what constraint records that? constraint

Specification, profile and serialization binding

Which SBOM specification family and version the manifest declares, which profiles or extensions it uses, and which serialization and registered media type carry the instance.

Which SBOM specification family and specification version does this manifest declare? classification
Which serialization and registered media type carry this manifest instance? interoperability
Which optional profiles or extensions of the declared specification are in use? composition
How is one logical manifest expressed in two serializations recognised as a single manifest? identity

Subject binding and generation context

Which released artifact the manifest describes and under what generation conditions the inventory was produced.

Primary component and subject binding

Identification of the root subject the manifest describes and its resolvable binding to an external release record and to an exact artifact digest.

Which described subject is the primary or root component of this manifest? composition
Which external package or release record does the primary component resolve to, and by which key? relationship
Which digest binds this manifest to an exact released artifact rather than to a product line? evidence
May a single manifest describe more than one primary subject, and how is that expressed? constraint

SBOM type, generating tool and interpretation limits

The declared lifecycle phase and method by which the inventory was produced, the tool that produced it, the producing run held as a reference, and the limits this places on how the inventory may be read.

Which SBOM type classifies how this manifest was produced? classification
Which tool identity and version generated this manifest, and was generation automated or manual? provenance
Which build or analysis run does this manifest cite as its producing event, without restating that run's own record? process
What limits does the declared generation context place on how this inventory may be interpreted? quality

Component Inventory and Identification The component entries the manifest carries: their core attributes, identifier sets, classification, integrity digests and producer attribution.

Component entry attributes and identifiers

What each inventory entry must state to be usable, and how it is identified and classified.

Core component entry attributes

The minimum attribute set of an inventory entry, its entry-local reference used as a relationship endpoint, and how versionless or duplicate entries are handled.

What is the minimum attribute set that makes a component entry usable by a downstream consumer? definition
Which entry-local reference identifies a component inside this manifest so that relationships can target it? identity
How is a component version recorded when the upstream project publishes no formal version string? exception
How are two entries recognised as describing the same component within one manifest? validation

Component identifier set and normalization

The governed identifier schemes recorded per component, their precedence, the normalization applied before comparison, and the fallback when no registry coordinate exists.

Which identifier schemes are recorded for a component and in what precedence order? identity
Which normalization rules apply before two package URLs are treated as equal? validation
How is a component identified when no registry coordinate exists for it? exception
Which recorded identifier is used to correlate a component entry with externally owned vulnerability data? interoperability

Component type, scope and modification state

Classification of each entry by component type, whether it is required, optional or excluded in the described subject, and whether it deviates from its upstream distribution.

Which component type vocabulary classifies each inventory entry? classification
Is the component required, optional or excluded within the described subject? state
How is a component that was modified from its upstream distribution flagged? quality

Component integrity and attribution

Cryptographic digests over component bytes and the parties credited with producing or supplying each component.

Component integrity digests

Hash algorithms and values recorded per component, what byte stream each digest covers, and what is recorded when a component cannot be hashed.

Which cryptographic hash algorithms and values are recorded for each component? security
Which exact byte stream does a recorded component digest cover? measurement
What is recorded when a component cannot be hashed at all? exception

Producer, supplier and author attribution

Which party is credited for each component, how producer differs from distributor, publisher and author, and how attribution resolves to durable party records.

Which party is recorded as the producer of a component, and how does that differ from its distributor? ownership
Which external party register resolves a supplier name to a durable organization identifier? relationship
What is recorded when the producer of an open-source component cannot be attributed? exception

Relationship Graph and Cross-Manifest Linkage The asserted dependency and containment structure, its declared depth and completeness, and links to other manifests and to externally owned evidence.

Dependency assertions and declared depth

How relationships are asserted between entries and how far the manifest claims to reach.

Relationship assertions and direction

Permitted relationship types between entries, the direction convention, how optional or phase-specific dependencies are distinguished, and how an asserted absence differs from silence.

Which relationship types are permitted between components in this manifest? relationship
Which direction convention applies to a dependency assertion in this manifest? constraint
How is an asserted absence of dependencies distinguished from an unasserted dependency? quality
How are build-only, runtime-only and optional dependencies distinguished from one another? classification

Declared dependency depth and completeness

How far into transitive dependencies the manifest claims coverage, the aggregate and per-relationship completeness assertions, and the regulatory floor that applies to the described product.

To what dependency depth does this manifest claim coverage? measurement
Which completeness assertion applies to the manifest as a whole and to individual assemblies? quality
Which regulatory floor for dependency depth applies to the described product? authority

Cross-manifest and external evidence links

Version-pinned links to other manifests and to evidence owned by other models.

Links to other manifests and assemblies

How a manifest references another manifest describing a contained subassembly, the link syntax that makes such a reference resolvable and version-pinned, and the effect of supersession on an assembled view.

How does this manifest reference another manifest that describes a contained subassembly? composition
Which link syntax makes an external manifest reference resolvable and version-pinned? interoperability
What happens to an assembled view when a linked manifest is superseded? lifecycle

External references to non-manifest evidence

Categories of outbound reference a manifest or entry may carry to advisories, exploitability statements, provenance attestations, documentation and download locations, and how each is pinned.

Which categories of external reference may a component entry carry? classification
Which reference binds an entry to exploitability statements without asserting them in this manifest? relationship
How is an external reference pinned so that its meaning cannot change silently? evidence

Declared Licensing and Rights Metadata Licence expressions carried for components and the rights and terms governing the manifest content itself.

Licence expressions and manifest rights

Per-component licence declarations and the terms attached to the manifest data.

Declared and concluded component licences

Which licence expression syntax and licence list version govern recorded values, how a declared licence differs from a concluded one, what supports a conclusion, and what is recorded when licensing is undetermined.

Which licence expression syntax and licence list version govern the recorded licence values? interoperability
How is a declared licence distinguished from a concluded licence for the same component? provenance
Which evidence supports a concluded licence value? evidence
What value is recorded when licensing could not be determined for a component? exception

Manifest data licence and confidentiality position

The terms under which the manifest content itself may be redistributed, who holds rights over it, and which confidentiality marking constrains onward sharing.

Under which terms may the manifest data itself be redistributed? ownership
Who holds rights over the manifest content as distinct from the described software? authority
Which confidentiality marking constrains onward sharing of this manifest? privacy

Authenticity Bindings and Declared Quality Integrity of the manifest itself, its binding to external signatures and attestations, and its declared completeness, known unknowns, conformance claims and corrections.

Manifest integrity and authenticity references

The digest over the manifest and the external envelopes bound to it.

Manifest digest and canonical byte form

Which canonical byte form of the manifest is hashed, which algorithms are recorded, how algorithm agility is handled, and how re-serialization affects the recorded digest.

Which canonical byte form of the manifest is hashed for integrity purposes? measurement
Which digest algorithms are recorded, and how is algorithm agility handled over time? security
How does re-serializing the same logical manifest affect its recorded digest? constraint

Signature and attestation envelope binding

How an external signature or attestation envelope is bound to a manifest revision by subject digest, which signer identity is asserted, and where verification outcomes and transparency-log inclusion are recorded by the owning models.

Which signature or attestation envelope is bound to this manifest revision, and by which digest? security
Which signer identity is asserted for this manifest, and where is that claim resolved? authority
Where is the outcome of envelope verification recorded, given that verification is performed outside this model? validation
How is a transparency-log inclusion reference recorded without importing log semantics? interoperability

Declared quality, conformance and corrections

Explicit unknowns, coverage exclusions, baseline conformance claims and the correction of published errors.

Known unknowns and coverage exclusions

How fields that could not be populated are explicitly marked unknown, which parts of the subject are declared outside coverage, and which tooling limitations shaped the result.

How is a field that could not be populated explicitly labelled as unknown? quality
Which parts of the described subject are declared to be outside this manifest's coverage? constraint
Which known limitation of the generating tool affects this inventory? evidence

Baseline element conformance claim and gap report

Which baseline element profiles the manifest claims to satisfy, which required elements are missing or unknown against that claim, which authority publishes the profile, and who is accountable for the claim.

Which baseline element profiles does this manifest claim to satisfy? classification
Which required elements are missing or unknown for the claimed profile? validation
Which authority publishes the claimed baseline, and in which version? authority
Who is accountable for the accuracy of a conformance claim recorded here? ownership

Amendment, errata and supersession of published content

How a factual error in a published manifest is corrected, which prior revisions a correction supersedes or withdraws, and how downstream consumers are notified.

How is a factual error in an already published manifest corrected? process
Which prior revisions does a correction supersede, and are they withdrawn or merely superseded? lifecycle
How are downstream consumers of an erroneous manifest notified of the correction? event

Distribution, Access and Manifest Lifecycle Where the manifest is published and discovered, who may see it and at what granularity, and how it moves through its states from issue to disposal.

Publication, discovery and access

How consumers obtain a manifest and what they are entitled to see.

Publication locators and discovery mechanism

Where a manifest revision is published, how a consumer discovers it starting from the artifact alone, and which delivery method applies when it is not openly retrievable.

Where is this manifest revision published, and by which retrieval address? spatial
Which discovery mechanism lets a consumer find the manifest starting from the artifact alone? interoperability
Which delivery method applies when the manifest is not publicly retrievable? process

Access classification and redaction tiers

The classification applied to a manifest and to individual entries, the redaction or summarization applied per audience tier, the lawful requests that compel disclosure, and how a redacted manifest is distinguished from an incomplete one.

Which access classification applies to this manifest and to individual entries within it? access
Which entries are redacted or summarized for a given audience tier? privacy
Which lawful request obliges disclosure of this manifest to a supervisory authority? authority
How is a deliberately redacted manifest distinguished from an incomplete one? quality

Manifest lifecycle, cadence and disposition

States a manifest revision occupies, the events that trigger regeneration, and the retention and disposal of revisions.

Lifecycle states and authoritative revision

The states a manifest revision may occupy, the events that transition it, and how a consumer determines which revision is authoritative for a given released artifact at a given time.

Which lifecycle states may a manifest revision occupy? state
Which event transitions a manifest revision to superseded or withdrawn? event
Which manifest revision is authoritative for a given released artifact at a given point in time? temporal

Generation cadence, triggers and staleness

Which events oblige a new manifest, the maximum permitted gap between the subject changing and the manifest being reissued, and how cadence is declared to consumers.

Which events require a new manifest to be generated for the subject? process
What is the maximum permitted staleness of a manifest relative to its subject? temporal
How is the manifest generation cadence declared to consumers? requirement

Retention, legal hold and disposition

How long a manifest revision must be kept after the subject reaches end of support, what survives disposal, which holds suspend it, and who executes disposal given that records-management enforcement sits outside this model.

How long must a manifest revision be retained after its subject reaches end of support? retention
Which tombstone record survives disposal of a manifest revision? retention
Who executes disposal, given that records-management enforcement sits outside this model? ownership
Which legal hold suspends scheduled disposal of a manifest revision? authority

Classifiers Filled

Family: World Models
Category: Information and virtual systems
Entry kind: aggregate
Navigation path: NAV.INF.SFT.SBOM
Domain: INF.SFT.SBOM
Industry: Cross-industry
Tags: sbomsupplychainmanifestinf.sft.sbom

What it is Filled

Scope is the SBOM manifest instance as an aggregate record: what it is, what it declares, how it is identified, revised, bound to a subject artifact, published, restricted and retired. The manifest is a declaration made by a named author at a stated time about a described subject. This model owns the manifest's own semantics only. It does not own the described release, the build that produced it, the vulnerabilities correlated against it, the licences it cites, the keys that sign it, or any runtime evaluation of its contents. Storage and interface (JSON-LD, tag-value, XML, protobuf, Git, OCI, MongoDB, MCP) are projections of this model, not part of it.

In scope

Manifest identity, revision series, namespace and immutability of published revisions
Specification and serialization binding (SPDX, CycloneDX, SWID) including declared spec version, profiles and media type
Primary (root) subject binding to a released artifact by identifier and digest, held as a reference
Generation context: SBOM type (design, source, build, analyzed, deployed, runtime), generating tool reference and stated interpretation limits
Component inventory entries: name, version, entry-local reference, type, scope, modification flag
Component identifier sets (purl, CPE, SWID tag id, OmniBOR gitoid, SWHID, ecosystem coordinates) and their normalization for comparison
Component integrity digests with named algorithms and stated coverage
Producer, supplier, author and publisher attribution carried as references to party master data
Asserted relationships (contains, dependsOn, describes) with direction, optionality and per-relationship completeness
Declared dependency depth, aggregate completeness and explicit known unknowns
Cross-manifest links and version-pinned external references to non-SBOM evidence
Declared and concluded licence expressions, licence list version, and the manifest's own data licence
Manifest digest over a defined canonical byte form, and bindings to external signature or attestation envelopes
Baseline element conformance claims and the gap report produced against them
Amendment, errata and supersession of published revisions
Publication locators, discovery mechanisms, access classification and redaction tiers
Manifest lifecycle states, generation cadence and staleness, retention and disposition state

Out of scope

Software package and release identity, versioning and release lifecycle (owned by WM-SFT-007)
Build execution, build platform trust, build parameters and the provenance predicate lifecycle (owned by WM-SFT-008)
Vulnerability records, severity scoring and exploitability determination, including VEX and CSAF authoring semantics
Licence obligation analysis, compatibility determination and compliance decisions
Cryptographic key lifecycle, trust roots, certificate issuance, signature verification execution and transparency-log operation
Policy evaluation, admission gating or enforcement based on manifest content
Consumer-side audit trails and enforcement records produced when a manifest is evaluated at runtime
Live deployed-asset inventory, configuration management database and runtime telemetry
Party and organization master data authoring
Storage-format, transport and query-interface specifics

Why it exists Filled

Distinguishing features Filled

Treats the SBOM as a declaration by a named author at a stated time about a subject, not as the truth about the software.
Differs from the component model, which identifies packages; the manifest lists them for one subject.
Records depth, completeness and known unknowns explicitly.
Separates vulnerability status statements (VEX, CSAF) into their own model.

What robots and AI may and may not do Filled

Must not

Claim completeness the manifest does not have.
Edit a published revision instead of issuing a new one.
Bind a manifest to an artifact without verifying its digest.
Publish a restricted manifest beyond its declared audience.
Treat the absence of a component in the manifest as proof it is not present.

Only with a human decision

Approving publication of a manifest to customers or regulators.
Withdrawing a published manifest.
Accepting a supplier manifest that fails baseline checks.

May

Generate a manifest revision and bind it to the subject artifact digest.
Normalize component entries and relationships.
Check a revision against a minimum element baseline.
Publish a revision with an integrity digest and discovery descriptor.

Moral aspects Filled

Accurate manifests let users respond quickly to vulnerabilities that could harm them.
Detailed manifests can reveal attack surface and should be shared with care.
Responsibility for incomplete declarations must be traceable to the author.

Who is affected

Software users and operators
Suppliers and authors of the manifest
Regulators and procurement bodies

Owners Filled

Steward

Name one accountable owner for manifest records - normally the software product or service owner - and record that owner reference on every manifest identity, including for manifests generated automatically.

Roles

Manifest Producer / Author: Generate manifest content and declare the SBOM type, generating tool and coverage limits; Populate baseline elements or mark them explicitly unknown with a reason; Issue corrections and amendment notices for content the producer authored
Manifest Steward (record plane): Maintain manifest identity, namespace allocation and revision series integrity; Enforce immutability of published revisions and record all in-place annotation changes; Operate canonicalization, digest recording and the no-shadowing policy against neighbour models
Access Approver: Assign and review access classification and audience tiers for manifests and entries; Approve redaction scopes and disclosure variants; Authorise disclosures made under lawful requests or contractual entitlement
Consumer / Verifier: Retrieve manifests through published discovery mechanisms and check digests against the declared canonical form; Perform envelope verification and any policy evaluation in their own systems, holding those outcomes in their own records; Report suspected errors back to the manifest producer for correction
Records Manager: Own the retention schedule, legal-hold placement and disposal execution for manifest records; Confirm tombstone creation and the continued resolvability of disposed references; Coordinate disposal with the owning release model when evidence sets are retired together

Links to other meta-models Filled

child

WM-SFT-007 Software Package / Release - WM-SFT-012 is the registered child of WM-SFT-007 at nav path NAV.INF.SFT.SBOM. The parent owns package and release identity, version scheme, support window and release lifecycle; this model contributes only the manifest that describes a release.

references

WM-SFT-007 Software Package / Release - Instance-level subject binding: the manifest carries a release key and subject artifact digest so a consumer can resolve which release it describes. The manifest never restates release lifecycle states or version semantics.
WM-SFT-008 Build / Release pipeline execution - Records the producing build or analysis run as a pinned reference for the generation-context finding. Build parameters, resolved build dependencies, builder trust and the provenance predicate lifecycle remain owned by WM-SFT-008.
in-toto Attestation Framework v1 and DSSE envelope model - Provides the subject-digest binding pattern used to attach an attestation or signature envelope to a manifest revision. Envelope verification, key trust, revocation and transparency-log operation are owned by the signing and key-management models.
Vulnerability and VEX / CSAF disclosure model - Correlation only: the manifest supplies identifier and digest keys and may carry a pinned reference to an exploitability statement. Affectedness, severity, exploitability status and remediation remain owned by the vulnerability model.
Party / Organization master-data model - Resolves supplier, producer, author and rights-holder names to durable organization identifiers so that attribution is not maintained locally.
SPDX License List and licence expression grammar - Supplies the versioned licence identifier vocabulary and expression syntax for declared and concluded licence values. Obligation analysis and compliance conclusions stay with the licensing model.

aligned

SPDX Specification 3.0.1 (Linux Foundation) - Alignment for element identity by IRI, creation information, integrity methods, relationship semantics with completeness, and the SbomType vocabulary. Alignment is asserted, not conformance.
CycloneDX 1.7 / ECMA-424 (OWASP, Ecma International) - Alignment for BOM metadata, component and dependency structures, compositions aggregates, lifecycle phases and serialization or media-type binding. Alignment is asserted, not conformance.
Package-URL (purl) 1.0 / ECMA-427 - Supplies the governed global identifier scheme and normalization rules used for component identifier sets and for comparison. The purl type registry is maintained externally and is referenced, not reproduced.
CISA Minimum Elements for a Software Bill of Materials (2026 edition) - Baseline element profile against which conformance claims and gap reports are recorded, plus the practices for frequency, depth, known unknowns, distribution, access control and accommodation of mistakes.
Regulation (EU) 2024/2847 Cyber Resilience Act, Annex I Part II point 1 - Regulatory floor for machine-readable format and at-least-top-level dependency depth in the EU, and basis for the supervisory-authority disclosure exception. Applicability determination is made by the adopting Dimension.

composes

Verifiable artifact integrity mix-in (canonical byte form plus named-algorithm digest) - Reusable pattern for digesting an artifact over a declared canonical form with algorithm agility, applied to the manifest document, its companion envelope and its subject artifact.

neighbor

WM-SFT-007 Software Package / Release - WM-SFT-012 is the registered child of WM-SFT-007 and describes a release; the release's identity, version scheme, support window and lifecycle states remain owned by WM-SFT-007. This model carries only a subject reference (release key plus artifact digest) and never re-declares release lifecycle transitions.
WM-SFT-008 Build / Release pipeline execution - WM-SFT-008 owns build execution and build provenance, including the in-toto statement, buildDefinition and runDetails. This model records only the SBOM type and a reference to the producing run; it must not reproduce build parameters, resolved dependencies of the build platform, or provenance predicate lifecycle.
Vulnerability and VEX/CSAF disclosure model - The manifest supplies correlation keys (purl, CPE, digests) and may carry a pinned reference to an exploitability statement, but it never asserts affectedness, severity, exploitability status or remediation. Those semantics stay with the vulnerability model.
Signing, key management and transparency-log models - This model binds an external signature or attestation envelope to a manifest revision by digest and records the asserted signer identity. Key trust, envelope verification, revocation and transparency-log inclusion proof evaluation are performed and recorded elsewhere; a reference here grants no ownership of verification or audit semantics.
Licence and compliance model - The manifest carries declared and concluded licence expressions and the licence list version used. Obligation analysis, licence compatibility and compliance conclusions are out of scope and belong to the licensing model.
Deployed-asset inventory / CMDB - A deployed or runtime SBOM is still a point-in-time manifest declaration, not a live system of record for installed assets. Continuous asset state, drift detection and reconciliation belong to the inventory model.
Policy decision and enforcement model - Conformance claims and completeness reports produced here are descriptive records about this model's own data. Admission control, gating and the audit trail of enforcement decisions are owned by the policy model.

parent

WM-SFT-007

What else AI and robots need to interact with it Filled

Sources Filled

SPDX Specification, Version 3.0.1 - The Linux Foundation / SPDX Project
SPDX 3.0.1 Core Model - Element class - The Linux Foundation / SPDX Project
SPDX 3.0.1 Core Model - Relationship class - The Linux Foundation / SPDX Project
SPDX 3.0.1 Software Profile - SbomType vocabulary - The Linux Foundation / SPDX Project
CycloneDX Specification Overview (v1.7, ECMA-424) - OWASP Foundation / Ecma International
CycloneDX BOM-Link - OWASP Foundation
2026 Minimum Elements for a Software Bill of Materials (SBOM) - Cybersecurity and Infrastructure Security Agency, with NSA, FBI and international partners
Types of Software Bill of Material (SBOM) Documents - CISA-facilitated community working group on SBOM Tooling and Implementation
Regulation (EU) 2024/2847 (Cyber Resilience Act) - European Union (EUR-Lex)
Package-URL (purl) Specification - package-url project / Ecma International (ECMA-427)
in-toto Attestation Framework - Statement layer, spec v1 - in-toto project (CNCF)
SLSA Provenance predicate, version 1.1 - OpenSSF / SLSA
NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1 - National Institute of Standards and Technology
Mapping CISA's 2026 SBOM Minimum Elements to CycloneDX and SPDX - RunSafe Security

Open questions

Resolve the descriptively named neighbour models (vulnerability/VEX and CSAF, party master data, licence compliance, signing and key management, transparency log, policy enforcement, deployed-asset inventory) to real registry model IDs and re-point the seven boundary_notes and all composition links accordingly.
Verify the 2026 CISA minimum elements against the primary publication and settle the two conflicting field groupings encountered; decide whether profile indirection stays or a versioned verbatim element list becomes safe to assert.
Verify the Cyber Resilience Act technical-documentation retention obligation directly against Regulation (EU) 2024/2847, specifically the retention duration and whether the clock starts at placing on the market or at end of support, and correct q-ret-period if the pack's framing is wrong.
Author the three missing functions covering cross-manifest link registration, external evidence reference registration, and licence declaration recording, which currently have findings but no writing function; add_functions was held empty here only because no second provider exists.
Track whether any delegated act, sector regime or successor profile mandates a fixed element list with exact field names, which is the provider's own declared failure mode for the profile-indirect conformance structure.
Assess whether Transparency Exchange API and comparable distribution protocols have stabilised enough to be cited as primary sources for the discovery mechanism, which is presently modelled only abstractly.
Decide whether AI/dataset manifests (SPDX AI and Dataset profiles, CycloneDX ML-BOM) and the hardware, cryptography and operations BOM variants become sibling models reusing this model's identity and integrity patterns, or extensions within this entry.
Re-run this audit against a second provider if the waiver is ever lifted, since the confidence ceiling of 'medium' and the single-provider hold are both consequences of the waiver rather than of any defect found in the delivered result.
Exact field names of the 2026 CISA minimum elements could not be extracted verbatim from the primary PDF; the model deliberately expresses baseline conformance as a versioned profile reference plus a gap list rather than hard-coding a field list that may be misnamed.
Neighbour models for vulnerability and VEX, party master data and licence compliance are named descriptively because no registry model identifiers were supplied for them; their composition links should be re-pointed to real model IDs at boundary review.
SBOM quality and accuracy scoring frameworks are excluded for lack of verified normative grounding.
AI-specific and SaaS-specific manifest descriptors (model cards, data cards, service inventories) are acknowledged as an open area in current guidance and are not modelled; SPDX AI and Dataset profiles and CycloneDX ML-BOM would be the alignment targets if adopted.
Transparency Exchange API and similar emerging distribution protocols are treated only abstractly under discovery mechanism, since their specifications were not verified as stable primary sources here.
Hardware, cryptography and operations bills of materials are out of scope for this entry even though CycloneDX supports them; they would be sibling models sharing this model's identity and integrity patterns.

Machine files

Card as JSON Specification AGENTS.md Source Card backlog vercy.card/1

Provenance

world-models research · reviewable-draft

Built from: models/wm-sft-012-sbom-supply-chain-manifest/spec.yaml, ver-cy/world-models/card-supplements/wm-sft-012-sbom-supply-chain-manifest.json