chore(security): audit dependabot security alerts (14 open, severity 6 high / 3 moderate / 5 low)

[ccross2]

Context

Push notifications from git push consistently surface the message:

GitHub found 14 vulnerabilities on sovren-software/visage's default branch (6 high, 3 moderate, 5 low). To find out more, visit:
https://github.com/sovren-software/visage/security/dependabot

These alerts have not been explicitly triaged. The git-remote count is the only signal I have visibility into; the actual list of advisories, affected dependencies, and severity-impact-on-our-code-paths needs maintainer review with an appropriate scope.

What I know

• Count: 14 open alerts on default branch
• Severity mix: 6 high, 3 moderate, 5 low
• Coverage: alerts run against the workspace's Cargo.lock (crates/visage*, crates/pam-visage, crates/visaged) and on .github/workflows/ci.yml Action versions

What I don't know

• Which specific advisory IDs (GHSA-*) are flagged
• Which dependencies they apply to (direct vs transitive)
• Whether they're advisory-database-listed deps that aren't actually exploitable in Visage's code paths (a common false positive on Rust projects — e.g., a flagged crate that's only pulled in for a build-time tool, or an unused API surface)
• Whether any are blocking for the PAM auth path (crates/pam-visage) or the daemon (crates/visaged) — those would gate v0.3.2 release sequencing

Why this needs explicit triage

This is a Tier A public-facing security-critical project — face authentication via PAM is the kind of surface where a real CVE in a transitive dependency must be assessed in-context (does our code path even reach the vulnerable API?), and any not-actually-exploitable advisories should be documented as such so the count doesn't keep growing through ignored signal.

Suggested triage process

For whoever picks this up (likely maintainer w/ security_events repo scope):

1. Open https://github.com/sovren-software/visage/security/dependabot
2. Categorize each alert as one of:
   • Real, exploitable in our code path — gate appropriate release (v0.3.2 if hot; v0.3.3 if not)
   • Real, not reachable in our code path — document the reasoning + dismiss with dependabot/inapplicable reason
   • Already fixed by an in-flight dependabot PR — link the PR, let it merge naturally
3. For real-and-reachable alerts: open one PR per advisory with the recommended fix, label security
4. Aim to clear the count to 0 before cutting v0.3.3 (or earlier if any are high-severity in reach)

Related context

• This issue is informational; it doesn't claim a category for any specific advisory
• v0.3.2 is queued (SIGTERM fix fix(visaged): handle SIGTERM (closes #26) #30 + PAM fleet sweep fix(pam): correct success=end → success=done across all 9 sites #31) — if any of the high-severity alerts are reachable in crates/visaged or crates/pam-visage, they should ride v0.3.2; otherwise v0.3.3 is the natural target
• cargo audit could produce a faster local triage signal if run by someone with the workspace checked out (see crates.io/crates/cargo-audit)

Labels (please add if appropriate)

security, chore, triage