Using Artifact Signing to Establish Provenance for SLSA
Use artifact signing, a feature of Endor Labs, to support build provenance requirements for SLSA.
Use artifact signing, a feature of Endor Labs, to support build provenance requirements for SLSA.
Use artifact signing, a feature of Endor Labs, to support build provenance requirements for SLSA.
Use artifact signing, a feature of Endor Labs, to support build provenance requirements for SLSA.
Use artifact signing, a feature of Endor Labs, to support build provenance requirements for SLSA.
Earlier this year, Endor Labs announced the availability of artifact signing, a low-code/no code capability that provides a trusted cryptographic signature to any artifact you might produce — from application code to containers and more. There are many use cases for signed artifacts, such as Kubernetes admission control and traceability.
In this article, we look at how artifact signing aligns closely with the Supply-chain Levels for Software Artifacts (SLSA: pronounced “Salsa”) Framework, an industry-standard framework developed to ensure the integrity and security of software artifacts throughout the software supply chain.
Many organizations adopt the SLSA framework and aim to achieve SLSA Build L2 and SLSA Build L3 (which were called SLSA Level 3 and SLSA Level 4 in previous versions) because these levels have been accepted as meeting certain supply-chain security requirements in other frameworks (like NIST’s Secure Software Development Framework [SSDF]) and standards (like FedRAMP compliance). Or, they adopt SLSA because their customers place a high value on it, sometimes even requiring their vendors to achieve a particular level.
A Primer on SLSA and Provenance
The SLSA framework addresses growing concerns about supply chain attacks and provides a structured approach to safeguard software from development to deployment. Its requirements are categorized into four primary areas: Source, Build, Provenance, and Common. Each category represents critical aspects of the software supply chain that need to be secured to achieve different levels of SLSA certification.
Artifact signing is most relevant to the concept of Provenance, which SLSA defines as follows:
“To trace software back to the source and define the moving parts in a complex supply chain, provenance needs to be there from the very beginning. It’s the verifiable information about software artifacts describing where, when, and how something was produced. For higher SLSA levels and more resilient integrity guarantees, provenance requirements are stricter and need a deeper, more technical understanding of the predicate.”
Put more simply, provenance is about tracking the history and origins of software artifacts to ensure their authenticity and integrity. SLSA defines requirements for establishing this provenance along with a computer-readable format for documenting it.
Meeting SLSA 1.0 Requirements for Provenance
The most current version of SLSA is at 1.0, which has three levels that provide increasing integrity guarantees. Each SLSA level builds on the previous one, progressively adding more stringent requirements to improve the security and integrity of the software supply chain. For example, if you’re trying to achieve SLSA Build L3, then you must have the requirements of SLSA Build L1, SLSA Build L2, and SLSA Build L3.
In order to produce artifacts with a specific build level, responsibility is split between the Producer and Build platform.
How to get SLSA Build L1: Provenance Exists
SLSA Level 1 requires that provenance “exists”, which translates to having the `buildDefinition` and `runDetails` stored. While signing with Endor Labs, this information is stored as provenance information for every signature, and helps in Identifying Artifacts, Identifying Builder, Identifying Source Code.
How to get SLSA Build L2: Provenance is Authentic
To reach SLSA Build L2 (roughly equivalent to the old SLSA Level 3), provenance must include a digital signature from a private key accessible only to the service generating the provenance, and you must be able to demonstrate that a build system performed the build. The provenance has to be able to be validated for authenticity of the attestation (so that, for example, a deployment can verify the artifact and provenance before putting it into production).
Endor Labs uses strong, keyless authentication in your AWS-hosted, GCP-hosted, or GitHub Actions build environments, and creates a single-use private key which it destroys after the signing. Other key-based authentication is also possible for use in other environments. We pick up immutable information about the build server, like digest and environment details. That signature data can then be included in the SLSA provenance document to make it tamper-resistant. When verifying the signature, you’re verifying:
- A particular build environment was responsible for the build
- A particular version of the build configuration was used
- A particular version of the repository produced the artifact
- The signature has not been revoked
Adding verification to your deployment controls lets you meet SLSA Build L2 requirements while also creating cloud-to-code traceability and gaining the ability to prevent regressions to old, vulnerable artifact versions by revoking their signatures, thus preventing new instances of them from being deployed.
How to get SLSA Build L3: Provenance is Unforgeable
SLSA Build L3 adds requirements to ensure that provenance is difficult for most attackers to forge or tamper with. As part of these requirements, any secrets relevant to signing must not be available to users of the build system.
Endor Labs addresses these requirements by providing secretless authentication for OIDC-capable build environments (build or signing jobs running on AWS, GCP, or GitHub Actions, for example), tamper-resistant signatures using ephemeral private keys with very short validity periods, and a tamper-resistant activity log that strongly associates with the signature. This approach requires an adversary who wishes to tamper with the signature after the fact to compromise multiple systems and controls, which is a key requirement for SLSA Build L3.
Endor Labs’ signing system also permits signing the provenance document itself in addition to the artifact, creating an additional layer of tamper-resistance.
Try Artifact Signing with Endor Labs
By leveraging Endor Labs' artifact signing capabilities, organizations can generate and manage cryptographic signatures for their software artifacts, ensuring that the provenance information is accurate, authenticated, and non-falsifiable. Proper implementation of these capabilities can enable an organization to achieve up to a SLSA Level 3 certification, enhancing the overall security posture of their software supply chain and protecting against potential supply chain threats.
Book a demo to discuss your use cases or start a free trial where you can explore the Endor Labs Software Supply Chain Security platform on a pre-populated demo environment and with your own projects.