Secure Software Supply Chain #26

arsulegai · 2024-09-20T07:24:12Z

Introduce governance mechanism for secure software supply chain in LFDT.
Introduce a mandatory scorecard badge.
Introduce governance mechanism for release artifacts signing and verification.

tkuhrt · 2024-09-20T17:45:29Z

tac/governing-documents/release-signing.md

+title:  Release Signing
+parent: Governing Documents
+grand_parent: LF Decentralized Trust TAC
+nav_order: 1


Suggested change

nav_order: 1

nav_order: 10

Not sure the right number, but I am guessing 10 is close.

Do you think there's a possibility for us to improve the structure with sub-folders? For instance, project reports may have annual report and quarterly report in them. Security may have governing documents related to software supplychain, the other process related to having a representative from the project.

I would like to avoid sub-folders as that results in too many clicks.

+1 for trying to avoid too many/too deep folder structures in general

tkuhrt · 2024-09-20T17:47:19Z

tac/governing-documents/release-signing.md

+
+LFDT has a holistic approach to governing the security of projects and implements the highest levels of standards. The objective is to establish a consistent and secure approach to signing artifacts, leveraging industry-standard tools and practices while allowing flexibility for individual project implementations. Software verification processes are made available to ensure the integrity and authenticity of all artifacts throughout their lifecycle. A monitoring framework is introduced to score the project, rating the release process.
+
+This initiative aligns with efforts to establish a secure software supply chain for LFDT projects and achieve full [SLSA (Supply Chain Levels for Software Artifacts) compliance](https://slsa.dev/spec/v1.0/levels) in the release process.


Suggested change

This initiative aligns with efforts to establish a secure software supply chain for LFDT projects and achieve full [SLSA (Supply Chain Levels for Software Artifacts) compliance](https://slsa.dev/spec/v1.0/levels) in the release process.

This policy aligns with efforts to establish a secure software supply chain for LFDT projects and achieve full [SLSA (Supply Chain Levels for Software Artifacts) compliance](https://slsa.dev/spec/v1.0/levels) in the release process.

tkuhrt · 2024-09-20T17:48:42Z

tac/governing-documents/release-signing.md

+## LFDT Project Compliance
+
+1. The LFDT Technical Advisory Committee (TAC) standardizes the signing of artifacts using tools from the Linux Foundation’s digital signing project, [OpenSSF Sigstore](https://openssf.org/projects/sigstore/).
+2. Each project must document the process of verifying the artifacts using [OpenSSF Sigstore](https://openssf.org/projects/sigstore/). The project must have a file called `RELEASE.md`.


Suggested change

2. Each project must document the process of verifying the artifacts using [OpenSSF Sigstore](https://openssf.org/projects/sigstore/). The project must have a file called `RELEASE.md`.

2. Each project must document the process of signing and verifying the artifacts using [OpenSSF Sigstore](https://openssf.org/projects/sigstore/) in a file called `RELEASE.md`.

tkuhrt · 2024-09-20T17:51:02Z

tac/governing-documents/release-signing.md

+
+1. The LFDT Technical Advisory Committee (TAC) standardizes the signing of artifacts using tools from the Linux Foundation’s digital signing project, [OpenSSF Sigstore](https://openssf.org/projects/sigstore/).
+2. Each project must document the process of verifying the artifacts using [OpenSSF Sigstore](https://openssf.org/projects/sigstore/). The project must have a file called `RELEASE.md`.
+3. Each project must enable and apply for a Sigstore's scorecard. The project must capture the scorecard's result and generate a badge visible on the README.md file.


Suggested change

3. Each project must enable and apply for a Sigstore's scorecard. The project must capture the scorecard's result and generate a badge visible on the README.md file.

3. Each project must enable and apply for an [OpenSSF's scorecard](https://openssf.org/projects/scorecard/). The project must capture the scorecard's result and generate a badge visible on the `README.md` file.

tkuhrt · 2024-09-20T17:52:44Z

tac/governing-documents/release-signing.md

+
+## LFDT Project Compliance
+
+1. The LFDT Technical Advisory Committee (TAC) standardizes the signing of artifacts using tools from the Linux Foundation’s digital signing project, [OpenSSF Sigstore](https://openssf.org/projects/sigstore/).


Suggested change

1. The LFDT Technical Advisory Committee (TAC) standardizes the signing of artifacts using tools from the Linux Foundation’s digital signing project, [OpenSSF Sigstore](https://openssf.org/projects/sigstore/).

1. The LFDT Technical Advisory Committee (TAC) standardizes the signing of artifacts and confirmation of signing using tools from the Linux Foundation’s Open Source Security Foundation (OpenSSF) -- [OpenSSF Sigstore](https://openssf.org/projects/sigstore/) and [OpenSSF Scorecard](https://openssf.org/projects/scorecard/), respectively.

tkuhrt · 2024-09-20T17:54:54Z

tac/governing-documents/release-signing.md

+1. The LFDT Technical Advisory Committee (TAC) standardizes the signing of artifacts using tools from the Linux Foundation’s digital signing project, [OpenSSF Sigstore](https://openssf.org/projects/sigstore/).
+2. Each project must document the process of verifying the artifacts using [OpenSSF Sigstore](https://openssf.org/projects/sigstore/). The project must have a file called `RELEASE.md`.
+3. Each project must enable and apply for a Sigstore's scorecard. The project must capture the scorecard's result and generate a badge visible on the README.md file.
+4. An LFDT incubation project will follow at least SLSA Level 1, while graduated projects will meet at least SLSA Level 2.


Suggested change

4. An LFDT incubation project will follow at least SLSA Level 1, while graduated projects will meet at least SLSA Level 2.

4. An LFDT incubation project must meet at least SLSA Level 1, while graduated projects must meet at least SLSA Level 2.

I've gone back and forth on whether graduated projects MUST sign artifacts, but after discussion at the TAC meeting I'm fine with it if there is a reference example of signing using Github Actions that we can point projects to.

tkuhrt · 2024-09-20T17:57:32Z

tac/governing-documents/release-signing.md

+- **Project Team:**
+  - Add a `RELEASE.md` file containing the build and release process of artifacts. Capture the information such as versioning followed, steps to reproduce the build, current release process, resources for verifying the signed artifacts at the least.
+  - Generate the scorecard and upload as a badge on `README.md` file.
+  - Each project will be responsible for the technical integration of Sigstore's cosign and scorecard into its build process. This approach allows projects to adapt the implementation to their specific needs while adhering to the overarching governance framework.


Suggested change

- Each project will be responsible for the technical integration of Sigstore's cosign and scorecard into its build process. This approach allows projects to adapt the implementation to their specific needs while adhering to the overarching governance framework.

- Each project will be responsible for the technical integration of Sigstore's cosign and OpenSSF's scorecard into its build process. This approach allows projects to adapt the implementation to their specific needs while adhering to the overarching governance framework.

petermetz

LGTM as long as the pending topics are resolved as well.

denyeart · 2024-10-24T13:59:48Z

tac/governing-documents/release-signing.md

+
+## Responsibilities
+- **Project Team:**
+  - Add a `RELEASE.md` file containing the build and release process of artifacts. Capture the information such as versioning followed, steps to reproduce the build, current release process, resources for verifying the signed artifacts at the least.


We use a RELEASING.md file in Fabric. I think this is typical when the file describes the process of creating a release.

denyeart · 2024-10-24T14:01:07Z

tac/governing-documents/release-signing.md

+1. The LFDT Technical Advisory Committee (TAC) standardizes the signing of artifacts using tools from the Linux Foundation’s digital signing project, [OpenSSF Sigstore](https://openssf.org/projects/sigstore/).
+2. Each project must document the process of verifying the artifacts using [OpenSSF Sigstore](https://openssf.org/projects/sigstore/). The project must have a file called `RELEASE.md`.
+3. Each project must enable and apply for a Sigstore's scorecard. The project must capture the scorecard's result and generate a badge visible on the README.md file.
+4. An LFDT incubation project will follow at least SLSA Level 1, while graduated projects will meet at least SLSA Level 2.


I've gone back and forth on whether graduated projects MUST sign artifacts, but after discussion at the TAC meeting I'm fine with it if there is a reference example of signing using Github Actions that we can point projects to.

tkuhrt · 2024-12-02T19:14:57Z

@arsulegai : Could you please update this pull request so that we may get it approved and checked in?

hendrikebbers · 2024-12-18T15:57:23Z

tac/governing-documents/release-signing.md

+  - The LFDT staff will maintain and secure the signing keys and the relevant infrastructure necessary for managing these keys. This centralization ensures a high level of security and reliability for key management practices.
+  - Scan for SBOM compliance.
+
+## General Recommendations


The document is called "Release Signing" but contains much more content. Maybe we extract the "General Recommendations" in a doc on the same level and name it "SLSA guidance" or something similar.

1. Introduce governance mechanism for secure software supply chain in LFDT. 2. Introduce a mandatory scorecard badge. 3. Introduce governance mechanism for release artifacts signing and verification. Signed-off-by: S m, Aruna <[email protected]>

arsulegai mentioned this pull request Sep 20, 2024

Secure Software Supply Chain hyperledger/toc#304

Closed

tkuhrt requested changes Sep 20, 2024

View reviewed changes

petermetz approved these changes Oct 5, 2024

View reviewed changes

tkuhrt requested review from mbrandenburger, swcurran, jimthematrix, yacovm, VRamakrishna and denyeart October 10, 2024 14:01

denyeart reviewed Oct 24, 2024

View reviewed changes

hendrikebbers reviewed Dec 18, 2024

View reviewed changes

VRamakrishna mentioned this pull request Dec 18, 2024

Project Lifecycle Transition Criteria #79

Merged

ryjones requested review from conor10 and non-fungible-nelson as code owners December 20, 2024 18:17

arsulegai force-pushed the slsa branch from 3f16d4e to d100e0e Compare January 16, 2025 15:36

arsulegai requested review from EnriqueL8, cjhowland, matthew1001 and wenjing as code owners January 16, 2025 15:36

arsulegai force-pushed the slsa branch from d100e0e to 9542fda Compare January 16, 2025 15:37

Secure Software Supply Chain

caf800a

1. Introduce governance mechanism for secure software supply chain in LFDT. 2. Introduce a mandatory scorecard badge. 3. Introduce governance mechanism for release artifacts signing and verification. Signed-off-by: S m, Aruna <[email protected]>

arsulegai force-pushed the slsa branch from 9542fda to caf800a Compare January 16, 2025 15:39

arsulegai requested review from tkuhrt, hendrikebbers and denyeart January 22, 2025 15:07

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Secure Software Supply Chain #26

Secure Software Supply Chain #26

arsulegai commented Sep 20, 2024

tkuhrt Sep 20, 2024

arsulegai Sep 21, 2024

tkuhrt Oct 10, 2024

petermetz Oct 18, 2024

tkuhrt Sep 20, 2024

tkuhrt Sep 20, 2024

tkuhrt Sep 20, 2024

tkuhrt Sep 20, 2024

tkuhrt Sep 20, 2024

denyeart Oct 24, 2024 •

edited

Loading

tkuhrt Sep 20, 2024

petermetz left a comment

denyeart Oct 24, 2024

denyeart Oct 24, 2024 •

edited

Loading

tkuhrt commented Dec 2, 2024

hendrikebbers Dec 18, 2024


		LFDT has a holistic approach to governing the security of projects and implements the highest levels of standards. The objective is to establish a consistent and secure approach to signing artifacts, leveraging industry-standard tools and practices while allowing flexibility for individual project implementations. Software verification processes are made available to ensure the integrity and authenticity of all artifacts throughout their lifecycle. A monitoring framework is introduced to score the project, rating the release process.

		This initiative aligns with efforts to establish a secure software supply chain for LFDT projects and achieve full [SLSA (Supply Chain Levels for Software Artifacts) compliance](https://slsa.dev/spec/v1.0/levels) in the release process.

	This initiative aligns with efforts to establish a secure software supply chain for LFDT projects and achieve full [SLSA (Supply Chain Levels for Software Artifacts) compliance](https://slsa.dev/spec/v1.0/levels) in the release process.
	This policy aligns with efforts to establish a secure software supply chain for LFDT projects and achieve full [SLSA (Supply Chain Levels for Software Artifacts) compliance](https://slsa.dev/spec/v1.0/levels) in the release process.

	2. Each project must document the process of verifying the artifacts using [OpenSSF Sigstore](https://openssf.org/projects/sigstore/). The project must have a file called `RELEASE.md`.
	2. Each project must document the process of signing and verifying the artifacts using [OpenSSF Sigstore](https://openssf.org/projects/sigstore/) in a file called `RELEASE.md`.

	3. Each project must enable and apply for a Sigstore's scorecard. The project must capture the scorecard's result and generate a badge visible on the README.md file.
	3. Each project must enable and apply for an [OpenSSF's scorecard](https://openssf.org/projects/scorecard/). The project must capture the scorecard's result and generate a badge visible on the `README.md` file.


		## LFDT Project Compliance

		1. The LFDT Technical Advisory Committee (TAC) standardizes the signing of artifacts using tools from the Linux Foundation’s digital signing project, [OpenSSF Sigstore](https://openssf.org/projects/sigstore/).

	4. An LFDT incubation project will follow at least SLSA Level 1, while graduated projects will meet at least SLSA Level 2.
	4. An LFDT incubation project must meet at least SLSA Level 1, while graduated projects must meet at least SLSA Level 2.

	- Each project will be responsible for the technical integration of Sigstore's cosign and scorecard into its build process. This approach allows projects to adapt the implementation to their specific needs while adhering to the overarching governance framework.
	- Each project will be responsible for the technical integration of Sigstore's cosign and OpenSSF's scorecard into its build process. This approach allows projects to adapt the implementation to their specific needs while adhering to the overarching governance framework.

Secure Software Supply Chain #26

Are you sure you want to change the base?

Secure Software Supply Chain #26

Conversation

arsulegai commented Sep 20, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

denyeart Oct 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

petermetz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

denyeart Oct 24, 2024 • edited Loading

Choose a reason for hiding this comment

tkuhrt commented Dec 2, 2024

Choose a reason for hiding this comment

denyeart Oct 24, 2024 •

edited

Loading

denyeart Oct 24, 2024 •

edited

Loading