Presenters

Source

Building Trust, Byte by Byte: A Deep Dive into Salsa and the Ample Policy Engine 🚀

Hey tech enthusiasts! Ever felt that nagging doubt about the security of the software you use, or the code you build? In today’s interconnected digital world, the integrity of our software supply chains is paramount. That’s why the recent talk by Alo Garcia of Carabiner Systems at our latest conference was a breath of fresh air, diving deep into Salsa, a powerful security framework for software supply chains, and showcasing how the Ample policy engine makes it all come together.

This isn’t just about theoretical concepts; it’s about end-to-end implementation, from the very first line of code to the final delivered artifact. Let’s break down how we can establish and verify trust at every single step of the software development lifecycle.

What is Ample and Why Should You Care? 💡

At its heart, Ample is an open-source policy engine designed to weave verification capabilities directly into your development workflows. Think of it as your vigilant guardian, ensuring that every critical step meets your defined security standards.

  • Policies as Code: Ample embraces the “policies as code” philosophy. This means your security rules are written, versioned, and managed just like your application code, making them transparent, auditable, and repeatable.
  • HJSON for Clarity: Policies are structured using HJSON, a human-friendly JSON variant that supports comments and multi-line strings. This makes writing and understanding your policies a whole lot easier.
  • Structured Policies: Each policy is neatly organized with metadata, the identity of the tester, and the crucial “tenets” – the actual data points that Ample will verify.
  • Evolving Language Support: While Ample currently leverages the CEL (Common Expression Language) runtime, the team is actively exploring other powerful options like Rigo and Amazon’s Cedar, promising even greater flexibility in the future.

The Power of Policy Sets: Strength in Numbers 🤝

One of the most exciting features of Ample is the concept of policy sets. Imagine needing to check for SBOMs, Salsa compliance, and vulnerability scans – instead of managing individual policies for each, you can group them!

  • Aggregation Made Easy: Policy sets allow you to combine multiple policies into a single, manageable unit.
  • Remote Referencing: Need to share common verification logic with other teams or projects? Policy sets can be remotely referenced from sources like HTTP servers or Git repositories. This is a game-changer for establishing consistent security practices across an organization.
  • Community Driven: This collective approach fosters collaboration on shared policy definitions for common predicates, accelerating the adoption of best practices.

Meet “Fredo”: A Playful Path to Salsa Mastery 👾

To truly bring these concepts to life, the presentation introduced the “Fredo” project. This isn’t just a demo; it’s a fun, yet incredibly insightful, example of how to implement Salsa from end to end. Fredo builds binaries and generates attestations that cleverly gate deployments based on whether the build occurred on a Friday. While this might sound whimsical, it perfectly illustrates the power of conditional gating in a supply chain.

Dissecting the Fredo Build Pipeline: A Step-by-Step Journey 🚶‍♂️

Let’s walk through how Ample policies are woven into each phase of the Fredo build:

  1. Source Code Protection 🛡️:

    • The presentation highlighted the emerging Salsa source track (Salsa 1.2 draft), emphasizing the critical need to prevent malicious commits from creeping into your version control systems.
    • A reusable GitHub Action was showcased, verifying commit SHAs against Salsa level one compliance. This action pulls policies from community repositories and verifies attestations signed by trusted identities, such as the GitHub Actions repository itself.
  2. Builder Image Verification 🐳:

    • Before any code is built, the container images used as builders are rigorously verified against Salsa specifications.
    • Checks include builder identity, the source repository from which the image was built, and the type of build.
    • This step culminates in the generation of a signed Vulnerability Summary Attestation (VSA), ready for future verification.
  3. Metadata Generation and Verification 📊:

    • This is where the magic of aggregating and verifying crucial data happens before the build even starts.
    • SBOMs, test results, and vulnerability scan data are brought together.
    • OpenVEX attestations are used to mute identified vulnerabilities, providing a clear picture of what’s acceptable.
    • Transformers within Ample play a starring role here. They can remix attestations, taking raw security scan outputs and combining them with VEX documents to create a consolidated, actionable attestation of vulnerabilities with suppressed results. This is a powerful way to manage noise and focus on what truly matters.
  4. Build Execution and Attestation 🏗️:

    • The build proceeds only after cryptographic proof confirms that all preceding checks have passed. No shortcuts here!
    • The build process itself generates a build attestation. For Kubernetes environments, the “holote” attester was demonstrated, observing GitHub Actions and capturing all the necessary information.
  5. Release Pre-flight and Subject Chaining 🔗:

    • A final “release pre-flight” acts as a last line of defense, ensuring all pre-build matches are met and verifying provenance attestations.
    • This stage leverages subject chaining, a sophisticated Ample feature. Subject chaining allows policies to link attestations of related artifacts. For example, a binary can be chained to its originating commit via a build attestation.
    • This becomes incredibly potent within policy sets. Imagine applying a single policy to an SBOM and all its dependencies – subject chaining makes this a reality, simplifying complex verification scenarios.
  6. User Verification: The Ultimate Goal ✅:

    • The ultimate deliverable for end-users is a Verification Summary Attestation (VSA).
    • This VSA serves as irrefutable proof of prior verification, signed by the software producer. It’s a powerful tool for establishing trust, especially when internal data cannot be shared due to confidentiality.

Seeing is Believing: The Attestation Bundle 📦

The presentation concluded with a practical demonstration of an attestation bundle, using the bind utility. This visual showcase highlighted the incredible variety of attestations collected throughout the Fredo build process:

  • Source provenance
  • Builder image verification
  • Tag provenance
  • Dependency verification
  • SBOMs
  • OpenVEX documents
  • Vulnerability scans
  • Test results
  • And, of course, the final VSAs!

Alo Garcia generously offered to demonstrate the verification process further and provided valuable links to all the showcased tools.

Key Takeaways for Your Supply Chain Journey:

  • Embrace “Policies as Code”: Make your security verifiable and repeatable.
  • Leverage Ample: It’s a powerful, open-source engine for embedding verification.
  • Explore Policy Sets: Build collaborative and consistent security practices.
  • Understand Salsa: It provides a standardized framework for supply chain security.
  • Subject Chaining is a Superpower: Unlock advanced verification possibilities.

The insights shared in this presentation offer a clear roadmap for building more secure and trustworthy software supply chains. By adopting tools like Salsa and Ample, we can move from a posture of reactive security to one of proactive, verifiable trust. Happy building, and stay secure! ✨

Appendix