SBOM Generation for Medical Device Software: Practical Setup by Stack

SBOMs for medical device software should be generated automatically at build time in CI/CD, in a machine-readable, industry-accepted format such as CycloneDX or SPDX, from immutable inputs like lockfiles and pinned image digests. That supports the SBOM FDA requires for cyber devices under Section 524B(b)(3), the content FDA recommends in Section V.A.4 of its premarket cybersecurity guidance (February 2026), and IEC 62304 SOUP control evidence, and it means the inventory matches the exact release artifact instead of a hand-built snapshot. Components outside package managers, like vendor binaries, still need manual SOUP declarations merged into the generated file.

At CyberMed, we help teams prepare their full cybersecurity package for submission, but one file we don't directly generate is the SBOM.

That's intentional. Your SBOM should be generated inside your regular build cycle so it captures exact dependency data from the repository and release artifact, not a manually reconstructed snapshot.

This tutorial gives practical SBOM generation instructions across common software stacks. If your team uses a different language, framework, or toolchain, reach out and we can help you map an SBOM process to your environment.

This post covers tooling. For what FDA requires (an SBOM for cyber devices under Section 524B(b)(3)) and what it recommends (the NTIA minimum elements, support status, end-of-support dates, and vulnerability disposition under Section V.A.4 of the February 2026 guidance), see the FDA SBOM requirements guide.

Purpose and scope

This guide covers SBOM generation for:

• Embedded software
• Mobile apps
• Cloud and SaMD workloads
• Common backend ecosystems

The regulatory objective is to maintain a machine-readable software inventory (CycloneDX or SPDX) that supports FDA premarket cybersecurity documentation expectations for cyber devices and supports IEC 62304 SOUP control evidence used in EU MDR technical documentation. What reviewers expect to see in the submitted file is covered in our book section on SBOM analysis and documentation for eSTAR submissions.

General operating rules

1. Automate at build time

   • Generate SBOMs in the CI/CD Build phase so artifacts reflect exact release versions.

2. Generate a release SBOM from production/runtime dependencies

   • For submission and released-product evidence, exclude dev/test-only packages.
   • Keep a separate internal build/toolchain SBOM when needed for supply-chain investigations.

3. Include SOUP explicitly

   • Third-party and proprietary components outside package managers still need declaration.

4. Use immutable inputs

   • Build from lockfiles, pinned tool versions, and immutable image digests.

Toolchain setup by ecosystem

A) Embedded systems (C/C++)

Embedded projects often lack complete package-manager metadata. Filesystem scanning is one input, not the whole picture.

Use a combined method:

• build-system manifests (CMake/Conan/vcpkg/Yocto/Bazel, as applicable),
• source and filesystem scan,
• binary or artifact scan,
• manual SOUP declaration for vendor/toolchain components.

Tool: cdxgen (OWASP)

npm install -g @cyclonedx/cdxgen@X.Y.Z
cdxgen -t c -o sbom.json --recurse   # scan source and include submodules and SDKs

B) Rust (safety-critical SaMD)

Rust lockfiles are a good fit for deterministic dependency capture.

Tool: cargo-cyclonedx

cargo install cargo-cyclonedx --version X.Y.Z
cargo cyclonedx --all --format json --output-file sbom.cdx.json   # all workspace members, lockfile-resolved

C) Node.js (web-based SaMD)

For release evidence, focus on runtime dependencies and lockfile-resolved versions.

Tool: @cyclonedx/cyclonedx-npm

npm install -g @cyclonedx/cyclonedx-npm@X.Y.Z
cyclonedx-npm --output-format JSON --output-file sbom.json --omit dev   # runtime dependencies only

If your version supports lockfile-only mode, enable it in CI.

D) Python (AI/ML components)

Prefer lockfile-driven environments so outputs are reproducible.

Tool: cyclonedx-python (cyclonedx-bom package)

pip install cyclonedx-bom==X.Y.Z
cyclonedx-py poetry -o sbom.json   # Poetry workflow, recommended for deterministic builds

E) .NET (clinical enterprise software)

Generate at solution scope to capture cross-project dependencies.

Tool: dotnet-CycloneDX

dotnet tool install --global CycloneDX --version X.Y.Z
dotnet-CycloneDX MyMedicalApp.sln -o ./artifacts -f json

F) Mobile apps (Android and iOS)

Track platform SDK and mobile-library dependencies.

Android (Gradle CycloneDX plugin):

id 'org.cyclonedx.bom' version '1.8.1'

Run:

./gradlew cyclonedxBom

iOS (SwiftPM/CocoaPods):

• Use resolved dependency files (Package.resolved, Podfile.lock) as the source of truth.
• Generate from built app or archive artifacts when possible, not only raw source.
• If using Syft, scan built output and document known detection limits.

syft /path/to/MyApp.app -o cyclonedx-json > sbom.json   # scan the built artifact, not just the repo root

Cloud and containerized environments

For cloud/SaMD workloads in containers, include OS-layer packages, not only app-level libraries.

Tool: Syft (Anchore)

syft IMAGE_NAME@sha256:DIGEST -o spdx-json > sbom.spdx.json   # immutable release digest, not a mutable tag

Post-generation controls (do not skip)

Generating an SBOM file is step one. You still need validation and governance.

1. Validate schema and quality fields

cyclonedx-cli validate --input-file sbom.json   # CycloneDX validation example

If you emit SPDX, run SPDX-compatible validation with your selected validator as part of CI.

2. Enforce quality gates

Gate on at least:

• component name and version,
• supplier,
• cryptographic hashes,
• dependency relationships,
• identifiers (purl, and cpe where applicable).

These cover the NTIA baseline attributes that FDA's guidance points to, plus the hashes and identifiers that make vulnerability matching reliable. CISA's 2026 Minimum Elements for an SBOM (July 2026) extends that baseline, so check your gates against it as well. Support status and end-of-support date for each component, which FDA recommends in Section V.A.4.b, can live in the SBOM or in an addendum.

3. Centralize and monitor

Store SBOMs in a central system (for example, Dependency-Track) for ongoing vulnerability monitoring. How that monitoring feeds component selection and lifecycle decisions is covered in our book chapter on third-party component management.

4. Handle VEX

If a vulnerability exists in a component but is not reachable in your deployed architecture, document exploitability context in VEX.

Reference table

Environment	Primary Tool	Target File
C/C++	cdxgen	Makefile / CMakeLists.txt
Rust	cargo-cyclonedx	Cargo.lock
Node.js	cyclonedx-npm	package-lock.json
Python	cyclonedx-py	poetry.lock / requirements.txt
.NET	dotnet-cyclonedx	.csproj / .sln
Containers	syft	image digest

How do you add proprietary SOUP components to an SBOM?

When components are outside package managers (for example .lib, .dll, or vendor binaries), add them manually.

Capture at minimum:

• Supplier (organization/legal entity)
• Component name and version
• Identifier (purl and/or cpe where applicable)
• SHA-256 (or stronger) hash of shipped artifact
• Dependency scope and usage context
• Source/provenance reference (vendor advisory, release note, or controlled evidence)

Manual component template (manual-soup.json)

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [
    {
      "bom-ref": "vendor-proprietary-algorithm-4.2.0",
      "type": "library",
      "supplier": {
        "name": "Vendor Name"
      },
      "publisher": "Vendor Name",
      "name": "Proprietary-Algorithm-Library",
      "version": "4.2.0",
      "purl": "pkg:generic/proprietary-algorithm-library@4.2.0",
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
        }
      ],
      "scope": "required",
      "externalReferences": [
        {
          "type": "website",
          "url": "https://vendor.com/docs"
        }
      ]
    }
  ]
}

Then merge manual entries into your generated SBOM using your CycloneDX toolchain for the exact CLI version pinned in CI.

Implementation sequence for medtech teams

Use this rollout order:

1. Select canonical SBOM format(s) per release stream (CycloneDX and/or SPDX).
2. Generate SBOMs in CI from immutable inputs (lockfiles, image digests, pinned tools).
3. Bind SBOM artifact to release artifact/version (build ID, commit SHA, provenance record).
4. Produce release/runtime SBOM and retain internal build/toolchain SBOM as needed.
5. Add manual SOUP declaration workflow with explicit ownership and review.
6. Enforce validation + quality gates + central retention/monitoring.
7. Integrate SBOM and VEX outputs into risk management and postmarket response.

Final takeaway

Keep SBOM generation operational and traceable. An SBOM is an inventory, and it doesn't prove exploitability by itself. Regenerate it on every release, hotfix, and critical dependency change, and normalize identifiers consistently (purl first, cpe where high-confidence).

If your team can show how SBOM artifacts map to release versions, vulnerability review, and risk decisions, reviewers can move through your package faster and postmarket response becomes easier to defend.

Need help with your SBOM or your full cybersecurity submission package? Email us at info@cybermed.ai.

Sources

1. Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, FDA, February 3, 2026. Section V.A.4 covers SBOM content, support status, and end-of-support dates.
2. Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), 2nd edition, NTIA Multistakeholder Process on Software Component Transparency, October 21, 2021. The "minimum elements (baseline attributes)" document FDA's guidance cites.
3. The Minimum Elements for a Software Bill of Materials (SBOM), NTIA, July 12, 2021.
4. 2026 Minimum Elements for a Software Bill of Materials (SBOM), CISA and partners, July 29, 2026.
5. CycloneDX, OWASP Foundation, and SPDX, The Linux Foundation.
6. Known Exploited Vulnerabilities Catalog, CISA.