also looking at this
Gate SBOM findings on whether they ship
#321
5 files
+230
-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.
| @@ -283,7 +283,7 @@ jobs: | ||
| 283 | 283 | run: zig fmt --check src/ build.zig |
| 284 | 284 | |
| 285 | 285 | - name: Test failure-safe vulnerability scanning |
| 286 | run: bun test scripts/scan-sbom.test.ts scripts/scan-release-artifacts.test.ts | |
| 286 | run: bun test scripts/scan-sbom.test.ts scripts/scan-release-artifacts.test.ts scripts/sbom-scope.test.ts | |
| 287 | 287 | |
| 288 | 288 | - name: Audit Zig C imports |
| 289 | 289 | run: bun run verify:cimports |
| @@ -129,6 +129,12 @@ jobs: | ||
| 129 | 129 | env: |
| 130 | 130 | CRAFT_FAIL_HIGH: ${{ inputs.enforce_high || false }} |
| 131 | 131 | |
| 132 | # Always on, unlike enforce_high. Fails when a High or Critical finding is | |
| 133 | # not confined to paths that publish nothing, and prints the tooling | |
| 134 | # inventory otherwise so the count stays visible rather than silent. | |
| 135 | - name: Require High findings to be tooling-only | |
| 136 | run: bun scripts/sbom-scope.ts scan-results/vulnerabilities.json | |
| 137 | ||
| 132 | 138 | - name: Upload scan results |
| 133 | 139 | if: ${{ always() }} |
| 134 | 140 | uses: actions/upload-artifact@v4 |
| @@ -25,6 +25,32 @@ 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 | 26 | full-source review. |
| 27 | 27 | |
| 28 | ## Shipping scope for SBOM findings | |
| 29 | ||
| 30 | The full-repository scan inventories the whole checkout, which includes the benchmark | |
| 31 | comparison apps and the development install. Every High finding in it today originates | |
| 32 | there: the Electron and Electrobun benchmark lockfiles, and the Go runtime compiled | |
| 33 | into the TypeScript compiler binary under `node_modules`. | |
| 34 | ||
| 35 | `scripts/sbom-scope.ts` decides by location. A High or Critical finding whose every | |
| 36 | recorded path lies under a prefix that publishes nothing — `/benchmarks/`, | |
| 37 | `/node_modules/`, `/examples/`, `/artifacts/`, `/.github/` — is tooling inventory, and | |
| 38 | is reported with its package list. Anything else fails the scan, including a finding | |
| 39 | with no recorded location, since an unlocatable High deserves review rather than a | |
| 40 | pass. A package appearing both in a benchmark and in Craft counts as Craft's. | |
| 41 | ||
| 42 | This runs unconditionally, unlike the `enforce_high` input, which remains available as | |
| 43 | a stricter opt-in that fails on any High regardless of where it sits. | |
| 44 | ||
| 45 | A path rule rather than a list of retained findings is deliberate: benchmark lockfiles | |
| 46 | and `node_modules` versions change constantly, so entries pinned to a package and | |
| 47 | version would go stale within days and the check guarding them would fire on every | |
| 48 | benchmark bump. Lockfile advisories are different — they are few and slow-moving — and | |
| 49 | they do use reviewed retentions, below. | |
| 50 | ||
| 51 | The shipped half of the division is `scripts/scan-release-artifacts.ts`, which scans | |
| 52 | the exact release archives with their resolved production dependencies. | |
| 53 | ||
| 28 | 54 | ## Reviewed advisory retention |
| 29 | 55 | |
| 30 | 56 | Lockfile advisories are decided rather than counted. `scripts/advisory-policy.ts` |