Defending against supply-chain attacks
This tutorial walks through three real supply-chain compromises, tj-actions/changed-files (March 2025), aquasecurity/trivy-action (March 2026), and litellm on PyPI (March 2026), and shows how CI/lock's three-layer defense stops each one. The detection logic is the same across all three; only the delivery vector changes.
Generate & verify SLSA provenance in GitHub Actions
Wrap a GitHub Actions pipeline with CI/lock to produce signed, keyless (Fulcio + GitHub OIDC) in-toto attestations for every build step, timestamped with Sigstore TSA and uploaded to Archivista — SLSA-aligned CI/CD provenance end to end.
GitLab CI end-to-end
This tutorial wires CI/lock into a GitLab pipeline using the reusable template at aflock-ai/cilock-action/gitlab/cilock.gitlab-ci.yml. The shape mirrors the GitHub Actions tutorial, same five-step pattern, same attestation outputs, with CILOCK_* variables instead of action with: inputs.
Sign and verify a container image
CI/lock and cosign are complementary tools for container provenance:
SBOM and SARIF evidence
This tutorial wires two of the highest-value security attestors (sbom and sarif) into your CI pipeline. The goal isn't just to generate SBOMs and security findings, it's to make their existence provable, so a release-gate policy can enforce "this artifact must have a signed SBOM and SARIF attached, or it doesn't ship."
Release promotion gate
This tutorial wires a real release-promotion gate: a build pipeline produces signed attestations, and a separate promotion workflow refuses to deploy until cilock verify proves the build met policy. It's the operational answer to "how do we make sure no one ships a release that skipped the SBOM step?"
Audit evidence bundle
An auditor asks: "Show me proof that release v1.4.2 was built from main, ran the SAST scanner, produced an SBOM, didn't use unpinned actions, and was signed by an authorized identity."