PYYUPSK

I have watched the security landscape for years, mostly from the sidelines. I patched dependencies, ran npm audit, and hoped for the best. The numbers from 2025 made me pay closer attention. Security researchers logged 48,185 CVEs (common vulnerabilities and exposures) in one year, an average of 132 new vulnerabilities every day.

One number stands out: 28% of exploits now happen within 24 hours of disclosure.

There is no time to move slowly anymore.

The Numbers That Changed My Perspective

Three major reports came out recently. Together, they show a clear picture.

The Bad News First

According to Deepstrike’s 2025 analysis:

Metric	Number
CVEs in H1 2025	21,500+
Daily average	~133 new vulnerabilities
High/Critical severity	38%
Year-end projection	~50,000 CVEs
Exploited within 24 hours	28%

The Linux kernel alone had about 2,879 CVEs. The WordPress ecosystem had more than 6,700 vulnerabilities. Plugins caused 90% of those, not WordPress itself.

This matters because many client projects run on WordPress. Every “trusted” plugin installed without review adds to the attack surface.

The XSS Problem That Will Not Go Away

Over 8,000 CVEs in 2025 were XSS vulnerabilities, short for cross-site scripting. Developers have known how to prevent this vulnerability class for decades.

The Stack’s analysis names the real cause: WordPress plugins and legacy code built without security review. These are the same bugs from 2005, now shipped faster and at a larger scale.

The 1000x Improvement That Made Me Rethink Everything

While CVE numbers keep climbing, Google’s Android team published a notable result. The team found a 1000 times reduction in memory safety vulnerability density when comparing Rust to C and C++.

This is not 10 times fewer or 100 times fewer. It is a thousand times fewer vulnerabilities per million lines of code.

Language	Vulnerabilities per MLOC
C/C++	~1,000
Rust	~0.2

This result is not theoretical. Android now runs about 5 million lines of Rust in production. The platform has expanded Rust into the Linux kernel, where Android 6.12 ships the first production Rust driver. Rust also now runs in firmware and in apps such as Chromium’s parsers and the MLS messaging protocol.

The Speed Myth Is Dead

The common assumption has always been that safety costs speed. You either ship fast or ship secure, but not both.

Google’s DORA metrics say otherwise:

• Rust changes needed 20% fewer revisions than C++ changes.
• Code review ran 25% faster for Rust changes.
• Rust changes had a 4 times lower rollback rate on medium and large changes.

The safer path is now also the faster one. This is no longer a tradeoff. It is simply better.

The Near-Miss That Proves Defense-in-Depth Works

Google almost shipped its first Rust memory safety vulnerability, a buffer overflow in CrabbyAVIF. The bug passed code review and testing.

But the bug never became exploitable, because the Scudo hardened memory allocator, a tool that manages memory safely, caught the bug before it caused any damage.

This is what layered security looks like in practice. Rust catches most issues at compile time. When an issue slips through, hardened allocators act as a safety net. The goal is not perfection. The goal is building systems that fail safely.

What This Means for JavaScript Developers

This Rust story can feel distant if you ship Next.js apps instead of kernel drivers.

That reaction makes sense. But these patterns apply everywhere:

1. Memory Safety Is Becoming Table Stakes

WebAssembly is bringing Rust to the browser. Node.js gains more Rust-based tooling every day, including SWC, Biome, and the wider Vite ecosystem. The line between systems programming and web development keeps blurring.

I have already written about why I prefer Rust-based tools like Biome over their JavaScript equivalents. Speed matters, but reliability matters too. I trust tools that do not crash.

2. The Patch Window Is Shrinking

With 28% of exploits happening within 24 hours, dependabot is not optional. It is critical infrastructure. The weekly dependency review you keep postponing is a security liability.

My current approach:

• I automate dependency updates through Renovate.
• I review breaking-change pull requests the same day.
• I merge security patches immediately, without waiting for the next sprint.

3. The Plugin Problem Is Universal

The WordPress plugin attack surface is not unique to PHP. Every package you install from npm is a trust decision. Every bun add command accepts code from strangers.

I have become more deliberate about dependencies:

• I keep fewer dependencies overall.
• I prefer packages with active maintenance and a strong security record.
• I read the code, or at least the README, before I install a package.

The Elephant in the Room: AI-Accelerated Exploits

One line from The Stack’s analysis stood out to me: LLMs (large language models) now speed up exploit development using public patch information.

When a CVE ships with a fix, attackers can now use AI to reverse-engineer the vulnerability from the patch diff. The gap between a patch becoming available and an exploit appearing in the wild keeps shrinking.

This changes the situation. Teams can no longer patch eventually. Teams must patch immediately, or they must accept the risk.

What I Am Actually Doing About This

After reading all this, here is my updated security approach:

For New Projects

• I use TypeScript strict mode everywhere. Type safety catches bugs before runtime.
• I prefer Rust-based tooling when it is available, such as Biome, SWC, and Turbo.
• I keep the attack surface small, with fewer dependencies and more deliberate choices.
• I automate updates and merge security patches the same day.

For Existing Projects

• I audit the dependency tree to see what actually runs in production.
• I remove unused packages. If a package is not used, it does not belong in the project.
• I enable automated security scanning, through tools like GitHub Dependabot or Snyk.
• I review plugin and extension choices carefully, especially for CMS-based projects.

For the Team

• The team includes security review in the pull request process, instead of treating it as a separate gate.
• The team shares a common understanding of basic vulnerabilities, such as XSS and SQL injection.
• The team keeps an incident response plan ready for when something gets through, since something eventually will.

The Takeaway

Two trends define the 2025 security landscape. Vulnerability counts keep growing, and memory-safe languages now make a 1000 times difference. The tools keep improving.

Google did not wait for a catastrophic Android vulnerability before investing in Rust. The team saw the trend and made a choice.

Treat security as a developer experience problem. Safer tools can also be faster tools. Security reviews belong in the normal shipping flow, not in a separate gate. Memory-safe languages are no longer only for systems programmers. They are becoming the foundation that everything else builds on.

The 1000 times improvement is real, and the exploit windows keep shrinking. The only question left is whether we adapt fast enough.