Cybersecurity risk and SBOM: connecting 524B to ISO 14971

FDA Section 524B pushed software bills of materials into the medical-device mainstream. An SBOM alone is an inventory. Regulated teams also need cybersecurity risk management: what a vulnerability means for patient harm, which requirements and mitigations respond, and what to re-verify when a new CVE lands.

This guide connects those layers — SBOM → risk → requirements/tests — on one thread.

Three layers people keep separate

Layer	Typical home	Job
SBOM inventory	SCA tool / build pipeline	What components you ship
Vulnerability intel	Scanner / NVD feeds	Which CVEs apply
Safety / security risk	ISO 14971 file / security risk assessment	What harm follows; what you mitigate

If those layers do not share IDs and links, every CVE becomes a meeting. If components are first-class records linked to hazards and requirements, a matched CVE gives you a component to follow straight to the hazards and requirements that depend on it. (A newly matched CVE does not flag suspect links by itself — triage is deliberate.)

Import the SBOM into the system of record

In traceunified, bring inventories in as CycloneDX or SPDX through SBOM import and triage via Import & triage an SBOM. Components become governed items — not a PDF attachment — so they can participate in risk and verification links. Re-import as builds change.

Link components to the risk file

For each critical component or vulnerability:

1. Identify hazardous situations / security risks (aligned with your ISO 14971 process and FDA cybersecurity guidance).
2. Link mitigations to requirements (hardening, patching policy, compensating controls).
3. Link tests that verify those controls.
4. Record residual risk acceptance where required.
5. When a new CVE hits a component you already ship, follow its links to the linked risks and verification and re-assess them as part of triage.

What “good” looks like in an audit conversation

• SBOM for the released version, regenerable from the project
• Known vulnerabilities triaged with rationale
• Trace from CVE/component → risk → requirement → test
• Evidence that a recent CVE led to a recorded re-assessment (not only a scanner email)

Evaluation questions

1. Import our CycloneDX file — are components linkable to risks and requirements?
2. Show how a component with a matched vulnerability leads you to its linked risks, requirements, and tests.
3. Can SBOM attestation sit beside a signed release package?

Related reading

• SBOM and FDA cybersecurity (524B)
• ISO 14971 risk on the thread
• SBOM module
• Suspect links and impact analysis
• SBOM import docs