Treat AI models, cryptographic assets, and software dependencies as separate but linked governance domains. Give each domain an owner, map it to a specific BOM type, and connect the resulting data to release approval and runtime policy. That is how organisations avoid treating xBOM as a single spreadsheet exercise.
Separate the governance domains before you try to unify the reporting
AI models, cryptographic assets, and software dependencies behave differently in inventory, risk ownership, and control enforcement, so they should not be managed as one undifferentiated list. ai inventory needs model provenance, usage boundaries, and approval context. Cryptographic inventory needs key, certificate, and signing asset lifecycle detail. Supply-chain inventory needs dependency integrity and release provenance.
The practical mistake is to start with a single spreadsheet and hope it becomes a governance system. Teams usually end up with incomplete ownership, mismatched fields, and controls that cannot tell whether they are approving a model, a signing key, or a package dependency. Lifecycle management guidance shows why inventory is only useful when discovery, ownership, rotation, and offboarding are treated as part of the same operating model.
A better structure is to define three records with shared linkage fields: what the asset is, who owns it, and which release or runtime process depends on it. That lets a team answer different questions without collapsing them into one governance object.
How BOMs should fit each governance domain
Each domain should map to a specific BOM type, because the evidence you need is different. An SBOM tracks software dependencies and transitive components. A CBOM tracks cryptographic material and the dependencies that rely on it. An AI-BOM tracks the model, data, tools, and other AI supply-chain elements that influence how the system behaves and what approvals it needs.
This mapping matters because the control plane differs by domain. A release gate should not ask the same questions of an LLM as it does of a package dependency or an expiring certificate. AI supply chain and AI-BOM guidance is useful here because it frames AI inventory as a supply-chain governance problem, while SLSA anchors the software-provenance side of the same decision chain.
Where teams get value is in the joins: the AI-BOM should point to the release that ships the model, the CBOM should point to the service or pipeline that depends on the key or certificate, and the SBOM should point to the artifacts that are approved for deployment. If those joins do not exist, policy decisions become manual and fragile.
How to connect inventory to approval and runtime policy
Inventory only becomes governance when it affects decisions. Release approval should check whether the relevant BOM record is complete, current, and owned. Runtime policy should enforce the outcome of that approval, such as allowed model endpoints, permitted signing keys, dependency allowlists, or environment-specific constraints. That creates a feedback loop instead of a static register.
The strongest operating model is to treat release approval as a conditional gate and runtime policy as the continuous enforcement layer. The gate answers whether the asset may ship; runtime policy answers whether it may continue to operate under the same assumptions. NIST SSDF supports this approach by tying secure development practices to build and release integrity, while OpenSSF provides the broader supply-chain ecosystem and tooling context for dependency governance.
For cryptographic assets, runtime policy should reflect rotation, revocation, expiry, and algorithm constraints. For AI, it should reflect model provenance, approved use cases, and any limits on tool access or external calls. For software dependencies, it should reflect signed artifacts, trusted sources, and the state of transitive risk. Post-quantum readiness for identity and PKI is a good reminder that cryptographic inventory is not just documentation, it is the basis for migration planning and policy enforcement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Software dependency governance depends on artifact provenance and build integrity. |
| Recommendation — Adopt SLSA-aligned provenance checks before approving software releases. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | The question is fundamentally about structured inventories for governed assets. |
| SI-7 — Software, Firmware, and Information Integrity | Release approval must trust integrity evidence for dependencies and shipped artifacts. | |
| Recommendation — Maintain separate inventories for AI, cryptographic, and software assets with clear ownership. Verify integrity controls before allowing dependencies or models into production. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | A governed xBOM program needs authoritative asset visibility and ownership. |
| A.8.9 — Configuration management | Runtime policy depends on controlled, approved configuration for assets and dependencies. | |
| Recommendation — Record each governed asset in an inventory with an accountable owner. Enforce approved configuration states for models, keys, and dependencies. | ||
Practitioner Guidance
What to prioritise: Start by separating ownership and control decisions from the raw asset catalog. If one team cannot say who approves a model, who owns a signing key, and who is responsible for dependency provenance, the inventory is too flat to govern.
What to verify: Check that each BOM record can be linked to a release artifact and a runtime policy object. If a record cannot drive either approval or enforcement, it is probably documentation, not governance.
Decision rule: If the asset can change production behaviour or trust, require a domain-specific BOM and an explicit owner before release. If it cannot, keep it out of the approval path and reduce noise.
Practitioner takeaway: The goal is not to centralise every inventory into one register, but to preserve domain-specific control while making the records interoperable enough that approval and runtime policy can act on them consistently.
Related resources from NHI Mgmt Group
- How should security teams govern non-human identities alongside human accounts?
- How should teams govern non-human identities alongside CAASM and EASM?
- How should security teams govern API keys used for generative AI access?
- How should security teams govern machine identities in software supply chains?