[Docs] The SBOM is shipped with the web build only, not with every build #599

New issue

Closed

opened 2026-07-22 16:18:16 +00:00 by brenno · 1 comment

brenno commented

2026-07-22 16:18:16 +00:00

Owner

Found in the pre-publication claim audit.

The claim — docs/SBOM.md:9: the SBOM is "checked into the repository, kept current by a staleness gate in the test suite … and shipped with every build"; :165: "The SBOM travels with the product, not just the repository."

Evidence: only build-web does that. Makefile:687 — build-web: deps-verify-offline sbom-verify … :696-697 — mkdir -p build/web/sbom plus cp sbom/*. Makefile:718, :724, :730 (build-macos, build-windows, build-linux) run a bare flutter build — no SBOM copy, and not even sbom-verify as a prerequisite. README.md:5 calls OciDeck "A desktop application", so the three targets that do not carry the SBOM are the primary product.

Second claim, same file: docs/SBOM.md:52 says the inventory "can never disagree with what is actually built". The build-SDK row is read from .tool-versions (tool/sbom_build.dart:665-684), so sbom/ocideck.cdx.json records sdk:flutter@3.44.6 while the toolchain resolved in this checkout is 3.44.2. Nothing in the Makefile or the tests asserts that the running Flutter matches .tool-versions.

Why this matters now: SBOM.md is explicitly aimed at CRA readers — the audience that will open sbom/ocideck.cdx.json and compare it against a build. "Can never disagree with what is actually built" is falsifiable on the maintainer own machine today, and the "every build" claim is falsifiable by reading the Makefile.

Proposal: say "shipped with the web build; desktop bundles carry it in the release artefact" (which .github/workflows/release.yml:48-51 does declare, though that workflow has never run). Replace the second claim with "derived from the files that pin the build (pubspec.lock, MANIFEST.json, .tool-versions) — a machine whose Flutter differs from .tool-versions is not detected". Cheap code fix worth doing: add sbom-verify as a prerequisite to the three desktop targets.

Found in the pre-publication claim audit. **The claim** — `docs/SBOM.md:9`: the SBOM is "checked into the repository, kept current by a staleness gate in the test suite … and **shipped with every build**"; `:165`: "The SBOM travels with the product, not just the repository." **Evidence:** only `build-web` does that. `Makefile:687` — `build-web: deps-verify-offline sbom-verify` … `:696-697` — `mkdir -p build/web/sbom` plus `cp sbom/*`. `Makefile:718`, `:724`, `:730` (`build-macos`, `build-windows`, `build-linux`) run a bare `flutter build` — no SBOM copy, and not even `sbom-verify` as a prerequisite. `README.md:5` calls OciDeck "A desktop application", so the three targets that do *not* carry the SBOM are the primary product. **Second claim, same file:** `docs/SBOM.md:52` says the inventory "can never disagree with what is actually built". The build-SDK row is read from `.tool-versions` (`tool/sbom_build.dart:665-684`), so `sbom/ocideck.cdx.json` records `sdk:flutter@3.44.6` while the toolchain resolved in this checkout is 3.44.2. Nothing in the Makefile or the tests asserts that the running Flutter matches `.tool-versions`. **Why this matters now:** SBOM.md is explicitly aimed at CRA readers — the audience that will open `sbom/ocideck.cdx.json` and compare it against a build. "Can never disagree with what is actually built" is falsifiable on the maintainer own machine today, and the "every build" claim is falsifiable by reading the Makefile. **Proposal:** say "shipped with the web build; desktop bundles carry it in the release artefact" (which `.github/workflows/release.yml:48-51` does declare, though that workflow has never run). Replace the second claim with "derived from the files that pin the build (`pubspec.lock`, `MANIFEST.json`, `.tool-versions`) — a machine whose Flutter differs from `.tool-versions` is not detected". Cheap code fix worth doing: add `sbom-verify` as a prerequisite to the three desktop targets.

brenno added the

docs

label

2026-07-22 16:18:16 +00:00

brenno referenced this issue from a commit

2026-07-22 17:07:10 +00:00

docs: claims en cijfers die niet meer klopten (#602 #599 #614 #640 #634 #587 #623)

brenno referenced this issue from a commit

2026-07-22 17:12:52 +00:00

docs: claims en cijfers die niet meer klopten (#602 #599 #614 #640 #634 #587 #623)

brenno referenced this issue

2026-07-22 17:14:10 +00:00