Medical Device SBOM Services Generation and Component Review

We quote a fixed fee after reviewing the device release, available source and build evidence, supplier components, existing SBOM, and analysis required. Generation, review, vulnerability assessment, and ongoing monitoring are distinct scope items. We do not publish an unconfirmed starting price.

Section 524B(b)(3) requires a software bill of materials covering commercial, open-source, and off-the-shelf software components for cyber-device submissions. The FDA's February 3, 2026 premarket guidance recommends machine-readable SBOM content, component support information, and assessment of known vulnerabilities. We document generation methods, provenance, verification, and unknown fields. Vulnerability monitoring and postmarket update responsibilities are agreed separately during scoping.

SPDX is Blue Goat's default delivery format. CycloneDX can be agreed where the manufacturer's tooling or workflow calls for it. The FDA does not mandate either named format. We agree the format, fields, provenance, and verification evidence before work begins, rather than treating a file format as proof of submission adequacy.

A component match does not by itself establish that a vulnerability affects your device. We review available configuration, use, exposure, and technical evidence within the agreed scope. VEX can record an applicability assessment where agreed. Unresolved questions remain explicit; the manufacturer approves final vulnerability dispositions.

Review the SBOM when software components or supplier information change and associate updates with the affected release. Your vulnerability management plan defines monitoring and triage cadence. Ongoing SBOM and VEX monitoring is a separate scope unless explicitly included in the proposal; one-time generation does not include indefinite monitoring.

Discuss your build system, existing inventory tools, release process, and access restrictions during scoping. Any pipeline work, automation, and handoff records must be agreed separately. We do not assume a particular platform or fixed implementation timeline before reviewing your environment.

We reconcile available build, source, binary, and supplier evidence for the agreed firmware release. The inventory records provenance and identification limits. Binary analysis can provide evidence where source is unavailable, but it does not establish complete visibility into every supplier component.

Record the supplier evidence requested, information received, and remaining gaps. Available binary evidence may support an inferred inventory with explicit limitations. Unknown support dates remain unknown pending supplier response. Your manufacturer team owns supplier agreements, component selection, and decisions about unresolved gaps.

The SBOM identifies software components. The threat model describes relevant attack paths and controls. The risk records document security impact and, where a finding can reach a patient, manufacturer-supplied harm severity. We agree the evidence connections in scope; an SBOM engagement does not automatically create or replace your threat model or ISO 14971 risk file.

Yes. Share the specific cybersecurity question and confirm the correspondence deadline with your regulatory team. We review existing inventory evidence and scope the updates or analysis needed for that question. Your regulatory team reviews and submits the response; the FDA makes the regulatory decision.

The proposal identifies the output format, files, analysis records, and handoff arrangements. SPDX is our default; another format can be agreed. Tool access, licensing, automation, and ongoing operations are separate matters to confirm during scoping, not assumptions attached to an SBOM file.

Available source and build evidence help component identification, but the scope can also include binary and supplier evidence. Agree processing and storage locations, assigned access, and return or destruction terms before transfer. Source stays within the agreed analysis environment. Component vulnerability lookups may send names, versions, and identifiers to vendor services, so restrictions must be agreed during scoping.