2025 Was Quietly Good for Application Security

So much of Application Security is focused on negative things: new attack methods, new vulnerabilities in tools and libraries, new weaknesses in systems and infrastructure our organizations and developers rely on. But a lot good happens too.

2025 had major challenges: from almost losing CVE, to the world’s first NPM worm. But it also had some big wins. Not products, not press releases, not empty promises; real, meaningful changes that made it easier for developers and AppSec teams and software developers to do the right thing — the safe thing — under real-world constraints.

Here’s six of them:

1) Publishing Malicious JavaScript Packages Became Meaningfully Harder

While no one wanted Shai-Hulud, and certainly not two rounds of it!, it was the final straw that pushed big players in the JavaScript and TypeScript ecosystem to make positive changes that make it significantly harder for adversaries to turn trusted npm packages into malware vectors.

The public npm registry made changes that directly reduced risk for maintainers and consumers, and GitHub reinforced and accelerated several of their programs:

Mandatory 2FA for high-impact publishers dramatically increases the effort required to successfully take over a legitimate developer’s account. GitHub has had mandatory 2FA for a while, and npm finally joined them; no more one-click phishing attacks targeting publishers of critical libraries.
Trusted publishing using short-lived tokens replacing broad “forever credentials”. The npm registry rolled out Trusted Publishing in mid-2025, an approach first adopted by the Python Package Index (PyPI) which allows systems like CI/CD platform to use OIDC authentication to get very short-lived and narrowly-scoped tokens to publish packages. This makes it harder for attackers to harvest npm credentials, since anything they grab becomes useless very quickly. GitHub Actions supported this quickly, but after Shai-Hulud has pushed harder to get organizations to adopt this safer pathway.
Removal of legacy token creation paths that attackers routinely abused, specifically the creation of so-called “classic” access tokens that allowed access to all repositories under a publisher’s account. In December 2025, npm revoked all remaining classic tokens, meaning safer default behavior: tokens that have specific access and are only valid for 7 days (though they can be given broader scopes and lifetimes of up to 90 days). This reduces the threat posed by a leaked or stolen token by limiting its lifetime and only allowing access to one package.
Faster coordinated takedowns when malicious campaigns were confirmed. GitHub and npm have established paths to work together to respond quickly to malware campaigns, and the defender community as a whole shifted toward working more in the open.

Taken together, these changes make life significantly harder for attackers while requiring little from developers and AppSec teams.

Get Checkmarx Zero in your Inbox

2) Developer Tooling Got Safer by Default

With Microsoft’s Visual Studio Code and GitHub’s code-management and Actions CI/CD system leading the way, 2025 saw quiet improvements to default configurations designed to protect developers from supply-chain attacks and other threats targeted at them. For just a few examples:

Tighter execution boundaries for plugins and extensions. Platforms like Microsoft’s Visual Studio Code responded to “zero-click” classes of attack by requiring more extensions to be explicitly activated (rather than activating automatically after installation), making it harder for developers to accidentally bypass or disable Workspace Trust controls, and increasing scrutiny of easy-to-exploit behaviors like background execution without user interaction.
Reduced default permissions for third-party integrations. We saw an increased emphasis on safe defaults and least-privilege for plugins and other third-party integrations, such as GitHub’s tightening of default token permissions used in Actions. Their decision to reduce the default scope and lifetime of per-job tokens significantly raised the level of effort required for common attacks with a minimum of disruption to DevOps and developer teams.
Better isolation of build and test contexts from developer credentials. With several providers working closely together to ensure that OIDC and other short-lived, tightly scoped credentials are the default and recommended pathway for cross-service integration, it became the straightforward default to separate build and test access from developer access to systems. This allows developers to maintain velocity by ensuring that build and test operations reliably function, while protecting organizations when developer accounts or workstations are compromised.

Safer defaults and secure paved paths make the secure way the easy way, and allow organizations to be more secure and resilient without risking developer productivity. Not annoying developers is a great outcome for any appsec improvement!

3) GitHub Made Malicious Pull Requests Easier to Defend Against

Since the introduction of pull_request_target events in GitHub Actions, GitHub has been warning developers and DevOps teams that their convenience comes with some risk. For example, it’s easy to configure this class of event in a way that leads to “pwn requests”: malicious pull requests that end up accessing important secrets and passing them off to attackers.

But GitHub didn’t just throw up their hands and say “this is on you to use safely”: they added new constraints in December 2025 to limit external PRs’ access to potentially insecure workflow files and completely close off attacks that relied on providing untrusted branch names.

This was a great example of an organization balancing developer and contributor needs for automation and velocity against the value of safe defaults and simplified ability to audit configurations and defend the open-source ecosystem.

4) “Supply Chain Risk” Became a Shared Language

Not all improvements are technical achievements; application security is a socio-technical system, after all, and changes that help people communicate across boundaries between development, security, operations, and leadership are an important part of the equation.

So it might seem weird to be excited that a new term rose to prominence, but it really did make a difference. Because through work from researchers, industry groups like OWASP, and AppSec leaders across organizations, we finally found a way to help developers and operations teams understand the need for fundamental change in the software supply chain.

It represents a shift in software delivery culture that understands the value of protecting the supply chain. Not as just “oh, look another security alert to put on the pile”, but rather helping to:

Shift patching and related activities to being seen as architectural and process essentials, not failures to blame on someone
Justify SDLC improvements meant to prevent issues and decrease remediation effort, like proactive defense against malicious open-source packages
Improve alignment on supply chain controls and defenses among developers, operations, security, and other aspects of software delivery

It’s a small step, but a significant one that marks significant progress toward a safer software supply chain and less pressure on developers.

5) Security Researchers Collaborated More

Another example of a “soft” improvement I’m excited about is a shift in the research community, especially around the response to critical vulnerabilities and impactful malware campaigns.

In 2025, we saw:

Less competition for headlines, instead favoring coordinated disclosure and an emphasis on keeping the community safe.
Collaboration across impacted orgs during events like Shai-Hulud, with researchers encouraging and enabling information-sharing and response rather than trying to control the conversation
More credit-sharing and boosting of signal, with researchers helping to highlight others’ work even as they expand upon it

For defenders, this meant less time spent trying to figure out what’s happening and what to do, and far fewer “panic-driven” incident response behaviors. For researchers, it reinforced trust among the community and between researchers, platform operators, and defenders: trust that’s critical to rapid mitigation and remediation of issues outside traditional processes.

6) The Security Community Reduced Its Reliance on a Single Government

April 2025 brought a close call for MITRE’s CVE program, where a lack of clarity about whether US Federal funding for the CVE and related programs caused a bit of a panic about the programs’ future. But the community’s response demonstrates the resilience among security leaders and practitioners:

Founding of the CVE Foundation, a group committed to diversifying funding sources and establishing clearer and more-independent governance for the CVE program
Increased attention and commitment to the EUVD, an alternative to the US NVD that serves (among other things) as a “backup plan” for organizations that rely heavily on the CVE system
Greater support for OSV, a vulnerability reporting system focused on the open-source ecosystem, anda. Collaboration between Google and the OpenSSF provides independence from MITRE’s CVE program.

The response was a great reminder that the application security community isn’t reliant on just one dominant source, but has the tools and foresight to make sure the world stays safe even under challenging circumstances.

Why This Matters

A lot of our work at Checkmarx Zero focuses on the bad things that are happening. It’s important to let people know when there are new attacks, new risks to worry about, malware campaigns targeting developers, and so on. But it’s just as important to remember that it’s not a losing battle. We and our colleagues across the application security community and in the broader security world do a lot of good. Even when it seems like the attackers must surely be winning — perhaps especially when it seems that way — we must remember that thousands of us show up every day and make the world a safer place.