Notifications
Clear all
Topic starter
02/08/2026 11:35 am
TL;DR: AI components are already in production, but traditional SBOMs cannot document models, agents, prompts, MCP servers, datasets, or their governance trail, according to Checkmarx. That leaves AppSec teams unable to produce audit-ready evidence for AI usage, making AI-BOMs a practical requirement rather than a future compliance concept.
NHIMG editorial — based on content published by Checkmarx: AI BOMs and AppSec supply chain governance
By the numbers:
- 43% have no formal governance over which AI components their developers are permitted to use.
- 70% expect AI components in production by the end of 2026, with 24% already there today.
Questions worth separating out
Q: What breaks when organisations rely on SBOMs alone for AI-enabled applications?
A: SBOMs can show package dependencies, but they usually miss models, agents, prompts, MCP servers, and dataset provenance.
Q: Why do AI components create a documentation problem for AppSec and IAM teams?
A: AI components blur the line between software inventory and runtime authority.
Q: How do teams know whether AI-BOM output is actually useful for compliance?
A: Useful AI-BOM output is reproducible, traceable, and release-specific.
Practitioner guidance
- Define an AI component inventory policy Classify what must be tracked, including models, agents, prompts, MCP servers, datasets, SDKs, and external service references.
- Require deterministic evidence for AI detections Use source-linked findings from imports, configuration files, API calls, and string constants so every AI component can be traced to a file and line number.
- Embed AI-BOM generation into CI/CD Generate AI-BOM output at build or release time and version it alongside the software artefact.
What's in the full article
Checkmarx's full article covers the operational detail this post intentionally leaves for the source:
- How Checkmarx generates AI-BOM output in CycloneDX format across release pipelines.
- How deterministic detection is implemented using imports, API calls, configuration files, and string constants.
- How policy enforcement works for provider allowlists, blocklists, and floating model references in CI/CD.
- How the output is mapped to CRA, EU AI Act, NIST AI RMF, and ISO 42001 reporting needs.
👉 Read Checkmarx's analysis of AI-BOM governance for AppSec supply chains →
AI BOMs and appsec supply chains: what governance teams need now?
Explore further
02/08/2026 12:49 pm
AI-BOMs are becoming the governance boundary between code inventory and AI accountability. Traditional SBOM practice assumes the security-relevant unit is a versioned package. That assumption fails when models, agents, prompts, and MCP servers affect runtime behaviour without appearing as first-class dependencies. The operational consequence is that audit evidence, risk review, and component ownership now depend on a richer inventory model. Practitioners should treat AI-BOMs as the control point that links technical detection to governance evidence.
A question worth separating out:
Q: Who should own accountability for undocumented AI components in production?
A: Accountability should sit with the application owner, security, and the governance function that approves software change, not with auditors after the fact. For regulated environments, the organisation must be able to show who approved the component, what it can do, and how its scope is controlled across its lifecycle.
👉 Read our full editorial: AI BOMs expose the governance gap in appsec supply chains
