Software Supply Chain Security for State and Local Government: 90-Day Plan

A state agency, county or city secures its software supply chain by knowing which bought products, cloud services, contractor-built applications and open source components run its services, by writing security asks into contracts before signing, and by tracking known exploited flaws across all of it. There is no single federal law that makes a state or city do this. Instead the duty arrives through several doors at once: the FBI's CJIS Security Policy for anything that touches criminal justice information, IRS Publication 1075 for federal tax data, cloud authorization programs such as GovRAMP and TX-RAMP in procurement, state law and executive orders, and the cybersecurity plans that federal grants require.

This guide is for the state CISO or CIO, the city or county IT director, the CJIS Systems Officer or Local Agency Security Officer, the procurement and contract office, the internal auditor and the agency application lead. The first two thirds work with any tools, or none. It is general guidance, not legal or audit advice; your own counsel and auditors decide what a rule means for you.

Key takeaways

• Supply chain duties reach state and local government through many doors. CJIS, IRS Publication 1075, state cloud programs, state statutes and grant conditions each pull in a piece. Map which apply to each system before you write a policy.
• CJIS Security Policy version 6.0 changed the baseline. The FBI released it on 27 December 2024 with modernized System and Services Acquisition and Supply Chain Risk Management control families, and FBI CJIS audits of version 6.0 started on 1 October 2025.
• Cloud services meet procurement gates. GovRAMP (formerly StateRAMP) and Texas's TX-RAMP give buyers a security verification to require from cloud vendors. They are procurement tools for the buyer, not a substitute for knowing what software is inside a product.
• Federal grant money is uncertain, so plan on your own budget. The State and Local Cybersecurity Grant Program's statutory authorization ran through fiscal year 2025, its FY 2025 round was $91.7 million, and its future depends on Congress.
• Recent incidents hit services, not just data. Columbus, Ohio cut its own internet connectivity in July 2024, Saint Paul, Minnesota needed the National Guard's cyber unit in July 2025, and Nevada closed state offices in August 2025.
• SBOM expectations changed in July 2026. CISA's 2026 Minimum Elements for an SBOM replace the 2021 NTIA baseline; ask suppliers for that version.
• A 30/60/90-day plan works with any budget. Inventory first, then vendor and contract asks, then gates, monitoring and evidence.
• 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

Supply chain questions usually reach a state or local government on a bad day, not a planned one. Four triggers are common.

A neighbour gets hit. A nearby city loses phones, payroll and permitting to ransomware, and the city manager asks the IT director whether it could happen here, and through what. The honest answer starts with a current list of software and suppliers, which most local governments lack.

An audit is on the calendar. The state CJIS Systems Agency schedules its audit of a police department, or the IRS Office of Safeguards announces a review of the revenue department. The auditor asks how the agency knows what runs on systems holding CJI or federal tax information, and how it handles their vulnerabilities.

A contract is up for renewal. The records management system, tax system or benefits portal comes up for rebid. If the security office's only input is a generic questionnaire, the agency signs for years with no right to see what is in the product.

A known exploited vulnerability lands on a product you run. CISA adds a flaw to its KEV catalog for a file transfer tool, remote access appliance or content management system. The IT director needs to know within hours whether any department, contractor or hosted service runs it.

A bad week looks like this: email and online payments are down, the police department is back on paper reports, and the public information officer needs to say something by noon. Each vendor says its product is fine. Nobody can say, with evidence, which suppliers have access to what.

What software state and local governments run

A mid-sized county or a state agency runs a portfolio that looks more like a conglomerate's than a single company's. Each line below is a separate supply chain with its own vendors, contracts and update habits.

Three features make this harder than the chart suggests. Contracts are long: a records or tax platform may run for a decade, and security terms missing at signature are hard to add later. Providers hold privileged access: many counties outsource IT, and the provider's remote management tool and patch schedule are part of your supply chain. There is more custom code than leaders think: integrations, data scripts between the jail and the courts, a contractor-built portal, and the open source libraries inside each are software you own, even with no developer on the payroll.

The regulations and frameworks that apply

No federal statute requires states and cities to run a software supply chain programme. The duties come from data-specific federal policies, state law, procurement programmes and grant conditions. Treat the list below as a starting map, not legal analysis.

CJIS Security Policy version 6.0

Any agency with access to criminal justice information (CJI) must follow the FBI's Criminal Justice Information Services Security Policy, administered through its state CJIS Systems Agency. The California Department of Justice's February 2025 bulletin to its subscribing agencies summarizes the change: version 6.0, effective 27 December 2024, contains modernized control families of Assessment, Authorization and Monitoring, Personnel Security, System and Services Acquisition, and Supply Chain Risk Management. The same bulletin says FBI CJIS audits of version 6.0 start on 1 October 2025, and explains that Priority One controls must be implemented immediately while Priorities Two to Four form a roadmap in that order.

Two points matter most for supply chain work. First, the policy now has explicit acquisition and supply chain control families, so the auditor has a place to ask how you choose and watch vendors. Second, the bulletin notes the policy applies to every individual, contractor and private entity with access to CJI or operating in support of criminal justice services. Your records management or dispatch vendor, and any managed service provider with access, is inside that scope. Read the FBI's policy text and its Requirements Companion Document for exact control wording and priorities.

IRS Publication 1075

State revenue, workforce and human services agencies that receive federal tax information (FTI) must protect it under IRS Publication 1075, Tax Information Security Guidelines for Federal, State and Local Agencies. The IRS Safeguards Program page lists the current edition as Rev. 11-2021. For supply chain purposes, any system, contractor or cloud provider in the FTI path is part of what the agency must protect and be able to describe in a review.

Cloud authorization in procurement: GovRAMP and TX-RAMP

GovRAMP is a nonprofit programme that verifies the security of cloud products sold to the public sector. Its site describes security snapshots and verification levels (Core, Ready, and Authorized or Provisional). It was founded as StateRAMP; Route Fifty reported on 14 February 2025 that the board had approved the GovRAMP name to reflect use by local governments, schools and others. Participating states write a required status into their cloud procurement rules, so read your state's policy.

Texas runs its own programme. The Texas Department of Information Resources says TX-RAMP provides a standard approach for security assessment, certification and continuous monitoring of cloud computing services that process the data of Texas state agencies, and offers forms to decide whether a service is in scope.

Both look at the provider's controls, not at which open source components are inside the product or how fast the vendor fixes them, so the plan below adds SBOM and vulnerability-handling asks.

State laws and executive orders

Many states have statutes or executive orders that set cybersecurity duties for agencies, require incident reporting from local governments, or ban specific products on state networks. They differ widely and change often. Before you write a supply chain policy, have counsel list the ones that bind your organisation and its contractors.

The State and Local Cybersecurity Grant Program

The Infrastructure Investment and Jobs Act created the State and Local Cybersecurity Grant Program (SLCGP), administered by CISA and FEMA. To receive funds, a state must have a cybersecurity plan approved by CISA that covers required elements, describes how local governments were consulted, and sets metrics. CISA's programme page lists the FY 2025 round at $91.7 million. The statute, 6 U.S.C. 665g, authorized appropriations for fiscal years 2022 to 2025 only, so further funding depends on reauthorization bills in Congress. Plan supply chain work so it survives without grant money.

Federal directives as reference points

CISA's Binding Operational Directives apply to federal civilian agencies, not to states or cities. They are still the clearest public statement of how fast to act on exploited flaws. CISA's directives page says BOD 26-04, Prioritizing Security Updates Based on Risk, supersedes and revokes BOD 19-02 and BOD 22-01 and consolidates remediation guidance for federal agencies, with risk-based timelines rather than one fixed deadline. Many state policies were written against BOD 22-01's two-week KEV deadline; that directive is now history, so update any policy that cites it. The KEV catalog itself remains the public list of vulnerabilities known to be exploited, and any agency can use it.

Secure by Demand and the 2026 SBOM minimum elements

CISA's Secure by Demand guide gives software buyers questions to ask manufacturers, including whether the manufacturer generates an SBOM in a standard, machine-readable format and makes it available to customers, and whether that SBOM lists all third-party dependencies, including open source components. On 29 July 2026 CISA and partners released the 2026 Minimum Elements for a Software Bill of Materials, which revise the 2021 NTIA baseline after more than 90 public comments. Use the 2026 document when you write SBOM language into contracts.

NIST frameworks

NIST's Cybersecurity Framework 2.0, released in February 2024, added emphasis on governance and supply chains, and many states use the CSF as the backbone of statewide policy. NIST SP 800-161 Rev. 1, updated in November 2024, is the detailed playbook for supply chain risk management practices. Neither is binding on a city by itself, but auditors and state policies often point to both.

Payment card portals

Where a city or county takes card payments online for taxes, fines, utilities or permits, PCI DSS applies to the payment environment and the software in it. Ask your assessor which current requirements cover custom software and its third-party components; the payment portal is often the first place a component inventory is already expected.

How the rules stack up for one system

Real public incidents from the last three years

The incidents below come from official statements or primary reporting. They show what failure looks like for a public body. They do not say what any victim should have done, and this guide does not either.

Columbus, Ohio, July 2024. The city said on 22 July 2024 that its Department of Technology had identified an abnormality on Thursday, 18 July, and took steps to limit exposure, including severing internet connectivity. That caused outages to some resident-facing IT services, while 911, 311 and employee payroll stayed operational.

Conduent, January 2025. Conduent, a business services contractor with many public sector clients, filed an Item 1.05 Form 8-K in April 2025. It said that on 13 January 2025 it experienced an operational disruption and learned that a threat actor had gained access to a limited portion of its environment, and that files associated with a limited number of clients were taken. When a shared contractor is hit, every agency that uses it has a supplier incident to work through.

Saint Paul, Minnesota, July 2025. The city shut down its networks on 28 July 2025 after detecting an attack. The mayor declared a local emergency, and on 29 July Governor Tim Walz activated the Minnesota National Guard's 177th Cyber Protection Team, the unit's first in-state deployment. The city said it would not pay; the group identified as Interlock then published about 43 gigabytes of city data.

State of Nevada, August 2025. The Record reported on 26 August 2025 that an incident on Sunday, 24 August took down state systems, websites and phone lines, and quoted Governor Joe Lombardo's statement that emergency services were still available. The Las Vegas Sun reported on 12 September that the governor said 90% of state websites were back online.

MOVEit Transfer, 2023, as context. Just outside the three-year window, the FBI and CISA advisory AA23-158A of 7 June 2023 described the CL0P group's exploitation of CVE-2023-34362 in the MOVEit Transfer file transfer product. Its first recommended action was to take an inventory of assets and data, identifying authorized and unauthorized devices and software.

What these incidents have in common

Three patterns run through the public record.

Shared products and shared providers. A file transfer tool, a services contractor or a managed service provider sits behind many agencies. When it fails, each customer has to work out its own exposure.

Service impact is the headline. Residents notice when they cannot pay a bill, file a report or receive a payment. Supply chain risk in government is about continuity as much as data.

Response depends on a list. CISA's MOVEit advisory put an inventory first among its recommended actions. A current list of software, vendors and access answers the first question after any of these events: are we affected?

The personas who own the problem

In state and local government, ownership is split across offices that rarely share a meeting. Each needs something different, at a different moment.

What each of them needs to hear

The state CISO needs a defensible picture for legislators and the governor's office: which vendors are critical to which services, what the state requires of them, and how it would know quickly if one were hit.

The city or county IT director often runs a handful of people, sometimes with a managed provider. A ranked list and one spreadsheet of systems, vendors, versions and remote access paths beats any framework.

The CSO or LASO needs audit evidence. With version 6.0's acquisition and supply chain families, expect questions on how CJI systems and their vendors were chosen and are watched.

Procurement needs contract language it can paste and questions whose answers can be compared. The best time to get a vendor's SBOM, disclosure process and support period is before signature.

The auditor or GRC lead needs dated evidence with named owners: a vulnerability decision, an exception with an expiry date, a vendor statement filed against a contract.

The application lead needs to know what is in the agency's own code and how to fix it without breaking a release, and should require a component inventory with every contractor delivery.

Small-government constraints and what is free

Many counties and towns have no security staff. CISA's no-cost Cyber Hygiene services include continuous vulnerability scanning of internet-accessible assets with weekly reports; check eligibility on its page. The KEV catalog, the Secure by Demand questions and the 2026 SBOM minimum elements are free, SPDX and CycloneDX are open standards with open source tooling, and your state CIO's office may offer shared services or statewide contracts to local governments.

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

This plan works with spreadsheets and free tools. Where a product helps, it speeds up the same steps rather than changing them.

Days 1 to 30: see what you have

1. Name one owner for the inventory, usually the IT director in a small government.
2. List every system that supports a public service, using the table above: product, vendor, version, hosting, administrator and remote access paths.
3. Flag regulated data: CJI, FTI, card data and health data. Audits will ask about these first.
4. List contractors and managed providers with access, and how and with which accounts they connect.
5. Inventory your own code. Generate an SBOM for each in-house or contractor-built application with any SPDX or CycloneDX tool, or ask the contractor for one.
6. Check everything against KEV and fix or mitigate any match first.
7. Write a one-page summary: systems, regulated systems, contractors with access, KEV matches and their status.

Days 31 to 60: ask your suppliers

1. Pick the critical vendors: systems with CJI or FTI, payment systems, and anything whose failure stops a public service.
2. Send the question list below and record answers with dates in a vendor register, including what each vendor declined.
3. Check cloud programme status for SaaS against the GovRAMP or TX-RAMP public listings where your state uses them.
4. Confirm CJIS paperwork. For each contractor with CJI access, confirm the agreements and personnel steps your CJIS Systems Agency requires are on file.
5. Review remote access: individual accounts, multi-factor authentication, and unused paths closed.

Days 61 to 90: make it stick

1. Add the purchasing language below to the next RFP or renewal on the calendar.
2. Gate your own code. Fail or flag a build that adds a component with a known exploited or critical vulnerability, and write down who approves exceptions and for how long.
3. Set a rhythm: weekly KEV checks, monthly vendor register review, quarterly SBOM refresh for critical vendors.
4. Rehearse a one-hour tabletop: a KEV entry lands for a product on your list on a Friday afternoon. Who finds it, calls the vendor, decides and tells the public?
5. File the evidence with dates. The same records serve the CJIS audit, the IRS review, grant reporting and insurance renewal.
6. Report the updated one-page summary to leadership.

Template: vendor question list

Use these with any vendor of a system that supports a public service. They draw on CISA's Secure by Demand guide and the 2026 SBOM minimum elements.

1. Will you provide an SBOM for the version we run, in SPDX or CycloneDX, meeting CISA's 2026 Minimum Elements, and update it with each release?
2. Does the SBOM list all third-party and open source components, including transitive ones?
3. What is your published vulnerability disclosure policy, and how do customers report issues?
4. How will you notify us when a vulnerability in your product, or a component in it, is known to be exploited? Within what time?
5. Will you provide machine-readable advisories (CSAF) and statements of which vulnerabilities do not affect your product (VEX)?
6. What is the support period for the version we are buying, and when does it end?
7. How do your staff access our environment for support, and with what controls?
8. Do you hold a GovRAMP, TX-RAMP or FedRAMP status for this cloud service? Which, and at what level?
9. For systems with criminal justice information, will you meet every CJIS Security Policy requirement for your staff and subcontractors with access?
10. Which subcontractors and hosting providers are part of delivering this service?

Template: purchasing language

Adapt with counsel. These are plain-language starting points, not contract terms.

• "The Contractor shall deliver a software bill of materials for each release of the Software, in SPDX or CycloneDX format, meeting the minimum elements published by CISA in 2026, within 30 days of release."
• "The Contractor shall notify the Agency within an agreed period after learning that a vulnerability in the Software or a component of it is known to be exploited, and shall provide a remediation or mitigation plan."
• "The Contractor shall maintain a public vulnerability disclosure policy."
• "The Contractor shall provide security updates for the Software for the period stated in the order, and shall give at least 12 months' notice of end of support."
• "Contractor personnel with remote access shall use individual accounts and multi-factor authentication, and access shall be logged and available to the Agency on request."

Decision table: a new vulnerability in something you run

Worked example: sizing the inventory (illustrative scenario)

Take an invented county of round numbers: 40 business systems, 12 of them SaaS, 8 with CJI or FTI, 6 contractors with remote access, and 10 in-house or contractor-built applications. Day 1 to 30 work is roughly one row per system and one SBOM per application: 40 rows and 10 SBOMs. Day 31 to 60 targets the 8 regulated systems and the 6 contractors first: 14 vendor conversations. Use your own numbers before you promise a date.

Where the procurement cycle fits

Most supply chain weight in government sits in procurement. Add the question list and purchasing language before the RFP goes out, score answers rather than promises at evaluation, and track renewal dates in the vendor register so security sees them months ahead. When a city buys through a state or cooperative contract, it inherits that contract's security terms, so ask the contract holder what they are.

How Safeguard does this

Safeguard can carry the inventory, vendor and code parts of the plan above. It does not replace network controls, identity management or the CJIS and IRS processes your state runs, 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 without handing over repository access, using 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 an agency whose code sits on a segmented network, or whose policy, or CJIS boundary, rules out 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 vendors 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 instead of an inbox.

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 and contractor 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, which matches the exception record auditors ask for. 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. A contractor's pipeline can run the same gate before code is delivered to the agency.

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 boundary 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, for agencies whose policy does not yet allow AI processing. On posture, Safeguard is designed for FedRAMP High and its SOC 2 Type II audit is in progress; check what your state's cloud policy requires before any SaaS purchase.

Which persona uses which part

What Safeguard does not do

• It does not secure your networks, identities or endpoints. Multi-factor authentication, account reviews, network segmentation, backups and endpoint protection stay with your IT team and its other tools. Safeguard does not monitor network traffic.
• It cannot inventory a closed vendor product on its own. For bought systems such as dispatch, records management or tax platforms, 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 products or SaaS. Fixes for a vendor's records management system, a SaaS portal or an appliance come from that vendor. Autonomous remediation applies to the open source dependencies in code you or your contractors build.
• It does not run your CJIS or IRS compliance. Your CJIS Systems Agency and the IRS Office of Safeguards decide whether you meet their policies. Safeguard can hold inventories and evidence that inform those reviews; the attestation, the signed addenda and the judgement stay with you.
• It does not make procurement decisions. Whether any product, Safeguard included, meets your state's cloud and contract rules is for your procurement office and counsel to decide.
• It does not decide public-service trade-offs. Whether to take a system offline during an incident, accept a risk until a contract ends, or notify residents is a decision for elected officials, managers and counsel.

Common mistakes

• Treating the inventory as an IT-only document. Dispatch, courts and finance each know systems IT does not. If department heads have not reviewed the list, it is incomplete.
• Forgetting contractors and managed providers. A provider's remote management tool reaches every system it manages. List it with the same care as any product you bought.
• Accepting a cloud authorization as the whole answer. GovRAMP or TX-RAMP status shows a provider's controls were reviewed. It does not tell you what is inside the product or how fast the vendor fixes a component.
• Citing revoked federal deadlines. Policies that still point to BOD 22-01 cite a revoked directive. Update the reference to BOD 26-04 or to your own risk-based timelines.
• 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.

FAQ

Do state and local governments have to collect SBOMs?

There is no general federal requirement. Some state policies, contracts and data-specific rules point toward component inventories. SBOMs are the most practical way to answer the supply chain questions CJIS, IRS and audit reviews ask, and CISA's Secure by Demand guide recommends asking vendors for them.

What changed in CJIS Security Policy version 6.0?

Version 6.0, effective 27 December 2024, modernized several control families, including System and Services Acquisition and Supply Chain Risk Management, and FBI CJIS audits of version 6.0 started on 1 October 2025. Check the FBI's policy text and your CJIS Systems Agency for the exact requirements and dates.

Is StateRAMP the same as GovRAMP?

Yes. The programme founded as StateRAMP now operates as GovRAMP, a name its board approved to reflect use by local governments, schools and other public bodies. Older contracts may still say StateRAMP.

Does GovRAMP status mean a cloud product is secure?

It means the provider's security controls were reviewed against the programme's framework to a stated level. It does not list the product's components or promise how quickly the vendor fixes them. Pair it with SBOM and vulnerability-handling questions.

Does BOD 26-04 apply to cities and states?

No. CISA's Binding Operational Directives apply to federal civilian executive branch agencies. States and cities often use them as a reference for their own timelines. BOD 26-04 replaced BOD 22-01, so update policies that cite the older one.

Is the State and Local Cybersecurity Grant Program still funded?

CISA lists an FY 2025 round of $91.7 million. Future funding depends on reauthorization in Congress, and bills have been introduced. Check CISA's programme page and your state administrative agency for the current position.

What should we ask a records management or dispatch vendor before buying?

Ask for an SBOM to CISA's 2026 minimum elements, a vulnerability disclosure policy, a notification commitment for exploited flaws, a defined support period, controlled remote access, and CJIS Security Policy terms for staff with access. 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 policy and a written statement on specific vulnerabilities. Weigh the answer at renewal, and add an SBOM clause to the next contract.

How does a small county without security staff start?

List every system, vendor and remote access path in one spreadsheet, check it against the KEV catalog each week, and ask CISA about its no-cost scanning and assessment services. That covers most of days 1 to 30.

Most of the risk in this guide sits in products and services that only their vendors can fix. For the in-house and contractor code and container images your government builds, 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 an agency whose integration code lives on a segmented network or inside a CJIS boundary, 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 city's permitting portal, a state agency's integration scripts or a contractor's web app, the part of the stack your own people can fix.

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

Quick check

Related reading

• Related in this series: 90-day plan for water utilities and 90-day plan for electric utilities.
• State and local government SBOM mandates
• State government software procurement in 2026
• Secure by Demand questions government buyers may ask suppliers
• CISA's 2026 SBOM minimum elements update
• Safeguard's Third-Party Risk Manager

Sources

• California DOJ Information Bulletin 2025-ISRS-001: CJIS Security Policy version 6.0 (1 February 2025)
• IRS: Safeguards Program and Publication 1075
• Route Fifty via Nextgov: StateRAMP to rebrand as GovRAMP (14 February 2025)
• GovRAMP
• Texas DIR: TX-RAMP
• CISA: State and Local Cybersecurity Grant Program
• 6 U.S.C. 665g, State and Local Cybersecurity Grant Program (Cornell LII)
• CISA: Cybersecurity Directives, including BOD 26-04
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Secure by Demand Guide
• CISA: 2026 Minimum Elements for an SBOM announcement (29 July 2026)
• CISA: Cyber Hygiene Services
• NIST: Cybersecurity Framework 2.0 release (February 2024)
• NIST SP 800-161 Rev. 1, updates as of November 2024
• CISA and FBI advisory AA23-158A: CL0P exploits CVE-2023-34362 (7 June 2023)
• City of Columbus: City of Columbus Addressing Cybersecurity Incident (22 July 2024)
• Conduent Form 8-K, Item 1.05 (April 2025)
• MIT Urban Cyber Defense: Ransomware attack on Minnesota's capital city
• The Record: Nevada state websites, phone lines knocked offline by cyberattack (26 August 2025)
• Las Vegas Sun: Lombardo says 90% of Nevada's websites back online (12 September 2025)
• 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.