Skip to main content

Module audit

Module audit 

Source
Expand description

Dependency-vulnerability audits, with the severity the push deserves.

The same policy the release workflow enforces in CI, brought to the machine where the push starts: an advisory against the dependency tree is INFORMATION on a branch push — named, never blocking, retried for free tomorrow — and a REFUSAL on a push that carries a v* tag, because a tag is a release leaving the building and immutable registries do not take anything back. The hook advises early; CI (for repositories that have it) enforces finally.

One check per ecosystem amont already speaks — cargo audit for Rust, npm audit for JS, pip-audit for Python — each opted in by the lockfile its tool actually audits. No lockfile, no check: an audit without a resolved tree audits a guess.

Three verdicts, learned the hard way in ci.yaml’s advisory job and kept here: the tools’ OUTPUT decides, not the exit code alone, because every one of them conflates “found vulnerabilities” with “could not fetch the advisory database” in its exit status. And “could not check” is spoken loudly but never blocks — crate::check::Outcome::Unavailable’s contract: a hook may be offline, and a push gate that fails on a captive portal teaches --no-verify. The release workflow, which is never offline, is where an unchecked tree refuses to ship.

Functions§

js
python
rust