STP
SBOM Observer/

Decision Trees

Structured decision frameworks for common SBOM scenarios

Decision trees provide systematic frameworks for navigating common SBOM choices and scenarios. Follow the paths based on your context to reach appropriate recommendations. These trees reflect common patterns but should be adapted to organizational needs.

Format Selection Decision Tree

START: Which SBOM format should we use?

Q1: What is your primary driver for SBOM adoption?

  • License compliance and legal requirements → Go to Q2
  • Vulnerability management and security operations → Go to Q3
  • Regulatory compliance (general requirement) → Go to Q4
  • Customer requirements (they specified format) → Use customer-specified format

Q2: License compliance focus

  • Do you need file-level licensing detail?
    • YES → Recommendation: SPDX (better file-level granularity)
    • NO → Go to Q5

Q3: Vulnerability management focus

  • Do you need integrated VEX capability?
    • YES → Recommendation: CycloneDX (superior VEX integration)
    • NO → Go to Q5

Q4: Regulatory compliance focus

  • Does regulation specify format?
    • YES, requires SPDX → Use SPDX
    • YES, requires CycloneDX → Use CycloneDX
    • NO, allows either → Go to Q5

Q5: Do you have existing tooling investment?

  • Tooling requires SPDX → Use SPDX
  • Tooling requires CycloneDX → Use CycloneDX
  • Tooling supports both → Go to Q6

Q6: Team expertise?

  • Team experienced with SPDX → Use SPDX
  • Team experienced with CycloneDX → Use CycloneDX
  • No significant experience with either → Recommendation: CycloneDX (operational focus, modern design, active development)

SBOM Update Frequency Decision Tree

START: How often should we update SBOMs?

Q1: What triggers software changes?

  • Every commit (continuous deployment) → Go to Q2
  • Regular releases (weekly, monthly) → Go to Q3
  • Infrequent releases (quarterly, annually) → Go to Q4

Q2: Continuous deployment

  • Are changes typically minor (dependency patches, small features)?
    • YES → Recommendation: Daily aggregated SBOM (hourly generates too much churn)
    • NO, major changes frequently → Recommendation: Per-deployment SBOM (every significant deployment)

Q3: Regular releases

  • Do dependencies change between releases?
    • YES, frequently → Recommendation: Per-release SBOM (every release gets new SBOM)
    • NO, rarely → Go to Q5

Q4: Infrequent releases

  • Do you apply security patches between releases?
    • YES → Recommendation: Per-release + per-security-patch (SBOM on any deployment)
    • NO → Recommendation: Per-release SBOM only

Q5: Are you under regulatory requirements?

  • YES, requires keeping SBOMs current → Recommendation: Per-release + periodic verification (SBOM with releases, quarterly verification for staleness)
  • NO specific requirement → Recommendation: Per-release SBOM (sufficient for most cases)

SBOM Distribution Strategy Decision Tree

START: How should we distribute SBOMs?

Q1: Who are your consumers?

  • Public (open source, freely available product) → Go to Q2
  • Customers only (commercial product) → Go to Q3
  • Internal only (not distributed outside org) → Go to Q7

Q2: Public distribution

  • Is product also publicly downloaded/accessible?
    • YES → Recommendation: Public download alongside product (GitHub releases, website, package registry)
    • NO (open source but not publicly distributed) → Go to Q3

Q3: Customer distribution - How many customers?

  • Under 50 customers → Go to Q4
  • 50-500 customers → Go to Q5
  • Over 500 customers → Go to Q6

Q4: Small customer base

  • Do customers have technical capability?
    • YES → Recommendation: Customer portal download + API
    • NO → Recommendation: Email distribution + portal backup

Q5: Medium customer base

  • Do customers need automation?
    • YES → Recommendation: API + webhook notifications + portal
    • NO → Recommendation: Customer portal + email notifications

Q6: Large customer base

  • Recommendation: Multi-channel automated distribution
    • Primary: API with webhook subscriptions
    • Secondary: Customer portal self-service
    • Tertiary: Email digests (opt-in only to avoid spam)
    • Consider: OCI registry attachments for container products

Q7: Internal distribution

  • Do you have SBOM repository infrastructure?
    • YES → Recommendation: Central repository with API (Dependency-Track, etc.)
    • NO → Go to Q8

Q8: Will you have over 20 products?

  • YES → Recommendation: Implement repository (manual tracking won't scale)
  • NO → Recommendation: Shared file storage + index (S3 bucket, SharePoint with manifest)

Supplier SBOM Request Priority Decision Tree

START: Which suppliers should we request SBOMs from first?

Q1: Supplier risk assessment

  • Does supplier provide critical infrastructure components?
    • YES → Priority: CRITICAL (request immediately)
    • NO → Go to Q2

Q2: Security exposure

  • Is supplier software internet-facing?
    • YES → Priority: HIGH (request within 30 days)
    • NO → Go to Q3

Q3: Regulatory scope

  • Is this supplier relationship subject to NIS2 or similar regulation?
    • YES → Priority: HIGH (regulatory compliance requirement)
    • NO → Go to Q4

Q4: Vendor maturity

  • Has supplier demonstrated SBOM capability or transparency?
    • YES → Priority: MEDIUM-HIGH (likely successful engagement)
    • NO → Go to Q5

Q5: Relationship type

  • Is this a major strategic vendor (high spend, long relationship)?
    • YES → Priority: MEDIUM (relationship supports engagement)
    • NO → Priority: LOW (address after higher priorities)

Prioritization summary:

  1. CRITICAL: Request immediately, escalate quickly if non-responsive
  2. HIGH: Request within 30-60 days, standard follow-up
  3. MEDIUM: Request within 90-120 days, patience with slower response
  4. LOW: Request within 6-12 months, opportunistic engagement

VEX Status Determination Decision Tree

START: What VEX status should we assign to this CVE?

Q1: Initial assessment

  • Have you completed technical analysis?
    • NO → Status: under_investigation (publish initial VEX, continue analysis)
    • YES → Go to Q2

Q2: Component presence

  • Is the vulnerable component present in your product?
    • NO → Status: not_affected (Justification: vulnerable_code_not_present)
    • YES → Go to Q3

Q3: Code reachability

  • Does your product execute the vulnerable code paths?
    • NO → Status: not_affected (Justification: vulnerable_code_not_in_execute_path)
    • YES → Go to Q4

Q4: Exploitability assessment

  • Can attacker control inputs to vulnerable code?
    • NO → Status: not_affected (Justification: vulnerable_code_cannot_be_controlled_by_adversary)
    • YES → Go to Q5

Q5: Compensating controls

  • Do you have mitigations preventing exploitation?
    • YES (input validation, sandboxing, etc.) → Status: not_affected (Justification: inline_mitigations_already_exist)
    • NO → Go to Q6

Q6: Remediation availability

  • Is patch or workaround available?
    • YES, deployed → Status: fixed (include version with fix)
    • YES, available but not deployed → Status: affected (include remediation timeline)
    • NO, not yet available → Status: affected (include expected timeline or workaround)

Automation Priority Decision Tree

START: What should we automate first?

Q1: Current state

  • Do you have manual SBOM generation working?
    • NO → First priority: Get manual process working (automate later)
    • YES → Go to Q2

Q2: Product count

  • How many products need SBOMs?
    • Under 10 → Priority: Validation automation (quality before scale)
    • 10-30 → Priority: Generation automation (manual doesn't scale)
    • Over 30 → Priority: End-to-end automation (generation, validation, distribution)

Q3: CI/CD maturity

  • Do products have automated build pipelines?
    • YES → Approach: CI/CD integration (natural automation point)
    • NO → Go to Q4

Q4: Without CI/CD

  • Will you implement CI/CD soon (under 6 months)?
    • YES → Recommendation: Wait and integrate with CI/CD (avoid throwaway automation)
    • NO → Recommendation: Scripted automation (standalone scripts for generation and distribution)

Q5: Bottleneck identification

  • What consumes most manual effort?
    • Generation → Automate generation first
    • Validation/quality checks → Automate validation first
    • Distribution to customers → Automate distribution first
    • All of above → Implement in sequence: generation → validation → distribution

Quality Gate Decision Tree

START: Should this SBOM pass quality gates?

Q1: Schema validation

  • Does SBOM pass schema validation?
    • NO → REJECT (fix schema errors, regenerate)
    • YES → Go to Q2

Q2: Completeness score

  • Is completeness score above minimum threshold?
    • NO (under 60 for Level 1, under 80 for Level 2) → Go to Q3
    • YES → Go to Q4

Q3: Completeness failure analysis

  • Can completeness be improved quickly (under 30 minutes)?
    • YES → CONDITIONAL PASS (approve with documented deficiency, require improvement)
    • NO → REJECT (requires significant rework)

Q4: Critical metadata

  • Are PURLs present for 90%+ of components?
    • NO → Go to Q5
    • YES → Go to Q6

Q5: PURL deficiency

  • Is this blocking deployment of critical security fix?
    • YES → CONDITIONAL PASS (approve with warning, track for improvement)
    • NO → REJECT (improve PURL coverage first)

Q6: For releases

  • Is SBOM signed?
    • NO → REJECT for production (signature required for releases)
    • YES → PASS (meets quality standards)

Q7: For development

  • Development/testing SBOMs don't require signatures
  • PASS (sufficient for non-production use)

Supplier Escalation Decision Tree

START: Supplier hasn't provided SBOM - what should we do?

Q1: Time since initial request

  • Under 30 days → ACTION: Wait (give reasonable time)
  • 30-60 days → Go to Q2
  • Over 60 days → Go to Q4

Q2: Response received?

  • NO response at all → ACTION: Send follow-up + escalate to supplier manager
  • Response received, working on it → ACTION: Confirm timeline, set next check-in
  • Response received, refusal → Go to Q3

Q3: Reason for refusal

  • Don't have capability → ACTION: Offer assistance, adjust timeline
  • Competitive concerns → ACTION: Address concerns, offer NDA
  • Not standard practice → ACTION: Explain regulatory trends, business case
  • Flat refusal → Go to Q4

Q4: Vendor criticality

  • Critical vendor (no alternative) → Go to Q5
  • Non-critical vendor (alternatives exist) → Go to Q6

Q5: Critical vendor escalation

  • ACTION: Executive escalation + contract review
    • Engage your executive sponsor + vendor executive
    • Review contract obligations
    • Discuss compliance requirements
    • Set hard deadline with consequences
    • Document escalation trail

Q6: Non-critical vendor evaluation

  • Can you tolerate no SBOM?
    • YES (low risk, low priority) → ACTION: Document risk acceptance, revisit annually
    • NO (risk unacceptable) → ACTION: Begin alternative vendor evaluation

Next Steps

Edit on GitHub

Checklists

Quick-reference checklists for common SBOM workflows and quality gates

Metrics and KPIs

Key performance indicators for measuring SBOM program effectiveness

On this page

Format Selection Decision TreeSBOM Update Frequency Decision TreeSBOM Distribution Strategy Decision TreeSupplier SBOM Request Priority Decision TreeVEX Status Determination Decision TreeAutomation Priority Decision TreeQuality Gate Decision TreeSupplier Escalation Decision TreeNext Steps