also looking at this
Decide dependency advisories instead of counting them
#320
6 files
+324
-1
Review threads live on the whole diff, not on one commit, so none are shown here - a thread's line means something in the branch's final form, and painting it into an intermediate step would put it on code it is not about.
| @@ -297,6 +297,15 @@ jobs: | ||
| 297 | 297 | - name: Test agent environment briefing |
| 298 | 298 | run: bun test scripts/agents-guidelines.test.ts |
| 299 | 299 | |
| 300 | - name: Test dependency advisory policy | |
| 301 | run: bun test scripts/advisory-policy.test.ts | |
| 302 | ||
| 303 | # Reads the registry, so this is the step that turns a newly published | |
| 304 | # advisory into a red build rather than a larger number in a report. | |
| 305 | # Clearing it is one reviewed entry in scripts/retained-advisories.ts. | |
| 306 | - name: Review dependency advisories | |
| 307 | run: bun scripts/advisory-policy.ts | |
| 308 | ||
| 300 | 309 | - name: Test merged SBOM inventory |
| 301 | 310 | run: bun test scripts/merge-sbom.test.ts |
| 302 | 311 | |
| @@ -22,6 +22,11 @@ jobs: | ||
| 22 | 22 | - name: Validate tag and workspace versions |
| 23 | 23 | run: bun scripts/release-version.ts |
| 24 | 24 | |
| 25 | # A release must not carry an advisory nobody has reviewed, or a review | |
| 26 | # that expired while the release was being prepared. | |
| 27 | - name: Review dependency advisories | |
| 28 | run: bun scripts/advisory-policy.ts | |
| 29 | ||
| 25 | 30 | release-sbom: |
| 26 | 31 | needs: validate-release |
| 27 | 32 | uses: ./.github/workflows/sbom.yml |
| @@ -23,7 +23,31 @@ tracks the reviewed High/Critical policy and shipping-scope analysis; issue | ||
| 23 | 23 | [#276](https://github.com/craft-native/craft/issues/276) tracks locked dependency |
| 24 | 24 | advisories. Native binary scanning records exact hashes and detected components, |
| 25 | 25 | but static Zig code may not be identifiable from the binary alone; retain the |
| 26 | full-source review. No baseline or vulnerability exemption is added by this workflow. | |
| 26 | full-source review. | |
| 27 | ||
| 28 | ## Reviewed advisory retention | |
| 29 | ||
| 30 | Lockfile advisories are decided rather than counted. `scripts/advisory-policy.ts` | |
| 31 | reads `bun audit --json` and fails when an advisory has not been reviewed, when a | |
| 32 | review has passed its expiry, when a retained entry no longer matches any current | |
| 33 | advisory, and on any High or Critical finding, which can never be retained. It runs | |
| 34 | in CI on every pull request and again in `validate-release`, so a release cannot | |
| 35 | carry an unreviewed advisory. | |
| 36 | ||
| 37 | Retentions live in `scripts/retained-advisories.ts`, one entry per advisory, each | |
| 38 | answering a single question: by what path would an installed Craft package reach | |
| 39 | this code? An advisory that reaches a published artifact is fixed instead of | |
| 40 | retained. Entries carry a review date and an expiry so that the reasoning is | |
| 41 | re-examined rather than inherited. | |
| 42 | ||
| 43 | A newly published advisory therefore turns the build red until someone either | |
| 44 | fixes it or writes down why it is unreachable. That is deliberate: the previous | |
| 45 | arrangement reported a count and stayed green, so a new finding was invisible. | |
| 46 | ||
| 47 | `bun audit fix` is not part of any gate. It is willing to *downgrade* a package so | |
| 48 | that it falls below an advisory window rather than upgrading past it, and reports | |
| 49 | that as a fix, so remediation stays a reviewed decision. Dependency updates go | |
| 50 | through buddy-bot. | |
| 27 | 51 | |
| 28 | 52 | Syft and Grype Linux x64 downloads are pinned by release version and SHA-256 in |
| 29 | 53 | `.github/workflows/sbom.yml`. Tool updates must update both the asset URL and its |