Presenters

Source

Level Up Your Software Supply Chain: Policy Engines for Attestations and Provenance 🚀

Hey tech enthusiasts! 👋 Ever feel like generating software attestations and provenance is the easy part, but actually using that valuable data feels like a black box? You’re not alone! Andrew McNamara from Red Hat and Adolfo García Veytia (aka “puerco”) from the Kubernetes release engineering team are here to demystify this crucial step. They’re showcasing how policy engines can transform your attestations and provenance into actionable, automated decisions for a more secure software supply chain.

What are Attestations and Provenance, Anyway? 🤔

Before we dive into the “how,” let’s quickly recap.

  • Attestations: These are cryptographically signed statements about your software artifacts. Think of them as digital certificates of authenticity. They include:
    • Subject: The specific artifact the attestation refers to (e.g., a container image).
    • Predicate Type: The kind of information the attestation contains.
    • Predicate Information: The actual details of the attestation.
  • Provenance: A specific type of attestation that details how an artifact was built. It’s the build’s fingerprint, showing the exact steps and components involved.

While SLSA provides a standard for generating provenance, the real challenge lies in consuming and acting upon this information. That’s where policy engines shine! ✨

Introducing Our Policy Engine Powerhouses 💪

Andrew and Adolfo are demonstrating two fantastic policy engines:

  1. Conforma: Developed at Red Hat, this Rego-based engine is incubated within Kubes. It’s designed for automated policy decisions within build platforms like Tekton.
  2. Ample: This open-source engine has been a year-long project, with plans to be donated to the OpenSSF. It offers a robust way to enforce policies.

They’ll be walking us through three levels of verification for SLSA attestations, using these engines for live demos! Let’s see how they stack up.

Level 1: Mild Verification - The Basics of Trust 🛡️

This is the entry point for verifying your SLSA attestations. The SLSA spec outlines key checks:

  • Attestation Presence: Is there an attestation at all?
  • Builder Identity: Was the artifact built by the expected system?
  • Build Type: Did the build use the correct tooling?
  • Source Materials: Was the artifact built from the intended commit?
  • External Parameters: For configurable builds, were the expected parameters used?

💡 Ample in Action:

Ample uses policy sets (collections of policies) to manage these checks. A policy typically has a tenant (the condition to meet) and configuration points. You can even pull policies from community repositories, so you don’t have to reinvent the wheel!

To run a policy in Ample, you invoke the Ample binary with the subject (what you’re verifying), the policy code, and the attestation. For real-world scenarios, you can use collectors to automatically fetch policies and provide contextual values (like build types). Ample can even generate a VSA (Verification Summary Attestation), which we’ll see later!

  • Demo Snippet: The demo shows Ample fetching attestations from a registry, applying policies, and verifying signatures. All policies pass, indicating successful verification! 💯

👨‍💻 Conforma in Action:

Conforma also handles these checks, often in two steps: verifying the image signature and then verifying the provenance. Andrew demonstrates verifying a Red Hat UBI 10 image, running 50 different checks to ensure requirements are met.

  • Demo Snippet: The Conforma demo highlights a “mild policy” that leverages standard library policies for checks like builder ID, version control, and external parameters. It confirms that all these checks pass, as seen in the detailed provenance report. ✅

Level 2: Medium Verification - Chaining Trust 🔗

Now, let’s crank it up a notch! What if you have hundreds of workloads relying on a verified container image? You don’t want to re-verify the base image every time. This is where Verification Summary Attestations (VSAs) come in. A VSA essentially says, “I’ve done the checks, you can trust me.”

This level involves verifying your container image against the three SLSA controls and checking the underlying VSA of its base image.

💡 Ample’s Chaining Predicates:

A key challenge here is linking attestations when the built image differs from the base image. Ample handles this with chaining predicates. You apply a selector to an attestation to extract data (like the base image hash), which then becomes the new subject for fetching the base image’s attestation.

  • Demo Snippet: The Ample demo showcases Verifying a container image, checking its SLSA levels, and then verifying the VSA of the base image. It uses a collector pointing to OCI references and demonstrates how the VSA ensures the expected SLSA level for the base image. 🌟

👨‍💻 Conforma and VSAs:

While Conforma doesn’t natively generate VSAs in the same way, Andrew demonstrates a workaround. He writes a script to take Conforma’s policy output (successes and failures) and create his own VSA.

  • Demo Snippet: The Conforma demo shows a build report with some warnings (due to missing optional add-ons), but all successes are logged. The generated VSA confirms a SLSA build level 2 for the artifact and its dependency. However, Andrew expresses a desire for stronger guarantees. 🤔

Level 3: Wild Verification - The Pinnacle of Trust 🏆

Andrew wants to push beyond level 2, aiming for a SLSA build level 3 with stronger isolation guarantees. This requires deeper knowledge of the build system and trusting the specific tasks that produced the artifact.

👨‍💻 Conforma and Tekton Tasks:

Conforma, when integrated with Tekton, can leverage information about resolved tasks. Tekton tasks are specifications for pods and containers, identified by specific commit SHAs. A policy can then verify that all tasks used in the build are from a trusted list.

  • Demo Snippet: Andrew explains how Tekton provenance includes task information. He shows a policy rule that checks these tasks against a trusted task reference file (a YAML file with trusted commit SHAs). If all tasks are trusted, the build automatically upgrades to SLSA level 3. The demo confirms a SLSA build level 3 for the produced image, highlighting isolation guarantees and the absence of PVC dependencies. 🎉

💡 Ample and Trusted Tasks:

Adolfo mirrors this by modifying the Ample policy. He demonstrates fetching the trusted task file and passing it as a contextual value to the policy. The Rego code then verifies each task in the provenance against the entries in this trusted file.

  • Demo Snippet: The Ample demo shows fetching the trusted task file and then performing the full verification: SLSA levels, base image VSA, and finally, ensuring all trusted tasks are present in the Red Hat file. This culminates in a highly trusted build. 🎯

The Power of Chaining and Interoperability 🌐

The key takeaway is that you can use the same attestation data to achieve progressively higher levels of trust.

  • Simple Verification: Start with checking signatures and signing identities.
  • Chaining Attestations: Link attestations together. Beyond provenance, you can chain S-bombs, vulnerability reports, and test results. Trust is built on the identity of the attestation creator.
  • Advanced Isolation: For those demanding the highest security, leverage build system specifics to achieve advanced isolation guarantees and elevate your SLSA level.

Crucially, all this relies on the common interface of internal attestations. Both Conforma and Ample offer standard libraries, making them largely interchangeable. This interoperability is a testament to the collaborative work happening within open-source foundations.

The Future is Secure and Automated! ✨

Andrew and Adolfo’s presentation beautifully illustrates how policy engines are bridging the gap between generating valuable software supply chain data and making it actionable. By embracing these tools, you can automate your trust decisions, enhance your security posture, and build more resilient software.

Keep an eye out for future developments in this space – the future of secure software development is bright! 💡

Appendix