Attestations: The Missing Link Between Your Code and Production Trust

“How do you know this is the same code that passed security review?”

The CISO’s question hung in the air. The development team had all the right answers: git commits, CI/CD logs, deployment records. But they couldn’t prove—cryptographically prove, that is—that the binary running in production was built from the exact code that was reviewed, using the exact dependencies listed, by the exact build process approved.

That’s when they learned about attestations the hard way.

Beyond the SBOM: The Chain of Trust

In my previous post about SBOMs being a 5-minute investment that could save millions, I explained how Software Bills of Materials (SBOMs) tell you what’s in your software. But there’s a critical gap: how do you know that SBOM actually matches what’s running in production?

Enter attestations: cryptographically signed statements that prove facts about your software. Think of them as tamper-proof certificates that travel with your code from commit to production.

While an SBOM is like a recipe card listing ingredients, an attestation is like a sealed certificate from the chef guaranteeing they used exactly those ingredients, in that kitchen, on that date, following those safety protocols.

What Attestations Actually Prove

Attestations aren’t just digital signatures. They’re structured, verifiable claims about your software supply chain. Here’s what modern attestations can prove:

Build Provenance

• What: The exact source code commit used
• Who: The build system and account that created it
• When: Timestamp of the build
• Where: The build environment and its configuration
• How: The exact build commands and parameters

Dependency Verification

• Each dependency matches the declared version
• No additional dependencies were injected
• Dependencies came from expected sources
• Dependency attestations are valid (chain of trust)

Security Scanning Results

• Vulnerability scans were performed
• Specific security policies were evaluated
• Compliance checks passed
• No critical vulnerabilities exist

Test Execution

• Required test suites ran successfully
• Code coverage met thresholds
• Performance benchmarks passed
• Integration tests validated

The Real-World Attack This Prevents

Let me paint a scenario that’s happened more than enterprises want to admit:

1. Developer commits clean code
2. Build system is compromised (or insider threat)
3. Malicious code is injected during build
4. Binary is deployed to production
5. SBOM shows clean dependencies (because it was generated from source)
6. Months later: data breach

Without attestations, you can’t prove that Step 3 didn’t happen. With attestations, any tampering breaks the cryptographic chain, immediately alerting you to the compromise.

As Niels Tanis explained in a recent discussion on The Modern .NET Show about hidden dependencies, “You can’t protect what you can’t see, and you can’t trust what you can’t verify.”

The Enterprise Reality Check

Here’s what I typically find when auditing enterprise build processes:

The Good:

• Source control with audit logs ✓
• CI/CD pipelines with access controls ✓
• Security scanning in pipelines ✓
• SBOMs (sometimes) ✓

The Missing:

• Cryptographic proof linking source to binary ✗
• Verification that build wasn’t tampered ✗
• Chain of custody for artifacts ✗
• Runtime verification of deployments ✗

The gap? Attestations.

Implementing Attestations: A Practical Guide

The good news: implementing attestations is easier than you think. Here’s the progressive approach I recommend:

Level 1: Basic Build Attestations (Week 1)

Start with signing your build outputs:

# GitHub Actions example
- uses: actions/attest-build-provenance@v2.4.0
  with:
    subject-path: ./build/app.exe

This creates a basic attestation proving:

• Which repository built it
• Which workflow ran
• Which commit triggered it
• When it was built

Level 2: SBOM Attestations (Month 1)

Link your SBOM to your build:

# Generate SBOM
syft scan dir:. -o cyclonedx-json > sbom.json

# Create attestation linking SBOM to artifact
cosign attest --predicate sbom.json --type cyclonedx \
  --key cosign.key myapp:latest

Now you can prove your SBOM matches your artifact.

Level 3: Vulnerability Attestations (Month 2)

Add security scan results:

# Scan for vulnerabilities
grype sbom:./sbom.json -o json > vulns.json

# Attest the results
cosign attest --predicate vulns.json --type vuln \
  --key cosign.key myapp:latest

This proves security scans were performed and what they found.

Level 4: Policy Attestations (Month 3)

Implement policy-as-code attestations:

# Policy: No critical vulnerabilities
# Policy: All tests must pass
# Policy: Code coverage > 80%

- name: Verify policies
  run: |
    opa eval -d policies.rego -i results.json
    cosign attest --predicate policy-results.json \
      --type policy --key cosign.key myapp:latest    

The Tool Ecosystem

As Scott Harden discussed in a recent conversation about modern NuGet packaging on The Modern .NET Show, the .NET ecosystem is rapidly adopting attestation standards. Here are the key tools:

For Creating Attestations:

• Sigstore/Cosign: Industry standard for container signing
• GitHub Attestations: Native support in Actions
• SLSA Framework: Standardized levels of supply chain security
• in-toto: Framework for supply chain attestations

For Verification:

• Cosign verify: Validate signatures and attestations
• Policy engines: OPA, Kyverno for policy validation
• Admission controllers: Kubernetes-native verification
• Binary authorization: GCP/AWS native solutions

Common Objections, Answered

“This seems like overkill for internal applications” Until your internal app becomes the pivot point for a breach. Internal threats are real, and compliance requirements are expanding.

“Our CI/CD is already secure” Great! Attestations prove it. They’re not about distrust, they’re about verifiable trust.

“This will slow down deployments” Adding attestations typically adds 10-30 seconds to build time. Compare that to the weeks of incident response after a supply chain attack.

“We don’t have the expertise” Start simple. Basic attestations are one line of configuration. Build expertise gradually.

The Kubernetes Connection

As Adrian Mouat explained in a discussion about Chainguard and container security, container environments make attestations even more critical:

When you’re running hundreds of containers from dozens of teams, you need cryptographic proof of what’s running. Attestations aren’t optional—they’re essential.

Kubernetes admission controllers can verify attestations before allowing deployments, creating an automated trust boundary.

Real Enterprise Success Story

A financial services client implemented attestations after a close call with a compromised build agent. Their journey:

Month 1: Basic build attestations

• Immediate visibility into build anomalies
• Caught two misconfigurations

Month 3: Full SBOM + vulnerability attestations

• Automated compliance reporting
• Reduced audit time by 75%

Month 6: Policy-based deployments

• Zero unauthorized deployments
• 90% reduction in security incidents
• Passed regulatory audit with flying colors

ROI: Implementation cost of £50k prevented potential breach costing millions.

Your Attestation Roadmap

This Week: Learn and Plan

• Understand your current build process
• Identify critical applications for pilot
• Review available tools
• Get security team buy-in

This Month: Pilot Implementation

• Implement basic attestations on one application
• Document the process
• Measure overhead and benefits
• Train team on concepts

This Quarter: Progressive Rollout

• Expand to critical applications
• Add SBOM attestations
• Implement verification in staging
• Create policy framework

This Year: Full Implementation

• All production deployments attested
• Automated policy enforcement
• Runtime verification
• Compliance automation

The Bottom Line

Attestations are not about perfection, they’re about provable trust. In a world where supply chain attacks are rising exponentially, “trust me” isn’t a security strategy.

Every enterprise developer should be providing attestations because:

1. They prove your security practices work
2. They catch compromises early
3. They simplify compliance
4. They’re becoming mandatory (EU Cyber Resilience Act, US Executive Order 10460)
5. They’re easier to implement than to explain why you didn’t

Start simple. Start today. Because the question isn’t “why do we need attestations?” The question is “how did we ever ship software without them?”

Next Steps

Ready to implement attestations in your enterprise? Here’s your action plan:

1. Read the SBOM guide if you haven’t already
2. Choose one pilot application
3. Implement basic build attestations this week
4. Share results with your security team
5. Build from there

Need help implementing a comprehensive attestation strategy? I provide DevSecOps consultation that helps enterprises build verifiable, secure software supply chains.

Reach out using the contact form below, and I’ll be in touch to schedule a free discovery call.