Upload the weekly Grype scan under the PR gate's SARIF category - #1502
Merged
Merged
Conversation
The weekly scan published its SARIF under its own code-scanning category, grype-scheduled, while ci.yml's grype-scan uploads under grype-sandbox-image. GitHub Advanced Security expects every category it has seen on the default branch to report on every PR, and the weekly workflow runs only on its cron and on workflow_dispatch, so each PR has shown a skipped "grype" check with "1 configuration not found" since the weekly lane first ran. The weekly upload now shares grype-sandbox-image; the workflow comment says why, and docs/TESTING.md records the shared-category semantics (one result set per tool, category and commit, so the weekly upload for the tip of main replaces the push run's) and the one-time deletion of the recorded grype-scheduled analyses that has to follow, since renaming the category does not retire a configuration GitHub already knows. The scans themselves are unchanged: the per-PR gate and its policy, the weekly rebuild, its report-all posture and its SARIF upload all stay. govulncheck-scheduled.yml is deliberately untouched. SECURITY.md already named only the shared category and the workflow file, so it needed no change. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
4 tasks
bradflaugher
added a commit
that referenced
this pull request
Sep 14, 2026
… keeps its cron-only SARIF category (#1503) ## What changed, and why Two leftovers from #1501 and #1502. **`GET /tasks/tags` in `docs/openapi.yaml`** still described a global catalogue. Since #1501 the endpoint requires `view_tasks` and is scoped by the same own-rows rule as `GET /tasks` (#1082): a non-admin user or scoped API key gets only the tags on tasks it created, with counts over those tasks, while the admin key, `PermissionAdmin` carriers and `view_all_logs` holders get the fleet-wide catalogue. The summary now says so in the same words the `/tasks` entry uses, so an API consumer does not mistake an omitted tag for a nonexistent one. **The govulncheck cron category is correct and now says why.** #1502 moved the weekly Grype upload onto the PR gate's category because GitHub expected the cron-only `grype-scheduled` configuration on every PR. `govulncheck-scheduled.yml` looks like the same shape, but is not: the per-PR govulncheck step in `ci.yml` runs the scan and uploads no SARIF, so this lane is the only govulncheck upload, there is no PR-side category to share, and GitHub shows no missing-configuration check for it (confirmed on #1501 and #1502, where only the Grype phantom appeared). The workflow comment and `docs/TESTING.md` record that so the category is not renamed by analogy. No scan command, schedule or alarm changed. ## How you verified it - `make lint` including actionlint over the edited workflow: clean. - `go test -tags fleet_host_executor -count=1 ./scripts/`: PASS. - Checked `gh pr checks` on #1501 and #1502: no "govulncheck" configuration-not-found check, only the Grype one that #1502 removed. - Reviewed once locally by Codex before opening. ## Scope and deviations Docs and one workflow comment only; no runtime, gate or schedule change. The alternative of making the PR gate emit SARIF under a shared category was not taken: it would change the per-PR gate for no visible defect. --- - [x] The title and "What changed, and why" are written for the release notes they become - [x] A design note (`docs/<FEATURE>.md`) added, if this ships a feature — not a feature - [x] An ADR added or superseded in `docs/adr/`, if this adds, weakens or reverses an invariant — none touched - [x] The diff is scoped to one change (no unrelated refactors) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
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.
What changed, and why
The weekly Grype scan (
.github/workflows/grype-scheduled.yml) uploaded its SARIF under its own code-scanning category,grype-scheduled, while the per-PRgrype-scanjob inci.ymluploads undergrype-sandbox-image. GitHub Advanced Security remembers every category it has seen on the default branch and expects each one to report on every PR; the weekly workflow runs only on its cron and onworkflow_dispatch, so every PR has shown a skipped "grype" check with "1 configuration not found" since the weekly lane first ran. The weekly upload now usesgrype-sandbox-image, the same category as the PR gate, with a comment recording why a distinct category is the wrong shape here.docs/TESTING.mdno longer names agrype-scheduledcategory and records the shared-category semantics (one result set per tool, category and commit, so the weekly upload for the tip ofmainreplaces the push run's) plus the one-time cleanup below.SECURITY.mdalready named onlygrype-sandbox-imageand the workflow file, so it needed no change.Nothing about the scans themselves changes: the per-PR gate and its policy are untouched, the weekly scan still runs, still reports all findings including unfixed ones, and still uploads SARIF.
govulncheck-scheduled.ymlis deliberately left alone.How you verified it
make lint(includes actionlint and shellcheck over the workflows): clean.go test -tags fleet_host_executor -count=1 ./scripts/(docs-index and pinned-docs checks): PASS.grep -rn grype-scheduled docs SECURITY.md .githubshows only the workflow's file name and job name, no category.Scope and deviations
Scoped to the category string, its comment, and the two doc mentions. After merge, the four existing
grype-scheduledanalyses onrefs/heads/mainare deleted through the code-scanning API, newest first, the last withconfirm_delete=true; until then PRs keep showing the missing-config check.grype-sandbox-imageand CodeQL analyses are not touched.govulncheck-scheduled.ymlhas the same shape (its owngovulncheck-scheduledcategory, four analyses on main) and is out of scope here by request.docs/<FEATURE>.md) added, if this ships a feature — not a feature; the change is recorded indocs/TESTING.mddocs/adr/, if this adds, weakens or reverses an invariant — none touched🤖 Generated with Claude Code