seanmarshall

Once you fork it, you are then on the hook for forking every future update and security patch. You can automate a lot of the testing, but its still adding an extra failure point that you are now responsible for.

And if you pin it, then when you inevitably get a CVE for an old version, the upgrade path is harder and more time consuming. And that's when the security teams come knocking to pass their audit.

AI coding agents pull package versions from training data that's months or years stale, and nobody catches it until CI fails. Or production does.

We've been building an enterprise AppSec platform for over a year. As part of that we built a vulnerability database - aggregating 160+ upstream vuln databases, plus external enrichment like EPSS scores and exploit data, plus our own enrichment on top. We also index malware and end-of-life data alongside vulnerabilities in the same data model.

The issue with how companies use vulnerability data is that it's always been a checkpoint after you've already written code. And AI agents make this worse. We wanted to see if we could get this into the development loop within Claude Code - so a human gets immediate feedback, but even better, an agent off doing a task gets feedback before it even gets back to the human.

The plugin checks dependencies the moment a manifest changes. Async, never blocks, no source code leaves your machine. Rather than sending your code out to a scanner to figure out reachability, we feed the right data to the agent so it can determine how a vulnerability affects the codebase itself.

The free tier gives you access to all 160+ aggregated sources without needing to build your own data pipeline or service layer. Paid tiers add our enrichment and proprietary data.

Install: /plugin marketplace add Vulnetix/claude-code-plugin then /plugin install vulnetix@vulnetix-plugins

Plugin docs: https://claude-docs.vdb.vulnetix.com/

There's also a CLI and API access. More details on these at vulnetix.com/vdb

The provenance gap is real, but most developers just rely on their scanning tools to block bad packages - which normally relies on a CVE - and malicious packages don't get CVE numbers.

GHSA and OSV have started tracking them as advisories - but the infrastructure to actually find these in a given system is still lacking. Most tools are still just checking NVD/CVE.

So the attestation signal was there, the malware flag comes later - normally after the malicious version is already pulled - and nothing in the average developer's toolchain is telling them that they got hit.