Two small things in _metadata (src/icebergsca/report/cyclonedx.py:77), from the assessment against CISA's 2026 Minimum Elements (docs/cisa-sbom-minimum-elements-2026.md on branch claude/tool-sbom-requirements-assessment-jkudvt). Both are confined to one function.
1. Generation Context
A new field in the 2026 revision. It asks which SDLC phase the SBOM was generated in, and how and where, so a consumer can judge how complete it is likely to be. We say nothing.
The answer is unambiguous and does not need a flag. This tool reads source manifests and lockfiles; it never observes a build and never inspects a built artefact. Its SBOMs are always pre-build source analysis, produced by a third party rather than by the software producer.
That is worth stating for its own sake, not just for the checkbox — a source-derived SBOM cannot see vendored code, a dependency patched during the build, or anything the build injects. Of everything in the assessment this may be the most useful single sentence to add, because it bounds what the whole document can be relied on for. It is the same instinct as vulnerabilities_checked: say what was not done, so nobody infers it was.
metadata.lifecycles (tests/schemas/bom-1.6.schema.json:585) is the standard slot. A property recording per-unit source-of-truth — lockfile, manifest fallback, or reconstructed — belongs beside it, and overlaps with #25, so check that first for where the per-unit data should live.
2. 0.0.0 is a fabricated version
report/cyclonedx.py:85:
"version": report.tool_version or "0.0.0",
When the version is unknown this writes a plausible-looking lie. 0.0.0 is a real version string; a consumer diffing SBOMs or reconciling which build produced which document has no way to tell it from an actual 0.0.0 release. Omitting the key says the true thing, and CycloneDX makes version optional on a tool component.
tool_version defaults to "" (core/models.py:461), so this is reachable rather than theoretical — any ScanReport constructed without it hits the fallback, which is most of the test fixtures and anything constructing a report directly.
Small, but it is the same error the project prohibits everywhere else: a confident-looking value backed by nothing.
Done when
Two small things in
_metadata(src/icebergsca/report/cyclonedx.py:77), from the assessment against CISA's 2026 Minimum Elements (docs/cisa-sbom-minimum-elements-2026.mdon branchclaude/tool-sbom-requirements-assessment-jkudvt). Both are confined to one function.1. Generation Context
A new field in the 2026 revision. It asks which SDLC phase the SBOM was generated in, and how and where, so a consumer can judge how complete it is likely to be. We say nothing.
The answer is unambiguous and does not need a flag. This tool reads source manifests and lockfiles; it never observes a build and never inspects a built artefact. Its SBOMs are always pre-build source analysis, produced by a third party rather than by the software producer.
That is worth stating for its own sake, not just for the checkbox — a source-derived SBOM cannot see vendored code, a dependency patched during the build, or anything the build injects. Of everything in the assessment this may be the most useful single sentence to add, because it bounds what the whole document can be relied on for. It is the same instinct as
vulnerabilities_checked: say what was not done, so nobody infers it was.metadata.lifecycles(tests/schemas/bom-1.6.schema.json:585) is the standard slot. A property recording per-unit source-of-truth — lockfile, manifest fallback, or reconstructed — belongs beside it, and overlaps with #25, so check that first for where the per-unit data should live.2.
0.0.0is a fabricated versionreport/cyclonedx.py:85:When the version is unknown this writes a plausible-looking lie.
0.0.0is a real version string; a consumer diffing SBOMs or reconciling which build produced which document has no way to tell it from an actual0.0.0release. Omitting the key says the true thing, and CycloneDX makesversionoptional on a tool component.tool_versiondefaults to""(core/models.py:461), so this is reachable rather than theoretical — anyScanReportconstructed without it hits the fallback, which is most of the test fixtures and anything constructing a report directly.Small, but it is the same error the project prohibits everywhere else: a confident-looking value backed by nothing.
Done when
metadata.lifecyclesdeclares the pre-build source-analysis phase0.0.0fallback is gone and the key is omitted insteadwebsite/docs/output.mdand the skill mention the limitation, since it bounds what an agent may conclude from the SBOM