What we shipped this week: stricter verdicts, more control over fix PRs

Two groups of changes went out this week. The first makes Arvion stricter about when it says a vulnerability can or can't be exploited in your code. The second gives your team more control over the pull requests Arvion opens.

Exploitability verdicts

A verdict now has to be backed by code Arvion extracted from your project. Knowing that you use a vulnerable version of a package isn't enough on its own: the verdict points at the code it's based on, so you can check our reasoning instead of taking it on trust.

CVEs in CISA's Known Exploited Vulnerabilities catalog now always get a second review before we report a verdict on them. These are the bugs attackers are already using, so a wrong "not exploitable" costs the most there.

We also changed what happens when part of your code wasn't analyzed. Until now, a project with code paths Arvion couldn't follow could still come back clean. Those paths are now reported as not analyzed, and the project doesn't get a clean result while they're open. "Clean" should mean we looked, and "we couldn't tell" should look different from "not exploitable".

Fix pull requests

The same kind of fix often shows up in many places at once. Arvion groups these into fix families, and you can now act on a whole family in one step instead of going through the fixes one by one.

Arvion can now open its fixes as draft pull requests, and a draft doesn't move forward until someone on your team explicitly approves it.

Dependency upgrade pull requests now include the evidence from the test run in their description. The reviewer sees how the upgrade did in your tests before reading the diff.