Supply chain security

Slipway treats “where did this artifact come from, and was it tampered with?” as a deployment question, not a build-time afterthought.

Provenance for every artifact

When a job uploads an artifact, Slipway emits a SLSA provenance attestation (an in-toto statement) recording the builder, the run, the pipeline definition, the source repository and commit, and the artifact’s SHA-256. Attestations are available on every plan. The control plane signs them; release provenance links the release to the run, commit and attestations that produced it.

You can see provenance on every release and use it in policy:

# environment policy gates (CEL)
policies:
  - name: built-by-slipway-from-main
    expression: provenance.verified && provenance.branch == "main"
  - name: signed-image
    expression: provenance.attestations.exists(a, a.type == "cosign" && a.verified)

require_verified_provenance: true on an environment rejects any release without verified provenance. See Gates.

Signing with cosign

Use Sigstore cosign in a job. With permissions: { id_token: write }, signing can be keyless: the job’s OIDC identity is exchanged for a short-lived certificate, so there is no signing key to manage.

permissions: { id_token: write }
jobs:
  - name: build
    steps:
      - uses: slipway/docker-build@v1
        id: image
      - run: cosign sign --yes "ghcr.io/acme/api@${{ steps.image.outputs.digest }}"

Verify before deploy, in the cluster (admission policy) or with a Slipway policy gate that checks the attestation recorded on the release.

SBOMs

Generate an SBOM (Syft: SPDX or CycloneDX) in the pipeline and keep it with the release as an attestation or artifact. This makes “which releases contain log4j” a query instead of an investigation.

Scanners as gates

Run Trivy, Grype, Snyk, Semgrep, SonarQube, Checkov or gitleaks as steps. Findings are ingested and shown on the run and release (IntegrationService.IngestScanReport), and failing a scanner step fails the job, which stops the release being created. Combine that with require_verified_provenance so only releases built by a pipeline that ran the scans can be promoted. See security scanning integrations.

Pinning

• Pin uses: steps to immutable versions or digests. Org templates are immutable once published.
• Reference images by digest in releases (image=ghcr.io/acme/api@sha256:...); a deployment applies exactly the digest in the release.

What provenance does and does not prove

Provenance proves how an artifact was built by this platform. It does not prove the source is free of bugs or malicious changes. Combine it with code review rules in your SCM, scanning, and approvals on protected environments.