Malicious open source packages grew 73% year over year in 2025, and AI coding assistants are now pulling dependencies into codebases faster than any human review process can keep pace with. Every one of those packages eventually shows up somewhere: in a pull request, a build log, or or a Trivy scan. Trivy is the open source security scanner maintained by Aqua Security. 

Trivy does exactly what it is built to do: scan the artifacts in your pipeline and identify known vulnerabilities and other risks. What it does not do is govern where those components originated or how they were built before reaching the scan. If nobody vetted a package on the way in, whether it was chosen by a developer or resolved by an AI agent, Trivy evaluates the artifact it receives. That is not a gap in Trivy. It is an upstream governance gap that ActiveState and Trivy can help address together. 

Here's what changed, and what it means for your CVE backlog.

Key Takeaways

• Malicious open source packages grew 73% year over year in 2025, and most of what shows up in a scan was never vetted before it entered the build in the first place.
• AI coding agents are increasingly the ones pulling those packages. When an agent's dependency request resolves against the ActiveState Curated Catalog instead of a public registry, the vulnerability never enters the build Trivy eventually scans.
• The average mean time to remediate a high or critical severity vulnerability was 54.8 days in 2025, which means most flagged vulnerabilities sit exposed for weeks before anyone acts on them.
• ActiveState joined Trivy Partner Connect in November 2025 and publishes a public VEX repository for Trivy. When Trivy is configured to consume ActiveState’s VEX data, it can apply ActiveState’s vulnerability assessments to the scan and attribute that context to ActiveState. 
• Trivy recognizes an ActiveState image automatically and reads the SBOM built into it. ActiveState's exploitability assessments on top of that takes the one step above: pointing Trivy at the VEX repository. Once that's set, findings ActiveState has already ruled out arrive marked suppressed and attributed, instead of as raw, unqualified CVE IDs.
• The result is the same trusted scanner your team already runs, working against a cleaner input. A meaningful share of what would normally show up as a fresh, unqualified alert has already been fixed upstream, and what remains arrives with context a bare CVSS score doesn't give you.

Most of what a scan finds was never vetted before it got there

Every year, the open source ecosystem gets bigger, faster, and more automated. AI coding assistants now generate dependency requests at a volume no manual review process was built to absorb, which is a large part of why  malicious packages grew 73% year over year in 2025. Trivy has gotten very good at telling you what's in your pipeline and what's known to be vulnerable about it. Telling you which of those findings is actually worth an engineer's afternoon is a different job, one that depends entirely on what happened before the component reached the scan, and increasingly, on who or what pulled it in.

That's a real part of why the average time to remediate a high or critical severity vulnerability still sits at 54.8 days. It isn't that nobody's looking. It's that everybody's looking at the same unsorted list of findings, with no reliable way to separate what's already been handled from what genuinely needs attention today.

ActiveState and Trivy solve two different problems in the same software supply chain

Open source components make up the bulk of most codebases, and the tools that carry that code the rest of the way into production make up the rest of the chain. ActiveState and Trivy sit at two different, connected points along it.

ActiveState governs components before they ever enter a build: built from source, remediated, and documented. Trivy scans what's already in the pipeline, checking it against known vulnerabilities as it moves toward production. Neither one does the other’s job. Instead, their capabilities are complementary: ActiveState governs and remediates components upstream, while Trivy independently scans the resulting artifacts. 

If your team's biggest complaint about vulnerability management is alert fatigue, the fix isn't asking Trivy to do less. It's giving Trivy less unvetted material to have an opinion about in the first place. That's the actual mechanism behind why ActiveState and Trivy work better together than either does alone, and it matters just as much when the thing doing the pulling is an AI agent instead of a person.

How the integration actually works

Picture the same open source component moving through two different paths.

Without this connection: A package enters your environment straight from a public registry. Nobody built it from a verified source, nobody remediated it in advance, and nobody attached provenance data to it. Trivy scans it and generates a finding with whatever CVSS data is publicly available. But that finding is only as informative as the package that produced it. With no upstream context attached, your team is left figuring out whether this is a five-alarm exposure or a low-priority CVE a dozen other tools have already flagged.

With ActiveState upstream of Trivy: The image includes an SBOM, which Trivy can use during scanning. ActiveState also provides VEX data containing its assessments of applicable vulnerabilities. When Trivy is configured to consume that VEX data through one of its supported VEX methods, it can filter findings according to the status and justification supplied by ActiveState. Vulnerabilities ActiveState has remediated are handled differently: the updated package version is reflected in the artifact, and Trivy’s standard version-matching logic determines whether the vulnerability remains applicable. 

The same logic holds when an AI agent is doing the pulling. AI coding agents resolve dependency requests the same way a developer typing an install command does, just faster and with less judgment about whether a given package is actively maintained or safe. Left alone, that request goes to the public registry and lands on the first path above. Point the agent's request at the ActiveState Curated Catalog instead, and it resolves to the same governed, already-remediated version a developer would get. The vulnerability doesn't enter the build in the first place, so it's never a Trivy finding to begin with. The velocity AI provides doesn't have to come with a matching increase in unvetted risk.

ActiveState and Trivy each do their job better because of the other. ActiveState remediates and documents a component before it ever reaches a scan, regardless of who or what requested it. Trivy scans it with that documentation attached instead of starting from zero. Two complementary capabilities operating at different points in the software supply chain, so teams receive more useful context instead of another unqualified finding. 

What changes for security and engineering teams

For security leaders, this means fewer low-value CVE alerts competing for attention against the ones that actually carry exposure, and cleaner advisory context on what's left. For engineering teams, it means fewer late-sprint fire drills over CVEs that, in a lot of cases, were already remediated somewhere in the pipeline before anyone had to open a ticket, including CVEs introduced by an AI agent nobody explicitly reviewed.

Neither ActiveState nor Trivy is trying to replace the other's job here. ActiveState governs and remediates open source components upstream, while Trivy scans artifacts for vulnerabilities and other risks. The connection brings ActiveState’s governance context into a scanning workflow teams may already use. 

The market is starting to recognize both halves of this as necessary. ActiveState's 2026 Gartner Magic Quadrant placement as a Niche Player isn't the point of this partnership, but it reflects a market that increasingly expects governance at the source and scanning in the pipeline to work together, not stand in for each other.

Start with what's already feeding your Trivy scans

If your team’s CVE backlog keeps growing, a Trivy configuration change alone will not address the upstream source of the problem.  It's upstream, in whether the components entering your builds, however they got there, were vetted and remediated before they ever became your problem.

Talk to your ActiveState team about what's currently feeding your Trivy scans, and ask the harder question: how much of what's in that backlog would never have shown up at all if it had come from a governed source?

Rebecca Banks is Senior Product Marketing Manager at ActiveState, where she leads go-to-market strategy for software supply chain security. She is currently a contributor to the Linux Foundation and OpenSSF 2026 AI Security Study on global AI security maturity for enterprises and critical infrastructure organizations.