Guide
Automated vulnerability remediation: what to automate, and how to trust it
BaseCobalt · Updated
Automated vulnerability remediation uses software to carry out the work between a security finding and a fix: investigating the code, reproducing the issue, generating a patch and validating it. Dependency upgrades have been automated for years. Code-level fixes are newer, and they are only useful with evidence that the patch removes the vulnerability without breaking the application.
What can be automated, stage by stage
| Stage | What software can do | What still needs a person |
|---|---|---|
| Triage | Deduplication, grouping, routing to an owner | Risk-acceptance decisions |
| Investigation | Reading code, tracing data flow, finding callers | Context that lives outside the repository |
| Reproduction | Writing tests or requests and running them in a sandbox | Issues that depend on production-only configuration |
| Exploitability | Reasoning about reachability, authentication and preconditions | Business impact of the affected data or feature |
| Patch | Dependency upgrades (mature); code and configuration fixes (newer) | Design-level fixes such as changing an authorization model |
| Validation | Running the project’s tests and build before and after | Judging whether test coverage is adequate |
| Verification | Re-running the reproduction and rescanning | — |
| Merge | Nothing: this stays with a reviewer | Approving the change |
The stages are described in detail in the remediation process.
Dependency upgrades versus code-level remediation
Dependency upgrade bots watch advisories and open pull requests that bump a vulnerable package to a fixed version. This works well when a fixed version exists and the upgrade is compatible. It struggles with major-version upgrades that change APIs, transitive dependencies that need an override, and advisories with no fixed release.
Code-level remediation is a different problem. A SAST finding, a Dockerfile misconfiguration or a penetration-test finding is fixed in your own code, so the fix depends on reading that code: its data flow, its helpers, its conventions. That is the work that has historically stayed manual.
Can AI fix software vulnerabilities?
Language models can read code, explain a vulnerability and write a plausible patch for many common vulnerability classes. The risk is in the word plausible. Generated security patches fail in recognizable ways:
- Fixing the pattern, not the flaw. Changing the flagged line so the rule stops matching while a sibling path stays vulnerable.
- Incomplete sanitization. Escaping that misses an encoding, a context or a second parameter.
- Behavior changes. A fix that drops privileges, tightens validation or changes a default and breaks a feature.
- Invented APIs. Calls to helpers or options that don’t exist in the project’s versions.
So the answer is yes, with a condition: an AI-generated patch without verification is a suggestion, not a fix. The value of automation is in producing the evidence alongside the patch.
How do security teams validate generated security patches?
Ask for the same evidence you would ask of an engineer’s fix, produced by the run itself:
- The finding reproduced against current source before patching.
- Project tests and build passing before the patch (baseline) and after it.
- The reproduction no longer succeeding after the patch.
- A rescan with the same rule: original finding resolved, no new findings.
- A minimal diff with a stated root cause.
If any of these is missing, the reviewer has to produce it, and most of the time saved by automation goes with it.
Questions to ask of an automated remediation tool
- Does it work from the findings you already have, or require its own scanner?
- Does it reproduce a finding before patching it?
- Does it run your project’s own tests and build, before and after?
- Does it rescan to confirm the finding is gone?
- Does it show that evidence with the patch?
- Does a person still approve the merge?
- Where does your code run during analysis, and what is retained?
- Is it clear about which languages, frameworks and finding types it handles?
Where automation should stop
Merging, accepting risk, redesigning an authorization model, and communicating with an external reporter are decisions, not tasks. Automation should hand those to a person with the evidence needed to make them quickly.
How BaseCobalt approaches it
BaseCobalt automates remediation for one existing finding at a time, with verification built into every run: it reproduces the finding against current source, runs baseline validation, applies a patch, re-runs validation and rescans. It returns a fix ready for review with that evidence attached. The aim is to turn hours of remediation work per finding into minutes of review. You can see a published run.