Validate and Sign

Generating an SBOM is necessary but insufficient for establishing software transparency. An SBOM containing inaccurate component information, missing dependencies, or corrupted data creates false confidence—consumers believe they understand software composition when they actually have incomplete or wrong information. This is worse than having no SBOM because it creates security blind spots disguised as visibility.

Validation ensures SBOMs meet quality standards before distribution. Signing provides cryptographic proof that SBOMs originated from claimed producers and haven't been tampered with during distribution. Together, validation and signing transform SBOMs from potentially misleading documents into trusted, verifiable transparency artifacts.

The Quality and Trust Problem

Software producers face two distinct but related challenges when distributing SBOMs:

Quality Problem: Automatically generated SBOMs often contain errors, omissions, or formatting problems that undermine their utility. Component version listed as "1.2.3" when actual deployed version is "1.2.4" due to build caching issues. Transitive dependency tree incomplete because build tool didn't recursively enumerate all levels. License field showing "NOASSERTION" for components where license is actually known but wasn't captured by generation tool.

Consumers receive these flawed SBOMs and make decisions based on incorrect information. Security team searches for vulnerable component version that SBOM says is present but actually isn't deployed (false positive). Or worse, team concludes product is safe because vulnerable component isn't listed in SBOM when it's actually present but was omitted during generation (false negative).

The fundamental problem: garbage in, garbage out. Automated generation produces SBOMs quickly, but speed without accuracy creates operational liability.

Trust Problem: Consumers receiving SBOMs need assurance they're authentic. SBOM claims to describe vendor's software, but how does consumer verify it actually came from vendor rather than attacker injecting malicious SBOM during transit? Man-in-the-middle attack could substitute SBOM hiding backdoored components for legitimate SBOM disclosing them.

Even without active attacks, operational confusion creates trust problems. Consumer receives SBOM via email from someone claiming to be vendor support engineer. Is this authentic or social engineering? SBOM published on website that looks like vendor's site but might be impersonation. Legitimate communication or credential harvesting?

Unsigned SBOMs cannot be trusted because authenticity cannot be verified. Trust requires cryptographic proof.

Validation Strategy

Effective validation operates at multiple levels, from schema compliance to semantic accuracy to operational fitness.

Schema Validation

First validation gate: does SBOM conform to format specification? CycloneDX 1.6 format requires specific JSON structure with mandatory fields, enumerated values for certain properties, and defined data types. Schema validation catches structural problems:

Invalid JSON syntax prevents parsing. Missing required fields like component name or version violates specification. Incorrect data types (string where integer expected) cause processing failures. Invalid enumerated values (license field containing non-SPDX identifier when spec requires SPDX) violate format rules.

Schema validation is fast, automated, and should be integrated into build pipelines as first quality gate. Failed schema validation should block SBOM publication immediately—structurally invalid SBOM is useless to consumers and damages producer reputation.

Validation implementation:

# CycloneDX validation using official schema
cyclonedx validate --input-file sbom.json --schema-version 1.6

# SPDX validation using official tools
java -jar spdx-tools.jar Verify sbom.spdx

Integration into CI/CD pipeline ensures every generated SBOM passes schema validation before proceeding to next stages. Build fails if SBOM is malformed, preventing broken artifacts from reaching production.

Completeness Validation

Second validation gate: does SBOM contain expected content? Schema compliance means SBOM is well-formed, but doesn't ensure it's comprehensive. Completeness validation catches content problems:

Component count too low suggests missing dependencies. Product with hundreds of npm dependencies shouldn't generate SBOM listing only 12 components. Required metadata fields populated with placeholder values rather than real data indicates incomplete generation. Entire dependency trees missing because build tool configuration excluded transitive dependency enumeration.

Completeness checks:

// Example completeness validation script
const sbom = JSON.parse(fs.readFileSync('sbom.json'));

// Check component count threshold
const componentCount = sbom.components?.length || 0;
if (componentCount < 10) {
  console.error(`Suspiciously low component count: €{componentCount}`);
  process.exit(1);
}

// Check for placeholder/missing data
const componentsWithoutVersion = sbom.components.filter(c => !c.version);
if (componentsWithoutVersion.length > 0) {
  console.error(`€{componentsWithoutVersion.length} components missing version`);
  process.exit(1);
}

// Check for license information
const componentsWithoutLicense = sbom.components.filter(
  c => !c.licenses || c.licenses.length === 0
);
const unlicensedPercent = (componentsWithoutLicense.length / componentCount) * 100;
if (unlicensedPercent > 20) {
  console.warn(`€{unlicensedPercent.toFixed(1)}% components without license info`);
}

// Check for PURL identifiers
const componentsWithoutPurl = sbom.components.filter(c => !c.purl);
if (componentsWithoutPurl.length > 0) {
  console.error(`€{componentsWithoutPurl.length} components missing PURL`);
  process.exit(1);
}

Completeness validation requires product-specific thresholds. Microservice with minimal dependencies might legitimately have 15 components. Enterprise monolith should have hundreds. Establish baselines through initial analysis and flag significant deviations.

Accuracy Validation

Third validation gate: does SBOM correctly describe deployed software? This is hardest validation but most critical for operational trustworthiness.

Runtime verification approach: Deploy software, enumerate actual runtime dependencies through inspection, compare to SBOM claims. Python application can introspect loaded modules via sys.modules. Container images can be analyzed post-build to enumerate installed packages. Compiled binaries can be scanned for linked libraries.

Discrepancies indicate accuracy problems. SBOM lists component X version 2.0 but runtime inspection shows version 2.1 actually deployed. SBOM omits component Y that runtime inspection confirms is present. SBOM includes component Z that isn't actually in deployment artifact.

Source code verification approach: Compare SBOM component list to source repository dependency declarations. package.json for Node, pom.xml for Java, requirements.txt for Python, go.mod for Go, Cargo.toml for Rust. SBOM should match dependency declarations plus transitives.

Perfect accuracy is difficult because build processes introduce complexity—caching, dependency resolution variations, platform-specific builds. But significant discrepancies indicate systematic problems requiring investigation.

Quality Metrics Tracking

Establish quantitative quality measures that track SBOM generation improvements over time:

Component coverage percentage: (Components in SBOM / Actual components deployed) × 100. Target: 95%+ for Level 2 maturity. Under 90% indicates significant gaps.

Metadata completeness: Percentage of components with complete information (name, version, PURL, license, supplier). Target: 90%+ for Level 2. Incomplete metadata undermines SBOM utility.

Validation failure rate: Percentage of generated SBOMs that fail validation on first attempt. High failure rate indicates problems with generation process requiring improvement.

False positive/negative tracking: When consumers report discrepancies (component in SBOM not in product, or vice versa), track these incidents. Frequent reports indicate accuracy problems.

Cryptographic Signing

After validation confirms SBOM quality, signing provides tamper-evidence and authenticity.

Signing Approaches

Embedded signatures (CycloneDX): CycloneDX 1.6 supports embedded signature components within SBOM structure. Signature algorithm, signature value, and certificate chain are included as part of SBOM JSON, creating self-contained attestation.

Detached signatures: Separate signature file accompanies SBOM. SBOM remains unsigned artifact; signature file (.asc for PGP, .sig for other schemes) provides attestation. Consumer must obtain both files and verify signature against SBOM content.

In-toto attestations: in-toto framework provides structured attestation format linking SBOM to build process. Attestation includes SBOM hash, build provenance, and signatures from multiple parties in supply chain. More comprehensive than simple SBOM signing.

Practical Signing Implementation

Digital certificate approach for organizations:

# Generate key pair (one-time setup)
openssl genrsa -out sbom-signing-key.pem 4096
openssl req -new -x509 -key sbom-signing-key.pem -out sbom-signing-cert.pem -days 730

# Sign SBOM
openssl dgst -sha256 -sign sbom-signing-key.pem -out sbom.json.sig sbom.json

# Publish both SBOM and signature
cp sbom.json sbom.json.sig /var/www/sbom-repository/product-v1.2.3/

PGP approach for simpler deployments:

# Sign with PGP key
gpg --detach-sign --armor sbom.json

# Creates sbom.json.asc signature file
# Publish both files; consumers verify using your public PGP key

Cosign approach for container ecosystems:

# Sign SBOM for container image using Cosign
cosign sign-blob --key cosign.key sbom.json > sbom.json.sig

# Store signature alongside SBOM
cosign attach signature --signature sbom.json.sig \
  registry.example.com/product:v1.2.3

Key Management

Signing effectiveness depends on key security. Compromised signing keys allow attackers to forge authentic-looking SBOMs, undermining entire trust model.

Key storage: Never commit signing keys to source repositories. Store in hardware security modules (HSM), cloud key management services (AWS KMS, Azure Key Vault, GCP KMS), or secure credential storage with strict access controls.

Access control: Limit signing key access to automated build systems and designated release engineers. Audit all key usage. Multi-person approval for key operations reduces insider threat risk.

Key rotation: Rotate signing keys periodically (annually minimum, quarterly for high-security contexts). Publish revocation notices for compromised or retired keys. Maintain certificate transparency logs showing key lifecycle.

Backup and recovery: Securely backup signing keys with recovery procedures. Losing signing keys breaks verification for all historical SBOMs. Encrypted backups in geographically distributed locations with tested recovery processes.

Validation and Signing Pipeline

Integrate validation and signing into automated CI/CD workflows for consistent, reliable execution.

Pipeline Integration Pattern

# Example GitHub Actions workflow
name: SBOM Generation and Attestation

on:
  release:
    types: [published]

jobs:
  sbom-attestation:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Build application
        run: npm ci && npm run build

      - name: Generate SBOM
        run: |
          npx @cyclonedx/cyclonedx-npm --output-file sbom.json

      - name: Validate schema
        run: |
          npx @cyclonedx/cyclonedx-cli validate --input-file sbom.json

      - name: Completeness checks
        run: |
          node scripts/validate-sbom-completeness.js sbom.json

      - name: Sign SBOM
        env:
          SIGNING_KEY: €{{ secrets.SBOM_SIGNING_KEY }}
        run: |
          echo "€SIGNING_KEY" > signing-key.pem
          openssl dgst -sha256 -sign signing-key.pem \
            -out sbom.json.sig sbom.json
          rm signing-key.pem

      - name: Publish to SBOM repository
        run: |
          aws s3 cp sbom.json s3://sbom-repo/product/€{{ github.ref_name }}/
          aws s3 cp sbom.json.sig s3://sbom-repo/product/€{{ github.ref_name }}/

      - name: Attach to release
        uses: actions/upload-release-asset@v1
        with:
          upload_url: €{{ github.event.release.upload_url }}
          asset_path: ./sbom.json
          asset_name: sbom.json
          asset_content_type: application/json

Pipeline ensures every release includes validated, signed SBOM without manual intervention. Build fails if validation fails, preventing distribution of low-quality SBOMs.

Consumer Verification Guidance

Producers should document how consumers can verify SBOM signatures, creating complete trust chain.

Verification Documentation

Publish public keys: Make signature verification keys publicly accessible. Website: https://example.com/sbom/signing-keys/2024-primary.pem. Key servers for PGP keys. In-repository for code-signed artifacts.

Provide verification instructions:

# Verifying SBOM Signatures

All SBOMs published by Example Corp are cryptographically signed.

## Download Files
- SBOM: https://sbom.example.com/product-v1.2.3/sbom.json
- Signature: https://sbom.example.com/product-v1.2.3/sbom.json.sig
- Public Key: https://sbom.example.com/keys/2024-primary.pem

## Verify Signature
openssl dgst -sha256 -verify 2024-primary.pem \
  -signature sbom.json.sig sbom.json

Successful verification displays: "Verified OK"

## Key Fingerprint
SHA256: a3:b2:c1:... (match against published fingerprint)

Transparency about signing practices: Explain signing workflow, key rotation schedule, what signature proves and doesn't prove. "Our signature verifies SBOM originated from Example Corp build system and hasn't been modified since signing. Signature does not attest to SBOM accuracy or completeness—see our Quality Assurance documentation for validation processes."

Quality Assurance Beyond Validation

Validation catches structural and obvious problems, but building truly trustworthy SBOMs requires broader quality culture.

Manual spot checks: Periodically sample generated SBOMs and manually verify accuracy against deployed software. Pick random component, confirm version matches deployed artifact. Check transitive dependency tree depth against known architecture.

Customer feedback loops: When customers report SBOM discrepancies, treat as quality incidents. Investigate root cause, fix generation process, update validation rules to catch similar issues. Frequent customer-reported issues indicate systematic problems.

Continuous improvement: Track validation failure trends. If schema validation failures are increasing, build tool configurations may be drifting. If completeness checks frequently fail, generation coverage is degrading. Use metrics to drive process improvements.

Third-party audits: For high-assurance contexts, engage external auditors to verify SBOM accuracy through independent analysis. Fresh perspective catches problems normalized by internal teams.

Common Validation Pitfalls

Pitfall 1: Validating only schema, ignoring completeness SBOM is well-formed but missing 40% of actual dependencies. Passes schema validation but is operationally useless.

Prevention: Implement multi-level validation covering structure, completeness, and accuracy. Don't rely solely on schema checks.

Pitfall 2: Signing SBOMs that failed validation Eager to meet deadlines, team signs and publishes SBOMs known to have quality problems. "We'll fix it next release." Cryptographic signature now attests to broken SBOM.

Prevention: Pipeline should make signing conditional on validation success. Failed validation = no signature = no publication.

Pitfall 3: Weak key management Signing keys stored in source repository, committed to Git history, accessible to all developers. Compromised keys allow signature forgery.

Prevention: Store keys in dedicated secrets management systems. Restrict access. Audit usage. Rotate regularly.

Pitfall 4: No verification documentation Producer signs SBOMs but doesn't publish public keys or verification instructions. Consumers cannot verify signatures, rendering signing pointless.

Prevention: Make verification as easy as generation. Publish keys prominently, provide clear instructions, test verification process from consumer perspective.

Pitfall 5: Inconsistent validation thresholds Different products have different validation rules, creating confusion about quality expectations. Product A requires 95% completeness, Product B accepts 60%.

Prevention: Standardize validation requirements across organization. Exceptions should be documented and justified, not arbitrary per-product decisions.

Maturity Progression

Level 1 (Basic): Schema validation using standard tools. Manual spot checks before major releases. Basic signing using organization-wide certificates. Validation runs on-demand rather than automatically.

Level 2 (Advanced): Automated multi-level validation in every build. Completeness and accuracy checking with product-specific thresholds. Automated signing with secure key management. Published verification documentation. Quality metrics tracking and continuous improvement.

Progression from Level 1 to Level 2 requires investment in validation tooling, pipeline automation, and key infrastructure, but dramatically improves SBOM trustworthiness.

Next Steps

Integrate with Generate SBOMs workflow
Prepare for Distribute to Customers
Understand quality principles in Quality and Validation
Implement verification as consumer via Validate Quality

Validate and Sign

On this page