ci: attest provenance/SBOM and Grype-scan the built rock - #80
Conversation
Adds a new `attest-and-scan` job between test and upload-ghcr in the tag-triggered publish pipeline: - Syft (anchore/sbom-action) generates an SPDX SBOM from the OCI archive produced by oci-factory Build-Rock. - actions/attest emits a signed SLSA build-provenance attestation for the rock (auto-generated predicate — provenance mode). - actions/attest emits a signed SBOM attestation with the SPDX predicate against the same rock subject. - Grype (anchore/scan-action) scans the SBOM and fails the build on vulnerabilities of severity high or above. Notes: - Uses actions/attest@v4 directly rather than the attest-build-provenance wrapper — per the v4 release note, new implementations should use actions/attest. Provenance and SBOM attestations are two invocations of the same action distinguished by mode auto-detection (no predicate inputs → provenance; sbom-path → SBOM). - upload-ghcr now depends on attest-and-scan, so a rock that fails scanning is not pushed to GHCR and no attestations are orphaned. - The corresponding CRA allowlist entries (`anchore/sbom-action@*`, `anchore/scan-action@*`) ride on the api_demo_server per-repo hunk in canonical/canonical-repo-automation#952. `actions/attest` is covered by the github-owned flag. - Grype's check name will be added to api_demo_server's required status checks in CRA once this workflow is green on master.
| with: | ||
| sbom: ./sbom.spdx.json | ||
| fail-build: true | ||
| severity-cutoff: high |
There was a problem hiding this comment.
Is this cutoff a recommendation of our SSDLC?
There was a problem hiding this comment.
Yes (§Mandatory escalation and §Pre-release blocking).
| - name: Scan rock (Grype) | ||
| uses: anchore/scan-action@e1165082ffb1fe366ebaf02d8526e7c4989ea9d2 # v7.4.0 | ||
| with: | ||
| sbom: ./sbom.spdx.json |
There was a problem hiding this comment.
It seems that Grype can scan OCIs directly (with image). Presumably we separately need the SBOM, so it makes sense to scan the SBOM here too. Is one approach stronger/weaker than the other?
There was a problem hiding this comment.
Both work. Scanning the SBOM keeps a single source of truth: the SBOM is the one we attest and publish, so a green Grype run against it means "the artefact whose SBOM we signed has no high+ vulnerabilities". There's no risk of the direct-image scan and the attested SBOM disagreeing.
The theoretical advantage of scanning the image directly is that Grype re-catalogues from scratch, so it might spot something Syft missed (like an unmanaged binary). For this rock that gap doesn't really exist, so I'd stay with the SBOM scan. If we ever add content Syft can't catalogue, it's worth switching to image: or running both.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
@tonyandrewmeyer the job failed when I pushed a tag. See https://github.com/canonical/api_demo_server/actions/runs/29325227915/job/87061485873 |
2 participants
This PR resolves the SSDLC requirement for SBOM generation and vulnerability scanning of artefacts, by adding a new
attest-and-scanjob betweentestandupload-ghcrin the tag-triggered publish pipeline:anchore/sbom-action) generates an SPDX SBOM from the OCI archive produced by oci-factoryBuild-Rock.actions/attestemits a signed SLSA build-provenance attestation for the rock (auto-generated predicate, provenance mode).actions/attestemits a signed SBOM attestation with the SPDX predicate against the same rock subject.anchore/scan-action) scans the SBOM and fails the build on vulnerabilities of severity high or above.upload-ghcrnow depends onattest-and-scan, so a rock that fails scanning is not pushed to GHCR and no attestations are orphaned.Syft and Grype are the tools recommended in the security team's "How to secure a repo" guide, as well as Trivy, but we've decided to not use Trivy in Charm Tech.