Patch Open Source in a GxP Validated System Without Full Revalidation

No. Neither 21 CFR Part 11 nor EU GMP Annex 11 says a library patch triggers a full revalidation. They require a validated system and controlled, traceable changes, and current FDA and ICH guidance says the assurance effort should match the risk. So you classify each open source patch by what it can break, run the testing that fits, and keep a change record an inspector can follow from finding to approval.

Below: what the primary texts say, how to tier a dependency patch, which vulnerabilities justify an out-of-cycle change, how to document "not affected" decisions, why floating versions break change control, and how to keep code and data inside the validated environment. The last part shows where Safeguard fits, with maturity labels, and what stays with your quality unit. This is not regulatory advice; your quality unit and procedures decide how it applies to a given system.

Key takeaways

• No rule says a library patch equals full revalidation. 21 CFR 11.10(a) requires validation, 11.10(k)(2) requires revision and change control procedures, and Annex 11 clause 10 requires changes to follow a defined procedure. The scope of retesting is a documented risk decision.
• FDA's Computer Software Assurance (CSA) guidance is final. The current version, issued 3 February 2026 by CDRH and CBER, superseded a final version of 24 September 2025. Its scope is device production and quality management system software under 21 CFR Part 820, not drug CGMP under Part 211.
• The revised EU Annex 11 is still a draft. Its consultation closed on 7 October 2025; EudraLex still lists the January 2011 text.
• Urgency and process risk are separate questions. Exploitation (CISA KEV, EPSS), reachability and exposure decide when you change. What the library supports decides how much assurance the change needs.
• "Not affected" needs a record. A VEX statement scoped to the validated version, inside a quality record with intended use, risk rationale, conclusion, who and when.
• Pin every version. Ranges, wildcards and "latest" mean a rebuild is not the software you validated.
• Safeguard's part, with labels: SBOM generation and analysis (GA), SCA and vulnerability management with EPSS and KEV (GA), reachability analysis (GA), CSAF and VEX upload (GA), policies and gates (GA), the compliance and GRC suite with GxP and 21 CFR Part 11 framework pages (GA), CLI and local runner (GA), on-prem and air-gapped deployment and Zero AI mode (GA), autonomous remediation (GA, ships switched off with every category set to Manual), desktop app, fork and patch (GA).
• Safeguard does not validate your system. Intended use, risk assessment and release approval stay with your quality unit.

What the regulations say when validated software changes

"The validation requirement" is really several texts with different legal weight. Reading them directly removes a lot of folklore.

21 CFR Part 11: validation and controlled change

Part 11 applies to electronic records created, modified, maintained, archived, retrieved or transmitted under any FDA records requirement (11.1(b)). For closed systems, 21 CFR 11.10 lists the controls. Three matter most for patching:

• 11.10(a): validation of systems to ensure accuracy, reliability, "consistent intended performance," and the ability to discern invalid or altered records.
• 11.10(e): secure, computer-generated, time-stamped audit trails of operator entries and actions that create, modify or delete records.
• 11.10(k)(2): revision and change control procedures that keep an audit trail of the time-sequenced development and modification of systems documentation.

Part 11 does not say how much testing a change needs. It says the system must be validated and changes must be controlled and traceable. A library upgrade that leaves the system validated for its intended use, recorded through your change procedure, meets the text. How you show it is still validated is where risk-based thinking comes in.

21 CFR 211.68: the drug CGMP rule for computers

21 CFR 211.68(a) allows computers in the manufacture, processing, packing and holding of drug products if they are routinely calibrated, inspected or checked under a written program, with written records. Section 211.68(b) requires controls so only authorised personnel change master production and control records, and input and output checks whose "degree and frequency" depend on the complexity and reliability of the system. That is a risk-proportionate idea written into the regulation itself.

FDA's CSA guidance: final, and scoped to devices

The guidance is now titled Computer Software Assurance for Production and Quality Management System Software. The FDA document says it was issued on 3 February 2026 and supersedes the final guidance "Computer Software Assurance for Production and Quality System Software" of 24 September 2025. It comes from CDRH and CBER under docket FDA-2022-D-0795, started as a September 2022 draft, and contains nonbinding recommendations.

Scope matters for pharma readers. It covers software used in medical device production or the quality management system under 21 CFR Part 820, and does not address 21 CFR Part 211. Many drug and biologics manufacturers apply its approach by analogy, but say that your approach is consistent with the principles in the CSA guidance, ICH Q9(R1) and Annex 11, rather than that CSA applies to your drug system.

What it says that helps with patching:

• Definition. Computer software assurance is a risk-based approach for establishing and maintaining confidence that software is fit for its intended use, with the burden of validation no more than necessary to address the risk, keeping the software in a "validated state" across its life cycle.
• Two risk categories. A feature, function or operation is "high process risk" when its failure may result in a quality problem that foreseeably compromises safety, for example maintaining process parameters, determining product acceptability with limited human review, or automating tracking of data essential to safety, with cybersecurity named as an example. Everything else is "not high process risk."
• Assurance scales with risk. For high process risk, scripted testing or a hybrid of scripted and unscripted testing; for the rest, unscripted methods such as scenario testing, error guessing and exploratory testing. FDA says these examples are not prescriptive.
• Other evidence counts. Process controls that would catch a failure, monitoring data after implementation, and the vendor's development, validation and cybersecurity practices, with the software bill of materials (SBOM) named among vendor documentation, can reduce assurance effort.
• The record. Intended use, the result of the risk-based analysis, and the assurance activities: what testing was done, issues found, a conclusion on acceptability for intended use, who did it and when, and review and approval where appropriate. FDA prefers digital records such as system logs and audit trails over screenshots.

EU GMP Annex 11: the 2011 text is current, the revision is a draft

For products reaching the EU, or companies applying PIC/S standards globally, the EudraLex Volume 4 page still lists "Annex 11 Computerised Systems (revision January 2011)." The relevant clauses:

• Clause 1: decisions on the extent of validation and data integrity controls should rest on a justified and documented risk assessment.
• Clause 3: formal agreements with third parties that supply or maintain a system; the need for a supplier audit based on risk.
• Clause 4.3: an up to date listing of relevant systems and their GMP functionality (inventory).
• Clause 10: any changes, including system configurations, only in a controlled manner under a defined procedure.
• Clause 11: periodic evaluation that the system remains in a valid state, covering where appropriate incidents, upgrade history, security and validation status.

The European Commission's consultation on a revised Annex 11, a revised Chapter 4 and a new Annex 22 on artificial intelligence, drafted by the EMA GMDP Inspectors Working Group with PIC/S, ran from 7 July to 7 October 2025. The Commission says the revision strengthens life cycle management, supplier oversight, data integrity, audit trails, electronic signatures and system security. As of this writing those texts are drafts: plan for them, cite the 2011 text.

ICH Q9(R1), PIC/S and GAMP 5

ICH Q9(R1), Quality Risk Management, was adopted on 18 January 2023. Its second principle: the level of effort, formality and documentation of quality risk management should be commensurate with the level of risk. That is the bridge between the quality system and a patch decision. A low-risk patch can use a short templated record; a patch under a function that releases product needs a more formal one.

PIC/S publishes PI 011-3 (computerised systems in GxP environments) and PI 041-1 (data management and integrity) for inspectors, which tells you what the reviewer of your change record is trained to look for. ISPE's GAMP 5 Second Edition (July 2022) is an industry guide, not a regulation; ISPE says it stresses critical thinking by subject matter experts, use of supplier documentation, iterative development, FDA's CSA approach, and adds an appendix on open source software.

FDA's "Data Integrity and Compliance With Drug CGMP: Questions and Answers" (final, December 2018) says FDA expects all data to be reliable and accurate and describes CGMP as allowing risk-based strategies to prevent and detect data integrity problems. A vulnerable library in a system holding GMP records is a data integrity risk, which is a useful framing when you argue for a timely patch.

Why validated systems fall behind on patches

A system goes live after a long validation effort. An update bumps a logging library or a JSON parser. Someone asks whether it needs revalidation, nobody is sure, and the safe-sounding answer is "full regression and a new validation package." That costs weeks, so the update waits. Six months later forty updates are queued and the next release has become a large, risky change. Meanwhile security sees a known exploited vulnerability in one of them and asks why it is still in production.

NIST SP 800-40 Rev. 4 (April 2022) frames patching as preventive maintenance and notes the divide between mission owners and security teams about its value. In GxP the cost of validation work is visible and the cost of an exploited library is not, until it is. The fix is not to skip assurance; it is to make assurance proportionate and decide the rules before the next urgent finding.

How to sort a library patch into a risk tier

Ask two separate questions. What can this change break in the process? How urgent is the security problem? Urgency decides when you change; process risk decides how much assurance you need.

Step 1: Map the library to the functions it supports

Keep a component inventory (an SBOM) per validated version, and for components that matter, a note of which features depend on them. It needs to answer one question well: does this library sit under a function that controls, measures or releases product, or under one that reports, exports or logs?

Step 2: Classify the change

Step 3: Combine them into an assurance plan

A worked example of how a quality unit might write this down. It is not a regulatory requirement; adjust it to your SOPs.

Two things make this workable. A trustworthy automated regression suite is often the largest single saving, and the CSA guidance recognises automated testing and digital records as evidence. And process controls outside the software count: if a person independently reviews every batch result, a failure in a reporting function is caught there, which can justify lighter assurance for that function.

Step 4: Record why, not just what

Use the CSA record elements as a minimum and add Annex 11 clause 1's "justified and documented" risk assessment. A reviewer should be able to follow your reasoning even if they would have chosen differently.

Which vulnerabilities justify an out-of-cycle change

Most fixes can ride the planned release. Write the exceptions into your change control SOP as explicit criteria, so an emergency change is a known path rather than an argument.

Signals worth using

• CISA Known Exploited Vulnerabilities (KEV). A KEV entry means exploitation in the wild has been observed. For federal agencies, CISA's BOD 26-04 (10 June 2026) sets remediation timelines from four factors: KEV status, exploit automation, technical impact and asset exposure. It revoked BOD 22-01 and BOD 19-02. It binds agencies, not pharmaceutical companies, but its four factors are a sensible public model.
• Reachability. Does the system's code call the vulnerable function? It is evidence for a risk decision, not a guarantee, and weaker for reflection, dynamic dispatch and data-driven flaws.
• Exposure. Internet, corporate network, or an isolated manufacturing segment? Isolation lowers likelihood but does not remove it where laptops, vendor remote access or file transfers cross the boundary.
• Exploit likelihood. FIRST's EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days. Use it to rank findings not on KEV.
• Data and process impact. Altered GMP records, a stopped line, or access to a system that releases product. Map it to the tiers above.

A worked trigger rule

An illustration, not a recommendation for any site:

1. Emergency change (days): on KEV, reachable or unknown, and reachable from outside the system's own segment.
2. Expedited change (weeks): on KEV but unreachable or isolated; or not on KEV but reachable with high EPSS and high impact.
3. Next planned release: reachable with low EPSS and low impact, or unreachable and not on KEV.
4. Document and monitor: not affected, with a recorded justification and a trigger to reassess if KEV status, exploitability or the code path changes.

An emergency change still goes through change control, on the emergency path your SOP defines, with the same record elements. The assurance is usually targeted: test the patched function, run regression, confirm audit trails and access control behave, and schedule deeper testing for the next release. See also keeping a contract promise of no known exploited vulnerabilities and whether you can patch during a change freeze.

How to record "not affected" decisions so an inspector can follow them

Most findings in a mature system will not need a change: the vulnerable function is never called, the feature is disabled, or a built-in control blocks the attack. In GxP, an undocumented "we looked, it's fine" is still a gap. If an inspector sees a critical CVE in your inventory, you want a dated, attributed record of why the system was left alone.

Use VEX for the vulnerability statement

CISA's "Minimum Requirements for Vulnerability Exploitability eXchange (VEX)" (21 April 2023) requires a VEX document to identify its author and carry identifiers and timestamps, and each statement to name the product and vulnerability with one status: not affected, affected, fixed or under investigation. A not affected statement should give a justification, and must give an impact statement if it does not. The justifications are: component not present, vulnerable code not present, vulnerable code not in execute path, vulnerable code cannot be controlled by adversary, and inline mitigations already exist. VEX can be written in CSAF 2.0, CycloneDX or OpenVEX.

Tie it to the validated version and wrap it in a quality record

The most common mistake is a statement with no version. "Not affected" becomes false the day someone adds a caller. Scope each statement to the exact validated version, matched to that release's SBOM. Then wrap it in a quality record holding the finding (CVE, component, version, date), the analysis (reachability result and how it was obtained, exposure, KEV and EPSS at the time), the decision, the reassessment trigger, and who decided and approved.

More on justifications: VEX not affected justifications for unreachable code and what "vulnerable but not reachable" means.

Why floating versions and unpinned dependencies break change control

A validated system is validated in a specific configuration. Annex 11 clause 10 brings configurations under change control, and 11.10(k)(2) asks for an audit trail of modifications. Neither works if the configuration changes itself.

That is what floating versions do. "Latest," wildcards and ranges let the package manager pick a different version on each build, so a rebuild for disaster recovery or an unrelated fix can pull transitive packages nobody tested or approved, while the documentation still lists the old ones.

Rules that close the gap:

• Commit lockfiles and build in frozen or locked mode so a mismatch fails the build.
• Pin container base images by digest, not tag.
• Keep an SBOM per validated version, generated from the built artifact and archived with the validation package; it is the Annex 11 clause 4.3 inventory at component depth.
• Fail builds on unpinned versions in validated product lines through a CI policy gate.

The bonus: with everything pinned, a patch becomes a small, deliberate diff that is easy to assess and test. For a fixed library reappearing after a merge, see how to stop a fixed vulnerability from being reintroduced.

How to keep code and data inside the validated environment

Many GxP sites forbid sending source code, configuration or GMP data to cloud services, and some forbid AI processing of it. Annex 11 clause 3 also asks for formal agreements and risk-based supplier assessment when a third party processes data. Options, most isolated first:

• Fully air-gapped: platform, vulnerability data and any models inside your perimeter, with updates arriving as signed bundles through a controlled channel.
• On-prem with controlled inbound updates of vulnerability feeds only.
• Local scanning with metadata upload: a runner scans locally and sends component lists and findings, acceptable where the policy is about source code.
• No AI in the loop: a tool that runs deterministically, with AI off by configuration, not just unused.

Whichever you choose, the tool becomes part of your process. If its output drives which patches you apply or which findings you mark not affected, your quality unit may need to assess it for that intended use. The CSA guidance treats tools that support development and testing as supporting software, often lower risk, where vendor evaluation, installation and configuration records may be enough. That call belongs to your quality unit.

A worked example: one CVE, three systems

An illustration, not a real event. Three validated systems carry the same XML parser version. A critical CVE is published and added to KEV a week later.

• System A, a laboratory information system. The parser handles instrument result files on import, the vulnerable function is on that path, and the system is reachable from the lab network. Emergency change. Process risk is high because import errors could alter results used for release, so: scripted tests of import with representative files, regression, audit trail checks, quality approval.
• System B, a document management system. A reporting add-on uses the parser for export. Reachable, but the feature is not high process risk. Expedited change with regression and exploratory testing of export, and a short record.
• System C, a training records system. The parser is a transitive dependency of an unused integration module; the vulnerable code is not in the execute path. Not affected: a VEX statement scoped to the validated version, a quality record with a reassessment trigger, and the upgrade queued for the next planned release.

Same CVE, three defensible responses, each recorded. None needed full revalidation; none ignored the finding.

How Safeguard does this job

Safeguard covers inventory, prioritisation, policy and evidence. It does not decide process risk, perform validation or approve a change. The steps use only what Safeguard's docs describe; where the docs show no screen or command, the step describes the outcome.

Step by step

1. Choose where Safeguard runs. On-prem and fully air-gapped deployment are GA. Safeguard's air-gapped docs describe a receiver in your DMZ that verifies signed snapshot bundles (vulnerability feed deltas including CISA KEV and daily EPSS, policy template updates, platform binaries) and pushes them to a control plane inside your perimeter, with no component inside calling outbound. Delivery can be a one-way diode, signed removable media, a scheduled DMZ sync or a pull replica. Zero AI mode (GA) runs the platform with no LLM. The docs also state that source code, SBOMs and telemetry are never used to train shared models.

2. Scan each validated version and keep its SBOM. SBOM generation and analysis is GA, in SPDX and CycloneDX. With the CLI (GA) or the local runner (GA):

   safeguard scan --dir .
   safeguard scan --image <name>
   safeguard scan --sbom <file>
   

   Results are written as JSON under ./output. In the web app, a project's Project Overview shows the version and branch or tag scanned, who created it and how the SBOM was generated, with a Dependencies tab for the full transitive tree. Export the SBOM as SPDX or CycloneDX to archive with the validation package. Scans run on schedules you set, on a manual Rescan, or in CI.

3. Read findings with KEV, EPSS and reachability. SCA and vulnerability management with EPSS and KEV is GA, and reachability analysis is GA. The docs classify findings as reachable, conditionally reachable, unreachable or unknown, and treat unknown as potentially reachable rather than suppressing it. They list static reachability for Ruby and PHP, and Swift and Objective-C overall, as covered. Safeguard's docs say reachability filtering typically removes 60 to 80% of findings from the urgent queue; treat that as Safeguard's stated figure, not a promise. Filters such as kev:true and reachable:true in the Vulnerabilities tab line up with the trigger rule above.

4. Upload VEX for not affected decisions. CSAF and VEX upload is GA. Go to Integrations, filter by Upload, click Connect on the Upload CSAF/VEX card, name the upload and add the file (CSAF 2.0, CycloneDX VEX, OpenVEX or the CSAF VEX profile), then set the Project Name and the Version, which ties the statement to the validated version. The Mitigations tab tracks risk acceptances with expiration dates, false positive markings and mitigation history, a dated trail with a built-in reassessment point.

5. Set policies and gates for validated lines. Policies and gates are GA. Each policy has one action: Block fails the gate, Warn passes it with a warning naming the policy, Notify passes it and sends a notification. An evaluation error is never counted as a pass, and a gate never evaluated shows Not evaluated, never Passed. You might Block on reachable KEV findings, Warn on unpinned versions during clean-up, and Notify on new high EPSS findings. When a finding must ship anyway, approval runs through an exception, which records who accepted the risk. Policy outcomes are turned on per workspace by Safeguard; if there is no Outcome column, ask your Safeguard contact.

6. Enforce the gate in CI. From the policy outcomes docs:

   safeguard ci scan --wait --fail-on-gate <gate name or id | all>
   

   It waits for the scan and gate evaluation, exits 0 on Passed or Warning, and exits non-zero on Failed, Error or Not evaluated, printing the failed Block policies. The result becomes build evidence for the change record.

7. Use the GxP and 21 CFR Part 11 framework pages. The compliance and GRC suite is GA. The GxP page lists scan requirements decided by each product scan and mapped to Annex 11 and 21 CFR 211.68: system inventory (clause 4), supplier attribution of each component (clause 3), document identity and timestamps that anchor audit trails (clause 9), change and configuration management where "latest," wildcards and ranges count against you (clause 10), cryptographic integrity evidence for components (clause 12), and recorded software versions for automated equipment (211.68). The Part 11 page maps scan requirements to 11.10(a), (b), (c), (e), (k) and 11.50, with the same floating version check under 11.10(k). Both add catalog controls (for GxP, change control, CSV, IQ, OQ and PQ among them) that you evidence with tests, uploads, policies or attestations, plus policy templates such as a Validation Master Plan and a Change Control and CAPA Procedure. Both frameworks are on unless switched off in Compliance › Manage.

8. Open fix pull requests, under your control. Autonomous remediation with Griffin fix pull requests is GA and ships switched off, with every category set to Manual. Enabled for a category, it opens a pull request moving the dependency to a fixed version; your review, testing and change control then apply. One diff, one record, one approval.

9. Approve each step locally. The Safeguard CLI asks before any command that changes something, so an engineer can have it prepare an upgrade and approve each edit and command. The desktop app shows the same approvals.

What each piece gives your change record

What remains the quality unit's call

• Intended use of each feature and whether it is part of production or the quality system.
• Process risk. A tool can say a library is reachable; it cannot say the function it serves decides batch acceptability.
• The assurance plan: which tests, scripted or unscripted, and who runs them.
• Regulatory impact, including any notification or submission update.
• Release approval that the system remains acceptable for its intended use.
• Supplier assessment of any tool in the process, Safeguard included.

What Safeguard does not do

• It does not validate your system. It produces inventory, findings, gate outcomes and records that can feed validation evidence; the validation is yours.
• It does not decide regulatory impact or process risk. Reachability and KEV status are inputs, not the assessment.
• A framework readiness score is not an inspection outcome. Inspectors look at the whole quality system, most of which Safeguard never sees: training, SOP adherence, deviations, CAPA, physical controls.
• It makes no "Part 11 compliant" claim. Part 11 compliance is a property of your system, procedures and records together.
• Reachability is not equal across languages. Any reachability analysis is weaker for reflection, dynamic dispatch, native code and data-driven flaws.
• You must assure Safeguard itself if its output becomes part of a GxP process.
• It does not test your application's GxP functions. Your scripted and unscripted tests still run in your environment.
• It does not fix code it does not see. Vendor appliances, hosted services and operating systems you do not build need the vendor's fix.

Common mistakes

• Every library update as full revalidation. This guarantees a growing backlog and large, risky releases.
• Every library update as no validation impact. A patch under a high process risk function needs targeted testing and quality approval.
• Citing CSA as covering drug CGMP, or the draft Annex 11 as current.
• CVSS alone driving out-of-cycle changes. Severity is not likelihood or relevance; combine KEV, EPSS, reachability and exposure.
• Not affected statements without a version, and without a reassessment trigger.
• Letting builds float, and inventories that list only direct dependencies.
• Writing the emergency path during the emergency.
• Screenshots as evidence. System logs, audit trails, CI gate results and SBOMs are better records, as the CSA guidance recommends.

FAQ

Do we have to revalidate a GxP system every time we patch an open source library?

No. The regulations require a validated system and controlled changes; how much testing a change needs is a documented, risk-based decision. Patches under functions that are not high process risk can often be assured with regression and exploratory testing; those under high process risk functions need targeted scripted testing and quality approval.

Is FDA's Computer Software Assurance guidance final?

Yes. Computer Software Assurance for Production and Quality Management System Software was issued on 3 February 2026, superseding a final version of 24 September 2025. It began as a September 2022 draft and contains nonbinding recommendations.

Does the CSA guidance apply to pharmaceutical manufacturing?

Its stated scope is device production and quality management system software under 21 CFR Part 820. It does not address Part 211. Drug manufacturers often apply the same principles, consistent with ICH Q9(R1) and Annex 11, and should describe their approach that way.

Has the revised EU GMP Annex 11 been finalised?

Not as of this writing. The consultation on the revised Annex 11, Chapter 4 and new Annex 22 ran from 7 July to 7 October 2025, and EudraLex still lists the January 2011 Annex 11.

What makes a library patch high risk?

Under FDA's CSA framing, a function is high process risk when its failure could lead to a quality problem that foreseeably compromises safety. A patch is high risk when it sits under such a function, or when a major or replacement change could alter behaviour broadly.

Which vulnerabilities should trigger an emergency change?

Write the rule into your SOP. A common pattern: on CISA's KEV catalog, reachable or unknown in your code, and exposed beyond the system's own segment. CISA's BOD 26-04 factors (KEV status, exploit automation, technical impact, asset exposure) are a useful public model.

How do we document that a vulnerability does not affect a validated system?

A VEX statement scoped to the validated version with a justification such as "vulnerable code not in execute path," inside a quality record with the analysis, decision, reassessment trigger, and who decided and approved.

Why do lockfiles matter for 21 CFR Part 11?

11.10(k)(2) asks for change control with an audit trail of modifications, and Annex 11 clause 10 covers configurations. Without pinned versions, a rebuild can pull dependencies you never validated.

Is Safeguard validated or Part 11 compliant?

Safeguard does not claim to make any system Part 11 compliant and does not validate your system. If its output becomes part of a GxP process, your quality unit decides what assessment the tool needs for that intended use.

When the fixed version is not there yet

Everything above assumes a fixed version exists and can be tested into a validated system on your schedule. When it does not, or when a safe version needs to reach many systems quickly, the options below are Safeguard's general remediation paths; any of them still enters your validated system through the same change control and proportionate assurance described in this post.

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

These demos show the surfaces a validated-system team would use day to day. None of them is a validation screen; they show how scanning and fixing stay on your own machines with a person approving each change.

The first demo shows the local runner. You set up the runner on your own machine, approve it with its device code, then scan from the terminal. For a GxP site this is the pattern that keeps source code on your network while you build the SBOM for each validated version.

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

The second demo is a real desktop app session. The CLI session shows in the desktop app's conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with an upgrade done and tests passing. In a validated system that upgrade would then go into your change record and assurance testing; the approval at each step is what keeps it a controlled change.

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

The third demo is a real CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. That one-line, pinned, tested diff is the shape of change that is easiest to assess in a validated system.

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

To try it on your own systems, download Safeguard from https://safeguard.sh/download and read the docs at https://docs.safeguard.sh/docs . For the wider security picture in life sciences, see GxP security for biotech and life sciences, and for device makers, FDA's February 2026 cybersecurity guidance and the QMSR changes.

Quick check

Sources

• eCFR: 21 CFR Part 11, Electronic Records; Electronic Signatures
• eCFR: 21 CFR 211.68, Automatic, mechanical, and electronic equipment
• FDA: Computer Software Assurance for Production and Quality Management System Software (final, February 2026)
• FDA: CSA guidance document (PDF)
• FDA: Data Integrity and Compliance With Drug CGMP: Questions and Answers
• European Commission: EudraLex Volume 4, Annex 11 Computerised Systems (2011)
• European Commission: EudraLex Volume 4 GMP guidelines
• European Commission: Stakeholders' consultation on Chapter 4, Annex 11 and new Annex 22
• ICH Q9(R1) Quality Risk Management (PDF)
• PIC/S publications (PI 011-3, PI 041-1)
• ISPE GAMP 5 Guide, Second Edition
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Minimum Requirements for Vulnerability Exploitability eXchange (VEX)
• FIRST: Exploit Prediction Scoring System (EPSS)
• Safeguard Docs: GxP (GMP/GLP/GCP)
• Safeguard Docs: Explore SBOM
• Safeguard Docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard Docs: CSAF/VEX Upload
• Safeguard Docs: Policy outcomes and actions
• Safeguard Docs: Air-Gapped Deployment
• Safeguard Docs: AI Models

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