Modern software teams are under pressure to move fast, innovate faster, and deliver continuously. At the same time, attackers are evolving just as quickly, and in many cases, faster than the tools meant to stop them.
For years, Common Vulnerabilities and Exposures (CVEs) and the National Vulnerability Database (NVD) have been the backbone of software security programs. They still play an important role.
But as the threat landscape shifts toward malicious open source, relying on CVEs alone is no longer enough to keep software supply chains safe.
CVEs provide a common language for describing vulnerabilities, which is essential for consistent, automated vulnerability management.
However, the system is struggling to keep pace with the volume, velocity, and complexity of today's threats.
Several trends are converging:
Incomplete coverage: Nearly two-thirds of open source vulnerabilities tracked in NVD lack a basic severity score, leaving security teams guessing about prioritization and risk.
Misleading severity: Inflated ratings create alert fatigue and false positives, while underestimates bury truly critical issues.
Slow updates: The average delay between vulnerability disclosure and NVD scoring is around six weeks — plenty of time for a vulnerability to be actively exploited, automated into attack toolchains, and widely weaponized.
This model works reasonably well for known vulnerabilities reported, triaged, and scored. But it doesn't account for deliberate malware published into public ecosystems, often with no CVE assigned and no NVD entry at all.
It's important to distinguish between vulnerabilities and malware. A vulnerability is an unintentional flaw in legitimate code, while malware is intentionally designed to cause harm and evade detection.
A component with a low-severity vulnerability might be within your organization's risk tolerance, especially with other security measures in place. A malicious package, however, never is.
Once malware enters your environment, the damage can happen quickly:
A developer might download a malicious package just to experiment locally.
A compromised component may never make it into production, but still execute its payload on a developer's machine.
A poisoned dependency can be pulled into multiple applications before anyone realizes something is wrong.
Without a CVE equivalent for intentional malware, waiting for a database update or scheduled software composition analysis (SCA) scan means reacting too late. By then, the component has already entered your organization.
Open source ecosystems like npm, PyPI, NuGet, and Maven Central have become prime targets for attackers. Instead of hunting for a single vulnerable application, adversaries now poison the upstream supply and let dependency resolution do the rest.
There are two common paths into an organization.
Most teams use a repository manager to proxy public repositories. Without additional protections, that proxy will happily cache:
Newly published components from public registries
Compromised packages published through hijacked maintainer accounts
Typosquatted or lookalike packages that mimic popular libraries
If your tooling pulls these components into builds before they're flagged as malicious, they become part of your internal supply chain.
Even with a repository manager, developers can bypass it and download components directly from public sources.
These shadow downloads create several challenges:
No central record of what was downloaded.
No enforcement of organizational policies.
No opportunity to block malicious components at the edge.
The result is a growing gap between what security teams think is in use and what is actually being evaluated and executed on developer machines.
Sonatype Repository Firewall combines real-time analysis with curated security research to help organizations block malware at the point of entry, not just identify it later.
At a high level, it works like this:
New components are continuously monitored across major open source ecosystems.
Each new release is fingerprinted and evaluated using behavioral, contextual, and code-level signals.
Components are quickly classified as malicious, suspicious, or benign.
Policies in Repository Firewall automatically block suspicious or malicious components from being proxied into your repositories.
Sonatype's research team performs deep analysis on suspicious components, enriching the intelligence over time.
Because this process starts as soon as components are published upstream, customers can avoid the exposure window between initial publication and public disclosure.
Instead of discovering malware during a build or later in production, organizations can prevent it from ever being downloaded.
Moving beyond a CVE-only mindset doesn't mean abandoning vulnerability management. It means expanding your strategy to account for intentional malware and real-time threats.
A more modern approach includes:
Protecting proxy repositories: Ensure every component flowing through your repository manager is evaluated against organizational policies and malware intelligence, not just CVE-based vulnerability feeds.
Blocking malware by default: Treat malicious and suspicious components differently from vulnerable ones. Vulnerabilities may be triaged. Malware should be blocked outright.
Reducing shadow downloads: Require developers to use approved repositories wherever possible. Where direct access is needed, apply edge protections that use the same intelligence and policies.
Aligning risk tolerance across teams: Make sure development, security, and operations agree on acceptable risk, what must be blocked, and how exceptions are handled.
Educating teams on process and outcomes: Clear expectations and predictable enforcement help developers understand why certain downloads are blocked and how to request alternatives, without derailing their work.
With these practices, organizations can protect their software supply chain without turning security into a bottleneck.
The software supply chain has become one of the most attractive targets for attackers. As open source adoption grows and malware authors focus on poisoning public ecosystems, CVE-centric strategies by themselves cannot keep pace.
Real-time malware detection and proactive blocking give teams a way to:
Reduce risk from malicious open source packages.
Cut down on false positives and noisy alerts.
Protect developers without slowing them down.
Sonatype Repository Firewall helps teams outpace malware by stopping malicious components before they enter development pipelines — at the repository, at the perimeter, and everywhere in between.
To see how these concepts play out in real attacks and learn how to apply them in your own environment, watch the full "Outpace Malware: Build Faster, Safer Software."