Software Supply Chain Security for Water Utilities: A 90-Day Plan

A water utility secures its software supply chain by knowing which products, firmware, integrator setups and in-house code run its plants, asking suppliers for component lists and fix commitments, and tracking known exploited flaws in all of it. The rule behind most of this in the United States is Safe Drinking Water Act section 1433, which requires larger community water systems to assess their "electronic, computer, or other automated systems" and recertify every five years. The July 2026 attacks on internet-facing controllers show why the supply side matters: the FBI and EPA noted that similar third-party network setups let attackers repeat the same success across many victims.

This guide is for the general manager, IT or security lead, SCADA manager, AWIA certification owner and purchasing office at a drinking water or wastewater utility. The first two thirds work with any tools, or none.

Key takeaways

• The legal floor is SDWA section 1433. Community water systems serving more than 3,300 people must assess risk and resilience, including the security of automated systems, and certify to EPA every five years. The second cycle runs through 2025 and 2026, with the last risk assessment deadline on 30 June 2026 and the last emergency response plan deadline on 31 December 2026.
• Enforcement is real. EPA's May 2024 enforcement alert said over 70% of systems it inspected since September 2023 violated basic section 1433 requirements.
• The incidents point at the supply chain. From the 2023 attacks on a widely used line of controllers to the July 2026 wave against internet-exposed PLCs, attackers went after products and common integrator setups, not one utility at a time.
• Procurement is the lever small utilities actually control. CISA's January 2025 Secure by Demand guide for OT buyers gives twelve product-selection elements, including asking for hardware and software bills of materials with delivery.
• SBOM expectations changed in July 2026. CISA's 2026 Minimum Elements for an SBOM revise the 2021 NTIA baseline; ask suppliers for that version.
• A 30/60/90-day plan works with any budget. Inventory first, then vendor asks, then gates and contract language.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis (GA), software composition analysis (GA), vulnerability management with EPSS and CISA KEV (GA), reachability analysis (GA), the Third-Party Risk Manager with SBOM requests, risk scoring and monitoring (GA), CSAF and VEX upload (GA), policies and gates (GA), autonomous remediation (GA, ships switched off), the Safeguard CLI and local runner (GA), on-prem and air-gapped deployment (GA) and Zero AI mode (GA).

The situation

Picture the week a water utility's leadership starts asking about software. It is usually one of four triggers.

The first is the AWIA calendar. A utility that certified its first risk and resilience assessment in 2020 or 2021 must recertify in the 2025 and 2026 cycle, and whoever owns that certificate needs an honest answer about the controllers, remote access paths and vendor software the law's "automated systems" language covers.

The second is an advisory. On 30 July 2026, CISA urged the water and wastewater sector to protect operational technology against a sharp rise in activity targeting PLCs, and the FBI and EPA issued a joint public service announcement the same day. A board member forwards the news story and asks a simple question: are we exposed?

The third is a contract: a SCADA upgrade or metering system is out to bid, and the request for proposals says nothing about the software inside the product, who patches it, or how remote support connects.

The fourth is an inspection or a grant application, where EPA inspectors or a grant program ask what the utility has actually done about cybersecurity.

A bad week looks like this: an integrator's cellular modem nobody had on the asset list, a controller still on its default password, a historian on an unsupported operating system, and a vendor who cannot say what open source sits inside its HMI. All of these are supply chain problems, because the utility bought them, inherited them or had them installed by someone else.

What software a water utility runs

Water and wastewater utilities run a mix of plant control systems, business systems and field devices. Most of it is bought, configured by an integrator and supported remotely by a vendor. Larger utilities also write their own code: integrations, data pipelines, customer portals and scripts. Each of these is part of the software supply chain.

Two features set the water sector apart. Most of the code is closed and bought, so the utility can only ask for transparency, track what is disclosed and choose suppliers who patch. And much of the riskiest equipment is installed and maintained by third parties. The FBI and EPA made exactly that point in July 2026, noting that similarities in network setups provided by third parties may let attackers "multiply successes" across customers.

If your utility writes even a handful of scripts that move data from the historian to a reporting tool, treat them as software you ship; they pull open source packages with vulnerabilities like anyone else's.

The regulations and frameworks that apply

This section summarises the rules from the primary sources. It is not legal advice; your state primacy agency, your counsel and EPA's own guidance are the authority on how they apply to your system.

SDWA section 1433, as amended by AWIA section 2013

America's Water Infrastructure Act of 2018 amended section 1433 of the Safe Drinking Water Act. According to EPA, community water systems serving more than 3,300 people must develop or update a risk and resilience assessment (RRA) and an emergency response plan (ERP), and certify completion to EPA by set deadlines.

The RRA must cover, among other things, the risk from malevolent acts and natural hazards and the resilience of "electronic, computer, or other automated systems (including the security of such systems)." The ERP, due within six months of the RRA certification, must include strategies and resources to improve resilience, explicitly including cybersecurity.

Systems must review the RRA and ERP every five years, revise them where needed and recertify. EPA's published deadlines for the current cycle are:

EPA notes that the ERP dates assume an RRA submitted on its final due date. Systems serving 3,300 or fewer people are not required to certify, though EPA provides guidance and technical help for them.

Section 1433 never says "software bill of materials," but you cannot assess the security of systems you have not listed, or judge a SCADA platform's resilience without knowing its support status, its known exploited vulnerabilities and who can connect to it. A software and firmware inventory is the most direct way to make the cyber section of an RRA defensible.

EPA enforcement and the rescinded sanitary survey memo

In May 2024 EPA issued an enforcement alert stating that over 70% of systems it had inspected since September 2023 were in violation of basic section 1433 requirements, including missing sections of the RRA and ERP. Inspectors reported utilities that had not changed default passwords, used single logins for all staff, or had not removed access for former employees. The alert lists actions from the joint EPA, CISA and FBI "Top Actions for Securing Water Systems," including conducting an inventory of OT and IT assets and reducing exposure to vulnerabilities.

A Congressional Research Service In Focus dated 27 August 2026 adds context. It records that EPA took at least 100 enforcement actions for section 1433 violations between 2020 and 2024, and that EPA's Office of Inspector General identified 97 systems serving about 26.6 million people as having critical or high risk cybersecurity vulnerabilities in a 2024 assessment of 1,062 large systems. It also records that EPA's March 2023 memorandum asking states to review operational technology cybersecurity during sanitary surveys was rescinded in October 2023 after a legal challenge. As of the CRS report, there is no general federal cybersecurity standard for water systems beyond section 1433.

Wastewater

CRS notes that federal water cybersecurity efforts have focused on drinking water rather than wastewater. Section 1433 applies to community drinking water systems. Wastewater utilities face the same threats, and several bills in the 119th Congress would add wastewater programs, but those are proposals, not law. Check your state's rules; some states impose their own requirements.

Grants and assistance in law

The Infrastructure Investment and Jobs Act added SDWA section 1459F, a grant program for systems serving 10,000 or more people to reduce cybersecurity vulnerabilities, and section 1420A, which requires EPA and CISA to develop a framework for identifying high impact systems and a technical cybersecurity support plan. It also made cybersecurity events an emergency situation under section 1442(b). These matter for planning: they are where money and help come from, especially for small systems.

Pending legislation

The CRS report lists several bills, including the Water Resources Development Act of 2026 (S. 4949), which would reauthorize section 1459F and authorize a wastewater cybersecurity grant program. Others would revise section 1433 or create an independent standards body. None was law at the time of the CRS report, so plan to the current statute.

CISA Secure by Demand for OT buyers

On 13 January 2025, CISA and partners including EPA, the FBI, NSA and TSA published "Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products." It argues that threat actors target specific OT products rather than specific organizations, and gives buyers twelve elements to prioritise: configuration management, logging in the baseline product, open standards, ownership, protection of data, secure by default, secure communications, secure controls, strong authentication, threat modelling, vulnerability management, and upgrade and patch tooling.

The vulnerability management element is the one most relevant here. It tells buyers to seek manufacturers who include hardware and software bills of materials with product delivery and commit to timely remediation through a vulnerability disclosure program. The secure by default element asks for no default passwords and insecure protocols disabled by default. For a utility, this document is the best available template for procurement language.

CISA 2026 Minimum Elements for an SBOM

On 29 July 2026 CISA and partners published the 2026 Minimum Elements for a Software Bill of Materials, a revision that builds on the 2021 NTIA minimum elements. CISA's announcement lists new elements such as component hash algorithm, component license, SBOM tool name and SBOM generation context, and renames others; supplier name becomes component producer. If you ask a vendor for an SBOM, ask for one that meets the 2026 elements in SPDX or CycloneDX, and treat the older NTIA list as history.

NIST frameworks

Three NIST documents are useful scaffolding.

• NIST Cybersecurity Framework 2.0 (released February 2024) added a Govern function with a cybersecurity supply chain risk management category, GV.SC. Many utilities already map to the CSF, and it is a natural home for supplier requirements.
• NIST SP 800-161 Rev. 1, with updates as of 1 November 2024, is the detailed guide to cybersecurity supply chain risk management. It is heavy for a small utility, but its scoping questionnaire is a useful checklist.
• NIST SP 800-82 Rev. 3 (September 2023) is the guide to OT security. NIST posted an initial public draft of Rev. 4 with comments due 30 November 2026, so expect updates.

EPA tools for the cyber section of the RRA

EPA's AWIA page points utilities to its Cybersecurity Checklist, the Water Cyber Assessment Tool and free assessments through the Water Sector Cybersecurity Evaluation Program, alongside the Vulnerability Self-Assessment Tool for larger systems and a small system RRA checklist. These are the usual starting points for the cyber section of an assessment.

Real public incidents from the last three years

The incidents below come from government advisories, a federal securities filing and local reporting. They are summarised as the sources state them, with no judgement about what any utility should have done.

What the July 2026 wave tells us

The July 2026 activity is the clearest supply chain lesson in the set. CISA said the activity had led to boil water notices and sustained manual operations. The FBI and EPA reported operational effects including loss of pressure and flooding. CISA also warned that targeting included cellular modems installed by operators, vendors or integrators that "may not be documented" in routine scans.

The FBI and EPA added a detail every purchasing officer should read twice: across several victims, similarities in network setup provided by third parties may have let the attackers repeat their success. That is the supply chain in plain terms. A utility's exposure was partly decided by how an integrator or vendor installed equipment, and the same pattern was repeated at other customers.

The 2023 campaign shows the product side. AA23-335A notes that the targeted PLCs may be rebranded under other manufacturers' names, so a utility can own an affected device without recognising the brand on its asset list. That is a strong argument for asking vendors what is inside what they sell you.

What the IT-side incidents add

The Arkansas City, American Water and Minot incidents involved computers and servers rather than controllers, and in each the public statements stress that water stayed safe. Those servers run commercial and open source software with their own patch cycles, so they belong in the same inventory and the same KEV check.

The personas who own the problem

Water utilities are small organizations. One person often wears several of these hats, and city IT may be shared with the utility. Here is who usually owns which part, what they need, and when they need it.

What each of them needs to hear

The general manager needs three numbers to repeat to the board: control system assets reachable from the internet (the right answer is zero), critical systems running software with known exploited vulnerabilities, and key vendors that have committed to a support period and a disclosure process. They also need to know how long the plant can run manually, because most of the incidents below ended in manual operation.

The IT or security lead carries the inventory. Their bad day is an advisory naming a product family and not knowing whether the utility owns it, so they need each system mapped to vendor, version, operating system and support status, checked against CISA's KEV catalog as it changes.

The SCADA or OT manager owns safety and uptime and will rightly resist anything that touches a running controller without a plan. They need clarity on firmware versions, integrator access paths and modem locations, plus a verified backup of each PLC program.

The AWIA certification owner needs evidence that the automated systems section of the RRA reflects reality. A software and firmware inventory, a vendor question log and a dated list of mitigations are the most useful attachments they can have. The purchasing owner needs short, standard contract language for every OT and IT solicitation, and a habit of asking again at renewal. Developers at larger utilities need dependency scanning in the pipeline and a fast path to fix what it finds.

Small-utility constraints and what is free

CRS records that EPA classifies 81% of community water systems as small, serving 3,300 or fewer people. These systems are not required to certify RRAs, and many have no dedicated IT staff. A supply chain programme for them has to fit in a few hours a month.

What is free today, according to EPA and CISA:

• EPA Water Sector Cybersecurity Evaluation Program. A third-party contractor runs a free assessment using EPA's Cybersecurity Checklist and returns an assessment report and a risk mitigation plan template.
• EPA Water Cyber Assessment Tool (WCAT). A self-assessment workbook based on the same checklist.
• EPA Cybersecurity Technical Assistance. A request form for direct help.
• CISA Cyber Hygiene Services. EPA's enforcement alert lists these under free help, requested by email to CISA. CISA's service scans internet-facing systems for known vulnerabilities, which is a quick way to learn whether a controller or modem is visible from the internet.

The minimum viable supply chain programme for a small system is short: an asset list with vendor, model and firmware or version for every controller, HMI, modem and server; a contact at each vendor and integrator; one page of purchasing language; and a monthly check of the asset list against new KEV entries and CISA ICS advisories. Everything else in this guide is an extension of that.

Step by step: a 30/60/90-day plan

This plan works with or without any product. Each phase lists who leads it and what "done" looks like.

Days 1 to 30: see what you have

1. Check internet exposure first. Request CISA Cyber Hygiene scanning if you have not, and ask your integrators and vendors in writing for every remote access path and cellular modem they installed. The CISA July 2026 alert specifically warns that integrator-installed modems may be undocumented. Lead: IT or security lead with the SCADA manager.
2. Build the asset and software list. For every controller, HMI, server, workstation, modem and business system, record vendor, model, firmware or software version, operating system, support end date, owner and who has remote access. Lead: IT lead and SCADA manager.
3. Back up PLC programs. Take a verified clean copy of each PLC program and configuration, as the FBI and EPA recommend, and store it offline. Lead: SCADA manager or integrator.
4. Match the list against KEV and ICS advisories. Flag anything with a known exploited vulnerability or an expired support period. Lead: IT lead.
5. Scan the code you own. If you have in-house integrations, scripts or a customer portal, generate an SBOM for each repository and container image and record the vulnerable components. Lead: development or data team.

Done looks like: one list, owned by a named person, that the general manager can summarise in three numbers.

Days 31 to 60: ask your suppliers

1. Send a vendor question list (template below) to every OT vendor and integrator, and to the vendors of your billing, metering and lab systems. Lead: purchasing with the IT lead.
2. Collect SBOMs where they exist. Ask for SPDX or CycloneDX documents meeting CISA's 2026 minimum elements, and for vendor security advisories in machine readable form (CSAF) where offered. Many legacy OT products will not have an SBOM; record that answer, because it is information too.
3. Record vendor answers and gaps in a simple register: SBOM yes or no, support end date, disclosure programme yes or no, remote access method, default password policy.
4. Draft the ERP addendum for manual operation of each critical process, with the PLC backups and vendor contacts attached. Lead: AWIA certification owner with operations.

Done looks like: a vendor register with an answer, or a documented non-answer, for every critical supplier.

Days 61 to 90: make it stick

1. Adopt purchasing language for every new OT and IT solicitation, based on CISA Secure by Demand. Lead: purchasing.
2. Set a monthly review. New KEV entries and ICS advisories against the asset list, vendor SBOM refreshes, modem and remote access re-check. Lead: IT lead.
3. Add a dependency gate for in-house code, so a release with a known exploited, fixable vulnerability does not ship without a decision. Lead: development team.
4. Fold the results into the RRA evidence file and the next board or council update. Lead: AWIA certification owner and general manager.
5. Apply for help where it fits. Use the EPA assessment programme and check grant eligibility under section 1459F or state programmes. Lead: general manager.

Done looks like: the next RFP that goes out asks for an SBOM, and the next advisory takes hours, not weeks, to answer.

Template: vendor and integrator question list

Send this to every OT vendor, integrator and critical IT vendor. Keep the answers.

1. Which products, models and firmware or software versions have you supplied or installed at our sites?
2. Can you provide an SBOM for each, in SPDX or CycloneDX, meeting CISA's 2026 Minimum Elements? If not, when?
3. What is the defined support period for each product, and the date security fixes stop?
4. Do you run a vulnerability disclosure programme, and do you publish advisories in CSAF or another machine readable format?
5. Have default passwords been changed on everything you installed? How are credentials stored and rotated?
6. List every remote access path you use or installed, including cellular modems, VPNs and remote support tools. Who at your company can use them?
7. Is any of our equipment reachable from the internet as you configured it?
8. Do you use the same network design or credentials across multiple customers?
9. How will you notify us of a new vulnerability affecting our products, and how fast?
10. Can you provide a verified backup of each PLC program and configuration you maintain?

Template: purchasing language

Adapt these clauses with your counsel. They follow the Secure by Demand elements.

• The supplier shall deliver a software bill of materials in SPDX or CycloneDX format, meeting CISA's 2026 Minimum Elements, with each release and on request.
• The supplier shall state a support period for each product and provide security fixes free of charge during it.
• The supplier shall maintain a vulnerability disclosure programme and notify the utility of vulnerabilities affecting supplied products within an agreed number of days.
• Products shall ship with no default passwords and with insecure protocols disabled by default.
• Remote access shall be documented, approved by the utility, routed through a utility-controlled gateway and never made directly to a controller.
• The supplier shall not reuse credentials or network designs across customers in ways that expose the utility.

Decision table: a new vulnerability in something you run

How Safeguard does this

Safeguard can carry the inventory, vendor and code parts of the plan above. It does not replace OT network controls, and it cannot see inside a vendor's closed product unless the vendor supplies an SBOM. The steps below come from Safeguard's offering documentation and docs.safeguard.sh. Commands are shown as the docs show them; they were not run for this post.

1. Inventory the code and images you own with the Safeguard CLI (GA). SBOM generation and analysis (GA) and software composition analysis (GA) run from the command line. The docs show one target per scan:

   # A local directory
   safeguard scan --dir .
   # A container image
   safeguard scan --image myregistry.azurecr.io/myapp:v1
   # An SBOM you already have (SPDX or CycloneDX)
   safeguard scan --sbom sbom.json
   

   Results are written as JSON files under ./output. The docs note that safeguard scan does not fail on findings; gating is done by policy gates in the platform.

2. Scan on a restricted network with the local runner (GA). The runner is part of the CLI. Per the docs, it polls the platform over outbound HTTPS, runs scan jobs on your own machine and uploads only the SBOM and findings, never source code. That suits a utility whose code sits on a segmented network or whose policy forbids giving a cloud service repository access.

3. Load vendor SBOMs. SBOMs that vendors send can be uploaded through Integrations, using the Upload SBOM card, in CycloneDX or SPDX. Safeguard validates the document, enriches it with vulnerability data, EPSS scores, CISA KEV status and license information, and keeps monitoring it. To check a file locally first, the docs show safeguard validate sbom.json.

4. Request SBOMs from suppliers with the Third-Party Risk Manager (GA). In TPRM, open a vendor and choose Request SBOM, or select several vendors for a bulk request. The standard template asks for SPDX or CycloneDX with required fields. Requests move through Sent, Viewed, In Progress, Submitted, and Validated or Rejected, with automatic reminders before and after the deadline. A submitted SBOM is checked for format, completeness and required fields, then scanned for vulnerabilities. This is the vendor question list from days 31 to 60, tracked in one place.

5. Score and monitor vendors (GA). TPRM gives each vendor a 0 to 100 risk score, where higher is better, built from vulnerability, compliance, component and operational factors, including EPSS and KEV. Monitoring alerts on new critical vulnerabilities, KEV additions, risk score drops and SBOM expiry, by email, chat or webhook, and re-scans can run daily for critical vendors.

6. Import vendor advisories as CSAF and VEX (GA). The docs support CSAF 2.0 and VEX in CycloneDX, OpenVEX and CSAF profiles, uploaded through Integrations, so a vendor's "not affected" statement is recorded against the products it covers.

7. Prioritise with KEV, EPSS and reachability (GA). Vulnerability management (GA) enriches findings with EPSS and CISA KEV. For your own code, reachability analysis (GA) ranks the vulnerable paths your application actually calls, so a small team works on what matters first.

8. Gate releases of in-house code with policies and gates (GA). Policies are created under Settings, Policies, from a visual builder or YAML, with conditions such as vulnerability severity, EPSS and license. Each policy's action is Block, Warn or Notify. Exceptions go through an approval workflow with a justification, an expiry date and an audit trail. In CI, the docs show:

   safeguard ci scan --wait --fail-on-gate <gate>
   

   which fails the job when the gate fails, with policy outcomes turned on for the workspace.

9. Fix your own dependencies with autonomous remediation (GA, ships off). Griffin can open tested, policy gated pull requests that move a vulnerable dependency to a fixed version, for one repository or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own.

10. Keep everything inside your perimeter if you need to (GA). Safeguard supports on-prem and fully air-gapped deployment; the docs describe signed snapshot bundles of vulnerability feed updates delivered on a cadence from hourly to quarterly, including by one-way diode or signed removable media. Zero AI mode (GA) runs the platform with no LLM in the loop.

What Safeguard does not do

• It does not secure your controllers or networks. Removing PLCs from the internet, securing cellular modems, setting access control lists, changing default passwords and putting key switches in run mode are network and OT engineering tasks. Safeguard does not do them and does not monitor OT network traffic.
• It cannot inventory a closed vendor product on its own. For bought SCADA, HMI or firmware, Safeguard works from what the vendor provides: an SBOM, a CSAF advisory or a VEX statement. If a vendor supplies nothing, your vendor register records the gap; the product cannot fill it.
• It does not patch vendor firmware or appliances. Fixes for a vendor's PLC firmware or SCADA platform come from that vendor. Autonomous remediation applies to the open source dependencies in code you build.
• It does not certify your RRA or ERP. The AWIA certification is your utility's statement to EPA. Safeguard can hold evidence and inventories that inform it; the judgement and the signature stay with you.
• It does not decide safety trade-offs. Whether to patch a running controller this week, run manually, or accept a risk until a capital replacement is an operational and safety decision for your staff.
• It does not replace EPA or CISA assessments. The free federal assessments look at governance, network design and practices that a software inventory does not cover.

Common mistakes

• Treating the asset list as an IT-only document. Controllers, modems and integrator laptops are the assets the July 2026 attackers used. If the SCADA manager has not reviewed the list, it is incomplete.
• Assuming the integrator handled security. The FBI and EPA pointed to similar third-party network setups across victims. Ask, in writing, what was installed and how it is reached.
• Asking for an SBOM and never reading it. An SBOM is useful only when someone checks it against vulnerability data and keeps it current. Assign an owner.
• Leaving the RRA cyber section generic. Inspectors found missing sections. A dated inventory and vendor register make the section specific.
• Patching a controller without a verified backup. Back up first. The FBI and EPA recommend a verified clean copy of each PLC program.

FAQ

Does AWIA require water utilities to collect SBOMs?

No. SDWA section 1433, as amended by AWIA, requires an assessment of the security of automated systems, not an SBOM. SBOMs are one of the most practical ways to make that assessment specific for software, and CISA's Secure by Demand guide recommends asking OT suppliers for them.

When is our next AWIA recertification due?

EPA's published dates for the current cycle are 31 March 2025, 31 December 2025 and 30 June 2026 for RRAs, by system size, with ERPs due six months after the RRA certification. The cycle repeats every five years. Check EPA's AWIA page for your system's dates.

Do the rules apply to wastewater utilities?

Section 1433 covers community drinking water systems. CRS notes that federal efforts have focused on drinking water. Several pending bills would add wastewater programmes, and some states have their own rules, so check with your state.

What did the July 2026 water attacks target?

The FBI and EPA reported attacks on internet-facing Rockwell Automation and Allen-Bradley MicroLogix 1100 and 1400 PLCs at utilities in at least seven states from 27 July 2026. CISA warned that integrator-installed cellular modems were part of the exposure.

What should we ask a SCADA vendor before buying?

Ask for an SBOM meeting CISA's 2026 minimum elements, a defined support period, a vulnerability disclosure programme, no default passwords, documented remote access through a utility gateway, and machine readable advisories. The question list above turns that into ten questions.

Our vendor says it cannot provide an SBOM. Now what?

Record the answer and its date, ask when it can, and ask for the other items: support period, disclosure programme and a statement on specific vulnerabilities. Weigh the answer at renewal. CISA's OT buying guidance treats SBOMs as a selection factor, not a precondition.

How do we watch for known exploited vulnerabilities without a security team?

Keep a vendor, model and version list, and check it against CISA's KEV catalog and ICS advisories each month, or subscribe to CISA alerts. Any tool that ingests SBOMs and KEV can automate the comparison.

Is a small water system too small to be targeted?

EPA's enforcement alert says small systems are not immune and that recent attacks hit systems of all sizes. The July 2026 activity hit utilities across many states. Exposure, not size, decides who gets hit.

Most of the risk in this guide sits in products and firmware that only their vendors can fix. For the code and container images your utility or its contractors build, though, you do not have to wait for anyone, and the options below show how.

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 shows the local runner: setting it up on your own machine, approving it with its device code, then scanning from the terminal. For a utility whose integration code lives on a segmented network, this is how a scan runs without giving a cloud service access to the repository.

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

The second demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before any command that changes something, edit package.json to lodash 4.17.21, run npm install and npm test with approval, print a summary and push nothing. The same flow applies to a utility's in-house dashboards and integrations, the part of the stack your own team can fix.

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

Quick check

Related reading

• CISA's 2026 SBOM minimum elements update
• Utilities, NERC CIP and the software supply chain
• Manufacturing OT supply chain security in 2026
• SBOMs for firmware and IoT devices
• KEV, EPSS or CVSS: which signal should drive patching
• Safeguard's Third-Party Risk Manager

Sources

• EPA: America's Water Infrastructure Act section 2013, risk assessments and emergency response plans
• EPA: Enforcement Alert, Drinking Water Systems to Address Cybersecurity Vulnerabilities (May 2024)
• Congressional Research Service IF13298: July 2026 Water System Cyber Incidents, Considerations for Congress (27 August 2026)
• CISA: Water and Wastewater Systems Sector
• CISA alert: CISA Urges Water and Wastewater Systems Sector to Protect OT Against Activity Targeting PLCs (30 July 2026)
• FBI and EPA PSA I-073026-PSA (30 July 2026)
• CISA advisory AA23-335A: IRGC-affiliated cyber actors exploit PLCs
• CISA: Secure by Demand, Priority Considerations for OT Owners and Operators (13 January 2025)
• CISA: 2026 Minimum Elements for an SBOM announcement (29 July 2026)
• NIST Cybersecurity Framework
• NIST SP 800-161 Rev. 1, updated November 2024
• NIST SP 800-82 Rev. 3
• American Water Works Company Form 8-K (7 October 2024)
• SecurityWeek: Kansas water facility switches to manual operations following cyberattack
• KFYR-TV: Minot city manager addresses ransomware attack on water treatment plant (2 April 2026)
• Safeguard docs: Local Runner
• Safeguard docs: CLI usage
• Safeguard docs: TPRM SBOM Requests
• Safeguard docs: TPRM Risk Assessment
• Safeguard docs: TPRM Monitoring
• Safeguard docs: Existing SBOM upload
• Safeguard docs: CSAF/VEX upload
• Safeguard docs: Policies and Gates
• Safeguard docs: Air-Gapped Deployment

To try the flows above, download Safeguard and read the documentation.

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