SBOM Best Practices for FDA Cybersecurity Submissions

What This Template Includes

A working SBOM (Software Bill of Materials) template pack for medical device cybersecurity submissions:

• SPDX 2.3 template with FDA-aligned fields (JSON and tag-value formats)
• CycloneDX 1.5 template with FDA-aligned fields (JSON format)
• Worked example for a hypothetical Class II SaMD device showing complete SBOM entries
• Vulnerability mapping worksheet linking SBOM components to known CVEs
• Lifecycle update workflow for keeping the SBOM current post-submission
• FDA cybersecurity submission cover letter template with SBOM references

The template pack is aligned with the FDA's 2023 Cybersecurity in Medical Devices final guidance and is compatible with the MFDS 2026 cybersecurity submission requirements.

Why SBOM Quality Matters

The FDA's 2023 final guidance made SBOM a required deliverable for premarket cybersecurity submissions. The submission expectation is not just "provide an SBOM" — it is "provide an SBOM that the reviewer can use to assess third-party component risk." The two are different.

A weak SBOM that lists components but omits versions, lacks license information, and provides no link to known vulnerabilities will be returned with deficiency findings. A strong SBOM enables the reviewer to quickly identify whether the device incorporates components with known critical vulnerabilities and how the manufacturer is managing them.

Roughly 30% of premarket cybersecurity deficiency letters we have seen relate to SBOM completeness or structure. The fix is a structured template that captures the required fields from the start of development.

Required Fields Per FDA Guidance

The FDA expects the SBOM to contain, at minimum:

1. Component name — official package name (e.g., "openssl", not "OpenSSL Cryptography Library")
2. Version — exact version including patch level (e.g., "3.0.7", not "3.x")
3. Supplier — origin organization or project (e.g., "OpenSSL Software Foundation")
4. License — SPDX license identifier (e.g., "Apache-2.0", "MIT", "GPL-3.0")
5. Component hash — cryptographic hash of the component artifact for integrity verification
6. Relationship — how the component is integrated (statically linked, dynamically linked, embedded, etc.)
7. Known vulnerabilities — CVE references for known issues, with manufacturer's risk assessment

Additional fields strongly recommended:

• Source URL — where the component was obtained
• Dependencies — the component's own dependencies (transitive)
• End-of-life status — whether the component is still maintained
• Patch availability — whether security patches are available for known vulnerabilities

SPDX vs CycloneDX: Which to Use

Both formats are accepted by FDA. The choice is largely about tooling.

SPDX — broader adoption in enterprise software supply chain (Linux Foundation steward). Better for organizations already using enterprise dependency-management tools (Black Duck, Snyk, Synopsys).

CycloneDX — broader adoption in security communities (OWASP steward). Better for organizations using security-focused tooling (OWASP Dependency-Track, OWASP DefectDojo).

For medical device manufacturers without existing SBOM tooling, CycloneDX is generally easier to start with — the JSON schema is simpler, the generator tooling (Syft, CycloneDX-CLI) is mature and free, and the integration with vulnerability databases is more direct.

For larger manufacturers with existing enterprise security tooling, SPDX is generally already in use — building on the existing tooling is the right call.

The Worked Example

The template pack includes a complete SBOM for a hypothetical Class II SaMD device — a cloud-connected diagnostic imaging viewer. The example demonstrates:

• 47 software components across application code, runtime libraries, and OS dependencies
• Mix of permissive licenses (MIT, Apache-2.0), copyleft licenses (LGPL-3.0), and proprietary (vendor SDK)
• Transitive dependency capture (component A depends on component B depends on component C)
• Known vulnerability mapping (2 components have known CVEs with documented risk assessment)
• Lifecycle status indicators (one component is approaching end-of-life)

The example file is approximately 800 lines in JSON format. It is intended as a reference for "what good looks like" — most actual devices will have 30–200 components depending on architecture.

Vulnerability Mapping Workflow

Beyond the SBOM itself, the FDA expects evidence of how the manufacturer monitors and responds to known vulnerabilities affecting SBOM components.

The included worksheet captures, for each vulnerable component:

• The CVE identifier and CVSS score
• The component version affected
• Whether the device's use of the component is exposed to the vulnerability (some vulnerabilities affect features the device does not use)
• The manufacturer's risk assessment
• The mitigation plan (patch, configuration change, compensating control, risk acceptance)
• The mitigation status and target date

This worksheet integrates with the Vulnerability Management Plan required by FDA cybersecurity submissions. The SBOM is the input; the worksheet is the operational output.

Lifecycle: SBOM Is Not One-and-Done

A common failure mode: manufacturers produce a clean SBOM for the premarket submission, then do not maintain it post-clearance. Six months later the SBOM is stale, new CVEs have emerged, and the post-market vulnerability management evidence shows gaps.

The lifecycle update workflow in the template covers:

• Automated SBOM regeneration tied to each build (CI/CD integration)
• Periodic SBOM review tied to vulnerability scanning cadence (monthly minimum, weekly preferred)
• Triggered SBOM updates on component changes
• SBOM versioning and archival (keeping historical SBOMs accessible for incident analysis)
• Cross-references from change control records to SBOM version

Manufacturers running this workflow report meaningfully faster response to emerging vulnerabilities — typically days rather than weeks from CVE disclosure to mitigation plan.

Integration with Korean MFDS Submissions

The 2026 MFDS cybersecurity guidance (effective July 1, 2026) accepts SBOMs in SPDX or CycloneDX format with substantially the same field requirements as FDA. An SBOM built for FDA submission can be reused for MFDS with translation of any narrative fields (component descriptions, risk assessments) into Korean.

This is one of the highest-leverage reusability points in cybersecurity submissions across the two jurisdictions. Manufacturers that build SBOM workflow well report 90%+ content reuse between FDA and MFDS cybersecurity packages.

Common SBOM Mistakes

Mistake 1: Listing only direct dependencies. Transitive dependencies often contain the vulnerable components. The SBOM must include the full dependency tree.

Mistake 2: Vague versioning. "OpenSSL 3.x" is not acceptable. "OpenSSL 3.0.7" with the exact patch level is required.

Mistake 3: Missing license information. Even open-source components have licenses. The license field cannot be left blank.

Mistake 4: Treating internal company libraries differently. First-party internal libraries are still components and belong in the SBOM. Their license is whatever the company internally uses (often proprietary).

Mistake 5: Static SBOM in a moving codebase. SBOMs generated manually at submission time become stale by the time of clearance. Automated generation tied to the build process is essential.

Download

Download the SBOM Template Pack — includes SPDX and CycloneDX templates, the worked example, vulnerability mapping worksheet, and lifecycle workflow guide.

Where Leanabl Plugs In

The Cybersecurity service runs full premarket cybersecurity submission preparation including SBOM, threat modeling, and vulnerability management plan. For SaMD-specific cybersecurity work in the Korean context, Korea SaMD Approval integrates cybersecurity with the broader submission.