Finding a vulnerability is the easy part. Security's job is to get the fix merged and deployed, so for vulnerable dependencies Coroid opens the upgrade pull request itself, and your team reviews and merges it.
When Coroid opens one
With Fix vulnerable dependencies on, a dependency finding at or above the fix severity (high by default) opens a fix task in its project:
- One task and pull request per package, covering every advisory that affects it.
- Critical findings first, then high.
- At most 5 open fix pull requests per project by default (up to 50). The next fix waits for a slot.
Owners and admins can also choose Fix on any open dependency finding whose advisory is public. When no fixed version has been released, Fix offers a mitigation task instead: remove or replace the package, pin a patched fork, or guard the vulnerable call.
Automatic upgrades work for npm projects today. For other ecosystems the finding says "No automatic fix for this ecosystem yet", and Fix offers the mitigation task.
What pays for it
Fix tasks use an AI model, so they spend agent hours like other work. They run under the built-in Security fixes mandate, which every organization has:
- Scope: dependency upgrades and security mitigations, nothing else.
- Budget: agent hours only, by default a quarter of your plan's agent hours per month. Owners change the hours, and whether they count per week or per month, under Security → Settings → Fix vulnerable dependencies.
- No review expiry. It is a standing default, not something to renew.
- Priority: security fixes are admitted before other self-initiated work.
Switching Fix vulnerable dependencies off on the organization default pauses the mandate. The mandate is listed with the others in Quality Control → Mandates.
When an organization that already had connected repositories gets Security, its owners receive a notice in the bell: "Security fixes starts in seven days". Fix work starts seven days after that notice is delivered, so an owner can switch it off before the first pull request. New organizations start at once.
Why a fix might wait
A finding's fix section says what it is waiting for. The usual reasons:
- the open pull request limit for the project is reached;
- the mandate's budget or the plan's agent hours are spent (detection carries on);
- agent work is paused in Mission Control, or no agent slot is free;
- the seven-day notice period has not ended;
- no compatible fix has been released, or the ecosystem has no automatic fix;
- Fix vulnerable dependencies is switched off.
How the upgrade is chosen
For each place a vulnerable package is installed, Coroid picks the smallest version above the installed one that fixes every advisory affecting it, staying within the declared range and major version where it can. It never downgrades. A workspace that needs one major and a workspace that needs another each get their own patched version, in the same pull request. A transitive package moves through its parent's upgrade or the package manager's override. Any major change or consolidation onto one version comes with its reason in the pull request. When no single upgrade fixes everything, the pull request fixes what it can and lists the rest as not fixed.
What the pull request carries
- The advisories it fixes, with their severity.
- The package inventory before and after the change, showing the vulnerable version gone.
- Your project's checks: when the project's Delivery graph has checks that can run, they must reach GO AHEAD on the pushed change before Coroid opens the pull request; otherwise the task ends with its reason. When the project has no checks configured, the pull request still opens and says that Coroid ran no project checks, that your repository's own CI runs on the pull request, and where to configure checks in Quality Control.
- The reasons for any major or range change.
- Any advisory it could not fix, listed as not fixed.
It ends with: "People review and merge. Deployment status is decided only by a scan of the deployed revision." The finding becomes fixed in code from the next complete inventory, and fixed per environment from a scan of the revision that environment runs. See Findings and their lifecycle.
Code findings
On a code finding, Fix files a task to fix it in its project. Owners and admins can use it on any open code finding. The task asks the developer to describe the fix, not the attack, in commit messages and the pull request, and to add a regression test. It runs under the same rules as other tasks and spends agent hours.
On a public repository, or one whose visibility Coroid cannot confirm, a fix for a finding that is not public yet is not committed there. Coroid keeps the prepared change privately for an owner or admin to publish. See Disclosure.
Leaked secrets
A leaked credential is fixed by rotating it, which Coroid cannot do for you. Fix on a secret finding creates a checklist task instead. See Leaked secrets.