feat: upload bakery trivy scan SARIF to GitHub code scanning - #734
Draft
bschwedler wants to merge 6 commits into
Draft
feat: upload bakery trivy scan SARIF to GitHub code scanning#734bschwedler wants to merge 6 commits into
bschwedler wants to merge 6 commits into
Conversation
This was referenced Aug 11, 2026
Test Results2 346 tests 2 346 ✅ 9m 9s ⏱️ Results for commit c84c966. ♻️ This comment has been updated with latest results. |
bschwedler
force-pushed
the
feat/trivy-sarif-code-scanning
branch
2 times, most recently
from
August 11, 2026 19:10
d4a933d to
26ac4e4
Compare
bschwedler
force-pushed
the
feat/trivy-security-scan
branch
from
August 28, 2026 19:11
15d4167 to
df4f352
Compare
bschwedler
force-pushed
the
feat/trivy-sarif-code-scanning
branch
from
August 28, 2026 19:11
26ac4e4 to
15ee405
Compare
Add a `latest` boolean to each `bakery ci matrix` entry, alongside the existing `dev` field, so CI workflows can gate per-version steps on whether a version is the latest release of its image. Without it, a workflow whose matrix has already pinned one version has no way to express "only act on the latest one" except by passing --latest to the pinned command. Those two filters intersect to nothing on every non-latest version, which bakery reports as an error rather than as the intentional no-op the caller meant. The value comes from ImageVersion.is_latest_release, which is also what the --latest filter calls via matches_latest_filter. A workflow gating on the field and a command using the filter always select the same versions; there is no second copy of the rule that could drift. is_latest_release is a plain property rather than a computed_field: ImageVersion is round-tripped into bakery.yaml via model_dump, and a computed field would write a derived key into the user's config.
Ports Trivy scanning from images-shared issue #218. Adds a bakery plugin for running `trivy image` scans and wires it into the native build workflow. Scans gate on `matrix.img.latest` so only the latest version of each image is scanned on production pushes, matching the Wiz scan policy. The existing Scan step is renamed to Wiz Scan for clarity. Trivy runs after Wiz Scan (and after Test, for the same reason: Test's `docker run` is what makes every target addressable in the local daemon). The Trivy version is pinned in setup-trivy/action.yml with no runtime override; updates go through Renovate so every bump has a human review. Co-authored-by: feat/trivy-security-scan
The Wiz Scan step passed --latest to a `bakery wizcli scan` already pinned to one version by the build matrix. On every non-latest version those two filters resolved to an empty target set, so bakery exited 1; continue-on-error hid it as a red annotation on an otherwise green job. Gate the step on (dev-versions == 'only' || matrix.img.latest) and drop LATEST_FLAGS. The decision is now made once at matrix generation time rather than per job from a filter combination that cannot match. Also fix _describe_active_filters (cli/common.py) to include --latest when set (it was omitted because False is falsy, so the one filter that emptied the selection was the one never shown) and render --image-platform as a string rather than a Python list repr.
`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 28, 2026 19:26
15ee405 to
c84c966
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.