Zero-Day Response Workflow for a State CISO Office: Day One to Close

When CISA issues an emergency directive on a widely used component, a state CISO office has to answer one question before the governor's office calls back: which systems, in which agencies, run the affected versions, and which of those face the internet? Federal directives do not bind state governments, but the work they describe is the right work. Run a statewide data call against a current inventory, rank exposure with the four risk factors in BOD 26-04, fix or contain inside days, look for signs of compromise, and keep a record that will hold up to your auditor, your legislature and your own after action review.

This post is for the state CISO, deputy CISO or enterprise security lead who owns that week. The first two thirds work with whatever tools your agencies already run. Safeguard enters at "How Safeguard does this", and the scenario in the middle is a composite example, not a customer. Nothing here is legal advice; your own counsel and state statutes decide what you must do and report.

Key takeaways

• A federal order with a state shaped lesson. Emergency directives under 44 U.S.C. 3553(h) bind federal civilian agencies, not states, but CISA urges state governments to act on the KEV catalog too.
• BOD 26-04 is the current triage model. Issued 10 June 2026, it revoked BOD 22-01 and BOD 19-02 and sets timelines from four factors: public exposure, KEV status, exploit automation and technical impact. The tightest is three days plus forensic triage.
• Inventory decides the first day. A directive's first required action is usually an inventory. SBOMs for state built applications and a vendor register for the rest make that answer a lookup instead of a chase.
• Vendors carry much of the exposure. Ask them for a VEX or CSAF statement and an SBOM, and record each answer against the product and version.
• Patching is not the end. The directive pattern is identify, collect evidence, update, hunt, harden and report.
• Safeguard capabilities in this post are all GA: SBOM generation and analysis, software composition analysis, vulnerability management with EPSS and KEV, reachability analysis and prioritisation, Griffin natural language search, continuous scanning, autonomous remediation (ships switched off, every category set to Manual), mitigations, CSAF and VEX upload, TPRM, policies and gates (Block, Warn, Notify), the CLI and local runner, the desktop and mobile apps, and on-prem, air-gapped and Zero AI deployment.

The job and who owns it

The trigger: CISA publishes an emergency directive, or a widely used component lands in the KEV catalog with a note about active exploitation. Within an hour the state CISO office hears from the governor's chief of staff, the state CIO, agency heads and a reporter. Everyone asks the same thing: are we affected, how badly, and when will it be fixed.

The state CISO rarely owns every affected system. Some agencies run on consolidated infrastructure, some run their own data centers, and many depend on commercial software and hosted services. The judicial and legislative branches, universities, counties and cities often sit outside the CISO's authority while sharing networks or vendors. On day one the CISO's power is mostly to ask, coordinate and report.

So the job is really four jobs:

1. Coordinate. Declare the response, name an incident lead, open a single log and start a statewide data call to every agency's information security officer.
2. Find. Establish which systems contain the affected component and version, across state built applications, vendor products, appliances and hosted services.
3. Act. Patch, mitigate or isolate, in priority order, and check exposed systems for signs of compromise.
4. Report. Give leadership a defensible status at fixed times, keep a record for the after action review and the auditor, and decide what, if anything, goes to the public.

A good week ends with a short list of residual risks, each with an owner, an expiry and a reason. A bad week ends with the spreadsheet still circulating on Friday and a forensic question nobody can close because the logs were not kept.

The rules behind the week

Emergency directives: what they are and who they bind

CISA's directives page explains that binding operational directives and emergency directives "require action on the part of certain federal agencies" in the civilian executive branch. The statutory basis for emergency directives is 44 U.S.C. 3553(h). It lets the Secretary of Homeland Security, in response to a known or reasonably suspected threat, vulnerability or incident that represents a substantial threat to an agency's information security, issue an emergency directive requiring the agency head to take lawful action on the system.

For a state, that means:

• A directive does not legally bind state agencies. The scope sections of recent directives apply to federal information systems and federal agencies. A state chooses to follow one, and should say so explicitly in its own instruction to agencies.
• A directive is still the best free playbook you will get that week. It names products and versions, sets an order of operations and often brings hunt and hardening guidance that fits a state network too.

The shape is consistent. ED 26-03, issued 25 February 2026 and superseded by a V1 on 11 March 2026, dealt with vulnerabilities in a widely deployed SD-WAN product. Its required actions had to be taken in order: Identify every in-scope system and report an inventory by 11:59 PM ET the next day; Collect logs and forensic artifacts, including disk and memory snapshots for on-premises deployments; Update to the vendor's fixed versions by a deadline two days after issue; Hunt using CISA's supplemental guidance, with immediate reporting and a full rebuild if root compromise is found; Harden using the supplemental hardening guidance; and Report in stages, with a summary inventory the next day, a detailed inventory and actions a week later, and hardening and logging reports after that.

Inventory is due before the patch, and evidence collection comes before patching, because patching can destroy what a responder needs to see.

Emergency directives also end. On 8 January 2026 CISA retired ten issued between 2019 and 2024; seven tied to specific CVEs were retired because those CVEs are now in the KEV catalog, so the lasting duty runs through KEV.

BOD 26-04: the current way to rank the work

BOD 26-04, "Prioritizing Security Updates Based on Risk", was issued on 10 June 2026. It revokes BOD 19-02 and BOD 22-01. (BOD 22-01 created the KEV catalog in 2021 and set fixed KEV deadlines; it is history now.) BOD 26-04 asks four questions about each vulnerable asset:

Table 1 of the directive turns those answers into calendar day timelines. Here it is in full:

Three details matter for a state adopting the model:

• The clock starts at the earlier of two events: CISA adding the CVE to KEV, or the agency finding the vulnerability on an asset. You cannot slow the clock by not looking.
• Timelines move as facts change. The directive gives the example that taking a system off the internet changes "publicly exposed" from yes to no, which lengthens the remaining timeline. A KEV addition shortens it.
• "Forensic triage" is a real step. CISA's BOD 26-04 Implementation Guidance describes triage steps with recommended target windows, starting within the first two hours of a KEV addition and running through roughly 48 hours, while noting that the requirement is an adequate triage, not those exact hours.

BOD 26-04 also asks agencies to tag externally reachable assets with organization, environment, exposure and asset type, a ready made schema for a state asset list.

KEV, SSVC and EPSS: the inputs

CISA's KEV criteria page sets three thresholds for a KEV entry: an assigned CVE ID, reliable evidence of active exploitation in the wild, and a clear remediation action such as a vendor update. The same page says that although state, local, tribal and territorial governments are not bound by BOD 26-04, every organization can reduce its exposure by using the catalog as an input to its own prioritization.

BOD 26-04's timelines are informed by SSVC, the Stakeholder-Specific Vulnerability Categorization method that Carnegie Mellon's Software Engineering Institute created with CISA in 2019. CISA's SSVC tree yields Track, Track*, Attend or Act; Act means leadership attention and a coordinated response.

EPSS, maintained by FIRST, estimates the probability that a CVE will be exploited in the next 30 days, updated daily. It helps with the long tail after the emergency; on day one a directive already tells you exploitation is happening.

Incident response and patch guidance

NIST SP 800-61 Revision 3 (April 2025) recasts incident response as a Community Profile of the Cybersecurity Framework 2.0, so a directive response can reuse the roles and reporting lines of ordinary incidents. NIST SP 800-40 Revision 4 (April 2022) treats patching as preventive maintenance: identify, prioritize, acquire, install and verify. CISA's federal incident and vulnerability response playbooks give a federal version of the same steps.

SBOMs, VEX and CSAF: the vendor half

CISA, with the NSA, the FBI and international partners, published the 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026. It updates and replaces the 2021 NTIA minimum elements. An SBOM is what lets a state answer "is the component in this product" without waiting for a vendor to reply.

For the vendor's answer, OASIS CSAF 2.0 defines a machine readable advisory format with a VEX profile, in which a supplier states that a product is known affected, known not affected, fixed or under investigation. That answer can be filed against the exact product and version.

State programs that shape the response

Three state level programs touch this work:

• The State and Local Cybersecurity Grant Program. CISA's SLCGP page describes a statewide Cybersecurity Plan that must be approved by the state's Cybersecurity Planning Committee and its CIO or CISO, with plans resubmitted by 30 January 2026, and a requirement that states pass at least 80 percent of funds to local governments. If your plan commits to asset inventory and vulnerability management, a directive week tests it.
• The MS-ISAC. The Multi-State Information Sharing and Analysis Center serves state, local, tribal and territorial governments with threat intelligence, a 24 hour security operations center and incident response support. Its site notes a transition to a member funded model in 2025. Its advisories and services reach member local governments as well as states.
• GovRAMP (the program previously called StateRAMP). It is a nonprofit membership organization that gives governments a common framework for verifying the security of cloud services and third party technology. A vendor's status there is a useful prompt for what to ask about its response.

How teams do it today and where it breaks

Most state responses look alike. The CISO office emails agency security officers the directive and a spreadsheet. Agencies forward it to application owners and vendors, and answers come back over days, in different formats, with different definitions of "affected".

The breaks are predictable:

• No shared definition of the component. Agencies search for different names, and transitive copies inside other software are missed.
• Inventory lives in people's heads. The configuration management database lists servers, not the libraries inside them.
• Vendor answers are slow and vague. "We are investigating" with no version or date is common.
• Exposure is unknown. Nobody can say which affected systems face the internet, so everything is urgent and nothing is.
• Patching outruns evidence. A public facing system is patched before anyone captures logs, and the forensic question is lost.
• Fixes regress. A container image is rebuilt from an old base, or a branch merges an old lockfile, and the vulnerable version returns two weeks later.
• The status report is a guess. Leadership hears how many agencies are "complete", not how many systems remain open.

These come from running a statewide response on email, memory and spreadsheets.

Step by step: the first five days, with or without any particular tool

The timings below follow the directive pattern and BOD 26-04's tightest timeline. Adjust them to your state's policy.

Hour 0 to 2: declare, scope and start the log

1. Read the directive and its supplemental guidance. Note products, affected and fixed versions, the required order of actions and the hunt guidance.
2. Declare the response under your incident plan and name one incident lead.
3. Announce scope. Executive branch agencies under your authority, plus an offer of help to other branches, universities and local governments.
4. Open a single incident log with timestamps, decisions, owners and evidence. Every later step writes to it.
5. Turn the federal directive into a state instruction with the actions that apply, state deadlines and the reporting template.

Hour 1 to 6: the statewide data call

Ask every agency for the same fields, in the same format, by a fixed time. A template that works:

Ask for "unknown" explicitly; it beats a guessed "not affected".

Hour 1 to 8: find the component in what you build

For state built applications, search lockfiles and resolved dependency trees, not only top level manifests. These commands use each ecosystem's own tools and show transitive paths:

# Node.js: show every path that pulls the package in
npm ls example-component --all

# Maven: show the resolved tree filtered to one artifact
mvn dependency:tree -Dincludes=org.example:example-component

# Gradle: show which configuration pulls it in and why
./gradlew dependencyInsight --dependency example-component

# Python: show installed version and what requires it
pip show example-component

# Go: list the module and the version actually selected
go list -m all | grep example-component

Inspect the container images you run, including base images. For appliances and commercial software you cannot inspect, the vendor's statement is the evidence.

Hour 2 to 24: ask vendors the right question

Send each vendor that supplies an in-scope product the same request:

1. Is product X, version Y, affected by CVE Z? Answer as known affected, known not affected, fixed or under investigation.
2. If affected, what is the fixed version or mitigation, and when?
3. If not affected, why (component absent, version outside range, vulnerable code not present or not reachable)?
4. Please send a CSAF advisory or VEX document and a current SBOM that meets CISA's 2026 minimum elements.
5. For hosted services: have you applied the fix, and will you confirm you have looked for compromise?

Record each answer against the product and version, with the date and who sent it. "Under investigation" gets a follow up time, not a closed status.

Hour 2 to 24: rank the hits with the BOD 26-04 factors

Use the four factors even though you are not bound; they are published, defensible and force the exposure question early.

Hour 6 to 72: contain where you cannot fix yet

Vendor fixes lag, and change freezes exist for tax season and elections. Where you cannot patch in time, contain and record the decision:

• Remove internet exposure (put the service behind a VPN, an access gateway or an allow list), which changes the BOD 26-04 exposure answer.
• Disable the affected feature or endpoint if the vendor documents it.
• Add detection for the exploit pattern described in the advisory.
• Write the workaround into the incident log with an owner and an expiry date, so it is reviewed and not forgotten.

Day 1 to 3: collect evidence, then fix

For each publicly exposed system, capture what the directive or advisory says to capture before changing it: logs (stored outside the system), configuration, and disk or memory images where the guidance asks for them. Then patch.

For state built code, change the dependency and lockfile, rebuild, test and deploy through your pipeline as a reviewed pull request. For vendor products, apply the vendor's fix or confirm the vendor applied it.

Day 1 to 5: hunt and verify

Run the hunt guidance on every system that was exposed while vulnerable. Re-scan or re-inspect to confirm the fixed version is what is actually running, not only what was deployed. If you find signs of compromise, move from vulnerability response to incident response, and report through the channels your state law and policies require. The MS-ISAC offers incident response and remediation support to its members.

Day 3 to 5: stop it coming back and close

Add a rule to your build and release process that fails or flags any build that reintroduces an affected version. Close each system only on evidence of the fixed version running, or a dated, signed risk acceptance. Then hand the residual list to normal vulnerability management.

What goes in the leadership status?

Leadership needs the same five lines at every update, at fixed times (for example 9 AM and 4 PM):

1. Systems confirmed affected, by agency, and how many are publicly exposed.
2. Systems fixed, contained and still open, with the next deadline for each open group.
3. Vendors that have not answered, by name of product.
4. Any sign of compromise found, and what was done.
5. Decisions needed from leadership (a change freeze waiver, a service taken offline, a public statement).

Avoid percentages without a denominator. A line such as "most agencies have reported" says nothing about the systems inside the eight that did not.

Illustrative scenario: a directive on a file transfer library in a composite state

This is a composite example, not a customer. The state, agencies, component and numbers are invented, and every number is an example input, not a result.

The State of Westbrook (fictional) hosts about 30 agencies on central infrastructure, while 10 larger agencies run their own. Example inputs: around 600 state built applications and 200 commercial or hosted products.

On a Tuesday afternoon, CISA issues an emergency directive on a widely used open source file transfer library, invented for this example and called LibRelay here, with a vulnerability that gives an unauthenticated attacker total control and is already being exploited. The CVE goes into KEV the same day. The directive requires an inventory by the next night, log collection before patching, the vendor's fixed version within two days, and a hunt.

The CISO declares a response at 3 PM, names the deputy CISO as incident lead and sends the data call template with a 10 AM Wednesday deadline. The governor's office hears that the state will follow the directive voluntarily and report at 9 AM and 4 PM.

By Wednesday morning the picture looks like this (example inputs):

• 25 state built applications use LibRelay directly or transitively. Six are publicly exposed.
• Four commercial products are confirmed affected by their vendors. Three vendors say not affected, with a VEX statement. Nine have not answered.
• Two agencies return "unknown" for a group of older applications whose owners have left.

The incident lead applies the BOD 26-04 table: the six exposed applications sit in a "3 days and forensic triage" row. Teams capture logs and images on Wednesday, then patch. Two exposed products whose vendor fix is not ready go behind the state's access gateway with a workaround that expires in seven days. The "unknown" group is treated as exposed.

On Thursday the hunt finds an unexplained outbound connection on one system, which moves to incident response. On Friday a container rebuild pulls an old base layer into staging; the release check catches it before production.

By the next Tuesday every exposed system is fixed or contained and two vendors have follow up dates. The after action review asks for SBOMs for every state built application, a vendor clause requiring VEX within a set time, and a gate against the old version.

How Safeguard does this

Safeguard does not run your response, declare incidents, talk to your vendors or decide what the state reports. It shortens and documents the parts of the week that depend on knowing which components run where, whether vulnerable code is reachable, whether a fix shipped and whether it stayed shipped. Every capability below is GA. Commands come from docs.safeguard.sh and were not run for this post. The matching use case page is Zero-Day Discovery with Safeguard.

1. Have the inventory before the directive arrives

SBOM generation and analysis (GA) and software composition analysis (GA) build a full transitive inventory of each application and image, in SPDX and CycloneDX. Agencies whose repositories are connected are scanned continuously. The Continuous Scanning docs describe rescans driven by vulnerability feed updates (a new CVE, GHSA or OSV entry, a CISA KEV addition or an EPSS change affecting a component you use) and by asset changes such as a new commit or image tag. New advisories are matched to components already indexed, so affected assets are rescored without anyone starting a scan.

For agencies that will not connect repositories, the CLI (GA) and local runner (GA) scan on the agency's own machine. The CLI Usage docs show one target per scan:

# A local directory (your own or proprietary code)
safeguard scan --dir .

# A Git repository
safeguard scan --repo https://github.com/org/repo

# An SBOM you already have (SPDX or CycloneDX, detected automatically)
safeguard scan --sbom sbom.json

Results are written as JSON under ./output. Scanning from the interactive terminal while signed in uploads the SBOM and findings, never the source. On a machine with no browser, safeguard login --no-browser prints a URL and a code to enter elsewhere.

Asset Discovery (GA) adds repositories, images and packages that nobody registered, which is where the "unknown" answers from the data call usually hide.

2. Ask the statewide question in plain English

Griffin natural language search (GA) runs across every indexed SBOM, component and vulnerability. The Search docs show plain lookups (a package name, a CVE ID, or a package and version) and plain English questions such as "Which projects have exploitable vulnerabilities?" or "Show me all critical vulnerabilities in production". Results group components with the projects that use them, and vulnerabilities with fix availability.

The first answer to the governor's office then comes from a query, not a spreadsheet. You can scope a query to one project with an @ mention, ask follow up questions in the same conversation, star the search so every analyst reuses it all week, and export results as JSON, CSV or PDF for the incident log.

3. Rank by exposure, exploitation and reachability

Vulnerability management (GA) enriches each CVE with CVSS, EPSS and KEV status. The Vulnerabilities page lists fields for affected component, fixed version, exploitable status and reachability, and filters by each.

Reachability analysis and prioritisation (GA) is described in Vulnerability Prioritization. It classifies each finding as reachable, conditionally reachable, unreachable or unknown, and treats unknown conservatively as potentially reachable. The Vulnerabilities page also weighs business context: asset criticality, data sensitivity and exposure level (internet facing or internal). Those map closely to the BOD 26-04 factors, so the ranked list lines up with the table your incident lead is already using. Reachability does not change a directive's instruction to patch; it orders the work and the hunt.

4. Get vendors' answers into the same place

TPRM (GA) handles the vendor half. The SBOM Requests docs show single and bulk requests to vendors with a template, a message and a deadline, and track each request through sent, viewed, in progress, submitted and validated.

CSAF and VEX upload (GA), described in CSAF/VEX Upload, accepts CSAF and VEX documents so a vendor's "known not affected" or "fixed" statement sits in the platform against the product and version it covers. The CLI can check a vendor's document against its specification before you rely on it:

safeguard validate sbom.json
safeguard validate ./sboms --recursive

5. Open fixes as pull requests

Autonomous remediation (GA) runs through AI Remediate. The AI Remediate docs describe analysis, solution generation, impact assessment, pull request creation and validation. It upgrades vulnerable packages, handles transitive conflicts and updates lock files. You can run it on one vulnerability, on a selected set (one pull request per repository) or from the top of the Vulnerabilities page for every fixable finding. Breaking change detection grades each change Safe, Minor, Major or Critical, and each pull request carries the CVE reference and test results when tests are configured.

Autonomous remediation ships switched off, with every category set to Manual, so agency change control still decides what merges and when.

6. Record workarounds, risk acceptances and evidence

The Mitigations tab records four types: risk acceptance, false positive, workaround applied and not applicable. Each record carries a justification, an approver, optional evidence and a scope, and risk acceptances carry an expiry date. Mitigations can be applied in bulk. That covers the access gateway workaround and its seven day expiry from the scenario, in a form an auditor can read. (The page's /v1 REST examples are not available yet, so use the app.)

7. Stop the vulnerable version coming back

Policies and gates (GA) are described in Policies & Gates and Policy outcomes and actions. Each policy has one action when it fails: Block fails the gate, Warn lets the gate pass with a warning naming the policy, and Notify lets it pass and sends a notification to the workspace's configured channels. A legitimate exception goes through the exceptions workflow: a request with a business justification and an expiry, a decision by an approver, and an audit trail.

To fail a CI job on a gate, the CI/CD Integration docs show a plain shell step with an API key stored as SAFEGUARD_API_KEY:

curl -fsSL https://cli.safeguard.sh/install | bash
SAFEGUARD_API_KEY=... safeguard ci scan --wait --fail-on critical \
  --repository-url "$REPO_URL" --branch "$BRANCH" --commit "$COMMIT"

With policy outcomes on for the workspace, safeguard ci scan --wait --fail-on-gate with a gate name, id or all fails the job when the gate fails. Agencies with self-hosted or firewalled Git servers can add --local, which scans on the runner so only results leave it. That is the check that catches the stale base layer in the scenario.

8. Approve from wherever the incident lead is

With the desktop app (GA) and mobile app (GA), an incident lead can send work to a computer running the CLI and approve each command from a phone. The CLI asks before any command that changes something.

9. Deploy it where state data rules require

Safeguard deploys as SaaS, in a private VPC, fully on-prem or fully air-gapped (GA), with the models running inside your environment if needed. Zero AI mode (GA) runs the platform deterministically with no language model in the loop, and bring your own model (GA) is available for agencies with an approved provider. The Air-Gapped Deployment docs describe signed vulnerability feed snapshots, including KEV and EPSS, delivered on a cadence you choose, so continuous scanning still works inside a closed state data center. Safeguard is designed for FedRAMP High, and its SOC 2 Type II audit is in progress.

The week, mapped

What to measure

Use this checklist after the week. These are measures for you to collect, not outcomes anyone can promise.

• Time from directive to first complete inventory of state built applications.
• Share of in-scope systems where the answer came from an SBOM or scan rather than a manual check.
• Number of "unknown" answers at 24 hours, and how many were still unknown at 72 hours.
• Vendors who answered with a VEX or CSAF document, and how long they took.
• Publicly exposed affected systems fixed or contained inside 3 days.
• Exposed systems with evidence collected before change.
• Forensic triage completed on every system in a "forensic triage" row.
• Workarounds and risk acceptances with an expiry date and a named approver.
• Regressions caught by a gate after the fix.

What Safeguard does not do

• It does not make a directive apply to you, or decide your obligations. Whether a state follows a federal directive, and what it reports to whom, are policy and legal decisions for the state.
• It does not see inside products it has no data for. For a commercial product, appliance or hosted service, Safeguard knows only what the vendor's SBOM, CSAF or VEX document says, or what you can scan. Vendor firmware on network appliances still needs the vendor's fix.
• It does not do your forensic triage or hunt. Collecting memory images, reviewing logs and judging whether a system was compromised stay with your responders, your MS-ISAC relationship or your incident response provider.
• It does not patch operating systems, appliances or hosted services. Its remediation opens pull requests for dependencies in code you build.
• It does not merge on its own by default. Autonomous remediation ships switched off, every category set to Manual. Turning it on is your decision.
• It does not replace notification decisions. Telling the public, affected residents, regulators or law enforcement is the state's call under its own laws.
• This workflow does not depend on Safeguard having found the vulnerability. It starts when a directive or CVE is public, and makes no claim about Safeguard's research on any particular issue.

Common mistakes

• Patching exposed systems before collecting evidence. The directive order exists for a reason. Capture first, then fix.
• Searching only top level dependencies. Most copies of a widely used component arrive transitively or inside another product.
• Accepting "not affected" without a reason. Ask why, and ask for it in VEX or CSAF form.
• Treating "internal only" as safe. In BOD 26-04, internal systems in KEV with total control and automatable exploitation still get 3 days and forensic triage.
• Letting workarounds become permanent. Every containment record needs an expiry and an owner.
• Reporting agencies, not systems. Leadership needs counts of systems by status, with the unknowns shown.
• Closing on deploy, not on evidence. Confirm the fixed version is running, then close.
• Forgetting local governments. Counties share vendors and networks with the state; share the template and vendor answers.

FAQ

Do CISA emergency directives apply to state governments?

No. They are issued under 44 U.S.C. 3553(h) to federal civilian executive branch agencies, and states follow them voluntarily. CISA's KEV page encourages state governments to use the KEV catalog in their own prioritization.

What is the difference between an emergency directive and a binding operational directive?

An emergency directive responds to a specific, urgent threat, usually with short deadlines and required actions in a set order, and CISA retires it once the risk is handled. A binding operational directive sets a standing requirement. BOD 26-04 is the current standing rule for prioritizing security updates.

How fast should a state patch a KEV vulnerability?

States set their own policy. As a benchmark, BOD 26-04 gives federal agencies 3 days plus forensic triage for a publicly exposed KEV vulnerability that gives total control, and 14 days or more for less severe combinations.

What is forensic triage under BOD 26-04?

It is a check of whether a vulnerable system was compromised, carried out alongside remediation for the highest risk rows of Table 1. CISA's implementation guidance gives recommended target windows starting within two hours of a KEV addition, and says the requirement is an adequate triage rather than those exact hours.

How do we find a vulnerable component inside software we do not build?

Ask the vendor for a CSAF or VEX statement and an SBOM that meets CISA's 2026 minimum elements, and scan any images or artifacts you can inspect. Record each answer against the exact product and version.

Can counties and cities use the same workflow?

Yes. The data call template, the BOD 26-04 table and the vendor questions work at any size. Many local governments get advisories and incident support through the MS-ISAC, and states pass most SLCGP funds to local governments, so sharing the workflow is often part of the state plan.

Can Safeguard run inside a state data center?

Yes. On-prem and air-gapped deployment are GA, with signed vulnerability feed snapshots delivered on a schedule you choose, and Zero AI mode runs with no language model at all. Safeguard is designed for FedRAMP High, and its SOC 2 Type II audit is in progress.

Related reading: finding affected products fast with SBOMs, a guide to VEX, an incident response playbook for a compromised dependency, the retail version of this workflow and policy gates in a CI pipeline.

A directive week ends with the vulnerable version gone from the code you build, and the faster that happens, the shorter the list of exposed systems you have to hunt. The section below sets out how Safeguard closes the gap between a published fix and production, and what it offers when no upstream fix exists yet.

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 sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. It is how an agency that will not connect its repositories still gets into the statewide inventory.

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

The second demo is a real CLI session. Someone installs the CLI, runs safeguard to open the interactive terminal and asks it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. The same flow applies to an agency application carrying the component named in a directive.

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

The third demo is a real Android session with the mobile app. Work is sent to a computer running the CLI, and each command is approved on the phone with Allow once, Allow for turn or Deny. That suits an incident lead moving between briefings.

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

To try it on your own code, download Safeguard from https://safeguard.sh/download and read the docs at https://docs.safeguard.sh/docs .

Quick check

Sources

• CISA: Cybersecurity Directives
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: BOD 26-04 Implementation Guidance
• CISA: V1 ED 26-03
• CISA: CISA Retires Ten Emergency Directives (8 January 2026)
• 44 U.S.C. 3553 (Cornell LII)
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Reducing the Significant Risk of Known Exploited Vulnerabilities (KEV criteria)
• CISA: Stakeholder-Specific Vulnerability Categorization
• FIRST: Exploit Prediction Scoring System
• NIST SP 800-61 Rev. 3
• NIST SP 800-40 Rev. 4
• CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbooks
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Software Bill of Materials
• OASIS: CSAF Version 2.0
• CISA: State and Local Cybersecurity Grant Program
• CIS: MS-ISAC
• GovRAMP
• GovRAMP: About
• Safeguard: Zero-Day Discovery use case
• Safeguard docs: Continuous Scanning
• Safeguard docs: CLI Usage
• Safeguard docs: Asset Discovery
• Safeguard docs: Search
• Safeguard docs: Vulnerabilities
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: SBOM Requests (TPRM)
• Safeguard docs: CSAF/VEX Upload
• Safeguard docs: AI Remediate
• Safeguard docs: Mitigations
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: CI/CD Integration
• Safeguard docs: Air-Gapped Deployment

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