Blog Articles by Checkmarx Team

The Vibe Coding Hangover

Checkmarx Team — Thu, 14 May 2026 06:58:22 +0000

Developers are moving faster than ever, with pull requests piling up and features that once took weeks now shipping in days. AI coding tools are working exactly as advertised, and the business impact shows up clearly in the numbers.

The problem is that as development speed increases, so does risk. AI doesn’t just write features; it writes vulnerabilities just as easily.

This is the AI coding paradox. The same technology accelerating development is also accelerating exposure, because code coming out faster doesn’t mean it’s coming out cleaner. Even advanced AI models introduce security vulnerabilities while generating functionally correct code – and it’s because code that works and code that’s secure are not the same thing. At the scale and speed that AI operates today, the gap between “works” and “secure” is growing faster than any security team can manually manage.

Eventually, the hangover sets in: the vulnerability backlog grows, rework starts slowing teams down, and security debt accumulates under all that increased productivity. According to Checkmarx’s Future of Application Security report, 81% of organizations knowingly ship vulnerable code, driven by overwhelming noise, uncontextualized backlogs, and limited resources. AI alone didn’t create that behavior, it just dramatically accelerated the consequences.

Gartner highlight this trend in their latest report¹, noting that as AI-generated code enters the codebase “without governance of its presence, the risks of security incidents and breaches from software products are exponentially increasing.”

But slowing down AI adoption isn’t a practical option at this point; it’s too deeply entrenched in development workflows to slow down, and business expectations have already shifted to match.

AppSec Infrastructure Is Broken

The only path forward is ensuring security infrastructure evolves at the same pace as development. The latest Gartner research maps exactly where organizations are falling short, identifies three specific gaps driving the problem:

The first is accountability. Gartner posits that “agentic coding tools are inherently incapable of taking accountability; you and your engineers are.” Without clear governance structures, responsibility diffuses and nothing gets caught until it’s complex and expensive to fix. Gartner recommends that organizations designate AI software leads: individuals explicitly accountable for the security and quality of AI-generated code, so there’s always someone looking for vulnerabilities.

The second is policy. Most teams have no formal allow and deny lists for AI coding tools, no structured training on data privacy risks, and no centralized visibility into what’s being produced. Gartner’s position it that internal governance for AI tool use needs to be built into strategic goals, performance reviews, and the secure software development methodology – not treated as an afterthought.

The third is automation. Running a single security scan at the end of a sprint isn’t enough when AI is generating code continuously throughout it. Gartner calls for a layered approach, combining tools that catch different vulnerability types across different stages of the pipeline, noting that organizations need to “layer multiple tools to provide defense-in-depth to security review AI-generated code at scale and with greater efficiency.” The goal is coverage that’s as continuous as the code being produced.

None of these gaps can be closed independently, and that’s what makes them difficult to address. Good tooling doesn’t help much if no one is accountable for acting on what it finds. Strong policy doesn’t do much if there’s no automation to actually enforce it. All three need to be in place for any of them to work properly.

How Checkmarx Closes All Three

Checkmarx One is designed to address these gaps directly through a single, integrated platform rather than a patchwork of point solutions.

For accountability, its ASPM layer creates a unified risk profile across code, dependencies, AI models, and runtime environments. Centralized audit logs, usage analytics, and AI output acceptance rates give teams clear visibility into what is being produced and deployed. When issues arise, there is already a complete record in place, making ownership and traceability straightforward.

For policy, Checkmarx enforces security rules consistently across the entire AI toolchain, not just the code it generates. Every model, dependency, MCP server, and AI tool is evaluated against organizational policies and tracked within a centralized AI-BOM. This gives security leaders a complete, enforceable inventory and turns governance from an abstract goal into an operational reality.

For automation, Checkmarx uses a hybrid approach that combines deterministic, rules-based engines with AI-powered contextual reasoning – because neither works as well alone. The deterministic layer reliably identifies known vulnerability patterns, while AI-driven analysis detects the novel issues introduced by agentic coding tools. Together, they reduce noise and deliver higher-confidence findings, allowing teams to focus on real risk instead of spending time validating false positives.

Addressing these gaps is not just about better tooling; it’s about keeping security aligned with the speed of modern development. That is where agentic AppSec comes in. Instead of relying on scans at the end of a sprint, Checkmarx Assist agents operate directly within the development workflow. Developer Assist flags vulnerabilities in the IDE before code is committed, Triage Assist prioritizes what truly represents risk, and Remediation Assist provides ready-to-merge fixes within pull requests.

This creates a continuous loop where risks are identified, understood, and resolved as code is written, rather than after the fact. Gartner calls autoremediation “a stand-out use case for AI in application security programs,” and this is exactly the role Checkmarx’s agentic agents are built to fulfill, with human oversight remaining firmly in control.

What Happens When You Don’t Act

he cost of ignoring these gaps shows up quickly. Checkmarx research shows that up to 45% of AI-generated code may be insecure, and large language models produce inconsistent results across tools and environments, meaning the problem is not isolated to a single model or team. Without accountability structures, policy enforcement, and automated scanning in place, there is no reliable way to catch what AI is quietly introducing into the codebase.

In practice, the way this debt accumulates follows a familiar pattern. Code ships quickly, tests pass, and everything appears fine until a security scan weeks later flags a vulnerability buried in an AI-generated dependency chain. By then the developer has moved on, the original context is gone, and what could have been a quick fix in the IDE turns into hours of rework, reproduction, and validation. When this plays out across hundreds of developers and projects simultaneously, security debt stops looking like a backlog and starts becoming structural drag on the entire organization.

The progression is predictable: fixes caught early are inexpensive, fixes after commit are costly, and fixes after a breach are far more severe. The three gaps Gartner identifies aren’t just operational inconveniences; they are the conditions that make the expensive version of this problem inevitable. Closing them is what keeps the cost manageable.

Hangovers Don’t Fix Themselves

Gartner’s argument is not that teams should slow down AI adoption. It is that security infrastructure must keep pace with development, and most organizations have not caught up.

The vibe coding hangover is real, and it gets worse the longer it goes untreated. Every week of unscanned AI-generated code is another week of debt accumulating quietly underneath the productivity gains.

Checkmarx One is built for this reality, closing the accountability, policy, and automation gaps directly inside the developer workflow so security scales with development instead of falling behind it. The hangover remedy isn’t slowing down; it’s building the infrastructure that makes the speed sustainable.

Access Gartner’s Best Practices to Mitigate Security Risks With Agentic Coding Tools report here and learn more about Checkmarx’s agentic application security here.

¹Gartner, Best Practices to Mitigate Security Risks With Agentic Coding Tools, Aaron Lord, Manjunath Bhat, 24 March 2026

GARTNER is a trademark of Gartner, Inc. and/or its affiliates.

Something’s Wrong With Your Code. And Attackers Know It.

Checkmarx Team — Thu, 14 May 2026 06:57:37 +0000

Picture this: you ask an AI to write a novel and it can deliver it in under an hour. And that’s really impressive – until you read it closely. The plot drifts, key details contradict each other, some ideas vanish halfway through, while others appear out of nowhere.

Now imagine handing that novel to a meticulous editor whose only job is to find every flaw. You’re in trouble.

That’s the analogy Checkmarx CEO Sandeep Johri used in his recent conversation with the New York Stock Exchange (NYSE), and it captures what’s happening to modern codebases. AI is accelerating software creation at a staggering pace, but it’s also introducing inconsistencies, blind spots, and unintended behavior just as quickly. And unlike a novel, your code doesn’t get a friendly editor; it gets attackers actively searching for those gaps.

According to Johri, the volume of AI-generated code is growing faster than the security programs designed to protect it. The result is that developers are no longer just building software, they’re also responsible for securing a much larger and more complex codebase.

And the stakes are rising.

With systems like Anthropic’s Claude Mythos reportedly capable of autonomously discovering and exploiting vulnerabilities at unprecedented speed and scale, the imbalance is only getting worse.

The question isn’t whether your code has gaps; it’s whether your security can keep up with how fast they’re being created and how quickly someone else can find them.

More Code, More Risk

Johri’s core point is straightforward: AI coding agents are producing more code – and more vulnerabilities. In fact, AI-generated code can contain two to three times the density of vulnerabilities compared to code written solely by humans, and the overall volume is growing fast.

Before AI, developers had a deep understanding of the code they wrote. Now, a single prompt can generate hundreds of lines instantly. The code works, but the context behind it – the decisions, trade-offs, and potential risks – is often missing.

Open source adds another layer. Roughly 70% of a typical enterprise application is made up of open-source components. Developers rely on it to move quickly, trusting that the code has been properly maintained and secured upstream. Sometimes that trust is well placed, but other times vulnerabilities or malicious code slip through.

The result is a growing backlog of risk. According to Checkmarx’s Future of Application Security report, 81% of organizations knowingly ship software with vulnerabilities they’ve already identified. These aren’t unknown threats or zero-days, they’re known issues that get deprioritized in favor of speed.

Developers Are in the Crosshairs

Developers are at the center of this problem because that’s where code begins. But most developers aren’t security experts – and they shouldn’t have to be. Their job and discipline is to build the functionality the business needs, and to build it fast. Security has historically been a separate discipline, applied after the fact, by a completely different team. But in the age of AI, later is really just too late.

What’s changed is the level of exposure. Because now developers aren’t just introducing risk, they’re being directly targeted. Attackers go after their package registries, plant malicious open-source dependencies, and compromise their credentials to gain access to codebases. The developer’s entire workflow – the IDE, the coding assistant, the dependencies – has become the attack surface.

Anthropic’s Claude Mythos makes this shift even harder to ignore. When Mythos found a 27-year-old bug in OpenBSD and catalogued vulnerabilities across major open-source dependencies, it wasn’t finding anything new. Those vulnerabilities were already there, sitting in production systems that developers had built on top of for years. What Mythos demonstrated is that finding and exploiting them is now fast, automatic, and cheap – roughly $1 per exploit in 10 to 15 minutes with no specialized expertise required.

And these vulnerabilities that developers unknowingly ship won’t sit idle anymore. With AI, the window between disclosure and active exploitation has shrunk, from roughly 840 days in 2018 to about 1.6 days today.

AI Is Also Creating New Threats

AI development isn’t just introducing more vulnerabilities, but it’s also introducing entirely new kinds of risk.

Coding assistants can hallucinate package names that don’t exist, and attackers are already registering those names to turn a simple mistake into a malicious dependency. Applications that pass user input into LLMs are now exposed to prompt injection, an entirely new attack vector with no real equivalent in traditional software. And as development becomes more agent-driven, with AI systems taking actions through MCP servers, the attack surface is expanding beyond what conventional security tools were designed to handle.

Some coding tools are starting to layer in security features, but as Johri points out, they don’t do it as exhaustively or with the full enterprise context of purpose-built AppSec platforms – and that includes Claude Code Security.

As AI-driven development accelerates, closing this gap will require security tools built specifically for how software is being created today, not how it was built before in the pre-AI era.

Security Has To Become Agentic Too

Johri’s conclusion is simple: application security needs to become agentic. The human-in-the-loop model that’s worked until now can’t keep pace with the velocity of AI-generated code. Agents generating code need security tools that can be called automatically, integrated into the pipeline, and capable of acting on what they find rather than just flagging it for someone to review later.

That urgency is reinforced by developments like Anthropic’s Project Glasswing, a coalition of 40+ technology organizations built around using Mythos defensively. It’s a clear signal that the industry sees what’s coming – but a coalition isn’t the same thing as a security program.

What’s really needed in this new age is a hybrid approach that combines AI’s speed and scale with deterministic analysis that doesn’t hallucinate. On its own, AI scanning produces findings that erode trust: it will flag an exception already caught upstream, describing a race condition in single-threaded code. Without a rules-based SAST, SCA, and IaC layer to validate what the AI finds, you’re just generating noise at scale.

And timing is just as important. Security has to begin at the moment code is created, while context still exists. In AI-driven development, even a short delay means that context is gone. And when vulnerabilities are found later, developers have to revisit code they’ve already moved past and no longer have the context for – and that retrace slows everything down and increases the chance risk will slip through.

Keeping Up With the Code

The takeaway here is that AI is accelerating how code is written, but security isn’t keeping up. More code, less context, and faster exploitation are all converging at once – and with the recent Mythos announcement, that gap is widening.

The good news is that slowing down development isn’t the answer. The path forward is bringing security into the same flow as development for a more seamless experience: integrated, automated, and able to keep pace with how code is created.

That’s where agentic application security comes in. It needs to move beyond detection to help developers understand, prioritize, and remediate issues in real time, without adding friction or noise.

Watch the full interview here, or learn more about how Checkmarx One is tackling this with Developer Assist, Triage Assist, and Remediation Assist.

Update: Ongoing Checkmarx Supply Chain Security Incident

Checkmarx Team — Sat, 09 May 2026 17:53:39 +0000

Supply Chain Security Incident Summary
Updated May 22, 2026

The following is designed to provide an incident summary and central location for updates that have previously been provided.

Situation Overview

Checkmarx experienced a cybersecurity supply chain incident affecting certain developer artifacts distributed through third-party channels.

Beginning on March 23, 2026, attackers gained unauthorized access to Checkmarx’s GitHub repositories, likely through a third-party supply chain attack that affected the broader cybersecurity community. This access enabled the publication of malicious code to a number of externally distributed artifacts, including VS Code extensions, GitHub Actions workflows, and a Jenkins plugin. In addition, a cybercriminal group published data to the dark web that our investigation indicates originated from Checkmarx’s GitHub repositories.

Our investigation, conducted with the support of external forensic specialists including Mandiant, is in its final stages.

Timeline

Following is a timeline of events and updates.

Date	Title	Description	Update
9-May-2026	Jenkins Plugin Compromise	External service account modified Jenkins AST plugin and published to Jenkins Marketplace	Incident Update: Friday, May 22, 2026 Incident Update: Saturday, May 9, 2026
25-Apr-2026	Dark Web Leak	Data exfiltrated from Checkmarx GitHub repos March 30 using compromised credentials from March wave; cyber-criminals published to dark web April 25	Incident Update: Monday, April 27, 2026 Incident Update: Sunday, April 26, 2026
22-Apr-2026	Second Wave Artifacts	Cached credentials enable publication of malicious KICS Docker image, updated VSCode & DevAssist extensions, and GitHub Action	Incident Update: Wednesday, April 22, 2026
23-Mar-2026	Supply Chain Entry	Team PCP compromises Trivy; stolen credentials used to publish malicious GitHub Actions & VSCode extensions to OpenVSX	Incident Update: Monday, March 23, 2026

Actions Taken

Since the first day of the incident, Checkmarx has been conducting active investigation, and remediation efforts. Key actions taken to date include:

Removed malicious artifacts and published clean, verified replacements across all affected channels
Rotated and revoked exposed credentials, with validation and follow-up rotation continuing as the investigation progresses
Blocked outbound access to attacker-controlled infrastructure
Implementing additional security controls, tools, and access restrictions within our development environment
Locked down access to affected GitHub repositories while the investigation continues
Engaged law enforcement and notified relevant authorities
Retained Mandiant, an elite incident response and digital forensics firm, to bolster our investigation
Conducting a code audit to verify no further malicious code is present beyond findings already identified
Reviewing our environments for any indications of further compromise

We are now in the final stages of our investigation. We will provide further updates as our investigation progresses.

Incident Updates

Over the past week and while our investigation is continuing, we held a series of conversations and calls with our customers so they could hear directly from us about the progress we are making in our response to the supply chain incident. We hope that these sessions were helpful in better understanding what has happened and what actions Checkmarx is taking in response.

We are sharing below the FAQs from these conversations. If you have further questions, please continue to direct these to your Checkmarx account team.

Frequently Asked Questions

What is the status of the investigation?

While we are continuing to investigate, we want to reiterate two key points from our investigation so far:

The incident occurred within our GitHub environment. To date, our investigation has not identified impact beyond the Checkmarx GitHub environment and a limited number of infected workstations. As an added precautionary measure in the meantime, we proactively disconnected our release pipeline from production during the initial stages of our response.
The malicious artifacts did not override previously published, known safe versions. Customers using versions or SHAs published prior to the affected timeframes (see below) are not affected by the artifact compromises themselves. A full list of affected artifacts, malicious tags and SHAs, is available in the updates here below and in the Customer Support Portal.

We have retained Mandiant, an elite incident response, digital forensics, and threat intelligence firm to confirm and further support our investigation, security hardening, and threat hunting efforts and to ensure no residual access remains. We will provide further updates as our investigation progresses.

What measures are being taken to prevent this from happening again?

We are undertaking, in partnership with Mandiant, a thorough investigation and implementing a robust set of containment measures and forward-looking controls to protect Checkmarx and our customers. To date, we have revoked all publishing permissions, revoked all classic GitHub personal access tokens, moved to OIDC authentication across the SDLC, and deployed additional monitoring and forensic tooling.

We are continuing to work alongside Mandiant to conduct a structured verification phase to confirm the scope of the incident and that no residual access paths remain.

What steps should customers take to protect themselves?

We recommend that our customers follow these best practices:

Pin to specific SHAs rather than mutable tags (latest, debian, alpine)
Disable auto-update on IDE extensions
Scan images at pull time and validate signatures
Restrict egress from CI runners to an allowlist; monitor outbound connections for unexpected domains
Treat CI runner credentials as short-lived and tightly scoped.

In addition, a full list of recommended actions for our customers can be found in the incident updates below.

Was the May 9 Jenkins AST plugin activity part of the original incident?

Our assessment based on currently available evidence is that the threat actor was able to leverage access, obtained as part of the March incident, to later publish the modified version of the Jenkins plugin on May 9. This plugin has now been removed and clean replacement versions have been published (2.0.13-848.v76e89de8a_053 and 2.0.13-847.v08c0072b_2fd5).

The malicious payload associated with the modified plug-in targets lists of file paths for common applications, each tailored to a specific operating system (WIN, LINUX, OSX). After determining the OS, it traverses the corresponding file list looking for credentials. Targeted applications include crypto wallets, VPNs, AWS, and Github. We are still conducting malware analysis to understand the specific paths, but to date we have not seen any references to Jenkins.

If you use the Jenkins AST plugin, we recommend the following actions:

Ensure you are on one of those versions or on 2.0.13-829.vc72453fa_1c16 from December 17, 2025 or earlier. The malicious window was 2026-05-09 01:25 UTC to 2026-05-10 08:47 UTC. We recommend rotating all credentials that the pipeline that executed the malicious payload has access to.
Hunt across your environment using the indicators below.

File Characteristics

File Name	File Type	Size (bytes)	MD5	SHA256
cli.js	TXT	488,465	9f9f83795fc162b7e44bc6859fc80535	08352b4c37808a25895cda1cae27ec8a83cf7ee9de15e2d4dd9560a2906730f4

Network-based Indicators

Connections

hxxps[:]//api[.]github[.]com:443/user
hxxps[:]//registry[.]npmjs[.]org:443/-/whoami

HTTP Headers

User-Agent: node
Accept: application/vnd.github+json

Has any customer data been affected as part of this incident?

Based on currently available evidence, we believe that the data the threat actor published to the dark web originated from Checkmarx’s GitHub repository. As standard practice, we do not store customer data in our GitHub repository. The investigation into the nature and scope of any impacted data remains ongoing. We will notify customers individually if any personal or sensitive data relating to them was affected.

Will you share a written incident summary with customers?

We will share a post-incident summary covering findings, remediation, and forward-looking controls with customers upon request.

We are aware that a modified version of the Checkmarx Jenkins AST plugin was published to the Jenkins Marketplace. We are in the process of publishing a new version of this plug-in.

If you are using Checkmarx Jenkins AST Plugin, you need to ensure that you are using the version 2.0.13-829.vc72453fa_1c16 that was published on Dec. 17, 2025 or previously.

We will continue to share updates as we have them available.

Checkmarx Jenkins AST Plugin IOCs (malicious artifacts)

Marketplace	Checkmarx AST Scanner (plugins.jenkins.io)
Version	2026.5.09
File	checkmarx-ast-scanner-2026.5.09.hpi
SHA256	01ff1e56fd59a8fa525d97e670f7f297a1a204331b89b2cd4e36a9abc6419203
File	checkmarx-ast-scanner-2026.5.09.jar
SHA256	f50a96d26a5b0beb29de4127e82b2bf350c21511e5a43d286e43f798dc6cd53f
File	checkmarx-ast-scanner-2026.5.09.pom
SHA256	3ddb8967919a801b3c383e58cddceab21138134c6a26560d99e2672e86f36f2a
Window	2026-05-09 01:25:00 UTC to 2026-05-10 08:47:00 UTC

Latest SHAs:

2.0.13-848.v76e89de8a_053
Released: May 9, 2026
SHA-1: 65e4fbfbfb66dfd4a6e2e521e879cfa1b5745282
SHA-256: db7e0a5eb292810fb9d68224596dd3fa887d094f37021073fb5b5b2a232bcd23
Requires Jenkins 2.452.4

2.0.13-847.v08c0072b_2fd5
Released: May 9, 2026
SHA-1: f430ce10bf8bb66ab133a257ab4063b8055d23de
SHA-256: 894c1a245f30ffe168f4dfda48f36ba5c1bc9da7d0f093a8095d8aed92d0fcd8
Requires Jenkins 2.452.4

What happened?

On March 23, 2026, Checkmarx identified a cybersecurity incident originating from the Trivy Supply Chain Attack. The cybersecurity community previously reported on March 19 that the TeamPCP attack affecting the Trivy scanner could potentially be used to harvest credentials from downstream users.

While we are still investigating the incident, we believe this is the likely vector that enabled the attackers to obtain credentials and to gain unauthorized access to our GitHub repositories. As a result of that access, the attackers were able to interact with Checkmarx’s GitHub environment and subsequently publish malicious code to certain artifacts.

As part of our investigation into the incident, we identified that exfiltration of data took place on March 30, 2026. A cybercriminal group subsequently published data related to Checkmarx to the dark web on April 25. Current evidence indicates that this data originated from Checkmarx’s GitHub repositories, and that access to those repositories was facilitated through the initial supply chain attack of March 23, 2026.

Importantly, Checkmarx’s GitHub repositories are maintained separately from our customer production environment. As standard practice, we do not store customer data in our GitHub repository.

Incident Timeline

— MARCH —
	Mar 23	EVENT	Compromised artifacts published Malicious Checkmarx artifacts are published. Attacker pushes malicious code directly into the Checkmarx GitHub repository. Containment, investigation, remediation and communication efforts commenced immediately, and remain ongoing.
— APRIL —
	Apr 22	PERSISTENCE	Compromised artifacts published A second wave of malicious Checkmarx artifacts are published, indicating continued or renewed attacker access.
	Apr 25	DISCLOSURE	LAPSUS$ publishes stolen data LAPSUS$ publicly releases data stamped March 30, nearly one month after the suspected exfiltration of data from the Checkmarx GitHub repository by the attacker.

Breach / Exfiltration
Persistence
Disclosure

Actions we have taken

Upon identification of the incident, Checkmarx commenced a formal investigation and engaged external forensic specialists to support that work.

Initial steps Checkmarx took to contain and remediate the incident included:

Removed unauthorized code and published clean artifacts
Implemented additional safeguards within our development and distribution workflows
Rotated credentials identified as potentially exposed, with validation and follow-up rotation continuing as the investigation progressed
Reviewed our environments for indications of further compromise

Following evidence of further malicious artifacts we took additional steps to strengthen our security posture:

Engaged law enforcement to make them aware of the incident
Retained Mandiant, an elite incident response, digital forensics, and threat intelligence firm to bolster our investigation efforts
Conducted a wider rotation of credentials across the environment
Implemented additional security controls, tools, and access restrictions within our development environment
Performed additional reviews of access pathways and integrations
We have locked down access to the affected GitHub repositories while the investigation continues
A code audit is also currently underway to verify that no further malicious code is present beyond the findings already identified

We are now in the final stages of our investigation and confirming that the unauthorised access has been fully contained. We will share further on this as soon as we are able.

Additional Information

We have communicated with our customers throughout this process and will continue to provide relevant updates as more information becomes available. Further information, including recommended steps customers can take, is available on our Support Portal or in our Security Updates.

New Development: GitHub Repository

We are writing to inform you of a new development in the ongoing Checkmarx supply chain security incident.

Our investigation, conducted with support from a leading third-party forensic firm, indicates that a cybercriminal group has published data related to Checkmarx to the dark web. Based on current evidence, we believe this data originated from Checkmarx’s GitHub repository, and that access to that repository was facilitated through the initial supply chain attack of March 23, 2026.

Checkmarx’s GitHub repository is maintained separately from our customer production environment. As standard practice, we do not store customer data in our GitHub repository. Our forensic investigation is ongoing and we are actively working to verify the nature and scope of the posted data.

As part of our immediate response, we have locked down access to the affected GitHub repository while the investigation continues.

If we determine that customer information was involved in this incident, we will notify customers and all relevant parties immediately.

We expect to share a more detailed update within 24 hours.

Questions and Support

If you have questions about this incident or need assistance assessing your environment, please open a case via the Support Portal.

What Happened

On April 22, we communicated with customers about a new development in the supply chain security incident that our team is actively investigating and addressing. We deeply value the trust you place in Checkmarx and are committed to keeping our customers informed as we continue to respond.

As part of our immediate response, we retained outside experts and are working around the clock to get to the bottom of this as quickly as possible. In the interim, we are sharing key findings to-date and recommended actions for our customers to take.

Key Findings

Notably, our investigation thus far indicates that the malicious artifacts did not override previously published, known safe versions. Customers using versions or SHAs published prior to the affected timeframes are not affected.

Affected Artifacts

The following artifacts have been identified as potentially affected:

Checkmarx public DockerHub KICS image — https://hub.docker.com/r/checkmarx/kics
1. Malicious tags: v2.1.20-debian, v2.1.21-debian, debian, v2.1.21, v2.1.20, alpine, v2.1.20, v2.1.21, latest
2. Malicious SHAs: sha256:222e6bfed0f3b, sha256:9183908decd0f, sha256:a6871deb0480e, sha256:ff7b0f114f87c, sha256:1b01a97753780, sha256:2588a44890263, sha256:54f8a56bf1f71, sha256:d186161ae8e33, sha256:415610a42c5b5, sha256:e35bc6afc4857, sha256:a0d9366f6f016, sha256:903eef3c05f6e, sha256:26e8e9c5e53c9, sha256:7391b531a07fc, sha256:4c963fa00e585
3. Timeframe: from 2026-04-22 12:31:35.883 UTC to 2026-04-22 12:59:46.562 UTC
Checkmarx public ast-github-action — https://github.com/checkmarx/ast-github-action
1. Malicious tags: 2.3.35
2. Timeframe: from 2026-04-22 14:17:59 UTC to 2026-04-22 15:41:31 UTC
Checkmarx VS Code extension
1. Microsoft marketplace: https://marketplace.visualstudio.com/items?itemName=checkmarx.ast-results
2. Open VSX marketplace: https://open-vsx.org/extension/checkmarx/ast-results
3. Malicious tags: 2.63, 2.66
4. Timeframe — Microsoft marketplace: From 2026-04-22 13:06:00 UTC to 2026-04-22 17:48:00 UTC
  Timeframe — Open-VSX marketplace: From 2026-04-22 13:06:00 UTC to 2026-04-22 21:20:00 UTC
Checkmarx Developer Assist extension
1. Microsoft marketplace: https://marketplace.visualstudio.com/items?itemName=checkmarx.cx-dev-assist
2. Open VSX marketplace: https://open-vsx.org/extension/checkmarx/cx-dev-assist
3. Malicious tags: 1.17, 1.19
4. Timeframe — Microsoft marketplace: From 2026-04-22 13:06:00 UTC to 2026-04-22 17:48:00 UTC
  Timeframe — Open-VSX marketplace: From 2026-04-22 13:06:00 UTC to 2026-04-22 21:20:00 UTC

Actions We’ve Taken

To date, in response to this development we have:

Removed the malicious artifacts;
Revoked and rotated exposed credentials;
Blocked outbound access to attacker-controlled infrastructure;
Reviewed our environments for any signs of further compromise.
Initiated a forensic investigation with the assistance of an independent, third-party forensic firm.

Recommended Actions

We recommend that our customers take the following steps as soon as possible:

Block access to these domains and IP addresses:
1. checkmarx.cx => 91[.]195[.]240[.]123
2. audit.checkmarx.cx => 94[.]154[.]172[.]43
Use pinned SHAs and review or disable auto-update settings in IDE marketplaces
Rotate secrets and credentials if a compromise is suspected or detected
1. DockerHub KICS image: latest, v2.1.20, alpine, Debian
2. Checkmarx ast-github-action: v2.3.36
3. Checkmarx VS Code extensions: v2.67.0
4. Checkmarx Developer Assist extension: v1.18.0

Guidance for CxSAST On-Premise Customers

We have received questions from customers running CxSAST on-premise about whether their environments are within the scope of this incident. This communication outlines what is, and is not, in scope for your specific environment (Cx SAST on-premises and CxSAST hosted), and the limited circumstance under which you may need to take action.

Scope Summary

Based on our investigation to date, the artifacts confirmed as compromised in this incident are externally distributed components associated with Checkmarx One. They are not part of, and are not delivered with, a CxSAST on-premise installation. Specifically:

CxSAST on-premise itself was not compromised. The incident affected externally distributed artifacts, not the CxSAST product or its installer.
Checkmarx One (SaaS) infrastructure has not been identified as compromised. We mention this for completeness, as customer questions often span both deployment models.
The compromised GitHub Actions (checkmarx/ast-github-action and checkmarx/kics-github-action) are used to invoke Checkmarx One scans from CI/CD pipelines. They are not used by CxSAST on-premise customers in that role.
The compromised VS Code extensions (checkmarx.ast-results and checkmarx.cx-dev-assist) are the Checkmarx One IDE integrations. The CxSAST on-premise IDE plugin is a separate component and was not affected.

Although CxSAST on-premise is out of scope for the compromised artifacts, an incident of this nature warrants standard security vigilance regardless of deployment model. Below we outline the specific conditions that would require a CxSAST on-premise customer to take action as a result of this incident.

Action Required If Applicable

If your organization independently uses the open-source KICS scanner — specifically by pulling the public KICS image from Docker Hub (hub.docker.com/r/checkmarx/kics) outside of any CxSAST or Checkmarx One workflow — we recommend further action if the image was pulled during the affected time window. This image is distinct from the CxSAST product and from the IaC scanning capability built into Checkmarx One.

The compromised KICS image was present on Docker Hub during the following window:

From 2026-04-22 12:31:35 UTC to 2026-04-22 12:59:46 UTC.

If you did not pull from Docker Hub during this window, you do not need to take further action. If you did, or are uncertain, please verify the image SHA against the list of malicious SHAs in our public advisory and treat any match as a potential compromise of the host that pulled the image and take further action as appropriate.

Precautionary Actions for All Customers

For most CxSAST on-premise customers, no product-level remediation is required. As precautionary measures aligned with the broader incident, we recommend:

Block outbound access at the network perimeter to: checkmarx.cx (91.195.240.123), audit.checkmarx.cx (94.154.172.43), updates.checkmarx.cx (94.154.172.183), and checkmarx.zone (associated with the March 23 round).
If your developers use VS Code, confirm that any installed Checkmarx extensions are sourced from the official Microsoft VS Code Marketplace and are current safe versions (ast-results v2.67.0 and Developer Assist v1.18.0 or v1.20.0). Consider temporarily disabling auto-update on these extensions until the investigation is closed.
Review CI/CD logs and developer workstation telemetry for outbound connections to any of the domains and IPs above during the affected windows.

Where to Go for Help

For environment-specific questions, please open a Support case via the Support Portal at support.checkmarx.com.

We will continue to update this page as our investigation progresses.

Next Steps

This is an ongoing investigation. Please continue to monitor the Checkmarx Community Incident Page for more information.

If you have questions about this development, please open a case via the Support Portal.

We are grateful for your continued support and patience as we work to address this incident.

On March 23, 2026, Checkmarx identified a cybersecurity supply chain incident affecting certain Checkmarx-related developer artifacts distributed via third-party channels.

This post contains a structured overview of the incident and the steps we have taken to date, as well as additional resources to support our clients and team members.

What Happened

On March 23, 2026, Checkmarx was the target of a cybersecurity supply chain incident which affected two specific plugins distributed via the OpenVSX marketplace and two of our GitHub Actions workflows.

OpenVSX Plugins

On March 23, 2026, at approximately 02:53 UTC, malicious versions of two plugins were published to the OpenVSX registry.

Only organizations that downloaded the following artifacts from OpenVSX on 23 March, 2026 between 02:53 UTC and 15:41 UTC and ran it are potentially impacted by this incident.

ast-results-2.53.0.vsix
cx-dev-assist-1.7.0.vsix

The affected plug-ins are no longer available and all older GitHub versions have been permanently removed.

Plugins downloaded from the VS Code Marketplace were not affected.

Recommended actions

The following guidance is provided as a precautionary measure to support customer-led assessments and remediation, where relevant to their environments.

If a client downloaded and ran either of the above extensions from the Open VSX registry, their organization may be affected.

If the client organization may have been affected, we strongly recommend taking the following steps as soon as possible.

1. Remove Malicious Components

Uninstall the following VSIX extensions from all environments:
- checkmarx.ast-results-2.53.0.vsix
- checkmarx.cx-dev-assist-1.7.0.vsix
use ast-github-action – v2.3.33 only
use kics-github-action – v2.1.20 only
Ensure they are removed from:
- All developer machines
- All VSCode profiles and environments

2. Revoke and Rotate Credentials

GitHub Actions

An issue was also identified in KICS and AST GitHub Action on March 23, 2026. The attacker injected malicious payloads into the following GitHub Actions workflows which were available between 12:58 and 16:50 UTC:

checkmarx/ast-github-action
checkmarx/kics-github-action

Maintainers revoked the affected tags, securing access, and preventing unauthorized changes.

All GitHub Actions have been updated to the following latest verified releases, and all older versions have been permanently deleted from the organization’s repositories:

ast-github-action — v2.3.33 (released March 23, 2026)
kics-github-action — v2.1.20 (released March 23, 2026)

Both versions are the only ones available in our repos. All pipelines must reference these versions exclusively or newer.

Recommended actions

If you downloaded the malicious versions of either plugin (ast-results-2.53.0.vsix or cx-dev-assist-1.7.0.vsix) from OpenVSX during the affected period, we strongly recommend following these precautionary steps:

Revoke and rotate all secrets and credentials accessible to CI runners during the affected period, including GitHub Personal Access Tokens (PATs), cloud service credentials, and repository or organization-level secrets.
Review GitHub Actions runs, search for suspicious indicators such as references to tpcp.tar.gz, aquasecurity, or checkmarx.zone, and check for unexpected repositories like tpcp-docs. In case you spot any occurrences of these, please remove them or contact the Checkmarx Support for guidance.
Revoke access to the following tokens, and issue new ones:
- GitHub credentials
- Microsoft Azure access
- Google Cloud (GCP) access
- AWS access
- Kubernetes service account tokens and kubeconfigs
- SSH keys
- Docker registry credentials
Block Malicious Infrastructure by restricting access to checkmarx[.]zone and review historical network traffic for any communication with this domain
Review logs and systems for GitHub activity such as unexpected API usage, suspicious repositories or artifacts such as docs-tpcp and/or tpcp.tar.gz, unauthorized releases or CI-triggered changes
For any revoked token, key or credentials from previous stages:
- Review related activity within exposure time frame, to validate no lateral movement took place
- Monitor for any future attempts to use these credentials to identify ongoing attempts to attack infrastructure

Containment & Remediation

Upon identification of the issue, we took immediate steps to contain and remediate the incident. We removed the unauthorized code, pinned our workflows to safe verified commit SHAs, revoked and rotated relevant credentials, blocked outbound access to the attacker-controlled domain, and reviewed our environments for any signs of further compromise.

Investigation Status

We have commenced a formal investigation and engaged external forensic specialists to support that work. This investigation is ongoing and includes investigating the behaviour and objectives of the malicious code.

Available information indicates that the primary functionality of the code was focused on the attempted collection and exfiltration of credentials and secrets from affected environments, without evidence to date that such data was successfully exfiltrated from any customer environment.

Based on the investigation to date, and subject to the evidential limitations described below, we recommend continued vigilance and that you notify us promptly if you become aware of any suspicious activity.

While the investigation is ongoing, to date, we do not have evidence indicating that the incident resulted in unauthorised access to customer data or systems, that data held by Checkmarx has been accessed, nor can we yet confirm that any particular customer environment was compromised.

It is important to note that because the affected artefacts execute within customer-controlled environments, confirmation of whether a particular customer was impacted depends on an assessment of those environments, rather than on telemetry held by Checkmarx. Those CI/CD pipelines and developer workstations are customer-controlled environments, and Checkmarx does not have independent visibility into their execution or logs.

Our Commitment to You

Protecting the security and privacy of our clients and team members is a responsibility we hold to the highest standard. The investigation into the nature and scope of any impacted data remains ongoing. We will notify customers individually if any personal or sensitive data relating to them was affected.

If you have questions or need assistance assessing your environment, please reach out to our security team at infosec@checkmarx.com or open a case via the Support Portal. Detailed assessment and remediation guidance, including indicators of compromise and recommended next steps, is also available on the Support Portal.

Frequently Asked Questions

While we are continuing to investigate, we want to reiterate two key points from our investigation so far:

The incident occurred within our GitHub environment. To date, our investigation has not identified impact beyond the Checkmarx GitHub environment and a limited number of infected workstations. As an added precautionary measure in the meantime, we proactively disconnected our release pipeline from production during the initial stages of our response.
The malicious artifacts did not override previously published, known safe versions. Customers using versions or SHAs published prior to the affected timeframes (see below) are not affected by the artifact compromises themselves. A full list of affected artifacts, malicious tags and SHAs, is available in the updates here below and in the Customer Support Portal.

We are continuing to work alongside Mandiant to conduct a structured verification phase to confirm the scope of the incident and that no residual access paths remain.

We recommend that our customers follow these best practices:

Pin to specific SHAs rather than mutable tags (latest, debian, alpine)
Disable auto-update on IDE extensions
Scan images at pull time and validate signatures
Restrict egress from CI runners to an allowlist; monitor outbound connections for unexpected domains
Treat CI runner credentials as short-lived and tightly scoped.

In addition, a full list of recommended actions for our customers can be found in the incident updates above.

If you use the Jenkins AST plugin, we recommend the following actions:

Ensure you are on one of those versions or on 2.0.13-829.vc72453fa_1c16 from December 17, 2025 or earlier. The malicious window was 2026-05-09 01:25 UTC to 2026-05-10 08:47 UTC. We recommend rotating all credentials that the pipeline that executed the malicious payload has access to.
Hunt across your environment using the indicators below.

File Characteristics

File Name	File Type	Size (bytes)	MD5	SHA256
cli.js	TXT	488,465	9f9f83795fc162b7e44bc6859fc80535	08352b4c37808a25895cda1cae27ec8a83cf7ee9de15e2d4dd9560a2906730f4

Network-based Indicators

Connections:

hxxps[:]//api[.]github[.]com:443/user
hxxps[:]//registry[.]npmjs[.]org:443/-/whoami

HTTP Headers:

User-Agent: node
Accept: application/vnd.github+json

We will share a post-incident summary covering findings, remediation, and forward-looking controls with customers upon request.

Determining whether a specific environment was affected requires a structured assessment across two vectors: CI/CD pipelines and developer workstations.

Assessment — CI/CD pipelines (GitHub Actions):

Search all GitHub workflow files (.github/workflows/*.yml) for references to checkmarx/kics-github-action and checkmarx/ast-github-action.
If references are identified, determine the version or tag in use (e.g., @main, @v2.3.32, a commit SHA).
Ascertain whether any workflow runs referencing these actions occurred during the affected window in March 2026. GitHub Actions run logs are retained for a configurable period and should be reviewed for the relevant timeframe.
If runs occurred during the affected window, review runner logs for: outbound connections to checkmarx[.]zone, execution of a setup.sh script not forming part of the customer’s own workflow, or any anomalous network activity.

Assessment — Developer workstations (Open VSX plugins):

Identify all developers utilizing VS Code within the organization.
Determine whether Checkmarx extensions were installed from the Open VSX Registry (open-vsx.org) rather than the official VS Code Marketplace (marketplace.visualstudio.com).
Verify the extension version and installation or last-update timestamp. Any Checkmarx VS Code extension installed or auto-updated from the Open VSX Registry during the affected window should be treated as potentially compromised.
Inspect the workstation for the relevant plugin directories (refer to FAQ F10 for applicable paths) and review proxy or DNS logs for connections to checkmarx[.]zone.

Important note regarding Checkmarx scan-based detection:

Executing a Checkmarx SAST or SCA scan against your organization’s codebase will not detect whether your environment was compromised by this incident. The incident involves malicious code executed within a CI/CD runner or IDE environment and does not constitute a vulnerability in application code that a scan would identify. Exposure assessment must be conducted through log analysis, workstation inspection, and credential audit as described above.

See Checkmarx Security Update, 26 March 2026 (https://checkmarx.com/blog/checkmarx-security-update/)

Both checkmarx/ast-github-action and checkmarx/kics-github-action were affected by this incident, as were the two Open VSX Registry plugins referenced in Checkmarx’s security communications.

The following indicators of compromise (IOCs) have been identified through Checkmarx’s investigation and independent third-party security research. The investigation remains ongoing and additional IOCs may be published.

Malicious domain / command-and-control infrastructure:

checkmarx[.]zone — This attacker-controlled domain was intended to be used for the exfiltration of any stolen credentials and secrets. Any outbound DNS query or HTTP/HTTPS connection to this domain originating from CI/CD runners or developer workstations during the affected window should be treated as a confirmed indicator of compromise.

Malicious VSIX filenames (Open VSX):

ast-results-[version].vsix
cx-dev-assist-[version].vsix

The specific filenames checkmarx.ast-results-2.53.0.vsix and checkmarx.cx-dev-assist-1.7.0.vsix have been referenced in customer communications. Customers should evaluate any version downloaded from the Open VSX Registry during the affected window, not solely these specific version numbers.

On-disk extension directories:

The presence of Open VSX-sourced Checkmarx extension directories within VS Code’s extension folder constitutes a potential indicator. Refer to FAQ F10 for applicable file paths.

Runner artifacts (setup.sh):

The compromised GitHub Actions injected a script (setup.sh) on the CI/CD runner as part of the action’s initialization sequence. The presence of this script or associated runner artifacts constitutes a behavioral indicator of compromise. The full contents of setup.sh cannot be publicly disclosed at this time given the ongoing investigation.

File hashes (SHA256) — sourced from Wiz threat intelligence reporting:

ast-results-2.53.0.vsix: 65bd72fcddaf938cefdf55b3323ad29f649a65d4ddd6aea09afa974dfc7f105d

cx-dev-assist-1.7.0.vsix: 744c9d61b66bcd2bb5474d9afeee6c00bb7e0cd32535781da188b80eb59383e0

The malicious payload embedded in both the GitHub Actions and the Open VSX plugins was designed to exfiltrate environment variables and secrets from the execution context of the affected GitHub repository.

Credentials at risk — GitHub Actions (CI/CD):

Any secret configured within the affected GitHub repository or organization and accessible to the workflow at the time the compromised action executed is potentially at risk. This includes, but is not limited to: GITHUB_TOKEN, API keys, cloud provider credentials, database credentials, and Checkmarx API tokens.

Credentials at risk — Developer workstations (Open VSX plugin exposure):

Any credential accessible within the VS Code environment, including those stored in environment variables, configuration files, or tokens used by the IDE, should be treated as potentially at risk.

Credentials requiring rotation:

All GitHub repository secrets in any repository or organization where the compromised actions executed.
Checkmarx API keys and tokens used within the affected pipelines.
Cloud provider credentials (AWS, Azure, GCP) if present as environment variables in affected workflows.
All other API keys, tokens, or passwords configured as GitHub secrets or environment variables in the affected workflows.
On developer workstations: any tokens or secrets stored in VS Code settings, environment variables, or configuration files where the malicious Open VSX plugin was installed and active.

Checkmarx recognizes that many enterprise customers — particularly those in regulated industries or with formal vendor risk management programs — require a written root-cause analysis or incident statement from strategic suppliers following a supply chain security incident such as this.

Checkmarx is committed to providing material updates, and preparing a post-incident report. While the investigation is still ongoing — including with support from a third-party forensic firm we have engaged — we expect the report to include:

Our findings with respect to the root cause and attack vector exploited by the TeamPCP threat actor, as established by the investigation
A timeline of events from initial compromise through detection and remediation
Findings with respect to affected artifacts and the scope of customer impact, as confirmed by the investigation
The remediation actions taken by Checkmarx
Forward-looking preventive controls to enhance Checkmarx’s security posture

The Checkmarx One SaaS platform, including cloud-hosted scanning engines, the Checkmarx One web application, and associated backend services, do not appear to be affected by this incident.

This incident constitutes a supply-chain compromise targeting specific open-source distribution artifacts (GitHub Actions and Open VSX plugins). It does not represent a breach of Checkmarx’s SaaS infrastructure. It does not appear that the threat actor obtained access to Checkmarx One customer tenants, customer data, scan results, or the platform’s internal systems.

Notwithstanding the above, SaaS customers who utilize the affected GitHub Actions (checkmarx/kics-github-action or checkmarx/ast-github-action) within their own CI/CD pipelines, or whose developers installed plugins sourced from the Open VSX Registry, may be indirectly affected.

We understand the residual risk pertains to the customer’s own CI/CD runner environments and developer workstations on which the malicious code may have executed.

Recommended action for SaaS customers:

If your organization does not use checkmarx/kics-github-action or checkmarx/ast-github-action in its GitHub pipelines and developers do not use Open VSX-sourced plugins, no specific action with respect to the SaaS platform is required. If the affected GitHub Actions are in use, any runner that executed those actions during the affected window should be treated as potentially compromised, and customers should follow the remediation guidance including credential rotation, log review, and runner inspection. We recommend heightened vigilance at this time.

Affected versions and tags:

checkmarx/ast-github-action:

3.32 was compromised.
References to @main during the exposure window (March 2026) were compromised.
Any unpinned or floating reference that resolved to a compromised commit during the exposure window should be treated as affected.

checkmarx/kics-github-action:

All versions and tags active on the @main branch during the exposure window (March 2026) were compromised.
Any unpinned or floating reference that resolved during the exposure window should be treated as affected.

Open VSX plugins:

ast-results v2.53.0 was compromised.
cx-dev-assist v1.7.0 was compromised.
Any version of either plugin installed or auto-updated from the Open VSX Registry during the exposure window should be treated as compromised.

Safe versions (post-remediation):

checkmarx/ast-github-action v2.3.33 or later has been confirmed clean.
checkmarx/kics-github-action: pin to a version or commit SHA published following remediation; customers should confirm the specific safe tag with their Checkmarx account team.
Open VSX plugins: reinstall from the official VS Code Marketplace. Current Marketplace versions are confirmed clean.
@main as of the date of remediation references clean code; however, pinning to an explicit version tag or commit SHA is strongly recommended as best practice.

Exposure window:

Malicious artifacts were active during March 2026. The precise commencement date remains under investigation. Any pipeline execution or plugin installation or auto-update occurring during this period should be evaluated for potential exposure.

Yes. We have appointed external breach counsel, and a leading forensics expert to assist with our investigation. We are unable to provide an estimated timeline. At this stage, we are notifying regulators and law enforcement as we deem necessary.

=992)return;var el=document.querySelector('.cx-incident');if(!el)return;var vw=document.documentElement.clientWidth;var node=el;var safety=0;while(node&&node!==document.documentElement&&safety<25){safety++;try{node.style.setProperty('max-width',vw+'px','important');node.style.setProperty('overflow-x','hidden','important');node.style.setProperty('box-sizing','border-box','important');}catch(e){}node=node.parentElement;}document.documentElement.style.setProperty('overflow-x','hidden','important');document.documentElement.style.setProperty('max-width',vw+'px','important');document.body.style.setProperty('overflow-x','hidden','important');document.body.style.setProperty('max-width',vw+'px','important');document.body.style.setProperty('width','100%','important');}catch(e){}})();this.remove();">

Vibe Coding Security: Risks, Vulnerabilities, and How to Secure AI-Generated Code

Checkmarx Team — Tue, 17 Mar 2026 09:06:00 +0000

updated March 17, 2026

With GenAI taking over almost everything we do, a great emerging use case is “vibe coding.” The formal defintion of vibe coding is: “an AI-dependent programming technique where a person describes a problem in a few sentences as a prompt to a large language model (LLM) tuned for coding.”

Basically it allows anyone to create applications without knowing how to code a single line. It has the potential to help accelerate velocity, untangle previous bottlenecks, and reduce the need to have every request go to R&D – allowing R&D to focus more on complex business logic.

What Is Vibe Coding?

Vibe coding describes a style of AI-assisted development where a user prompts an LLM or coding assistant to generate code, refine logic, and iterate quickly toward a working outcome. It lowers the barrier to entry, increases development speed, and helps teams prototype and ship faster.

But the same acceleration that makes vibe coding attractive also creates new security pressure. AI can introduce insecure logic, unsafe dependencies, weak access controls, or exposed secrets at a pace that quickly outstrips manual review. In other words, the more software is created at machine speed, the more important vibe coding security becomes.

For engineering leaders, the opportunity is clear: faster delivery, fewer bottlenecks, and more experimentation. For security leaders, the challenge is equally clear: less visibility, more change volume, and a wider software supply chain to govern. The real question is not whether teams should use AI-assisted development. It is how to make it secure at scale.

The Security Risks of Vibe Coding

Vibe coding security risks are not theoretical. When AI generates code without strong guardrails, teams can inherit the same classes of issues security teams already know well, only faster and at greater scale.

1. Insecure AI-generated code

AI coding tools can reproduce insecure patterns from training data or generate flawed logic under pressure to produce fast results. That can lead to issues such as injection flaws, weak authentication, broken authorization, or unsafe handling of sensitive data.

2. Vulnerable and unverified dependencies

AI-generated code often introduces open-source packages, frameworks, and libraries automatically. Without validation, teams can inherit vulnerable, malicious, or simply inappropriate dependencies that expand software supply chain risk.

3. Hard-coded secrets and unsafe configuration

Generated code may expose API keys, tokens, credentials, or permissive defaults. These issues are easy to miss during rapid iteration and can become high-impact weaknesses once merged or deployed.

4. Over-trust in AI output

One of the biggest vibe coding security issues is not just bad code. It is uncritical acceptance of AI-generated code. If teams assume generated output is production-ready, vulnerabilities can move downstream without meaningful validation.

5. Reduced auditability and governance

As AI tools generate more code and suggest more changes, it becomes harder to explain how decisions were made, what dependencies were introduced, and whether policy requirements were followed. That creates friction for governance, compliance, and risk ownership.

6. More change volume than traditional security processes can absorb

AI-assisted development increases code volume, dependency churn, and pull request activity. Traditional detection-only workflows struggle to keep up, which means backlogs grow even when teams are trying to move faster.

Why Traditional AppSec Struggles With Vibe Coding Security

Most security programs were built for a world where code moved at human speed. Vibe coding changes that. AI can generate, modify, and refactor code continuously, which means security teams are no longer dealing with occasional bursts of change. They are dealing with a new operating model.

That is why securing vibe coding requires more than periodic scanning or post-hoc review. Security has to work in parallel with creation. Teams need visibility into AI-generated and human-written code, the dependencies AI introduces, and the real business risk associated with each issue. The goal is not to slow innovation down. The goal is to make trust scale as fast as development does.

How to Improve Vibe Coding Security in Practice

Organizations do not need to choose between AI-driven velocity and secure development. They need guardrails that fit the way modern teams actually build.

Treat AI-generated code like any other untrusted input

Every AI-generated change should be validated before merge. Teams should review generated logic, check dependencies, and verify that security controls still hold under real usage conditions.

Add security guardrails where developers already work

Security works best when it fits naturally into the developer workflow. That means surfacing security feedback in the IDE, pull request, and CI/CD pipeline instead of forcing teams into disconnected tools and manual handoffs.

Prioritize what is truly risky

High-volume AI-assisted development can flood teams with findings. Prioritization should account for exploitability, reachability, runtime context, business impact, and policy alignment so teams can focus on what materially reduces risk.

Validate runtime behavior, not just code patterns

Static analysis matters, but so does verifying how applications behave at runtime. AI-generated code can introduce logic flaws, authentication gaps, and API weaknesses that only become visible when applications are tested under real conditions.

Govern dependencies and the AI software supply chain

Securing vibe coding also means governing the packages, frameworks, models, and other AI-related components that code generation tools introduce. Visibility and policy enforcement are essential if teams want to prevent risky components from shipping.

Preserve human oversight

AI can accelerate triage and remediation, but production-bound changes should still remain reviewable, explainable, and auditable. The strongest security programs use AI to help teams move faster while preserving control.

What Securing Vibe Coding Looks Like at Scale

As AI-assisted development becomes part of normal engineering workflow, security teams need more than isolated scanners and after-the-fact review. They need a way to secure human and AI-generated code as it is created, prioritize the issues that matter most, and keep remediation inside the workflows developers already use.

That is the shift from reactive AppSec to continuous assurance. Instead of waiting for risk to pile up, organizations can reduce exposure earlier with security controls in the IDE, richer prioritization across the platform, and governed remediation that supports developer speed without sacrificing oversight.

Secure AI-Generated Code

Protect vibe-coded applications without slowing developers down

Checkmarx Developer Assist helps teams secure human and AI-generated code in real time inside the IDE, with explainable guidance and safe remediation that keeps developers in flow.

Start 30-day Free Trial Now

Conclusion

Vibe coding is here to stay. It can unlock major gains in speed, experimentation, and developer productivity, but it also creates a faster, more complex risk surface. That makes vibe coding security a business and engineering priority, not just a coding hygiene issue.

The organizations that succeed will be the ones that secure AI-generated code without interrupting the flow of development. That means combining visibility, prioritization, runtime validation, supply chain governance, and developer-first guardrails so teams can move quickly with confidence.

Goodbye SDLC, Hello ADLC: How Will AppSec Adapt?

Checkmarx Team — Mon, 26 Jan 2026 18:49:33 +0000

Application security, as it exists today, was shaped by the Software Development Lifecycle.

The SDLC assumed that code was written primarily by humans, progressed through recognizable phases, and paused naturally at points where review made sense.

Security controls were layered onto those pauses – during pull requests, before releases, or after builds – because that’s where time existed to apply them.

Those assumptions are becoming obsolete.

The SDLC Mental Model Is Breaking

AI has changed how code comes into existence. An increasing number of modern codebases are now generated, modified, and refactored continuously, often without a clear distinction between “writing,” “fixing,” and “improving.”

The lifecycle no longer advances in steps or clear breaks. It loops.

Once that happens, many of the places where AppSec traditionally operated, like stage gates, handoffs, centralized review queues, lose their effectiveness. They weren’t designed for continuous change, and they weren’t designed for machine-paced production.

What ADLC Actually Describes

The Agentic Development Lifecycle (ADLC) is a new methodology that is shaping a new reality.

In an ADLC environment, humans and AI systems work together to produce and evolve software continuously. Developers guide intent and direction, while AI systems generate, transform, and extend code at a rate that no longer maps cleanly to phases or milestones.

This changes the unit of work AppSec has to reason about: Instead of releases or pull requests, security has to contend with a constant stream of small, fast-moving changes.

Why Existing AppSec Models Struggle

Most AppSec programs were built around interruption: stop here, scan there, review later. That approach assumes development can afford to wait.

In ADLC, waiting becomes part of the risk.

Centralized security teams cannot manually review the volume of code produced by AI-assisted workflows, and stage-based tooling struggles to stay relevant when code is rewritten multiple times before it ever reaches a traditional checkpoint.

There’s also a growing false sense of safety around AI-assisted development.

Because AI-generated code often looks clean, idiomatic, and well-structured, it’s easy to assume it is safer than hand-written code.

In practice, it frequently reproduces insecure patterns, makes inconsistent trust assumptions, and introduces vulnerabilities that are harder to spot precisely because they appear reasonable.

The impact is felt on both sides of the organization: Security teams lose timely visibility and effective control as AI accelerates code creation beyond traditional review models.

At the same time, developers experience security as an after-the-fact interruption, flagging issues in code that has already changed.

ADLC exposes a fundamental mismatch: tools designed for sequential development cannot keep pace with AI-driven workflows without compromising either security or speed.

What AppSec Has to Become

If development is continuous, security has to operate continuously as well.

That means security systems need to evaluate code as it is created and modified, not after the fact. They need to understand context – how a piece of code fits into a broader system – and they need to act without relying on human intervention for every decision.

This is where agentic AI becomes necessary rather than aspirational. Security systems need the ability to reason about changes, apply organizational policies automatically, and persist alongside development rather than responding to snapshots.

In practical terms, this pushes AppSec closer to where development decisions are made: inside the IDE and before changes are committed. It’s where developers’ convenience and necessity intersect, because that’s where intent is expressed and where correction is still cheap.

The Developer Workflow Is Changing

As AI takes on more of the mechanical aspects of coding, developers spend more time directing, validating, and integrating output. Security decisions increasingly happen implicitly, through what developers accept, reject, or modify.

Independent research such as the BaxBench benchmark, which measures how well large language models generate backend applications that are both functionally correct and secure, shows a stark reality:

Even flagship models frequently produce code that may or may not work but still contain security vulnerabilities. In the BaxBench evaluation, many generated programs that passed functional tests still failed security checks when exposed to expert-designed exploits, indicating that correctness and security don’t automatically coincide in AI-generated outputs.

AppSec has to align with that reality. Guidance that arrives late or requires developers to context-switch will be ignored, regardless of policy. Guidance that arrives in-line, with enough context to be actionable, has a chance to influence outcomes at scale.

AppSec in SDLC vs. ADLC

This doesn’t eliminate governance. Organizational standards, risk tolerances, and compliance requirements still matter. What changes is how they are enforced: automatically and continuously, rather than episodically and manually.

Organizational Consequences

In many organizations, this shift is already reshaping responsibility boundaries. AppSec capabilities are beginning to intersect more closely with platform engineering and emerging AI engineering teams, reflecting the fact that security, developer experience, and AI systems are now tightly coupled.

Security becomes less about approval and more about enablement, providing guardrails that operate at the same speed as development rather than trying to slow it down.

Closing

ADLC doesn’t leave much room for AppSec to catch up later. Code is produced continuously, changes compound quickly, and delayed feedback becomes indistinguishable from no feedback at all.

That reality forces a simple conclusion: security has to operate inside the development loop itself, aligned to how software is actually produced in an AI-driven lifecycle.

Checkmarx.dev offers a view on what ADLC-oriented security looks like in practice, with Checkmarx Developer Assist – an agentic security linter that operates directly inside supported IDEs to evaluate risk as code is written – before commits, pipelines, or handoffs exist.

Developers and AI engineers can try it hands-on through a free trial in IDEs like VS Code, Cursor, Windsurf, and AWS Kiro.

If SDLC framed how AppSec worked for the last decade, ADLC will define what works next.

Learn more and get your free trial at https://checkmarx.dev

This article was originally published on Checkmarx’s LinkedIn Newsletter, “The Monthly Checkup”.

Your New Teammate Doesn’t Eat Pizza

Checkmarx Team — Thu, 18 Dec 2025 16:47:59 +0000

Human beings have had teammates since our ancestors went hunting together to refresh the tribal stock of woolly mammoth burgers. More recently, our teammates have been people who share our offices, deadlines, late night pizza, and IT issues.

Now, how we view teammates is evolving, thanks to the two-letter noun that has changed everything: AI.

Building Together

Across even mainstream businesses, AI agents are fast becoming valuable members of the team. These agents go beyond software systems to autonomously deliver complex tasks using reasoning, planning, and learning from experience.

Our new virtual colleagues are doing the slow jobs at supersonic speeds, the boring jobs without complaining, and the complex jobs without fuss. In short, they’re becoming ideal teammates whose only fault is not paying for the late night pizza (not yet anyway).

This is particularly true in our own world of software development.

At Checkmarx, we believe the future of software development will be a mix of agents and humans building together. Productivity and security delivered thanks to a combination of advanced tech and good old fashioned brain cells.

All of which sounds great but, of course, AI isn’t all sunshine and rainbows.

A New World

In the past year we’ve seen AI make a huge impact on software development where the use of coding assistants is becoming widespread. Our Future of Application Security Report discovered that 50% of organizations now use AI to write code. This was mid-2025 and we expect this number to rise significantly when we report back again in 2026.

AI itself is now driving cyberattacks that are more sophisticated, widescale, and dangerous than ever before. It can find the weak link in the supply chain, impacting everyone. You need to know what’s going on and what’s in place across your supplier list.

As a result, security is struggling to keep up with the pace of code creation and the scope of new vulnerabilities that AI brings. This problem is so acute that traditional AppSec simply can’t cope by itself.

Organizations are looking to simplify ineffective tool stacks with unified platforms that automate and combine security actions providing speed, efficiency and, above all, effectiveness.

At Checkmarx, we’re specifically developing Agentic AI teammates that will provide our customers with the application security they need through our Checkmarx One platform.

Meet the Checkmarx Teammates

We’re redefining software security by embedding autonomous, reasoning agents inside the development process itself. Instead of waiting for code to hit the CI/CD, AI lives directly inside the IDE, understanding context, enforcing policy, and reasoning through risk as developers type.

Our approach to agentic security has three pillars (and three teammates), all of which will be available in the very near future:

Developer Assist

Launched in 2025, Developer Assist is already making a huge difference to security for our customer. It validates both AI-generated and human written code inline, blocking unsafe completions and explaining secure alternatives in real time.

Triage and Remediation Assist (launching early 2026)

This agent applies governance dynamically before code ever leaves the local environment directly within the build process and in the SCM (GitHub). Aligns AI-generated logic with enterprise and regulatory policies.

Insights Assist (launching early 2026)

Our third agent correlates developer behavior, policy enforcement, and security telemetry to generate business-level ROI metrics.

Together, all these agents form a reasoning loop that doesn’t just find problems but learns from them to help you remediate in real-time.

And Your Future Colleagues?

Very soon, Checkmarx will have you fully covered for code creation. We also see Agentic AI as crucial to your entire SDLC in the future. The diagram below shows you where we believe these agents will play a role in security and productivity:

The Team Works

In 2026, it’s no longer sensible to approach application security reactively. AppSec needs to be continuous, always on and in real time to deal with the hypersonic speeds of an AI attack and weakness of code creation.

The development team of the future will be the humans who inspire the ideas, drive the projects and make the big decisions. They’ll be working alongside new AI agent teammates, doing the serious working of ensuring code is clean and AI-powered attacks are repelled by AI itself. Like good colleagues, they don’t get in the way but actually increase the productivity of developers, working alongside them directly in the IDE.

This future is here now at Checkmarx.

Start your journey by taking a look at Developer Assist and get in touch if you’d like a personalized demo for your own team.

Leading the Shift to a Continuous Agentic AppSec: Checkmarx Acquires Tromzo

Checkmarx Team — Mon, 08 Dec 2025 17:03:28 +0000

Software development has fundamentally changed. Application Security must change with it.

AI Code Generation Broke the Speed Limit

The ratio of developers to AppSec engineers has always been lopsided. But with the advent of AI coding assistants, that gap is no longer just a resource issue; it is an existential crisis for the industry.

AI is accelerating software creation dramatically. We are seeing exponentially more code, shipped faster, by more developers of varying skill levels. The traditional model of securing code (manual reviews, gatekeeping, and retrospective scanning) cannot mathematically keep up with this velocity. But the solution isn’t just “more AI.” It is Continuous Agentic Application Security that is rigorous enough for the complex enterprise.

The world’s most critical infrastructure runs on code secured by Checkmarx. We are leading the industry toward a future where AI possesses the reasoning capabilities to secure massive, complex ecosystems without breaking developer workflows. We are building a future that understands real risk, automates remediation, and collapses the noise-heavy processes that fail at scale.

AI for Application Security is an Imperative

With the scale and capabilities of modern AI coding assistants that are baked into the AI IDEs like Windsurf by Cognition, Cursor, AWS Kiro, and others, organizations must adopt an equivalent Agentic AI AppSec solution. It has been found across various recent reports including the OpenAI and Jellyfish paper around AI impact of AI coding tools, that the more AI adoption and utilization by developers, the more software stability and security issues arise.

Checkmarx has made a tremendous step forward in building the most advanced AI for AppSec platform with its announcement of the Checkmarx One Developer Assist that empowers developers to identify and prevent issues at the pre-commit phase within the IDE and as code is being written or generated by AI. This solution that also embeds a unique capability of “Safe Refactor” ensures that code is being secured as its being generated as well as ensuring that the entire repo, dependencies, and build are kept intact.

This initial developer tailored agent was the first step in the process and it provides great coverage for developers in the AI coding Era at the pre-commit phase, however, this is only one piece of the puzzle – the entire AI lifecycle needs to be Agentically secured, and that is what Tromzo’s additional Agents as we will define below are aiming to address – Proper triaging and remediation at the post commit and build phase including within the SCMs (GitHub).

The “Context Gap” is Killing Remediation

The problem in AppSec today isn’t limited to finding the vulnerabilities; it is the inability to remediate them at scale before attackers can exploit them. This problem has only gotten worse as AI powered code generation is writing more software and increasing this backlog of vulnerabilities at an exponential rate.

The current generation of AppSec tools (and even best-in-class scanners) operate on a model of “Find and List.”, identifying vulnerabilities in code but without contextual understanding of the business context.

Missing Context: Current AppSec tools treat a vulnerability in a test environment the same as a critical flaw in a production banking app.
Manual vs. Autonomous: Security teams are drowning in triage queues and ticket-driven workflows that rely on human intervention for every single decision.

When AI generates 10x the code, a manual triage process doesn’t just slow you down; it collapses. Organizations are wasting precious cycles fixing low-impact issues while critical exposures, hidden in the noise, remain live. The “Old Way” lacks the business awareness to answer the only question that matters: Does this actually pose a risk to us right now?

Adding the Layer of Tromzo AppSec Agents for Triaging and Remediation to Checkmarx Assist.

Tromzo is the only platform built on a true Cognitive Architecture capable of handling enterprise complexity. Their reasoning agents don’t just “guess”; they ground themselves in the customer’s actual code, cloud, and business data.

The Bake-off Result: We pitted multiple AI AppSec agents against our own world-class research team and gold-standard datasets. Tromzo consistently emerged as the leader, delivering the highest accuracy, the deepest reasoning, and the strongest UX. It was the only solution that behaved like an expert AppSec engineer rather than a chatbot.

From “Finding” to “Reasoning”

This acquisition reinforces Checkmarx as the only true enterprise-grade AppSec platform in a sea of point solutions.

By integrating Tromzo, we are delivering the stability and trust of Checkmarx with the speed of next-gen autonomy.

Enterprise-Grade Reasoning: Tromzo’s agents analyze vulnerabilities with deep code-to-cloud context. They understand how a massive, distributed application works, evaluate exploitability, and determine business impact.
Noise Collapse: Instead of equal-weight findings, you get precise, risk-based decisions grounded in your complex environment.
Autonomous Remediation: We replace “ticket floods” with precise, reliable code fixes to remediate risks. This isn’t just about moving fast; it’s about moving fast without breaking compliance or governance controls.

Checkmarx has always been the leading platform for securing the world’s most complex code. Now, we are the most intelligent platform as well.

Integrating into Checkmarx

Tromzo’s technology and AI agents are becoming the core intelligence layer of the Checkmarx platform.

We are infusing Tromzo’s deep reasoning agents directly into our platform. This integration strengthens the intelligence layer that helps enterprise customers prevent and remediate vulnerabilities throughout the SDLC. With Tromzo, Checkmarx Assist gains the ability to see the full picture, from code to cloud, pre and post code commit, enabling the unprecedented accuracy and stability that our enterprise customers demand and driving us toward the future of fully supervised, autonomous Application Security.

The future of code is AI-generated. The future of application security in the era of AI coding is Checkmarx.

Checkmarx Influencer 2026 Predictions

Checkmarx Team — Tue, 02 Dec 2025 08:24:55 +0000

AI is accelerating everything online—volume, velocity, and risk. Great Application Security no longer reacts to threats. It prevents them before they happen.

Checkmarx leaders share what is next: a shift from one-off code scans to continuous, agentic intelligence that learns, explains, and protects organizations in real time. Check out these Checkmarx predictions for 2026.

“There’s a collective CEO obsession (and I count myself in this group) with AI-driven productivity that will peak in 2026 when organizations wake up to the reality of weakened security postures.”

Sandeep Johri

CEO, Checkmarx

This year was pivotal in our business. The headlines, trendlines, and our data say the same thing: threats are accelerating—and we must stay vigilant to stay ahead.

Anthropic reported a largely autonomous AI-led espionage campaign against 30 organizations, executed with minimal human intervention and raising serious questions about the stability of business and public infrastructure. Nearly every one of the 1,500 AppSec leaders we surveyed reported breaches tied to vulnerable code. Less than one in five organizations even have governance policies in place to manage the coming wave of autonomous code in 2026.

There’s a collective CEO obsession (and I count myself in this group) with AI-driven productivity that will peak in 2026 when organizations wake up to the reality of weakened security postures.

The new obsession will be a healthier marriage of speed and intelligence, leveraging AI for productivity with security for AI, and AI for security. The way to stem the tide of the coming wave of automated code is to make AppSec agentic: autonomous, intelligent, and developer-first. The future of AppSec is about reimagining security, not as an afterthought or a gatekeeper, but as a strategic engine for innovation at scale.

“AI agents will support developers at every stage of coding, from the first lines they write to the moment they save changes to the shared repository. Traditional IDEs that will not adopt agentic approaches will lose significant developers’ market share to modern AI IDEs.”

Eran Kinsbruner

VP of Portfolio Marketing

2026 will be the year when Agentic AI AppSec becomes a natural component within the integrated development environments (IDEs), supporting traditional application security tasks including prevention, remediation, prioritization, and overall AppSec orchestration activities.

AI agents will support developers at every stage of coding, from the first lines they write to the moment they save changes to the shared repository. Advanced LLM and other intelligent capabilities will proactively enhance AI coding security to spot risks early and suggest fixes before they turn into problems. Traditional IDEs that will not adopt agentic approaches like Eclipse, IntelliJ, and others, will lose significant developers’ market share to the modern AI IDEs like AWS Kiro, Cursor, Windsurf, and Co-Pilot.

“The best tools in 2026 won’t be the ones that generate the most code. They will be the ones that help developers see how a line of code came to be, what assumptions it carries, and whether it meets the team’s standards.”

Steve Boone

Director of Product Marketing

The idea that AI will replace developers misses the point. In practice, it changes what “writing code” means. Developers are becoming editors and reviewers of generated work. Their value shifts toward judgment. They must know when to trust a suggestion and when to discard it.

The best tools in 2026 won’t be the ones that generate the most code. They will be the ones that help developers see how a line of code came to be, what assumptions it carries, and whether it meets the team’s standards.

Developers will shift from coders to curators, guiding and auditing machine-generated output. The next phase isn’t full automation—it’s disciplined collaboration, where transparency, traceability, and trust define maturity in an AI-driven SDLC.

“The bigger risk now is the software supply chain. Just look at the attacks on the open-source community in the last few months. With more LLMs and AI-driven apps, dynamic analysis is back in the spotlight.”

Ori Bendet

VP of Product Management

Static analysis—checking code without running it—is losing ground faster than you think. It’s still useful, but its future lies in smarter roles like correlation, which groups related security findings into themes, and context, which explains why issues matter and how to fix root causes instead of chasing individual alerts.

The bigger risk now is the software supply chain, just look at the attacks on the open-source community in the last few months. With more LLMs and AI-driven apps, dynamic analysis, or testing code while it runs, is back in the spotlight to help keep AppSec adaptive and resilient.

“The next generation of security must combine classic cybersecurity with AI governance, model integrity, and agent-level risk management. ”

Jonathan Rende

Chief Product Officer

AI is moving from a ‘human hands on the wheel’ approach to a future with no human in the middle. Traditional LLMs like Claude or Google may do a ‘good enough job’ for basic static needs, but security can’t just focus on static versus dynamic systems anymore.

Agentic and autonomous systems are self-learning ecosystems, which means the next generation of security must combine classic cybersecurity with AI governance, model integrity, and agent-level risk management. This is how we safeguard trust, compliance, and resilience in the AI era.

“’Model-as-Malware’ is rising. Open-source LLMs and fine-tuned weights are slipping into the supply chain like npm packages. Expect poisoned weights, rigged adapters, and backdoored models trusted by teams because they are disguised as ‘productivity tools.’”

Erez Yalon

VP of Security Research

Breach stories won’t change, but they will accelerate. Convenience beats caution and attackers hunt the newest building blocks. We warned that attackers would keep going after the supply chain. AI just made it bigger and harder to see. In 2026, that risk will hit production scale.

API surfaces are getting weirder and noisier. Vibe-augmented apps hit more third-party APIs, more often, with less human oversight—amplifying timing races, auth errors, and logic bugs in blind spots. API security has long focused on awareness, but autonomous callers multiply the blast radius of a single dangling permission.

“Model-as-Malware” is rising. Open-source LLMs and fine-tuned weights are slipping into the supply chain like npm packages. Expect poisoned weights, rigged adapters, and backdoored models trusted by teams because they are disguised as “productivity tools.” For attackers, models are ideal payloads: opaque, bulky, hard to inspect, and everyone’s rushing. This isn’t hypothetical. We already see malicious LLM components in the supply chain.

“Founders will realize they need a solution that figures out security for them the same way Claude and Lovable figured out app building for them. That awareness will expose a market gap, and a major opportunity.”

Frank Emery

Director of Product Management

More and more people who have no idea what it takes to take an application to production will start adopting AI-based development and application-building solutions. “Tar pit ideas” turned into working products will be wildly insecure.

We’ll see more “great ideas” rushed to market, only to be attacked soon after. As this pattern continues, founders will realize they need a solution that figures out security for them the same way Claude and Lovable figured out app building for them. That awareness will expose a market gap, and a major opportunity.

The way people use LLMs will fragment even more.

“It will become clearer that LLMs cannot develop complex, maintainable solutions on their own (i.e. without very strong technical guidance). Many companies and individuals will find that out the hard way.”

Simon Bennetts

Software Engineering Expert

There will be a significant LLM backlash from people who don’t really understand how to use them best, but who believed the hype.

It will become clearer that LLMs cannot develop complex, maintainable solutions on their own (i.e. without very strong technical guidance). Many companies and individuals will find that out the hard way.

Lots of “AI” startups who raise funding and just build wrappers around LLMs will fail.

People who work out how to integrate LLMs into their workflows and can reliably evaluate their output (and get them to rework it) will get great benefit from them and will keep cheerleading.

There’s significant potential for a solution which automates a set of security tests against LLM generated code (SAST, DAST, SCA, and others,) and then makes it easy to feed that data back into the LLM that the customer used to generate it, as an “auto-correction” loop.

“Our solution must be able to differentiate between code written by developers and code written by AI, providing the best insights and solutions. ”

Yossi Rifold

Director of Product Management

AI will be integrated into various parts of the SDLC, meaning we must identify the relevant personas in the right phase of the process (for example, developers in the IDE and PR, AppSec) in their day-to-day activities, etc.)

The more developers depend on AI, the more security risks they’ll introduce. Tools like Checkmarx Codebashing and other platforms will become essential to teach secure coding and safer AI use.

Our solution must be able to differentiate between code written by developers and code written by AI, providing the best insights and solutions.

“AppSec teams will give code agents a shot to help secure all AI-generated code, but those tools won’t live up to the hype. Instead, we’ll see a shift toward a hybrid approach: stronger versions of existing controls combined with new agent-based systems that wrap around applications in clever ways.”

Darren Meyer

Security Research Advocate

Driven largely (though not entirely) by AI, AppSec tooling will shift noticeably to the right in 2026, focusing more on what happens later in the SDLC: runtime and production.

As AI starts generating code at unprecedented speed, AppSec teams will be overwhelmed trying to fix vulnerable code and will move toward a combination of tools to prevent security flaws and weak code from resulting in breaches.

AppSec teams will give code agents a shot to help secure all the AI-generated code flying around, but those tools won’t quite live up to the hype. So instead, we’ll see a shift toward a hybrid approach: stronger versions of existing controls like EDR/XDR, CNAPP, and runtime SCA, combined with new agent-based systems that wrap around applications in clever ways. These newer solutions will be marketed hard and we believe, successfully, as modern alternatives to traditional AppSec tooling.

“AI-coding assistants have changed the game. The new challenge isn’t scanning—it’s trusting machine-generated code and ensuring continuous validation.”

Scott Walston

VP, Americas

Stop building scanners. Start building security intelligence systems that learn, predict, and prevent.
The future AI-driven platforms will sit inside developer workflows—validating AI-generated code, protecting APIs, and delivering contextual, code-to-cloud visibility. Leaders will integrate automation, transparency, and adaptive protection that continuously learns and self-tunes.

AI-coding assistants have changed the game. The new challenge isn’t scanning—it’s trusting machine-generated code and ensuring continuous validation. Security must evolve from reactive testing to adaptive engineering that connects code and runtime intelligence.

As regulations tighten and the AI supply chain expands, success will belong to those who prove security, not just test it—embedding compliance, provenance, and assurance into every build. By 2026, AppSec will mean governing AI-driven software with predictive, autonomous systems that protect at the speed of code.

Revolutionizing SCA With Agentic AI: How Checkmarx Developer Assist Transforms Open-Source Security Within the IDE

Checkmarx Team — Wed, 19 Nov 2025 14:22:06 +0000

Revolutionizing SCA with Agentic AI: How Checkmarx Developer Assist Transforms Open-Source Security within the IDE

Software Composition Analysis (SCA) has become an essential pillar of modern application security, helping organizations identify vulnerabilities, malicious components, and licensing issues within open-source dependencies.

Traditional SCA solutions scan codebases to detect risky packages, providing security teams with critical visibility into their open-source attack surface. However, the typical SCA workflow—scanning code at specific stages in the software development lifecycle (SDLC) and then cycling back to remediate issues—creates friction, delays releases, and frustrates developers who must context-switch away from active development to address security findings.

SCA, Shifted All-the-Way Left

The true value of SCA emerges when it is embedded directly into the developer’s workflow, providing real-time feedback within the integrated development environment (IDE) where the code is written. By shifting security left into the IDE, developers receive immediate alerts about vulnerable or malicious dependencies as they work, rather than discovering problems days or weeks later during code commit or CI/CD pipeline scans.

This real-time approach prevents security debt from accumulating, reduces the cost and effort of remediation, and empowers developers to make secure choices as they create their code. When SCA becomes an integrated, continuous process rather than a disruptive checkpoint, security transforms from a bottleneck into an enabler of faster, safer development.

Introducing Agentic AI for SCA

Checkmarx is already a leading SCA provider through its Checkmarx One platform, but the recent introduction of the agentic-AI Developer Assist takes this functionality to an entirely new level. Developer Assist’s agentic AI core changes the SCA dynamic, because it is constantly on the lookout for problems and is always ready to act on behalf of the developer, all within the IDE.

Developer Assist fundamentally transforms the traditional SCA experience by introducing agentic AI capabilities that continuously and actively monitor, analyze, and remediate OSS dangers without breaking developer flow – instead of forcing developers to reopen closed code bases later.

At its core, Developer Assist provides ongoing background SCA scanning of open-source package dependencies during all code writing activities, whether the code is written by humans or provided by generative AI tools.

This continuous monitoring extends to whenever manifest files are modified. Supported manifest file types currently include:

.NET (csproj, directory.packages.props, packages.config)

Maven (pom.xml)

npm (package.json)

PyPI (requirements.txt)

Go (go.mod)

This breadth of coverage ensures that regardless of their technology stack, developers receive consistent and accurate real-time security feedback.

The Safe Refactor Revolution

The most far-reaching innovation of Developer Assist lies in its ability to not just identify open-source dependency problems but to autonomously resolve them with intelligent, context-aware remediation.

When a vulnerable or malicious package is detected, the developer can launch agentic-AI Safe Refactor capabilities that automatically generate code changes directly within the IDE, complete with step-by-step explanations that developers can review and approve before implementation.

Safe Refactor first attempts to replace a dangerous package with a safe version of the same package. In cases where no safer version exists, Safe Refactor leverages the developer’s generative AI tools (e.g., Cursor or GitHub Copilot) to suggest alternative packages with similar functionality, ensuring developers aren’t blocked, without a path forward.

Beyond simple package swaps, Safe Refactor demonstrates sophisticated understanding of dependency ecosystems by detecting when other related open-source packages also need replacement to ensure compatibility with newly introduced packages. This holistic approach prevents the cascade of compatibility issues that often plague manual security remediation efforts, where fixing one dependency breaks another. But there is even more…

The crown jewel of Developer Assist is how Safe Refactor autonomously handles the complex code-level changes that package updates often require, saving developers vast amounts of time and effort: Safe Refactor automatically detects breaking changes introduced by replaced packages and makes the necessary code modifications so that calls to updated packages’ methods and functions continue to operate as expected.

Developers can interactively chat with the AI agent to ask questions and refine remediation suggestions, maintaining control over the process while benefiting from cutting-edge AI assistance.

After developers approve suggestions, Safe Refactor runs tests to ensure that the modified application code compiles and functions correctly, even creating new tests when relevant existing tests aren’t found in the project.

Watch a demo showing Developer Assist’s Safe Refactor in action.

Developer Assist for SCA Saves Time and Improves Security

The time savings delivered by Developer Assist are substantial for both development teams and application security professionals. Tasks that previously consumed hours – researching package alternatives, rewriting function calls, ensuring compatibility, and running post-remediation tests – are now almost completely automated.

In fact, very conservative Checkmarx benchmarks indicate that upgrading dependencies is up to 70% faster with assisted code refactoring, saving approximately $420 per upgrade in developer time.

This efficiency enables developers to maintain their productivity, creative flow, and innovation instead of being pulled into time-consuming security firefighting. Meanwhile, AppSec teams can better focus on strategic security initiatives rather than being mired in triaging SCA findings and tracking support tickets.

The benefits of Developer Assist for SCA extend far beyond mere convenience. From a security perspective, continuous background SCA scanning means that vulnerable and malicious packages are caught immediately, rather than lingering undetected until the next scheduled scan. More vulnerable and malicious packages get remediated because the friction of remediation has been dramatically reduced; developers are far more likely to address issues when an AI agent can handle the heavy lifting.

Developer Assist leverages Checkmarx’s industry-leading open-source vulnerability intelligence database.

Unlike many SCA tools that simply aggregate and republish public data, Checkmarx’s CVE database is vetted by in-house expert security analysts who validate and contextualize each CVE entry, reducing false positives and highlighting real threats.

Going even further, Developer Assist identifies malicious and suspicious packages (which are not included in CVE databases), by automatically querying Checkmarx’s proprietary database of malicious packages, which is the largest available anywhere (currently containing over 420,000 entries). If a package in a project is classified as malicious or suspicious, the developer is alerted in the IDE so that rapid remediation can occur.

In brief, Developer Assist represents a pure shift-left methodology, bringing early security resolution into the IDE in real-time, rather than forcing the costly cycle of commit or CI/CD scan failures followed by code fixes and re-scans. By resolving issues before code ever leaves the developer’s machine, organizations reduce pipeline delays, accelerate release velocity, and build security into their culture rather than bolting it on afterward.

Join the AI-Driven SCA Paradigm Shift

The evolution from traditional scan-and-alert SCA to continuous AI-driven security monitoring and remediation automation represents a paradigm shift in how organizations can protect their software supply chain without sacrificing developer speed or experience. Developer Assist doesn’t just make SCA more convenient, it fundamentally reimagines what’s possible when intelligent automation meets security expertise.

Ready to transform your SCA approach and empower your developers with agentic AI security assistance? Learn more about Developer Assist or request a personalized demo of Checkmarx One Assist and see how Checkmarx is revolutionizing security within enterprise development workflows.

Rumors of the Developer’s Demise Have Been Greatly Exaggerated: A Perspective From Simon Bennetts, Software Engineering Expert at Checkmarx

Checkmarx Team — Tue, 18 Nov 2025 11:06:17 +0000

If you’ve spent any time in the world of software development lately, you’ve seen the impact of AI—especially Large Language Models (LLMs). They’re fast, powerful, and transformative. They can generate code in seconds, and in many cases, it runs right out of the gate.

It’s impressive, exciting, but also raises many concerns.

We’re now generating more code with machines than humans: Our research found that over a third of organizations say more than 60% of their code is automated. That sounds efficient, but it introduces a new kind of risk.

AI-generated code is often less secure, less maintainable, and more opaque. LLMs do not understand your business logic, your architecture, or your long-term goals. They’re not developers—they are token prediction engines.

So the good news is, LLMs are not going to replace developers any time soon. But they are dramatically changing how developers work.

The days of coding lines of JavaScript, Golang, and Python in isolation are over. We are in an era where developers are critical decision-makers, validating AI output, spotting flaws, and safeguarding security at scale. They will soon spend more time on design, integration, security, and innovation, and less time typing in lines of code, which means their value proposition is on the rise.

But with that shift comes a greater burden of responsibility. Developers need AppSec more than ever—not just to secure the code they write, but to validate and fortify the code AI generates on their behalf. As they become gatekeepers of software quality and security, they need tools that empower them to move fast without compromising safety. This is no longer a nice-to-have; it is mission-critical.

I’ve been on both sides of this equation: Before joining Checkmarx, I spent decades as a developer and security advocate. I created ZAP , the world’s most widely used open-source Dynamic Application Security Testing (DAST) tool. ZAP was built to bring more efficiency into security testing without slowing developers down, with automation—a principle that still drives me today.

When Checkmarx employed 3 of the ZAP Core team, it wasn’t just about adding DAST to the portfolio. It was about building a unified vision for the future of AppSec—one that combines SAST, SCA, DAST, IaC scanning, and API security into a single platform: Checkmarx One.

This integration moves us beyond scanning code to understanding business risk, which is exactly what modern organizations need. Because according to our research, there has never been a more critical time for Application Security than now.

34% of organizations report that 60%+ of their code is AI-generated, yet only 18% have policies governing AI use.

81% knowingly ship vulnerable code, and 98% experienced at least one breach in the past year (with over half of orgs reporting three breaches or more).

With this dizzying pace, it’s clear that security cannot be a bolt-on; it must be embedded from code to cloud and designed to match the pace and heightened risk of AI-generated code. So we are launching a family of AI-powered agents designed to deliver always-on protection throughout the SDLC.

These agents don’t just scan code. They reason, prioritize, and adapt. They collaborate in an intelligent ecosystem helping developers move faster, stay secure, and innovate with confidence. They do the operational work so developers can ask the hard questions behind every line of code.

Introducing the Checkmarx One Assist Family

Developer Assist: Your AI pair programmer, embedded in the IDE, fixing vulnerabilities in real time.

Policy Assist (coming soon): A DevSecOps enforcer that applies security policies consistently across pipelines.

Insights Assist (coming soon): An AppSec strategist that prioritizes vulnerabilities based on business impact.

Imagine asking the simple question: “What’s the biggest vulnerability in our tech stack that could impact our customers?” With Checkmarx One Assist, you will get an answer—fast, accurate, and actionable.

The road(map) ahead…

We’re excited to lead a future where security is developer-first, AI-driven, and business-aware. Our roadmap includes new agents for compliance, threat modeling, and runtime protection—plus continued investment in open source and the best ASCA tools on the planet.

Soon, Checkmarx is likely to hit a major milestone: scanning one trillion lines of code every month. That is not just a number—it’s a responsibility. So developers are not going away, they are moving up the value chain. With the right tools, they will lead the next era of secure, AI-powered software development.

Learn more about Checkmarx One Assist.