Pharma and Life Sciences Supply Chain Security: Rules, Incidents, a Plan

A validated system is only validated for the software that was in it on the day you tested it. In pharma and life sciences, 21 CFR Part 11 asks for validated systems, secure audit trails and change control over system documentation, and 21 CFR 211.68 asks for controls over computers used in drug manufacture. None of that holds up if nobody can say which open source libraries, container images and vendor components are inside the LIMS, the chromatography data system, the batch record or the clinical data platform this week. The practical answer is a component inventory per system, a risk-based way to judge each vulnerability against GxP impact, and a change path that patches fast without breaking the validated state.

This guide covers the software a drug, biologic or life sciences company runs, the rules that apply in 2026, public incidents from the last three years, the people who own each part of the problem, and a 30, 60 and 90-day plan that works with any tools. Safeguard appears only near the end. Nothing here is legal or regulatory advice; your quality unit and counsel decide how a rule applies to you.

Key takeaways

• Part 11 is about records, but it reaches the software. Section 11.10 requires validation, secure computer-generated audit trails, access limits and revision and change control over systems documentation. Each of those assumes you know the exact software in the system.
• FDA finalised its Computer Software Assurance (CSA) guidance on 24 September 2025. It was written for software used in medical device production and quality systems, but its risk-based thinking is what many pharma validation teams now borrow.
• Data integrity is still the inspection lens. FDA's December 2018 data integrity Q&A and its October 2024 Q&A on electronic systems in clinical investigations are the current final guidance for drugs and clinical work.
• The EU is rewriting Annex 11 and adding Annex 22 on AI. The consultation ran from 7 July to 7 October 2025. Treat it as context for US teams with EU sites or partners, and watch for the final text.
• The incidents that touched this sector came through suppliers and shared code. A drug distributor's data exfiltration in February 2024, the XZ Utils backdoor, a compromised GitHub Action in March 2025 and a self-replicating npm worm in September 2025 all reached companies through components they did not write.
• Ownership is split. The CISO, the head of computer system validation, QA, lab and R&D IT, plant OT, clinical operations and supplier quality each hold part of the evidence. The plan below gives each a job.
• Safeguard capabilities covered here are all generally available (GA): SBOM generation and analysis, software composition analysis and vulnerability management, reachability analysis, policies and gates, license compliance, CSAF and VEX upload, Compliance and GRC frameworks including FDA 21 CFR Part 11 and GxP, Portal audit trails and sharing, Third-Party Risk Manager (TPRM), Trust Center, autonomous remediation (ships off), the CLI and local runner, Zero AI mode and air-gapped deployment.

The situation

Picture the week a critical vulnerability lands in a widely used library. By lunch the executive team asks the CISO whether the company is exposed. QA asks the head of IT quality whether patching the LIMS means revalidation, and whether batches can still be released meanwhile. The lab informatics lead finds the chromatography data system runs on a vendor appliance with an unknown Java runtime. Clinical operations asks whether the EDC vendor is affected before an interim analysis. Supplier quality finds the vendor's last component list is a PDF from 2023.

That is the bad week. In the good week, an inventory says which validated systems contain the component and in which version, a written risk method says which of them touch GxP records, and change control already has a pre-approved security patch path with a documented impact assessment and targeted testing. Vendors were asked for SBOMs at qualification and renewal, so the question to them is specific.

The usual triggers:

• An FDA inspection or a pre-approval inspection where investigators ask how computerised systems are controlled and how audit trails are reviewed.
• A sponsor or partner audit, often from a larger company auditing a contract manufacturer, a contract research organisation or a lab.
• A board or audit committee question after a sector incident, especially for US public companies that must decide whether a cybersecurity incident is material.
• A vendor renewal or a new SaaS platform for quality, clinical or lab work, where supplier qualification is due.
• A validation backlog, where every security patch seems to need a full revalidation, so patches wait.

The last is the quiet risk: when patching is expensive it is deferred, and deferred patches in GxP systems are what an attacker hopes to find.

What software a pharma or life sciences company runs

The estate is wider than most security teams expect. Group it by the GxP area it supports, because that is how quality will judge risk.

Research and discovery (mostly non GxP, sometimes GLP)

• Electronic lab notebooks (ELN) and scientific data management systems (SDMS).
• Bioinformatics and cheminformatics pipelines written in Python and R, often pulling hundreds of open source packages, plus workflow engines and container images run on high performance computing or cloud clusters.
• Machine learning models for target identification, protein structure and molecule design, frequently downloaded from public model hubs.
• Instrument control software on lab PCs, often on old operating systems the instrument vendor still certifies.

Quality control and manufacturing (GMP)

• Laboratory information management systems (LIMS) and chromatography data systems (CDS).
• Manufacturing execution systems (MES) and electronic batch records (eBR).
• Distributed control systems, SCADA and PLC software in plants, which overlap with the OT concerns covered in the manufacturing OT guide.
• Quality management systems for deviations, CAPA, change control and document control.
• ERP modules that hold GMP-relevant data such as material status and release.
• Serialisation and track and trace systems for the Drug Supply Chain Security Act (DSCSA), from line-level printers and vision systems to enterprise repositories that exchange data with trading partners.

Clinical development (GCP)

• Electronic data capture (EDC), eCOA and ePRO apps on patient phones and provisioned devices.
• Interactive response technology (IRT, also called RTSM) for randomisation and drug supply.
• Clinical trial management systems, electronic trial master files and safety and pharmacovigilance databases.
• Statistical computing environments where analysis programs, often in R, produce submission datasets.

Regulatory and commercial

• Regulatory information management and eCTD publishing tools.
• Medical information, CRM and patient support apps.
• Software as a medical device or companion apps for combination products, which pull in FDA's device rules. Those are covered in the medical devices guide and not repeated here.

Three facts make this estate hard to secure: much of it is bought and the vendor holds the source; validated systems change slowly by design, so old components stay for years; and the fastest-growing in-house code, in data science, has the most open source dependencies and the least change control.

The regulations and frameworks that apply

This section lists the rules a US pharma or life sciences company meets, with dates checked on the primary source. It is a map, not legal advice.

21 CFR Part 11: electronic records and signatures

Part 11 applies when records required by other FDA rules (the "predicate rules" such as the drug GMPs in Part 211, GLP in Part 58 and the clinical investigation rules) are kept or submitted electronically. Section 11.10 lists the controls for closed systems. The ones that touch software supply chain directly:

FDA's September 2003 guidance on Part 11 scope and application is still listed as final. It says FDA will interpret the scope of Part 11 narrowly and will exercise enforcement discretion on the validation, audit trail, record retention and record copying requirements as the guidance explains, while records must still meet the predicate rules. In practice, companies decide those controls through a documented risk assessment, and the same logic can decide how fast a security patch must go in.

21 CFR 211.68: computers in drug manufacturing

Section 211.68 allows computers and related systems in manufacturing, processing, packing and holding of drug products, on conditions. Equipment must be routinely calibrated, inspected or checked under a written program. Under 211.68(b), appropriate controls must ensure that changes to master production and control records are made only by authorised personnel, input and output must be checked for accuracy, and a backup of data entered into the system must be kept. For a security team, the plain reading is that unauthorised change to a manufacturing system is a GMP problem, not only a security problem.

FDA's data integrity guidance

FDA's "Data Integrity and Compliance With Drug CGMP: Questions and Answers" (December 2018, final) is the reference quality teams use for ALCOA: data should be attributable, legible, contemporaneous, original and accurate. Its questions cover how access to CGMP computer systems should be restricted, why shared logins are a concern, and who should review audit trails and how often. A compromised component that lets someone alter data or audit trails without trace is a data integrity failure in the sense this guidance describes.

Clinical investigations: the October 2024 Q&A

"Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers" (final, October 2024) covers sponsors, investigators, IRBs and CROs. It is written for sponsors, clinical investigators, IRBs, contract research organisations and others, and sets out when FDA considers electronic systems, records and signatures trustworthy and reliable. Because many trial systems are run by vendors, supplier oversight is part of meeting it.

Computer Software Assurance, final since September 2025

FDA announced the final guidance "Computer Software Assurance for Production and Quality System Software" in the Federal Register on 24 September 2025, three years after the September 2022 draft. The notice says it gives recommendations for computers and automated data processing systems used as part of medical device production or the quality system. Its method is to identify the intended use of each software feature, decide whether a failure could cause a quality problem that compromises safety, and choose assurance activities in proportion to that risk.

CSA is a device guidance, not a drug GMP rule, but many pharma quality teams use its risk thinking alongside GAMP 5. For security, the useful idea is that a documented, targeted test can be enough for a low-risk change, such as a library upgrade that does not change a feature's intended use, if your procedures say so.

GAMP 5 Second Edition

ISPE's "GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems (Second Edition)" was published in July 2022. It is an industry guide, not a regulation, but it is what most validation teams follow. ISPE says the second edition addresses evolving approaches to software development, expanded use of software tools and automation, and the critical thinking of experienced subject matter experts, and it touches on AI and machine learning, cloud computing and open source software. It is written for regulated companies, suppliers and regulators, which is where SBOMs and vulnerability disclosures fit.

DSCSA

FDA describes the Drug Supply Chain Security Act as the steps to an interoperable, electronic way to identify and trace certain prescription drugs at the package level as they move through the US supply chain. The software that carries those serialised data (line systems, enterprise repositories and partner exchanges) is part of the supply chain in two senses: physical and software. FDA keeps current status and exemptions on its DSCSA page; check it for your trading partner type before planning.

SEC disclosure for public companies

For US public pharma and life sciences companies, the SEC's cybersecurity disclosure rules, adopted on 26 July 2023, require a Form 8-K under Item 1.05 within four business days of determining that a cybersecurity incident is material, and annual disclosure of cybersecurity risk management, strategy and governance. A supplier incident can trigger the materiality question, which is why the CISO needs to know quickly which vendors and components a business process depends on.

CISA's 2026 SBOM minimum elements and NIST SSDF

CISA published "2026 Minimum Elements for a Software Bill of Materials (SBOM)" on 29 July 2026. CISA says it updates and replaces the NTIA minimum elements published in 2021. It is not a pharma rule, but it is the current US reference for what an SBOM should contain, and it is the right template for what you ask vendors for.

NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, describes practices for producers of software. It is the vocabulary to use when you assess how a GxP software vendor builds and maintains its product, and when you write expectations for your own in-house development.

The EU picture, for context

For companies with EU sites, partners or marketing authorisations, the European Commission ran a stakeholder consultation from 7 July to 7 October 2025 on a revised EU GMP Chapter 4 (Documentation), a revised Annex 11 (Computerised Systems) and a new Annex 22 on artificial intelligence. The consultation page now shows it as closed. Until the final text is adopted, the current Annex 11 still applies in the EU. US teams should watch it because global quality systems tend to converge on the stricter text.

Real public incidents from the last three years

These incidents come from official or primary reporting. The lessons stated are limited to what the sources say.

Cencora data exfiltration, February 2024

Cencora, a large US drug distributor, filed a Form 8-K with the SEC dated 27 February 2024. It said that on 21 February 2024 it learned that data from its information systems had been exfiltrated, some of which might contain personal information. The filing said the incident had not had a material impact on operations as of that date, that systems remained operational, and that the company had not yet determined whether the incident was reasonably likely to have a material impact on its financial condition.

Change Healthcare, February 2024

UnitedHealth Group filed a Form 8-K under Item 1.05 on 22 February 2024. It said that on 21 February 2024 it identified a suspected nation-state associated threat actor with access to some Change Healthcare IT systems, that it isolated the affected systems from connecting systems, and that certain networks and transactional services might not be accessible during the disruption. For pharma and life sciences, the point the filing supports is narrow: one shared service provider in health care can be cut off from the organisations that connect to it, even when their own systems are untouched. That is a supplier concentration risk rather than a code flaw.

XZ Utils backdoor, March 2024

On 29 March 2024, CISA reported malicious code embedded in XZ Utils versions 5.6.0 and 5.6.1, tracked as CVE-2024-3094, and advised downgrading to an uncompromised version. XZ Utils is compression software present in many Linux distributions. Much lab, analytics and manufacturing software runs on Linux images and appliances, so the first question was simply which systems carried those versions.

Compromised GitHub Action, March 2025

CISA reported that the popular GitHub Action tj-actions/changed-files, tracked as CVE-2025-30066, was compromised, allowing disclosure of secrets such as access keys, GitHub personal access tokens, npm tokens and private RSA keys from build logs. CISA noted the compromise may have been enabled by an earlier compromise of reviewdog/action-setup, tracked as CVE-2025-30154, and that the issue was patched in v46.0.1. Any company that builds in-house apps, data pipelines or validated tools with GitHub Actions was in scope to check.

Self-replicating npm worm, September 2025

CISA reported on 23 September 2025 a widespread compromise of the npm registry by a self-replicating worm publicly known as "Shai-Hulud" that compromised over 500 packages. After initial access, the actor scanned for credentials, then used compromised developer accounts to publish infected versions of other packages. Web front ends for patient support apps, clinical portals and internal quality tools commonly use npm packages, so the inventory question reached far beyond engineering teams.

What these incidents share is not a technique. Each reached organisations through something they did not build: a distributor, a shared processor, a compression library, a CI action, a package registry.

The personas who own the problem

No single function owns this in life sciences. The table summarises who needs what and when; the notes below go deeper.

CISO. The problem is speed and defensibility. After a sector incident, the board and, for public companies, the disclosure committee want to know fast whether a material business process depends on the affected supplier or component. That needs one inventory across validated systems, which quality owns, and everything else, plus a risk register entry for supplier concentration.

Head of IT quality or CSV lead. This person decides whether a patch triggers revalidation. Without a written, risk-based method for security patches, every patch becomes a full change and the backlog grows. With one, a library upgrade with no functional change can take an expedited path with targeted testing and a recorded rationale.

Head of QA. The quality unit owns release and data integrity. It will ask security to show that a fix did not change validated functionality, and will want that evidence filed with the change record.

Lab and R&D IT, including data science. These teams pull in more open source than anyone, often outside formal change control. They need an inventory per pipeline, container image and model, and fix pull requests that do not break results. If a pipeline later supports a GLP study or a submission, that inventory becomes reproducibility evidence.

Plant OT and MES engineering. Fixes go in during planned windows. These engineers need vendor SBOMs, a ranked list for the next shutdown, and a record of what cannot be patched and which compensating controls apply.

Clinical operations. Sponsors stay responsible for trial data integrity when vendors run the systems, so EDC, IRT and eCOA vendors must answer component and patching questions at selection and before study start.

Supplier quality, procurement and GRC. Supplier quality and procurement need standard software terms in qualification and renewals, and a way to chase vendors who have not delivered. GRC turns it all into controls, Part 11 and 211.68 clauses plus company policy, each with named evidence that is current at inspection time.

Step by step: a 30, 60 and 90-day plan

This plan works with spreadsheets, open source tools or a platform. A small biotech can run it for a handful of systems; a global manufacturer will phase it by site.

Days 1 to 30: know what you run

1. Start from the validated system inventory. Then add the non-GxP systems that support it: identity, file transfer, analytics, build pipelines.
2. Classify each system by GxP impact. Use your existing categories, or a simple scale: direct impact on product quality or patient safety data, indirect impact, no GxP impact.
3. Get or generate a component inventory for each system. For in-house code and containers, generate SBOMs from the build. For vendor systems, request the vendor's SBOM in SPDX or CycloneDX. For appliances where neither works yet, record what you know (operating system, runtime, major libraries) and mark it as incomplete.
4. Match against known vulnerabilities. Check each inventory against public vulnerability data, and flag anything on CISA's Known Exploited Vulnerabilities (KEV) catalog.
5. Write down the patch path that exists today. For each GxP system, record who approves a security patch, what testing is required, and how long it usually takes. This is your baseline.

A simple inventory template to use the same day:

Days 31 to 60: make it a process

1. Write a security patch procedure for validated systems. With the CSV lead and QA, define categories: emergency (KEV or actively exploited, GxP direct impact), expedited (critical or high, no functional change) and routine. For each, state the impact assessment, the testing required and the approval. Base the testing on risk to intended use, as FDA's CSA guidance and GAMP 5 describe.
2. Add a VEX-style record of exploitability. For each critical finding you decide not to patch now, record why: the component is not present in the shipped build, the vulnerable function is not called, or a compensating control blocks it. This record is what an inspector or sponsor auditor can follow.
3. Set gates in your build pipelines. For in-house software, stop builds that introduce new critical vulnerabilities, KEV entries or disallowed licenses, with a documented exception process for business justification and expiry.
4. Add software terms to supplier qualification. Add to your supplier questionnaire and quality agreements: SBOM per release in a machine-readable format, vulnerability disclosure contact and timelines, support and end-of-life dates, notification of incidents that affect your data, and the right to ask for evidence of secure development practices aligned with NIST SSDF.
5. Assign owners for the research estate. Make one person in each data science or bioinformatics group responsible for the inventory of pipelines, containers and models.

A decision table for the patch procedure:

Days 61 to 90: prove it works

1. Run a tabletop on a supplier incident. Use an illustrative scenario: a widely used Java library has a critical vulnerability on the KEV catalog, and two vendors in your GxP estate are silent. Time how long it takes to list affected systems, classify impact and decide on actions. Include the disclosure committee if you are a public company.
2. Patch one validated system through the new path. Pick a real finding and take it through the expedited procedure end to end, with QA watching. Fix what slows it down.
3. Measure and report. Track, per system class, the time from disclosure to decision and from decision to deployed fix, the share of vendors that provided an SBOM, and open KEV entries. Report to QA management review and to the security committee.
4. Map controls to evidence. For each Part 11, 211.68 and data integrity expectation that your security work supports, name the evidence: inventory, patch records, audit trail reviews, supplier files. Store it where the inspection team can find it.
5. Plan the next quarter. Extend inventories to remaining appliances and add AI models used in GxP decisions as their own class.

How Safeguard does this

This section shows how the plan runs in Safeguard, using only what Safeguard's offering and documentation describe. Every capability named here is generally available (GA).

1. Connect the sources for each system (GA). On the Integrations page you connect repositories and set a project name, version and branch or tag for each, so a LIMS integration layer, a bioinformatics pipeline and a patient app can each map to a project. Safeguard covers code, containers and AI models, and you can bring in SBOMs and CSAF or VEX files you already have.

2. Generate SBOMs per release (GA). SBOM generation and analysis produces SPDX and CycloneDX output. The generation options include the version (auto-detected from Git tags), the branch or tag, and whether to include development dependencies. The docs say Safeguard rescans every project daily for newly disclosed vulnerabilities. For a vendor system, upload the vendor's SBOM so it is analysed alongside your own code.

3. Scan where the code lives, if it cannot leave (GA). GxP source and research code can be sensitive. The Safeguard CLI and local runner scan on your own machine. The docs show:

# Install the CLI
curl -fsSL https://cli.safeguard.sh/install | bash

# Scan a local directory
safeguard scan --dir .

# Scan an SBOM you already have, for example one a vendor sent
safeguard scan --sbom sbom.json

The docs say safeguard scan does not fail on findings; gating is done by policy gates. We did not run these commands for this post.

4. Match vulnerabilities and rank them (GA). Software composition analysis inventories direct and transitive dependencies, and vulnerability management enriches findings with EPSS and CISA KEV. Reachability analysis and prioritisation ranks the vulnerable code paths your application actually calls. That gives the CSV lead a defensible input to the patch category, though the GxP impact decision stays with your team.

5. Record exploitability with VEX (GA). CSAF and VEX upload lets you bring in vendor advisories and VEX documents, so a vendor's statement that a vulnerability does not affect its product sits next to your own findings.

6. Set gates that stop risky components (GA). Policies evaluate SBOMs and produce findings; gates enforce them. Policy conditions in the docs include vulnerability severity, CVSS score, EPSS score, license and component age and maintenance. Each policy's action is Block, Warn or Notify. When a team needs an exception, the docs describe a request with a business justification and an expiry date that goes to approvers, with an audit trail. In CI, the docs show this GitHub Actions step, which we did not run:

- name: Safeguard scan
  env:
    SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
    SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
  run: |
    set -eu
    curl -fsSL https://cli.safeguard.sh/install | bash
    "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

The docs list --fail-on-gate all as the option to fail the job on a policy gate instead of a severity threshold.

7. Check licenses (GA). License compliance parses SPDX expressions and supports policy on license types, which matters when a research tool moves into a commercial or GxP use.

8. Map scan results to Part 11 and GxP (GA). The Compliance and GRC suite includes an FDA 21 CFR Part 11 framework and a GxP (GMP, GLP, GCP) framework, both on by default in a workspace unless you switch them off in Compliance › Manage. Each scan of a product checks scan requirements against the SBOM. For Part 11 the docs list checks that every component is named and versioned (11.10(a)), that the record is in a machine-readable standard format (11.10(b)), that components carry integrity hashes (11.10(c)), that the SBOM carries document identity and timestamps (11.10(e)) and that versions are not floating (11.10(k)). The GxP framework maps similar checks to EU Annex 11 clauses, ALCOA attributability and 21 CFR 211.68. Both include controls and policy templates, such as a computer system validation policy and an audit trail review procedure. These checks cover the software record, not your whole validation.

9. Keep an audit trail of SBOM activity (GA). Portal, meaning here the SBOM publishing and sharing product rather than the free entry tier, logs SBOM creation, changes, views, downloads, sharing events and permission changes. The docs show audit logs under Settings › Audit Logs, with filters and export to CSV, JSON or a formatted PDF report.

10. Request SBOMs from vendors (GA). Third-Party Risk Manager handles SBOM requests to vendors, one at a time or in bulk, with a template that sets the format, required fields and a deadline. Requests move through statuses from Sent to Validated or Rejected, with reminders around the deadline. Received SBOMs are checked for format and completeness and scanned, so supplier quality can see which LIMS, EDC or MES vendors have delivered.

11. Share SBOMs with sponsors and partners (GA). If you are a CDMO, CRO or software vendor to pharma, Portal sharing lets you share SBOMs with named recipients at set permission levels, create expiring and password-protected links, require NDA acceptance and revoke access. Trust Center publishes a posture page, and nothing goes live until you publish it.

12. Open fix pull requests, under your control (GA). Autonomous remediation lets Griffin open tested, policy-gated pull requests that move a dependency to a fixed version, on one repository or in bulk. It ships switched off, with every category set to Manual. For validated software, keep it on Manual and treat each pull request as an input to your change control, not a release.

13. Keep code and models in your environment (GA). Zero AI mode runs the platform with no LLM in the loop, or you bring your own model, and Safeguard deploys as SaaS, private VPC, on-prem or fully air-gapped.

How the plan maps:

What Safeguard does not do

• It does not validate your GxP systems. It produces evidence about the software inside them. Validation plans, test execution, QA approval and the decision that a system is fit for intended use remain yours.
• It does not review the audit trail of your LIMS, CDS or MES. Portal audit logs cover activity in Safeguard. The Part 11 audit trail of each GxP system, and its periodic review, are separate duties.
• It does not decide GxP impact. Reachability, EPSS and KEV help order the work. Whether a finding threatens product quality, patient safety or data integrity is a quality judgment recorded in your change control.
• It does not see inside closed appliances. Safeguard's documented inputs are repositories, container images, AI models, manifests, SBOMs and CSAF or VEX files. For a vendor appliance with no SBOM, you need the vendor to provide one.
• It does not deploy patches to validated systems. Fix pull requests stop at your repository. Testing, approval and release stay in your process.
• It does not write your SEC disclosure or materiality decision. It can help answer which systems contain a component; the disclosure committee and counsel decide what is material.
• It does not make you compliant with Part 11 or GMP. Its framework mappings check the software record and give you templates; inspectors judge your whole quality system.

Common mistakes

• Treating "validated" as "frozen". A system left unpatched to protect its validated state is a data integrity risk. Write a risk-based patch path instead.
• Revalidating everything for every patch. Full revalidation for a library upgrade with no functional change is usually not what the risk calls for, and the delay it causes is a risk in itself. Decide the testing by impact on intended use.
• Leaving research pipelines out of the inventory. The code with the most open source dependencies is often in data science. When that code supports a study or a submission, its history matters.
• Accepting a PDF component list as an SBOM. Ask for SPDX or CycloneDX, per release, and check it against CISA's 2026 minimum elements.
• Writing "not applicable" without evidence. A finding closed without a recorded reason will be questioned. Write down whether the component is absent, the function is not called, or a control blocks it.

FAQ

Does 21 CFR Part 11 require an SBOM?

No. Part 11 does not mention SBOMs. It requires validation, protection of records, access limits, secure audit trails and change control over systems documentation. A component inventory is a practical way to show what was validated and what changed, which is why many teams use one as Part 11 evidence.

Do I have to revalidate a GxP system after a security patch?

Not necessarily in full. FDA's CSA guidance and GAMP 5 both describe effort in proportion to risk. If your procedures define a risk assessment for security patches and the patch does not change intended use, targeted testing with a documented rationale may be enough. Your QA unit makes that call.

What is the latest FDA guidance on computer software assurance?

"Computer Software Assurance for Production and Quality System Software", finalised in September 2025. It covers production and quality system software, takes a risk-based approach to assurance, and supersedes Section 6 of the 2002 General Principles of Software Validation.

Is DSCSA a cybersecurity rule?

Not directly. It sets requirements to identify and trace prescription drugs at the package level. But the serialisation and data exchange systems that meet it are software, with their own components and suppliers, so they belong in your inventory.

How does the EU Annex 11 revision affect US companies?

Directly only if you have EU sites, EU marketed products or EU partners. The draft revision of Annex 11 and the new Annex 22 on AI were open for consultation from 7 July to 7 October 2025. Watch for the final text, since global quality systems often adopt the stricter version.

What should we ask LIMS, EDC and MES vendors for?

An SBOM per release in SPDX or CycloneDX, a vulnerability disclosure process with contact and timelines, support and end-of-life dates, incident notification terms, and a description of secure development practice aligned with NIST SSDF. Put the terms in the quality agreement, not only the questionnaire.

Does the SEC rule apply to a supplier incident?

The rule applies to registrants. If a supplier incident affects a public company's systems or data, the company still has to assess materiality, and if material, file Form 8-K Item 1.05 within four business days of that determination.

Are AI models part of the software supply chain in pharma?

Yes. Models downloaded from public hubs and used in discovery or, increasingly, in GxP decisions are components with their own provenance and risks. The EU's draft Annex 22 addresses AI in GMP. Inventory models as their own class.

The plan above shortens the time from a disclosed vulnerability to a fix your change control can accept. For the open source components inside your in-house pipelines, apps and containers, the options below cover both the case where a fix exists and the case where it does not yet.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session. After install, safeguard opens the interactive terminal, and the user asks it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. For a life sciences team, the same pattern fits a clinical portal or an internal quality tool: the change arrives as a reviewable edit that then goes through your change control.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code, then scans from the terminal. This is the route for research and GxP source that should not leave your network, since the scan happens where the code is.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. A CISO or CSV lead could use the same connection during a sector incident to ask which projects carry an affected component, with access limited to the tools you allow.

Click through it at your own pace, or open it full screen.

Quick check

Related reading

• Related in this series: medical devices and hospitals and health systems.
• Pharmaceutical software validation and the supply chain
• Pharma clinical trials software supply chain
• Healthtech and FDA software supply chain guidance

Sources

• 21 CFR 11.10, Controls for closed systems, Legal Information Institute
• 21 CFR 211.68, Automatic, mechanical, and electronic equipment, Legal Information Institute
• FDA, Part 11, Electronic Records; Electronic Signatures: Scope and Application (September 2003)
• FDA, Data Integrity and Compliance With Drug CGMP: Questions and Answers (December 2018)
• FDA, Electronic Systems, Electronic Records, and Electronic Signatures in Clinical Investigations: Questions and Answers (October 2024)
• FDA, Drug Supply Chain Security Act (DSCSA)
• European Commission, Stakeholders' Consultation on EudraLex Volume 4: Chapter 4, Annex 11 and New Annex 22
• ISPE, GAMP 5 Guide, Second Edition
• NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
• CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• Cencora, Inc., Form 8-K dated 27 February 2024, SEC EDGAR
• SEC, press release 2023-139: SEC Adopts Rules on Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure by Public Companies (26 July 2023)
• Federal Register, Computer Software Assurance for Production and Quality System Software; final guidance availability (24 September 2025)
• UnitedHealth Group, Form 8-K Item 1.05 dated 21 February 2024, SEC EDGAR
• CISA, Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094
• CISA, Supply Chain Compromise of Third-Party tj-actions/changed-files (CVE-2025-30066) and reviewdog/action-setup@v1 (CVE-2025-30154)
• CISA, Widespread Supply Chain Compromise Impacting npm Ecosystem
• Safeguard Docs, FDA 21 CFR Part 11 framework
• Safeguard Docs, GxP (GMP/GLP/GCP) framework
• Safeguard Docs, Portal Audit Trails
• Safeguard Docs, Compliance
• Safeguard Docs, Generate SBOM
• Safeguard Docs, Policies and Gates
• Safeguard Docs, CLI usage
• Safeguard Docs, GitHub Actions
• Safeguard Docs, TPRM SBOM Requests
• Safeguard Docs, Portal Sharing
• Safeguard Docs, Trust Center

To try the flow on your own code, download Safeguard at https://safeguard.sh/download and read the documentation at https://docs.safeguard.sh/docs .

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.