On May 9, 2026, Checkmarx published a malicious version of its Jenkins AST plugin to the public Jenkins plugin repository. This compromised version was designed to exfiltrate user credentials and potentially other sensitive data from Jenkins environments. This incident was part of a broader supply chain attack that began with a March 23, 2026 attack on Trivy, which allowed attackers to compromise Checkmarx's GitHub repositories and inject malicious code into trusted distribution channels.
If your team uses Jenkins with the Checkmarx plugin, you may have unknowingly downloaded malware from the official plugin repository. This is a classic example of a supply chain attack: trusted infrastructure distributing compromised code.
Timeline
March 23, 2026: Trivy supply chain attack identified. Attackers compromised the vulnerability scanning tool, gaining initial access to downstream targets.
May 9, 2026: Malicious Checkmarx Jenkins AST plugin version published to Jenkins plugin repository. The compromised plugin began distributing to Jenkins instances configured for automatic updates or manual installations during this period.
Post-May 9: Checkmarx engaged a third-party forensic firm to investigate the breach. Unauthorized access to GitHub repositories was confirmed. The investigation is ongoing to determine the full scope of the compromise and affected artifacts.
Which Controls Failed or Were Missing
Code Signing and Artifact Verification
The attack succeeded because Jenkins instances installed the malicious plugin without verifying its origin. The Jenkins plugin repository's integrity controls did not prevent the publication of a compromised artifact from a legitimate maintainer account.
Repository Access Controls
Attackers gained unauthorized access to Checkmarx's GitHub repositories, indicating failures in:
- Multi-factor authentication for privileged accounts
- Session management and token lifecycle controls
- Monitoring for unusual repository access patterns
Supply Chain Dependency Monitoring
The March 23 Trivy compromise went undetected long enough for attackers to pivot to Checkmarx infrastructure. Your dependency tree includes not just the packages you directly use, but the tools those vendors use in their development pipeline.
Build Pipeline Integrity
The malicious plugin reached production distribution, indicating gaps in:
- Code review processes for commits from compromised accounts
- Automated security scanning of build artifacts before publication
- Segregation of duties between code commit and release authorization
What the Standards Require
NIST 800-53, Control SA-12 (Supply Chain Protection) requires organizations to define and document security requirements for developers, assess supply chain risks, and implement monitoring mechanisms. Specifically, SA-12(2) requires supplier reviews, and SA-12(5) mandates limiting harm from suppliers.
For your Jenkins environment, this means:
- Maintain an inventory of all plugins, their versions, and update sources
- Document security requirements for plugin vendors in your procurement process
- Implement technical controls to limit what plugins can access
ISO/IEC 27001:2022, Control 5.19 (Information Security in Supplier Relationships) mandates defining and agreeing upon security requirements with suppliers, including managing changes in supplier services. The Checkmarx incident shows why these requirements must extend to your CI/CD toolchain vendors.
PCI DSS, Requirement 6.3.2 states that software development personnel must be trained on secure coding techniques. For vendors in your supply chain, verify equivalent training and secure development practices exist. Requirement 6.3.3 adds that code changes must be reviewed prior to release—a control that failed in this incident.
NIST Cybersecurity Framework (CSF) v2.0 includes supply chain risk management as a core function. The Identify function (ID.SC) calls for understanding your supply chain's cybersecurity risks. The Detect function (DE.CM) requires monitoring for anomalous activity, including unexpected plugin updates or behavior changes in your CI/CD pipeline.
Lessons and Action Items for Your Team
Immediate (This Week)
Audit your Jenkins plugin inventory. Generate a list of all installed plugins, their versions, and last update dates. If you installed or updated the Checkmarx plugin between March 23 and now, assume compromise and rotate all credentials accessible from your Jenkins environment.
Disable automatic plugin updates. Move to a controlled update process where you test plugins in a non-production Jenkins instance before promoting to production. This creates a detection window.
Review Jenkins security realm configuration. Limit what credentials plugins can access. Use the Credentials Binding plugin to scope credential access to specific jobs rather than making them globally available.
Short-Term (This Month)
Implement artifact verification for all plugins. Configure your Jenkins instances to verify checksums and signatures before installing or updating plugins. Document the verification process and make it a required step in your change management workflow.
Map your supply chain dependencies. Create a diagram showing not just your direct dependencies (Jenkins plugins) but your vendors' dependencies (what tools do Checkmarx, Trivy, and other vendors use?). This is your attack surface map.
Establish plugin update testing protocols. Before deploying any plugin update to production:
- Test in an isolated environment
- Review the plugin's changelog and commit history
- Run the plugin through static analysis tools
- Monitor for unexpected network connections or file system access
Long-Term (This Quarter)
Build supply chain monitoring into your security operations. Subscribe to security advisories for all CI/CD tools in your pipeline. Configure alerts for:
- Unexpected plugin updates in your Jenkins environments
- New network connections from Jenkins agents
- Credential access patterns that deviate from established baselines
Require Software Bill of Materials (SBOM) from vendors. When evaluating or renewing contracts with CI/CD tool vendors, require them to provide SBOMs for their products. This gives you visibility into their dependency tree and helps you assess transitive risk.
Conduct supply chain attack simulations. Test your incident response plan with a scenario where a trusted plugin is compromised. Can you identify affected systems? How quickly can you rotate credentials? Do you have backups of your Jenkins configuration that don't include the compromised plugin?
The Checkmarx incident proves that "trusted" doesn't mean "trustworthy." Your Jenkins plugins have the same access to credentials and source code as your engineering team. Treat them accordingly.
