Dependency Provenance and SBOM Attestation Governance

2. Summary

Dependency Provenance and SBOM Attestation Governance requires that every organisation deploying AI agents maintains a complete, cryptographically verifiable inventory of all software dependencies, model artefacts, and transitive components consumed by those agents across every stage of the build, training, and deployment lifecycle. The inventory takes the form of a Software Bill of Materials (SBOM) that is machine-readable, continuously regenerated, and attested through signatures that bind the SBOM to the specific artefact it describes. Without this governance, an organisation cannot determine whether a deployed agent contains a compromised library, an unlicensed component, a recalled model weight, or a dependency that has been silently replaced by an adversary — creating an unquantifiable attack surface that grows with every untracked transitive dependency.

3. Example

Scenario A — Compromised Transitive Dependency Deployed Without Detection: A financial-value agent processes loan underwriting decisions for a mid-size bank. The agent's inference service depends on a machine learning framework that itself depends on 347 transitive packages. One of those packages — a tensor serialisation library at depth four in the dependency tree — is compromised through a maintainer account takeover. The attacker publishes a new patch version (3.2.17 to 3.2.18) containing an exfiltration payload that transmits serialised model inputs to an external endpoint. The bank's build pipeline uses floating version pins ("^3.2.0") and pulls the compromised version during a routine rebuild. Because no SBOM is generated or compared between builds, the new dependency version enters production without review. Over 19 days, the compromised library exfiltrates 14,200 loan application records including income, employment, and credit history data. The breach is discovered only when a network anomaly detector flags unusual egress traffic.

What went wrong: No SBOM was generated at build time, so no mechanism existed to detect the version change from 3.2.17 to 3.2.18. No cryptographic attestation bound the dependency inventory to the deployed artefact, so the organisation could not verify what was actually running. The floating version pin allowed automatic adoption of the compromised version. Consequence: 14,200 customer records exfiltrated, regulatory notification to three jurisdictions, £2.3 million in breach remediation, regulatory fine of £890,000 for inadequate supply chain controls, and 8-month consent order requiring supply chain governance implementation.

Scenario B — Model Artefact Substitution During Transfer: A safety-critical agent controlling pharmaceutical manufacturing quality checks receives a quarterly model update. The updated model weights are transferred from the training environment to the production inference cluster via an internal file share. During transfer, a misconfigured access control on the file share allows a contractor's automated backup process to overwrite the model file with a stale version from three months earlier. No provenance attestation exists for the model artefact — the deployment pipeline checks only that a file exists at the expected path with a matching filename. The stale model is deployed and operates for 6 weeks before a quality assurance review detects that the model's rejection rate for defective batches has dropped by 34%, meaning defective pharmaceutical batches are passing quality control. Investigation reveals the model substitution.

What went wrong: The model artefact had no provenance record linking it to a specific training run, dataset, or evaluation outcome. No cryptographic hash or signature was verified at deployment time. The deployment pipeline treated any file at the correct path as the correct model. Consequence: 6 weeks of degraded pharmaceutical quality control, recall of 12 batches at a cost of £4.7 million, regulatory investigation by the medicines authority, and suspension of the automated quality control system pending full provenance implementation.

Scenario C — Invisible Licence Violation in Dependency Chain: A public sector agent deployed by a government agency to process citizen benefit applications depends on a natural language processing library. That library's dependency tree includes 89 transitive packages, one of which uses a copyleft licence requiring that any derivative work be released under the same licence. The government agency's procurement rules prohibit copyleft-licensed software in citizen-facing systems due to intellectual property concerns. Because no SBOM inventories transitive dependency licences, the violation is not detected during procurement or deployment. Eighteen months later, an open-source advocacy organisation identifies the violation through reverse analysis of the agency's published container images. The agency must immediately decommission the agent, find an alternative library, retrain and revalidate the model, and redeploy — a process taking 5 months during which the benefit application system reverts to manual processing.

What went wrong: The SBOM either did not exist or did not capture licence metadata for transitive dependencies. Procurement review considered only the top-level library's licence, not the full dependency chain. No automated licence policy check was integrated into the build pipeline. Consequence: 5-month service disruption affecting 230,000 citizens, £1.8 million in emergency manual processing costs, parliamentary inquiry into procurement controls, and reputational damage to the digital transformation programme.

4. Requirement Statement

Scope: This dimension applies to every AI agent deployment where the agent's software stack, model artefacts, or runtime environment includes components sourced from third parties — whether commercial vendors, open-source projects, internal shared libraries, or pre-trained model repositories. The scope encompasses application-level dependencies (libraries, frameworks, SDKs), model artefacts (weights, embeddings, fine-tuning adapters, tokenizers), infrastructure components (container base images, runtime environments), and data pipeline components (preprocessing transforms, feature extractors). Any component not authored entirely within the deploying organisation's direct control is in scope. The scope extends to transitive dependencies at all depths — a dependency of a dependency is subject to the same provenance requirements as a direct dependency. Organisations that use managed services or platform-as-a-service offerings must obtain SBOMs from their providers or generate equivalent inventories through runtime analysis.

4.1. A conforming system MUST generate a machine-readable SBOM for every deployable artefact — application binaries, container images, model packages, and inference service bundles — at build time, capturing all direct and transitive dependencies with their exact versions, cryptographic hashes, and source locations.

4.2. A conforming system MUST cryptographically sign each SBOM using an identity-bound signing mechanism and bind the signature to both the SBOM content and the specific artefact it describes, such that any modification to either the SBOM or the artefact invalidates the attestation.

4.3. A conforming system MUST verify SBOM attestation signatures at deployment time, rejecting any artefact whose SBOM signature is missing, invalid, expired, or does not match the artefact being deployed.

4.4. A conforming system MUST include model artefacts in the SBOM or in a companion Model Bill of Materials (MBOM), recording the model's origin (training run identifier, dataset version, base model lineage), cryptographic hash, evaluation metrics at the time of approval, and any fine-tuning or adaptation applied.

4.5. A conforming system MUST continuously monitor all dependencies listed in production SBOMs against known vulnerability databases and security advisory feeds, triggering alerts within 24 hours of a new vulnerability disclosure affecting any listed component.

4.6. A conforming system MUST detect and alert on any dependency that enters the deployed artefact without appearing in the previous build's SBOM — a "dependency diff" that highlights all additions, removals, and version changes between consecutive deployments.

4.7. A conforming system MUST reject deployment of any artefact containing a dependency whose provenance cannot be verified — specifically, dependencies pulled from unattested sources, dependencies with no verifiable publisher identity, or dependencies whose cryptographic hashes do not match their declared source.

4.8. A conforming system SHOULD integrate licence metadata into the SBOM for every dependency at all transitive depths and enforce automated licence policy checks against the organisation's approved and prohibited licence lists during the build pipeline.

4.9. A conforming system SHOULD implement reproducible builds or build environment attestation such that a given set of source inputs deterministically produces the same artefact, enabling independent verification that the SBOM accurately represents the artefact's contents.

4.10. A conforming system MAY implement runtime SBOM verification — periodic checks during operation that compare the running artefact's actual loaded libraries, model files, and dependencies against the attested SBOM, detecting runtime substitution or injection.

5. Rationale

The software supply chain is the broadest and least visible attack surface for AI agent deployments. A modern AI agent's dependency graph routinely includes hundreds to thousands of components: machine learning frameworks, numerical computing libraries, serialisation utilities, HTTP clients, logging frameworks, data processing pipelines, tokenizers, embedding models, and dozens of their transitive dependencies. Each component represents a trust decision — the organisation is trusting that the component is what it claims to be, that it has not been tampered with, that it does not contain known vulnerabilities, and that its licence terms are compatible with the deployment context. Without a structured, verifiable inventory of these components, the organisation is making thousands of unverified trust decisions with every deployment.

The risk is not theoretical. Supply chain attacks against software dependencies have increased dramatically since 2020. The compromise of widely-used packages through maintainer account takeovers, typosquatting, and dependency confusion attacks has demonstrated that even well-known, heavily-used libraries can become attack vectors. For AI systems specifically, the supply chain risk extends beyond traditional software to model artefacts — pre-trained models, fine-tuning adapters, embedding models, and tokenizers are all artefacts that can be poisoned, substituted, or tampered with. A model artefact does not have the same transparency as source code; a poisoned model weight file looks identical to a legitimate one without cryptographic verification.

Regulatory expectations are converging on supply chain transparency. The EU AI Act's Article 15 requires robustness against attempts to alter the system's use or performance by exploiting system vulnerabilities, which explicitly includes supply chain manipulation. The EU Cyber Resilience Act mandates SBOMs for products with digital elements. The US Executive Order 14028 on cybersecurity requires SBOMs for software sold to the federal government. DORA Article 28 requires financial entities to manage ICT third-party risk, which includes the software components running on their infrastructure. ISO 42001 Clause 6.1 requires risk identification and treatment that encompasses supply chain risks. Organisations that cannot produce an SBOM for their AI agent deployments will face increasing regulatory friction across all major jurisdictions.

The SBOM is not merely an inventory — it is the evidentiary foundation for multiple downstream governance processes. Vulnerability management requires knowing what components are deployed. Licence compliance requires knowing what licences are in the dependency tree. Incident response requires knowing whether a compromised component is present in the organisation's deployments. Regulatory reporting requires demonstrating that the organisation knows what is running in its AI systems. Without the SBOM, all of these processes operate on incomplete information or assumptions. AG-491 establishes the SBOM as a first-class governance artefact with the same rigour applied to financial records or audit logs.

6. Implementation Guidance

Dependency Provenance and SBOM Attestation Governance requires organisations to treat every component in their AI agent stack as a governed artefact with a verifiable chain of custody from source to production. The implementation spans three domains: software dependency tracking, model artefact provenance, and continuous verification.

Recommended patterns:

• Build-time SBOM generation integrated into CI/CD. Generate the SBOM as a mandatory step in the build pipeline, not as a post-hoc analysis. The SBOM generator runs after dependency resolution but before artefact packaging, capturing the exact dependency graph that will be deployed. Use established SBOM formats (CycloneDX or SPDX) for interoperability with vulnerability scanners, licence analysers, and regulatory reporting tools. The SBOM generation step must be a pipeline gate — if SBOM generation fails, the build fails.
• Attestation signing with identity-bound keys. Sign each SBOM using an identity-bound signing mechanism tied to the build pipeline's verified identity, not a shared key. The signature binds the SBOM content hash to the artefact content hash, creating a verifiable assertion that "this SBOM describes this artefact, signed by this build pipeline at this time." Store the attestation alongside the artefact in the artefact registry. Rotate signing keys on a defined schedule and revoke compromised keys immediately.
• Model Bill of Materials (MBOM) for AI-specific artefacts. Extend the traditional software SBOM with an MBOM section or companion document that records: the base model identifier and version, the training dataset identifier and version, the fine-tuning dataset identifier and version, the training run identifier, the evaluation metrics at approval time, the cryptographic hash of the model file, and any quantisation or optimisation applied. This creates a provenance chain from training to deployment that enables verification that the deployed model is the model that was evaluated and approved.
• Dependency diff enforcement at deployment gates. Before any deployment, compute the diff between the incoming artefact's SBOM and the currently deployed artefact's SBOM. Present all additions, removals, and version changes for review. New dependencies or major version changes require explicit approval. Minor version or patch changes may proceed with automated checks (vulnerability scan, licence check) but must be logged. This prevents the silent introduction of new dependencies that occurred in Scenario A.
• Continuous vulnerability correlation. Maintain a service that continuously correlates all production SBOMs against vulnerability advisory feeds. When a new CVE is published, the service identifies every deployed artefact containing the affected component, its version, and whether the vulnerability is exploitable in the deployment context. Alert the responsible team within 24 hours with affected artefact identifiers, deployment locations, and recommended actions.

Anti-patterns to avoid:

• Post-deployment SBOM generation. Generating the SBOM by scanning the deployed artefact rather than capturing the dependency graph at build time. Post-deployment scanning may miss components that are present in the build but not easily discoverable at runtime (build-time code generators, compile-time macros, statically linked libraries). The SBOM must be generated at the point where the full dependency graph is known — during the build.
• Top-level-only dependency tracking. Recording only direct dependencies without resolving the full transitive graph. The compromised library in Scenario A was at depth four in the dependency tree. A top-level-only inventory would not have detected it. Every transitive dependency at every depth must be inventoried.
• Manual SBOM maintenance. Maintaining the SBOM as a manually updated spreadsheet or document rather than generating it programmatically from the actual dependency resolution. Manual SBOMs drift from reality within days of the first unrecorded dependency update.
• Unsigned SBOMs. Generating an SBOM without cryptographic attestation. An unsigned SBOM can be modified after generation — an attacker who gains access to the artefact registry could alter the SBOM to conceal a malicious dependency. Attestation signing makes the SBOM tamper-evident.
• Ignoring model artefact provenance. Treating model files as opaque blobs with no supply chain governance. Model artefacts are the most AI-specific component of the supply chain and the most difficult to inspect visually. Without provenance, a model substitution (Scenario B) is undetectable until its effects manifest in production.

Industry Considerations

Financial Services. Financial regulators increasingly expect software supply chain transparency as part of operational resilience. DORA Article 28 on ICT third-party risk encompasses the software dependencies running financial processing systems. Financial institutions should implement SBOM requirements not only for AI agents but for all software components that influence financial decisions, creating a unified supply chain governance framework. The vulnerability monitoring requirement (4.5) is particularly critical — a compromised dependency in a financial processing agent could enable data exfiltration (Scenario A) or calculation manipulation.

Healthcare and Pharmaceutical. Model artefact provenance (Requirement 4.4) is especially critical in healthcare, where a model substitution (Scenario B) could directly affect patient safety. Medical device regulations (FDA, MDR) increasingly require software bill of materials for device software. Organisations should align their AI SBOM practices with existing medical device SBOM requirements to avoid maintaining parallel governance systems.

Public Sector. Government deployments face additional licence compliance requirements (Scenario C) because public procurement rules often restrict the use of certain licence types. SBOM-driven licence policy enforcement (Requirement 4.8) is essential for public sector deployments. Additionally, government deployments may be subject to national cybersecurity directives that mandate SBOMs, making AG-491 compliance a procurement prerequisite.

Crypto/Web3. Blockchain and decentralised application environments have unique supply chain risks including dependency confusion attacks targeting package registries, compromised smart contract libraries, and adversarial model weights distributed through decentralised storage. The cryptographic attestation requirements of AG-491 align well with the cryptographic verification culture of the Web3 ecosystem, but organisations must extend attestation to cover chain-specific components.

Maturity Model

Basic Implementation — The organisation generates machine-readable SBOMs at build time for all AI agent artefacts, covering direct and transitive software dependencies. SBOMs are cryptographically signed and verified at deployment. A dependency diff is generated between consecutive deployments. Known vulnerability databases are checked at build time. Model artefacts are hashed and the hash is recorded, but full model provenance (training run, dataset lineage) may be incomplete. This level meets the minimum mandatory requirements of 4.1 through 4.7.

Intermediate Implementation — All basic capabilities plus: full model provenance is recorded in an MBOM including training run identifiers, dataset versions, and evaluation metrics. Licence metadata is captured for all transitive dependencies and automated licence policy checks are enforced in the build pipeline. Continuous vulnerability monitoring correlates production SBOMs against advisory feeds with 24-hour alerting. Dependency diff reviews are mandatory for new dependencies and version changes. Build reproducibility is verified for at least the application layer.

Advanced Implementation — All intermediate capabilities plus: full build reproducibility or hermetic build attestation enables independent verification of artefact contents. Runtime SBOM verification periodically confirms that running components match the attested SBOM. Model artefact provenance covers the full lineage from base model through all fine-tuning and adaptation steps. The organisation participates in or consumes industry vulnerability sharing for AI-specific supply chain risks. SBOM data feeds into automated risk scoring that prioritises remediation based on deployment criticality and exposure.

7. Evidence Requirements

Required artefacts:

• Current SBOMs for all deployed artefacts. Machine-readable SBOMs (CycloneDX or SPDX format) for every application binary, container image, model package, and inference service bundle currently in production. Each SBOM must include all direct and transitive dependencies with exact versions and cryptographic hashes.
• Attestation signatures. Cryptographic signatures binding each SBOM to its corresponding artefact, with verifiable signer identity, signing timestamp, and signature validity chain.
• Model provenance records. MBOM or equivalent documentation for each deployed model artefact, recording origin, training lineage, evaluation metrics, and cryptographic hash.
• Dependency diff logs. Records of dependency diffs generated between consecutive deployments, including approval records for new dependencies or version changes.
• Vulnerability monitoring records. Evidence of continuous vulnerability correlation, including alert generation timestamps, affected component identification, and remediation actions taken.
• Deployment gate verification logs. Records showing that SBOM attestation was verified at deployment time for every deployment, including any rejections for invalid or missing attestations.
• Licence compliance records. Where Requirement 4.8 is implemented, records of licence policy checks and their outcomes for each build.

Retention requirements:

• SBOMs, attestation signatures, and deployment verification logs: minimum 7 years for regulated financial services and pharmaceutical; minimum 5 years for other regulated sectors; minimum 3 years otherwise.
• Vulnerability monitoring records: minimum 3 years for all sectors.
• Model provenance records: retained for the full operational lifetime of the model plus 3 years after decommissioning.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. SBOMs must be available in machine-readable format for automated analysis. Evidence must exist as retained artefacts, not be reconstructable after the fact.

8. Test Specification

Test 8.1: SBOM Completeness Verification

• Stimulus: Select a deployed artefact and its attested SBOM. Independently analyse the artefact using a separate SBOM generation tool (or manual inspection for container images) to produce a reference dependency list. Compare the attested SBOM against the reference list.
• Expected behaviour: The attested SBOM contains every dependency found in the reference analysis, with matching versions and hashes.
• Pass criteria: 100% of dependencies in the reference analysis appear in the attested SBOM with correct versions and hashes. Zero unrecorded dependencies.
• Fail criteria: Any dependency present in the artefact is missing from the SBOM, or any version or hash in the SBOM does not match the actual component.

Test 8.2: Attestation Signature Verification

• Stimulus: For 5 deployed artefacts, retrieve their SBOMs and attestation signatures. Verify each signature against the signing key's certificate chain. Then modify one byte of one SBOM and re-verify.
• Expected behaviour: All 5 unmodified SBOM signatures verify successfully. The modified SBOM's signature verification fails.
• Pass criteria: All legitimate signatures verify. The modified SBOM is detected as tampered (signature verification fails). Signer identity is traceable to the build pipeline.
• Fail criteria: Any legitimate signature fails to verify, or the modified SBOM's signature still verifies, or signer identity cannot be determined.

Test 8.3: Deployment Gate Rejection of Unattested Artefacts

• Stimulus: Attempt to deploy three artefacts through the standard deployment pipeline: (a) an artefact with a valid SBOM and valid attestation, (b) an artefact with no SBOM, and (c) an artefact with an SBOM whose attestation signature does not match the artefact (simulating substitution).
• Expected behaviour: Artefact (a) is accepted. Artefacts (b) and (c) are rejected with clear error messages identifying the reason.
• Pass criteria: Artefact (a) deploys successfully. Artefacts (b) and (c) are rejected at the deployment gate. Rejection reasons are logged.
• Fail criteria: Either artefact (b) or (c) is deployed, or artefact (a) is incorrectly rejected.

Test 8.4: Dependency Diff Detection

• Stimulus: Produce two consecutive builds of the same agent. Between builds, add one new direct dependency, upgrade one existing dependency to a new minor version, and remove one dependency. Generate the deployment and examine the dependency diff.
• Expected behaviour: The dependency diff correctly identifies the added dependency, the upgraded dependency (with old and new versions), and the removed dependency.
• Pass criteria: All three changes (addition, upgrade, removal) are correctly identified in the diff. No false positives (unchanged dependencies reported as changed).
• Fail criteria: Any of the three changes is missed, or any unchanged dependency is incorrectly reported as changed.

Test 8.5: Vulnerability Alerting Timeliness

• Stimulus: Inject a test vulnerability advisory for a component known to be present in a production SBOM (using a test advisory feed or synthetic CVE). Record the time of injection and the time the alert is received by the responsible team.
• Expected behaviour: The vulnerability monitoring system correlates the advisory with the affected production artefact and generates an alert.
• Pass criteria: Alert is generated within 24 hours of advisory injection. The alert identifies the correct artefact, component, and version. The alert includes deployment location.
• Fail criteria: Alert is not generated within 24 hours, or the alert does not correctly identify the affected component and deployment.

Test 8.6: Unverifiable Dependency Rejection

• Stimulus: Introduce a dependency into the build that originates from an unattested source — a package with no verifiable publisher identity or a component whose cryptographic hash does not match its declared source repository. Attempt to build and deploy.
• Expected behaviour: The build pipeline or deployment gate rejects the artefact due to the unverifiable dependency.
• Pass criteria: The artefact is rejected before deployment. The rejection identifies the specific unverifiable dependency and the reason (missing publisher identity, hash mismatch, or unattested source).
• Fail criteria: The artefact containing the unverifiable dependency is deployed to production.

Test 8.7: Model Artefact Provenance Verification

• Stimulus: Select a deployed model artefact. Retrieve its MBOM or provenance record. Verify that the cryptographic hash in the provenance record matches the deployed model file. Verify that the recorded training run identifier, dataset version, and evaluation metrics are traceable to their source records.
• Expected behaviour: The deployed model's hash matches the provenance record. The training run, dataset, and evaluation metrics are traceable and consistent.
• Pass criteria: Cryptographic hash matches. Training lineage is fully traceable. Evaluation metrics in the provenance record match the metrics recorded at the time of model approval.
• Fail criteria: Hash mismatch between the deployed model and the provenance record, or any element of the training lineage is untraceable.

Conformance Scoring

• Score 0: No SBOM is generated for AI agent artefacts. Dependencies are not inventoried. Model artefacts have no provenance records. The organisation cannot determine what components are running in its AI systems.
• Score 1: SBOMs are generated at build time covering direct dependencies, but transitive dependencies may be incomplete. SBOMs are not cryptographically attested. Vulnerability checks occur at build time but not continuously. Model artefacts are hashed but lack full provenance. Deployment does not verify SBOM presence or validity.
• Score 2: SBOMs are generated at build time covering all direct and transitive dependencies. SBOMs are cryptographically signed and verified at deployment. Dependency diffs are generated between deployments. Continuous vulnerability monitoring is active with 24-hour alerting. Model provenance records include training lineage and evaluation metrics. Unverifiable dependencies are rejected.
• Score 3: All Score 2 capabilities plus: full build reproducibility enables independent artefact verification. Runtime SBOM verification confirms deployed components match attested SBOMs. Model provenance covers complete lineage including base model, all fine-tuning stages, and quantisation. Licence policy enforcement is automated. The organisation demonstrates through independent testing that no supply chain manipulation can reach production undetected.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 15 (Accuracy, Robustness and Cybersecurity)	Direct requirement
EU AI Act	Article 9 (Risk Management System)	Supports compliance
SOX	Section 404 (Internal Controls Over Financial Reporting)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls)	Supports compliance
NIST AI RMF	MAP 3.4, MANAGE 2.2, GOVERN 1.7	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks and Opportunities)	Supports compliance
DORA	Article 28 (ICT Third-Party Risk)	Direct requirement

EU AI Act — Article 15 (Accuracy, Robustness and Cybersecurity)

Article 15(4) requires high-risk AI systems to be resilient against attempts to alter their use or performance by exploiting system vulnerabilities, including supply chain vulnerabilities. A compromised dependency (Scenario A) or a substituted model artefact (Scenario B) is a direct exploitation of a supply chain vulnerability. The SBOM and its cryptographic attestation provide the evidentiary mechanism for demonstrating that the organisation has implemented technical measures against supply chain manipulation. Without an SBOM, the organisation cannot demonstrate compliance with the supply chain resilience requirement of Article 15.

SOX — Section 404 (Internal Controls Over Financial Reporting)

For financial-value agents that influence financial reporting (transaction processing, risk calculation, loan underwriting), the integrity of the software executing those calculations is a material internal control. SOX auditors assess whether controls exist to ensure that software has not been tampered with and operates as intended. An SBOM with cryptographic attestation provides auditable evidence that the specific software components involved in financial processing have been inventoried, verified, and monitored. The dependency diff requirement (4.6) ensures that changes to financial processing software are detected and reviewed.

FCA SYSC — 6.1.1R (Systems and Controls)

The FCA requires firms to maintain adequate systems and controls for the management of risks, including technology risks. The FCA's operational resilience framework expects firms to know what software is running in their important business services and to manage the risks arising from third-party software components. An SBOM programme provides the foundational visibility that the FCA expects, and the continuous vulnerability monitoring requirement (4.5) demonstrates active risk management of the software supply chain.

NIST AI RMF — MAP 3.4, MANAGE 2.2, GOVERN 1.7

NIST AI RMF MAP 3.4 addresses the identification of risks arising from third-party data and components, directly corresponding to the SBOM requirement for dependency inventories. MANAGE 2.2 addresses the management of AI risks including those from the AI supply chain. GOVERN 1.7 addresses the processes for managing AI system components throughout their lifecycle. AG-491 provides the operational mechanism for implementing these functions — the SBOM is the artefact through which third-party component risks are identified and managed.

ISO 42001 — Clause 6.1 (Actions to Address Risks and Opportunities)

ISO 42001 requires organisations to identify and address risks associated with their AI management system, including risks arising from third-party components. The SBOM provides the structured risk identification mechanism for software supply chain risks. The continuous vulnerability monitoring requirement ensures that newly discovered risks in existing components are identified and addressed, fulfilling the standard's expectation of ongoing risk management.

DORA — Article 28 (ICT Third-Party Risk)

DORA Article 28 requires financial entities to manage risks arising from ICT third-party service providers and components. While DORA primarily addresses outsourcing and third-party services, the regulation's scope encompasses ICT components that financial entities depend upon. Software dependencies are ICT components. The SBOM provides the inventory that DORA requires financial entities to maintain of their ICT dependencies, and the continuous monitoring requirement aligns with DORA's expectation of ongoing third-party risk assessment.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Organisation-wide — a compromised dependency or model artefact may be present in multiple agents across multiple business functions; the same transitive dependency can appear in dozens of deployed artefacts simultaneously

Consequence chain: Failure to maintain dependency provenance and SBOM attestation creates an unquantifiable attack surface across all deployed AI agents. The immediate technical consequence is blindness — the organisation does not know what software and model components are running in its AI systems. This blindness cascades into multiple failure modes. A compromised dependency enters production undetected (Scenario A), exfiltrating data or manipulating outputs for days or weeks before an unrelated detection mechanism discovers the breach. A model artefact is substituted without detection (Scenario B), degrading critical safety or quality controls for the time between substitution and discovery. A licence violation in a transitive dependency triggers forced decommissioning of a production system (Scenario C), causing service disruption. The organisation cannot respond effectively to vulnerability disclosures because it cannot determine which of its deployments contain the affected component, turning a routine patching exercise into an emergency investigation. The blast radius is organisation-wide because the same popular dependency may appear in dozens of deployed artefacts — a single compromised package affects every agent that depends on it. The regulatory consequence compounds the operational impact: regulators in financial services (DORA), healthcare (MDR), and AI governance (EU AI Act) increasingly require supply chain transparency, and the inability to produce an SBOM on regulatory request demonstrates a governance failure that invites enforcement action.

Cross-references: AG-006 (Tamper-Evident Record Integrity), AG-407 (Build Pipeline Attestation Governance), AG-489 (Open-Source Licence Policy Binding Governance), AG-490 (Maintainer Trust and Project Health Governance), AG-494 (Vendor Incident Disclosure Governance), AG-495 (Procurement Security Requirement Governance), AG-405 (Secure Model Artifact Transport Governance), AG-408 (Infrastructure Drift Detection Governance).