Software Supply-Chain Security & SBOM
Almost none of the software running a regulated business was written by it. A LIMS is configured, not built; an instrument’s control software is the vendor’s; a device’s firmware pulls in open-source libraries several dependency levels deep. Supply-chain security is the discipline of knowing what those components are, learning quickly when one of them turns out to be vulnerable, and being able to answer — for a specific product, system or device — whether it is affected. The software bill of materials is the inventory that makes the question answerable; it is not, by itself, the answer.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 23 LINKSA regulated system is mostly components someone else wrote. Without a maintained bill of materials, the honest answer to "are you affected by this vulnerability" is not no — it is that you cannot tell.
06 · QUALITY MATURITY — SOFTWARE SUPPLY-CHAIN SECURITY & SBOM, REACTIVE TO ADAPTIVE
Systems are bought and installed. What they are built from is the supplier’s business and has never been asked.
A bill of materials is requested at purchase for some systems, filed, and never compared against anything afterwards.
Components are inventoried per system and kept current through upgrades, so a disclosed vulnerability can be answered against the estate in hours rather than weeks.
Provenance and integrity are verified rather than assumed — signed artefacts, known sources — and a supplier who cannot supply a bill of materials is a qualification finding.
Component risk shapes selection: the estate is chosen partly for what it is built from and how quickly its makers fix things, so exposure falls by design.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 4
Derived from the 4 standards SPEQ maps to this subject, across 4 regulatory bodies: EMA, IEC, FDA, ISO.
RECORDS & OBJECTIVE EVIDENCE
- A component inventory per GxP system, with its currency date
- Supplier obligations covering component disclosure and vulnerability notification
- Verification of artefact integrity and provenance at installation and upgrade
- The assessment route from a disclosed vulnerability to the affected systems
- Records of components reaching end of support, and what was done about them
COMMON INSPECTION FINDINGS
- No component inventory, so vulnerability exposure cannot be determined at all
- A bill of materials captured at purchase and never updated through upgrades
- Software installed from unverified sources or unsigned artefacts
- Components past end of support running in production with no compensating controls
- Supplier agreements silent on vulnerability notification
The component you did not write is still yours to answer for
Regulatory accountability does not follow the build. A marketing authorisation holder answers for the systems its records live in; a device manufacturer answers for the software in its device, including the parts it licensed or downloaded. When a widely used component is found vulnerable, the question arriving from a customer, an inspector or a notified body is specific and urgent: is this product affected, and what are you doing about it. An organisation that cannot enumerate its components answers that question by manual archaeology, one system at a time, while the exposure window stays open.
The 2017 NotPetya attack made the point at industrial scale: destructive malware distributed through a compromised update to legitimate accounting software reached pharmaceutical manufacturing and halted production for weeks. The intrusion path was not a vulnerability in the victims’ own code. It was trust in a supplier’s update channel, which is a supply-chain control, not an endpoint one.
What an SBOM is, and what it is not
A software bill of materials is a machine-readable inventory of the components that make up a piece of software, together with their relationships. The NTIA’s 2021 minimum elements define seven data fields — supplier name, component name, version, other unique identifiers, dependency relationship, author of the SBOM data, and a timestamp — plus practices for how SBOMs are generated and shared. The established formats are SPDX, published as ISO/IEC 5962:2021, CycloneDX, and SWID tags.
For medical devices this moved from good practice to statute. Section 524B of the FD&C Act, added by the December 2022 omnibus legislation, requires sponsors of a "cyber device" to provide a software bill of materials covering commercial, open-source and off-the-shelf components, alongside a plan to monitor, identify and address postmarket vulnerabilities and processes providing reasonable assurance the device is secure. FDA’s premarket cybersecurity guidance, reissued 3 February 2026 to align with the Quality Management System Regulation, sets out what the submission should contain.
What an SBOM does not do is assess anything. It records that a component of a given version is present. Whether the vulnerability disclosed against that version is reachable in this configuration, exploitable by a threat with access to this system, and capable of causing harm is a separate analysis — and it is the analysis that produces a decision. An SBOM generated once for a submission and never regenerated is an artefact; one generated from the build pipeline on every release is a control.
Vulnerability intake, triage and disclosure
The operating half of supply-chain security is a process that runs continuously: monitor sources for newly disclosed vulnerabilities, match them against the component inventory, assess exploitability in the actual deployed configuration, decide on remediation or a compensating control, and communicate. ISO/IEC 29147 covers how an organisation receives and publishes vulnerability information; ISO/IEC 30111 covers how it handles what it receives. Both assume a named intake route that a researcher can find, which many regulated organisations still lack.
A CVSS base score is a triage input, not a verdict. It describes the vulnerability in the abstract, with no knowledge of whether the affected function is compiled in, reachable from any interface the deployment exposes, or already contained by segmentation. Treating the score as the decision produces both failures: emergency changes to systems that were never exposed, and slow responses to a moderate-scored flaw that happens to sit directly behind a listening port on a production network.
Suppliers, leverage, and the limits of a questionnaire
EU GMP Annex 11 requires the regulated user to assess suppliers of computerised systems and services, with the depth of that assessment driven by risk and the criticality of the system. GAMP 5 makes the same point constructively: where a supplier operates a robust development and testing regime, the regulated company can leverage that evidence rather than re-testing from scratch — but leverage is earned by assessment, not assumed from a brand.
The assessment gap that recurs is cloud and software-as-a-service. The supplier will not permit a site audit of a multi-tenant platform, offers a third-party attestation instead, and the regulated user accepts it without reading its scope — which frequently excludes the specific service in question, or covers the platform while leaving configuration entirely with the customer. The practical controls are unglamorous: read the scope of the attestation, contract for notification of security incidents and material subprocessor changes within a defined period, and settle data export and exit terms before there is a reason to use them.
Where a vulnerability lands in the quality system
A vulnerability affecting a GxP system is not only a security ticket. If it is exploited, or if remediation changes the system, it enters the same machinery as any other event: a deviation with an assessment of impact on product and data, root-cause analysis, corrective and preventive action, and change control for the fix. For a marketed device, a vulnerability with safety or effectiveness implications can reach complaint handling, corrections and removals, and vigilance reporting exactly as a non-cyber quality issue would.
SPEQ’s view is that the join between the security backlog and the quality system is where most programmes are thinnest. Security teams track vulnerabilities to closure in their own tooling; quality systems never see them unless someone remembers to raise a record. The fix is a defined trigger — agreed in advance, written into the procedure — that says which vulnerabilities are also quality events, so the decision is made by a rule rather than by whoever is on the call.
FREQUENTLY ASKED
What are the NTIA minimum elements of an SBOM?
Seven data fields: supplier name, component name, version of the component, other unique identifiers, dependency relationship, author of the SBOM data, and a timestamp. The 2021 report also covers automation support through machine-readable formats — SPDX, CycloneDX and SWID tags — and practices for how frequently SBOMs are generated and how they are distributed.
Does a pharmaceutical manufacturer need an SBOM for its GxP systems?
No regulation requires one. The SBOM obligation in section 524B of the FD&C Act is device-specific. But the question an SBOM answers — is this system affected by the vulnerability disclosed this morning — is one a pharmaceutical manufacturer has to answer too, and requesting an SBOM from suppliers of high-criticality systems is the cheapest way to be able to answer it in hours rather than weeks.
Is a CVSS score enough to decide whether to act?
No. A CVSS base score describes a vulnerability in the abstract. The decision depends on whether the affected code path is present and reachable in the deployed configuration, what an attacker would need in order to reach it, and what harm would follow. Exploitability analysis against the actual deployment is what converts a score into a decision, and it can move the answer in either direction.
Who is accountable when a cloud provider is breached?
The regulated organisation remains accountable to its regulator for its records and its product, regardless of who operated the infrastructure. Annex 11 places responsibility for supplier assessment and for the validated state of the system on the regulated user. Contracts allocate liability between the parties; they do not transfer regulatory accountability.
How does IEC 81001-5-1 relate to FDA’s premarket cybersecurity guidance?
They meet from opposite directions. IEC 81001-5-1 specifies the security activities in the health-software development lifecycle — what the manufacturer does. FDA’s guidance specifies what the premarket submission must demonstrate — what the regulator sees. A manufacturer following 81001-5-1 generates much of the evidence the submission asks for, which is why it is commonly used as the process backbone.