Software Supply Chain Review for Self-Hosted AI Software

Why the review has to be structured

When a regulated enterprise runs AI software in its own cloud or data center, it inherits the vendor's supply chain: base images, open-source libraries, inference runtimes, and model-serving components. NIST asks that supply chain risk assessment, covering component quality, vulnerabilities, and authenticity, be completed before deployment. NIST's draft Cyber AI Profile likewise stresses understanding the origins of AI components, including containers, libraries, and microservices, and the vulnerabilities they may introduce.

A questionnaire does not meet that bar on its own, because answers are not artifacts. A structured review replaces each question with an acceptance criterion, a verification step you run yourself, and a retained piece of evidence. The sections below apply that pattern to SBOMs, signing, and update cadence.

One framing point matters for governance. Supply chain evidence supports a promotion decision; it does not make the decision. An SBOM or a valid signature is an input to risk acceptance, not proof that software is safe.

Control 1: SBOM format, depth, and freshness

Start from the current minimum elements. The 2026 Minimum Elements for a Software Bill of Materials, authored by CISA with partner organizations and listed in September 2026, updates and replaces the NTIA minimum elements. It applies to SBOMs for all software, including open source, AI software, and SaaS. If your internal policy or older NIST text still cites the NTIA elements, check those references against the update.

Translate the guidance into acceptance criteria. Format: SPDX or CycloneDX, the two formats widely used to generate and consume SBOMs. Delivery: machine-readable, which NIST SP 800-161r1 Appendix F says agencies should require where applicable to a procurement action. Depth: all components that make up the software, including transitive dependencies. Freshness: a separate SBOM for each software version or update, including builds that integrate updated components.

For AI software, check that the inference runtime, model-serving components, and base image layers appear in the SBOM, and ask the vendor how it is generated. Ask how sub-tier suppliers' SBOMs are obtained and maintained. If the vendor SBOM is missing or looks incomplete, NIST describes binary decomposition of installation packages as a way to produce a comparison SBOM, where technically and legally feasible. Differences between the two become review findings.

Finally, load the SBOM into a repository that supports automated vulnerability alerting. A static PDF in a procurement folder does not tell you when a listed component becomes vulnerable.

• Format: SPDX or CycloneDX, delivered in machine-readable form.
• Depth: All components, including transitive dependencies and AI runtime and serving components.
• Freshness: One SBOM per release or component-updating build.
• Evidence: Stored SBOM, completeness comparison, and the vendor's description of how it was generated.

Control 3: release cadence, disclosure, and patch expectations

Cadence is the least standardized of the three controls, so the review should turn it into written terms. The goal is predictable exposure and predictable change control. Ask the vendor to state how often it ships releases, how it notifies customers of security fixes, and how quickly it commits to patching vulnerabilities of different severity. Ask how it tells customers whether a vulnerability in a listed component is actually exploitable in its product, because an SBOM lists components and helps identify vulnerabilities but does not show exploitability.

On your side, decide which software assets require automated updates, as NIST recommends, and test integrity after changes. A vendor patch that arrives faster than your change process can absorb is a risk of its own, so match the vendor's cadence to your staging and approval windows. Agree how out-of-band security fixes will be delivered and signed.

OWASP's guidance on LLM supply chain risk adds a durable practice: review supplier security and access regularly, and watch for changes in supplier security posture or terms. Put a re-review date in the record and ask how the vendor will notify you of such changes.

Limits of the review and where runtime controls fit

Each control has a boundary. An SBOM lists what is inside the software; it does not prove those components are exploitable, and it is only as accurate as the process that generated it. A valid signature shows that an accepted party signed an artifact, not that the artifact is free of vulnerabilities. A good cadence reduces exposure time but does not remove it. The review reduces uncertainty before deployment; it does not replace monitoring afterward.

Trussed is deployed self-managed in the customer cloud, which is why this review applies when evaluating it as it would any self-hosted software. Pre-deployment supply chain verification is a separate activity from what Trussed does. Trussed enforces policy in the execution path of AI interactions and tool calls, produces audit-ready evidence from that enforcement, and provides code provenance covering origin, licence, and security context of code. These complement, and do not substitute for, the SBOM, signing, and cadence checks described here.