Appsec vulnerability management fails in most organizations not because scanners miss things, but because nobody has a working process for what happens after a finding lands. Teams run SAST, DAST, and SCA tools, generate thousands of findings a month, and then rely on individual engineers to decide, ad hoc, what gets fixed — which means the loudest scanner output wins, not the most exploitable risk. A real workflow needs five stages: intake, triage, prioritization, remediation, and verification, each with an owner and an exit condition, or the backlog just grows forever.
What does the intake stage of vulnerability management actually involve?
Intake means consolidating findings from every scanner and source — SAST, DAST, SCA, cloud posture tools, penetration test reports, bug bounty submissions — into a single system of record instead of leaving them scattered across five separate dashboards. Without consolidation, the same underlying vulnerability can show up as four different tickets in four different tools, and nobody has a full picture of actual exposure. Most mature programs feed everything into a central vulnerability management platform or a ticketing system with a dedicated security queue, tagged with source, asset, and discovery date, so the next stage has something coherent to work with.
How should triage separate real risk from noise?
Triage should filter for exploitability and reachability before anything else, because a raw CVSS score tells you almost nothing about whether a finding matters in your specific application. A critical-severity vulnerability in a library function your code never calls is not an emergency; a medium-severity vulnerability in an internet-facing authentication path is. This is where combining SCA reachability data with SAST and DAST context earns its keep — reachability analysis tells you whether a vulnerable function is actually invoked, and runtime context from DAST tells you whether the affected endpoint is exposed at all. Teams that skip this step end up triaging by severity label alone, which reliably produces a backlog that's 80% noise.
How do you prioritize what gets fixed first?
You prioritize by combining exploitability, exposure, and business impact into a single ranked list, not by working strictly top-down through a CVSS-sorted spreadsheet. A useful model layers in whether a CVE has a known public exploit (CISA's Known Exploited Vulnerabilities catalog is a solid signal here), whether the affected asset is internet-facing or internal-only, and whether it touches a system that holds regulated data. Set explicit SLAs by risk tier — for example, actively exploited critical findings on internet-facing assets fixed within 72 hours, internal-only mediums fixed within the normal sprint cadence — and track adherence to those SLAs as the actual health metric of your appsec vulnerability management program, not raw finding count.
Who owns remediation, and how do you keep it from stalling?
Remediation should be owned by the engineering team responsible for the affected code, with security acting as the escalation path rather than the fixer, because security teams are almost always outnumbered by the volume of findings relative to engineers who can write the actual patch. What keeps remediation from stalling is making the fix as low-friction as possible: auto-generated pull requests with the minimal version bump or code change needed, clear reproduction steps for DAST findings, and a defined path for when a fix genuinely isn't feasible (a documented risk acceptance with an expiration date, not a silently ignored ticket). Programs that make remediation someone's full-time unstructured side task see fix times measured in months; programs that route findings directly into existing engineering workflows see days.
Why does verification matter as its own stage?
Verification matters because a closed ticket isn't the same as a fixed vulnerability — engineers mark tickets resolved for all kinds of reasons that don't include "the vulnerability is actually gone," including partial fixes, environment mismatches, and simple mistakes. A real verification stage re-scans the affected asset after the fix ships and confirms the specific finding no longer reproduces before the ticket closes for good. This is also where you catch regressions: a dependency bump that fixes one CVE but reintroduces a different vulnerable version elsewhere in the tree, or a WAF rule that mitigates a DAST finding in staging but wasn't deployed to production.
FAQ
What's a reasonable SLA for critical vulnerability remediation?
Many mature programs target 24-72 hours for actively exploited critical findings on internet-facing assets, 30 days for other critical findings, and 90 days for high-severity findings — adjusted based on your actual risk tolerance and regulatory obligations.
How is appsec vulnerability management different from generic IT vulnerability management?
AppSec-specific programs deal heavily with code-level findings (SAST, SCA, DAST) tied to a specific commit or dependency, which usually route to engineering teams for a code fix, versus infrastructure vulnerability management, which more often routes to ops teams for patching or configuration changes.
Should every finding get a ticket?
No — findings below an agreed severity or exploitability threshold should be tracked in aggregate (for dashboarding and trend analysis) without generating individual tickets, or your ticketing system becomes noise nobody trusts.
How do you measure whether the workflow is actually working?
Track SLA adherence by risk tier, mean time to remediation, and the ratio of findings closed via verified fix versus findings closed via risk acceptance or ticket staleness — a workflow that mostly closes tickets through staleness isn't working, whatever the dashboard says. See our SAST/DAST product page for how automated verification fits into this loop.