[mptfire]

Found by the same independent audit (2026-11-01).

What

A new security-audit.yml workflow running cargo audit against both workspaces' lockfiles (Cargo.lock and lnvps_fw/Cargo.lock), matrix-isolated so one red lockfile doesn't hide the other:

• triggers: every PR, master pushes, weekly schedule, manual dispatch — the weekly run is what catches an advisory published against an already-pinned version without any code change;
• read-only: permissions: contents: read, no secrets, nothing pushed or commented;
• the checkout action is pinned by SHA — this repo's workflows otherwise use tag/floating pins (one of the audit's findings).

Sequencing

Merge after #429 (the RustSec dependency bumps): until those land, master's lockfiles carry known-flagged versions and the gate will be red on master by design. If that's awkward, land #429 first and this can merge immediately after — or flip to advisory-only and back once clean.

Trade-offs stated plainly

• cargo install cargo-audit --locked costs a few minutes per run (no cache configured — kept deliberately simple; a Swatinem/rust-cache-style step can be added later if the runtime matters).
• A newly published advisory red-lines master until someone bumps the crate. That is the point of a gate, but it is a maintenance commitment: if it proves too noisy, the weekly run can be made advisory-only while PRs stay blocking.

[v0l]

Happy to have this, but it can't land blocking yet: even with #429 merged, cargo audit on master still fails. On #429's lockfile I get, in the root workspace: crypto-bigint 0.5.5 (RUSTSEC-2026-0387, a second copy via an older dep), quick-xml 0.39.4 (-0194, -0195), quinn-proto 0.11.16 (-0338..-0342), rustls 0.23.40 (-0285, -0346, -0348, -0349), rustls-webpki 0.103.13, webpki-roots/webpki-root-certs 1.0.8, and rsa RUSTSEC-2023-0071 (no fix exists). lnvps_fw/Cargo.lock still has webpki-roots 1.0.8.

To land:

1. Add an audit.toml (or --ignore list) for advisories with no fix, starting with RUSTSEC-2023-0071, each with the reason.
2. Bump the rest in #429 (or a follow-up) until cargo audit is green on both lockfiles, and show the green run.
3. Install a pinned prebuilt cargo-audit (e.g. taiki-e/install-action pinned by SHA) instead of cargo install on every run.
4. Drop the comments from the workflow file; the "expects #429" note goes stale on merge.