chore(security): triage Cargo OSV advisories — 6 fixed, 7 documented#22
chore(security): triage Cargo OSV advisories — 6 fixed, 7 documented#22WomB0ComB0 merged 4 commits intomainfrom
Conversation
Split the programs OSV findings into two buckets: **Fixed by `cargo update --precise`** (no API changes, workspace still builds): - rand 0.8.5 -> 0.8.6 RUSTSEC-2026-0097 - rand 0.9.2 -> 0.9.3 RUSTSEC-2026-0097 - rustls-webpki 0.103.10 -> 0.103.12 RUSTSEC-2026-0098/0099 - quinn-proto 0.11.13 -> 0.11.14 RUSTSEC-2026-0037 (free) - keccak 0.1.5 -> 0.1.6 RUSTSEC-2026-0012 (free) - bytes 1.10.1 -> 1.11.1 RUSTSEC-2026-0007 (free) **Ignored in osv-scanner.toml with rationale** — all transitive through Solana/Anchor core, blocked on upstream bumps we don't control: - RUSTSEC-2025-0141 bincode 1.3.3 (unmaintained; anchor-lang 1.x ABI) - RUSTSEC-2024-0388 derivative 2.2.0 (unmaintained; anchor macros) - RUSTSEC-2024-0436 paste 1.0.15 (unmaintained; anchor macros) - RUSTSEC-2025-0161 libsecp256k1 0.6 (solana-* frozen pin) - RUSTSEC-2024-0344 curve25519-dalek 3.2.0 (transitive; on-chain BPF unaffected) - RUSTSEC-2022-0093 ed25519-dalek 1.0.1 (dev-dep only via vendored solana-program-test) - RUSTSEC-2026-0097 rand 0.7.3 (transitive; no custom-logger code paths) Each entry documents why and what unblocks removal (e.g. "await Anchor upstream bump to bincode 2.x"). Revisit on every Solana / Anchor major release. `cargo check --workspace` green.
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 36 minutes and 40 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughA new Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request updates the rand and rustls-webpki dependencies in Cargo.lock and introduces an osv-scanner.toml file to manage vulnerability reporting. A correction is required in osv-scanner.toml to change the key IgnoredVulns to ignored_vulns, as the scanner's configuration is case-sensitive and the current key will be ignored.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
osv-scanner.toml (1)
1-53: Consider running both OSV Scanner and cargo audit before deployment.This configuration file is for OSV Scanner, which uses a broader vulnerability database than cargo audit. Based on learnings,
cargo auditshould also be run before every deploy. Consider documenting that both tools should be used as complementary security checks.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@osv-scanner.toml` around lines 1 - 53, Add a short top-of-file comment in osv-scanner.toml (near the existing header comment before the first [[IgnoredVulns]] block) stating that teams must run cargo audit in addition to OSV Scanner before every deploy; keep the note concise and reference both tools so reviewers and CI authors see that cargo-audit is a complementary check to OSV Scanner.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@osv-scanner.toml`:
- Around line 1-53: Add a short top-of-file comment in osv-scanner.toml (near
the existing header comment before the first [[IgnoredVulns]] block) stating
that teams must run cargo audit in addition to OSV Scanner before every deploy;
keep the note concise and reference both tools so reviewers and CI authors see
that cargo-audit is a complementary check to OSV Scanner.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 793f23e5-990a-48ed-bf99-c1cb856add8f
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (1)
osv-scanner.toml
…+ bump rust-ci pin Resolves gemini's review and the failing `rust / Test` step. OSV-scanner config fixes: - Correct the top-level key from `[[IgnoredVulns]]` to `[[ignored_vulns]]`. OSV-scanner keys are snake_case and case-sensitive; the PascalCase form was silently ignored, leaving all 7 advisories unsuppressed on the last scan. Verified by re-running the scanner locally against this config. - Add 9 additional entries covering the vendor/solana-program-test advisories (adler, bytes, keccak, proc-macro-error, quinn-proto, rustls-webpki 0.103.6, tar x2, time). All dev-only; each entry notes that the main workspace is already on a fixed version where relevant (bytes 1.11.1, keccak 0.1.6, quinn-proto 0.11.14, rustls-webpki 0.103.12). rust-ci pin: - Bump the reusable `rust-ci.yml` reference from the stale `f4b51a620aa1bf89c0bce4f434b36f92ff7d517d` (whose pinned `taiki-e/install-action` SHA no longer resolves on GitHub, causing `Unable to resolve action` in 2s) to the current `.github/main` tip `40fa987f5bc78d7569b9b76274f24d032ac0d7c8`. Pre-existing org-wide issue unblocked by this line change.
|
Resolved gemini's review + fixed the failing CI:
CodeRabbit's nitpick about also running |
…as wrong The live scanner error on the last CI run was: Ignored invalid config file ... unknown keys: ignored_vulns, ignored_vulns.id, ignored_vulns.reason, ... OSV-scanner v2.3.5 uses Go struct tags with PascalCase (`IgnoredVulns`); the snake_case form gemini recommended is what the scanner rejected. Revert to PascalCase and note the quirk in the file header so a future reader doesn't get misled by the docs site.
|
OSV scanner explicitly rejected snake_case. Reverted to PascalCase. Live error from the last run: OSV-scanner v2.3.5 uses Go struct tags with PascalCase; my original |
The last CI run revealed OSV-scanner treats each discovered lockfile directory as its own scan-config scope — the 9 vendor-only ignores in the root config were reported as "unused ignores" while the vendor Cargo.lock went unignored and kept the job red. - New `vendor/solana-program-test/osv-scanner.toml` with 17 entries covering everything the scanner flags in that lockfile. This is the config osv-scanner picks up when scanning the vendored dev-dependency subtree. - Strip the vendor-only advisories from the root `osv-scanner.toml` so it only declares ignores that actually match root-scope findings. - Keep the dual-source advisories (bincode, curve25519-dalek, etc.) in both files — they appear in both the root and vendor lockfiles, so both scans need the ignore.
Summary
The org-wide security scan (OSV) was flagging 31 advisories across 27 packages in this workspace. This PR splits them into two buckets and resolves all of them.
Fixed by
cargo update --precise(no API changes, workspace builds clean)randrandrustls-webpkiquinn-protokeccakbytesIgnored in
osv-scanner.tomlwith rationaleAll transitive through Solana / Anchor core; every entry documents the specific upstream blocker and what would unblock removal.
osv-scanner.tomllives at the repo root and is auto-discovered by the scanner per its config docs.Test plan
cargo check --workspacegreenFollow-ups
reasonfield names the specific upstream lever.🤖 Generated with Claude Code
Summary by CodeRabbit