Your enterprise doesn’t need six BOM programs. It needs one evidence graph

In infrastructure and security programs, I have watched visibility projects follow a familiar path. The first dashboard feels like progress. Then the data grows, ownership blurs and the team discovers that visibility without identity and action has become another estate to operate.

Bill-of-materials programs are reaching that point now.

Most CIOs know the Software Bill of Materials, or SBOM. It helps teams investigate software components, licenses, vulnerabilities and supplier exposure. The category is expanding. A Cryptography Bill of Materials identifies algorithms, certificates, protocols and key-management dependencies. AI and machine-learning BOMs describe models, data, evaluations and serving infrastructure. Emerging Authorization BOMs aim to show what people, workloads, services and AI agents can do. Workflow, binary and behavioral inventories add process, delivered artifact and runtime views.

The easy response is to assign each inventory to a different program. In my view, that creates the wrong operating model. The enterprise does not need six disconnected BOM repositories. It needs a common evidence contract that allows specialized records to answer one business question.

The incident question crosses organizational boundaries

When a critical library is disclosed, senior leaders do not ask how many SBOMs the company has collected. They ask which products are affected, whether the code is deployed and reachable, which customers are exposed, what data and actions the service can access, who owns remediation and how quickly the organization can contain the risk.

No single BOM answers that. The decision crosses software, cryptography, identity, workflow, deployment, model and runtime evidence.

An AI agent makes the gap easier to see. A model inventory may identify a provider and version, but the risk changes if the agent can call production tools, read sensitive memory, delegate to another agent or execute without human approval. A component list describes what exists. Authorization and workflow evidence describe what can happen.

Standards improve the evidence, not the operating model

The 2026 CISA-led update to SBOM Minimum Elements strengthens provenance and quality information, including generation context, tool and format details, component hashes, licenses, coverage and known unknowns. SPDX 3.0.1 provides modular profiles. CycloneDX 1.7, standardized as ECMA-424, represents software, cryptographic assets, machine-learning models, services, formulations, vulnerabilities and cross-BOM relationships.

Regulatory pressure is also moving the conversation from voluntary visibility to defensible evidence. The EU Cyber Resilience Act requires manufacturers of products with digital elements to identify and document components, including a machine-readable SBOM covering at least top-level dependencies.

Yet interoperability does not guarantee factual accuracy or operational use. Collection tools may disagree about components and dependency paths. A valid document may describe source code but not the released binary, the approved architecture but not the running deployment, or direct permissions but not transitive authority.

This is why CIO sponsorship matters. Evidence arrives from product engineering, cloud platforms, suppliers, identity teams, AI governance and managed-service providers on different schedules. The CIO can establish the contract across those boundaries: which subjects need evidence, which identifiers are authoritative, how quickly records must refresh, which signatures are trusted and which differences require a decision.

Procurement should use the same contract. Suppliers should state which profiles they support, how evidence is generated, how often it changes, what is withheld and how vulnerability and lifecycle updates are communicated. A material change to a component, cryptographic dependency, model, service or remote-access path should trigger notice, not wait for an annual review.

The contract also needs an assurance scale. Supplier-declared evidence, independently verified evidence, customer-observed evidence and runtime observations should not carry the same weight. The distinction becomes important when two records conflict. A signed supplier statement proves origin and integrity, but it does not prove that a collector found every component or that the customer’s deployment still matches the released product. Recording the evidence class prevents teams from turning a cryptographic signature into a broader claim than it supports.

Ownership must remain visible as well. Product engineering may own the component inventory, security may own vulnerability disposition, IAM may own effective authority and operations may own the deployed state. The graph should preserve those accountabilities while giving incident leaders one path through the evidence. Centralization of every source is unnecessary; consistent identity and decision rules are not.

Build a federated evidence graph

I recommend a federated design. Keep each domain profile in its native format, preserve the original evidence and connect it through a small common envelope and a relationship graph.

Every record should identify the exact subject, version and digest; profile and schema version; producer and tool; lifecycle phase; generation and observation context; creation, validity and expiry times; completeness and known unknowns; sensitivity; owner; and cryptographic integrity. Relationships should be typed, directional, scoped and time-bounded.

Existing specifications can supply much of the plumbing. CycloneDX and SPDX can connect domain records. SLSA provenance and in-toto can describe how an artifact was built. Enterprise signing or Sigstore can bind statements to a producer and subject. VEX and CSAF can record exploitability and remediation status. OpenID AuthZEN 1.0 provides subject, action, resource, context and decision semantics for authorization interoperability. OSCAL can connect machine-readable evidence to controls.

The goal is not to deploy every technology. It is to agree on a few evidence semantics that the whole enterprise will honor.

A 90-day pilot is enough to test the idea

Start with one critical service rather than an enterprise taxonomy exercise.

1. In the first month, collect source, build, artifact and deployment SBOMs. Identify cryptographic dependencies, export effective cloud and application authority, capture one critical workflow and add model evidence if the service uses AI. Assign stable identifiers and owners. Record what each collector cannot see.
2. In the second month, connect the profiles and sign the evidence. Compare declared components with the released binary and deployment. Compare approved authorization with effective and recently exercised authority. Compare the designed workflow with observed calls. The result should be a short list of explainable differences, not a dashboard containing thousands of unowned findings.
3. In the third month, connect material differences to policy. Block an unexpected critical component unless an accountable owner records a time-bounded exception. Require approval and expiry for increased authority. Review a model, workflow or external-service change that lacks matching provenance.

Finish with an exercise. Introduce a vulnerable component, an excessive permission and an unapproved workflow call. Measure the time required to identify affected deployments, reachable resources, accountable owners and containment actions.

Treat the graph as sensitive infrastructure

A connected evidence graph reveals suppliers, high-value identities, trust relationships, model dependencies and operational paths. It can become an attack map if access controls are weak.

Use least-disclosure views. Keep credentials, private keys, raw secrets, proprietary datasets and unrestricted authorization paths out of broadly distributed inventories. Share hashes, attributes and signed attestations when full evidence is unnecessary. Apply classification, retention, access logging and segregation of duties to the evidence platform itself.

Measure decisions, not documents

A useful CIO dashboard should show coverage and freshness for critical services, verified-evidence percentage, cross-profile link completeness, time to impact identification, unexpected authority or runtime drift, revocation propagation time, exception age and sampled accuracy. It should not lead with the number of SBOM files collected.

The opportunity is larger than compliance. Connected evidence can shorten incident triage, improve supplier reviews, make AI governance and zero trust more measurable and give auditors a view closer to the operating state. The enterprise does not need another inventory project. It needs a reliable way to establish what exists, what can happen, what happened and whether that state is approved.