Then, weeks later, leadership asks: “Are we using AI in any of our applications?” 

Honestly? No one knows. 

Somewhere in your codebase, invisible to every tool you have, an application is calling a hosted LLM service. An agent framework arrived through a dependency. Prompts are loading from runtime configuration. Embeddings are being sent to a vector store. 

None of it shows up in your SBOM. None of it is on anyone’s radar. 

This isn’t a failure of your security team. It’s a structural gap. 

The Supply Chain is Changing (Again) 

For years, traditional AppSec protected a predictable set of things: application code, open-source packages, secrets, containers, and infrastructure. SAST, SCA, vulnerability management, all built for that world. 

Then AI became a production dependency. 

More than 75% of enterprises are already embedding LLMs, AI SDKs, and AI services directly into their applications. But the security and governance programs designed to manage software haven’t caught up. 

Modern applications now depend on: 

• Hosted AI services (LLM APIs) 

• AI frameworks and SDKs 

• Agent code and MCP servers 

• Prompts and datasets 

• Embeddings and vector stores 

These don’t behave like traditional dependencies: 

• A model can be safe in testing and unsafe under real-world prompts 

• A prompt can quietly change system behavior without changing application logic 

• An MCP tool can expand execution capability beyond what developers intended 

• A service provider can change data retention terms without a code change 

Traditional AppSec tools don’t detect these risks because they weren’t designed to. They can’t assess model poisoning, unverified weights, unsafe adapters, malicious MCP servers, or licensing violations.  

None of these are hypothetical. They’re showing up in real pipelines, real codebases, and real compliance conversations, often without anyone realizing it. 

At the same time, regulatory pressure is real. The EU AI Act, ISO 42001, and other frameworks are creating real accountability for AI governance. Yet, most organizations lack even a basic AI asset inventory, let alone the ability to demonstrate compliance. 

The Hidden Threats in Your AI Dependencies 

Below are 10 prominent AI supply chain risks validated by OWASP LLM03:2025 (the industry standard) and our own Checkmarx Zero research team. 

These risks reflect where visibility gaps typically become security gaps in this new supply chain structure: 

Group A: Trust & Provenance Poisoned models, fake models, abandoned models, vulnerable AI packages—risks tied to where models actually come from and whether you can trust them. 

Group B: Modification & Fine-Tuning Malicious adapters, model merge exploits—risks introduced when models are altered without visibility. 

Group C: Deployment Risks Mobile and edge model attacks where compromised models are embedded outside standard update mechanisms. 

Group D: MCP Supply Chain Tool poisoning, compromised dependencies, shadow MCP servers, unauthorized integrations that expand what AI can actually do. 

Group E: Governance & Exposure Licensing violations, unclear terms-of-service, privacy policy drift that quietly changes how your data is used. 

Each reflects a different failure mode: compromised artifacts, unmanaged modifications, invisible deployments, unauthorized connections, and untracked obligations. 

Where Does Your Organization Actually Stand? 

Most security teams assume they’re at least partially aware of their AI exposure. In practice, the answer is usually Stage 1: Unknown. There’s no inventory, no policy enforcement, and no audit trail, just scattered usage across repos and environments. 

Getting from Unknown to Governed isn’t a single leap. It’s a defined progression: from discovery, to control, to compliance-ready reporting. Understanding where you sit today is the prerequisite to knowing what to do next. 

Visibility First, Then Everything Else  

What connects all these risks is something simple: if you don’t know an AI component exists in your software, you can’t assess it, govern it, or protect against what it might do. 

This requires building what didn’t exist before: an AI-BOM, an inventory that captures what AI is running your applications and what that implies for risk and compliance. 

This requires four capabilities: 

1. Discover AI assets across code and configuration 

2. Assess AI-specific risks (not just CVEs) 

3. Control through policy enforcement and approved registries 

4. Report compliance-ready documentation 

AI is already embedded in your stack, whether you know it or not. The goal isn’t to slow adoption, it’s to bring the same AppSec discipline to AI dependencies that teams already apply to everything else they ship. 

That starts with visibility.  

Want to go deeper?  

We’ve put together a full breakdown of the threat landscape with all 10 risk categories, real-world examples, and the controls mapped to each. But more than that: the guide walks through a practical AI Supply Chain Maturity Model so you can identify where your organization stands today, a side-by-side comparison of traditional SBOMs vs. AI-BOMs, and a two-floor security architecture that tells you what to preserve from your existing AppSec program and what to add on top of it. 

Read it now  

Every commit now triggers a chain reaction of scans across SAST, SCA, IaC, containers, APIs, secrets, and cloud infrastructure, with each producing its own findings, severity rating, and risk interpretation. And when everything appears critical, developers are left with no guidance on what to fix first. The introduction of AI coding propelled new risks almost overnight speeding everything up. While AI tools help teams ship faster, they also create more code, more components, and more attack surface – leading to more alerts and more noise.

The alert problem that existed before AI? It intensified. And when everything looks urgent, teams lose focus on the vulnerabilities that create business risk.

Developers can’t operate effectively when they’re constantly buried under alerts without prioritization or clarity. Because when they can’t distinguish between theoretical and real threats, critical vulnerabilities slip through unnoticed, exposure windows widen, and business risk increases.

This is exactly the outcome we need to prevent. Detecting vulnerabilities is easy; the real challenge is understanding which ones matter, why they matter, and what to fix first.

The Noise Problem: Volume vs. Actionable Insights 

Noise isn’t just annoying, it’s dangerous. When teams are forced to sift through endless alerts, fatigue sets in and important issues get overlooked.

To make matters worse, these alerts rarely tell a coherent story. Each scanner operates independently, surfacing different symptoms of potentially related problems.

SAST may identify a potential injection risk, SCA may flag a critical CVE in a transitive dependency, and IaC may highlight risks in cloud configuration – all at the same time.

Individually, each issue appears “critical,” but without understanding how the vulnerabilities relate to each other and to real execution paths, AppSec teams are flying blind, leading to:

• Multiple tools reporting versions of the same underlying issue
• High‑severity findings in code paths that cannot execute
• Duplicate tickets routed to different teams
• “Critical” vulnerabilities treated equally, regardless of real impact

The problem isn’t the volume of alerts, but the absence of context. Raw vulnerability data means nothing without the intelligent insights to prioritize them. Because when every vulnerability is “urgent,” nothing actually is.

Contextual Risk Scoring: What It Is, How It Works, and Why It Matters 

When teams understand a vulnerability’s real-world impact, they can stop chasing theoretical risks and instead fix the issues that matter most.

Instead of treating all “critical” tags equally, contextual risk scoring evaluates how a vulnerability behaves in your specific application and if it presents a realistic threat. This allows teams to move from severity‑driven triage to intelligent risk‑driven prioritization.

Contextual risk scoring takes the following into account:

Exploitability: Is there a realistic attack path? Are exploit techniques known or emerging? Is the weakness commonly abused in the wild?

Reachability: Is the vulnerable code path actually executed? Can untrusted input reach it? A flaw in unreachable or dead code may pose minimal risk despite its severity.

Correlation: Do signals from multiple scanners converge on the same root issue? Correlation provides a deeper understanding of location, impact, and propagation across services.

Business impact: How critical is the asset? Does it handle sensitive data? Is it externally exposed? Does it support a revenue‑generating or regulated function?

By combining these factors, contextual risk scoring aligns remediation with real exposure. This is how a “critical” issue in an unused library becomes low urgency, while a “medium” flaw in an internet-facing API becomes top priority. Severity alone can’t make that distinction, but contextual risk scoring can.

Correlation Between Scanners: Full Context Requires Multiple Signals Working Together

We need to get smarter about where we focus. Not every vulnerability is worth dropping everything for, and only teams that filter out the noise and focus on what really matters are able to stay ahead of risk.

Teams today rely on a variety of scanners, but no single engine provides complete risk context.

A dependency vulnerability flagged by SCA is just random data until you know whether your application code calls the affected function. An exposed cloud configuration only becomes urgent when tied to the services and code running on that infrastructure.

Let’s look at an example:

SCA flags a critical CVE in a transitive dependency. On its own, it looks urgent. But SAST scan shows no code path that calls the affected function, and runtime signals confirm the component isn’t loaded in production. Three scanners, three separate alerts – but when correlated, the actual risk is low. Meanwhile, a medium-severity SAST finding in an internet-facing API that handles PII, is reachable, and is exercised in production traffic. That “medium” instantly becomes the top priority.

That’s why correlation matters. It stitches together findings across code, dependencies, infrastructure, containers, and runtime environments – transforming disconnected alerts into a single, unified view of actual risk.

Without it, everything becomes noise.

The correlation of findings across SAST, SCA, IaC, API testing, runtime signals, container scans, and CI/CD metadata helps teams determine:

• When multiple alerts represent the same issue
• Whether vulnerabilities propagate across microservices
• If issues exist in deployed, production-facing assets
• Which components introduce actual operational risk
• True root causes that need to be fixed

Correlation turns noise into intelligent, actionable signals. Instead of dozens of fragmented alerts, teams receive a single, contextualized insight that reflects the complete picture. This unified code‑to‑cloud intelligence closes visibility gaps, eliminates redundant triage, and enables smarter prioritization for faster, more efficient remediation. 

Turning Contextual Insights Into Actionable Remediation 

Insight alone doesn’t reduce risk, action does. Risk reduction requires turning signals into a fast, confident remediation. A vulnerability isn’t neutralized just because it’s been detected. It’s only eliminated when developers understand why it matters, where it originates, and how to fix it without wading through logs or deciphering cryptic scanner output.

This is where contextual risk intelligence stops being just a risk scoring exercise and becomes a practical remediation engine. When you combine exploitability, reachability, and cross‑scanner correlation, you give developers something they rarely get: findings they can trust. Instead of another generic “critical” label, they get true prioritization – and a clear explanation of why the issue is important, the exact code path, and where to remediate. And that clarity transforms how teams work.

Delivering these insights directly in the IDE is what makes them actionable. There’s no tool sprawl or no context switching. Developers don’t need to jump between dashboards or triage queues because the context comes to them, showing them precisely which part of the code needs attention.

Your AppSec stack doesn’t need more scanners or stricter thresholds, it just needs contextual intelligence. Contextual risk scoring cuts through the noise to surface genuine threats to your code. And when that intelligence reaches developers where they work, directly in their workflow, remediation becomes fast, confident, and focused.

The most effective teams aren’t the ones processing every alert, they’re the ones with enough context to confidently deprioritize most of them. When everything is labelled “critical,” protecting against true vulnerabilities requires the ability to actually distinguish real risk from noise.

Leader in the 2025 Gartner® Magic Quadrant for Application Security Testing (AST)

We feel this recognition affirms our developer-centric approach to application security, our commitment to innovation, all deeply attuned to the needs of DevSecOps, modern development, and real risk across the software supply chain. 

This year, Checkmarx was also positioned furthest on the Completeness of Vision axis out of all 16 evaluated vendors, which assesses a vendor’s Innovation, Market Understanding, Marketing Strategy, Offering (Product) Strategy, Business Model and Vertical/Industry Strategy.  

This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Checkmarx. 

In addition to our leader position in the Magic Quadrant, Checkmarx earned the highest ranking in the 2025 Gartner® Critical Capabilities for Application Security Testing companion report, across DevSecOps and Customer use cases.

Recognized for Vision, Built for AppSec 

We believe this continued recognition from Gartner reinforces our ongoing commitment to innovation and how customers benefit from our AI-driven innovation, broad coverage, and seamless integration into modern development workflows. 

We’re proud of our comprehensive suite of application security capabilities, built with a strong focus on developer experience. We continue to invest in and expand these solutions to help developers and security teams work smarter and faster—keeping pace with the speed of AI.  

With AI-native capabilities embedded at every layer of the SDLC, Checkmarx One secures both human-written and AI-generated code, across IDEs, languages, etc enabling secure development from code to deploy. This includes our AI assist family of agents, providing developers with real-time, AI-driven guidance directly in their workflows to remediate vulnerabilities more effectively.  

Thank you to our incredible customers, partners, and employees who have been, and will continue to be, the cornerstone of our success. 

Ready to learn more?   

Access the 2025 Gartner® Magic Quadrant for Application Security Testing (AST)  report or get a demo to learn more about Checkmarx One.   

Gartner®, Magic Quadrant for Application Security Testing, By Jason Gross, Mark Horvath, Giles Williams, Shailendra Upadhyay, Dionisio Zumerle, Aaron Lord, October 6, 2025 

Gartner®, Critical Capabilities for Application Security Testing, By Mark Horvath, Jason Gross, Aaron Lord, Shailendra Upadhyay, October 13, 2025

Magic Quadrant is a registered trademark of Gartner, Inc. and/or its affiliates and is used herein with permission. All rights reserved. Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.  GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.   

Choosing the right ASPM is critical to achieving AppSec success. The ability to correlate and contextualize risks in real time helps you keep pace with development cycles that now move at hyper speed.  

According to the IDC MarketScape, “Checkmarx is a strong fit for organizations seeking an ASPM solution embedded in a developer-focused AppSec platform, supported by sustained AI investment, and designed to deliver strong return on investment for platform-oriented buyers.”

“We’re honored to be named a Leader in the IDC MarketScape for ASPM,” said Jonathan Rende, Chief Product Officer at Checkmarx. “We believe this recognition validates our vision of delivering an AppSec platform where AI and developer experience go hand-in-hand. With Checkmarx One, we’re helping organizations gain earlier visibility into application risk, streamline remediation, and reduce total cost of ownership.” 

Making ASPM Actionable for Developers 

The report noted, “Checkmarx is advancing its AI strategy through a multiagent framework designed to embed intelligent automation across the SDLC. Within this framework, the Checkmarx One Assist family includes specialized agents for secure coding, as well as policy orchestration and enforcement. The forthcoming Insights Assist Agent, most relevant to ASPM, is intended to provide real-time visibility into application security posture, risk trends, and SLA adherence.”  

As the IDC MarketScape notes: 

“By embedding ASPM directly into the IDE, the platform provides real-time visibility into application risk during code development. Developers can view exploitable vulnerabilities and a filtered list of the top 50 critical issues without leaving their workflow, reducing context switching and improving productivity.” 

Instead of overwhelming developers with every finding, Checkmarx ASPM surfaces the few vulnerabilities that matter most. The result is up to 40 percent noise reduction, with clear guidance on what to fix first.  

Developers get precise, actionable insights in their IDE with guidance on the best fix location, while security teams have a centralized, clear view of risk posture, remediation progress, and coverage gaps.

Analyst Report

2025 IDC MarketScape for Application Security Posture Management (ASPM)

Download your free copy to explore why Checkmarx was named a Leader in Application Security Posture Management (ASPM).

Get the Report

Checkmarx One: A Platform-Centric Approach to ASPM 

Checkmarx ASPM solves this gap by turning raw data into unified, actionable risk insights. Unlike point solutions or siloed ASPM add-ons, Checkmarx One delivers ASPM as a native capability within a unified, cloud-native platform.  

Checkmarx ASPM correlates data across tools to reduce alert fatigue and prioritize exploitable vulnerabilities. With a centralized view of risk posture, coverage gaps, and remediation progress, security leaders and engineering teams can act faster and smarter.  

You can access aggregate  data from our in-house scanners, including SAST, SCA, DAST, IaC, and container security, alongside findings from third-party tools via our bring-your-own-results (BYOR) capability and CNAPP integrations.

This unified data is transformed into a single, contextual view of application risk, so you can prioritize what truly matters: exploitable vulnerabilities, ranked using real-world signals like business context, runtime exposure, and asset criticality, not just static severity scores.  

This platform-centric approach ensures security teams and developers operate from a shared source of truth, accelerating decision-making, streamlining remediation, and delivering measurable ROI across the entire application security lifecycle. 

Making AI a Priority: Intelligent Automation Across the SDLC 

The report noted, “AI is a strategic priority for Checkmarx, with capabilities embedded across the platform to enhance risk analysis, accelerate remediation, and reduce manual effort.” 

Capabilities include: 

• In-IDE secure coding guidance 

• AI-generated fix recommendations 

• Risk scoring enriched by exploitability, business impact, and runtime exposure 

The growing Checkmarx One Assist agent family reflects this investment, bringing automation to secure coding, policy enforcement, and posture visibility, all from within the developer’s workflow. 

See Why IDC MarketScape Named Checkmarx a Leader in ASPM 

The 2025 IDC MarketScape named Checkmarx a Leader in ASPM. By unifying findings across SAST, SCA, DAST, IaC, containers, and third-party tools, Checkmarx delivers real-time, contextual risk visibility and prioritization—directly within developer workflows. 

Read the IDC MarketScape report excerpt 

Get a demo of Checkmarx ASPM to see how it fits into your AppSec strategy. 

IDC MarketScape: Worldwide Application Security Posture Management Platforms 2025 Vendor Assessment, Doc # US53001925, September 2025

IDC MarketScape vendor analysis model is designed to provide an overview of the competitive fitness of technology and suppliers in a given market. The research methodology utilizes a rigorous scoring methodology based on both qualitative and quantitative criteria that results in a single graphical illustration of each supplier’s position within a given market. The Capabilities score measures supplier product, go-to-market and business execution in the short-term. The Strategy score measures alignment of supplier strategies with customer requirements in a 3-5-year timeframe. Supplier market share is represented by the size of the icons.

From outdated base images and misconfigurations to runtime drift and exposed secrets, container security risks grow at every stage of the SDLC, and fixing them in production can cost up to 30x more than catching them early. 

In our recent webinar, AppSec experts from Checkmarx break down the most common misconceptions around container security and show how to avoid costly mistakes with a smarter, layered approach. 

Here’s a quick rundown of the key takeaways. 

Misconception 1: “We already scan the code. We’re covered.” 

The Reality: Scanning your codebase with tools like SAST or SCA is just the beginning. Once code is containerized, it can pull in unseen dependencies, packages, and configuration risks during build time, things that simply aren’t visible in the repo. 

Why it matters: 

• Build-time actions can introduce hidden vulnerabilities. 

• Dependencies may be pulled from untrusted or outdated sources. 

• Scanning only the repo leads to false positives (chasing what never deploys) and false negatives (missing real risks). 

The fix: What you see in the repo isn’t always what you get in the final image. Scan the fully built container image, not just the codebase or Dockerfile. This reveals what’s going to run, including hidden packages, malicious layers, and runtime-only risks, giving you a truer picture of what’s going to run in production. 

Misconception 2: “Our base images are from Docker Hub, so they’re safe.” 

The Reality: Just because an image comes from Docker Hub doesn’t mean it’s secure. Public registries are full of outdated, unmaintained, or even malicious images, including some that look official, and many containing tens of thousands of known vulnerabilities. No matter how trusted the source feels, we can’t take it as face value. 

Why it matters: 

• Typosquatting is real: attackers create images that mimic popular ones to exploit developer trust. 

• Even popular images often carry hundreds of known vulnerabilities. 

• Many haven’t been updated in 2+ years, leaving them wide open to known exploits. 

The fix: Scan early, scan often, and treat base images like any other dependency in your supply chain. Tags like “Docker Official” or “Verified Publisher” help as they go through additional vetting, but they’re not foolproof. Always scan base images before building on top of them and maintain a pre-approved image library to reduce risk across teams. 

Secure Early, Ship Fast

Smarter Container Security

Get smart with your use of containers and understand the real threats you face with practical advice on how to deal with them.

Watch Now

Misconception 3: “If we patch known vulnerabilities, we’re secure.” 

Reality: Most container breaches don’t happen because of unpatched CVEs, they happen because of misconfigurations. While patching is critical, it’s not enough. Misconfigurations are just as dangerous as unpatched code. And they’re often even easier to exploit. Containers and Kubernetes environments often fall victim to security gaps like containers running as root, secrets hardcoded in code or config files, and clusters with overly permissive roles or unnecessary exposure.  

Why it matters:  

• Privilege escalation. If a container is running as root or has more access than it needs, it’s like handing over the master keys. From there, attackers can move laterally and gain full control. 

• Data exposure. A single hardcoded secret or exposed config file is all it takes. Suddenly, attackers have direct access to your databases, APIs, or internal services. 

• Resource hijacking. Think crypto mining, service abuse, or denial of service. All made possible just because a resource limit wasn’t set correctly. 

The fix: Treat misconfigurations with the same urgency as vulnerabilities. To help prevent these kinds of misconfigurations before they hit production, we built KICS, an open-source tool that scans Terraform, Kubernetes, Docker, and other IaC files for security risks and compliance gaps. It supports over 2,400 checks out of the box, is highly customizable, and plugs easily into CI/CD pipelines. 

For leaked credentials, 2MS (Too Many Secrets) goes a step further, scanning not just your code files, but applications like Slack channels, Confluence docs, and more 

Misconception 4: “We’ll catch it all with runtime scanning.” 

The Reality: Relying only on runtime scanning is like locking the door after the intruder has already walked in. Yes, runtime security, monitoring, intrusion detection, anomaly alerts, is critical. But if that’s your first line of defense, you’re reacting too late. 

Why this matters: 

• The average time it takes to patch a vulnerability? 38 days 

• The average time it takes attackers to exploit a new one? Just 12 days 

That’s a 26-day head start for attackers, and they don’t wait for your next sprint. When vulnerabilities are found too late, the damage goes beyond just code: 

• Fixing issues in production costs up to 30x more than catching them earlier. 

• Delays lead to business disruption, customer trust issues, and possible regulatory penalties 

The fix: Adopt a defense-in-depth strategy. Runtime tools are your last line of defense,  not your only one. The earlier you catch issues, the safer (and cheaper) your containers will be. Scan early, scan often, and cover all stages of your SDLC, not just production. 

Build a Smart Container Security Workflow 

Container security can’t wait for the end of the pipeline, it needs to be built in across the entire SDLC. Start by scanning base images before you even write code, so you don’t embed insecure dependencies from day one. Then scan again before production, after the image is fully built, because that’s the real artifact that will run. And even post-deployment, security matters. Misconfigured containers or missing runtime controls can still expose you to risk. Scan your infrastructure and container configs for drift, secrets, and misconfigurations. 

A good rule of thumb is to treat container security as a continuous process, not a point-in-time event: 

• During every build: Scan images before deployment to catch misconfigs & known CVEs early 

• Nightly/Weekly: Rescan registry images for newly disclosed CVEs to detect vulnerabilities introduced after deployment 

• Quarterly: Perform full Docker security assessments or Kubernetes security audits including access control, policy enforcement, and network segmentation 

• After major changes: Trigger a fresh audit when deploying new services, infrastructure updates, or base image changes 

Dig Deeper into Container Security with Our Full Webinar 

In our expert-led webinar, we take you beyond the surface to break down these misconceptions with practical advice, real-world examples, and into how open-source tools like Checkmarx KICS and 2MS help teams keep containers secure.  

Watch the full webinar to dive deeper.