Prevent Bad Actors from Hacking your SBOM

Prevent Bad Actors from Hacking your SBOM

Software supply chain transparency depends on a reliable SBOM. Whether you use a commercial sbom management software suite or an open source sbom tool like Dependency Track, the goal is the same: full visibility into every library, module, and dependency that makes up your product. Yet attackers know SBOMs are a trusted source of truth and starting to target them directly. Over the years of leading product SBOM Management, I’ve discussed various tactics that manipulate SBOMs. Below I share the best practices we preach at Cybeats to secure SBOMs in production, with a focus on regulated environments like security for medical devices.

The Five Horsemen of SBOM Manipulation

Omission of Vulnerable Components

A build pipeline that skips a deprecated library leaves security teams blind to exploitable CVEs. The US Cybersecurity and Infrastructure Security Agency warns consumers to verify SBOM integrity and origin before trusting it.

Mitigation

• Run an SBOM binary analysis tool BCA to generate SBOMs from compiled artifacts and compare to the ones provided by the vendor of the software or device.
• OWASP guidance shows this catches hidden or omitted components missed by source or build based SBOMs. As example and Operating System and it's packages.
• Automate these scans in CI/CD so any mismatch between the SBOM manifest and the actual binary triggers an alert in your SBOM monitoring pipeline.

Version Mismatch

If your SBOM lists OpenSSL at version 3.1.8 but you ship version 1.1.1w, vulnerability scanners of your customers will assume you are patched when you are not. This breaks your SBOM vulnerability management and creates a blind spot.

Mitigation

• Use SBOM tools for developers, build plugins for CycloneDX or SPDX to auto generate SBOMs during each build and automatically upload it to your SBOM managment tool.
• Record the artifact’s SHA256 hash of the generated SBOM file alongside the SBOM. Your SBOM management tool should reject any build where the hash or version drifts.

SBOM Spoofing and Source Validation

A forged SBOM can slip alongside a trojanized update and look perfectly legitimate unless you prove both integrity and provenance.

Mitigation

• Sign every SBOM with CycloneDX 1.6 JSF or XMLsig using commands like cdxgen
• Check hashes of SBOM components agains malicious package databases such as OSV and VirusTotal
• Provide the purl for every component with proper identification of package manager so the hashes captured in the SBOM can be compared to the hashes form the package mangers.

Package Instrumentation Manipulation

Instrumentation agents such as New Relic may modify open source libraries at build time for monitoring. A malicious actor could do the same to introduce backdoors or injecting malicious code.

• Component level hash validation. Expand your CycloneDX SBOM to include a hashes block for each component, recommended to use SHA256.
• Automate a hash check in CI/CD pipeline or at runtime so any unapproved instrumentation or tampering of dependency packages gets flagged immediately.

Tampering in Transit or Storage

Even a signed SBOM can be rolled back or swapped out if stored in an insecure repository.

Mitigation

• Whole SBOM file hashes publish a SHA256 digest of the entire SBOM in your release notes or via an API.
• Hash check on ingest your device SBOM management service computes the hash on download and rejects mismatches.
• Write once artifact repositories use object lock in S3 or similar to enforce read only access and eliminate silent rollbacks.

A Layered Defense Strategy

Why Integrity Matters in Medical Devices

Since October 1 2023 the FDA has required every cyber device pre market submission to include an SBOM that lists all commercial open source and off the shelf components. The FDA’s Premarket Cybersecurity Guidance specifies that SBOMs must be machine readable and generated as part of device design controls under 21 CFR 820.30. Regulators around the world are mandating similar integrity checks by following FDA rules and the NTIA CISA framing group guidelines. Although the FDA references the October 2021 NTIA framing document, it is now best practice to also follow CISA’s September 2024 framing document. In healthcare an altered SBOM could conceal a critical flaw in an infusion pump or pacemaker. That is why managing medical device security today means treating SBOM authenticity and provenance with the same form of care you apply to clinical data integrity.

Device makers would integrate SBOM workflows into their quality system processes sticking the following guidelines:

• Author Name: Legal entity (plus unique identifier, e.g., email or URL) that created the SBOM.
• Primary Component: The device or firmware image that is the SBOM’s subject.
• Component-Level SBOM: (machine-readable manifest) with all baseline and device-specific elements.
• Configuration Control: Maintain BOM in your device master record (21 CFR 820.181) and design history file (21 CFR 820.30(j))
• Regular Updates: Automate SBOM regeneration and submission of updates whenever any component changes.
• Risk & Vulnerability Annex: Table of CVEs, assessments, and controls.
• Vulnerability Discovery Method: e.g., NVD scan, CISA KEV, various advisories and code review.
• EOL/EOS Monitoring: Continuously scan for component end-of-life or end-of-support dates and flag obsolete/unsupported parts.
• Justification: if any attribute cannot be provided.

Which SBOM Platform Is Best for Software Supply Chain Security?

Teams often ask which SBOM platform is best for software supply chain risk. Look for these essentials:

1. End to integrity validation from upload to sharing
2. Unified SBOM Vulnerability Management Dashboard that supports VEX
3. Source independent SBOM ingestion for containers firmware and applications
4. RBAC for various roles across the company:
   
   1. Developers
   2. DevOps
   3. Product Security
   4. Product Managers
   5. PSIRT
   6. GRC
5. Public APIs that support integration with the ecosystem and automation flows
6. Organiaztional scalability with multi tenancy support
7. Alerting
8. Pricing model that scales

Solutions that nail these capabilities whether commercial or among the popular software bill of materials platforms rise to the top of best software bill of materials SBOM tools lists. When you evaluate SBOM vendors focus on proven scale and security features not slideware.

Key Takeaways

• Treat SBOMs as critical security artifacts not paperwork
• Automate SBOM creation and import via a software bill of materials tool
• Sign and hash every BOM and each component then verify both on ingest
• Cross check declared components with independent binary BCA/SCA
• Employ continuous SBOM monitoring tied to CVE and EOL feeds to respond in days not months

By hardening your SBOM integrity with these layered defenses you transform it into a proactive control that shields cloud apps on prem software and connected medical devices alike. That is how Cybeats helps organizations strengthen their software supply chain components verification.