FRSCA: Factory for Repeatable Secure Creation of Artifacts

A Blueprint for Improving Software Supply Chain Security

This is the second in a series of blogs on the Factory for Repeatable Secure Creation of Artifacts (FRSCA); if you haven’t read our blog on SLSA, we highly recommend you check it out first!

FRSCA is a prototype implementation of the Secure Software Factory (SSF) Reference Architecture. This architecture was defined by the Cloud Native Computing Foundation’s (CNCF) Technical Advisory Group (TAG) for Security and is detailed in the Secure Software Factory whitepaper released in May of 2022. The SSF whitepaper was a follow-up to the TAG’s Software Supply Chain Best Practices whitepaper, which outlined several recommended practices to secure the software supply chain. While the best practices doc did not make specific recommendations regarding architecture or technology, the SSF whitepaper focused on the specific requirements and components needed to generate provenance during artifact builds. FRSCA defines specific technologies and open source software to implement the components described in the SSF architecture.

To understand what role each of the FRSCA technologies plays in the SSF architecture, we need to understand the SSF components, which can be grouped under three broad categories:

  • Core – taking inputs and producing outputs
  • Management – policy enforcement
  • Distribution – safe consumption of produced outputs

Core components are composed of the scheduling and orchestration platform, pipeline tooling, and build environment.

  • Scheduling and orchestration platform – in FRSCA, Kubernetes (K8s) fulfills this role; as an orchestration platform, K8s is perfectly suited to provide the foundation for secure artifact generation
  • Pipeline tooling and build environment Tekton Pipelines implement these SSF components; while other CI tools exist, Tekton is Kubernetes-native and follows OpenSSF best practices, deploying each task in a build pipeline in an ephemeral container that is not reused

Management components include a policy management framework and monitoring tools to verify conformity with policies. SPIFFE/SPIRE provide the necessary identities for principals performing builds, including nodes and workloads, which act as attestors. Tekton Chains provides observation and capture of tasks in a build, and the signature of attestations using credentials from SPIRE and Vault for the signing. When enforcing policy, the attestations can then be used by a downstream Kubernetes admission controller to validate that an authorized workload on an authorized node performed a given image build before allowing a container to be launched using said image.

Distribution components include the admission controller, and artifact registry/repository. While an OCI Registry is external to the FRSCA implementation, the Helm charts, SBoMs, and container images stored within require signatures. This is where Sigstore comes in, enabling cryptographic artifact signatures that can be stored adjacent to the artifact in the OCI Registry for consumer verification.

This covers all of the FRSCA projects except for Helm and CUE. These two projects are used for platform provisioning; they deploy all of the other projects in a FRSCA-based platform!

FRSCA Architecture Diagram

How does FRSCA help with SLSA compliance?

Recall that SLSA, which stands for Supply-chain Levels for Software Artifacts, is designed to enhance the security and integrity of software supply chains. SLSA is defined in terms of tracks and levels. A SLSA track focuses on a particular aspect of a supply chain, such as the Build Track (the only track in SLSA v1.0). Each track has a set of levels that measure a particular aspect of supply chain security, FRSCA addresses the SLSA Build Track Levels in the following ways:

SLSA Build Level 0 has no requirements, so a FRSCA-based implementation achieves this (of course so does my laptop running Docker). 

SLSA Build Level 1 requires build provenance, identifying outputs by cryptographic digest and describing how they were produced. While the SLSA Provenance format (currently the in-toto format) is recommended it is not required; the format of the provenance, however, must be one that is used by the output package’s ecosystem. Because Tekton Chains is being used with Tekton Pipelines in FRSCA, provenance is created and is made available to consumers by pushing it to an OCI Registry alongside the image. Here the ecosystem is OCI; OCI-compliant build tools use cryptographic SHA256 hashes for images, and the provenance generated by Tekton Chains is in the in-toto format. Just by using Tekton, Build Level 1 requirements are satisfied.

SLSA Build Level 2 requires Level 1 compliance and adds two more requirements:

  • All build steps run using a hosted build platform on shared or dedicated infrastructure (no developer laptops!)
  • Provenance authenticity and integrity can be verified by consumer(s)

Once again Tekton Pipelines on K8s provide the required hosted build platform. Tekton Chains generate the provenance and can be authenticated using SPIFFE/SPIRE identities and signed by a private key.

SLSA Build Level 3 adds two more requirements in addition to those at Levels 1 and 2:

  • Provenance must be strongly resistant to forgery by tenants
  • The build platform must be hardened:
    • Builds cannot access secrets of the build platform
    • Overlapping builds on the same infrastructure cannot influence one another
    • Ephemeral environments required for each build
    • “Cache poisoning” must not be possible
    • Remote influence is not allowed unless captured in provenance

Ephemeral containers are used to isolate builds from each other and the host they run on. The platform is isolated using network policies, firewalls, and ACLs. Scanners (Trivy, kube-bench) are used to identify misconfigurations and enable corrections. The private key used for signing provenance is stored in Vault and is only available to the Tekton Chains service, not Tekton Pipelines or any build containers.

As you can see, the FRSCA reference implementation addresses many of the requirements of a secure supply chain and/or factory and can help organizations achieve SLSA compliance. Follow us here and on our Cloud Native Short Take channel to learn more about SSF, SLSA, and FRSCA in the coming weeks/months as we build out a working FRSCA platform!