Why it matters
Modern software inherits risk through dependencies, package registries, build actions and developer tooling. An organization can write secure first-party code and still import a compromised component into a production build.
Google Threat Intelligence Group says the scale of open-source supply-chain activity expanded materially through 2025 and the first half of 2026, including campaigns designed to spread through large dependency ecosystems.
The 1,444% figure refers to identified malicious packages
GTIG cites statistics compiled by the Open Source Security Foundation showing that the number of identified malicious open-source software packages increased 1,444% from 2024 to 2025.
That statistic should be interpreted precisely: it is a count of identified malicious packages in the cited dataset, not a claim that 1,444% more open-source projects became insecure or that every package ecosystem experienced the same rate of growth.
Package ecosystems create asymmetric leverage
A malicious dependency can reach far beyond the repository in which it first appears. GTIG's 2026 reporting includes incidents in which compromised packages had very large direct download populations and also sat underneath thousands of downstream dependencies.
The leverage comes from trust automation: package managers, CI/CD systems and developer workflows are designed to retrieve and execute external code efficiently. Security controls have to govern that automation without making software delivery impossible.
Inventory and SBOMs create the visibility layer
GTIG recommends maintaining a continuous inventory of applications, vendors and dependencies and implementing automated software bills of materials. Those controls provide a map of which versions and packages are actually present when a new compromise is disclosed.
Without that map, incident response starts with discovery rather than containment, increasing the time required to determine whether a malicious package entered a build or production environment.
Cooldowns, isolation and scoped credentials reduce blast radius
A practical defensive stack can include package quarantine or cooldown periods for newly published versions, controlled registries, dependency pinning, isolated CI/CD runners and tightly scoped build credentials. These measures reduce the chance that a newly compromised release is immediately executed with broad privileges.
Build infrastructure should be treated as a privileged production system because it can turn a dependency event into a signed, distributed application artifact.
The RFDELTA takeaway
Software supply-chain security is dependency governance at machine scale. The core controls are visibility, delay where appropriate, isolation, least privilege and a fast way to answer one question after a disclosure: exactly where did this package execute?
Watch the original Signal
The concise video version is designed for discovery; this page preserves the sourcing, caveats and deeper context.
Memorable path: https://rfdelta.com/030
Video transcript
Open-source supply-chain attacks are scaling fast. Google cites OpenSSF data showing identified malicious packages increased one thousand four hundred forty-four percent from 2024 to 2025. Attackers can target repositories, dependencies and developer tooling that organizations automatically trust. The defensive baseline is to inventory dependencies, maintain software bills of materials, quarantine or cool down newly published packages, isolate CI/CD runners and tightly scope build credentials. Your application attack surface includes code your own team never wrote. Follow InfoSec for daily defensive intelligence.
Frequently asked questions
What exactly increased 1,444%?
The cited OpenSSF statistics measure identified malicious open-source software packages from 2024 to 2025. The figure does not mean that all open-source software became 1,444% more dangerous.
Does open source itself create the problem?
No. The risk comes from the scale and automation of dependency ecosystems. Open-source software can be managed safely, but organizations need visibility and controls around what they import and execute.
Which controls provide the most immediate value?
Dependency inventory and SBOMs establish visibility; controlled package intake, isolated build runners and least-privilege build credentials can then reduce execution and blast-radius risk.
Primary sources
Continue exploring RFDELTA
RFDELTA Signals map the hidden systems, technology transitions and operational dependencies underneath fast-moving headlines.