deps lane scans nothing: .gitignore hides the tracked Cargo.lock from osv-scanner

[bdelanghe]

---

kind: task
effort: 2
value: 75

The deps lane has never scanned this repo's Rust dependencies. It reports green because it finds no lockfiles at all, not because the lockfile is clean.

From the last scheduled run on main (2026-08-04, run 30899021017):

Scanning dir .
Starting filesystem walk for root: /
End status: 170 dirs visited, 1617 inodes visited, 0 Extract calls, 43.29ms elapsed
No package sources found
No issues found

0 Extract calls with Cargo.lock sitting at the repo root.

Root cause

.gitignore:7 lists Cargo.lock, under # Global build artifacts:

target/
Cargo.lock

The file is tracked, so git exempts it — the rule is inert for git, git status is clean, and nothing looks wrong. But osv-scanner respects .gitignore patterns directly and does not model git's tracked-file exemption, so it skips the repo's only lockfile. --allow-no-lockfiles then converts "scanned nothing" into exit 0.

Confirmed with git check-ignore, which shows the divergence directly:

$ git check-ignore -v Cargo.lock            # respects the index
  (no output — not ignored, because it is tracked)

$ git check-ignore --no-index -v Cargo.lock # what a plain pattern-matcher sees
  .gitignore:7:Cargo.lock	Cargo.lock

Not a fault in the shared lane. front-desk-scheduler runs the byte-identical deps.yml and reports 3 Extract calls, including a Cargo.lock with 31 packages. It simply has no such .gitignore line.

What it cost

Sixteen live advisories sat behind a green hard-fail check for months. Measured via the OSV API against the versions on main:

package	version on main	advisories
rustls-webpki	0.103.4	8, incl. GHSA-82j2-j2ch-gfr8, RUSTSEC-2026-0049/0098/0099/0104
openssl	0.10.73	8

The oldest was published 2026-03-20 — months of green scans over known-vulnerable versions. #90 and #88 were open the whole time and read as routine chores rather than as a lane failure, because nothing contradicted them.

The fix

Remove Cargo.lock from the generator, not just from .gitignore — it is baked into two places in crates/xtask/src/main.rs, so editing the file alone would be undone by the next gen-config:

1. generate_full_gitignore() — the full template (~line 10550)
2. the --minimal ignorable_patterns list (~line 10681), which is what produced the current file

Then regenerate and update the @checksum header.

A workspace with a committed Cargo.lock should not be ignoring it in either mode; the entry looks like a default carried over from the library case, where Cargo.lock genuinely is not committed.

Sequence this after the advisories are cleared. #107 bumps both to clean versions; unblinding the scanner before that lands would red-line a hard-fail lane on main. After #107, expect the first honest scan to surface whatever else is in the remaining ~225 packages — that is the point, and better learned on a PR than on main.

Worth checking fleet-wide

deps.yml is a standardized org-wide caller, copied byte-identical. Any other repo whose .gitignore lists its lockfile has the same silent hole. 0 Extract calls / No package sources found is the tell — a scan reporting green with nothing scanned should be distinguishable from a scan reporting green having scanned something, and right now it is not. That is the #112 shape: nothing is broken, nobody had checked that it ran.

[bdelanghe]

Measured what the blind scan is actually hiding. This issue guessed "expect the first honest scan to surface whatever else is in the remaining ~225 packages" — here are numbers, read from origin/main's Cargo.lock after #107 landed and queried against the OSV API:

package	version on main	advisories
wasmtime	18.0.4	28
wasmtime-wasi	18.0.4	5
rand	0.8.5	2

35 more, live on main right now, on top of the 16 #107 just cleared. All three have had open Dependabot PRs the whole time — #109 (wasmtime → 24.0.7), #91 (wasmtime-wasi → 24.0.9), #89 (rand → 0.8.6) — and all three read as routine chores for the same reason #90 and #88 did: nothing contradicted them, because the lane that would have was scanning nothing.

wasmtime is the sharp one. It is this repo's reason for existing ("Build Rust binaries into Lefthook hooks with WASM components"), it is six major versions behind, and 28 advisories is the largest single concentration here. That is not a lockfile nudge like #107 was — 18.x → 24.x is a real upgrade with API surface to work through, so it wants its own item and its own estimate.

This changes the sequencing advice in the issue body. I wrote that #107 should land first so the scan does not go "blind straight to red." That was right about #107 and wrong as a general rule: clearing 16 did not make main clean, it left 35. So fixing the .gitignore now will red-line the hard-fail lane, and it should — that is the lane finally telling the truth. The choice is between a red lane and a blind one, not between red and green.

Suggested order:

1. This issue — unblind the scanner and accept the red. A lane that reports green while scanning nothing is worse than one that reports red accurately.
2. chore(deps): bump rand from 0.8.5 to 0.8.6 #89 (rand, 2 advisories) — almost certainly a lockfile bump like chore(deps): bump openssl to 0.10.81 and rustls-webpki to 0.103.13 #107.
3. chore(deps): bump wasmtime-wasi from 18.0.4 to 24.0.9 #91 / chore(deps): bump wasmtime from 18.0.4 to 24.0.7 #109 (wasmtime, wasmtime-wasi, 33 between them) — the real work.

Also worth re-reading the value: 75 in the frontmatter: this issue is not "tidy up a scanner config," it is the reason 51 advisories went unnoticed across two quarters.

---

Generated by Claude Code