What is vulnerability remediation?

Remediation, mitigation and risk acceptance

A security team has three possible responses to a confirmed vulnerability. Only one of them removes it.

Mitigation is often the right first move when a fix will take time, but a mitigated finding should stay open. The flawed code still exists, and a new caller, route or configuration change can make it reachable again without anyone revisiting the original finding.

What is the difference between vulnerability management and vulnerability remediation?

Vulnerability management is the program: inventory, scanning, deduplication, prioritization, SLAs and reporting across every finding an organization has. Vulnerability remediation is the engineering work on each individual finding: understanding the affected code, writing the fix and proving it works.

The distinction matters because the two scale differently. Better prioritization tells a team which findings to fix first; it does not make any single fix faster. When findings arrive faster than engineers can investigate and patch them, the backlog grows no matter how well it is ranked.

What happens after a vulnerability is found?

Whether the finding came from a SAST scanner, a dependency scanner, a penetration test or an outside researcher, remediating it follows the same sequence:

1. Triage. Is it real, is it a duplicate, and who owns the code?
2. Investigate. Read the affected code and trace how untrusted input reaches it.
3. Reproduce. Demonstrate the issue against the current source.
4. Assess exploitability. Decide whether an attacker can reach it here, and what they gain.
5. Patch. Fix the root cause, not the pattern the scanner matched.
6. Validate. Run the project’s tests and build to show nothing else broke.
7. Verify. Re-run the reproduction and the scanner to show the vulnerability is gone.
8. Review and merge. A human approves the change and it ships.

Each step is covered in detail in the vulnerability remediation process.

When is a vulnerability actually remediated?

Closing a ticket is not the same as remediating a vulnerability. A finding is remediated when all of these hold:

• The root cause has changed, not just the line the scanner flagged.
• The reproduction that demonstrated the issue no longer succeeds.
• The scanner rule that reported the finding no longer fires on the patched code, and the rescan reports no new findings.
• The project’s existing tests and build still pass.
• The change has been reviewed, merged and deployed wherever the vulnerable code ran.

Findings closed without a rescan or a reproduction check are the ones that come back later as reopened findings or regressions.

Why is vulnerability remediation slow?

Writing the patch is rarely the slow part. Many security fixes are a few lines. The time goes into everything around those lines:

• Context. The engineer assigned the finding often didn’t write the affected code and has to learn it first.
• Handoffs. Security understands the vulnerability class; engineering understands the code. Every question between them adds queue time.
• Doubt about exploitability. Without a reproduction, teams debate whether a finding is real before anyone fixes it.
• False positives. A finding that turns out not to be exploitable costs the same investigation as one that is, before it can be dismissed.
• Validation. Running tests, building, and rescanning takes time, and a failure sends the fix back to the start.

This is why remediation effort is measured in hours per finding even when the eventual diff is small.

How is remediation time measured?

The common metric is mean time to remediate (MTTR): the time from when a finding is reported to when a verified fix closes it. A single average hides where the time goes, so it is more useful to track the segments separately: time to triage, time to an owner, time to a merged fix, and time to verified closure. The segment that dominates tells you what to change.

Can vulnerability remediation be automated?

Partly, and the automatable share is growing. Dependency upgrades have been automated for years by tools that open version-bump pull requests. Code-level fixes (injection, broken authorization, unsafe configuration) require reading and changing application code, which has historically been manual. Software agents can now investigate code and generate patches, but a generated patch is only useful with evidence that it removes the vulnerability and breaks nothing. See automated vulnerability remediation for what that evidence should look like.

Where BaseCobalt fits

BaseCobalt automates remediation one finding at a time. Given an existing security finding, it investigates the codebase, reproduces the vulnerability, assesses exploitability, generates a patch, runs the project’s validation, and rescans, then returns a verified fix ready for review. It doesn’t discover vulnerabilities or run the vulnerability management program; it works on the findings that program produces. More about BaseCobalt.