Attestation

A digitally signed statement or evidence about software artifacts that verifies specific properties, origins, or processes related to the software supply chain, enhancing trust and transparency.

What is Attestation?

In the context of software supply chain security, an attestation is a digitally signed statement that verifies specific properties, origins, or processes related to software artifacts. Attestations serve as cryptographically verifiable evidence that particular claims about software are true, providing a foundation for trust in the software supply chain.

Attestations are created by trusted entities (attestors) who have firsthand knowledge of the claims being made. These statements are then cryptographically signed to ensure their authenticity and integrity, allowing consumers to verify that the software meets specific security or compliance requirements.

Types of Software Supply Chain Attestations

Build Attestations

Statements about how a software artifact was built:

Build Environment Information: Details about the system that performed the build
Input Sources: Verification of the source code used in the build
Build Commands: Documentation of the exact commands executed
Dependency Information: List of dependencies included in the build
Configuration Settings: Build-time configuration options used

Provenance Attestations

Statements about the origin and history of software:

Source Repository: The original repository where the code was hosted
Commit Hash: Specific commit from which the artifact was built
Author Identity: Verification of who authored the code
Build Timestamp: When the artifact was created
Build System Identity: Which system performed the build

Policy Attestations

Statements about compliance with security policies:

Vulnerability Scan Results: Confirmation that security scanning was performed
Policy Compliance: Verification that the artifact adheres to security policies
Quality Gates: Evidence that quality checks were passed
License Compliance: Confirmation of license verification

Testing Attestations

Statements about testing performed:

Test Coverage: Metrics about the extent of code testing
Test Results: Outcomes of security and functional tests
Performance Benchmarks: Results of performance testing
Compatibility Testing: Verification of platform compatibility

Attestation Formats and Standards

in-toto Attestations

The in-toto framework provides a format for supply chain security attestations:

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "predicateType": "https://slsa.dev/provenance/v0.2",
  "subject": [
    {
      "name": "example-package",
      "digest": {"sha256": "abcdef123456..."}
    }
  ],
  "predicate": {
    "builder": {"id": "https://github.com/actions/runner"},
    "buildType": "https://github.com/actions/runner/build",
    "invocation": {
      "configSource": {
        "uri": "git+https://github.com/example/repo@refs/heads/main",
        "digest": {"sha1": "abc123..."},
        "entryPoint": ".github/workflows/build.yml"
      }
    },
    "buildConfig": {
      "commands": ["npm ci", "npm run build"]
    },
    "materials": [
      {
        "uri": "git+https://github.com/example/repo@refs/heads/main",
        "digest": {"sha1": "abc123..."}
      }
    ]
  }
}

SLSA Provenance

The Supply-chain Levels for Software Artifacts (SLSA) framework defines provenance attestation formats:

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "predicateType": "https://slsa.dev/provenance/v0.2",
  "subject": [
    {
      "name": "example-artifact.tar.gz",
      "digest": {"sha256": "abcdef123456..."}
    }
  ],
  "predicate": {
    "builder": {"id": "https://github.com/Attestations/builder@v1"},
    "buildType": "https://github.com/Attestations/builder/cloudbuild@v1",
    "invocation": {
      "configSource": {
        "uri": "git+https://github.com/example/repo@refs/heads/main",
        "digest": {"sha1": "abc123..."},
        "entryPoint": "cloudbuild.yaml"
      }
    },
    "materials": [
      {
        "uri": "git+https://github.com/example/repo@refs/heads/main",
        "digest": {"sha1": "abc123..."}
      }
    ]
  }
}

SBOM Attestations

Software Bill of Materials (SBOM) can be wrapped as attestations to verify component inventories:

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "predicateType": "https://spdx.dev/Document/v2.3",
  "subject": [
    {
      "name": "example-package",
      "digest": {"sha256": "abcdef123456..."}
    }
  ],
  "predicate": {
    "SPDXID": "SPDXRef-DOCUMENT",
    "name": "example-sbom",
    "packages": [
      {
        "name": "example-package",
        "SPDXID": "SPDXRef-Package-1",
        "versionInfo": "1.0.0",
        "downloadLocation": "https://example.com/packages/example-1.0.0.tgz",
        "filesAnalyzed": true,
        "licenseConcluded": "MIT",
        "licenseDeclared": "MIT"
      }
    ],
    "relationships": [
      {
        "spdxElementId": "SPDXRef-DOCUMENT",
        "relatedSpdxElement": "SPDXRef-Package-1",
        "relationshipType": "DESCRIBES"
      }
    ]
  }
}

Sigstore Cosign Attestation

Cosign from the Sigstore project supports creating and verifying attestations:

{
  "payload": {
    "body": {
      "_type": "https://in-toto.io/Statement/v0.1",
      "predicateType": "https://slsa.dev/provenance/v0.2",
      "subject": [{"name": "example", "digest": {"sha256": "abcdef123456..."}}],
      "predicate": {"builder": {"id": "https://github.com/actions/runner"}}
    }
  },
  "signatures": [
    {
      "keyid": "SHA256:abcdef123456...",
      "sig": "base64encodedSignature=="
    }
  ]
}

Creating and Managing Attestations

Attestation Generation

Attestations are typically generated as part of automated build and release processes:

# Example using Sigstore Cosign to create an attestation
cosign attest --key cosign.key \
  --type slsaprovenance \
  --predicate provenance.json \
  registry.example.com/myapp:1.0.0

Attestation Storage and Distribution

Attestations can be stored and distributed through various methods:

Container Registry Extensions: Platforms like OCI registries and Docker Hub
Transparency Logs: Public append-only logs like Rekor
Artifact Repositories: Alongside the artifacts they attest to
Trusted Databases: Specialized attestation storage services

Attestation Verification

Consumers verify attestations to establish trust in software:

# Example using Sigstore Cosign to verify an attestation
cosign verify-attestation \
  --key cosign.pub \
  --type slsaprovenance \
  registry.example.com/myapp:1.0.0

Attestation in CI/CD Pipelines

GitHub Actions Example

Generating attestations in GitHub Actions:

name: Build and Attest
 
on:
  push:
    branches: [ main ]
 
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      id-token: write  # Required for keyless signing
      packages: write  # Required for pushing to GHCR
 
    steps:
      - uses: actions/checkout@v3
      
      - name: Build application
        run: |
          npm ci
          npm run build
          
      - name: Generate provenance
        uses: slsa-framework/slsa-github-generator@v1
        with:
          artifact-path: ./dist/app.js
          output-path: ./provenance.json
          
      - name: Install Cosign
        uses: sigstore/cosign-installer@main
        
      - name: Sign and attest artifact
        run: |
          cosign sign-blob --key env://COSIGN_PRIVATE_KEY ./dist/app.js > app.sig
          cosign attest --key env://COSIGN_PRIVATE_KEY --predicate ./provenance.json ./dist/app.js
        env:
          COSIGN_PRIVATE_KEY: ${{ secrets.COSIGN_PRIVATE_KEY }}

GitLab CI Example

Generating attestations in GitLab CI:

stages:
  - build
  - attest
 
build:
  stage: build
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
 
attest:
  stage: attest
  script:
    - apt-get update && apt-get install -y jq curl
    - curl -sLO https://github.com/slsa-framework/slsa-verifier/releases/download/v1.0.0/slsa-verifier-linux-amd64
    - chmod +x slsa-verifier-linux-amd64
    - |
      cat <<EOF > provenance.json
      {
        "_type": "https://in-toto.io/Statement/v0.1",
        "predicateType": "https://slsa.dev/provenance/v0.2",
        "subject": [
          {
            "name": "app.js",
            "digest": {"sha256": "$(sha256sum dist/app.js | cut -d ' ' -f 1)"}
          }
        ],
        "predicate": {
          "builder": {"id": "https://gitlab.com/project/pipeline"},
          "buildType": "https://gitlab.com/project/pipeline/job",
          "invocation": {
            "configSource": {
              "uri": "git+https://gitlab.com/project@$CI_COMMIT_SHA",
              "digest": {"sha1": "$CI_COMMIT_SHA"}
            }
          },
          "materials": [
            {
              "uri": "git+https://gitlab.com/project@$CI_COMMIT_SHA",
              "digest": {"sha1": "$CI_COMMIT_SHA"}
            }
          ]
        }
      }
      EOF
    - curl -sLO https://github.com/sigstore/cosign/releases/download/v1.13.1/cosign-linux-amd64
    - chmod +x cosign-linux-amd64
    - ./cosign-linux-amd64 attest --key $COSIGN_PRIVATE_KEY --predicate provenance.json dist/app.js
  dependencies:
    - build

Consuming and Verifying Attestations

Verification in Deployment Pipelines

Attestations can be verified before deploying software:

name: Deploy with Attestation Verification
 
on:
  workflow_dispatch:
 
jobs:
  verify-and-deploy:
    runs-on: ubuntu-latest
    
    steps:
      - name: Install Cosign
        uses: sigstore/cosign-installer@main
        
      - name: Verify attestation
        run: |
          cosign verify-attestation \
            --key cosign.pub \
            --type slsaprovenance \
            registry.example.com/myapp:1.0.0
        
      - name: Deploy if verified
        if: ${{ success() }}
        run: |
          # Deploy the verified artifact
          kubectl apply -f deployment.yaml

Policy Enforcement with Open Policy Agent

Enforcing attestation policies using OPA:

package attestation
 
# Allow deployment only if a valid SLSA provenance attestation exists
allow_deployment {
  input.attestations[_].predicateType == "https://slsa.dev/provenance/v0.2"
  verify_builder_identity
}
 
# Verify the builder is from a trusted source
verify_builder_identity {
  input.attestations[_].predicate.builder.id == "https://github.com/actions/runner"
}

Container Security with Kubernetes Admission Controllers

Enforcing attestation verification during container deployment:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: verify-image-attestations
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["pods"]
  validations:
    - expression: "has(object.spec.containers[0].image) && object.spec.containers[0].image.contains('verify-attestation')"

Benefits of Attestation in Software Supply Chain

Enhanced Trust and Verification

Attestations enable:

Evidence-Based Trust: Trust decisions based on cryptographic proof
Policy-Driven Validation: Automated verification against security policies
Artifact Integrity: Confirmation that artifacts haven't been tampered with
Comprehensive Verification: Evidence for the entire software supply chain

Regulatory Compliance

Attestations support compliance with:

Executive Order 14028: U.S. order on improving cybersecurity
NIST SSDF: Secure Software Development Framework
GDPR: Data protection requirements in the EU
Industry-Specific Regulations: Financial services, healthcare, etc.

Security Risk Reduction

Attestations help mitigate:

Supply Chain Attacks: Verification of legitimate sources
Counterfeit Software: Confirmation of authentic artifacts
Malicious Insertions: Evidence that no unauthorized code was added
Compromised Build Systems: Validation of build environment security

Challenges and Limitations

Complexity of Implementation

Implementing attestations can be challenging due to:

Technical Expertise: Requiring specialized knowledge of cryptography
Integration Complexity: Adding to existing build and deployment pipelines
Key Management: Securely managing signing keys
Tool Maturity: Evolving standards and tooling

Ecosystem Maturity

The attestation ecosystem is still developing:

Standard Evolution: In-progress standardization efforts
Tool Integration: Varying levels of tool integration
Adoption Barriers: Learning curve for implementation

Verification Challenges

Verification systems may face:

Performance Overhead: Additional verification steps in deployment
Revocation Handling: Managing attestation revocation
Trust Transitivity: Establishing trust in the attestation system itself

Future of Attestations

Emerging Trends

The field of software attestations is evolving rapidly:

Automated Generation: Increased automation in attestation creation
Policy-as-Code: Declarative policies for attestation verification
Integration with Existing Tools: Broader tool ecosystem integration
Standardization: Consolidation around key standards
Transparency Logs: Wider use of public transparency services

Industry Adoption

Increasing adoption across sectors:

Open Source: Growing adoption in open source projects
Enterprise: Integration into enterprise security programs
Cloud Providers: Native attestation services from cloud platforms
Software Vendors: Attestations as part of software delivery

Research and Development

Ongoing areas of innovation:

Hardware-Backed Attestations: TPM and secure enclave integration
AI for Attestation Verification: Automated anomaly detection
Blockchain Integration: Decentralized attestation verification
Formal Verification: Proof-based verification of attestation claims