SLSA Provenance Attestations During Incident Triage: A Practical Guide

An incident begins. Your monitoring shows elevated error rates starting 47 minutes ago. Your deployment log shows a new version shipped 52 minutes ago.

Question: "Did we cause this?"

Old answer (6 hours of investigation):

Check git log to find the commit
Review the diff to see what changed
Manually test if the change could cause the observed failure
Check if the author (or agent) is on-call to explain intent
Meanwhile, the incident is still burning

New answer (10 minutes with SLSA provenance):

Find the container digest currently running: sha256:a1b2c3d4e5f6...
Query the Sigstore Rekor transparency log with that digest
Retrieve the SLSA provenance attestation
Inspect the builtFromCommit field
Compare that commit SHA to your observed changes
Check the builtBy field to see if an AI agent authored the code
Conclude: "Yes, this deployment caused the incident" or "No, something else is happening"

SLSA provenance attestations are cryptographic evidence that a given artifact was built from a specific commit, at a specific time, by a specific build system. During an incident, they compress diagnosis time from hours to minutes.

What a SLSA Provenance Attestation Contains

A SLSA Level 2+ provenance attestation is a signed JSON document that cryptographically proves:

{
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://github.com/Scytale-Security/build-definitions/golang",
      "externalParameters": {
        "source": "https://github.com/crashoverride/myapp.git",
        "entrypoint": "Makefile"
      },
      "internalParameters": {
        "GOVERSION": "1.21"
      }
    },
    "runDetails": {
      "builder": {
        "id": "https://github.com/crashoverride/workflows/build.yml"
      },
      "metadata": {
        "invocationId": "abc123def456ghi789",
        "startedOn": "2026-04-29T14:23:45Z",
        "finishedOn": "2026-04-29T14:28:12Z"
      },
      "byproducts": [
        {
          "name": "GITHUB_CONTEXT",
          "content": "{\"ref\":\"refs/heads/main\",\"sha\":\"abc123def456ghi789jkl012mno345pqr\"}"
        },
        {
          "name": "GITHUB_TOKEN_PERMISSIONS",
          "content": "{\"contents\":\"read\",\"packages\":\"write\"}"
        }
      ]
    },
    "resolvedDependencies": [
      {
        "uri": "pkg:golang/github.com/google/[email protected]",
        "digest": {
          "sha256": "d41d8cd98f00b204e9800998ecf8427e"
        }
      }
    ]
  }
}

The key fields for incident triage:

builder.id — Which CI/CD system created this build? (GitHub Actions, GitLab CI, Tekton, etc.)
byproducts.GITHUB_CONTEXT.sha — Exact commit SHA that was built
startedOn / finishedOn — Build timestamp, correlated to your deployment time
resolvedDependencies — Every dependency that went into the build (equivalent to SBOM)
byproducts — Build context, environment variables, permissions used

For incident response, the most critical field is the commit SHA. If that SHA is known-good (tested, approved), then the deployment is trustworthy. If that SHA contains risky code, or was authored by an untrusted source (or autonomous agent without proper constraints), you have your root cause.

Retrieving Attestations During an Incident

SLSA provenance attestations are stored in the Sigstore Rekor transparency log — a publicly verifiable, append-only ledger. This means:

Attestations cannot be faked or deleted retroactively
They are discoverable without contacting your build system
They survive even if your CI/CD infrastructure is compromised

Step 1: Identify the Running Artifact Digest

In your incident war room, identify the exact container or binary hash running in production:

# If running in Kubernetes
kubectl get pods -n production \
  -o jsonpath='{.items[*].spec.containers[*].image}' | \
  grep myapp | head -1

# Example output: myapp@sha256:a1b2c3d4e5f6g7h8...
ARTIFACT_DIGEST="sha256:a1b2c3d4e5f6g7h8"

Or from your deployment tracking system, pull the exact artifact digest that was deployed 47 minutes ago.

Step 2: Query the Rekor Transparency Log

Use the cosign tool (part of Sigstore) to retrieve the provenance attestation:

# List all attestations for a given digest
cosign tree gcr.io/crashoverride/myapp@sha256:a1b2c3d4e5f6g7h8

# Example output:
# gcr.io/crashoverride/myapp@sha256:a1b2c3d4e5f6g7h8
# └── Attestations
#     ├── predicate type: https://slsa.dev/provenance/v1
#     │   ├── invocationId: abc123def456ghi789
#     │   └── builtFromCommit: abc123def456ghi789jkl012mno345pqr
#     └── sbom (cyclonedx)

Step 3: Download and Inspect the Attestation

# Download the provenance attestation
cosign download attestation \
  gcr.io/crashoverride/myapp@sha256:a1b2c3d4e5f6g7h8 \
  --predicate-type slsaprovenance1 > provenance.json
# Note: 'slsaprovenance1' is the cosign alias for the SLSA v1 predicate type
# (https://slsa.dev/provenance/v1). The legacy 'slsaprovenance' alias still
# defaults to the deprecated v0.2 schema. SLSA v1.2 is the current spec
# (v1.0 itself is now retired) — see https://slsa.dev/spec/

# Extract the built commit
BUILT_COMMIT=$(jq -r '.predicate.runDetails.byproducts[] | 
  select(.name=="GITHUB_CONTEXT") | 
  .content | 
  fromjson | 
  .sha' provenance.json)

echo "This artifact was built from commit: $BUILT_COMMIT"

Step 4: Correlate to Your Change Set

Compare the built commit to your known deployments and changes:

# Show what changed between current and deployed commit
git diff $BUILT_COMMIT HEAD

# If this is the problem, you'll see the risky code
# If this is NOT the problem, the risky code is elsewhere

This is the moment of truth. If the deployed commit is clean and the incident is still happening, the problem is in infrastructure, not code. If the deployed commit contains the risky change, you've found your root cause in under 10 minutes.

Detecting Autonomous Agent Authorship in Provenance

When code is authored by an autonomous AI agent, that information should be recorded in the provenance attestation's metadata or in an adjacent custom attestation.

Standard SLSA provenance does not yet include an "authored by agent" field, but you can add one via a custom attestation predicate:

{
  "predicateType": "https://crashoverride.com/ai-authorship/v1",
  "predicate": {
    "authoredBy": "autonomous-agent",
    "agentName": "replit-agent",
    "agentVersion": "v1.2.3",
    "modelUsed": "claude-3-opus",
    "humanApprovalRequired": true,
    "approvedBy": "[email protected]",
    "approvalTimestamp": "2026-04-29T14:15:00Z"
  }
}

During incident triage, if the attestation shows authoredBy: "autonomous-agent", your team immediately escalates to a different playbook:

Did the agent respect its constraints?
Was human approval properly enforced?
Did the agent have the right permissions?

Detecting Build Tampering

SLSA attestations detect tampering at several levels:

1. Artifact Digest Tampering

If someone modifies the artifact after it's built, its digest changes. If the attestation claims one digest but your production pod is running a different digest, tampering occurred.

# During incident, verify the artifact hasn't changed
RUNNING_DIGEST=$(kubectl get pods -n prod myapp-xyz \
  -o jsonpath='{.spec.containers[0].image}' | grep -o 'sha256:[^"]*')

ATTESTED_DIGEST=$(cosign download attestation \
  gcr.io/crashoverride/myapp@sha256:... | \
  jq -r '.predicateType')

if [ "$RUNNING_DIGEST" != "$ATTESTED_DIGEST" ]; then
  echo "ALERT: Running artifact does not match attestation!"
  # Immediate containment action
fi

2. Build Tampering

The attestation includes metadata about which build system created it, which commit it was built from, and which permissions it had. If the build system's logs show different information, tampering occurred.

3. Time-Based Anomalies

If the attestation says the artifact was built 30 minutes ago, but the incident started 47 minutes ago, the timeline doesn't match. This can indicate the wrong artifact is running, or the timeline is corrupted.

Building an Incident Runbook with SLSA

Update your incident playbook to include SLSA triage as a standard step:

INCIDENT TRIAGE: Deployment-Related Outage
===============================================

1. Identify the affected service
2. Find its current artifact digest
   kubectl get pods... | grep <service>
   
3. Retrieve SLSA provenance attestation
   cosign download attestation <artifact>
   
4. Extract the built commit SHA
   jq -r '.predicate.runDetails.byproducts...' provenance.json
   
5. Check if commit is agent-authored
   If yes → Route to "Agent-Authored Code Incident" playbook
   If no → Continue with standard code review
   
6. Compare built commit to incident timeline
   git diff <built_commit> HEAD
   If diff contains risky code → Root cause found
   If diff is clean → Problem is in infrastructure
   
7. Decide: rollback vs. investigate further
   If code is suspect → Rollback immediately
   If code is clean → Infrastructure investigation

Limitations and Complementary Approaches

SLSA provenance is powerful but not a silver bullet:

It only covers code-to-artifact traceability. It doesn't tell you if the code is functionally correct, only that it came from a specific commit.
It requires artifacts to be signed at build time. If you're not signing, there's no attestation to retrieve during an incident.
It traces to the commit, not the author intent. If the author (human or agent) made a mistake, the attestation proves the mistake was deployed, but doesn't tell you why the mistake was made.

Complement SLSA with:

SBOM scanning — Does the artifact contain known-vulnerable dependencies?
Deployment changelog — Who approved this deployment, and when?
Build logs — Did the build environment have unexpected changes?

Why This Matters for AI-Accelerated Development

In a world where 35% of merged PRs at Cursor (the company) are now created by their own autonomous cloud agents — Cursor's internal data, not an industry-wide figure — and where autonomous agents can make deployment decisions independently, SLSA attestations become a critical accountability tool.

When an incident happens and an autonomous agent was involved:

The attestation proves which code the agent authored
The metadata shows whether the agent respected its constraints
The build logs show what permissions the agent had
The approval record shows whether a human actually approved the deployment

Without this chain of evidence, blame and responsibility become impossible to assign. With it, you can answer: "This was the agent, these were its constraints, and here's how it violated them" — which is essential for fixing the problem before it happens again.