How SBOM Supports the Secure Product Development Framework (SPDF): Mapping Components to FDA Cybersecurity Requirements

The U.S. Food and Drug Administration (FDA) now enforces strict software transparency requirements through Section 524B of the FD&C Act for medical device manufacturers. As part of your Secure Product Development Framework, the FDA’s automated eSTAR system instantly verifies your software inventory upon submission. When you submit an SBOM report with static spreadsheets, missing data fields, or unmapped open-source code, it immediately causes a Refuse-to-Accept (RTA) hold. This means stopping the process of submission before a human reviewer can see it.

The key to avoiding these delays is combining the SBOM and SPDF. This blend of SBOM and SPDF acts as a tracking system rather than a last-minute paper chase for compliance. It reveals unwanted third-party code, eliminates false-alarm security alerts, and links software vulnerabilities to patient safety within the quality system.

In this article, you’ll find out how using SBOM for medical device SPDF can help you operationalize your SPDF, standardize machine-readable schemas, which are CycloneDX and SPDX, and automate build pipeline security.

Key Takeaways

• SPDF ensures secure development, and SBOM enables software composition visibility.
• FDA Section 524B requires a machine-readable SBOM compatible with SPDF.
• Transitive dependencies and SOUP need to be considered for greater supply chain visibility.
• SBOM mapping enhances SAST, SCA, threat modeling, and VEX.
• Automated SBOMs through CI/CD ensure every software build stays current.
• VEX focuses on exploiting vulnerabilities, not all of them.
• Continuous monitoring helps manage vulnerabilities post-market effectively.
• Combining SBOM with SPDF will result in a fully auditable software supply chain.

What is Secure Product Development Framework (SPDF)?

SPDF is a set of security and management processes that helps medical device manufacturers to build and secure devices by integrating cybersecurity at each stage of development. Before considering issues regarding FDA documentation, statutory compliance, and creating a component inventory such as an SBOM, manufacturers should first develop an SPDF where cybersecurity is incorporated into TPLC. Understanding the importance of SBOM for SPDF is important because SBOM serves as the primary technical output.

Cybersecurity is not seen as a stand-alone entity but rather should be embedded within the Quality Management System (QMSR incorporating ISO 13485) and Software Development Lifecycle during four critical operations.

Phase 1: Design & Architecture

Defining security needs, conducting threat modelling for the architecture early before primary application code is written, and analysing risks for third-party components.

Phase 2: Development & Build

Implementing secure coding practices, creating automatic machine-readable SBOMs during build, and cryptographically signing software build artifacts.

Phase 3: Verification & Validation

Vulnerability Findings Triage using VEX documentation, running static and dynamic code scans, and performing penetration testing in physical hardware and network interfaces.

Phase 4: Post-Market Surveillance

Scanning fielded device component trees for vulnerabilities in public vulnerability databases and sending authenticated security patches to devices in the field.

Understanding the role of SBOM in the SPDF lifecycle across these four phases allows engineering and regulatory teams to maintain continuous compliance. 

What is the Importance of standardizing SPDF?

To build a compliant SPDF, it is necessary to integrate the existing software development processes within the company with the accepted international practices. The role of SBOM in the SPDF lifecycle includes three key frameworks that should be taken into account to create an acceptable SPDF:

• IEC 81001-5-1: Sets standards for health software security, secure coding, and continued software maintenance throughout the software lifecycle.
• ANSI/AAMI SW96: Provides requirements for medical device security risk management.
• NIST SP 800-218: Establishes the Secure Software Development Framework for verifying software supply chain integrity and build environments.

An industry analysis report from Censinet RiskOps™ shows that traditional post-market patching models cost up to 30 times more than embedding security controls during initial design. An SPDF puts this operational change in place through specific Quality System Design Controls:

• Design Input & Architecture: Cybersecurity requirements and threat models should be documented formally as design inputs in your official Design History File (DHF).
• Supplier & Component Management: Third-party open-source libraries and commercial off-the-shelf software must be assessed for risks before integration into the codebase.
• Continuous Verification: Static Application Security Testing (SAST) and Software Composition Analysis (SCA) must be performed in real-time during development.

Section 524B Mandates: Cyber Devices and Premarket Clearance

With the SPDF structural baseline established, manufacturers must evaluate the explicit legal mandates enforced under federal law. Section 524B of the FD&C Act provided the FDA with new statutory enforcement powers on medical device security under the Consolidated Appropriations Act. 

What is a Cyber Device?

A Cyber Device has three operational requirements that your product must satisfy under the FD&C Act. Section 524B(c) offers a clear statutory definition of Cyber Device:

• Software Componentry: Software, firmware, or programmable logic that has been validated, installed, and authorized by the sponsor or manufacturer.
• Network Connectivity: The device can be directly or indirectly connected to the Internet or a commercially available network interface such as Wi-Fi, cellular, Bluetooth/BLE, or physical USB/serial port.
• Vulnerability Vector: Software or technological features of the device that are vulnerable to cyberattacks or exploit vectors.

Avoid FDA 510(k) Submission Delays

Avoid costly FDA 510(k) delays by identifying SBOM compliance gaps before submission.

Book an SBOM Gap Assessment →

What happens when SPDFs, Threat Models, and Security Scans don’t work with machine-readable SBOMs?

SPDF outlines the security management approach, whereas SBOM contains the foundation for the data engine that enables SPDF functionality. About 76% of medical devices have software supply chain weaknesses. Mapping SBOM to SPDF guidelines clarifies how an open-source vulnerability flows within a medical device stack.

Vulnerabilities never exist in the primary application, but rather in nested third-party libraries. Think of how an unmapped open-source vulnerability flows within a medical device stack:

• Primary application code, such as Infusion Pump Firmware, includes a commercial Wi-Fi stack called Software of Unknown Provenance (SOUP). 
• The Wi-Fi stack is highly dependent on a transitive dependency, such as an OpenSSL cryptographic library. 
• An unmapped vulnerability disclosure (CVE) occurs within OpenSSL. 
• The third-party Wi-Fi component holds an embedded version of OpenSSL, which the vendor is unaware of. Consequently, it remains undiscovered and unfixed. After being installed in the hospital, attackers can take advantage of the vulnerable version of OpenSSL to execute their own code.

Mapping SBOM to SPDF guidelines properly helps to eliminate these blind spots.

Why Threat Models and Vulnerability Scans Fail Without Component Graphs

Threat modelling and vulnerability scanning heavily depend upon knowing exactly which software is present inside the medical device. The identified vulnerabilities found in medical products increased substantially year-over-year, and those actually used in the wild more than doubled, according to data published by Finite State and Health-ISAC.

Without explicit SBOM manifests, there are a few important reasons why standard security tools fail:

• Nested Transitive Dependencies: Open-source frameworks rely on secondary sub-libraries that hide critical vulnerabilities from basic file scanners.
• False Negatives in Threat Modeling: Threat modeling tools (STRIDE/PASTA) produce incomplete risk scores for threat modeling without a dependency tree of components.
• Manual Bottlenecks: Manual tracking of components in spreadsheets causes human error and slows FDA eSTAR reviews.

To ensure compliance, FDA reviewers evaluate how seamlessly engineering teams map software components to security testing and quality system design controls (21 CFR Part 820 / QMSR):

• Requirement Mapping: Trace all software elements directly to functional design requirements and threat model entries.
• Test Verification: Reference the software version in static code analysis and penetration testing reports.
• Vulnerability Tracking: Associate known component defects to mitigation records within your official Design History File (DHF).

Constructing an FDA-Compliant Medical Device SBOM Payload

FDA-approved SBOM for a medical device SPDF should include first-party, third-party, and transitive components incorporated into a medical device. To make sure that the SBOM can be easily read and processed, it must comply with the relevant industry standards, such as SPDX or CycloneDX. 

Going Beyond NTIA Minimum Data Elements

Although the National Telecommunications and Information Administration sets baseline SBOM standards, FDA premarket reviewers need more component metadata:

• Direct vs. Transitive Mapping: Account for both primary libraries and secondary implicit sub-dependencies.
• SOUP Inventory Under IEC 62304: Document all Software of Unknown Provenance (SOUP) and Off-The-Shelf (OTS) software.
• End-of-Support (EOS) & Lifecycle Tracking: The new FDA cybersecurity guidance also mandates manufacturers to document support status and known End-of-Support (EOS) dates for all the components of the SBOM.
• Precision Identifiers: Identify disambiguated components with Package URLs, Common Platform Enumerations, and binary cryptographic hashes.

Which SBOM Format Should You Choose? 

The FDA accepts SPDX and CycloneDX standard formats for premarket submissions. But architectural differences influence the ability of each schema to fit into medical DevSecOps pipelines:

What Does a CycloneDX v1.6 Look Like?

The following is an example of a production-ready CycloneDX 1.6 payload that is valid according to the CycloneDX schema and is submitted as part of a medical software submission, including End-of-Support lifecycle metadata and a set of SHA-256 hashes:

JSON
{
  "$schema": "http://cyclonedx.org/schema/bom-1.6.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-07-31T12:00:00Z",
    "component": {
      "type": "application",
      "name": "InfusionPump-Firmware",
      "version": "2.4.1"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "openssl",
      "version": "3.0.8",
      "purl": "pkg:generic/openssl@3.0.8",
      "cpe": "cpe:2.3:a:openssl:openssl:3.0.8:*:*:*:*:*:*:*",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "a2c3b4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3"
        }
      ],
      "lifecycles": [
        {
          "phase": "support",
          "expiration": "2028-09-07T00:00:00Z"
        }
      ]
    }
  ]
}

How to Automate SBOM and SPDF Security Throughout Development?

Embedding SBOM and SPDF means ensuring that SBOM controls are applied at each development stage. Automated DevSecOps pipelines enable security verification throughout the entire pipeline, not just at the end of development.

Phase 1 – Planning & Architecture Phase

• Threat Model Integration: Integrate third-party component data into the STRIDE or PASTA threat models in architecture design.
• Library License Audits and Vitality Audits: Assess whether a library is being used under an open-source license or whether the library’s upstream vendor is in good health before approving the library.

Phase 2 – Development & Build: Continuous CI/CD Pipeline Generation

According to research by RunSafe Security, 81% of healthcare purchasing organizations now rate SBOM availability as an essential procurement requirement. Automating creation within CI/CD pipelines guarantees that every build generates an attestation payload.

YAML
name: Medical Device DevSecOps Pipeline

on:
  push:
    branches: [ "main" ]

jobs:
  build-and-generate-sbom:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Source Code
        uses: actions/checkout@v4

      - name: Generate CycloneDX SBOM
        uses: CycloneDX/gh-python-generate-sbom@v2
        with:
          output: "sbom.json"

      - name: Cryptographic Attestation Signing
        run: |
          cosign sign-blob --key env://COSIGN_PRIVATE_KEY sbom.json --output-signature sbom.json.sig

Phase 3 – Verification & Testing Phase

• SCA & SAST Correlation: Associate findings from Software Composition Analysis with Static Application Security Testing.
• Vulnerability Exploitability eXchange (VEX): Create machine-readable VEX documents to prove if vulnerable code pathways are untouched during execution.

Phase 4 – Post-Market Operations Phase

• Continuous Monitoring: Check device component graphs against NVD, CISA Known Exploited Vulnerabilities (KEV), & Health-ISAC databases.
• Metrics Optimization: Reduce and measure Time-to-Detect and Time-to-Remediate for deployed field devices.
• Coordinated Vulnerability Disclosure (CVD): Manufacturers are required to have a formal CVD policy and to label devices in accordance with FDA guidelines (Section 524B(b)(2)) to report and receive alerts of vulnerabilities.

How Qualysec Helps Medical Device Manufacturers Build FDA-Compliant SBOM Reports 

Qualysec allows medical device makers to translate their highly engineered software code bases into FDA submission-ready artifacts without impacting their development process and risking an RTA under Section 524B.

Converting software artifacts to FDA requirements is hard; engineering tools provide unfiltered build outputs, but FDA eSTAR reviewers need exact compliance maps and clinical hazards. Automatic scanners may miss dependencies that are buried deep inside or produce a deluge of false positives. 

With the help of automatic pipeline analysis plus manual review, we close this gap by ensuring that your SBOM and SPDF documentation passes eSTAR ingestion and FDA reviewer validation from the get-go.

A 7-Step Process for FDA-Compliant SBOM Reports

1. Schema-Strict Extraction & Validation: We extract your build data and structure it into clean, schema-valid CycloneDX or SPDX files that will be accepted by eSTAR intake automatically.
2. Deep Component & Architecture Review: Our security engineers analyze your architecture and review exact versioning, custom binaries, and sub-tier dependencies according to IEC 62304 regulations.
3. Multi-Database Threat Intelligence: We correlate every software component with credible threat intelligence sources such as NVD, CISA KEV, MITRE CVE, and Health-ISAC notices.
4. Clinical & Patient Hazard Analysis: We assess how software vulnerabilities can impact your product’s use and identify specific reachability to ISO 14971 hazards.
5. Developer-Friendly Remediation Plan: You receive step-by-step instructions on fixing software vulnerabilities through patching, updating libraries, and implementing controls.
6. Regulatory-Ready Assembly of Findings: We compile your findings into compliant packages, including SBOMs, VEX to silence false positives, and cybersecurity risk assessment for 510(k), PMA, and De Novo submissions.
7. Continuous Post-Market Compliance Support: Once cleared, we constantly scan your deployed component list for newly disclosed vulnerabilities during the lifetime of your device.

Conclusion

Medical device manufacturers remove the need for manual and static documentation and integrate the generation of a machine-readable SBOM into their build pipelines, thus guaranteeing real-time visibility of upstream vulnerabilities.

The use of SBOM and SPDF together makes it easier for manufacturers to comply with the FDA Section 524B guidelines. The automation of SBOM creation using software development ensures that manufacturers can see real-time visibility of software components and new software vulnerabilities. This makes it easier for FDA eSTAR submissions and ISO 14971 risk management.

Preparing for an FDA 510(k) Submission?

Generate FDA-compliant SBOMs, SPDF, VEX documentation, and cybersecurity assessments with expert support.

Speak with Our FDA Compliance Team →

Frequently Asked Questions

1. What is the main difference between an SBOM and SPDF?

An SPDF is a comprehensive engineering approach to security throughout the life cycle of the product. An SBOM is one kind of particular machine-readable artefact created inside the SPDF that contains all software parts, dependencies, and metadata.

2. Is an SBOM mandatory for all FDA medical device submissions?

Yes. Section 524B of the FD&C Act requires an SBOM for all premarket applications like 510(k), PMA, and De Novo for Cyber Devices.

3. How to deal with legacy software binaries (SOUP) without source code?

You can use Binary Composition Analysis (BCA) tools to analyze binary files for the purpose of reverse engineering component structure, libraries, and symbols. 

4. What SBOM format does FDA prefer: SBOM (SPDX) or CycloneDX?

The FDA supports both the SPDX and CycloneDX formats. But CycloneDX is a popular choice in the MedTech DevSecOps space. It natively supports VEX documentation, End-of-Support lifecycle metadata, and Cryptographic Bills of Materials (CBOM). 

5. How does VEX help reduce false positive vulnerability reports? 

Manufacturers can use VEX to document when a vulnerability cannot be exploited in the device’s specific execution context and thus eliminate false alarms during the regulatory review process.

6. What is the frequency of the SBOM’s update in post-marketing surveillance?

An SBOM should be automatically updated upon software changes during build cycles. It should regularly scan for vulnerabilities throughout the operational lifetime of the device.