Key takeaways
- Scan & Pray was built for human-scale development. AI coding assistants have made that model structurally insufficient.
- The TeamPCP attacks in March 2026 demonstrated that malicious code injected at the source into trusted packages bypasses scanning entirely.
- Curate & Govern is the security posture that governs open source software at the point of origin, before it reaches your environment, rather than after.
- Scan & Pray still has a role. The problem is that it has been treated as sufficient when it is not.
- Documented provenance, built-from-source infrastructure, and contractual remediation SLAs are what constitute a defensible program under current regulatory frameworks.
For years, the security industry operated on a shared assumption: if you can see a vulnerability, you can manage it. Scan everything. Alert on everything. Triage the queue. Patch what you can, when you can. Repeat.
That model had a name, even if nobody called it one. Scan & Pray. It was the foundation of software composition analysis, the logic behind every vulnerability scanner, and the implicit promise of every security dashboard that has ever turned a sea of CVEs red.
It also assumed something that is no longer true: that humans are the ones writing the code, pulling the dependencies, and setting the pace.
They aren’t.
The Speed Problem Scan & Pray Cannot Solve
In March 2026, a threat actor known as TeamPCP compromised Trivy, a widely used open source vulnerability scanner, and used the credentials stolen from its CI pipeline to cascade across five separate package ecosystems in under 2 weeks. The final payload landed in LiteLLM, a Python package with 97 million monthly downloads whose function is routing AI API credentials through a single proxy. The malicious code executed on install, with no import required, bypassing standard code review and dependency scanning entirely.
What stopped it wasn’t a scanner. It was a developer who noticed their machine slowing down.
Sysdig, who analyzed the attack, said it plainly: code review and dependency scanning failed because the malicious code was injected at the source into trusted, verified packages. The binary looked legitimate. It came from the right repository, published under the right version tag, by what appeared to be the right account. There was nothing for a scanner to flag because, at the point of installation, nothing looked wrong.
This is not a failure of any individual tool. It is a structural failure of the Scan & Pray model itself. Detection is reactive by definition. It operates after the code has already entered your environment. In a world where developers are pulling hundreds of dependencies manually, that lag is manageable. In a world where AI coding assistants are generating dependencies at machine speed, often pulling transitive libraries that no human explicitly chose, that lag is a liability.
Scan & Pray tells you the house is on fire. In the age of AI-generated code, the fire is already inside the walls before the alarm sounds.
What Curate & Govern Means
Curate & Govern is not a product. It is a security posture.
Where Scan & Pray operates at the point of discovery, Curate & Govern operates at the point of origin. The question it answers is not “what vulnerabilities do we have?” but “what are we allowing into our environment, and can we verify how it was built?”
The difference is structural.
Scan & Pray monitors what has already entered your environment, assesses it against known vulnerability databases, generates alerts, and hands the remediation work back to your team. It is reactive, human-scale, and backlog-generating by design.
Curate & Govern controls what enters your environment before it gets there. Open source software components are vetted, built from source within verified infrastructure, continuously monitored, and automatically remediated when community-approved fixes are available. Policy is enforced at the point of consumption, not bolted on afterward.
Think of it this way: Scan & Pray is the smoke alarm. It tells you the house is on fire. Curate & Govern is the fire-resistant construction and the sprinkler system built into the walls. The alarm still has a role. But when AI coding assistants are generating code and pulling dependencies at machine speed, you need the fire prevention in the structure itself, not just a louder alarm.
Why This Matters More Now Than Ever
The TeamPCP attacks are not an anomaly. They are a preview of the attack surface that AI-assisted development is creating at scale.
When an AI coding assistant suggests a dependency, it may suggest one that has been compromised since the last time it was vetted, one that was legitimate 6 months ago and has since been poisoned, or one that arrived as a transitive dependency of something your developer never directly chose. The LiteLLM compromise reached developer machines exactly this way: as a dependency of a dependency of a Cursor MCP plugin. Nobody on those teams chose to install it.
98% of applications today include open source software. AI is accelerating the rate at which that open source software enters your environment faster than any human team can manually vet. The attack surface is expanding at machine speed. Scan & Pray was built for human-scale ingestion. It is not equipped for what is happening now.
The regulatory environment has also moved. The 2026 regulatory landscape requires documented due diligence, not just detection records. When a breach reaches a deposition, “we had a scanner” does not constitute a reasonably designed program. Documented provenance, immutable audit trails, and contractual remediation SLAs do.
What Curate & Govern Looks Like in Practice
A Curate & Govern posture has three operational requirements.
Control what enters. Open source software components should be drawn from a vetted, policy-governed source, not directly from public registries. When AI coding assistants and developers pull dependencies, they should be pulling from a curated catalog where every component has been scanned for CVEs and malware, and built from source in a verified environment. Risky components never reach the developer. The governance is embedded at the point of consumption.
Verify how it was built. Pre-built binaries require blind trust in the environment that produced them. When that environment is compromised, as Trivy’s was, everything downstream inherits that compromise. Building open source software from source within SLSA Level 3 compliant infrastructure provides cryptographic proof of origin for every artifact. You are not trusting the label. You are verifying what’s inside.
Own the remediation cycle. Detection without remediation is a backlog. The industry average time to remediate a critical CVE runs upward of 60 days. A Curate & Govern posture closes that gap with contractual SLAs: 5 business days for critical CVEs, with continuous monitoring that identifies new vulnerabilities and applies community-approved fixes before they become incidents. Your team reviews the outcome, not the process.
Scan & Pray Still Has a Role
To be direct: Scan & Pray is not obsolete. Scanners catch what slips through, flag newly discovered CVEs against your existing inventory, and provide a necessary layer of defense in depth. In a mature security posture, you want both.
The problem is that Scan & Pray has been treated as sufficient when it is not. It was never designed to prevent the class of attack that TeamPCP executed. It cannot govern the rate at which AI is introducing unvetted dependencies. It cannot provide the provenance documentation that regulators now require.
Curate & Govern is what makes Scan & Pray valuable rather than merely necessary. When you control what enters your environment and verify how it was built, your scanner’s signal-to-noise ratio improves dramatically. The alerts that fire are the ones worth acting on.
The Posture Your Current Model Wasn’t Built For
TeamPCP said publicly they are not finished. The structural vulnerabilities they exploited, blind trust in pre-built binaries, cascading CI credential exposure, and transitive dependency blindness, are not unique to the tools they targeted. They are endemic to how most organizations consume open source software today.
Every security leader right now faces the same question: is your posture built for the speed at which this class of attack now moves, or is it still trying to catch up to it?
Scan & Pray was the right answer for a different era. Curate & Govern is the posture the current one requires.
ActiveState was built around this model. Our library of 79 million open source software components, built from source within SLSA Level 3 infrastructure, with full provenance, continuous remediation, and native integration into your existing CI/CD pipelines and AI coding tools, is the structural answer to a structural problem. If you want to understand where your current posture has gaps, our free OSS Risk Assessment maps your actual open source software risk surface and builds a mitigation plan with contractual remediation SLAs your team can act on. It is a working engagement, not a demo.
Frequently Asked Questions
By the time you’re scanning, it’s already too late. The TeamPCP attacks made this concrete: malicious code was injected at the source into trusted, verified packages, so the binary arriving in your environment looked completely legitimate. No scanner flagged it at the point of installation because nothing looked wrong. Scanning assesses what has already entered your environment. Against an attack that originates inside a trusted package maintainer’s account or CI pipeline, detection after ingestion is structurally too late. The model was built for a human-scale development pace. AI coding assistants have broken that assumption entirely.
Software composition analysis is a detection discipline. It tells you what open source software is in your environment and whether known vulnerabilities exist in it. Curate & Govern is a governance discipline. It determines what open source software is permitted to enter your environment, enforces that policy at the point of consumption, and ensures every component can be verified by how it was built. SCA operates after ingestion. Curate & Govern operates before it. Both have a role in a mature security program, but only one of them can prevent a compromised package from reaching your developers in the first place.
Most organizations consume open source software as pre-built binaries, which means trusting that the environment that produced those binaries was not compromised. When that environment is compromised, as Trivy’s CI pipeline was in the TeamPCP attack, everything downstream inherits that compromise invisibly. Building from source means compiling open source software components directly from their original code within a controlled, cryptographically verified build environment. It provides proof of how every artifact was constructed, eliminates inherited risk from upstream build systems, and produces the immutable provenance that regulators and auditors now require.
Transitive dependencies are the packages your direct dependencies depend on. When you install one package, you often inherit dozens of additional packages you never explicitly chose. The LiteLLM compromise in the TeamPCP attack reached developer machines as a transitive dependency of a Cursor MCP plugin. Nobody on those teams chose to install it. Without full visibility into transitive and OS-level dependencies, your actual attack surface is significantly larger than your known dependency list, and your security posture only covers the portion you can see.
No. Curate & Govern is a posture, not a replacement stack. Your existing scanners, CI/CD pipelines, and artifact repositories remain in place. What changes is what feeds them. When the components entering your environment are drawn from a vetted, built-from-source catalog rather than directly from public registries, your existing tooling becomes dramatically more effective. Scanner noise drops, remediation cycles shorten, and the alerts that surface are the ones worth acting on. The governance is embedded upstream. Everything downstream benefits.
