Remediation
AI code fixes and automated remediation, approved by a person
AI code fixes are changes an AI model proposes to remove a vulnerability, usually a dependency upgrade or a small code edit. They can shorten the time to remediate, but a person should approve each one, because a fix can break behaviour, bring in new transitive packages, change a licence or simply not fix the problem.
Free plan, no card required.
What are AI code fixes and automated vulnerability remediation?
Automated vulnerability remediation covers any tooling that turns a finding into a proposed change. For a vulnerable dependency, that is usually a new version in the manifest and a regenerated lockfile. For a finding from source analysis, it is an edit to the code, such as replacing a query built from strings with a parameterised one. For a misconfiguration, it is a changed setting in a Dockerfile or Terraform file. AI models are now used both to write these changes and to explain them.
The approaches differ mainly in how much a person sees before a change lands. At one end, a tool suggests a fix next to a finding and a developer applies it by hand. In the middle, a tool prepares a change that someone reviews. At the other end, changes are merged automatically when the tests pass. The closer a process gets to automatic merging, the more it depends on tests that would catch a broken or incomplete fix.
Why a person should approve every fix
A proposed fix is a change to production code, written by something that cannot run your product in your customers' environments. The model can be confident and wrong, and a clean diff can hide a change in behaviour. Approval does not mean redoing the work; it means a named person has checked the points below and accepts the change. That record is also evidence later, when you need to show how a vulnerability was handled.
- Breaking changes: a major-version upgrade can remove or change the APIs your code calls.
- Transitive upgrades: a new version can pull in new packages, each with its own vulnerabilities and maintainers.
- Licence changes: a new release can move to a licence your organisation does not accept.
- Regression risk: behaviour your tests do not cover can change silently.
- Incomplete fixes: the change may miss an affected code path or target the wrong version range.
- Invented details: a proposed version or package that does not exist.
How to judge a proposed dependency upgrade
Start from the advisory, not from the proposal. In the OSV format, an advisory's affected ranges record where a vulnerability was introduced and in which version it was fixed. The smallest safe move is usually the first fixed release on the version line you already use, because it changes the least. Jumping to the newest major version may fix more, but it is a feature upgrade as well as a security fix and deserves its own review.
If the vulnerable package is not one you declare, it arrives through a direct dependency. Upgrading the transitive package on its own can conflict with what its parent expects, so the cleaner fix is usually to upgrade the parent to a release that resolves the vulnerable package to a fixed version. Package-manager overrides are a fallback when no such release exists yet; record them so they are removed once the parent catches up.
| Check | What to look for |
|---|---|
| Fixed version | The advisory lists the proposed version, or an earlier one on the same line, as fixed. |
| Direct or transitive | For a transitive package, the direct dependency you need to move is identified. |
| Lockfile diff | Only the expected packages change, and no unexpected new packages appear. |
| Release notes | No breaking changes, removed features or change of licence. |
| Tests | The test suite passes and covers the code that uses the package. |
| Origin | The version was published on the official registry by the package's usual maintainers. |
What the Cyber Resilience Act says about remediation
Annex I Part II of the Cyber Resilience Act, Regulation (EU) 2024/2847, sets the vulnerability-handling requirements for manufacturers. Point (2) requires them, in relation to the risks posed to the product, to address and remediate vulnerabilities without delay, including by providing security updates, and, where technically feasible, to provide new security updates separately from functionality updates. That matters when a fix arrives bundled with a large version jump.
Point (8) requires that, where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed with a business user for a tailor-made product, free of charge, together with advisory messages that tell users what they need to know, including any action to take. The CRA does not prescribe how a fix is written, by a person or with AI. These requirements apply from 11 December 2027.
When not to fix: recording that a vulnerability does not affect you
Not every finding needs a code change. A vulnerable function may never be called, or the affected feature may be switched off in your build. In that case a documented decision is better than an upgrade that adds risk of its own. A VEX (Vulnerability Exploitability eXchange) document records, per vulnerability, whether a product is affected and why, in a machine-readable form that customers and authorities can read. Keep the evidence behind each “not affected” statement and revisit it when the code changes.
Available in KROMSE today
KROMSE tells you what to change and why; a person on your team decides and makes the change.
- Upgrade guidance from advisory data: the fixed version of the vulnerable package and, for a transitive package, the direct dependency that brings it in where the lockfile proves it. No version is invented for that parent.
- An AI verdict per finding within your plan allowance, next to a plain-language explanation.
- Response actions proposed by the AI assistant, each of which a person approves or rejects.
- Malicious packages flagged as critical, with removal as the only remedy.
- For Go projects, call analysis that can show whether your code calls the vulnerable function.
- VEX export in CycloneDX 1.6 VEX and OpenVEX 0.2.0, and CRA response cases with deadlines and recorded human decisions.
- Nothing modifies code: the GitHub App is read-only and KROMSE cannot open pull requests.
Coming next
On the roadmap, not available yet. Dates are targets, not promises; this page changes the day a capability is live.
- Coming · Q4 2026 (November)AI fix proposals, approved by a person. KROMSE will propose fixes for findings, written with AI and applied only after a person on your team approves them.
- Coming · Q4 2026 (November)Coding-agent plug-in. A plug-in for AI coding agents will check every package the agent proposes before it lands, including packages that do not exist or were published only days ago.
- Coming · Q4 2026 (December)Monitoring on your schedule, with AI agents. Rescans will run on a schedule you set, with AI agents that watch for new advisories, triage what applies, propose fixes and draft the report for your review.
Frequently asked questions
Are AI code fixes safe to merge automatically?
Only where tests and review would catch a broken fix, and even then with care. An AI-proposed change can break an API, pull in new transitive packages, change a licence or miss part of the vulnerability. A named person approving each fix, with the lockfile diff and release notes in front of them, is the safer default for production code.
What is the minimal safe version for a dependency upgrade?
It is usually the first release that the advisory lists as fixed on the version line you already use. It removes the vulnerability with the smallest change in behaviour. A larger jump, especially across a major version, may be worth making, but it is also a feature upgrade that needs its own review and testing.
How do I fix a vulnerability in a transitive dependency?
Find the direct dependency that pulls the vulnerable package in, and upgrade it to a release that resolves the package to a fixed version. If no such release exists, a package-manager override can force the fixed version, but record it and remove it once the parent catches up, because an override can break the parent package.
Does the Cyber Resilience Act require automated remediation?
No. Annex I Part II requires manufacturers to address and remediate vulnerabilities without delay in relation to the risks, including through security updates, and to disseminate available security updates without delay and, as a rule, free of charge. It does not say how fixes are produced. Automation can help with speed; documented decisions help with evidence.
Does KROMSE apply fixes to my code?
No. KROMSE explains each finding, gives upgrade guidance from advisory data and can propose response actions that a person approves or rejects. It does not edit code or open pull requests. AI fix proposals that are applied only after a person approves them are on the roadmap.