feat: upload bakery trivy scan SARIF to GitHub code scanning - #734
Draft
bschwedler wants to merge 3 commits into
Draft
feat: upload bakery trivy scan SARIF to GitHub code scanning#734bschwedler wants to merge 3 commits into
bschwedler wants to merge 3 commits into
Conversation
This was referenced Aug 11, 2026
Test Results2 147 tests 2 147 ✅ 8m 2s ⏱️ Results for commit 26ac4e4. ♻️ This comment has been updated with latest results. |
bschwedler
force-pushed
the
feat/trivy-sarif-code-scanning
branch
from
August 11, 2026 18:35
8a8a0fd to
d4a933d
Compare
`bakery trivy scan` needs two different identifiers per target, and the previous design conflated them. The code-scanning category must omit the version so a PR can be diffed against its baseline, but the results filename must include it or two versions of one image overwrite each other -- 50 connect targets collapsed onto 6 files. Split them. results_file stays keyed on image_target.uid; scan_category is stamped into each run's automationDetails.id as "<category>/". upload-sarif only fills automationDetails in when it is absent, so a single directory upload can carry a distinct category per file, which is what code scanning has required since runs sharing a category stopped being combined in July 2025. The category's architecture now comes from the platform the CLI actually resolved rather than the host's. A target is not platform-scoped (image_os.platforms is a list), so host arch was only correct for native scans and mislabelled every cross-arch scan.
Re-adds the security-events: write grant and the upload step held back from #722, now that the category no longer has to be smuggled through the SARIF filename. Uses github/codeql-action/upload-sarif rather than a hand-rolled `gh api` loop. The action handles gzip/base64 and validation, and it surfaces a 403 instead of swallowing it the way the previous `|| true` did. No `category:` input is passed, because each file already supplies its own via automationDetails.id -- passing one would give every run in the directory the same category, which code scanning rejects. Deliberately not added to bakery-build-pr.yml. Fork PRs get a read-only token, so a job requesting security-events: write there would fail for exactly the contributors that workflow's Detect Fork job exists to support. Main also only analyses latest versions, so PR-time uploads of older versions would have no baseline and would report every finding as new. Merging this requires the three product repos to grant security-events: write to their calling jobs first, per #729.
Keeps only why `category:` is omitted; the mechanism is in the commit that introduced the stamping.
bschwedler
force-pushed
the
feat/trivy-sarif-code-scanning
branch
from
August 11, 2026 19:10
d4a933d to
26ac4e4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Splits the GitHub code-scanning half of #722 into its own PR so that one can merge without breaking every caller.
bakery trivy scanneeds two identifiers per target that #722 conflated into one string: a version-stable category, so code scanning can diff a PR against its baseline, and a unique filename, so two versions of an image don't overwrite each other. Keying the filename off the category collapsed 50images-connecttargets onto 6 SARIF files. Here the filename stays uid-keyed and the category rides in each run'sautomationDetails.id, whichupload-sarifpreserves — so one directory upload carries a distinct category per file.Not wired into
bakery-build-pr.yml: fork PRs get a read-only token, so requestingsecurity-events: writethere would fail for exactly the contributors that workflow'sDetect Forkjob exists to support. Main also only analyses latest versions, so PR-time uploads of older versions would have no baseline and would report every finding as new.Do not merge before the three product repos grant
security-events: writeto their calling jobs. That ordering is what #729 tracks; merging early reproduces the failure this split exists to avoid.