[bherila]

Summary

Adds dependency and container-image scanning for Temps' own supply chain (as opposed to crates/temps-vulnerability-scanner, which only scans deployed customer application images — crates/temps-vulnerability-scanner/src/trivy.rs, daily_scanner.rs). Tracked as bherila#23.

• .github/dependabot.yml (new): version-update PRs for

  • cargo (workspace root, /)
  • bun (/web — web/bun.lock confirms bun, not npm/yarn/pnpm, per CLAUDE.md; Dependabot's native bun ecosystem went GA Feb 2025 and supports the text-based bun.lock format this repo uses)
  • github-actions (workflow files, including this PR's new workflow)

  All three run weekly (Monday 06:00 America/New_York) and group minor+patch updates into a single PR per ecosystem to cut down on PR spam across 51 crates + the web deps; major bumps stay ungrouped so each gets its own PR and full CI signal, since majors are the ones most likely to need a real code change.

• .github/workflows/dependency-scan.yml (new): runs on pull_request (path-filtered to **/Cargo.toml, **/Cargo.lock, web/package.json, web/bun.lock, and the workflow file itself), on a weekly schedule (Monday 06:00 UTC), and via workflow_dispatch.

  • cargo-audit: rustsec/audit-check@v2.0.0 against the workspace Cargo.lock. Fails the job on any RUSTSEC advisory match.
  • web-audit: bun install + bun audit --audit-level=high in web/. Fails the job on high/critical severity findings.
  • container-scan (stretch goal, implemented): Trivy scan of the currently published ghcr.io/<owner>/temps:latest image (CRITICAL,HIGH, ignore-unfixed), with best-effort SARIF upload to GitHub code scanning (continue-on-error: true since Advanced Security may not be enabled everywhere). This only runs on schedule/workflow_dispatch, not pull_request — release.yml only builds+pushes images on v*.*.* tags, so a PR has no fresh image to scan; scanning the last-published :latest weekly is the meaningful signal here.

Fail vs. warn

Chose fail for cargo-audit and bun audit (job returns non-zero on high/critical findings) rather than warn-only: this is a net-new capability, so there's no existing "required check" to break, and a scanner that only prints warnings tends to get ignored. Same threshold (CRITICAL,HIGH) is used for the Trivy job for consistency.

Heads-up: running bun audit --audit-level=high against web/'s current lockfile as of this PR already reports 29 existing vulnerabilities (1 critical, 28 high) in transitive deps (react-router, handlebars via a transitive dep, d3-color, flatted, picomatch). That means this workflow will show red on the first PR/schedule run against main, not because the workflow is broken, but because it's surfacing real pre-existing debt for the first time. Recommend a fast-follow PR to bump/patch those before treating this check as a merge gate.

Verification

• python3 -c "import yaml,sys; yaml.safe_load(open(sys.argv[1]))" run against both new YAML files — both parse cleanly.
• Confirmed web/bun.lock (not package-lock.json/yarn.lock/pnpm-lock.yaml) is present, confirming bun is the actual package manager.
• Ran bun audit --audit-level=high directly against web/ locally — confirmed it installs, runs, and exits non-zero on the existing high/critical findings (see heads-up above).
• Verified rustsec/audit-check@v2.0.0's action.yml directly (it's a bundled Node 20 action, not a from-source cargo install, so it doesn't hit slow compiles in CI) and confirmed its token input matches what's wired up here.
• Verified aquasecurity/trivy-action@v0.36.0's action.yaml directly against the upstream repo (not from memory) — confirmed image-ref, format, output, severity, exit-code, and ignore-unfixed are all real, current inputs, and that tags use a v prefix (v0.36.0, not 0.36.0).
• Attempted a local cargo install cargo-audit --locked to do an end-to-end run of the underlying tool against this workspace's Cargo.lock; the from-source build didn't finish in the sandbox's time/CPU budget (shared box, heavy gix/rustls dependency tree) so I killed it rather than let it run indefinitely. Since rustsec/audit-check doesn't build from source in CI (see above), this doesn't block the workflow from working — but I did not get a completed local cargo audit run against this repo's actual Cargo.lock, so flagging that explicitly rather than claiming full end-to-end verification of that one piece.

Follow-ups (not done here)

• Fix/triage the 29 existing bun audit findings in web/ (see heads-up above) so the new check goes green.
• Consider adding CodeQL (mentioned in the original issue) as a separate, larger PR — out of scope here, which is specifically dependency/container scanning.

[dviejokfs]

@bherila Picked up the failing Rust Dependency Audit (cargo-audit) check (run 28694843923, job 85102598339) and pushed a fix directly to this branch (23759b5a).

Root cause: cargo audit was flagging 3 real (non-"unmaintained") vulnerabilities that this branch's own Cargo.toml already had fully researched and documented as unreachable/blocked-upstream (see the "Dependency Overrides - Security Fixes" section, items 1, 2, and 5) — but the workflow's ignore: list was never updated to match that write-up, so the job kept failing on findings that had already been triaged:

• RUSTSEC-2024-0437 — protobuf 2.28.0 via prometheus 0.13 ← pingora-core 0.8.x. The vulnerable recursive-parse path is compiled in, but pingora only ever emits metrics via TextEncoder, never parses protobuf-encoded input — not reachable. Blocked upstream: both pingora-core 0.8.0 and the latest 0.8.1 still pin prometheus ^0.13, and a [patch.crates-io] to protobuf 3.x doesn't compile against prometheus 0.13's generated code.
• RUSTSEC-2023-0018 — remove_dir_all 0.5.3 via tempdir ← nixpacks 1.41.0 (still crates.io latest). The TOCTOU race only fires in nixpacks' implicit-output-dir branch; temps-presets always passes an explicit out_dir, so that branch is dead code here.
• RUSTSEC-2023-0071 (Marvin Attack) — rsa 0.9.10 via jsonwebtoken ← octocrab (GitHub App JWT) / openidconnect (OIDC). No fixed rsa release exists upstream at all yet. Our usage is RS256 JWT sign/verify, not the private-key decryption path the timing side-channel targets, and the signing key isn't exposed to a remote timing oracle.

I re-verified all three reachability claims still hold against main as of today before ignoring them, added the three RUSTSEC IDs to the cargo-audit step's ignore: list (mirroring the existing "unmaintained crate" entries), and cross-referenced the workflow comment back to the Cargo.toml section so the two don't drift again. Confirmed locally: cargo audit with the updated ignore list now exits 0 against this branch's Cargo.lock.

Didn't touch anything else on the branch (web-audit / container-scan jobs untouched) — just the cargo-audit job that was linked.

[dviejokfs]

Correction to my previous comment — after posting the cargo-audit fix, I ran a security-auditor pass specifically on the RUSTSEC-2023-0071 (rsa/Marvin Attack) risk-acceptance, since that's a real unfixed CVE and I wanted an independent check before letting it stand. It found my initial write-up (copied from this branch's existing Cargo.toml comment) was incomplete in two ways, now fixed in da3b5e94 [latest commit]:

1. Missing dependency path. crates/temps-dns/src/providers/gcp.rs uses the rsa crate directly (RsaPrivateKey + pkcs1v15::SigningKey) to sign GCP Cloud DNS service-account JWTs. Neither the original Cargo.toml comment nor my first pass mentioned this — only the jsonwebtoken <- octocrab/openidconnect path was documented. It's a real gap in the risk record.

2. Imprecise framing. The Marvin Attack is specifically a chosen-ciphertext attack against RSA decryption (a Bleichenbacher-style padding oracle). My first comment blurred signing and decryption together. Temps has zero RSA decryption usage anywhere — only signing, on 4 call sites total (3 GitHub App JWT paths in temps-git, 1 GCP DNS JWT path in temps-dns). That's a real but much narrower and harder-to-exploit timing side-channel than what the CVE title suggests.

The bottom line is unchanged — the security-auditor's verdict is "approve with follow-up": ignoring RUSTSEC-2023-0071 in CI is still justified, because (a) no RSA decryption exists to serve as a chosen-ciphertext oracle, (b) the signing operation's timing is buried inside 100-500ms of network I/O to GitHub/GCP that a remote attacker can't isolate to nanosecond precision, (c) the signed payload isn't attacker-controlled, and (d) each key is customer-supplied (their own GitHub App / GCP service account), not a shared temps secret, so blast radius is bounded per-customer even in a worst case. No fixed rsa release exists upstream yet regardless.

I've updated both Cargo.toml and the workflow comment to list all 3 dependency paths accurately and added a tracked follow-up: monitor upstream rsa for a constant-time release, and evaluate migrating both signing paths to ring/aws-lc-rs-backed signing instead of waiting on that.

Re-verified locally after this correction: cargo audit with the ignore list still exits 0. Sorry for the churn — wanted to flag this rather than leave inaccurate security reasoning sitting in the repo.

[dviejokfs]

could you review the PR after the fixes? @bherila

[bherila]

fixes LGTM, thank you @dviejokfs