Pass a Pharma Customer's GxP Supplier Audit as a Software Vendor

A pharma customer's GxP supplier audit checks whether your software is built and changed under control, so the customer can rely on your work when it validates the system. Auditors sample your quality system, release and change records, the component inventory behind each release, how you handle vulnerabilities, and proof that what you shipped is what you built. Prepare that evidence per release, and share it once, under NDA, with every customer's auditor.

This post is for the quality, security or compliance lead at a US vendor selling laboratory, quality, clinical or manufacturing software to pharma and biotech. It is the supplier's side of the audit. If you are the pharma company trying to patch a validated system, read the companion post, patch open source in a GxP validated system without full revalidation.

Key takeaways

• Your customer is the regulated party. 21 CFR Part 11, 21 CFR 211.68 and EU GMP Annex 11 bind the pharma company, and the company passes the duty to you through supplier assessment and contracts.
• Annex 11 clause 3 asks regulated users to have formal agreements with suppliers and to base the need for an audit on risk. Clause 4.5 says the supplier should be assessed appropriately. GAMP 5 Second Edition encourages customers to reuse supplier documentation, which rewards vendors whose evidence is ready.
• Auditors sample four things in the software supply chain: a pinned component inventory per release, change and release records, vulnerability handling for releases customers have validated, and integrity evidence for what you delivered.
• Safeguard SBOM generation and analysis (GA) produces an SPDX or CycloneDX inventory per release, tied to a version and branch or tag.
• The Safeguard compliance and GRC suite (GA) has GxP and FDA 21 CFR Part 11 framework pages whose scan requirements check pinned versions, supplier attribution, hashes and document identity on every scan.
• Safeguard policies and gates (GA) record a Passed, Failed, Warning, Error or Not evaluated outcome for each release, and safeguard ci scan --wait --fail-on-gate stops a build when a Block policy fails.
• Safeguard attestation and signing (GA) shows a SCAL level, signature status and provenance per component. Vulnerability management (GA), reachability analysis (GA) and CSAF and VEX upload (GA) support affected and not-affected statements.
• Safeguard Portal, the SBOM publish and share product (GA), shares SBOMs with NDA acceptance and download tracking, with an audit trail of who saw what.
• Nothing here makes your product "Part 11 compliant" or "GxP certified". Your quality management system, training records and SOPs come from elsewhere, and the customer still validates for its intended use.

Why do pharma companies audit software suppliers?

Because the regulations make them responsible for software they did not write. A pharma company that runs your laboratory information system, quality management system, manufacturing execution system or clinical data platform in a GMP, GLP or GCP process owns the validated state of that system. It cannot hand that duty to you. What it can do is rely on your work, and it can only rely on work it has assessed.

A supplier audit is the customer's quality unit deciding how much of your development, testing and change control it can trust, and so how much it must repeat. A weak assessment means more testing, more questions, and a product that may be judged too much work to keep.

What EU GMP Annex 11 says about suppliers

The European Commission's Annex 11 on computerised systems, in force since 2011, is the clearest text on suppliers, and US pharma companies selling into Europe apply it alongside FDA rules. Clause 3 covers suppliers and service providers:

• 3.1 When third parties supply, install, configure, integrate, validate, maintain or support a computerised system, there should be formal agreements that state their responsibilities.
• 3.2 The competence and reliability of a supplier are key factors in choosing them, and the need for an audit should be based on a risk assessment.
• 3.3 Documentation supplied with off-the-shelf products should be reviewed by the regulated user to check that user requirements are met.
• 3.4 Quality system and audit information about suppliers or developers of software should be made available to inspectors on request.

Clause 4.5 adds that the regulated user should take all reasonable steps to make sure the system was developed under an appropriate quality management system, and that the supplier should be assessed appropriately. Clause 10 asks that changes are made in a controlled manner under a defined procedure. Clause 11 asks for periodic evaluation. Clause 12.1 asks for physical or logical controls that restrict access.

Read clause 3.4 from your side of the table: the customer's audit report about you may be handed to an inspector. That is why auditors ask for records rather than assurances.

A revision of Annex 11 (together with Chapter 4 on documentation and a new Annex 22 on artificial intelligence) went to stakeholder consultation from 7 July 2025 to 7 October 2025, according to the European Commission's consultation page. It is still a draft. The 2011 text is the one in force, and that is what auditors cite today.

What GAMP 5 thinking adds

ISPE's GAMP 5 guide is the industry's working method for validating GxP computerised systems. The Second Edition, published in July 2022, keeps the risk-based framework of the first edition and, according to ISPE's page, gives more weight to service providers and encourages regulated companies to maximise supplier involvement so they can use the supplier's knowledge, experience and documentation where possible. ISPE's page also says the guide covers open source software, iterative development, and more use of software tools and automation, and that it is intended for suppliers as well as regulated companies and regulators.

In practice a pharma customer would rather reuse your test evidence and release records than repeat them, but only for a supplier it has assessed and trusts. The audit is the gate to that trust.

GAMP 5 also stresses critical thinking by subject matter experts, so the auditor will not be satisfied by a binder. They will pick a release, a component and a vulnerability, and follow the trail.

FDA's risk-based approach

In the US, two regulations carry the weight for drug manufacturers.

21 CFR 211.68 covers automatic, mechanical and electronic equipment, including computers, used in drug manufacture. Paragraph (a) requires such equipment to be routinely calibrated, inspected or checked under a written program, with written records. Paragraph (b) requires appropriate controls over computer systems so that changes to master production and control records are made only by authorised personnel, input and output checked for accuracy, and a backup kept that is secure from alteration, inadvertent erasure or loss.

21 CFR Part 11 covers electronic records and electronic signatures, and section 11.10 lists the controls for closed systems. More on that in the next section.

FDA's newer thinking on software assurance is in its Computer Software Assurance (CSA) guidance. FDA announced the final guidance in the Federal Register on 24 September 2025, and the current version is dated 3 February 2026. It is written for software used in medical device production and quality systems under 21 CFR Part 820, not for drug manufacturing. Pharma quality teams borrow its principles anyway: focus assurance effort on software features that carry high process risk, use the least burdensome assurance activity that gives confidence, and use supplier records and testing where they are adequate. If your customer has adopted a CSA style approach, your evidence directly reduces what it has to test.

PIC/S, the cooperation scheme for GMP inspectorates, publishes inspector guidance that shapes audits: PI 011-3, Good Practices for Computerised Systems in Regulated GxP Environments, and PI 041-1, Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments. PI 054-1 covers risk-based change management. Your customer's auditors have usually been trained against these.

What does 21 CFR Part 11 require, and what can the customer expect you to show?

Part 11 applies to the regulated company's records and signatures. It does not certify software. Instead of "Part 11 compliant", say the product has features that let a customer meet Part 11 when it configures, validates and operates the system under its own procedures.

Section 11.10 lists the controls for closed systems. Here is each one, with what it means for the vendor.

Two lines in that table land squarely on the vendor.

11.10(i) is about your people. "Persons who develop" includes your engineers. An auditor will ask for training records and role descriptions for the people who build and support the product. That evidence lives in your HR and learning systems.

11.10(k) is about your documentation. System documentation needs controls over distribution and access, plus revision and change control with an audit trail that documents its time-sequenced development and modification. A release note that does not match the build, an installation guide that names a component version you no longer ship, or a manual with no revision history will be noted.

Your component inventory sits under several of these at once. Validation under 11.10(a) only has a meaning against a system whose parts are named and versioned. Documentation under 11.10(k) includes the record of which components went into which release. And the ability to discern altered records under 11.10(a) starts with being able to show that the software processing those records is the software you released.

What component and change control evidence do auditors sample?

Auditors sample. A typical trail looks like this:

1. Pick a release the customer has validated, for example version 7.4.2.
2. Ask for the release record: what changed, who approved it, what testing ran, when it shipped.
3. Ask for the list of third-party and open source components in that release, with exact versions.
4. Pick one component and ask how you chose it, how you track it, and what you did about its known vulnerabilities.
5. Ask how you would know if that component's version changed between the build you tested and the build you shipped.

Each step needs a record that exists before the auditor asks.

A pinned component inventory per release

The inventory has to be exact. "Uses a JSON library" is not an inventory. "Version 2.17.x of a JSON library" is not pinned. The auditor wants the name, the exact version and ideally the supplier and a hash, for every component, in a release you can name.

A software bill of materials (SBOM) is the standard way to hold this. CISA, NSA, FBI and international partners published the 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026, which updates and replaces the NTIA minimum elements from 2021. It sets the baseline data an SBOM should carry. NIST's Secure Software Development Framework, SP 800-218 version 1.1 (February 2022), asks producers to archive and protect each software release (PS.3.1) and to collect, safeguard, maintain and share provenance data for all components of each release, for example in an SBOM (PS.3.2). For how to do that in a pipeline, see how to produce an SBOM for every release.

The key words are per release. The customer validated a specific version, so you need the 7.4.2 inventory retrievable two years after 7.5 shipped.

Pinned versions in the build itself

An auditor who understands software will ask how the inventory relates to the build. If your manifests use version ranges, wildcards or "latest", the build that produced 7.4.2 might resolve different components from the build you tested an hour earlier. That is a change control failure under Annex 11 clause 10 and 21 CFR 11.10(k), even if nobody intended a change.

The fix is lockfiles enforced in CI, and container images referenced by digest.

Change and release records

For each release the auditor wants a record that links:

• The change requests or tickets included.
• Who reviewed and approved the code changes.
• What automated and manual testing ran, and the results.
• The security checks that ran, their outcome, and who approved any exception.
• The release approval, with name and date.
• The documentation set that shipped with it, at its revision.

The security check record is the part vendors most often lack: a CI log line deleted after 30 days is not evidence. An auditor wants a retained record that shows the release passed a defined gate, or that a named person approved shipping with a known exception and why. For more on that, see prove every production release passed a security gate.

Component selection and supplier attribution

Annex 11 clause 3 is about your suppliers, but your customer will apply the same logic one level down: who supplies the components inside your product? Open source components have no contract, so the evidence is different. Auditors look for:

• A documented process for approving new components (licence, maintenance activity, known vulnerabilities, origin).
• Each component attributable to a named supplier or project.
• A view of how well each component's origin and build can be verified.

How should a vendor handle vulnerabilities in a release a customer has validated?

You want customers on the latest release. The customer validated 7.4.2 and will not move to 7.6 until it has assessed the change. Then a critical vulnerability is published in a library inside 7.4.2.

The customer needs three things from you, quickly:

1. Is 7.4.2 affected? Not "is the library present", but does the vulnerable code run in your product in a way that matters.
2. If affected, what is the fix and how big a change is it? A patch release, 7.4.3, that changes only that library is a small change for the customer to assess. A jump to 7.6 is a large one.
3. If not affected, a written statement they can file. The customer's quality unit needs a record it can show an inspector.

Have a disclosure policy that fits validated customers

SSDF practice RV.1 asks producers to identify and confirm vulnerabilities on an ongoing basis, including by having a policy for receiving and handling reports. RV.2 asks them to assess, prioritise and remediate. For a pharma customer base, your policy should say:

• Which release lines you support with security patches, and for how long.
• How quickly you will tell customers whether a supported release is affected by a critical vulnerability.
• That security patches for a supported line are issued as minimal changes on that line, so customers can assess them without revalidating a feature release.
• How you deliver affected and not-affected statements, in what format.

Use VEX for affected and not-affected statements

A Vulnerability Exploitability eXchange (VEX) document states, per product version and per vulnerability, whether the product is affected, not affected, fixed, or under investigation, with a justification for "not affected". Delivered in CSAF or CycloneDX format, it is machine-readable, so a customer with many suppliers can process it. More importantly for GxP, it is a dated, versioned statement tied to a release, which is exactly the kind of record a quality unit can file.

Do not issue a "not affected" statement because a scanner score is low. Issue it when you have evidence: the vulnerable function is not called, the vulnerable configuration is not used, or the component is present only in a build tool that does not ship. Write down which.

Do not force an upgrade to deliver a fix

When the fix exists only in a much newer version of the component, most pharma customers want a backported fix on the release line they run, not an upgrade that changes validated behaviour. The section on fixing without waiting for upstream below covers the options.

What integrity evidence shows the delivered software was not altered?

The auditor's question is simple: how does the customer know the software it installed is the software you tested and released? Annex 11 clause 12.1 asks for controls that restrict access, and 21 CFR 11.10(a) asks for the ability to discern altered records. Your customer extends that to the software itself.

Integrity evidence comes in layers:

• Hashes for delivered artifacts. Publish a cryptographic hash for every installer, package or container image you deliver, and tell customers how to check it. SSDF practice PS.2.1 asks producers to make software integrity verification information available to acquirers.
• Signatures. Sign release artifacts and publish how to verify the signature.
• Build provenance. A record of where and how the artifact was built, from which source revision, on which builder. The SLSA framework and in-toto are the common formats.
• Component hashes in the SBOM. An SBOM that carries hashes for each component lets the customer, or you, check that the components in the deployed system match the inventory.
• Container images by digest. If you ship images, reference and deliver them by digest so the image cannot change under the same name.

How do you share evidence with many customers' auditors without a new pack each time?

A vendor with twenty pharma customers can face twenty audits a year asking for the same records in different shapes. A new pack each time is slow and breeds inconsistencies.

The better pattern:

1. Keep evidence per release in one place, generated by the pipeline rather than assembled by hand.
2. Separate what is shareable from what is internal. SBOMs, VEX documents, release notes, policy outcomes and test summaries can be shared under NDA. Source code and internal tickets usually cannot.
3. Share under NDA with access controls: per recipient, with expiry, and with a record of who downloaded what.
4. Keep an audit trail of the sharing itself, so you can show which version of which document each customer received.
5. Answer questionnaires from the same records, so answers match the evidence.

How Safeguard does this job

Safeguard covers the software supply chain part of a supplier audit: the component inventory per release, the scan-checked GxP and Part 11 requirements, release gates with recorded outcomes, component attestation, vulnerability statements, and NDA-gated sharing with an audit trail. It does not cover your quality management system, your training records or your customer's validation. Every capability below is generally available (GA) unless marked otherwise. The Trust Center is generally available and is not part of this flow.

Step by step

1. Connect each product's source and images. In Safeguard, go to Integrations from the sidebar. The Add Project/Product tab lists source code integrations (GitHub, GitLab, Bitbucket and generic Git), container image registries and file uploads. When you connect a repository, the review step lets you set the Branch/Tag, the Project Name and the Version for each repository. Set the branch or tag to your release tag so each scan maps to a released version.

2. Generate an SBOM for every release (SBOM generation and analysis, GA). Safeguard generates SBOMs in SPDX and CycloneDX. The generation options include the version (auto-detected from git tags), the branch or tag, whether to include development dependencies, and Deep Analysis. Continuous scanning can run on push, on a schedule or on release. To scan from your own pipeline or machine, the Safeguard CLI (GA) scans a directory, an image or an existing SBOM file:

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

   Results are written as JSON under ./output. Keep development dependencies out of the release SBOM unless they ship, and record that choice in your SBOM procedure.

3. Turn on the GxP and FDA 21 CFR Part 11 frameworks (compliance and GRC suite, GA). Both framework pages are on by default in a workspace unless you switch them off in Compliance › Manage. Each scan of a product checks the framework's scan requirements against what the scan found, including the product's SBOM. The next section lists what each requirement checks.

4. Define the release gate (policies and gates, GA). Create policies for the conditions that must not ship, for example a known exploited vulnerability in a reachable component or a component with no pinned version, and link them to a release gate. Each policy has one Action: Block fails the gate, Warn lets it pass with a warning that names the policy, and Notify lets it pass and sends a notification to your configured channels. Safeguard's offering also lists "require approval" as a gate action; the policy outcomes docs page documents Block, Warn and Notify, so confirm the approval flow on your workspace before you write it into an SOP.

5. Fail the build when the gate fails. In CI, run the documented command:

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

   It waits for the scan and for the gate's policies to be evaluated on the new data. It exits 0 when the gate is Passed or Warning, and exits non-zero when the gate is Failed, Error or Not evaluated, or when the policies were not evaluated before --timeout. --fail-on <severity> can be combined with it. A gate that has never been evaluated shows Not evaluated, never Passed, which is the behaviour an auditor wants: no silent pass.

6. Keep the gate outcome as a release record. Under Policies › Gates, expand the gate to see each linked policy's Action, outcome, effect on the gate, matches and evaluation time, plus the gate's evaluation history. Reference that outcome in your release record. Policy outcomes are turned on per workspace by Safeguard; if your workspace does not show an Outcome column yet, ask your Safeguard contact.

7. Review component attestation (attestation and signing, GA). Open a project, go to Explore SBOM, and click the Attestation tab. Each component shows a Safeguard Component Attestation Level (SCAL) from 0 to 5, where lower is better, plus attestation type, signature status and provenance (build platform, source repository, build trigger, timestamp and builder identity) where they exist. Filter on Unattested Only to list SCAL 3 to 5 components. You can create a policy that sets a maximum SCAL level for a release gate.

8. Triage vulnerabilities in validated releases (vulnerability management, GA; reachability analysis, GA). Safeguard matches components against NVD, GHSA, OSV, CISA KEV and vendor bulletins, and combines reachability with EPSS and KEV into one priority. Reachability support varies by language. Use the SBOM for the customer's validated version, not your main branch, when you answer "is 7.4.2 affected?".

9. Record affected and not-affected statements (CSAF and VEX upload, GA). Upload your CSAF or VEX documents through Integrations › Upload CSAF/VEX so the statements sit next to the SBOM they describe.

10. Publish the release evidence to Portal (Portal, the SBOM publish and share product, GA). Publishing moves an artifact from the scanning side of Safeguard into Portal and creates an immutable copy. That copy is what you share. Products move through Draft, Review, Published and Archived.

11. Share under NDA. In Portal sharing, choose direct sharing (named recipients, with View, Download or Full permission) or a shareable link (with expiry date, download limit, password and format restrictions). At the SBOM level you can require NDA acceptance and turn on download notifications. Organisation-level settings can require authentication for all shares and restrict sharing to approved domains. For many customers at once, select several SBOMs and use Share Selected. You can also set up a branded customer portal under Settings › Customer Portal. Revoke access from the SBOM's sharing settings; access ends immediately.

12. Show the audit trail. Go to Settings › Audit Logs in Portal. Each entry records timestamp (UTC), actor, action, resource, details, IP address, user agent and result, and covers SBOM creation and changes, views, downloads, sharing events, link use and permission changes. Export as CSV, JSON or a formatted PDF. The docs list default retention of 2 years for access logs and 7 years for administrative and security event logs, configurable for enterprise customers. The audit trail docs page also shows a REST API, but it carries a banner that the /v1 endpoints are not yet available, so use the web interface and exports.

What the GxP and Part 11 framework pages check on each scan

Safeguard's docs list the scan requirements for each framework. All are decided by a scan.

GxP (GMP, GLP, GCP) has seven scan requirements:

FDA 21 CFR Part 11 has six:

These check properties of your inventory and its documentation. They do not test your product's audit trail, electronic signatures or access controls.

Each framework page also lists more controls from Safeguard's control catalog that you evidence with automated tests, uploaded evidence, policies or an attestation. For GxP these include URS, IQ, OQ and PQ, change control, deviation and CAPA, training, SOPs and computer system validation. Both frameworks come with policy templates: for GxP, a validation master plan, a data integrity policy, a change control and CAPA procedure and a training requirements procedure; for Part 11, a computer system validation policy, an electronic signature controls procedure, an audit trail review procedure and an open systems security policy. Treat templates as a starting draft for your QMS, not as approved documents.

One caution from reading the Part 11 page: its catalog list labels a control "11.10(k) Personnel Training Controls". In the regulation, training is 11.10(i) and 11.10(k) is control over systems documentation. Map your training evidence to 11.10(i) when you build your own trace matrix.

What each piece gives the auditor

Deployment questions the auditor may ask about Safeguard

Safeguard can run as SaaS, on premises or air-gapped (GA), and Zero AI mode (GA) turns off AI features. Its posture is designed for FedRAMP High, and its SOC 2 Type II audit is in progress. It is not a validated GxP system; assess it as a supplier, the way your customers assess you.

What the audit covers that Safeguard does not

A supplier audit is much wider than the software supply chain. Expect the auditor to spend most of the day on things Safeguard does not touch:

• Your quality management system. The quality manual, document control, management review, internal audits, supplier management for your own suppliers, complaint handling, and CAPA.
• Your software development lifecycle procedures. How requirements become designs, how designs are reviewed, how you test, how you trace requirements to tests. GAMP 5 suppliers are expected to have this documented.
• Training. 21 CFR 11.10(i) evidence for the people who develop and support the product.
• Product features. Audit trails, electronic signatures, access control, data backup and restore, all tested by you and validated by the customer.
• Hosting and operations, if you run the product as a service.
• The quality agreement. The document that splits responsibilities between you and the customer, which Annex 11 clause 3.1 expects.

What Safeguard does not do

• It does not make anything Part 11 compliant or GxP certified. No product is compliant by itself. Safeguard makes no such claim for your software or for itself.
• The readiness score is not an audit result. A framework readiness score in Safeguard counts the requirements and controls you have evidenced. It is a working measure for your team, not a statement from an auditor or regulator, and you should not show it to a customer as one.
• The scan requirements check your inventory, not your product's functions. A pass on FDA-P11-10E means your system documentation carries identity and timestamps. It does not mean your product's audit trail meets 11.10(e).
• It does not hold your QMS, SOP or training evidence. The framework pages list catalog controls for these and offer templates, but the records come from your document control, learning and HR systems.
• It does not validate the system for the customer's intended use. The customer still writes its own requirements and decides what assurance to apply. Your evidence reduces that work; it does not replace it.
• It does not decide whether a validated release is affected. Reachability and exploit signals inform the decision. A named person on your team makes it and signs the VEX statement.
• The Portal audit trail API is not live. The docs page shows /v1 endpoints that return 404 today. Use the web interface and exports.
• The Trust Center is generally available and is not part of the flow in this post.

Common mistakes

• Saying "Part 11 compliant" in the sales deck. The auditor will ask you to prove it, and you can't, because compliance belongs to the customer's use of the system. Describe the features that support Part 11 instead.
• Version ranges in manifests. A range in a manifest means your tested build and shipped build can differ. Commit lockfiles and fail CI if they are missing or stale.
• Security results that vanish with the build log. Keep gate outcomes as release records with a retention period that matches your longest supported release line.
• Forcing a feature upgrade to deliver a security fix. Pharma customers will hold off, and the vulnerability stays open. Support patch releases on the lines customers have validated.
• Issuing "not affected" without a reason. A VEX statement without a justification is a claim the customer's quality unit cannot file.
• A new evidence pack per audit. Inconsistencies between packs are worse than gaps. Generate once, share many times, and log what each customer received.

FAQ

What does a pharma company check in a GxP supplier audit of software?

It checks whether it can rely on your development, testing and change control when it validates your product. Expect questions on your QMS, SDLC procedures, testing and traceability, release and change records, component inventory per release, vulnerability handling, integrity of delivered software, training, and the quality agreement.

Is a software vendor required to comply with 21 CFR Part 11?

Part 11 binds the regulated company that keeps electronic records and uses electronic signatures. The vendor is pulled in through supplier assessment and the quality agreement. Your product needs features that let the customer meet Part 11, and your processes need to support the customer's validation.

What is 21 CFR 11.10(k)?

It requires controls over systems documentation: controls on the distribution of, access to and use of documentation for operation and maintenance, and revision and change control procedures that keep an audit trail of how the documentation was developed and modified. Training is a separate control, 11.10(i).

Does EU Annex 11 apply to US pharma software vendors?

It applies to the regulated user, and many US pharma companies apply it because they supply the EU market or work to global procedures. Clause 3 on suppliers and clause 4.5 on supplier assessment are what pull you in. The 2011 text is in force; the revision consulted on in 2025 is still a draft.

Does FDA's Computer Software Assurance guidance apply to pharma?

It is written for medical device production and quality system software under 21 CFR Part 820. Pharma quality teams borrow its risk-based principles for GxP systems, and that makes good supplier evidence more valuable, because a CSA-style approach relies more on supplier records.

Do I need to provide an SBOM to a pharma customer?

21 CFR Part 11 and 21 CFR 211.68 do not mention SBOMs. Auditors still ask for a component inventory with exact versions, because validation and change control depend on it, and an SBOM is the standard format for it.

How do I tell pharma customers whether a validated release is affected by a new CVE?

Check the SBOM for that exact release, assess whether the vulnerable code is reachable in your product, and issue a dated VEX statement per release with a justification. If affected, offer a minimal patch release on the same line.

Is Safeguard validated for GxP use?

No. Safeguard produces supply chain records that your QMS controls. Assess it as a supplier. Its posture is designed for FedRAMP High and its SOC 2 Type II audit is in progress.

When a vulnerability lands in a component inside a release your pharma customers have validated, the hardest case is a fix that exists only in a much newer version, or not at all. The options below are how Safeguard approaches getting a fixed version without forcing a feature upgrade on a validated customer.

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 Safeguard CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix the lodash CVE in a repo. 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 your approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan .. For a supplier, that is the shape of a patch release on a validated line: one component changed, tests run, and every change approved by a named person.

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 supplier's release process, that upgrade then goes into your change record, your release gate and the SBOM for the patch release you share with customers.

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

To try it on your own releases, 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. To check what you send against the 2026 baseline, see check a supplier SBOM against minimum elements, and for the questions buyers increasingly ask every software supplier, see CISA Secure by Demand questions for software buyers.

Quick check

Sources

• eCFR: 21 CFR 11.10, Controls for closed systems
• eCFR: 21 CFR 211.68, Automatic, mechanical, and electronic equipment
• Federal Register: Computer Software Assurance for Production and Quality System Software, final guidance availability (24 September 2025)
• European Commission: EudraLex Volume 4, Annex 11 Computerised Systems (2011)
• European Commission: Stakeholders' consultation on Chapter 4, Annex 11 and new Annex 22
• ISPE: GAMP 5 Guide, Second Edition
• PIC/S: Publications (PI 011-3, PI 041-1, PI 054-1)
• PIC/S: PI 041-1 Good Practices for Data Management and Integrity
• NIST SP 800-218, Secure Software Development Framework version 1.1
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• Safeguard Docs: GxP (GMP/GLP/GCP)
• Safeguard Docs: FDA 21 CFR Part 11
• Safeguard Docs: Generate SBOM
• Safeguard Docs: Policy outcomes and actions
• Safeguard Docs: Attestation
• Safeguard Docs: Portal Sharing
• Safeguard Docs: Portal Audit Trails

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