Add workflow code to generate SBOMs and upload them to the release/pre-release#179
Add workflow code to generate SBOMs and upload them to the release/pre-release#179
Conversation
85920f3 to
6a499a3
Compare
setup.py no longer exists, but pyproject.toml has taken its place.
6a499a3 to
e5806d4
Compare
Thus our SBOMs are named, e.g., cisagov-skeleton-python-library.py3.13.spdx-json rather than sbom.py3.13.spdx-json.
216405b to
281d5aa
Compare
The latest release supports the artifact-metadata permission that we are now using in the generate-sbom job of the build.yml GitHub Actions workflow.
ef9a6a8 to
11e73ea
Compare
Note that actions/attest-build-provenance has changed its name to actions/attest, partly because it now supports different types of attestations. One such type is an SBOM attestation, which we are now using here.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This agrees with changes made elsewhere in this workflow.
This job name changed in a previous commit and hence needs to be updated here as well.
wheel need not be installed alongside setuptools as of setuptools 70.1.
felddy
left a comment
There was a problem hiding this comment.
Looks good. Nice and clean.
Not today, but in the future, we should consider decoupling the attestation steps from the build process. i.e., move attestation to its own workflow. This will be helpful when we move to reusable workflows, and have various artifacts to attest. (SBOMs, vulnerability scans, provenance, etc..)
Strong work! 💪
mcdonnnj
left a comment
There was a problem hiding this comment.
I spoke with @jsf9k in person about this but I have some reservations about SBOMs for our Python projects. The issue is that the only way to generate one at present is to create a lockfile of some kind (this PR uses Pipfile.lock) and generate an SBOM from this snapshot of dependencies. Unlike our Docker images there is no guarantee that the same software with the same versions will be installed when installing the project/wheel at a later point in time.
| - name: Setup tmate debug session | ||
| uses: mxschmitt/action-tmate@v3 | ||
| if: env.RUN_TMATE | ||
| generate-sbom: |
There was a problem hiding this comment.
I think a release workflow still makes sense here. We should be uploading a wheel to releases and it does not need to be built with different Python versions. I think a release workflow that builds a wheel for the release and then uploads the built wheel and SBOMs generated from that wheel makes more sense than band-aiding it to this workflow.
| artifact-name: >- | ||
| ${{ steps.manipulate-repo-name.outputs.repo-name }}.py${{ | ||
| matrix.python-version }}.${{ matrix.sbom-format }} | ||
| file: Pipfile.lock |
There was a problem hiding this comment.
An issue here is the SBOM may not accurately reflect the result of installing the Python package. The Pipfile.lock file is a snapshot in time of the dependency chain, but there is no guarantee of the same result if you install the wheel at a later point.
|
@mcdonnnj mentioned PEP 770, which is related. See also here and pypa/setuptools#4821). |
🗣 Description
This pull request:
💭 Motivation and context
CISA advocates for the use of SBOMs, so we should be generating them for our software products.
Resolves #178.
🧪 Testing
All automated tests pass.
✅ Pre-approval checklist
✅ Pre-merge checklist