Threat actors exploited 768 unique vulnerabilities in the wild in 2024, marking a 20% increase over the previous year, recent research from VulnCheck shows. That sharp rise in exploit activity involving old, new, and zero-day bugs has made it clear that vulnerability patching cannot be the sole mechanism for protecting against attacks and data breaches.
Nearly a quarter of those CVEs were exploited on or before their public disclosure, meaning organizations had little or no opportunity to patch the vulnerabilities before attackers began exploiting them. Making matters worse, last year saw a 40% increase in total vulnerability disclosures, to 39,000, up from 28,000 in 2023, a new report from GuidePoint Security disclosed. That's an average of 378 vulnerability disclosures every day.
Resources such as the National Institute of Standards and Technology's National Vulnerability Database (NVD) and the U.S. Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerability (KEV) catalog help application security (AppSec) teams identify, assess, and prioritize the most critical of these vulnerabilities, especially as they pertain to their specific environments. However, their usefulness is less than comprehensive.
In 2024, CISA's KEV listed just 186 publicly known-exploited vulnerabilities, and all of those were specifically relevant to civilian federal agencies. That left enterprises on their own to try to get more context around all the other vulnerabilities that attackers exploited last year. VulnCheck counted more than 100 entities that were first to report a CVE in 2024, meaning it was easy for organizations to miss vulnerability disclosures if they weren't looking at the right sources.
Meanwhile, a decision by NIST to scale back its contributions to the NVD severely hampered the ability of many organizations to get the critical contextual information around vulnerabilities they need to prioritize remediation efforts. At one point last year, there were over 3,000 vulnerabilities in the NVD lacking information about their severity, the platforms they affected, and the underlying software weaknesses. Though the NVD backlog has eased considerably, there are still some 154 known exploited CVEs that currently have no contextual information around them, VulnCheck said.
Making vulnerability remediation your sole defense in such an environment is dangerous and misguided, said Gareth Lindahl-Wise, CISO at Ontinue.
"Patching everything is a race to the bottom as far as security resources go. Too much, too fast, too hard."
—Gareth Lindahl-Wise
These reports — and the rise of artificial intelligence-derived coding and software supply chain attacks — demonstrate that the time has come for organizations to look beyond just vulnerability mitigation when it comes to shoring up their AppSec. Here are three ways to modernize your strategy.
[ Get our Essential Guide: Software Supply Chain Security for Dummies ]
1. Reduce your software footprint
Software complexity is on the rise, and that highlights why reducing your overall software footprint is key, Lindahl-Wise said.
"Remove the programs, apps, binaries, and libraries you don’t use or need. It is exceptionally common to find unnecessary code lurking on endpoints. If it isn’t there, you don’t have to patch it."
—Gareth Lindahl-Wise
Moving away from legacy platforms as a long-term strategy is also something to consider, even if it might not be easy. Legacy platforms often lag in patching and support and therefore are often in a vulnerable state, Lindahl-Wise said.
Attackers know that legacy platforms are an easy target. Last year, many of the vulnerabilities that adversaries exploited were old ones. Many of these remained unpatched in production environments due to resource constraints, lack of awareness, or the complexity of patching legacy systems, GuidePoint said in its report. "If you are left with legacy platforms or known historically broken software, do all you can to segregate them from sources of threats or at least from the rest of your environment to minimize the impact radius of a successful exploitation," Lindahl-Wise said.
2. Introduce chaos engineering
AppSec teams should also consider approaches such as chaos engineering that fundamentally shift AppSec testing from the theoretical to the practical, said Jason Soroko, a senior fellow at Sectigo. By deliberately introducing controlled failures and attack scenarios, AppSec team teams can get an idea of how their applications actually behave under adverse conditions, he said.
The same is true of machine learning–based anomaly detection, Soroko said. ML-based tools can help AppSec teams quickly analyze large amounts of data to spot anomalous and unusual behavior in real time. Unlike traditional rule-based security measures, ML tools can adapt to evolving threats, meaning they are better equipped to detect zero-day threats and subtle deviations in behavior that are otherwise easy to miss.
"Techniques like chaos engineering for security testing, which stress-test defenses in unpredictable ways, and machine learning–driven anomaly detection offer fresh layers of defense. These measures limit lateral movement and flag subtle shifts in network behavior, tightening security even when patching lags behind threat emergence."
—Jason Soroko
3. Harden your development environment
Trey Ford, chief information security officer at Bugcrowd, suggested that organizations should harden their application development environments against attacks by leveraging frameworks such as the Center for Internet Security's CIS Level 1 and Level 2 security benchmarks. CIS Level 1 controls focus on measures that provide baseline protection against threats without having a significant impact on system functionality. The controls cover areas such as ensuring secure configurations, limiting user privileges, and hardening systems — all of which can go a long way toward bolstering application security, he said.
CIS Level 2 controls offer relatively more advanced security measures such as enhanced access control, continuous monitoring, and anomaly detection. It's typically used by larger organizations to bolster security and often to meet regulatory requirements.
"Hardening environments — not just patching, but moving toward CIS levels 1 and 2 — causes difficulty for commodity malware and offensive tool sets. Doing this drives up the cost, complexity, and risk for attackers and creates additional noise in compromised environments, helping defenders identify malicious activity."
—Trey Ford
After hardening, every investment tied to driving up the cost of lateral movement is important, Ford said. This includes measures such as multifactor authentication (MFA), privileged account management, and zero-trust network access. "Finally, if your organization has not removed local admin from the user fleet, now is the time," he said.
The most effective AppSec controls ultimately combine microsegmentation with strong authentication and adaptive access and behavioral analytics, Sectigo's Soroko said. Microsegmentation can help enhance AppSec by dividing a network into isolated segments, restricting access to those segments, which can prevent attackers from moving laterally. Many companies use the approach to enforce zero-trust polices to ensure that only authorized apps and users can communicate.
"The term 'zero trust' is often used, but it’s the principles behind it that are important."
—Jason Soroko
Patching vulnerabilities is ultimately a reactive process that is based on when vulnerabilities are discovered and disclosed, said Ken Dunham, cyberthreat director at the Qualys threat research unit. Security controls to reduce risk around vulnerability management are much broader — and more complex to solve — when considering hybrid architectures of legacy, cloud, mobile, and third parties, he said.
Organizations should implement controls at multiple layers and deploy configurations that best reduce risk within each environment Dunham said. For a well-managed and mature AppSec program, it’s essential to leverage a variety of re-architected solutions for both isolation and segmentation, he said.
"Understanding your personal attack surface mapped against high-value assets — and how to best reduce risk to the left of boom — is a continual challenge for every organization in 2025."
—Ken Dunham
Supply chain risk highlights need to go beyond vulnerabilities
Jeremy Long, a principal engineer at ServiceNow and founder and project lead of the OWASP Dependency Check Program, said that from an attacker’s perspective, targeting the software development supply chain makes most sense given the large attack surface and evolving complexity with today's software.
In a recent Black Hat conference talk, "Reflections on Trust in the Software Supply Chain," Long explained how the threat of software supply chain attacks has changed, making organizations’ current defenses inadequate. This gap in security coverage is the result of changes in both the intention and methodology of software supply chain attacks, Long explained. This comes down to the difference between the two ways supply chain threats can be described: vulnerable and malicious. Tools that organizations are currently using to secure their supply chains, including software composition analysis (SCA) and static application security testing (SAST), pinpoint only the threats that can be classed as vulnerable.
The tracking of CVEs is an example of a software supply chain security protocol that centers on vulnerable rather than malicious threats, which are intentional campaigns by threat actors meant to cause harm. Long stressed that while these vulnerabilities at times have the potential to cause damage, they are not the major threat to supply chains.
“I do think that in a lot of these cases, some of these vulnerabilities might be overhyped.”
—Jeremy Long
Long said that early software supply chain attacks relied on vulnerable threats that could be detected and patched, but more recent supply chain attacks, such as SolarWinds and 3CX, were catastrophic not because of vulnerabilities, but because of malicious threats such as malware insertion or the abuse of secrets leaks.
Focusing only on finding vulnerable threats, which tools such as SCA and SAST can spot, will leave a gap in organizations’ defenses against supply chain attacks, Long said. Organizations that want to properly defend against today's software supply chain attacks will have to adopt tooling and measures that detect and mitigate malicious threats, he said.
Long recommends modern tooling such as binary analysis, which can detect threats such as malicious build-time dependencies. This type of protocol can provide a comparison of build versions, showcasing anomalies that traditional testing misses and that further analysis may deem malicious.
Recent federal guidance on software supply chain security from the Enduring Security Framework recommends shifting from legacy AST to binary analysis and reproducible builds to tackle supply chain threats.
