Package manager security in 2026 — state of the ecosystem
The npm and PyPI ecosystems have meaningfully improved their security postures over the last three years. 2FA requirements, provenance attestations, improved malware scanning, automated takedowns, and better security reporting tools are all real improvements. But significant gaps remain, and supply chain attack frequency has not decreased.
What's improved
2FA requirements on npm. In 2022, npm began requiring 2FA for the top 100 most-depended-upon packages. In 2023, they expanded this to the top 500. As of 2024, accounts maintaining packages with over 1 million downloads per week are required to use 2FA. This has meaningfully raised the difficulty of account-takeover attacks against the most critical packages.
npm provenance (Sigstore integration). Since May 2023, npm supports build provenance — cryptographic attestations linking a published package to its source code and build environment. Adoption is still limited (fewer than 5% of packages have provenance as of early 2024) but growing, especially for packages published by organizations with security programs.
PyPI malware detection improvements. PyPI has significantly improved its automated malware scanning. New packages are scanned on upload, and known-malicious signatures are blocked. The scanning catches simple obfuscation patterns and obvious payload structures. Sophisticated attacks still evade it.
Faster takedown times. Both npm and PyPI have improved their response times for malicious package reports. The average time from report to takedown has decreased from days to hours for clearly malicious packages. This doesn't help during the zero-day window, but it limits downstream spread.
Trusted Publishing on PyPI. PyPI now supports OpenID Connect-based "Trusted Publishing," which allows publishing from GitHub Actions without storing a long-lived API token. This eliminates the token theft vector for CI publishing — an attacker who compromises the GitHub Actions environment still can't publish to PyPI without a new token issued via OIDC. Adoption is growing among security-conscious maintainers.
What remains broken
Account security is still inconsistent. Despite 2FA requirements for high-download packages, millions of packages are maintained by accounts with no 2FA. Many of these packages have significant indirect reach — they're dependencies of dependencies of popular tools. An attacker willing to do the work of identifying high-reach packages outside the top 500 has a large target surface.
The zero-day window is an architectural constraint, not a policy failure. No amount of investment in threat database quality can eliminate the window between publication and detection of a novel attack. The window may shrink from hours to tens of minutes, but it won't reach zero. The only defense against the zero-day window is preventive verification — checking whether a package has accumulated enough community trust before allowing installation.
Typosquatting is unsolved. PyPI has an active typosquatting program that registers common typos of popular packages. npm has similar efforts. But the attack surface is enormous — any misspelling, transposition, or character substitution is a potential typosquat. Systematic prevention requires comparing every install request against a list of legitimate packages in real time, which the registries themselves don't do.
Private package ecosystems have no security standard. Organizations running Artifactory, Nexus, or Verdaccio instances typically have no security verification at download time. A malicious package that makes it into a private mirror persists there indefinitely, even after the public registry removes it.
Transitive dependency visibility is still poor. Most developers can enumerate their direct dependencies. Far fewer can enumerate their transitive dependency tree, and fewer still monitor it for changes. A malicious package three levels deep in a dependency tree may go unnoticed for months.
The current attack patterns by frequency (2024–2025)
Based on security reports from npm, PyPI, Checkmarx, Sonatype, and Socket:
| Attack pattern | % of reported incidents | Trend | |---|---|---| | Credential harvesting via install hooks | ~45% | Stable | | Typosquatting | ~25% | Increasing | | Dependency confusion | ~12% | Stable | | Compromised maintainer accounts | ~10% | Decreasing (2FA improvements) | | Build process compromise | ~5% | Increasing | | Malicious updates to legitimate packages | ~3% | Stable |
The decrease in compromised maintainer accounts reflects the impact of npm's 2FA requirements. The increase in build process compromise reflects attackers adapting to the improved account security by targeting CI pipelines instead.
Where Veln fits in 2026
Veln's architecture addresses the threat classes that remain unresolved after the ecosystem's improvements:
- The zero-day window: closed by the cooling gate
- Typosquatting: caught by the Levenshtein-distance check in Tier 1
- Dependency confusion: caught by publisher identity checks and community consensus
- Credential harvesting via install hooks: caught by the canary sandbox
- Obfuscated payloads: caught by Veln Lens
- Targeted attacks with different binaries per user: caught by consensus hash comparison
The ecosystem is getting harder to attack through the front door. Sophisticated attackers are adapting. The preventive verification layer that Veln provides is increasingly the layer that catches what improved registry security doesn't.
The npm and PyPI ecosystems have improved. The attacks are adapting. Veln catches what's left.