[REVIEW] sbom-analysis: add current format and artifact-bound evidence

[mlodygbelmondo]

Skill Being Reviewed

Skill name: sbom-analysis
Skill path: skills/vuln-management/sbom-analysis/

False Positive Analysis

Benign SBOM that can be under-rated as unsupported or incomplete:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "component": { "type": "application", "name": "payments-api", "version": "2026.6.1" }
  },
  "components": [],
  "services": [],
  "dependencies": [],
  "compositions": [],
  "declarations": {}
}

Why this is a false positive risk:

The skill frontmatter and process are pinned to CycloneDX 1.5 and SPDX 2.3. CycloneDX 1.6 has been released and adds supply-chain-relevant structures such as expanded BOM capabilities beyond a classic software component list. A valid CycloneDX 1.6 SBOM should not be treated as "other" or less analyzable only because the skill's version table stops at 1.5.

Coverage Gaps

Missed variant 1: Current SBOM formats are not recognized as first-class review targets

Accepted in skill: CycloneDX 1.5, SPDX 2.3
Current ecosystem examples: CycloneDX 1.6, SPDX 3.0.1

Why it should be caught:

Reviewers need to identify current format versions, then map fields safely instead of downgrading or ignoring newer SBOMs. SPDX 3.0.1 uses a model/profile structure that is different from SPDX 2.3's document/package-centric shape, so a parser or checklist that assumes only packages, files, and relationships can miss valid SPDX 3 SBOM data.

Missed variant 2: CISA's newer SBOM framing and 2025 minimum-elements draft are not tracked

Skill minimum-elements baseline: NTIA July 2021
Current references: CISA 2024 Framing Software Component Transparency and 2025 draft Minimum Elements

Why it should be caught:

The 2021 NTIA minimum elements remain important, but SBOM operational expectations have matured. Reviews should record whether the assessment is using the 2021 NTIA baseline, CISA's 2024 framing, or the 2025 draft guidance. Otherwise the same SBOM may be scored inconsistently for identifiers, relationships, generation context, and operational use.

Missed variant 3: VEX status is trusted without signer, product, version, and timestamp binding

VEX says:
  CVE-2026-12345: not_affected
  justification: vulnerable_code_not_in_execute_path
Missing:
  matching product/version identity
  document signature or trusted source
  timestamp/freshness
  statement scope for the deployed artifact digest

Why it should be caught:

The skill explains VEX statuses and justifications, but it should also require evidence that the VEX statement applies to the exact product version/artifact under review. A correct-looking not_affected justification is weak if it is unsigned, stale, scoped to a different edition, or not bound to the deployed component identity.

Missed variant 4: SBOM integrity and attestation are not separated from SBOM completeness

Image digest: sha256:prod
SBOM file: generated locally after pulling image tag latest
Attestation: none
Signature: none
Build provenance: absent

Why it should be caught:

An SBOM can be complete but still untrustworthy if it is not generated at the right build stage or bound to the immutable artifact it describes. The skill should ask for SBOM generation point, artifact digest binding, signature/attestation status, and provenance linkage separately from component-field completeness.

Edge Cases

• A CycloneDX 1.6 document may include valid fields that older 1.5-only tooling ignores.
• SPDX 3 profile/model structure can require different traversal than SPDX 2.3 package relationships.
• A vendor VEX can be valid for one product edition but not for another image, appliance build, or SaaS tenant variant.
• "Not affected" needs justification plus applicability evidence; the status alone is not enough.
• SBOMs generated from source, lockfile, container image, and running environment can produce materially different inventories.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: Refresh sbom-analysis to support current SBOM format versions and to distinguish field completeness, operational minimum-elements baseline, VEX applicability, and artifact-bound integrity/provenance evidence.

Comparison to Other Tools

Tool / Framework	Catches this?	Notes
CycloneDX 1.6	Yes	Current CycloneDX release with newer BOM capabilities than the skill's 1.5 baseline.
SPDX 3.0.1	Yes	Current SPDX model/profile structure differs from SPDX 2.3 assumptions.
CISA SBOM guidance	Partial	Provides current framing and draft minimum-elements expectations; reviewers must decide which baseline applies.
Syft / Trivy	Partial	Can generate SBOMs and sometimes attestations, but do not prove business applicability or VEX trust by themselves.
Cosign / in-toto attestations	Partial	Can bind SBOMs to artifacts, but the review still needs to verify generation point and scope.

Overall Assessment

Strengths:

• Strong coverage of NTIA minimum elements, dependency relationships, VEX statuses, transitive dependency risk, and license conflict detection.
• Useful distinction between CVE triage and SBOM-context analysis.
• Good output template for completeness and VEX summaries.

Needs improvement:

• The supported format baseline is stale for CycloneDX and SPDX.
• The minimum-elements baseline should be explicitly revisioned instead of assuming only the 2021 NTIA document.
• VEX review needs applicability evidence: signer/source, product identity, version, timestamp, and artifact scope.
• SBOM completeness should not be conflated with SBOM integrity or provenance.

Priority recommendations:

1. Add format detection for CycloneDX 1.6 and SPDX 3.0.1 while preserving support for CycloneDX 1.5 and SPDX 2.3.
2. Add a Minimum-elements baseline used field that records NTIA 2021, CISA 2024 framing, or CISA 2025 draft guidance when applicable.
3. Add a VEX applicability table: CVE, product, version/range, artifact digest, VEX source, signature/trust evidence, timestamp, status, justification, and confidence.
4. Add SBOM integrity checks for generation stage, immutable artifact binding, signature/attestation, and provenance linkage.

Sources Checked

• CycloneDX specification repository release table: https://github.com/CycloneDX/specification
• SPDX Specification 3.0.1: https://spdx.github.io/spdx-spec/v3.0.1/
• SPDX 3.0.1 SBOM class: https://spdx.github.io/spdx-spec/v3.0.1/model/Software/Classes/Sbom/
• CISA SBOM overview and current guidance links: https://www.cisa.gov/sbom
• CISA 2024 Framing Software Component Transparency: https://www.cisa.gov/sites/default/files/2024-10/SBOM%20Framing%20Software%20Component%20Transparency%202024.pdf
• CISA 2025 Minimum Elements for SBOM draft: https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom

Bounty Info

• I have read and agree to the CONTRIBUTING.md bounty terms
• Preferred payment method: to be provided privately after acceptance

[JamesJi79]

Review: Issue #196 (PR #300) — sbom-analysis: current format + artifact-bound evidence

Review Date: 2026-06-03
Skill: sbom-analysis (vuln-management)
PR Branch: origin/pr/300 (commit bd972d9)
Base Branch: main (commit f4f3374)
Reviewer: Hermes Agent

---

Summary

This PR adds support for current SBOM formats (CycloneDX 1.6, SPDX 3.0.1), introduces named minimum-elements baselines (NTIA 2021, CISA 2024, CISA 2025 draft), and adds a new Step 6 for SBOM integrity and artifact-bound evidence. It also restructures the previous VEX binding guidance into a cleaner VEX Applicability Gate subsection. Two new test files provide benign and vulnerable scenarios covering the new behaviors.

Overall Assessment: PASS — well-structured, content-complete, internally consistent. Minor optional suggestions below.

---

Changes Delivered

1. Format Support Expansion

• Description: Adds CycloneDX-1.6, SPDX-3.0.1, and CISA-SBOM-Guidance to the frontmatter frameworks list.
• SKILL.md impact: Updated identification guidance, output templates, and framework references throughout.
• Key details:
  • CycloneDX 1.5/1.6 identification: notes that specVersion can be "1.5" or "1.6", warns against downgrading a valid 1.6 SBOM to "unknown" due to stale parsers.
  • SPDX 2.3/3.0.1 identification: documents that 3.0.1 uses model/profile structure, not the document/package-only shape of 2.x.
  • New fields in SBOM Format Assessment: Parser Baseline and Version Handling.
• Verdict: Correct and complete. The "do not downgrade" guidance is a well-placed anti-pattern guard.

2. Named Minimum-Elements Baselines (NTIA/CISA)

• Description: Replaces the single "NTIA Minimum Elements" baseline with a selection model supporting NTIA 2021, CISA 2024 Framing, CISA 2025 draft, and custom contract profiles.
• Key details:
  • New "Baseline Selection" table in Step 2 with use-case guidance and evidence impact for each baseline.
  • Warnings against silently mixing baselines.
  • NTIA Completeness Assessment template updated with Minimum-Elements Baseline field.
• Verdict: Correct. This is well-researched and timely given CISA's evolving SBOM guidance.

3. VEX Applicability Gate (Restructured)

• Description: Replaces the previous Step 3A checklist (from PR Improve sbom-analysis VEX provenance binding #82, unmerged) with a cleaner VEX Applicability Gate subsection inside Step 3.
• Key details:
  • New Applicability Gate field in VEX assessment output (Pass | Fail | Not Evaluable).
  • Table-based evidence recording for CVE, product identity, component identity, artifact scope, source/trust, timestamp/freshness, and status/justification.
  • Low-confidence guidance: "If the VEX statement only names a component family, omits product/version scope, is stale, or is not bound to the artifact under review, mark confidence as Low."
• Verdict: Correct. The table format is clearer and more actionable than the previous checklist approach. The 8 SBOM-BIND codes from PR Improve sbom-analysis VEX provenance binding #82 have been effectively absorbed into structured fields.

4. New Step 6: SBOM Integrity and Artifact Binding (New Section)

• Description: Separates SBOM completeness from SBOM trust. A complete SBOM is weak evidence if not bound to the reviewed artifact.
• Key details:
  • Checklist for generation point, reviewed artifact, immutable binding, signature/attestation, freshness, and scope gaps.
  • Output template: Artifact-Binding Assessment with Reviewed Artifact, Artifact Digest/Hash, SBOM Subject Binding, Generation Point, Signature/Attestation, Freshness, and Trust Classification.
  • Trust classifications: Artifact-bound | Complete but unbound | Stale | Not evaluable.
• Verdict: Very well done. This is the core deliverable for "artifact-bound evidence." The trust classification provides clear guidance for downstream risk decisions.

5. Updated Output Format

• Description: Extended SBOM Overview with Parser Baseline, Minimum-Elements Baseline, Reviewed Artifact, and Artifact Digest/Hash. Expanded VEX Status Summary table with additional provenance columns. New SBOM Integrity and Artifact Binding section in the report.
• Verdict: Complete and consistent. All new fields are reflected in the output template.

6. New Common Pitfalls

• Pitfall intel: devsecops/compliance social updates 2026-03-25 #6: Stale parser downgrading current formats.
• Pitfall intel: appsec community updates 2026-03-29 #7: Mixing NTIA/CISA baselines without naming them.
• Pitfall intel: ai-security model-supply-chain community updates 2026-03-29 #8: Trusting complete but unbound SBOMs.
• Verdict: Relevant and well-placed. These directly support the new behaviors.

7. Test Files

• Benign: tests/benign/cyclonedx-16-artifact-bound.md — CycloneDX 1.6 SBOM bound to the reviewed container digest. Expected: treat as first-class format, preserve parser version, mark as artifact-bound.
• Vulnerable: tests/vulnerable/current-format-downgraded-by-stale-parser.md — Tool marks newer SBOMs as unknown. Expected: record parser limitation, don't downgrade, mark as Not Evaluable.
• Verdict: Correct. Tests follow standard scenario/evidence/expected-handling format. Each directly exercises a new behavior.

8. Other Updates

• Version bump: 1.0.0 → 1.0.1 (appropriate for substantial changes without breaking existing behavior).
• Immutable artifact identity added to "Context the Agent Needs" checklist.
• Framework Reference updated with CycloneDX 1.6, SPDX 3.0.1, and CISA SBOM Guidance sections.
• References section updated with new URLs for CDX 1.6, SPDX 3.0.1, CISA pages.
• Prompt Injection Safety Notice unchanged (still covers the right injection vectors for SBOM skills).

---

Detailed Findings

Pass Criteria

Criterion	Status	Notes
Skill frontmatter valid YAML	PASS	No syntax errors. Version bumped logically.
Markdown renders without issues	PASS	All tables, lists, code blocks are properly formatted.
New formats correctly documented	PASS	CycloneDX 1.6 and SPDX 3.0.1 identification guidance is accurate.
Artifact-bound evidence implemented	PASS	Step 6 is complete with checklist and output template.
Baseline selection model works	PASS	CISA 2024/2025 baselines added; mixing warning present.
VEX binding restructured cleanly	PASS	Table format is an improvement over the previous checklist.
Test files present and reasonable	PASS	Both benign and vulnerable scenarios directly exercise the changes.
Changes focused on #196 scope	PASS	Scope is format updates + artifact-bound evidence; no scope creep.
No breaking changes to prior structure	PASS	Existing steps 1-5 are preserved; Step 6 is additive.

Issue Checklist (from #196)

• Current format support: CycloneDX 1.6 and SPDX 3.0.1 added throughout.
• Artifact-bound evidence: New Step 6 with digest/hash matching, generation point tracking, trust classification.

---

Minor Optional Suggestions

1. SPDX 3.0.1 field mapping in the NTIA table: The NTIA minimum-elements table only maps CycloneDX 1.5 and SPDX 2.3 fields. For SPDX 3.0.1 documents (which use a model/profile structure), the SPDX 2.3 column is not directly applicable. Consider adding a "SPDX 3.0.1" column or a footnote explaining how to map 3.0.1 model elements to the 7 NTIA fields. This is non-blocking since the new "Baseline Selection" section already warns about format-specific handling.

2. Test files exist only on PR branch: The two test files exist in origin/pr/300 but not in the working tree. This is normal for a PR that hasn't been merged — just noting that final merge will populate them.

3. VEX table column width: The expanded VEX Status Summary table (10 columns) in the output format section is wide for markdown. Consider whether a condensed view with overflow notes would be more readable in terminal output. Minor formatting concern only.

4. Step 4 framework mapping: The framework mapping for Step 4 still reads "CycloneDX 1.5 dependencies array, SPDX 2.3 Relationship types" — this could be updated to reflect that CycloneDX 1.6 and SPDX 3.0.1 also support these structures. However, this is technically accurate since the fields are backward-compatible.

---

Conclusion

Recommendation: APPROVE

This PR cleanly delivers both requested features:

• Current format support: CycloneDX 1.6 and SPDX 3.0.1 are treated as first-class formats with explicit version-handling guidance and anti-downgrade protection.
• Artifact-bound evidence: The new Step 6 provides a structured, actionable framework for separating SBOM completeness from SBOM trust, with clear trust classifications.

The changes are internally consistent, well-documented, and include appropriate test scenarios. No blocking issues found. The four optional suggestions above are minor refinements that can be addressed in follow-up work.