The industry needs a reliable system for reporting and tracking compromised packages if it is to continue sharing software.
Despite having more open source software available than ever, the risk of consuming it has never been higher. Why? Because recent reports of package poisoning demonstrate that scanning source code in a public repo does not guarantee the distributed package is safe.
Since we assume packages are safe, while they demonstrably are not, the software supply ecosystem is subsequently exposed. Build artifacts, packages, pipelines, package distribution points, and installation behaviors are routinely misused maliciously.
The more popular the package is, the faster damage is done. Currently we are witnessing AI tooling subjected to most of the poisoning, and AI agents are compounding the damage so quickly it is safe to say the industry is overwhelmed by package compromise.
What we’ve done won’t get us there
The open source software ecosystem has no official registry of compromised software packages. This means organizations have no credible system by which to trust the code packages they consume. Further, build pipelines, installation behaviors, and package repositories assume safety instead of compromise. Automation and AI agents compound and accelerate the risk at machine speed.
To rise to this new challenge, the open source software ecosystem requires:
- Industry-wide collaboration to report compromised packages using a single source of truth.
- Focused effort to close the security gaps in the ecosystem software supply chain.
- Ecosystem commitment to develop, evangelize, and implement industry best practices.
A culture of getting smarter and doing better is a formidable defense. We can never give up improving security of our source code ecosystem, build pipelines, and package repositories.
Getting started
We have an approximation of what we need. It is hosted by the Open Source Security Foundation (OpenSSF) and is called the Malicious Packages Repository (MPR). It offers a central place and process for defining and reporting malicious packages. What it needs is comprehensive industry participation to make it the de facto standard for tracking compromised packages and remediating them.
The MPR utilizes a machine-friendly file specification called Open Source Vulnerability (OSV) format that uses JSON to automate the submission and collection of reports, as well as to feed scanners. This supports a specific procedure for trusted researchers to feed new data continuously, quickly, and efficiently. Finally, it is maintained by an active working group open to accepting new contributors and improvements.
We need something like OpenSSF MPR that targets poisoned packages to do for them what is being done for source code vulnerabilities through the CVE program. Change starts by acknowledging the state of things, and this was certainly the impetus for establishing the OpenSSF MPR. So, while the work has started, there is much more to do before it becomes as helpful as the CVE database. As an industry, we can and should work together to make our shared software ecosystem more trustworthy.
About the Author
Related Blog Posts
AI App Delivery Top 10: Lack of security and regulatory compliance
AI expands compliance from securing paths and stores to governing runtime behavior—model access, retrieval context, outputs, and agent actions—so controls must move closer to inference.
AI App Delivery Top 10: Insufficient traffic controls
Traditional rate limits and throttles miss the real blast radius. AI workloads fan out across models, vector stores, and services, driving latency spikes, cascading failures, and retries.
Behavior and boundaries: The agentic security shift
Agents create emergent, unbounded sequences where risk accumulates over time. Security must shift from single-request validation to continuous behavioral governance across multi-step, evolving flows.
Agent skills: An emerging open standard
Skills declare intent but don't enforce control. Real security must live at the tool boundary, where agent thoughts become actions and policy can be enforced.
From packets to prompts: Inference adds a new layer to the stack
Inference is not training. It is not experimentation. It is not a data science exercise. Inference is production runtime behavior, and it behaves like an application tier.