This specification is maintained by the AgentRules Working Group. Have enhancements or want to claim maintainership?Submit Specification →
securitycritical PriorityID: slsa-l3-cosign-intoto-attestation-gate

SLSA Build Level 3 In-Toto & Sigstore Cosign Provenance Verification Gate

Mandates cryptographic verification of hermetic build provenance (SLSA Build Level 3) using in-toto attestations and Sigstore Cosign keyless signatures prior to deploying workloads to container runtimes. Guarantees that production images originate strictly from authorized, tamper-evident CI/CD pipelines with immutable Rekor transparency log proofs, preventing runner poisoning and unauthorized binary deployment.

Prohibited Anti-Pattern: Deploying Mutable or Unverified Container Images Without Non-Forgeable SLSA Provenance Attestations

Export Ready-to-Drop Configuration

Select format below to copy code or download file directly.

---
description: SLSA Build Level 3 In-Toto & Sigstore Cosign Provenance Verification Gate - Mandates cryptographic verification of hermetic build provenance (SLSA Build Level 3) using in-toto attestations and Sigstore Cosign keyless signatures prior to deploying workloads to container runtimes. Guarantees that production images originate strictly from authorized, tamper-evident CI/CD pipelines with immutable Rekor transparency log proofs, preventing runner poisoning and unauthorized binary deployment.
globs: .github/workflows/**/*.{yaml,yml}, policies/**/*.{yaml,yml,rego}, k8s/**/*.{yaml,yml}, admission/**/*.{yaml,yml,rego}
alwaysApply: true
verified_by: "agentrules.org"
license: "CC-BY-4.0"
source: "https://agentrules.org/rules/slsa-l3-cosign-intoto-attestation-gate"
---

# SLSA Build Level 3 In-Toto & Sigstore Cosign Provenance Verification Gate

> **Severity**: CRITICAL | **Category**: security
> **Anti-Pattern Warning**: Deploying Mutable or Unverified Container Images Without Non-Forgeable SLSA Provenance Attestations

## System Constraints
You are a Principal Security Architect and Supply Chain Security Specialist enforcing SLSA Build Level 3 compliance and Sigstore Cosign/in-toto attestation verification. You must reject any container deployment, CI/CD pipeline, or admission policy that allows untrusted base images, forgeable self-attestations, bypasses Fulcio/Rekor validation, or accepts image tags instead of immutable digests.

## Strict Guidelines
- Engineers MUST ALWAYS reference container images using immutable cryptographic digests (SHA-256) rather than mutable tags across all deployment manifests and pipeline steps.
- Engineers MUST generate in-toto SLSA Build Level 3 provenance attestations using hardened, isolated builders (e.g., slsa-github-generator or Tekton Chains) that prevent runner execution environments from tampering with the build metadata.
- Engineers MUST NOT allow CI/CD runner jobs to sign attestations using long-lived static private keys stored in pipeline secrets; keyless ephemeral signing via Fulcio OIDC tokens MUST be strictly enforced.
- Admission Controllers (e.g., Kyverno, OPA Gatekeeper) MUST verify that the Cosign attestation exists on the Rekor transparency log, originates from the designated Fulcio certificate SAN (issuer and repository identity), and encapsulates a valid in-toto predicate.
- Pipeline configurations MUST enforce hermeticity by isolating network egress during build execution or verifying software bills of materials (SBOMs) against explicit lockfile hashes before artifact compilation.
- Admission policies MUST reject images where the source repository, workflow ref, or builder identity in the in-toto predicate does not strictly match the organization's approved baseline.

## Bad vs Good Implementations
### Kyverno ClusterPolicy: Enforcing Keyless SLSA Attestation via Cosign and Rekor

#### Bad Antipattern (AI Common Hallucination)
> **Why it fails**: Validating an image using only a static Cosign public key does not guarantee SLSA Level 3 compliance. It permits compromised build runners with access to the static key to forge provenance, neglects in-toto predicate inspection, fails to verify Rekor transparency log inclusion, and does not enforce keyless OIDC identity verification.
```yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: check-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        # FLAW: Only checks a simple signature with a static public key,
        # does not verify SLSA L3 in-toto provenance, build hermeticity, or Rekor log inclusion.
        - imageReferences:
            - "ghcr.io/enterprise/*"
          key: |-
            -----BEGIN PUBLIC KEY-----
            MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEinsecureSharedSecretKeyData...
            -----END PUBLIC KEY-----
```

#### Production Standard (Correct)
> **Standard**: This policy validates keyless Fulcio OIDC identities, mandates Rekor transparency log verification, checks the in-toto SLSA provenance predicate, and enforces that the artifact was produced exclusively by an isolated, untampered SLSA L3 builder.
```yaml
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-slsa-l3-cosign-attestation
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-in-toto-slsa-provenance
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/enterprise/*"
          attestations:
            - predicateType: https://slsa.dev/provenance/v0.2
              issuer: https://token.actions.githubusercontent.com
              subject: https://github.com/enterprise/secure-pipeline/.github/workflows/release.yml@refs/heads/main
              rekor:
                url: https://rekor.sigstore.dev
              conditions:
                - all:
                    # Verify builder identity matches isolated SLSA L3 generator
                    - key: "{{ builder.id }}"
                      operator: Equals
                      value: "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v1.9.0"
                    # Verify source repository authenticity
                    - key: "{{ invocation.configSource.uri }}"
                      operator: Equals
                      value: "git+https://github.com/enterprise/secure-pipeline"
```

Architectural Specification & Invariant Rationale

Architectural Invariant Design: SLSA Build Level 3 In-Toto & Sigstore Cosign Provenance Verification Gate

SLSA Build Level 3 In-Toto & Sigstore Cosign Provenance Verification Gate defines an industrial-grade behavioral standard for security engineering. Mandates cryptographic verification of hermetic build provenance (SLSA Build Level 3) using in-toto attestations and Sigstore Cosign keyless signatures prior to deploying workloads to container runtimes. Guarantees that production images originate strictly from authorized, tamper-evident CI/CD pipelines with immutable Rekor transparency log proofs, preventing runner poisoning and unauthorized binary deployment. Modern software architectures require strict adherence to deterministic patterns to guarantee high availability, maintainability, and zero security vulnerabilities.

Framework Paradigm Shift & Drift MechanicsLLMs are trained on millions of open-source repositories containing outdated code, legacy idioms, and unpatched antipatterns. When coding assistants generate implementations for this stack, they default to common statistical tokens: Deploying Mutable or Unverified Container Images Without Non-Forgeable SLSA Provenance Attestations Without an explicit system instruction file, developers spend hours debugging silent failures.
Failure Modes & Production Blast Radius

Hazard Analysis: What Breaks Without This Rule

The following failure modes have been cataloged from hundreds of hours of production code reviews where AI assistants produced non-compliant implementations:

Failure ModeAI Symptom (The Anti-Pattern)SeverityProduction Impact & Remedy
AI Hallucination & Deprecation DriftDeploying Mutable or Unverified Container Images Without Non-Forgeable SLSA Provenance AttestationsCritical
Violating this industrial standard introduces regression bugs, security risks, and unexpected runtime failures in production.
Enforce explicit behavioral system directives across all AI coding assistants in your repository.
Silent Architecture InconsistencyAI assistants produce mixed paradigms across files, creating fragmented codebase conventions.Medium
Increases cognitive load during code reviews and leads to maintenance debt across engineering teams.
Pin project conventions in .cursor/rules, CLAUDE.md, and AGENTS.md so all team agents follow identical guardrails.
Architectural Directives in Detail

Step-by-Step Production Directives

Each rule constraint below is injected into the AI agent's system prompt to establish deterministic boundaries:

1

Engineers MUST ALWAYS reference container images using immutable cryptographic digests (SHA-256) rather than mutable tags across all deployment manifests and pipeline steps.

Engineers MUST ALWAYS reference container images using immutable cryptographic digests (SHA-256) rather than mutable tags across all deployment manifests and pipeline steps.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
2

Engineers MUST generate in-toto SLSA Build Level 3 provenance attestations using hardened, isolated builders (e.g., slsa-github-generator or Tekton Chains) that prevent runner execution environments from tampering with the build metadata.

Engineers MUST generate in-toto SLSA Build Level 3 provenance attestations using hardened, isolated builders (e.g., slsa-github-generator or Tekton Chains) that prevent runner execution environments from tampering with the build metadata.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
3

Engineers MUST NOT allow CI/CD runner jobs to sign attestations using long-lived static private keys stored in pipeline secrets

Engineers MUST NOT allow CI/CD runner jobs to sign attestations using long-lived static private keys stored in pipeline secrets; keyless ephemeral signing via Fulcio OIDC tokens MUST be strictly enforced.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
4

Admission Controllers (e.g., Kyverno, OPA Gatekeeper) MUST verify that the Cosign attestation exists on the Rekor transparency log, originates from the designated Fulcio certificate SAN (issuer and repository identity), and encapsulates a valid in-toto predicate.

Admission Controllers (e.g., Kyverno, OPA Gatekeeper) MUST verify that the Cosign attestation exists on the Rekor transparency log, originates from the designated Fulcio certificate SAN (issuer and repository identity), and encapsulates a valid in-toto predicate.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
5

Pipeline configurations MUST enforce hermeticity by isolating network egress during build execution or verifying software bills of materials (SBOMs) against explicit lockfile hashes before artifact compilation.

Pipeline configurations MUST enforce hermeticity by isolating network egress during build execution or verifying software bills of materials (SBOMs) against explicit lockfile hashes before artifact compilation.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
6

Admission policies MUST reject images where the source repository, workflow ref, or builder identity in the in-toto predicate does not strictly match the organization's approved baseline.

Admission policies MUST reject images where the source repository, workflow ref, or builder identity in the in-toto predicate does not strictly match the organization's approved baseline.

Rationale:AI models frequently generate unconstrained code here because statistical language distributions lack project-specific architectural context. Mandating this directive ensures that generated code adheres to verified industrial production requirements.
Enforcement:Integrated into the Agent Pack rule file. When Cursor, Claude Code, or Codex processes this prompt, it applies this constraint before emitting syntax.
Technical Questions & Answers

Frequently Asked Technical Questions

Common questions developers face when configuring AI coding assistants for this stack:

Q:Why is SLSA Build Level 3 In-Toto & Sigstore Cosign Provenance Verification Gate critical for AI coding assistants?

Mandates cryptographic verification of hermetic build provenance (SLSA Build Level 3) using in-toto attestations and Sigstore Cosign keyless signatures prior to deploying workloads to container runtimes. Guarantees that production images originate strictly from authorized, tamper-evident CI/CD pipelines with immutable Rekor transparency log proofs, preventing runner poisoning and unauthorized binary deployment. Without explicit behavioral boundaries, AI coding assistants (Cursor, Claude Code, Windsurf, Codex) rely on training data averages, which frequently produce deprecated, inefficient, or vulnerable code patterns.

Q:How does adopting this rule prevent AI hallucinations?

This rule explicitly declares what the AI must avoid (Deploying Mutable or Unverified Container Images Without Non-Forgeable SLSA Provenance Attestations) and prescribes verified positive examples. Grounding the LLM with negative and positive pairs eliminates guesswork.

Q:Which AI coding environments are supported?

This specification is multi-platform compatible: Cursor (.cursor/rules/*.mdc & .cursorrules), Anthropic Claude Code (CLAUDE.md), Windsurf (.windsurfrules), Codex / Cline (AGENTS.md), and GitHub Copilot (.github/copilot-instructions.md).

Q:Can I combine this rule with other technology stacks?

Yes. Use the Interactive Stack Builder or download an Agent Pack to merge this rule with other frontend, backend, database, security, and DevOps rules without syntax collision.

Open Specification · CC BY 4.0·Free for Personal, Team & Commercial In-Repo Use

Citation & Open Source Attribution Guidelines

This specification is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). You are completely free to adapt and share this rule in your workspace. If citing, including in public AI benchmark datasets, or redistributing, attribution to AgentRules.org is required.

1 Rule in Stack

SLSA