Apply for SLSA graduation #415
Conversation
Signed-off-by: Arnaud J Le Hors <[email protected]>
Signed-off-by: Arnaud J Le Hors <[email protected]>
| * https://github.com/slsa-framework/slsa/blob/main/CONTRIBUTING.md#slsa-versions-management | ||
|
|
||
| Projects should harden their build systems in accordance with the SLSA Framework | ||
| * Not Applicable but we do use features such as branch protection, Dependabot, and Mend Renovate bot. |
There was a problem hiding this comment.
Should we be looking how to apply SLSA in the builds of our reference implementations (e.g. slsa-github-generator)?
|
|
||
| ### Security Baseline | ||
|
|
||
| The project meets all applicable Security Baseline requirements: |
There was a problem hiding this comment.
Do these requirements need to be applied to our demos and reference implementations?
There was a problem hiding this comment.
This something that I think we should clarify. I think in SLSA's case it's the spec and the SLSA GitHub generator.
There was a problem hiding this comment.
I'd say that the SLSA Jenkins generator is another tool that needs to be included, only if for the relatively wide use of Jenkins.
|
|
||
| ### Project adoption | ||
| The project must be able to show adoption by multiple parties, which could be production deployments or substantial use by established open source communities, and demonstrate the value of that adoption to either the end users or the open source community. | ||
| * Since the release of SLSA 1.0 in April 2023, evidence of its adoption keeps growing. This includes support in build platform offerings from companies like [Google](https://cloud.google.com/build/docs/overview), [IBM](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-slsa), and [Red Hat](https://developers.redhat.com/products/trusted-software-supply-chain/overview), as well as support for [npm package provenance in GitHub](https://github.blog/security/supply-chain-security/introducing-npm-package-provenance/) and integration with Sigstore among others. |
There was a problem hiding this comment.
Would it make sense to also call out GitHub and Tekton adoption of it? We haven't linked the documentation to the SLSA repositories itself, but we also have konflux-ci.dev (which is built on top of Tekton)
There was a problem hiding this comment.
Can confirm that https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds / https://github.com/actions/attest-build-provenance uses SLSA Provenance in-toto attestation.
|
|
||
| ### Project adoption | ||
| The project must be able to show adoption by multiple parties, which could be production deployments or substantial use by established open source communities, and demonstrate the value of that adoption to either the end users or the open source community. | ||
| * Since the release of SLSA 1.0 in April 2023, evidence of its adoption keeps growing. This includes support in build platform offerings from companies like [Google](https://cloud.google.com/build/docs/overview), [IBM](https://cloud.ibm.com/docs/devsecops?topic=devsecops-cd-devsecops-slsa), and [Red Hat](https://developers.redhat.com/products/trusted-software-supply-chain/overview), as well as support for [npm package provenance in GitHub](https://github.blog/security/supply-chain-security/introducing-npm-package-provenance/) and integration with Sigstore among others. |
There was a problem hiding this comment.
Can confirm that https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds / https://github.com/actions/attest-build-provenance uses SLSA Provenance in-toto attestation.
| * https://github.com/slsa-framework/governance | ||
|
|
||
| Have a defined and documented roadmap and annual goals for the project | ||
| * https://github.com/slsa-framework/slsa/projects?query=is%3Aopen |
There was a problem hiding this comment.
At first I was skeptical, but this is actually not a bad way to indicate the high-level workstreams a TI is undertaking, especially for a larger project like SLSA!
No description provided.