diff --git a/docs/spec/v1.0/certification.md b/docs/spec/v1.0/certification.md new file mode 100644 index 000000000..49066f41e --- /dev/null +++ b/docs/spec/v1.0/certification.md @@ -0,0 +1,107 @@ +# Certification + +## **TODO** + +- [ ] Create a certification registry repo and add links in this doc. +- [x] Create a self-certification questionnaire. + +- [x] Add a link to the SLSA Self-Certification Questionnaire. + +## Overview + +> User's looking for certifications for a particular build system can find them +> on the Certification Registry (**TODO:** create repo for certification +> registry and link here). + +The SLSA Framework defines a series of levels that describe increasing security +guarantees. The certification process is intended to verify that a build system +meets the requirements of a particular SLSA level and is provided to help users +determine the level of trust they can place in a build system and the artifacts +it produces. + +## Certification Tiers + +These tiers are intended to provide users with a way to determine the level of +trust they can place in a build system. The following tiers are defined: + +### Tier 0 - No evidence of conformance + +> **Note:** If a build system is not listed in the Certification Registry +> (**TODO:** create repo for certification registry and link here), you should +> assume that it is in Tier 0. + +The Tier 0 trust tier is the lowest level of trust. Build systems in this tier +have not produced any supporting evidence for their claimed level of SLSA +conformance and no third-party verification has been performed. It is +recommended that users exercise caution or take additional steps to verify the +build system before using it. + +### Tier 1 - Self-certified conformance + +> Build systems in this trust tier are listed in the Certification Registry +> (**TODO:** create repo for certification registry and link here). + +Tier 1 signifies that a build system owner has self-certified their build system +to a particular SLSA level. This certification is intended to be a reasonable +level of trust. Users should still exercise reasonable caution when using a +build system in this trust tier and should consider reviewing the full responses +to the self-certification questionnaire. + +**Process** + +The self-certification process consists of several steps which are intended to +ensure that the build system owner has implemented the requirements necessary to +produce artifacts at a particular SLSA level. The process is as follows: + +**1 - Self-assessment Questionnaire** + +The build system owner is expected to answer a series of questions that document +their build system's conformance to a particular SLSA level. These questions are +based on the [Verifying Build Systems](verifying-systems.md) document and are +provided as a +[spreadsheet](https://docs.google.com/spreadsheets/d/1KZidrnUhmUC8qNvkq5l1FkvRmaUlWzTTVLC8KUMNSEs/edit?usp=sharing). +The build system owner is expected to maintain a current copy of the answers and +update it as their build system evolves. + +**2 - Attestation** + +The build system owner is expected to attest to the accuracy of the +questionnaire responses and publish it on their website. This attestation should +be made by a person with authority to make such statements on behalf of the +build system owner. + +**3 - Build System Identification** + +Build system workers are required to sign provenance in a secure way that +provides strong identification of the builder. The prefered method of this is by +utilizing sigstore with keyless signing and an OIDC identity provider that +provides strong identification of the builder. Additionally a PKI system with a +root certificate and subkeys for each worker can be used in combination with the +[rekor transparency log](https://github.com/sigstore/rekor). + +These options are also available but are not recommended and are only provided +to allow organizations to use existing tooling: + +> **Note:** The following options will be deprecated in the future and will +> generate warnings in tooling. + +- Provide a root certificate and distribute signed worker certificates to their + build system workers. +- Provide a link to a public key or list of public keys that are associated with + the build system. + +The method used to sign the provenance should be included in the submission to +the Certification Registry (**TODO:** create repo for certification registry and +link here). This will allow tools to automatically link builders with their Tier +1 responses. + +**4 - Submission to Certification Registry** + +The build system owner submits a pull request to add their build system to the +Certification Registry (**TODO:** create repo for certification registry and +link here) utilizing the provided PR template. The PR template provides all the +required fields for the submission to be accepted. + +### Tier 2 - Third-party verified conformance [TODO] + +**Note:** This tier is not yet implemented. diff --git a/docs/spec/v1.0/index.md b/docs/spec/v1.0/index.md index 3212c3a1d..0b8cecf8d 100644 --- a/docs/spec/v1.0/index.md +++ b/docs/spec/v1.0/index.md @@ -22,6 +22,8 @@ in the menu at the top of the page. | [Guiding principles](principles.md) | Background on the guiding principles behind SLSA. | | [Terminology](terminology.md) | Terminology and model used by SLSA. | | [Requirements](requirements.md) | Detailed technical requirements, intended for system implementers. | -| [Verifying build systems](verifying-systems.md) | Guidelines for securing SLSA Build L3+ builders, intended for system implementers. | +| [Certification](certification.md) | Guidelines for certifying SLSA builders, intended for build system owners. | +| Certification Registry (**TODO:** create repo for certification registry and link here) | Registry of certified SLSA builders | +| [Verifying build systems](verifying-systems.md) | Guidelines for securing SLSA Build L3+ builders, intended for build system implementers. | | [Threats & mitigations](threats.md) | Specific supply chain attacks and how SLSA helps. | | [FAQ](faq.md) | Questions and more information. |