Checklists

Checklists provide structured verification for complex workflows, ensuring critical steps aren't skipped and quality standards are met. Use these checklists during implementation, quality reviews, and operational execution. Adapt to organizational context—these are starting points reflecting common patterns, not rigid requirements.

Pre-Implementation Readiness Checklist

Before launching SBOM program, verify organizational readiness:

Technical Readiness

• Build automation exists or planned for target products
• Source code and dependency information accessible
• Technology stacks identified (languages, frameworks, package managers)
• Network access for SBOM tools to reach package registries
• Infrastructure for SBOM storage and distribution available
• CI/CD pipelines exist or planned for automation
• Initial tooling selected (generation, validation, repository)

Organizational Readiness

• Executive sponsorship secured with budget allocation
• Cross-functional working group formed (security, dev, legal, procurement)
• Program goals defined and communicated
• Success criteria and metrics identified
• Initial scope defined (products, timelines, maturity targets)
• Key stakeholders briefed and supportive
• Resource allocation confirmed (people, tools, time)

Knowledge and Skills

• Core team understands SBOM concepts and value
• Format selection made (CycloneDX, SPDX, or both)
• Tool operation knowledge exists or training planned
• Regulatory requirements understood (NIS2, CRA, procurement)
• Customer SBOM requirements documented
• Training plan developed for broader organization

Process and Governance

• Ownership model defined (who generates, validates, distributes)
• Quality standards documented
• Distribution channels identified
• Update cadence established
• Escalation paths defined for issues
• Integration touchpoints mapped (vulnerability mgmt, compliance, procurement)

SBOM Generation Checklist

For each product SBOM generation:

Pre-Generation

• Product version clearly identified
• Build environment prepared and dependencies resolved
• Generation tool configured for product technology stack
• Previous SBOM reviewed (if updating existing)
• Changes since last SBOM documented

Generation Execution

• SBOM generated using approved tools
• Transitive dependencies included (not just direct)
• Format specification met (CycloneDX 1.6+ or SPDX 2.3+)
• Metadata populated (timestamp, author, tools used)
• Component PURLs included where possible
• License information captured for components
• Hashes calculated for integrity verification

Post-Generation Validation

• Schema validation passed
• Component count reasonable for product complexity
• No placeholder values (NOASSERTION, N/A) above acceptable threshold
• Transitive dependency depth appropriate (multiple levels present)
• Known major dependencies confirmed present
• License information completeness above 80%
• PURL coverage above 90%
• Spot-check: sample components verified against actual deployment

SBOM Quality Validation Checklist

When receiving or generating SBOM, assess quality:

Structural Quality

• Valid JSON/XML syntax
• Schema validation passes (CycloneDX or SPDX spec)
• Required fields populated
• Appropriate data types used
• UUIDs valid where required
• Timestamps in ISO 8601 format with timezone
• Version information present and properly formatted

Content Completeness

• Component count aligns with product complexity (under 10 for complex app = suspicious)
• Component names and versions present for all entries
• PURLs present for 90%+ of components
• License information present for 80%+ of components
• Supplier/author information included where known
• Component relationships documented (dependency graph)
• Transitive dependencies enumerated (not just directs)

Accuracy Indicators

• Known major components confirmed present
• Component versions plausible (not all version "1.0.0")
• No obvious duplicates with different identifiers
• Dependency depth reasonable (not all depth-0)
• For binary analysis: file counts match expected artifacts

Operational Fitness

• Suitable for intended use case (vuln mgmt, compliance, etc.)
• Metadata includes generation method and tool information
• Contact information for SBOM questions provided
• Links to additional resources included
• Confidence level documented if applicable
• Known limitations documented

Quality Score Targets

• Completeness score above 70 (basic) or 85 (advanced)
• Validation pass rate above 90%
• No critical quality issues blocking operational use

Supplier SBOM Request Checklist

When requesting SBOMs from suppliers:

Pre-Request Preparation

• Supplier identified and prioritized (risk-based)
• Products in scope documented
• Format requirements determined
• Delivery channel established
• Request template prepared or customized
• Contact person identified at supplier
• Timeline expectations set (30-60 days reasonable)

Request Content

• Clear subject line indicating SBOM request
• Product and version clearly specified
• Format requirements stated (CycloneDX, SPDX, or flexible)
• Purpose explained (compliance, risk mgmt, customer requirement)
• Delivery method specified (email, portal, API)
• Timeline requested with specific date
• Contact information for questions provided
• Resources offered if supplier needs guidance
• Follow-up plan documented

Post-Request Tracking

• Request logged in tracking system
• Acknowledgment received from supplier
• Follow-up scheduled (15 days if no response)
• Escalation path defined if needed
• Receipt date tracked
• Quality assessment planned upon receipt

Upon Receipt

• SBOM received and stored
• Format validated
• Quality assessed using validation checklist
• Feedback provided to supplier if issues found
• Thanks communicated for good-quality submission
• Internal stakeholders notified of availability
• Tracking system updated with delivery status

VEX Publication Checklist

When publishing VEX document for vulnerability:

Assessment Phase

• CVE identified and understood
• Affected component confirmed in product SBOM
• Impact analysis completed (code reachability, configuration dependencies)
• Status determined (under_investigation, not_affected, affected, fixed)
• Justification documented if not_affected
• Remediation path identified if affected
• Timeline for resolution estimated
• Stakeholders consulted (development, security, product)

VEX Document Creation

• Format selected (CycloneDX VEX, CSAF, standalone)
• CVE ID correctly referenced
• Product version(s) specified
• Status clearly stated
• Justification provided for not_affected determination
• Action statement included for affected status
• Timeline information provided
• Impact statement included
• Contact information for questions
• References to patches or workarounds

Publication

• VEX document validated against schema
• Signed with organizational key
• Published to designated channels (API, portal, advisories page)
• Customers notified of availability
• Internal tracking systems updated
• Security advisory published if warranted
• Metrics recorded (time to VEX, status distribution)

Follow-Up

• Monitor for status changes requiring VEX update
• Update VEX when moving from under_investigation to definitive status
• Publish fixed status when patch deployed
• Track customer questions and update VEX if clarification needed
• Document lessons learned for future VEX publications

Pre-Release SBOM Checklist

Before releasing product with SBOM:

SBOM Preparation

• Current SBOM generated from release candidate
• All validation checks passed
• Quality score meets organizational standards (80+ for releases)
• Enrichment completed (metadata, hashes, signatures)
• Known issues documented in SBOM metadata
• Cryptographic signature generated
• Signature verification instructions prepared

Distribution Readiness

• Distribution channels prepared (portal, downloads, API)
• SBOM uploaded to all designated channels
• URLs and access instructions verified
• Customer notification prepared (if applicable)
• Documentation updated with SBOM information
• Release notes mention SBOM availability

Internal Coordination

• Security team aware of release and SBOM availability
• Support team briefed on SBOM (in case of customer questions)
• Product team confirms SBOM aligns with release
• Legal team approved disclosure (if concerns existed)
• Metrics baseline captured for comparison post-release

Post-Release

• SBOM accessibility verified from customer perspective
• Initial customer feedback monitored
• Internal repository updated with release SBOM
• Vulnerability monitoring initiated for new release
• Metrics updated (products with SBOM, quality scores)

Incident Response SBOM Checklist

When vulnerability disclosed:

Immediate (Hour 0-4)

• CVE details captured (ID, severity, affected components)
• SBOM repository queried for affected component
• Initial impact assessment: affected products identified
• Severity classification determined (CVSS + context)
• Key stakeholders alerted
• Investigation task force assembled if critical

Assessment (Hour 4-24)

• Detailed impact analysis per affected product
• Exploitability assessed (code paths, configurations)
• VEX status determined (investigating, not_affected, affected)
• Initial VEX published if status determined
• Customer communication drafted
• Remediation options evaluated

Response (Day 1-7)

• Patches identified or developed
• Workarounds documented if patches unavailable
• VEX documents updated with definitive status
• Customer notifications sent
• Remediation deployed to critical systems
• Progress tracked and reported

Resolution (Week 1+)

• All affected systems remediated or risk accepted
• Final VEX status published (fixed or accepted)
• Updated SBOMs published showing patched versions
• Incident retrospective conducted
• Lessons learned documented
• Process improvements identified and implemented

Supplier Evaluation Checklist

When assessing supplier SBOM capability:

SBOM Provision

• Supplier provides SBOM without extensive prompting
• SBOM delivery timely (within 30 days of request)
• Format meets requirements (CycloneDX or SPDX)
• Updates provided with new releases
• Distribution mechanism reliable and accessible

SBOM Quality

• Schema valid and complete
• Comprehensive component enumeration
• Transitive dependencies included
• License information present
• Metadata properly populated
• Quality score above 70

VEX Capability

• VEX documents published for known vulnerabilities
• VEX publication timely (under 7 days for critical)
• Status justifications clear and detailed
• Updates provided as status changes
• Multiple VEX formats supported (optional but valuable)

Communication

• Responsive to SBOM questions
• Proactive about updates and issues
• Clear contact information provided
• Willing to improve based on feedback
• Documentation available and helpful

Overall Supplier Rating

• Excellent (90-100): Exceeds expectations, proactive, high quality
• Good (75-89): Meets requirements, responsive, acceptable quality
• Marginal (60-74): Minimally compliant, reactive, quality concerns
• Poor (under 60): Non-compliant, unresponsive, or low quality

Next Steps

• Apply checklists during implementation following Implementation Guides - Maturity Progression
• Use for quality gates in Producer Workflows - Validate and Sign
• Reference during supplier engagement in Consumer Workflows - Request from Suppliers
• Complement with Reference - Decision Trees