Automated vulnerability remediation, from finding to fix

What automated vulnerability remediation means

Vulnerability remediation is removing a known vulnerability from your software: upgrading the affected package, applying a patch, or replacing the component. Automated remediation hands the mechanical part of that work to software. It reads a finding, works out which version fixes it, changes the manifest, lockfile or code, and proposes the change, most often as a pull request.

For third-party dependencies, which is where most of a modern codebase's known vulnerabilities live, the loop looks the same in every tool:

1. Inventory. Know which packages, at which versions, are in each thing you ship.
2. Match. Check that inventory against advisories, and keep checking as new ones are published.
3. Prioritize. Decide what to fix first, by severity, exploitation and exposure.
4. Fix. Pick the fixed version, update it, and adapt the code if the upgrade breaks something.
5. Verify. Build and test the change, then confirm the fixed version is what actually shipped.
6. Record. Keep a trail of what was affected, when it was fixed, and in which release.

Automation is strongest at steps 2, 4 and 6, where the work is repetitive. It is weakest where the inputs are wrong, and the input to everything else is step 1.

Four kinds of automated remediation

Approach	What it does	Examples	Where it stops
Dependency update bots	Open pull requests that bump a vulnerable dependency to a fixed version	Dependabot security updates, Renovate	Works from the manifests and lockfiles in the repository; a breaking upgrade still needs a person to adapt the code
SCA fix pull requests	Open upgrade pull requests for the findings a commercial SCA tool raises	Snyk, Black Duck, Aikido, Endor Labs	Coverage varies: some tools fix direct dependencies only, some add patches or backports
AI code fixes	Generate a code change for a finding, often a static analysis alert	GitHub Copilot Autofix	Non-deterministic suggestions that need review; see AI remediation
Infrastructure auto-remediation	Reverts a misconfiguration or patches a host when a rule fires	Cloud security posture and endpoint tools	Covers running infrastructure, not the dependencies inside the software you ship

The first three all fix code you ship, and they all share one assumption: that the list of vulnerable packages they are fixing is the right list.

Every fix depends on the inventory

A remediation tool can only fix the vulnerabilities it knows about, and it knows about the ones its inventory contains. Most inventories are reconstructed from files: manifests, lockfiles, installed packages or a finished container image. That reconstruction misses things in predictable ways.

• Packages the files do not declare. Tools the build downloads, base images, plugins and anything installed by a script never appear in a lockfile, so no fix pull request is ever opened for them.
• Versions that differ from the lockfile. The build may resolve a different version than the one a scanner reads, especially without a committed lockfile. A fix keyed on the wrong version is a confident wrong answer.
• Packages restored from caches. A cached dependency never touches the registry again, so what the build used can lag behind what the repository says.

The fix is to start from what the build actually used. A build-time SBOM is recorded while the build runs, so it lists the packages the job pulled in, including transitive ones, rather than what a manifest says it should need. Remediation that starts there fixes what ships.

What to automate and what to keep

Most teams that make remediation work split it like this:

• Automate the finding and matching. New advisories are published every day. Re-checking every shipped build against them by hand does not scale, and it is exactly the kind of work software does well.
• Automate the proposal. Picking the fixed version and opening the change is mechanical. Group related updates so reviewers see one pull request instead of twenty.
• Gate the merge on tests. Automerge patch-level security updates the test suite covers. Keep breaking upgrades, and anything without test coverage, for a person.
• Keep the judgment calls human. Whether a vulnerability affects your product at all, and whether a risky upgrade is worth it this week, are decisions. Record them, for example as a VEX statement, so the same question is not asked twice.

How to evaluate a remediation tool

Before you trust a tool to open pull requests on your repositories, ask:

1. Where does its vulnerability list come from: files in the repository, a scanned image, or the build itself?
2. Does it fix transitive dependencies, or only the direct ones you declare?
3. How does it choose the fixed version: the minimum patched version, the latest, or a version you pin?
4. Is the fix built and tested before you see it, or is the pull request the first time it runs?
5. Can it group updates, and schedule them, so it does not flood reviewers?
6. Does it record which releases were affected and when each fix shipped?

Where CRACI fits today

CRACI runs your GitHub Actions jobs on its own runners and records the packages each job actually fetched, including transitive dependencies and packages restored from caches, with a completeness state for every job. That recording is the inventory a remediation workflow should start from.

CRACI re-evaluates monitored SBOMs continuously, so when a new advisory is published you see which shipped builds it affects across your repositories. Security teams triage each finding and send it to the team that owns the fix, and CRACI supports VEX for recording how a vulnerability affects your product. The next build's SBOM then shows whether the fixed version is what the build really used. The vulnerability tracking page covers the full capability.

Under the EU Cyber Resilience Act, manufacturers must address and remediate vulnerabilities without delay, including through security updates. A record of what each build contained and when each fix shipped is the evidence that process needs.

Automated vulnerability remediation: frequently asked questions

What is automated vulnerability remediation?

Automated vulnerability remediation is software that turns a vulnerability finding into a fix without a person doing the legwork: it works out the fixed version, changes the manifest, lockfile or code, and proposes the change, usually as a pull request. A person, or a policy the team trusts, still decides what merges.

What is the difference between vulnerability remediation and mitigation?

Remediation removes the vulnerability, for example by upgrading to a fixed version or applying a patch. Mitigation reduces the risk while the vulnerability is still there, for example by disabling the affected feature or blocking the attack path. Mitigation buys time; remediation closes the finding.

Can vulnerability remediation be fully automated?

Parts of it can. Finding affected builds, matching advisories and proposing a version bump are mechanical and automate well. Deciding whether a breaking upgrade is safe, or whether a vulnerability affects your product at all, still needs judgment. Most teams automate the proposal and keep a person, backed by tests, on the merge.

Does Dependabot do automated vulnerability remediation?

Dependabot security updates open pull requests that update a vulnerable dependency to the minimum patched version, for the alerts GitHub raises on your repository's dependency graph. That is automated remediation for what the manifests and lockfiles declare. CRACI vs Dependabot covers where declared and shipped differ.

What should I look for in a vulnerability remediation tool?

Where its vulnerability list comes from, whether it handles transitive dependencies, how it picks the fix version, whether the fix is built and tested before you see it, and whether it records what was fixed and when. The last one matters for audits and for the CRA, which asks manufacturers to remediate vulnerabilities without delay.