A vulnerability in cyber security is a weakness — in code, configuration, or a dependency — that could let an attacker do something the system was never meant to allow; a scanner's job is to find them, and application security vulnerability management is the process that turns that scanner output into fixed code. Most programs get the scanning half right while the process half quietly falls apart. This post lays out a workflow — intake, triage, prioritization, remediation, verification — that holds up against a real release calendar rather than an idealized one.
What does the intake step actually need to capture?
Every finding needs a consistent record regardless of which scanner produced it: the affected component or file, a severity score, a CWE or vulnerability class, and a unique identifier that survives re-scans so the same issue is not re-reported as new every time CI runs. Programs that skip normalizing intake across SAST, SCA, DAST, and container scanners end up with duplicate tickets for what is functionally one underlying issue, which is the single biggest source of triage fatigue in application security vulnerability management.
How should triage separate signal from noise?
Triage is where reachability and exploitability context get applied, and it is the step most workflows shortcut. A raw CVSS score treats every instance of a vulnerable dependency identically, whether the vulnerable function is called from user-facing code or sits in an unused code path. Effective triage asks whether the finding is reachable, whether a known exploit exists, and whether the affected component is internet-facing, then downgrades or defers findings that fail all three checks rather than routing everything into the same queue at the same urgency.
How do you prioritize once triage is done?
Rank by a combination of reachability, exploit maturity (is there a public proof-of-concept or evidence of in-the-wild exploitation), and business context (does this service handle payment data or sit behind three layers of internal auth). A critical CVSS score on a dependency that is never called in production should rank below a medium-severity finding on an internet-facing authentication path. This is where most teams that rely purely on CVSS get their prioritization wrong, and it is the specific gap reachability analysis is designed to close.
Who owns remediation, and what's a realistic SLA?
Ownership should sit with the engineering team that owns the affected service, not a central security team that has to file tickets into someone else's backlog and chase them. Realistic SLAs scale with severity: critical, actively-exploited findings within days; high-severity findings within one to two sprints; everything else on a rolling quarterly cleanup. SLAs that ignore severity and demand everything fixed within 48 hours get ignored within the first month because they are not achievable, and an ignored SLA is worse than a realistic one.
How do you verify a fix actually closed the finding?
Re-scan and confirm the specific finding is gone, not just that the overall count dropped — a version bump can resolve one CVE while introducing a new one in the updated dependency, and a naive "count went down" check will miss that. Verification should be automated as part of the same pipeline that generated the original finding, closing the loop without requiring a human to manually cross-reference before-and-after reports.
What does a scan report need to communicate for this workflow to work?
A scan report that only lists findings by severity without also carrying reachability and ownership context forces every recipient to redo the triage work by hand. A useful scan report groups by owning team, flags what changed since the last scan, and surfaces the small number of findings that actually need attention this cycle rather than the full historical list. Reports that read like a wall of red severity badges get skimmed once and then ignored.
Where does automation genuinely help this workflow, versus just adding tooling?
Automation earns its place at intake normalization (deduplicating across scanners), at triage (auto-scoring reachability), and at verification (auto-closing tickets when a re-scan confirms a fix). It earns its place far less at the actual remediation decision for anything above low severity — a human should still decide whether a critical finding gets an emergency patch or a scheduled fix, even if the surrounding steps are automated. Our SCA product and SAST/DAST product pages describe how this triage-through-verification loop runs in practice.
FAQ
What's the biggest gap between scanning and actual vulnerability management? The absence of a triage and ownership step. Scanning produces findings; management is what turns those findings into fixed code with someone accountable for the fix and a deadline that's realistic.
Should every finding get the same SLA? No. Severity, reachability, and exploit maturity should all shift the SLA — treating a low-severity, unreachable finding the same as an actively exploited critical one guarantees the SLA gets ignored for one of the two.
How do you avoid duplicate tickets across scanners? Normalize intake so findings from SAST, SCA, DAST, and container scanning that map to the same underlying vulnerability get merged into one record before triage, rather than filed independently by each tool.
What is vulnerability in cyber security, in one sentence? The most common security vulnerability definition is: a flaw that could be exploited to violate a system's intended security guarantees, whether that's unauthorized access, data exposure, or disruption. The workflow in this post exists because finding that flaw is the easy part — deciding which ones matter and getting them fixed is the actual work.
Is CVSS enough for prioritization on its own? No — CVSS measures theoretical severity, not whether the vulnerable code path is actually reachable in your application. Pairing it with reachability analysis is what turns a long finding list into a short, actionable one.