cargo-audit: Rust crate checks explained

What the tool is

cargo-audit comes from the RustSec project, the Rust community's security effort. It reads the lockfile of a Rust project, which pins the exact version of every crate in the build, and compares those versions with the RustSec database of known flaws. Its ids look like RUSTSEC-<year>-<number>.

How DevFlow runs it

DevFlow's Rust scanner walks the repository tree for files named Cargo.lock, skipping .git, target and other build or dependency folders. cargo-audit checks one lockfile per call, so DevFlow calls it once for each path, in JSON mode, and merges the results, keeping one finding per crate and id.

A non-zero exit is expected when problems are found; DevFlow treats a call as failed only when it returned no JSON. All lockfiles of a repository share the 300-second default limit of the scanner.

Severity from the CVSS vector

The JSON output carries a CVSS vector string, not a severity label. DevFlow computes the CVSS v3 base score from that vector and buckets it with the standard ranges: under 4.0 is low, under 7.0 moderate, under 9.0 high, and 9.0 or more critical.

A CVSS v4 vector, or one that cannot be parsed, gives unknown. The rounding follows the v3.1 specification for both 3.0 and 3.1 vectors, a difference too small to change a bucket.

Informational warnings

RustSec also publishes informational notices for crates that are unmaintained, unsound or yanked. They carry no CVSS vector, but DevFlow keeps them as findings so they reach the report.

Unsound crates rank highest of these warnings, because unsoundness can mean a real memory-safety hazard.

What each finding records

• the RustSec id;
• the crate name;
• the title of the notice;
• every patched version range, joined in one field;
• a link to the source page.

A worked example

Suppose a repository has a root lockfile and a separate tool under tools/ with its own lockfile, and both resolve a crate with one known flaw. DevFlow makes two calls, one per lockfile, and the report holds that crate and id once. Even if the two lockfiles pin different versions of the crate, one finding remains, because the key is the crate name and the id, not the version, and the entry from the first lockfile is the one kept.

Where results go

Findings are listed by name in the task's scan report, and the merge evidence section of the pull request counts them by severity for each repository. The recurring vulnerability poll runs the same scan on each default branch, every 12 hours by default.