[0x73746F66]

Problem

On pushes to main, every job in vulnetix.yml spends one hourly GitHub API quota: the repository's job token. On the push that merged #341 (run 43458567106):

• At 16:04:54 the analyze preflight logged 4,913/5,000 requests remaining.
• At 16:08:18 the SCA go job logged code scanning sca/not-go: upload failed: GitHub API rate limit exhausted.
• When the forge pass ran, it found 0 of 5000 requests left.

#339 and #341 only made analyze cope with a spent quota. This PR removes what spends it.

Root cause: the licence lookups in the scan jobs

Every scanner that resolves licences asks GitHub about each package that the Vulnetix store, the registry and deps.dev left UNKNOWN. Measured locally on this repository with the network stubbed out, one vulnetix license run sends 72 distinct names to the GitHub stage:

• 46 of the 72 cannot be repositories at all. They are the 45 $/… entries from actions-e2e.yml's uses: $/sbom, **/*.{css,scss,less} and <your.
• Each name ran the whole chain. That is about 14 requests through gh (repo, /license, 11 blind contents/LICENSE* fetches, the listing), then 12 more on the "PAT fallback" with GITHUB_TOKEN. That second pass is the same token, because gh already sends GITHUB_TOKEN. A 404 never ended the chain early.
• Nothing stopped on a 403, and with a PAT set no miss was ever stored.
• Six processes repeat this on each push: sca (two steps), license, sbom, and the sbom prior steps of the upload and bom-validate extras. The prior steps take the action's default token even on pull requests.

That comes to roughly 1,400 requests per process, which matches 4,913 requests gone in under 3.5 minutes. Scans run with ghactx NoAPI: true, so apart from publishing, the licence lookups are the only GitHub API traffic the scan jobs make.

Fix

• internal/ghquota: the forge budget from fix(analyze): bound the forge pass to half the token quota and a short window in CI #339 and fix(analyze): a spent GitHub quota at preflight skips the forge pass instead of failing the run #341 is moved here unchanged and shared, and forge keeps its names through aliases. It gains:
  • Keep(share) and Hint(...);
  • ObserveHTTP, which reads X-RateLimit-* and treats a primary or secondary rate-limit 403, or any 429, as a refusal (through go-github's CheckResponse and IsRateLimit);
  • Seed, which takes the free /rate_limit answer;
  • Spend, for the gh-process path.
• internal/license:
  • validOwnerRepo drops impossible names before any request.
  • The chain is repository → /license → root listing plus the files it names. A repository 404 ends it, so a repository costs 1–4 requests.
  • There is no duplicate token pass.
  • Every request goes through githubGet / ghAPICall, which spend from one budget. Inside GitHub Actions that budget keeps 80% of the limit (it stops at 4,000 of 5,000), which leaves room above the forge pass's 50%. Every job sees the same remaining count, so the floor holds for the whole run.
  • A rate-limit answer stops every later lookup. Unchecked licences stay UNKNOWN, with a single warning that names how many.
  • In Actions each batch logs GitHub licence lookups: N requests for M repositories (R of L left), so the run logs now carry per-job counts.
  • The dead FetchLicenseFromGitHub copy of the chain is removed.
• gha init: a scanner run as an extra's prior step gets github-token: "", because it only writes the file the extra reads. vulnetix.yml is regenerated (three prior steps change).

Tests

• TestLookupChainCost pins the request count for each repository shape.
• TestNamesThatCannotBeRepositoriesNeverReachGitHub
• TestLookupsKeepTheirShareInGitHubActions
• TestLookupsSpendNothingBelowTheFloor
• TestRateLimitAnswerStopsLookups
• ghquota tests cover the HTTP headers, secondary limits, Keep and Seed.
• TestPriorScannerStepsGetNoToken

go test ./internal/... passes (83 packages), and so do the cmd and actiongen tests.

A live run of the new binary against a token whose core quota was already at 0 made no lookup requests (the /rate_limit seed stopped it) and printed the warning.

Follow-up

vulnetix.yml installs the CLI at its pinned action ref, so the CLI fix reaches this repository's CI only after the release is cut and the pin is bumped, as #340 did after #339.

[github-actions]

Vulnetix config plan

Manager gitops:vulnetix/cli, prune off, plan hash a8bd984f1753c68b180298051dd9e2524ab644d2ebe9e4c7c811ff4126753b5f

	Object	Action	Changes
~	QualityGate/default	update (adopt)	severity: null -> "high"

0 to create, 1 to update, 0 to delete, 0 unchanged