Notifications
Clear all
Topic starter
02/08/2026 11:45 am
TL;DR: More than 75% of enterprises are already embedding LLMs, AI SDKs, and AI services into applications, yet traditional AppSec tooling does not inventory AI assets, assess model-specific risk, or expose MCP and prompt-driven dependencies, according to Checkmarx. The governance gap is now structural: visibility, policy enforcement, and compliance evidence have to extend beyond SBOM-era assumptions.
NHIMG editorial — based on content published by Checkmarx: AI supply chain risks in application security
By the numbers:
- More than 75% of enterprises are already embedding LLMs, AI SDKs, and AI services directly into their applications.
Questions worth separating out
Q: What breaks when AI dependencies are not included in application security reviews?
A: Security teams lose visibility into a dependency class that can change behaviour, expose data, or invoke tools without appearing in a normal SBOM or vulnerability scan.
Q: Why do AI agents create a governance problem for IAM teams?
A: AI agents create a governance problem because they authenticate and act as autonomous software entities with tool access.
Q: How do organisations know whether AI governance is actually working?
A: AI governance is working when teams can prove that data access, identity permissions, and runtime controls line up with policy in practice.
Practitioner guidance
- Inventory AI dependencies across the release path Map hosted model calls, AI SDKs, agent frameworks, prompts, embeddings, vector stores, and MCP servers into the same asset view used for application and secret inventories.
- Classify AI components as governed dependencies Require approval for any AI service or model endpoint that can change application behaviour, access data, or invoke tools, and route it through release governance.
- Tie AI access to secret and identity controls Review API keys, tokens, service accounts, and delegated permissions used by AI workloads under the same lifecycle and least-privilege rules applied to other non-human identities.
What's in the full article
Checkmarx's full article covers the operational detail this post intentionally leaves for the source:
- The 10 AI supply chain risk categories and how they map to real dependency patterns in application pipelines.
- The practical AI Supply Chain Maturity Model for moving from unknown exposure to governed control.
- A side-by-side comparison of traditional SBOMs versus AI-BOMs for inventory and compliance work.
- The two-floor security architecture that separates what to preserve from existing AppSec and what to add for AI dependencies.
👉 Read Checkmarx's analysis of AI supply chain risks in application security →
AI supply chain governance: what AppSec teams are missing?
Explore further
02/08/2026 12:55 pm
AI supply chain governance is now an inventory problem before it is a scanning problem. Organisations cannot govern what they cannot enumerate, and AI assets often enter through runtime configuration, hosted APIs, and agent orchestration rather than visible source changes. That makes traditional AppSec evidence incomplete even when scans are clean. Practitioners should treat AI-BOM coverage as a prerequisite for control, not a reporting luxury.
A question worth separating out:
Q: Who is accountable when unapproved AI dependencies ship into production?
A: Accountability should sit with the product and security owners who approved the release, but compliance and risk functions also need evidence that governance gates were defined and enforced. Frameworks such as the EU AI Act and ISO 42001 make the absence of traceable AI oversight a board-level problem, not just an engineering oversight.
👉 Read our full editorial: AI supply chain risks are outpacing traditional AppSec controls
