Managing Application Security Vulnerabilities: Moving Beyond the CVE Backlog

Application security vulnerabilities are piling up faster than most teams can triage them. More than 48,000 CVEs were published in 2025 alone, a 20.6 percent jump on top of 2024’s already-record 40,000 (CVE.org). Underneath that number sits a far larger volume of scanner findings: SAST rules firing across millions of lines of code, DAST results from every environment, SCA alerts from every transitive dependency in your package manifests. If your AppSec program is still triaging by CVSS score alone, you’re already behind.

CVSS tells you how bad a vulnerability could be in the abstract. It doesn’t tell you whether it matters to your environment. Closing that gap and reducing your 240-day mean time to remediation to single digits requires unifying your scanner output, adding business context, and automating the handoff to engineering.

The Volume and Variety Problem

Each scanner produces its own format, its own severity scale, and its own notion of what counts as a finding. The same vulnerability gets reported three different ways by three different tools. A single library upgrade might trigger dozens of related CVEs across your codebase.

The result is a reconciliation tax. AppSec engineers spend hours deduplicating findings, normalizing severities, and mapping scanner output to something a developer can act on. By the time the ticket reaches the engineering team, the context is lost or stale. Developers see a wall of critical vulnerabilities with no way to distinguish real risk from noise.

Why CVSS Scores Aren’t Enough

A CVSS 9.8 on a library that isn’t reachable from any external-facing service is far less urgent than a CVSS 7.5 on an internet-exposed API handling authentication. Yet most vulnerability dashboards treat the 9.8 as more important.

CVSS isn’t wrong. It’s incomplete. Without business context, asset criticality, exploitability data, and environmental factors, CVSS scores produce prioritization paralysis. Teams either fix everything in CVSS order, which is inefficient, or fix nothing, which is dangerous. We’ve written about this in more detail: Vulnerability Risk Scoring: Why CVSS Alone Isn’t Enough.

Research on EPSS and CISA KEV data consistently shows that roughly 3% of vulnerabilities account for 80% of actual exploitation activity (ArmorCode). If you’re remediating by CVSS alone, you’re spending the majority of your effort on the 97% that won’t be exploited.

Key Categories of Application Security Vulnerabilities

To prioritize effectively, you need to understand what types of vulnerabilities your scanners are surfacing and where they come from.

• Code-level flaws, caught by SAST (static analysis): broken access control, SQL injection, XSS, hardcoded secrets, insecure deserialization.
• Runtime flaws, caught by DAST (dynamic testing): broken authentication, missing authorization checks, exposed debug endpoints.
• Open source and third-party risk, caught by SCA (composition analysis): vulnerable dependencies, transitive package risk, reachability gaps.
• API and cloud misconfigurations, caught by CSPM and API scanners: misconfigured S3 buckets, overly permissive IAM roles, unauthenticated endpoints.

Code-Level Flaws (SAST & DAST Findings)

Code-level flaws are the most direct path to exploitation. They’re also the most context-dependent. A SQL injection in an internal admin panel behind SSO is a different risk profile than the same flaw in a public-facing signup form. Insecure deserialization is a particular concern here, since it can lead to remote code execution when unvalidated data is processed.

Open Source and Third-Party Risks (SCA Findings)

Modern applications pull in hundreds of third-party libraries, each with its own transitive dependency tree. SCA findings dominate by volume: when a new high-profile CVE drops, SCA tools flag it across every project that uses the affected library. The real challenge is reachability. Is the vulnerable function actually called by your code? Most SCA tools can’t answer that question. ArmorCode’s Context Risk Graph correlates SCA findings with runtime and code-path data to determine whether a vulnerability is reachable in practice.

API and Cloud Misconfigurations

Misconfigured S3 buckets, overly permissive IAM roles, unauthenticated API endpoints, and missing rate limits are all vulnerabilities that scanners are just starting to surface effectively. These don’t always map cleanly to a CVE, but they represent real exposure. When CSPM and API scanner findings sit siloed from SAST, DAST, and SCA results, teams lose visibility into which misconfigurations sit adjacent to exploitable code, which is exactly the adjacency attackers look for.

Shifting from Vulnerability Management to Exposure Management

Traditional vulnerability management asks: what are my vulnerabilities? Exposure management asks a better question: what are my actual exploitable risks, and what happens to the business if they’re exploited?

This shift is at the heart of Continuous Threat Exposure Management (CTEM), the framework Gartner introduced to close the gap between finding vulnerabilities and managing real-world risk. If you’re weighing the two approaches, we compare them directly in CTEM vs. Vulnerability Management: Why It’s Time to Upgrade.

Adding Business Context to Risk

Risk doesn’t exist in a vacuum. A vulnerability’s real severity depends on a handful of factors:

• Asset criticality: is the affected application handling payment data, PII, or other sensitive data?
• Exposure: is the component internet-facing, internal-only, or in a CI/CD build step?
• Exploitability: is there a known exploit in the wild? Is it on CISA’s KEV catalog?
• Reachability: is the vulnerable code path actually executed?
• Environmental controls: are there WAF rules, network segmentation, or compensating controls already reducing exploitability?

This is what ArmorCode’s Context Risk Graph does. It pulls in data from scanners, CMDBs, cloud providers, and runtime tools to build a unified view of risk that reflects your actual environment, not a theoretical one.

Risk-Based Prioritization in Action

Risk-based prioritization replaces CVSS-only triage with a multi-signal approach, where CVSS is one input rather than the whole decision:

• EPSS (Exploit Prediction Scoring System): a data-driven score from FIRST that predicts the probability of a vulnerability being exploited in the wild within 30 days.
• CISA KEV: the Known Exploited Vulnerabilities catalog lists vulnerabilities actively being exploited today. A finding on KEV moves to the top of the queue.
• Business context: asset value, data sensitivity, and blast radius.
• Reachability: whether the vulnerable code is actually reachable from an entry point.

When you layer these signals, the picture changes. A CVSS 9.8 with a low EPSS score and no KEV entry on an internal-only service drops in priority. A CVSS 7.0 on the KEV list, affecting an internet-facing API handling authentication, moves to critical. This is how you find the 3% that matters.

Unifying the Security Ecosystem

You can’t prioritize what you can’t see. Most enterprises run five to fifteen security scanners across SAST, DAST, SCA, secrets scanning, IaC scanning, container scanning, and cloud posture. Each produces its own dashboard, its own severity scale, and its own backlog.

Unified Vulnerability Management (UVM) addresses this by ingesting scanner output in a scanner-agnostic way (ArmorCode). ArmorCode integrates with over 400 security tools out of the box, normalizes findings into a common model, and deduplicates them. The same CVE reported by your SCA tool, your container scanner, and your runtime CSPM appears as a single issue with all three sources attached.

Centralized visibility also matters for detection speed: fragmented logging across tools is a well-documented driver of extended breach dwell time, and consolidating scanner and runtime data closes part of that gap.

Accelerating Remediation and Reducing Friction

Prioritization is half the battle. The other half is getting issues fixed without creating friction between security and engineering teams.

Automating Developer Workflows

The traditional remediation workflow is broken. A security engineer exports findings from a scanner, formats them into a spreadsheet or Jira ticket, assigns it to a developer, and follows up manually. The developer receives a ticket with a CVE ID, a library name, and no context about why it matters or how to fix it.

ArmorCode routes findings directly to the right engineering team based on rules you define. A SCA finding on a Python service goes to that service’s owner. A SAST finding in a specific repository creates a Jira ticket linked to the exact file and line. SLAs are tracked automatically, and escalations happen when SLAs are breached, not when someone remembers to check. We cover the mechanics of this in How to Build an Automated Vulnerability Remediation Workflow.

The key integrations:

• Jira and ticketing systems: auto-create and route tickets with full context
• CI/CD pipelines: block builds on critical findings or surface them as pipeline annotations
• Slack and Teams: notify developers in their workflow, not in a separate security tool
• Git-based remediation: auto-create branches with fix suggestions for dependency upgrades

OWASP updates the Top 10 on a multi-year cycle. The 2025 edition replaced the 2021 list in November 2025, adding a new Software Supply Chain Failures category alongside Mishandling of Exceptional Conditions, and OWASP maintains separate Top 10 lists for APIs and LLMs. The result of tightening the remediation workflow: ArmorCode customers have reduced MTTR from 240 days to 7 days by eliminating manual triage and handoff steps.

The Role of Agentic AI in AppSec

Security teams don’t need another AI assistant. They need AI workers. Anya Agents turn ArmorCode’s AI from a single virtual security champion into a library of specialized AI workers, each built for one security workflow like triage, remediation planning, or CVE assessment. Instead of retyping the same prompts into a public LLM off to the side, engineers invoke a preconfigured agent with a defined context and pre-approved actions, so behavior stays bounded and results stay consistent across users and teams.

What makes this possible is grounding. Every Anya Agent connects to ArmorCode’s Context Risk Graph (findings, assets, supply chain data, threat intel, and platform documentation), using the same 400+ integrations already powering the platform, so it can answer whether your organization is actually exposed, not just define a CVE. This matters more as AI-generated code grows: Cloud Security Alliance research from July 2025 found that 62% of AI-generated code samples contained design flaws or known vulnerabilities, even with current foundational models, so it needs the same scanning as any other first-party code.

Conclusion

The application security backlog isn’t a volume problem you can outrun by hiring more engineers or buying another scanner. It’s a prioritization problem. CVSS alone will always point you at the wrong 97%.

Fixing that requires three things working together: unifying scanner output so you’re looking at one list instead of fifteen, layering in EPSS, KEV, and reachability data so severity reflects actual risk, and automating the handoff to engineering so fixes don’t stall in a ticket queue. Teams that do all three consistently find the 3% of vulnerabilities that matter, and they fix them in days instead of months.

Want to see how ArmorCode can help your team move beyond the CVE backlog? 

Request a demo or take a tour of the platform.

Frequently Asked Questions

What are application security vulnerabilities?

Application security vulnerabilities are weaknesses in software applications that attackers can exploit to compromise confidentiality, integrity, or availability. They include code-level flaws like SQL injection and XSS (found by SAST and DAST), vulnerable open-source dependencies (found by SCA), and misconfigurations in APIs and cloud infrastructure. Managing these vulnerabilities requires a combination of application security testing, risk-based prioritization, and automated remediation workflows.

How do you prioritize application security vulnerabilities?

Effective prioritization moves beyond CVSS scores alone. Use a multi-signal approach that combines CVSS base scores with EPSS (probability of exploitation), CISA KEV (active exploitation in the wild), asset criticality, environmental exposure, and code reachability. Research shows approximately 3% of vulnerabilities account for 80% of real exploitation activity, so risk-based prioritization focuses your team on the issues that actually pose a threat to your environment.

What is the difference between vulnerability management and exposure management?

Vulnerability management focuses on identifying and cataloging security findings from scanners. Exposure management, and the broader CTEM framework, adds business context, asset criticality, exploitability data, and environmental factors to determine real-world risk. While vulnerability management asks “what vulnerabilities exist,” exposure management asks “what is our actual exploitable risk and what’s the business impact?” This shift is why platforms like ArmorCode use a Context Risk Graph to correlate scanner data with runtime and business context.

Key Takeaways

• Application security vulnerabilities span code-level flaws (SAST and DAST), vulnerable open-source dependencies (SCA), and API and cloud misconfigurations, each surfaced by a different class of scanner.
• CVSS rates severity, not risk. Roughly 3% of vulnerabilities account for about 80% of real exploitation, so prioritization has to layer in EPSS, CISA KEV, asset criticality, and reachability.
• Exposure management and the broader CTEM framework replace “what are my vulnerabilities?” with “what is actually exploitable, and what happens to the business if it is?”
• Unifying scanner output through UVM and ASPM, then automating the handoff to engineering, is how teams cut mean time to remediation from 240 days to 7.