Supply-chain Levels for Software Artifacts Level 3 (SLSA L3)
The Supply-chain Levels for Software Artifacts (SLSA) framework consists of a set of incrementally adoptable guidelines for supply chain security, established by industry consensus. It is designed to support automation that tracks code handling from source to binary, protecting against tampering regardless of the complexity of the software supply chain. The SLSA framework provides trust with best practices and tamper-resistant evidence for securing each step of the software production process.
Tanzu Application Catalog produces provenance attestations for all the distributed assets, as the verifiable information about software artifacts describing where, when and how something was produced, that meets SLSA Build Level 3.
SLSA L3 requirements
The table below shows the requirements needed to be SLSA compliant for Level 3 based on this specification. As you will see in the following sections, Tanzu Application Catalog follows SLSA recommendations to meet those requirements when building and delivering applications.
| Implementer | Requirement | Degree | L3 |
|---|---|---|---|
| Producer | Choose an appropriate build platform | Yes | |
| Follow a consistent build process | Yes | ||
| Distribute provenance | Yes | ||
| Build platform | Provenance generation | Exists | Yes |
| Authentic | Yes | ||
| Unforgeable | Yes | ||
| Isolation strength | Hosted | Yes | |
| Isolated | Yes |
How Tanzu Application Catalog meets SLSA L3 requirements
In this section you will learn how Tanzu Application Catalog artifacts are compliant with the following SLSA requirements:
- Choose appropriate build platform
- Follow a consistent build process
- Hosted platform
- Isolated platform
- Distribute provenance
- Provenance exists
- Provenance is authentic
- Provenance is unforgeable
Choose appropriate build platform
SLSA requirement
The producer must select a build platform that is capable of reaching their desired SLSA Build Level.
How Tanzu Application Catalog meets that requirement
Tanzu Application Catalog custom build platform is the evolution of the Bitnami build platform, following these rules:
- Proper access control mechanisms
- Anti-tampering and auditing
- Ephemeral and isolated build environments
- Provenance verification
Follow a consistent build process
SLSA requirement
The producer must build their artifact in a consistent manner such that verifiers can form expectations about the build process.
How Tanzu Application Catalog meets that requirement
- All packages are produced and distributed automatically in a consistent manner. There are no manual steps or human intervention in any part of the build process. Consumers and verifiers can make proper expectations, since Tanzu Application Catalog produces enough provenance metadata to verify its contents.
- Application recipes are managed in a Git repository, requiring signed commits and at least two approvals in any pull request from package maintainers.
Hosted platform
SLSA requirement
All build steps ran using a hosted build platform on shared or dedicated infrastructure, not on an individual’s workstation.
How Tanzu Application Catalog meets that requirement
Tanzu Application Catalog build platform runs in a dedicated hosted environment, isolated from the rest of services, with all expected security measures and strict network rules.
Isolated platform
SLSA requirement
The build platform ensured that the build steps ran in an isolated environment, free of unintended external influence. In other words, any external influence on the build was specifically requested by the build itself. This must hold true even between builds within the same tenant project.
How Tanzu Application Catalog meets that requirement
- Tanzu Application Catalog build steps are isolated and there is no way to influence them externally.
- Overlapping build steps cannot influence each other, they are run in different agents, and there is no shared memory or storage. All agents are ephemeral and every step uses a newly provisioned one.
- All the builds are triggered in an ephemeral environment and without sharing any cache system to ensure the isolation with consequent or parallel builds.
- Builds don’t open any service or interface that could be externally used to influence the build.
- Provenance Signing secret is not available to individual build steps, since only the control plane orchestrating the builds, has access to it.
Distribute provenance
SLSA requirement
The producer must distribute provenance to artifact consumers.
How Tanzu Application Catalog meets that requirement
Custom provenance metadata is distributed in Tanzu Application Catalog along with the build outputs:
- As signed OCI artifacts -with both Cosign and Notation signatures- in same registry as the subject artifact. Learn how to verify the signatures in this page
- As downloadable artifacts through the Tanzu Application Catalog user interface
- As payloads through the Tanzu Application Catalog public API
Provenance metadata is based on the SLSA Provenance proposal. The Tanzu Application Catalog build type definition can be found here.
Additional metadata consists of several artifacts such as SPDX SBOMs, test results, CVE scans, VEX documents and so on.
All these artifacts are available for download through the Tanzu Application Catalog UI as shown in the screenshot below or via CLI.
Provenance exists
SLSA requirement
The build process must generate provenance that unequivocally identifies the output package by cryptographic digest and describes how that package was produced. The format must be acceptable to the package ecosystem and/or consumer.
How Tanzu Application Catalog meets that requirement
Tanzu Application Catalog asset specification contains SHA-256 hashes of all artifacts produced during the build process, and also the OCI repo digests (manifest digests) of the delivered images.
SLSA Provenance is digitally signed (protected against tampering), and its information is complete, including:
- Full bill of materials (BOM) in SPDX format, which includes the full list of system components, references to source code repositories used to compile Bitnami modules, and references to downloaded binaries from external package systems.
- Source code of the recipes used to build the images, including the Dockerfile and the full image filesystem contents.
Provenance is authentic
SLSA requirement
Consumers must be able to validate the authenticity of the provenance attestation in order to ensure integrity and define trust.
How Tanzu Application Catalog meets that requirement
SLSA provenance
Provenance based on the SLSA security framework is digitally signed by the build platform control plane, and the public key is available in a well known URL for customers and verifiers to check its integrity.
- SLSA Provenance file consists of a JSON payload based on the SLSA Provenance schema. The provenance is distributed as an OCI artifact in the registry as a signed DSSE envelope.
- The specific Tanzu Application Catalog build type can be found here
- Public keys for the DSSE envelope validation are maintained in Tanzu Application Catalog’s well-known location at https://app-catalog.vmware.com/.well-known/cosign.pub
Metadata
Additionally, all delivered OCI artifacts are signed with both Cosign and Notation. To learn how to verify artifacts signatures in Tanzu Application Catalog, see this tutorial.
Provenance is Unforgeable
SLSA requirement
Provenance must be strongly resistant to forgery by tenants.
How Tanzu Application Catalog meets that requirement
Provenance is generated in the Tanzu Application Catalog build platform control plane. Security measures are put in place to ensure that non-authorized access to the provenance signing key cannot occur.
- Signing key is stored in a Vault, protected with access policies.
- Only the Tanzu Application Catalog provenance control plane can access the signing key.
- Provenance is generated from the result of different build steps. Each partial result is signed and verified before starting the next one, protecting the system against tampering.
- All build external parameters (customer custom base images and customizations) are well enumerated and included in the provenance metadata.
