In March 2026, the TeamPCP attack compromised Trivy, Checkmarx, LiteLLM, and dozens of npm packages. Security teams knew about the vulnerabilities. They'd logged tickets, assigned severity scores, and scheduled patches. But nothing moved fast enough because nobody could show leadership what "exploitable CI/CD vulnerability" actually meant in their environment.
Boost Security just released SmokedMeat, an open-source tool that simulates complete attack chains in CI/CD pipelines. It doesn't just flag a vulnerability; it demonstrates the full exploitation path against your actual infrastructure. This isn't a theoretical exercise. It's a live demonstration of what an attacker would do with that single weakness you've been deferring.
The Pattern of CI/CD Compromises
The TeamPCP compromise followed a pattern we've seen repeatedly: attackers find a vulnerability in a widely-used CI/CD component, exploit it to inject malicious code, then use that foothold to compromise downstream systems. The attack succeeded because security teams couldn't effectively communicate the urgency of patching to those controlling deployment schedules.
SmokedMeat addresses this communication gap by executing controlled attack simulations. According to Zaid Al Hamami, CEO of Boost Security, the tool can "execute a live demonstration against a team's own infrastructure starting from a single vulnerability." You point it at a known weakness in your pipeline, and it shows you exactly what an attacker could reach.
Timeline of a Typical CI/CD Compromise
Week 1: Security scanner identifies vulnerability in CI/CD tool or dependency. Ticket created, assigned P3 priority.
Week 2-4: Vulnerability sits in backlog. Engineering argues it's not customer-facing. Security can't quantify the actual risk.
Week 5: Attacker discovers the same vulnerability. Unlike your team, they don't need approval to act.
Week 5, Day 2: Attacker gains initial access through the unpatched component.
Week 5, Day 3-5: Lateral movement. Attacker maps your pipeline, identifies secrets, locates production deployment keys.
Week 6: Malicious code ships to production. You discover it when customers report issues or when the breach appears in security feeds.
This timeline isn't hypothetical. It's the sequence that played out in the TeamPCP attack and in dozens of similar incidents.
Which Controls Failed
Let's map this to specific requirements:
Vulnerability Management (NIST 800-53 Rev 5, RA-5): Teams identified vulnerabilities but couldn't prioritize remediation effectively. The control existed on paper but failed in practice because risk assessment relied on CVSS scores rather than actual exploitability in the specific environment.
Change Management (ISO/IEC 27001:2022, Annex A.8.32): Changes to CI/CD configurations weren't subject to the same review rigor as production code changes. Attackers exploited this gap to introduce malicious modifications that bypassed standard approval workflows.
Access Control (PCI DSS v4.0.1, Requirement 7.2.2): CI/CD service accounts had excessive permissions. Once compromised, a single service account provided access to multiple downstream systems. The principle of least privilege wasn't enforced at the pipeline level.
Secrets Management (OWASP ASVS v4.0.3, V2.10): API keys and deployment credentials were accessible to CI/CD processes without adequate rotation or scoping. Compromising the pipeline meant compromising every secret it touched.
What the Standards Actually Require
NIST 800-53 Rev 5, RA-5(5) requires organizations to employ vulnerability scanning tools that include the capability to readily update the vulnerabilities to be scanned. But it also requires you to act on those findings. The control isn't satisfied by scanning alone; you need a process that connects vulnerability discovery to remediation decisions.
ISO/IEC 27001:2022, Annex A.5.23 (Information Security for Use of Cloud Services) requires security controls to be applied to cloud-based development and deployment processes. Your CI/CD pipeline is infrastructure. It needs the same configuration management, access controls, and monitoring you apply to production systems.
PCI DSS v4.0.1, Requirement 6.3.2 states that security vulnerabilities are identified using reliable sources and that new security vulnerabilities are addressed. The keyword is "addressed," not "documented." If you're logging vulnerabilities but not fixing them because you can't demonstrate business impact, you're not meeting the requirement.
Lessons and Action Items
1. Demonstrate impact before you need to. Run SmokedMeat or similar tools during your quarterly security reviews, not after an incident. Show your engineering leadership what an attacker could accomplish with that P3 vulnerability. Record the demonstration. When the next vulnerability appears, you'll have context for the conversation.
2. Apply production security standards to your CI/CD infrastructure. Your pipeline deploys to production. Treat it like production. This means:
- Configuration as code with peer review
- Secrets rotation on a defined schedule
- Service accounts scoped to specific tasks, not broad pipeline access
- Audit logging for all pipeline modifications
3. Rewrite your vulnerability SLA based on exploitability, not CVSS. A CVSS 7.5 that provides no access to your environment is less urgent than a CVSS 5.8 that gives an attacker a foothold in your deployment process. Use demonstration tools to establish this distinction in your remediation policy.
4. Test your incident response for CI/CD compromises specifically. Most incident response plans focus on production breaches or endpoint compromises. Run a tabletop exercise where the initial access vector is a compromised CI/CD component. You'll discover gaps in your logging, your ability to identify affected deployments, and your rollback procedures.
5. Inventory what your CI/CD pipeline can reach. Map every system, secret, and deployment target accessible from your pipeline. This inventory becomes your blast radius assessment for any CI/CD vulnerability. If you can't complete this inventory, your pipeline has too much access.
The TeamPCP attack succeeded because security teams couldn't make the risk real until it was too late. Tools like SmokedMeat change that equation. You can now show exactly what "compromised CI/CD pipeline" means in your environment, using your actual infrastructure, before an attacker does it for you.
