On this page
Published:
Key Takeaways
- The SBOM must refer to the agreed shipped software version, not only a development manifest.
- Source/build evidence, binary analysis, and supplier information are reconciled, and more complete inputs produce a more complete SBOM.
- Support level and end-of-support fields need evidence; unknown dates remain explicitly unknown pending supplier response.
- Failed enrichment review means correction and re-verification before delivery, followed by second-person peer review.
- These are Blue Goat Cyber methodology controls, not an FDA certification or guarantee of review outcomes.
How does Blue Goat Cyber verify a medical device SBOM before delivery?
Blue Goat Cyber checks that the SBOM describes the agreed shipped software, reconciles available source/build and binary evidence, verifies component support information, and completes an enrichment gate and second-person peer review before delivery. A generator's output is an input to that review, not proof that the inventory is complete.
Reviewed October 23, 2026. Based on Blue Goat Cyber's BGC-GUIDE-SW-002, Rev B, effective October 22, 2026.
A component list is useful only when its entries correspond to the software under assessment. A manifest can omit a statically linked library, a supplier can provide an SBOM for a different release, and an end-of-support field can contain a guess rather than supplier evidence. Our verification process addresses those gaps before we deliver the inventory.
This page covers verification before delivery. For statutory applicability, format selection, SAST, and lifecycle management, start with the broader medical-device SBOM guide.
1. Identify the shipped software being assessed
The manufacturer identifies the software systems and release in scope. We agree which source repositories, manifests, lock files, build outputs, released binaries, firmware, and supplier records will be available. The scope may include several software-bearing parts of a device system, but we do not imply coverage of an app, cloud service, or firmware image that was not supplied and assessed.
| Input | What we check | Why it matters |
|---|---|---|
| Source revision and build records | Connection to the agreed release | Development dependencies may differ from shipped components |
| Manifests and lock files | Resolved versions and dependency relationships | A package name alone does not identify the shipped version |
| Released binary or firmware | Version and available component evidence | Compiled or vendored components can be missing from source manifests |
| Supplier SBOM and component records | Product/version match and supporting information | A supplier document for another release can mislead vulnerability analysis |
The manufacturer remains responsible for configuration management and the connection between the inventory and its approved release. More complete inputs produce a more complete SBOM and more accurate dependency relationships.
2. Reconcile source, build, binary, and supplier evidence
We combine available source/build analysis with binary software composition analysis of the released artifacts in scope. Binary analysis can reveal statically linked libraries, vendored code, and other components absent from a manifest. Supplier evidence can help identify proprietary components and resolve uncertain versions.
Tool output is independently verified by Blue Goat Cyber before it is included in a deliverable. A library detected in a binary but absent from the manifest is one example of why one scan is not treated as definitive.
The inventory records the supplier, component name, version, unique identifiers, dependency relationships, author of the SBOM data, and timestamp. Tool names, versions, configuration, and discovery methods are retained so another reviewer can understand how the inventory was produced. Tools have limitations: neither a source scan nor binary analysis alone proves complete coverage.
For identifier matching, see CPE and PURL in medical-device SBOMs. SPDX is our default delivery format under this methodology; format choice does not remove the need for verification, and the FDA does not mandate SPDX.
3. Verify support status and end-of-support dates
Support information answers a different question from component identity: who supports the component, at what level, and until when? Examples of support levels include actively maintained, no longer maintained, and abandoned. A version can be correctly identified while its support information remains incomplete.
We review each component's support level and end-of-support field against published supplier information. Where the supplier has not published a date, we request it. Until a response is obtained, the date remains explicitly unknown. We do not infer a date from an unrelated product, substitute the device's planned retirement date, or invent one to fill the field.
| Support record | Treatment |
|---|---|
| Supplier publishes an applicable end-of-support date | Record the date for that component/version |
| Supplier has not published a date | Request clarification and record unknown pending response |
| Unsupported or abandoned component | Record the status for manufacturer maintenance and risk review |
A recorded unknown is not a verified support date or evidence that the component is supported indefinitely. It remains visible for follow-up and review. This page does not declare that an unknown automatically satisfies the release gate.
The February 3, 2026 guidance recommends component support level and end-of-support information, which may accompany the SBOM in an addendum. Our review controls should not be confused with additional statutory fields prescribed by Section 524B.
4. Apply the enrichment verification gate
Before delivery, the enrichment gate reviews every component's support and end-of-support fields to confirm they are complete, and the gate result is documented. The gate checks the documented information, including explicit unresolved unknowns; it does not turn an absent supplier answer into a known date.
If the SBOM fails the enrichment gate, we withhold it, correct the identified issues, and re-verify it. The required review must be completed before release.
This gate is a Blue Goat Cyber methodology control. It is not an FDA-mandated generation method, a conformity assessment, or a guarantee that the FDA will accept the submission.
5. Complete independent peer review
A second qualified team member performs peer review before delivery. No deliverable goes out on the preparer's review alone.
Issues identified in review are addressed before the required gate and peer review are considered complete.
Findings and ratings change when the evidence changes, not to fit a schedule or template. Independent review adds scrutiny; it does not establish that every possible component or vulnerability has been found. The manufacturer's release decision remains separate from our SBOM delivery decision.
6. What the manufacturer receives and still owns
The agreed delivery includes the verified inventory, support enrichment or accompanying addendum, and documented scope and limitations. Known-vulnerability assessment uses that inventory as an input; device-specific applicability and risk reasoning are separate from merely finding a CVE match. See SBOM vulnerability management.
The manufacturer supplies the agreed release artifacts and owns configuration management, remediation, risk acceptance, lifecycle approvals, and postmarket decisions. Delivery of an SBOM does not authorize device release or establish IEC 62304 conformity.
Source code does not leave Blue Goat Cyber's environment during analysis and is not sent to any third party. Processing and storage location is agreed before transfer; some vulnerability lookups can send component names, versions, and identifiers to vendor services. Restrictions should be settled during scoping, not assumed.
Frequently asked questions
Related guidance
- SBOM for medical devices: requirements, formats, and SAST
- SAST review: confirmed findings, CWE, remediation, and retesting
- CWE vs CVE: how each supports findings and FDA evidence
- Supplier SBOM responsibilities
- IEC 62304 cybersecurity deliverable map
- Medical Device SBOM Services for FDA Premarket Submissions
Discuss SBOM verification for your release.
Sources and boundaries
- Blue Goat Cyber, BGC-GUIDE-SW-002, SBOM/SAST Methodology, Rev B, effective October 22, 2026. This page summarizes the verification workflow; the proprietary source document is not a public download.
- The FDA's February 3, 2026 final premarket cybersecurity guidance, Section V.A.4(b), for recommended SBOM presentation and support information.
- Section 524B of the FD&C Act, for the statutory SBOM requirement on covered cyber-device pathways, distinct from these methodology controls.
Sources & references
Primary sources cited in this article. Links open in a new tab.
