Skip to content

Improve pipeline deploy attestation evidence gates #1389

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
danyili2632 wants to merge 1 commit into
base: main
Choose a base branch
from
+50 −1
Open

Improve pipeline deploy attestation evidence gates #1389

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 50 additions & 1 deletion skills/devsecops/pipeline-security/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,6 +62,8 @@ The assessment produces a formal report containing a SLSA build level determinat
| **SLSA Build L2** | Hosted build platform. Signed provenance generated by the build service. | Builds run on a managed service (GitHub Actions, Cloud Build, etc.). Provenance metadata is produced and signed. |
| **SLSA Build L3** | Hardened builds. Build environment is isolated, ephemeral, and parameterless. Builds cannot influence one another. | Isolated runners, no shared caches across trust boundaries, hermetic builds, non-falsifiable provenance. |

> SLSA build levels describe build-side provenance generation. Production release reviews must also verify that downstream deploy gates consume and enforce that provenance before running the artifact.

### OWASP Top 10 CI/CD Security Risks

| Control ID | Risk Name |
Expand Down Expand Up @@ -392,6 +394,11 @@ docker.sock
- No SBOM (Software Bill of Materials) generation in the build pipeline.
- Downloaded dependencies or tools without checksum verification.
- Missing provenance attestation (SLSA provenance, in-toto, Sigstore).
- Provenance generated during build but never verified at release or deployment time.
- Deployment consumes mutable tags (`latest`, branch tags, semantic tags) instead of the attested subject digest.
- Verification commands run without issuer, certificate identity, source repository/ref, builder identity, or predicate constraints.
- Admission controllers or release gates run in audit/warn mode for production artifacts.
- Multi-arch images verify only one platform image or only the manifest list when production can pull another platform digest.

**Grep patterns:**

Expand All @@ -412,9 +419,46 @@ sbom
# Look for digest pinning in container references
image: nginx@sha256:abcdef... # GOOD
image: nginx:latest # BAD

# Look for deploy-time verification and enforcement
cosign verify
cosign verify-attestation
slsa-verifier
gh attestation verify
kubectl set image
helm upgrade
kustomize edit set image
kyverno
gatekeeper
connaisseur
ratify
policy-controller
```

**Finding format:** Report whether artifacts are signed, whether provenance is generated, whether SBOMs are produced, and whether container images use digest pinning.
**Deploy-time attestation verification gates:**

| Gate | Evidence to Collect | Finding When Missing |
|---|---|---|
| Subject digest binding | Deploy manifest, Helm values, Kustomize patch, release config, or admission request uses the same `sha256` digest named in the attestation subject | Deployment uses `repo/app:latest`, branch tags, semantic tags, or a digest different from the attested subject |
| Signature and attestation verification | `cosign verify-attestation`, `gh attestation verify`, `slsa-verifier`, or private-PKI equivalent runs before release | Build signs artifacts, but deploy proceeds without verifying the signature and attestation |
| Identity constraints | Verification checks issuer, certificate identity, source repository, workflow ref, builder ID, and expected subject | Verification accepts any valid signature from the transparency log or any trusted CA identity |
| Predicate validation | SLSA predicate type, buildType, source URI, commit SHA/ref, builder, and materials are checked against the release policy | Attestation exists, but deploy policy does not inspect whether it describes the expected source and build |
| Enforcement mode | Admission controller, release gate, or environment protection rejects invalid artifacts in production | Policy is audit-only, warn-only, or not connected to the production deploy path |
| Exception governance | Break-glass exception has owner, expiry, reason, approval, and post-deploy review | Manual override can deploy unsigned or unverifiable artifacts without traceability |
| Multi-arch handling | Manifest digest and per-platform image digests are both understood, or deployment platform is pinned and verified | Only one architecture's attestation is checked while production may pull another platform image |

**Severity calibration:**

| Condition | Severity |
|---|---|
| Production deploy uses mutable image tags while build attests a digest | High |
| Production deploy has no signature/provenance verification gate | High |
| Verification runs without issuer/certificate identity/source-ref constraints | High |
| Admission or release policy is warn-only for production | Medium |
| Multi-arch image provenance is incomplete or ambiguous for deployed platforms | Medium |
| Development deploys are warn-only with documented production enforcement | Low |

**Finding format:** Report whether artifacts are signed, whether provenance is generated, whether SBOMs are produced, whether container images use digest pinning, and whether deploy-time verification enforces subject digest, identity constraints, SLSA predicate checks, and exception governance.

---

Expand Down Expand Up @@ -478,6 +522,7 @@ Produce the final report using the following structure:
|------------|-----------|----------|--------|-----------------|
| CICD-SEC-1 | Insufficient Flow Control | High/Med/Low | Pass/Fail/Partial | <summary> |
| CICD-SEC-2 | Inadequate IAM | ... | ... | ... |
| CICD-SEC-9 | Artifact Integrity Validation | ... | ... | <build provenance and deploy-time verification status> |
| ... | ... | ... | ... | ... |

### Detailed Findings
Expand All @@ -488,6 +533,7 @@ Produce the final report using the following structure:
- **File:** <path to relevant config>
- **Line(s):** <line numbers if applicable>
- **Description:** <what was found>
- **Deploy-time Verification Evidence:** <subject digest / verifier command or policy / issuer identity / cert identity / source ref / builder ID / predicate / enforcement mode / exception owner>
- **Remediation:** <specific fix>

### Prioritized Remediation Plan
Expand Down Expand Up @@ -551,10 +597,13 @@ This skill processes user-supplied content including CI/CD configuration files,
- OWASP Top 10 CI/CD Security Risks: https://owasp.org/www-project-top-10-ci-cd-security-risks/
- GitHub Actions Security Hardening: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions
- Sigstore / Cosign: https://docs.sigstore.dev/
- Sigstore Cosign Verification: https://docs.sigstore.dev/cosign/verifying/verify/
- GitHub Artifact Attestations: https://docs.github.com/en/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds
- SLSA GitHub Generator: https://github.com/slsa-framework/slsa-github-generator

---

## Changelog

- **1.0.0** -- Initial release. Full coverage of SLSA v1.0 build track and OWASP Top 10 CI/CD Security Risks (CICD-SEC-1 through CICD-SEC-10).
- **1.0.1** -- Added deploy-time attestation verification gates for CICD-SEC-9, including digest binding, identity constraints, SLSA predicate checks, enforcement mode, exceptions, and multi-arch handling.