Supply chain robots, electric sheep, and SLSA

How to build supply chain robots that secure your pipelines and keep the digital wolves at bay.

Why is securing the supply chain important?

In my mind’s eye, the “electric sheep” are the products we build and sell to generate revenue. To create “electric sheep”, we build “supply chain robots” that dream of “electric sheep.” The robots are our automated pipelines, our CI/CD systems, and our infrastructure. They construct the sheep, herd them along the software development lifecycle (SDLC), and shepherd them to market.

That all sounds great but, there are wolves at the door. Smart digital wolves. And they are not just trying to eat the electric sheep, they mean to reprogram the robots, poison the assembly line, and turn our own infrastructure against us. The reality of software supply chain security today is that we need supply chain robots to protect everything from the digital wolves.

Why this matters

After a few major attacks, the government decided to protect itself as governments should. On May 12, 2021, the White House dropped Executive Order 14028 on Cybersecurity. And with that, if you wanted to sell to the federal government, you had a whole new set of regulations to meet.

So you skim the Executive Order (EO). It reads like an android interpretation of lawyers and lawmakers notes on engineering security documentation. Excellent vague bits like the following:

• PO.5.1: Separate and protect each environment involved in software development
• PO.5.2: Secure and harden development endpoints
• PW.6.1: Use compiler, interpreter, and build tools that offer security features
• PW.6.2: Determine which tool features should be used and implement approved configurations
• PS.1.1: Store all forms of code based on least privilege principles
• PS.3.2: Collect, safeguard, maintain, and share provenance data for all software components

For reference it sends you down the rabbit hole of NIST standards, which are just as vague. The next step is to leverage your company’s ISO subscription to start digging into ISO 27001. ISO 27002 guidelines give you a glimmer of hope but still no real answers.

How do you turn this mountain of abstract policy into concrete action?

Read more: Leveraging Software Bill of Materials for enhanced security

SLSA: From confusion to clarity

SLSA (pronounced “salsa”) is a comprehensive security framework for software supply chains. Think of it as a maturity model – organizations can progressively improve their security posture by advancing through levels. Each track focuses on different aspects of the supply chain: Build focuses on artifact creation integrity, while Source focuses on code trustworthiness. The framework is designed to be practical and incrementally adoptable, allowing organizations to start where they are and improve over time. Version 1.2-rc1 introduces the reintegrated Source Track after focusing solely on Build in v1.0.

SLSA provides us with:

• A common vocabulary to talk about software supply chain security
• A way to secure your incoming supply chain by evaluating the trustworthiness of the artifacts you consume
• An actionable checklist to improve your own software’s security
• A way to measure your efforts toward compliance with the Secure Software Development Framework (SSDF)

The framework establishes three trust boundaries encouraging the right standards, attestation, and technical controls, so we can harden the system from these threats and risks.

Most importantly for our EO 14028 journey: SLSA translated policy requirements into technical implementation steps.

The two tracks: Build and Source

SLSA has two complementary but independent tracks. You can advance on one without necessarily being at the same level on the other, though both are important for comprehensive supply chain security.

Build Track: The provenance receipt

The Build Track uses provenance as a receipt for your software build. It answers three critical questions:

1. Identity of the builder – Who or what built this?
2. The build process used – How was it built?
3. What inputs went into the build – What materials were used?

This matters because many supply chain attacks happen during the build phase: attackers compromise build systems, inject malicious code, or substitute artifacts. Provenance creates an auditable trail.

Build L0: No guarantees; you’re not doing SLSA yet

Build L1: Provenance exists

• Basic provenance generated and distributed
• Prevents mistakes, but easy to bypass
• Quick to implement with minimal workflow changes
• This got us started on EO requirements for provenance data

Build L2: Hosted build platform

• Provenance signed by the build platform itself
• Requires explicit attack to forge
• Move to platforms like GitHub Actions, GitLab CI, or Google Cloud Build
• This addressed PW.6.1 and PW.6.2: using hardened build tools

Build L3: Hardened builds

• Strong tamper protection during the build
• Isolated build environments
• Prevents insider threats and credential compromise
• This satisfied PO.5.1 and PO.5.2: environment separation and hardening

Build L3 became our target for most releases. It requires significant platform investment but provides strong protection against sophisticated attacks.

Source Track: Trust from code to commit

The Source Track addresses “How do we know this source code is what the organization intended?” It focuses on the change management process: how code gets into the repository and onto protected branches.

Source L1: Version controlled

• Code in a modern version control system like Git
• Foundation for operational maturity
• This covered PS.1.1: proper storage of all code forms

Source L2: Controls enforced

• Protected branches and tags identified
• All changes recorded and tracked
• Technical controls enforced
• This ensured proper access control and change tracking

Source L3: Signed and auditable provenance

• Source Control System generates tamper-resistant evidence
• Contemporaneous documentation of revision creation
• Strong guarantees for change management
• This delivered the PS.3.2 requirement: collecting and safeguarding provenance

Source L4: Two-party review

• Requires two trusted persons to review all changes
• Makes unilateral malicious changes much harder
• This became our gold standard for production code

Building the platform: A series of “What if’s?”

Now that we have a plan, we asked ourselves a series of “what if’s” to turn our chaotic collection of services into a proper platform:

What if we used GitOps for everything?

Everything that can go in Git goes in Git: code, documentation, Infrastructure as Code, policy, and architectural decision records. Benefits: continuous validation, audit trail, guaranteed reviews of changes, and git blame for accountability.

What if we remove out-of-band human checks?

Phase two we shift security left for developers through IDE plugins for quality and compliance and automate right for platform teams with security scans, and testing in the CI/CD. Results are we eliminate friction while strengthening supply chain security. Developers maintain a simple workflow: code, push, get two-party review, and merge when automated checks pass. Vulnerabilities are addressed during the PR; either fixed immediately or documented with time-boxed remediation plans. Meanwhile, automation transparently generates provenance, creates attestations, validates commitments, and blocks only expired remediations.

What if we teach the robots to verify everything?

By verifying environments, materials, processes, and artifacts before running actions, we increase security. Verification tools validate signed provenance and verify metadata, including the source repository used to build binaries.

Verification answers the critical question, “Is this an electric sheep or is it a digital wolf?”

The final results are that developers stay productive while the organization gains comprehensive SLSA-compliant supply chain visibility and protection without manual security gates or out-of-band human checks.

Attestations: More than just SBOMs

SBOMs are great, we should do them. However, an SBOM is just a list of ingredients. At some point, the supply chain must be able to vouch for itself.

We create attestations that are cryptographically signed to verify supply chain assets. Think of it like lab work for your doctor:

• Environment: What lab and what date?
• Process: What machine performs the test and how is it configured?
• Materials: Whose blood and is the chain of custody verified?
• Artifact: The test result should be verifiable and traceable

The robot grabs the signed provenance, validates the signature, uses the SHA sums to validate what it’s about to execute, validates the tools are what they claim to be, validates the instructions are correct, validates the environment is properly configured, and validates the resulting artifact while creating signed provenance for it.

The pipeline builds the pipeline, gaining the benefits of pipeline verification. All the electric sheep are verified and can be trusted.

Read more: SBOM’s: The essential foundation of open source security

Policy as Code: Automating compliance

Policy as Code (PaC) turned our EO requirements from checkboxes into automated enforcement. Security should be codified, automated, and collaborative.

We use JFrog Curation to define third-party software policies and enforce them across the platform: what packages are allowed, what versions, what licenses. This ensures secure and compliant packages.

We use OPA (Open Policy Agent) to define policies that limit network access, control resource usage, and ensure compliance with security standards.

Centralized policy implementation allows platform and security teams to set and enforce standards across all clusters and workloads, removing the need for each application team to secure applications individually.

Benefits:

• Improved security through automated enforcement
• Enhanced compliance with consistent enforcement
• Increased efficiency and reduced errors
• Greater agility in responding to changing requirements
• Improved collaboration through version-controlled policies

The shift-down security model

While shift-left security focuses on early integration in development, shift-down extends security into runtime and operational layers, addressing vulnerabilities that emerge post-deployment in dynamic cloud-native environments.

The approach requires security automation using Policy as Code, collaboration across developers, operations, and security, and continuous tuning to ensure platform security and resilience.

Cross-cutting areas include:

• Reducing vulnerabilities
• Reducing misconfigurations
• Improving software supply chain security

Platform teams establish organizational standards, implement guardrails like Pod Security Standards (PSS) and role based access control (RBAC), manage minimal and hardened base images, and streamline vulnerability management to reduce security burdens on application and security teams.

The road ahead: AI and intelligent platforms

Like everyone else in the free world, we are exploring how to integrate AI into our platform for code quality, security, and compliance. We are running proof of concepts with Model Context Protocol (MCP) Servers, Retrieval Augmented Generation (RAG), and Agentic AI to help with onboarding, observability, deployment diagnosis, and answering frequently asked questions.

Developers can ask from their IDE, “Did we run our security scans?”, “What were the results?”, “Did all tests pass?”, “Can we promote the unit to the next level?” with no context switching and no digging across multiple sources.

This is the next evolution of the platform: intelligent automation that helps developers stay in flow while maintaining rigorous security standards.

Conclusion: From chaos to compliance

If you have a lot of electric sheep, you need a fleet of supply chain robots to tend them. Build a platform to manage the chaos, herd the cats, eliminate the unicorns, and eradicate the chaos from your Software Supply Chain.

SLSA is how we get from safe enough to being as resilient as possible, at any link in the chain.

When we started this journey, Executive Order 14028 was nothing more than pages of requirements with no clear implementation path. SLSA translated those abstract requirements into concrete, measurable levels. Build Track mapped to build tool requirements and environment hardening. Source Track mapped to access control and provenance collection.

The incremental nature of SLSA levels meant we could show progress, justify investment, and continuously improve rather than attempting a massive all-at-once transformation.

You now have an EO 14028 compliant pipeline. Use it for everything.

The pipeline builds the pipeline. Use SLSA as your roadmap. Build a platform to manage the chaos.

And remember: compliance doesn’t equal security, but SLSA helps you achieve both.

More from We Love Open Source

• 10 tips to learn Linux easier and faster
• 12 everyday technologies powered by Linux
• SBOM’s: The essential foundation of open source security
• Leveraging Software Bill of Materials for enhanced security
• What is prompt engineering?