EVIDENCE TRAIL
Signed AIBOM / Agent SBOM
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The label "Signed AIBOM / Agent SBOM" is Helmwart's normalised title — upstream sources use "AI BOM" (MITRE ATLAS AML.M0023), "AIBOMs / Agent SBOMs" (OWASP Threats & Mitigations T17), and "ML-BOM / AI-BOM" (CycloneDX / OWASP Agentic Top 10 Appendix B) interchangeably.
References
Each row records what a source said, as of the date shown — not a claim about today.
OWASP Agentic AI — Threats & Mitigations v1.1
§T17 Supply Chain Compromise — Mitigation column
"Secure agent ecosystems by digitally signing artifacts, use verifiable SBOMs (AIBOMs, Agent SBOMs), and apply version control with peer review. Enforce strong authentication across the supply chains, restrict untrusted tool installations, and run agents in sandboxed, isolated environments. Continuously monitor for drift or malicious behavior across the supply chain, and red-team agents with simulated supply chain attacks to validate defenses."
Supports: Verbatim upstream prescription of "verifiable SBOMs (AIBOMs, Agent SBOMs)" as the primary mitigation for T17. Directly names this control by type and purpose.
Does not prove: Does not specify a BOM format (CycloneDX vs. SPDX), signing mechanism, or toolchain. Helmwart's guidance on CycloneDX + Sigstore goes beyond what T17 prescribes.
OWASP Top 10 for Agentic Applications 2026
§ASI04 Agentic Supply Chain Vulnerabilities — Prevention and Mitigation Guidelines, item 1
"Provenance and SBOMs, AIBOMs: Sign and attest manifests, prompts, and tool definitions; require and operationalize SBOMs, AIBOMs with periodic attestations; maintain inventory of AI components; use curated registries and block untrusted sources."
Supports: Explicitly names signing, attestation, and AIBOM operationalisation as the supply-chain countermeasures. Covers prompts and tool definitions — the agentic-specific extensions to traditional SBOM scope.
Does not prove: Mitigation list also includes sandboxing, pinning, and kill-switch mechanisms not part of the AIBOM control; those belong to separate mitigations.
OWASP Top 10 for Agentic Applications 2026
Appendix B — Relationship to OWASP CycloneDX and AIBOM
"The OWASP CycloneDX project provides a globally adopted Bill of Materials (BOM) standard that delivers visibility and provenance for software, hardware, and machine-learning components across the supply chain. It defines how to identify and exchange component data-including dependencies, versions, and provenance-through structured SBOM, ML-BOM, and AI-BOM formats."
Supports: Establishes CycloneDX as the OWASP-endorsed BOM standard for ML and AI components, and identifies ML-BOM and AI-BOM as the formats relevant to agentic supply-chain transparency.
Does not prove: Appendix B describes the relationship between the two frameworks at a high level; it does not prescribe implementation steps or signing mechanics.
OWASP LLM Top 10 2025 — LLM03 Supply Chain
§LLM03:2025 Supply Chain — Mitigation Strategies, SBOM item
"AI BOMs and ML SBOMs are an emerging area and you should evaluate options starting with OWASP CycloneDX."
Renumbered in the 2026 LLM Top 10: this entry is now LLM04 Supply Chain. LLM04:2026 →
Supports: Names AIBOM/MLBOM as the primary inventory-based mitigation for compromised upstream AI components. Points to CycloneDX as the starting implementation.
Does not prove: LLM03 focuses on static dependencies in LLM applications, not the runtime-composition threat surface specific to agentic systems. The m-sbom control extends coverage to prompts, model weights, and dynamically loaded tools.
OWASP AIBOM Project
Project homepage — AIBOM definition
"An AI Bill of Materials, SBOM for AI, or AIBOM is a structured machine readable inventory of AI components such as models, datasets, agents tools, guardrails, and runtime elements along with evidence of origin, rights, integrity and evaluation."
Supports: Canonical OWASP definition of AIBOM scope: models, datasets, agent tools, guardrails, and runtime elements. Confirms that prompts and tooling are in scope, not just code dependencies.
Does not prove: Project is an active workstream without a published standard; the definition reflects current project consensus, not a ratified specification.
MITRE ATLAS AML.M0023 — AI Bill of Materials
AML.M0023 — description field
"An AI Bill of Materials (AI BOM) contains a full listing of artifacts and resources that were used in building the AI. The AI BOM can help mitigate supply chain risks and enable rapid response to reported vulnerabilities. This can include maintaining dataset provenance, i.e. a detailed history of datasets used for AI applications. The history can include information about the dataset source as well as a complete record of any modifications."
Supports: MITRE ATLAS independently names AI BOM as the mitigation for supply-chain risks (AML.T0011, AML.T0019, AML.T0020, AML.T0058). Frames dataset provenance as a first-class AIBOM concern.
Does not prove: Does not specify BOM format, signing, or the prompt/tooling components that distinguish agentic AIBOM from a conventional SBOM.
MITRE ATLAS AML.M0014 — Verify AI Artifacts
AML.M0014 — description field
"Verify the cryptographic checksum of all AI artifacts to verify that the file was not modified by an attacker."
Supports: Names cryptographic checksum verification of AI artifacts as the integrity mechanism — the runtime-verification half of signed AIBOM. Directly supports the Sigstore signing step in this mitigation.
Does not prove: Scoped to artifact integrity (checksums); does not address the inventory/provenance dimension or the format in which those checksums are published.
CycloneDX v1.6 JSON Schema — machine-learning-model component type
CycloneDX v1.6 JSON reference — components[].type enum value "machine-learning-model"
"A model based on training data that can make predictions or decisions without being explicitly programmed to do so."
CycloneDX v1.7 has been the current release since October 2025. This quote is from the v1.6 schema. CycloneDX v1.7 schema →
Supports: Confirms that CycloneDX 1.5+ defines a first-class component type for ML models, enabling machine-readable AIBOM generation using standard tooling.
Does not prove: The component-type definition does not describe prompt or agent-tool provenance fields — those are addressed in the MLBOM capability extension, not the base type enum.
2026 Minimum Elements for a Software Bill of Materials (SBOM) — CISA with seventeen co-authoring organisations (NSA, FBI, ASD’s ACSC, Cyber Centre, NÚKIB, ANSSI, BSI, CERT-In, ACN, METI, NCO, NIS/NCSC, KISA, NCSC-NL, NCSC-NZ, NASK, NBU)
§Data Fields → Component Data → Component Hash Algorithm (New), p. 12
"The Component Hash Algorithm element documents the algorithm that produced the Component Hash Value to allow validation of the integrity of the target component. The SBOM author should identify the algorithm using Internet Assigned Numbers Authority (IANA) Hash Function Textual Names. The algorithm should be approved by a relevant authority, such as NIST."
Supports: Places the hash-pinning mechanism of this control inside the SBOM baseline rather than leaving it an optional practice. Component Hash Value (the hash of the executable component artifact) and Component Hash Algorithm are both new in the 2026 elements, and the stated purpose — validating the integrity of the target component — is exactly the startup check this mitigation performs. SBOM Author Signature, also new, covers the manifest itself.
Does not prove: Expects the hash and algorithm to be recorded in the SBOM; it does not prescribe verifying them at agent startup, nor a signing toolchain such as Sigstore. It also permits an explicit "unknown" value where the SBOM author had no access to the executable artifact, so a conforming SBOM does not guarantee a hash is present for every component. The document is also explicit that the minimum elements "do not create new requirements; they refine how organizations should generate and request SBOMs" — so these are baseline expectations, not a compliance obligation in themselves.
2026 Minimum Elements for a Software Bill of Materials (SBOM) — CISA with seventeen co-authoring organisations
§Appendix B: Summary of Minimum Elements Changes From 2021 — Automation Support (Major Update), Explanation, p. 20
"SWID tags are not a widely used SBOM data format for which multiple tools exist. SBOM data formats and SBOM tools have prioritized machine processability and established using machine-processable data as a core practice for SBOM implementation."
Supports: Records the 2026 change to the automation element: the same Appendix B entry states that the changes are to "Remove Software Identification (SWID) Tags from list of data formats. Replace Automation Support element with Machine-Processable Data element. Move Machine-Processable Data element under Practices and Processes." Confirms that machine-readable BOM output is a baseline practice, not an implementation detail.
Does not prove: The removal of SWID is scoped to the list of SBOM data formats; it is not a ruling that only SPDX and CycloneDX are acceptable. The document describes those two as "The two data formats currently widely used by software ecosystem stakeholders to generate and consume SBOMs", which is a statement about the ecosystem, and the element itself asks organisations to "accept any widely used, interoperable, and machine-processable SBOM format." Reading it as a two-format mandate overstates the source.
2026 Minimum Elements for a Software Bill of Materials (SBOM) — CISA with seventeen co-authoring organisations
§Introduction → Scope, p. 7
"The minimum elements outlined in this document apply to SBOMs for all software, including open source software, AI software, and SaaS. While additional elements may be necessary to make more complex software systems (such as AI or SaaS) transparent, an SBOM should still include the minimum elements. Additional elements that may be necessary to enable transparency for specific types of software are out of scope for this document."
Supports: Puts AI software explicitly inside the scope of the minimum elements, so an agent’s conventional dependencies, model files, and container images are covered by the same baseline as any other software. Confirms the baseline is a floor an AIBOM builds on rather than a parallel track.
Does not prove: Does not supply the AI-specific fields this mitigation depends on. The Discussion section states that "this document does not introduce additional elements for SBOMs for AI systems"; model lineage, dataset provenance, and prompt-template inventory come from the AIBOM/MLBOM layer and from the separate CISA and G7 guidance Software Bill of Materials for AI – Minimum Elements (May 2026), not from this document.
Excerpts are quoted for verification and credited to each source above. MITRE ATLAS content is © 2021–2026 The MITRE Corporation, reproduced and distributed with the permission of The MITRE Corporation, and licensed under the Apache License 2.0. ATLAS and ATT&CK are trademarks of The MITRE Corporation and no endorsement is implied. OWASP content is licensed under CC BY-SA 4.0.