v0.12 item 3: an SBOM of the wheel, measured from the wheel - #210
Merged
Merged
Conversation
I filed this behind "when a design partner asks", beside v1.0's EU controls pack. That was wrong, and the two are not the same kind of thing. A controls pack is prose about clause mappings, written on request. An SBOM is a build artifact generated mechanically from data this repository already holds, and it is produced at release time from the artifact itself, so deferring it means either retrofitting one onto tags already published or shipping releases that never had one. It also clears the standards rule without argument: `integrate first, map second, never claim compliance`. A bill of materials asserts conformance with nothing. It is a measurement. **From the built wheel, not from `pyproject.toml`.** `scripts/sbom.sh` installs the wheel into an empty environment and records what resolves. A manifest-derived SBOM would be this repository's opinion of its own dependencies, and the point of the document is to be checkable against reality, which is the same rule release verification already follows everywhere else here. **pip is uninstalled before the scan.** `python -m venv` seeds it, and a scanner reading that environment cannot tell "ctrlrun needs this" from "the venv came with this". An SBOM listing pip is wrong in the direction that matters: it overstates what a consumer is taking on, and nothing about a padded SBOM looks broken. `test_sbom.py` asserts the component list is **exactly** `PyYAML` and `click`, by equality and not containment, so a future Python that seeds a venv with something else fails the suite rather than shipping a wrong document. The result is worth having for what it says: two runtime dependencies, and `test_core_declares_only_pyyaml_and_click` pins that from the other side. CI generates and checks it on every pull request, so a change that would ship a wrong one goes red on the PR rather than at the tag. `release.yml` writes it into `dist/` **before** the attestation step, so it is signed along with the distributions: an unsigned inventory of a signed artifact is the weakest link in the pair. Not a Scorecard check. I checked the live API rather than assuming: SBOM is not among the eighteen scored for this repository, so this buys nothing on the 9.1 and is worth doing anyway. Signed-off-by: arpan <contact@arpanghoshal.com>
|
Warning Review limit reachedNext included review available in 24 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (7)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The SBOM step went red on its first real run with `['PyYAML', 'click', 'setuptools']`. Python 3.12 seeds only pip into a venv and 3.11 seeds setuptools as well, so the version I developed against was the one that hid it. That is the guard doing its job rather than a slip getting through. The assertion compares by equality and not containment precisely so a padded SBOM fails instead of shipping, and the thing it caught is a document that would have told a consumer ctrlrun depends on setuptools. `setuptools` and `wheel` go first, then pip, because pip cannot uninstall anything once it has removed itself. Verified on both interpreters: 3.11 and 3.12 now produce the same two components. Signed-off-by: arpan <contact@arpanghoshal.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I filed this behind "when a design partner asks", beside v1.0's EU controls pack. That was wrong, and the two are not the same kind of thing.
A controls pack is prose about clause mappings, written on request. An SBOM is a build artifact generated mechanically from data this repository already holds, produced at release time from the artifact itself. Deferring it means either retrofitting one onto tags already published or shipping releases that never had one.
It also clears the standards rule without argument.
ROADMAP.md: integrate first, map second, never claim compliance. A bill of materials asserts conformance with nothing. It is a measurement.From the built wheel, not from the manifest
scripts/sbom.shinstalls the wheel into an empty environment and records what resolves. A manifest-derived SBOM would be this repository's opinion of its own dependencies, and the point of the document is to be checkable against reality, which is the rule release verification already follows everywhere else here.Two runtime dependencies, and
test_core_declares_only_pyyaml_and_clickpins that from the other side.pip is uninstalled before the scan, and that is not cosmetic
python -m venvseeds pip, and a scanner reading that environment cannot tell "ctrlrun needs this" from "the venv came with this". The first draft produced exactly that:An SBOM listing pip is wrong in the direction that matters: it overstates what a consumer is taking on, and nothing about a padded SBOM looks broken.
tests/test_sbom.pyasserts the component list is exactly{PyYAML, click}by equality and not containment, so a future Python that seeds a venv with something else fails the suite rather than shipping a wrong document. Four assertions in all: the component set, the root's name/type/licence, that it is CycloneDX with a spec version, and that every component carries a version and a purl (a scanner matching on names alone is guessing).Where it runs
release.yml— written intodist/before the attestation step, so it is signed along with the distributions and attached to the GitHub release. An unsigned inventory of a signed artifact is the weakest link in the pair.cyclonedx-bomis hash-pinned in its ownrequirements/sbom.txtviascripts/lock.sh, like every other tool CI installs.One thing it does not buy
Not a Scorecard check. I pulled the live API rather than assuming: SBOM is not among the eighteen scored for this repository, so this does nothing for the 9.1. It is worth doing anyway, for the audience that actually reads one.
Gate
No docs pairing: this adds no page and changes no generated reference.
🤖 Generated with Claude Code