Software Supply Chain Security for Nonprofits and NGOs: A 90-Day Plan

Software supply chain security for a nonprofit or NGO comes down to three jobs: know what is inside the software you build or commission (the donation site, the program app, the volunteer portal, the scripts that sync your CRM), know which vendor runs every system that holds donor, client or beneficiary data, and give both a patch clock that a named person owns. Small teams can do this. The constraint is not money first, it is attention, so the work has to be scoped to the systems that matter and written down in a form a board, a funder or an auditor can read. A focused team, even one person with a managed service provider and a few volunteers, can stand up the inventory, the rules and the vendor evidence in about 90 days.

This guide covers the software the sector runs, the US rules that reach it, incidents from the last three years, the people who own each part, and a 30, 60 and 90 day plan for any toolset. Safeguard appears only near the end. Nothing here is legal, regulatory or audit advice; your counsel, your auditor and your funders decide what applies to you.

Key takeaways

• A nonprofit's software supply chain is mostly bought, donated or volunteered: donor CRMs and add-ons, donation forms, grant and case management platforms, a CMS with plugins, and code from agencies, volunteers or a small team.
• No single US law says "software supply chain" for nonprofits. The obligations arrive through federal award terms (2 CFR 200.303 now names cybersecurity), state data security and breach laws, PCI DSS for card donations, HIPAA for health and human services programs, state privacy laws that cover nonprofits, and the expectations of funders, insurers and boards.
• PCI DSS v4.x payment page security requirements took effect on 31 March 2025. Even merchants on the short SAQ A form must now confirm their site is not susceptible to script attacks, so any donation page that loads third-party JavaScript needs a script inventory.
• Recent incidents that reached nonprofit software were third-party events: a backdoored compression library, a compromised GitHub Action, an npm worm and a campaign against CRM tenants through connected apps.
• The 90 day plan: inventory in month one, rules and vendor tiers in month two, evidence and a rehearsed incident in month three.
• Safeguard capabilities used here, all GA: SBOM generation and analysis, SCA, vulnerability management, reachability analysis, policies and gates, autonomous remediation (ships switched off), TPRM, the Compliance and GRC suite, Trust Center, the CLI and local runner, and Gold Open Source.

What software nonprofits and NGOs run

From a three person food pantry to an international humanitarian agency, the system types repeat, and almost all hold personal data about donors, clients, beneficiaries or volunteers.

Why the supply chain is wide here

Three things make the nonprofit supply chain wider than its budget suggests.

First, most software is bought or donated, and the purchase decision often sits with a program or fundraising team, not with IT. A department adopts a tool on a free plan, connects it to the CRM with an API key, and it never appears on a vendor list.

Second, a lot of code is written by people who leave. An agency builds the website, a volunteer writes the CRM import script, a grant funds a developer to build a field app. When the work ends, the code keeps running on the dependencies it had on the last day.

Third, many organizations are suppliers themselves. NGOs publish open source tools, foundations host projects the world builds on, and federated networks push shared software to their chapters. When you ship software, you inherit the job of saying what is inside it.

The regulations and frameworks that apply

US rules lead here. International NGOs will also meet EU and other national law; we mention the EU Cyber Resilience Act only as context because it has a specific provision for nonprofits that steward open source.

None of these rules uses the phrase "software supply chain" as a stand-alone obligation for nonprofits. They reach it through three routes: protecting personal information, managing service providers, and conditions attached to money you accept.

Federal awards: 2 CFR 200.303

If you receive federal grants or cooperative agreements, directly or as a subrecipient, 2 CFR 200.303 sets internal control rules for the award, including an explicit line: paragraph (e) requires recipients and subrecipients to take reasonable cybersecurity and other measures to safeguard information, including protected personally identifiable information.

The text prescribes no control set; it says "reasonable". A software and vendor inventory, a patch process with owners and an incident plan are the kind of documentation that lets a single auditor or grants officer see what you do. Individual awards can add their own security terms, so read your notice of award too.

State data security and breach notification laws

State breach and data security laws often apply to any entity holding residents' personal information, nonprofit or not. Massachusetts is the clearest example. The state's data security regulation, 201 CMR 17.00, applies to any person who owns or licenses personal information about a Massachusetts resident, and its definition of "person" covers corporations, associations and other legal entities. It requires a written information security program, and section 17.03(2)(f) requires taking reasonable steps to select and retain third-party service providers capable of protecting that information and requiring those protections by contract.

New York's SHIELD Act, General Business Law section 899-bb, requires any person or business that maintains private information of New York residents to adopt administrative, technical and physical safeguards. The New York Attorney General's summary lists, among the administrative safeguards, selecting service providers capable of maintaining appropriate safeguards and requiring those safeguards by contract.

Most comprehensive state consumer privacy laws exempt nonprofits, but not all do, and the list changes each legislative session. Ask counsel which laws reach you in every state where you have significant donors, clients or staff.

PCI DSS for card donations

If you accept card donations, the Payment Card Industry Data Security Standard reaches you through your merchant agreement, even when a processor handles the card data. The PCI Security Standards Council says 51 of the 64 new requirements in version 4.0 were future-dated and became effective on 31 March 2025. Two of them, which the Council calls e-commerce payment page security requirements, are about the supply chain of your donation page: Requirement 6.4.3 covers the scripts that run on a payment page, and Requirement 11.6.1 covers detecting unauthorized changes to payment pages.

In January 2025 the Council removed 6.4.3 and 11.6.1 from Self-Assessment Questionnaire A, the short form for merchants that fully outsource card handling, and replaced them with an eligibility criterion: the merchant must confirm its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The Council was explicit that this changes how merchants report, not the underlying requirements.

A donation page that loads an analytics tag and a chat widget has two suppliers next to the card flow. Your acquirer or payment facilitator, not the Council, sets which questionnaire you use.

HIPAA for health and human services programs

Community health centers, behavioral health providers, some social service agencies and many hospital foundations are HIPAA covered entities or business associates. Under the Security Rule, section 164.314 requires business associate contracts in which the vendor agrees to comply with the rule and to bind its own subcontractors. If your programs touch health data, your vendor list needs a column for "signed business associate agreement".

NIST frameworks you can borrow

• NIST Cybersecurity Framework 2.0 (26 February 2024) includes a Govern function with a Cybersecurity Supply Chain Risk Management category, GV.SC, starting from GV.SC-01: a supply chain risk management program, strategy, objectives, policies and processes agreed by organizational stakeholders. NIST says it can be used by any organization regardless of size, sector or maturity.
• NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, describes practices for producing software securely, including collecting and sharing provenance data for all components of each release, for example in an SBOM (PS.3.2), and identifying and confirming vulnerabilities on an ongoing basis (RV.1). It fits any nonprofit that builds and ships its own apps.

SBOMs: CISA's 2026 minimum elements

A software bill of materials (SBOM) is the ingredient list for software. CISA published its 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026, replacing the 2021 NTIA list as the US reference for what an SBOM should contain. A small nonprofit need not publish SBOMs, but should be able to produce one for software it builds. Our post on whether a small nonprofit needs an SBOM covers the smaller case.

CISA's guidance for civil society

On 14 May 2024 CISA and partners published joint guidance, "Mitigating Cyber Threats with Limited Resources: Guidance for Civil Society". CISA describes civil society, including nonprofit, advocacy, cultural, faith-based, academic, journalist, dissident and diaspora organizations, as high-risk communities often targeted by state-sponsored threat actors. The guide gives organizations and individuals recommended actions and mitigations, and it urges software manufacturers to commit publicly to Secure by Design practices. That second half is a supply chain point: a small organization's security depends heavily on the defaults its vendors ship.

Context for international NGOs: the EU Cyber Resilience Act

The EU Cyber Resilience Act entered into force on 10 December 2024; reporting obligations apply from 11 September 2026 and the main obligations from 11 December 2027, according to the European Commission. It creates the open-source software steward: per the Commission, a legal person that does not place free and open source products on the market but provides systematic, sustained support for their development, where they are intended for commercial activities. Many open source foundations are nonprofits that may fit. The Commission summarizes the Article 24 steward obligations as a cybersecurity policy for secure development and vulnerability handling, cooperation with market surveillance authorities, and reporting of actively exploited vulnerabilities and severe incidents; stewards are not subject to administrative fines. Nonprofits that only use open source are not stewards.

What funders, insurers and boards ask

Much of the real pressure is contractual: funder due diligence questionnaires, cyber insurance renewal forms and board questions after a peer's incident. None is regulation, but each arrives with a deadline. We wrote separately about answering a funder security questionnaire and the cybersecurity questions board directors should ask.

Real public incidents from the last three years

These come from official advisories. We draw no conclusions beyond what the sources say. None is specific to nonprofits; all reached software nonprofits run.

A backdoor in a volunteer-maintained library (March 2024)

On 29 March 2024 CISA reported that malicious code had been embedded in versions 5.6.0 and 5.6.1 of XZ Utils, a data compression library shipped in many Linux distributions, tracked as CVE-2024-3094. CISA recommended that developers and users downgrade to an uncompromised version, such as XZ Utils 5.4.6 Stable, hunt for any malicious activity and report positive findings to CISA.

The relevance for this sector is less the specific library than the pattern: a small, widely reused component, deep in the stack, that few of its users knew they ran. Nonprofits build on community-maintained open source every day, and many maintain open source projects themselves. The practical question after an event like this is simple and often hard to answer: which of our servers, images and apps have that version?

A compromised GitHub Action (March 2025)

In March 2025 CISA reported that tj-actions/changed-files, a third-party GitHub Action that detects which files changed in a pull request or commit, had been compromised, tracked as CVE-2025-30066. According to CISA, the compromise allowed disclosure of secrets including valid access keys, GitHub personal access tokens, npm tokens and private RSA keys, and was patched in v46.0.1. CISA added that the compromise was potentially enabled by the compromise of another Action, reviewdog/action-setup@v1, tracked as CVE-2025-30154. One build tool's compromise led to another's.

Many volunteer-built nonprofit repositories run GitHub workflows copied from examples. A workflow that references a third-party Action by tag rather than commit hash takes whatever the tag points to on the day it runs.

A self-replicating worm in the npm registry (September 2025)

On 23 September 2025 CISA warned of a widespread compromise of the npm registry, the main source of JavaScript packages. A self-replicating worm publicly known as Shai-Hulud compromised more than 500 packages, according to CISA. After gaining access, the malicious code harvested credentials and used them to publish compromised versions of further packages. CISA advised reviewing dependencies for affected packages, rotating developer credentials, pinning dependency versions to known safe releases and enabling phishing-resistant multifactor authentication on developer accounts.

Donation sites, volunteer portals and many mobile apps depend on npm, and an agency build server or a volunteer's laptop with publishing rights holds exactly the kind of credential the worm sought.

Data theft from CRM tenants through connected apps (2025)

On 12 September 2025 the FBI published a FLASH alert on two criminal groups it tracks as UNC6040 and UNC6395, which compromised organizations' Salesforce instances for data theft and extortion. According to the FBI, UNC6040 has since October 2024 used voice phishing, posing as IT support, to trick employees into authorizing malicious connected apps, often a modified version of a data loading tool, which then pulled data out in bulk through API queries. UNC6395, in August 2025, used compromised OAuth tokens for a third-party chatbot application integrated with Salesforce; the FBI says those tokens were revoked on 20 August 2025. Among its recommendations: review all third-party integrations and, for each application, rotate API keys, credentials and authentication tokens.

Many nonprofits run their donor CRM on a platform with an app marketplace, and every integration is a third party with standing access to the donor file. This incident is about those connections, not a vulnerability in the CRM itself.

Why a 2020 fundraising vendor breach still shapes contracts

The breach the sector remembers best happened in 2020 at a fundraising software vendor, outside our window. It still drives breach notice, retention and audit clauses in donor CRM contracts; we covered it in nonprofit software supply chain risk in 2026.

What the incidents have in common

Each event entered through something the affected organizations did not write: a library, a build tool, a package registry or a connected app. In each case the first question was an inventory question (do we run it, where, which version, which tokens does it hold), and the official advice involved rotating credentials and restricting what third parties can change. An organization that can answer in an hour has a manageable week. One that has to ask a departed volunteer does not.

The personas who own the problem

In a nonprofit several of these roles are often one person, and some are outsourced. Name a person for each row anyway.

Where the work collides

The executive director and board do not need component lists. They need the five vendors that would hurt most if breached, whether each has security terms in its contract, and proof the incident plan was tested.

The CFO or finance director is often the de facto supply chain owner, because finance holds the contracts, the insurance and the grant compliance file. The deadline is the single audit, the award acceptance or the renewal date.

The IT director or managed service provider will do the patching. If IT is outsourced, the contract should say who watches for vulnerabilities in software you build or commission, because many providers cover devices and productivity suites only.

The CRM lead controls which apps can read the donor file and needs a current list of every installed package, connected app and integration token, with who approved it. The 2025 FBI alert is the reason this matters now.

The digital or engineering lead, whether staff, agency or volunteer, owns the code after the last commit: an SBOM per app, a CI check, pinned build tools and a handover rule. The privacy lead and the program lead for field and client systems need to know which vendors process the most sensitive data, under what contract, and how fast each will report a breach.

Step by step: a 30, 60 and 90 day plan that works with any tools

This plan assumes one owner with a few hours a week, help from IT or a managed service provider, and access to whoever maintains your code. A spreadsheet is enough to start.

Days 1 to 30: see what you run

1. Name the owner and the deputies. Write one line per persona from the table above with a real name, even if names repeat. Put the list in the incident plan.
2. List every system that holds personal data. Start from finance (what we pay for), the sign-on console (what has access) and the CRM's installed apps page. Record the vendor, the data it holds, the owner and the contract renewal date.
3. Tier the vendors. Critical: holds donor payment data, client health or case data, or the full donor file. High: holds personal data in bulk. Medium and Low: everything else.
4. List the code you own. Every repository, website, mobile app, low-code app and integration script, including the ones an agency or volunteer built. Find the lock files (package-lock.json, yarn.lock, poetry.lock, composer.lock, Gemfile.lock and the like).
5. Generate an SBOM for each. Use any SBOM generator that outputs SPDX or CycloneDX. For a hosted CMS, list the core version, theme and every plugin with its version.
6. Inventory your donation page scripts. Open the payment page, list every script it loads, and write down why each is there. Remove any without a reason. This is the start of PCI DSS requirement 6.4.3.
7. Inventory connected apps on the CRM and productivity suite. Record each app, its permissions and who approved it. Remove anything nobody can explain.
8. Run a first vulnerability scan against every SBOM and sort by whether the vulnerability is on CISA's Known Exploited Vulnerabilities catalog, then by EPSS score, then by severity.

Days 31 to 60: control what changes

9. Set a patch clock. Write down how fast each class of vulnerability is fixed, and get the executive director to sign it. A starting point that a small team can keep:

These are illustrative numbers. Pick ones you will meet.

10. Put a check in the build. In each repository's CI, fail the build on known exploited or critical vulnerabilities with a fix available, and warn on the rest. Start in report-only mode for two weeks so the first run does not block a release.
11. Pin build tools and Actions. Reference third-party CI actions by commit hash. Pin dependency versions in lock files and commit them. Turn on multifactor authentication for every account that can publish code or packages.
12. Write security terms into critical vendor contracts at renewal. Breach notice within set hours, a security contact, a subprocessor list, the right to an SBOM or security report, and audit support. Massachusetts and New York already expect contract terms for service providers.
13. Set the handover rule. No agency, contractor or volunteer project is accepted without a repository you control, a lock file, build instructions, an SBOM and two named maintainers.
14. Send vendor questionnaires to critical vendors only. Ask for their latest independent audit report, how they track open source components, how fast they patch known exploited vulnerabilities, and how they notify customers.

Days 61 to 90: prove it works

15. Rehearse an incident. Use one of the incidents above. Time the answers: do we run it, where, who owns it, what could it reach, who must we notify.
16. Write the one page board summary. Critical vendors and contract status, KEV findings open past the clock, the rehearsal result, and the top risks you accept.
17. Assemble the evidence folder. Inventory, SBOMs, patch clock, exception register, vendor contracts and questionnaires, rehearsal notes. This is what you hand a single auditor, a funder or an insurer.
18. Schedule the rhythm. Weekly vulnerability triage for 30 minutes, quarterly vendor review for critical vendors, annual review for the rest, and a re-run of the inventory before each budget cycle.

Illustrative scenario: a library advisory during a year-end campaign

This is an illustrative scenario. It is late December, the busiest fundraising fortnight of the year. A critical vulnerability is published in an image processing library and added to the KEV catalog the next day. A search across the SBOMs from step 5 finds it in the donation site's build (upgrade available) and a field data collection server (no upgrade yet).

The patch clock in step 9 says seven days because both systems hold donor or beneficiary data. The donation site is upgraded through the normal release process and the CI check from step 10 confirms the fixed version. The field server cannot be upgraded, so the IT director records a mitigation (image uploads disabled until the fix ships) in the exception register with a review date, and the executive director signs it. The January board summary shows one open exception with an owner and a date.

How Safeguard does this

Everything above works without Safeguard. This section shows the same plan in Safeguard, using only flows from docs.safeguard.sh. Every capability named here is generally available (GA). Commands are copied as the docs show them; we did not run them for this post.

1. Inventory the software you build

Safeguard's Enterprise Software Supply Chain Manager (ESSCM, GA) generates SPDX and CycloneDX SBOMs (SBOM generation and analysis, GA) and runs software composition analysis (SCA, GA) across each project's full transitive dependency tree. Per the docs, you connect repositories or container registries through Integrations, or upload files, and Safeguard creates the project and its SBOM.

If a cloud service may not clone your code, for example because a program's data sharing agreement restricts it, the local runner (GA) built into the Safeguard CLI (GA) runs scan jobs on your own machine and uploads only the SBOM and findings. The docs show:

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

# start the interactive terminal, then type /login
safeguard

For a server without a terminal UI, the docs show:

safeguard runner start --workspace ./path/to/repo
safeguard runner status

On-prem and fully air-gapped deployment (GA) and Zero AI mode (GA), which runs the platform with no large language model in the loop, suit NGOs whose agreements restrict where beneficiary data and code may go.

2. Prioritize by exploitation and reachability

Vulnerability management (GA) enriches findings with EPSS and CISA KEV status, and reachability analysis and prioritization (GA) adds whether your application calls the vulnerable code path. Together they fill the patch clock table from step 9. License compliance (GA) helps NGOs that publish open source tools.

3. Turn the patch clock into policies and gates

Policies, gates and guardrails (GA) put the clock into the pipeline. Per the docs, you go to Settings › Policies, click Create Policy, define conditions (severity, CVSS, EPSS, license, component age, maintenance) in the visual builder or YAML, and set severity and actions.

Each policy has one action that decides what a failure does to the gate:

A small team might Block KEV-listed or critical findings with a fix in the donation site and client systems, Warn on high and Notify on the rest. The docs show this GitHub Actions workflow:

name: Safeguard
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - 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

Drop --fail-on critical for report-only mode in the first weeks, which matches step 10. The key is created under Settings › Developer with the scans:trigger and scans:read scopes. Policy outcomes are switched on per workspace, so confirm yours first.

4. Run exceptions through a recorded approval

Approval runs through exceptions. Per the docs, a developer clicks Request Exception, selects the policy and finding, gives a justification and an expiration date, and submits; approvers decide and the audit trail records it.

For findings you will not fix yet, the Mitigations tab records the type (Risk Acceptance, False Positive, Workaround Applied or Not Applicable), justification, approver, an optional expiry for risk acceptances, and evidence. That is the exception register from the illustrative scenario, kept in one place.

5. Fix faster where a fix exists

Autonomous remediation (GA) opens fix pull requests that move a vulnerable dependency to a fixed version, singly or in bulk. It ships switched off, with every category set to Manual, so nothing changes until your team turns it on.

6. Bring vendors inside the clock with TPRM

Third-Party Risk Manager (TPRM, GA) is where the CFO or vendor owner keeps the register. Per the docs:

1. Vendors › Add Vendor records the company, contact, products used and risk tier (Critical, High, Medium, Low), with CSV bulk import for a register that started in a spreadsheet.
2. Request SBOM, or Bulk Request for many vendors, sets the SBOM format (SPDX or CycloneDX) and a deadline, with automatic reminders.
3. Each request shows its status, ending as Validated when the SBOM is verified or Rejected when it is not.
4. Continuous monitoring alerts on critical vulnerabilities and CISA KEV additions that affect a vendor.

Not every donor CRM vendor will send an SBOM; the register still records that you asked and what came back.

7. Keep grant and audit evidence in one place

The Compliance and GRC suite (GA) holds frameworks, controls, evidence and tests. Per the docs, the framework library spans national data protection, cybersecurity and sector laws plus standards such as PCI DSS, and each framework page says which requirements a scan decides and which need your own evidence. For the HIPAA Security Rule, PCI DSS and NIST CSF 2.0, among others, it also maps automated tests from the systems you connect. Portal audit trails (GA) log activity and export as CSV, JSON or a formatted PDF report for the evidence folder in step 17.

8. Answer funders and partners once

Trust Center (GA) publishes a page with your security posture, policies, subprocessors and documents. Per the docs, you manage it on Compliance › Trust Center and publish explicitly; nothing goes live on its own. It suits an NGO that answers the same funder questionnaires every grant cycle.

What Safeguard does not do

• It does not inventory your donation page scripts or detect changes to them. PCI DSS requirements 6.4.3 and 11.6.1 are about the scripts on a live payment page and unauthorized changes to it. Safeguard scans the components in code you build; script management and change detection on a live payment page are separate controls, usually provided by your payment processor or a dedicated mechanism.
• It does not review CRM connected app permissions. The 2025 FBI alert is about apps and tokens inside a CRM tenant. Reviewing and restricting those is work in the CRM's own admin console.
• It does not patch vendor-hosted systems. When the vulnerable code sits inside a hosted donor CRM, grant platform or case management system, the fix has to come from that vendor. TPRM helps you track and chase it.
• It does not decide legal obligations. Whether a law or award term applies and whether an incident triggers notification are decisions for counsel and leadership, and your single auditor or PCI assessor reaches its own conclusions.
• It does not replace identity and device controls. Multifactor authentication, account offboarding for volunteers and staff, device management and backups are separate controls you still run.

Common mistakes

• Treating "hosted" as "someone else's problem". A hosted vendor holds your donors' data under your name. The contract and the vendor register are your controls.
• Inventorying vendors but not code. The website and the integration scripts are often the least maintained software in the building, and the agency or volunteer who wrote them is gone.
• Ignoring the payment page because the processor is compliant. A compliant processor does not cover the scripts your own page loads around its form.
• Setting a patch clock nobody can meet. A clock you miss every month teaches everyone to ignore it. Start slow and tighten.
• Blocking builds on day one. Run checks in report-only mode first, fix the backlog, then switch the most important rule to Block.
• Accepting volunteer and agency projects without a handover. No lock file, no build instructions and no maintainers means no way to patch.

FAQ

What is software supply chain security for a nonprofit?

It is knowing which third-party code and vendors handle your donor, client and beneficiary data, knowing when one has a known problem, and having a named person and a deadline to deal with it.

Do nonprofits have to comply with cybersecurity regulations?

Yes, in several ways, even though there is no single nonprofit cybersecurity law. Federal award recipients must take reasonable cybersecurity measures under 2 CFR 200.303(e). State breach laws and some state security and privacy laws apply to nonprofits. PCI DSS applies to card donations and HIPAA to health programs. Ask counsel which apply to you.

Does PCI DSS apply if our payment processor hosts the donation form?

PCI DSS applies to any merchant accepting cards, including nonprofits, but the scope depends on how the form is delivered. If your own page embeds the processor's form, requirements on payment page scripts may apply to your page. Your processor and acquirer will tell you which self-assessment questionnaire to use.

Does 2 CFR 200.303 require specific security controls?

No. Paragraph (e) requires reasonable cybersecurity and other measures to safeguard information, including protected personally identifiable information. Individual awards can add specific terms, so read your notice of award.

Does a small nonprofit need an SBOM?

You do not need to publish one. You should be able to produce one for software you build or commission, so that you can answer "do we run this?" in an hour when an advisory lands. Asking critical vendors for an SBOM or an equivalent component report is reasonable but not always successful.

What should we ask our donor CRM vendor about supply chain security?

Ask for their latest independent audit report, how they track open source components, how fast they patch known exploited vulnerabilities, how they vet marketplace apps, how fast they notify customers, and whether they can provide an SBOM.

Are NGOs that host open source projects affected by the EU Cyber Resilience Act?

Possibly. The Act's open-source software steward role covers a legal person that provides systematic, sustained support for free and open source products intended for commercial activities without placing them on the market itself. Stewards carry lighter obligations in Article 24 and are not subject to administrative fines. Organizations that only use open source are not stewards. EU counsel should confirm your position.

Can Safeguard scan our code without sending it to the cloud?

Yes. The local runner built into the Safeguard CLI runs scans on your own machine and uploads the SBOM and findings rather than cloning your code. On-prem and air-gapped deployment and Zero AI mode are also available. All are GA.

The open source dependencies in your own donation site, apps and integration scripts are the part of this supply chain you can fix yourself, without waiting for a vendor's release. The section below explains how Safeguard closes the gap between a published vulnerability and a fixed build.

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: ask "fix the lodash CVE in this repo", and the CLI 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, and pushes nothing. A volunteer maintaining a donation site would use the same flow on that site's repository.

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 its device code, and scans from the terminal. It is the route for NGOs whose partner or data sharing agreements do not allow a cloud service to clone program code.

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 chooses which tools Claude can use. A finance director preparing a board summary could use the same connection to ask about open findings in plain language.

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

Quick check

Related reading

• Nonprofit software supply chain risk in 2026
• Nonprofit security: the first 90 days with no IT staff
• Do we need an SBOM? A small nonprofit with a website or app
• Answer a funder security questionnaire
• Cybersecurity questions for nonprofit board directors

Sources

• eCFR: 2 CFR 200.303 Internal controls
• 201 CMR 17.02 Definitions (Massachusetts), via Cornell LII
• 201 CMR 17.03 Duty to protect and standards (Massachusetts), via Cornell LII
• New York State Attorney General: SHIELD Act
• eCFR: 45 CFR 164.314 Organizational requirements
• PCI SSC: Now is the time to adopt the future-dated requirements of PCI DSS v4.x
• PCI SSC: Important updates announced for merchants validating to SAQ A (30 January 2025)
• NIST CSWP 29: The NIST Cybersecurity Framework (CSF) 2.0
• NIST SP 800-218: Secure Software Development Framework version 1.1
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Mitigating Cyber Threats with Limited Resources: Guidance for Civil Society
• European Commission: Cyber Resilience Act
• European Commission: Cyber Resilience Act and open source
• CISA: Reported supply chain compromise affecting XZ Utils, CVE-2024-3094 (29 March 2024)
• CISA: Supply chain compromise of third-party tj-actions/changed-files, CVE-2025-30066
• CISA: Widespread supply chain compromise impacting npm ecosystem (23 September 2025)
• FBI FLASH-20250912-001: UNC6040 and UNC6395 compromising Salesforce instances (PDF)
• Safeguard docs: Policies and gates
• Safeguard docs: Policy outcomes
• Safeguard docs: GitHub Actions
• Safeguard docs: Local runner
• Safeguard docs: Generate an SBOM
• Safeguard docs: Mitigations
• Safeguard docs: Third-Party Risk Management
• Safeguard docs: TPRM vendor management
• Safeguard docs: TPRM SBOM requests
• Safeguard docs: TPRM monitoring
• Safeguard docs: Compliance
• Safeguard docs: Portal audit trails
• Safeguard docs: Trust Center
• Safeguard docs: Air-gapped deployment

To try the flows in this guide, 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.