Vulnerability Remediation
The Vulnerability Remediation agent works through the dependency vulnerabilities your scanner reports. For each CVE it decides whether the vulnerable code is reachable from your services, finds every repository that carries the affected package, and either opens a tested fix PR per repository, routed to the team that owns it, or files a mitigation ticket when no upstream fix exists yet.
This page describes what the agent does at each stage of a run, what you configure, and what it produces.
How a run works
A run moves each finding through six stages.
The agent reads open issues from your scanner. With Snyk, each issue carries the CVE and CWE identifiers, the CVSS score and effective severity, exploit maturity when Snyk has assessed it, fixability signals (upgradeable, patchable, pinnable, fixable upstream), available remedies, and Snyk's reachability result. A run starts on a schedule or on demand for a single CVE. The Snyk integration is read-only and has no webhook, so runs don't start from a Snyk event.
Findings are ranked by severity, exploit maturity and fixability, and weighted by the business criticality and environment recorded on the scanner project, so a critical CVE in a production service is handled before a medium one in a sandbox. Findings below your severity threshold are skipped.
For each remaining finding, the agent checks whether your code can actually call the vulnerable function. It starts from the scanner's reachability data where it exists, then reads the call sites in the repository to confirm. A finding with no reachable path is recorded as not reachable, with the evidence, instead of producing a PR.
The agent maps the vulnerable package to every repository, base image and Terraform module that carries it, using the scanner's project-to-repository mapping and the project's SBOM. Each repository is matched to its owning team through the Catalog.
In a sandbox, the agent clones each affected repository and tries the smallest upgrade that clears the CVE, described below. It regenerates the lockfile, runs the repository's tests, and checks the changelog for breaking changes.
The agent opens one pull request per repository, assigned to the owning team, or a mitigation ticket when no fix exists. After the PR merges, it checks that the scanner's next scan no longer reports the finding, and it closes the loop in the finding's evidence trail.
Choosing the fix
The agent always tries the least disruptive upgrade first:
- Patch release of the current version, if one clears the CVE.
- Minor release, if no patch does.
- Major release, only if nothing smaller clears the CVE. Majors are the most likely to break the build, so the agent reads the changelog for breaking changes and records what it found in the PR.
For transitive dependencies, it upgrades the direct dependency that pulls the vulnerable package in, or pins the transitive version when the package manager supports it and the scanner reports the finding as pinnable.
When the first repository's fix succeeds, the agent reuses that fix pattern (the target version, the pin and any code changes the upgrade needed) for the other repositories that carry the same package. Later PRs therefore need fewer steps than the first.
What the agent produces
| Outcome | When | What you get |
|---|---|---|
| Fix PR | An upgrade clears the CVE and tests pass | A small PR with the version change, the regenerated lockfile, test results and the CVE it closes |
| Draft PR | An upgrade clears the CVE but tests fail | The same PR opened as a draft, with the failing tests and the relevant changelog entries attached, so an engineer starts from a diagnosis |
| Mitigation ticket | No upstream fix exists | A Jira ticket with the workaround, such as a config change or disabling the affected code path. The agent returns to the finding when a fix is published |
| Not reachable | No call path reaches the vulnerable code | A recorded decision with the evidence, visible in the run, with no PR |
Every PR and ticket links to the run, so a reviewer can see the triage decision, the reachability evidence and each command the agent ran.
Evidence trail and SLAs
Each finding has a severity-based SLA, and the agent records every step from detection to a clean rescan: when the finding arrived, the triage and reachability decisions, the PR or ticket, the merge, and the rescan that confirmed the fix. For regulated teams, this record can support audit evidence requirements such as those in PCI DSS, DORA or FFIEC, and it lives in the Audit Trail rather than being reconstructed before the audit.
Access and safety
- Sandboxed changes. Cloning, upgrading and testing happen in a sandbox on the built-in harness. The agent has no write access to your main branch; every change reaches you as a PR that goes through your normal review and CI.
- Scoped tool access. The agent reads from the scanner and source control, and writes only what you grant: pushing a branch, opening a PR, filing a ticket. A governance policy on write operations pauses each of them for a person to approve.
- Models and budget. Each step routes to a model from your approved list, with a per-agent budget, and the frontier model is reserved for steps such as reachability analysis and breaking-change review.
The agent runs in your isolated tenant (SaaS) or your own environment (BYOC), connected or airgapped. See Sovereignty.
How it improves
Upgrades teach lessons that are expensive to learn twice: which major version broke a build, which pin fixed a lockfile, what a changelog entry meant for your code. After each run those lessons are captured as memories that later runs recall for the same package.
Each run is also scored by the Evaluator against what happened downstream, such as whether the PR merged without follow-up fixes, whether CI needed re-runs, and whether the rescan came back clean. The Healer turns weak scores into context changes, such as a skill for a package manager's quirks, that an engineer approves.
Limits
- Reachability depends on what the agent can read. A vulnerable package reached through a repository you haven't connected, or through reflection or dynamic loading, can be judged not reachable. Connect every repository that ships to production, and treat "not reachable" as a decision with evidence to review, not a guarantee.
- Tests bound confidence. A fix PR is only as safe as the repository's test suite. A passing run on a repository with thin tests says little about a major upgrade, which is why majors carry the changelog review.
- Container and OS packages. Base-image vulnerabilities are fixed by bumping the image reference; the agent doesn't rebuild images you don't build from source in a connected repository.
Integrations
| Integration type | Integrations | Used for |
|---|---|---|
| Scanner | Snyk | Findings, fixability, reachability, project-to-repo mapping and SBOMs |
| Source control | GitHub, GitLab | Reading code and manifests, pushing branches, opening PRs |
| CI/CD | Jenkins | Test results on the fix branch, when tests run in CI rather than in the sandbox |
| Issue tracking | Jira | Mitigation tickets |
| Collaboration | Slack, Microsoft Teams | Starting a run for a CVE and posting status to the owning team |
| Service ownership | Catalog | Routing each PR to the team that owns the repository |
Get started
- Connect Snyk and confirm it lists your projects.
- Connect source control with a credential that can push branches and open pull requests. The GitHub integration's own tools are read-only; the agent pushes branches and opens PRs with
gitandghin its sandbox, so the connected credential needs Contents and Pull requests write permission. On GitLab, the integration includes branch and merge-request tools. - Populate service ownership in the Catalog so fixes route to the right team.
- Set the severity threshold and SLA per severity, and add a governance policy that requires approval for write operations.
- Run the agent on one known CVE and review the PRs, tickets and reachability decisions it produces before putting it on a schedule.