Build CRA-Ready SBOMs Before December 2027

The EU Cyber Resilience Act becomes applicable in December 2027. If you sell software products in the EU, you need verifiable Software Bills of Materials (SBOMs) for everything you ship. These must be auditable, machine-readable inventories of every component in your software supply chain.

The challenge is significant. Sixty-two percent of organizations find achieving high SBOM completeness quite difficult or extremely difficult. This difficulty increases with the complexity of software products, which often include hundreds of third-party dependencies. Many suppliers may not provide their own SBOMs.

This guide walks you through building a CRA-compliant SBOM program from scratch. You'll establish automated generation, manage supplier gaps, and create validation processes auditors will expect.

What You Need Before Starting

Tooling requirements:

• A package manager that supports SBOM generation (npm 9.0+, Maven 3.9+, pip 23.0+, or go 1.18+)
• SBOM generation tool (syft, trivy, or cdxgen)
• CI/CD pipeline with write access to artifact storage
• Version control system with branch protection
• Container registry if you ship containerized products

Organizational prerequisites:

• List of all products to be sold in the EU after December 2027
• Current software composition analysis (SCA) tool or budget to acquire one
• Supplier contact list with technical points of contact
• Legal review of supplier contracts for SBOM delivery clauses

Knowledge gaps to address:

• Which SBOM format to standardize on (SPDX 2.3 or CycloneDX 1.5)
• Your product versioning scheme and release cadence
• Where SBOMs will be published (customer portal, artifact alongside binary, API endpoint)

Step-by-Step Implementation

Phase 1: Generate Your First SBOM (Week 1-2)

Start with one product and one environment. Choose your simplest application.

For a Node.js application:

# Install syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Generate SBOM in SPDX format
syft packages dir:. -o spdx-json > sbom.spdx.json

# Validate the output
cat sbom.spdx.json | jq '.packages | length'

For a containerized application:

# Generate from built image
syft packages docker:myapp:latest -o cyclonedx-json > sbom.cdx.json

# Include OS packages and application dependencies
syft packages docker:myapp:latest --scope all-layers -o spdx-json > sbom-full.spdx.json

For Java with Maven:

# Add CycloneDX plugin to pom.xml
<plugin>
    <groupId>org.cyclonedx</groupId>
    <artifactId>cyclonedx-maven-plugin</artifactId>
    <version>2.7.9</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>makeAggregateBom</goal>
            </goals>
        </execution>
    </executions>
</plugin>

# Generate during build
mvn package
# SBOM appears in target/bom.json

Review the first SBOM manually. Check for:

• Recognizable direct dependencies
• Unknown transitive dependencies
• Version numbers matching your lock files
• Missing components (common with dynamically loaded modules)

Phase 2: Automate in CI/CD (Week 3-4)

Add SBOM generation to your build pipeline so every release artifact includes its SBOM.

GitHub Actions example:

- name: Generate SBOM
  run: |
    syft packages dir:. -o spdx-json > sbom-${{ github.sha }}.spdx.json
    
- name: Upload SBOM as artifact
  uses: actions/upload-artifact@v3
  with:
    name: sbom
    path: sbom-*.spdx.json
    
- name: Attach SBOM to release
  if: startsWith(github.ref, 'refs/tags/')
  run: |
    gh release upload ${{ github.ref_name }} sbom-${{ github.sha }}.spdx.json

GitLab CI example:

generate-sbom:
  stage: build
  script:
    - syft packages dir:. -o cyclonedx-json > sbom.cdx.json
  artifacts:
    paths:
      - sbom.cdx.json
    expire_in: 1 year

The SBOM should be versioned and stored alongside the binary. If you ship myapp-2.3.1.tar.gz, store myapp-2.3.1-sbom.spdx.json in the same location.

Phase 3: Handle Supplier Dependencies (Week 5-8)

This is where most organizations encounter challenges. You need SBOMs from your commercial software vendors, SaaS dependencies, and third-party libraries that don't generate them.

For commercial vendors:

• Send a formal request to your account manager with CRA Article 11 language
• Request SPDX 2.3 or CycloneDX 1.5 format
• Ask for SBOMs with each version release
• Specify delivery method (email, customer portal, API)
• Set a deadline: Q2 2026 to allow time for remediation

For open source dependencies without SBOMs:

• Generate them yourself from the source repository
• Document the generation method and tool version
• Store these in a separate directory: vendor-sboms/
• Re-generate quarterly or when you update the dependency

For SaaS dependencies:

• Many won't provide SBOMs for their hosted services
• Document this gap in your risk register
• Request attestations about their security practices instead
• Consider whether CRA applies to your use case (it covers products, not all services)

Create a supplier tracking spreadsheet:

Supplier	Product	SBOM Requested	SBOM Received	Format	Last Updated
Vendor A	Auth SDK	2024-01-15	2024-02-01	SPDX 2.3	2024-02-01
Vendor B	Analytics	2024-01-15	Pending	-	-

Phase 4: Integrate with Vulnerability Scanning (Week 9-10)

Your SBOMs should feed your vulnerability management process. Modern SCA tools ingest SBOM formats directly.

Using Grype for vulnerability scanning:

# Scan SBOM directly
grype sbom:./sbom.spdx.json -o json > vulnerabilities.json

# Set severity threshold
grype sbom:./sbom.spdx.json --fail-on high

Integration with existing SCA tools:

• Snyk: snyk test --file=sbom.spdx.json --package-manager=spdx
• Trivy: trivy sbom sbom.cdx.json
• Dependency-Track: Import SBOMs via API for continuous monitoring

Configure alerts for:

• New critical vulnerabilities in SBOM components
• Components with no identified license
• Components with end-of-life status
• Drift between SBOM and actual deployed code

Phase 5: Establish SBOM Governance (Week 11-12)

Create the policies and processes that turn SBOM generation from a technical task into an organizational capability.

Document your SBOM standard:

• Format: SPDX 2.3 (or CycloneDX 1.5 — pick one)
• Minimum data fields: package name, version, supplier, license, dependencies
• Generation frequency: every release build
• Storage location: artifact repository, retention period 7 years
• Access controls: who can retrieve SBOMs, audit log requirements

Define completeness thresholds:

• 100% coverage of direct dependencies
• 95% coverage of transitive dependencies (some may be dynamically loaded)
• All components must have license information
• All components must have supplier or origin information

Create escalation paths:

• Supplier doesn't provide SBOM within 90 days: escalate to procurement
• SBOM shows critical vulnerability: trigger incident response
• SBOM completeness below threshold: block release

Validation - How to Verify It Works

Run these checks before considering your SBOM program operational:

Completeness validation:

# Count components in SBOM
SBOM_COUNT=$(jq '.packages | length' sbom.spdx.json)

# Count dependencies in lock file
LOCK_COUNT=$(jq '.dependencies | length' package-lock.json)

# They should match within 5%
echo "SBOM components: $SBOM_COUNT"
echo "Lock file dependencies: $LOCK_COUNT"

Format validation:

# Validate SPDX format
spdx-tools Verify sbom.spdx.json

# Validate CycloneDX format
cyclonedx validate --input-file sbom.cdx.json

Audit trail test:

• Pull an SBOM from 6 months ago
• Verify it matches the binary artifact from the same release
• Confirm you can trace every component back to its source

Supplier SBOM test:

• Request an SBOM from your top 5 critical vendors
• Verify you receive it within 30 days
• Confirm the format is machine-readable
• Test importing it into your SCA tool

Vulnerability response test:

• Identify a component in your SBOM with a known CVE
• Verify your scanning tool detected it
• Confirm the alert reached the right team
• Document time to detection and notification

Maintenance and Ongoing Tasks

Daily (automated):

• Generate SBOMs for all builds
• Scan SBOMs for new vulnerabilities
• Alert on critical findings

Weekly (manual):

• Review SBOM generation failures
• Triage new vulnerability findings
• Update supplier SBOM tracking spreadsheet

Monthly:

• Audit SBOM completeness metrics
• Review supplier SBOM delivery status
• Update SBOM generation tools to latest versions

Quarterly:

• Re-request SBOMs from suppliers who haven't delivered
• Audit SBOM storage and retention
• Review and update SBOM policy
• Re-generate SBOMs for vendored dependencies
• Test SBOM retrieval and format validation processes

Annually:

• Full audit of SBOM program against CRA requirements
• Review supplier contracts for SBOM delivery clauses
• Update SBOM tooling and format standards
• Train new team members on SBOM procedures

The CRA's December 2027 deadline is firm. Start generating SBOMs now, automate the process in your next sprint, and begin the supplier conversation before your competitors fill their inboxes. Organizations that treat this as a compliance checkbox will struggle. Those that build SBOM generation into their development workflow will have supply chain visibility their competitors lack — and the audit trail to prove it.