Create generator-generic-ossf-slsa3-publish.yml #1815
Conversation
WalkthroughThis update introduces a new GitHub workflow aimed at generating Software Bill of Materials (SBOM) provenance files, aligning with the OpenSSF's SLSA level 3 requirements. It focuses on building artifacts and creating provenance subjects with sha256 checksums, alongside enabling external verification of these provenance files. This enhancement is a step forward in bolstering the security of the software supply chain. Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
|
nice |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 1
Configuration used: CodeRabbit UI
Files selected for processing (1)
- .github/workflows/generator-generic-ossf-slsa3-publish.yml (1 hunks)
Additional comments: 5
.github/workflows/generator-generic-ossf-slsa3-publish.yml (5)
- 1-11: The header comments provide a clear overview of the workflow's purpose, its alignment with OpenSSF initiatives, and the tools used for generating and verifying SLSA provenance files. It's good practice to include such comprehensive documentation at the beginning of a workflow file for clarity and transparency.
- 13-17: The workflow is triggered manually (
workflow_dispatch) and automatically on the creation of a release (release: types: [created]). This setup ensures flexibility in generating SLSA provenance files either on-demand or as part of the release process. It's a well-thought-out approach to trigger the workflow under these specific conditions.- 25-37: The steps for building artifacts are clearly defined, with a placeholder for the actual build commands. This section is crucial for generating the artifacts that will be referenced in the provenance file. Ensure that the placeholder commands (
echo "artifact1" > artifact1,echo "artifact2" > artifact2) are replaced with the actual build commands relevant to the project.Ensure that the build commands are correctly replaced with project-specific build steps.
- 47-55: The step for generating the provenance subjects uses
sha256sumto hash the artifacts and then encodes the output in base64. This is a critical step for generating the provenance file. However, ensure that thebase64 -w0command is compatible with the environment where the workflow runs. The-w0option is used to disable line wrapping in the output, which is important for generating a consistent hash. However, this option might not be available or behave differently on non-GNU systems.Verify the compatibility of
base64 -w0in the GitHub Actions runner environment.
- 57-66: The
provenancejob correctly specifies its dependency on thebuildjob and sets the necessary permissions for reading the workflow path, signing the provenance, and adding assets to a release. It uses theslsa-framework/slsa-github-generatoraction to generate the SLSA provenance file, passing the base64-encoded subjects from thebuildjob. This setup is well-configured for generating and optionally uploading the provenance file to a new release. It's a good practice to explicitly define permissions for each job to adhere to the principle of least privilege.
| jobs: | ||
| build: | ||
| runs-on: ubuntu-latest | ||
| outputs: | ||
| digests: ${{ steps.hash.outputs.digests }} |
There was a problem hiding this comment.
The build job is configured to run on ubuntu-latest. While this is a common practice, consider specifying a fixed version of Ubuntu (e.g., ubuntu-20.04) to ensure the workflow's stability over time. Using ubuntu-latest might lead to unexpected behavior if GitHub changes the underlying version.
- runs-on: ubuntu-latest
+ runs-on: ubuntu-20.04Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
| jobs: | |
| build: | |
| runs-on: ubuntu-latest | |
| outputs: | |
| digests: ${{ steps.hash.outputs.digests }} | |
| jobs: | |
| build: | |
| runs-on: ubuntu-20.04 | |
| outputs: | |
| digests: ${{ steps.hash.outputs.digests }} |
Purpose / Abstract
Summary by CodeRabbit