A Critical Library CVE Dropped Friday Night: Retail Incident Response

When a critical CVE lands in a common open source library on a Friday night, the job is to answer one question before anything else: which of our systems run the vulnerable version, and which of those face the internet or touch card data? Answer that from a current inventory rather than from memory, rank the hits by exploitation and reachability, ship the fix behind a gate that stops the old version coming back, and keep a record that will satisfy your PCI assessor and your own post-incident review.

This post is for the security engineer at a US retailer who gets the page, inside a PCI DSS scope. The first two thirds work with whatever tools you already have. Safeguard enters at "How Safeguard does this", and the scenario in the middle is a composite example, not a customer.

Key takeaways

• The first hour is about exposure, not patching. Build the affected list from a current inventory, including transitive dependencies and images.
• Rank with more than CVSS: KEV, EPSS, internet exposure, reachability and cardholder data environment (CDE) scope decide what gets fixed tonight.
• PCI DSS v4.0.1 shapes the clock: requirement 6.3.3 asks for critical patches within one month of release, requirement 6.3.2 asks for an inventory of bespoke software and its third-party components, and requirement 12.10.1 asks for an incident response plan ready to activate.
• CISA's BOD 26-04 (10 June 2026) binds only federal civilian agencies, but its four factors (public exposure, KEV status, automatable exploitation, technical impact) make a sound triage model for anyone. BOD 22-01 is revoked and is history.
• A peak season change freeze needs a written emergency path, not a quiet exception.
• Safeguard capabilities used in this post, all GA: SBOM generation and analysis with continuous scanning (GA), SCA with deep transitive dependency scanning (GA), vulnerability management with EPSS and KEV enrichment (GA), reachability analysis and prioritisation (GA), Griffin natural language search (GA), autonomous remediation with AI Remediate pull requests (GA, ships switched off with every category set to Manual), policies and gates with Block, Warn and Notify (GA), mitigations and risk acceptance records (GA), CSAF and VEX upload (GA), and the CLI, local runner and mobile app (GA).

The job and who owns it

The persona here is a security engineer at a mid-sized US retailer. Not the CISO, not the head of AppSec: the person who is on call this week and whose phone lights up at 21:40 on a Friday because an advisory for a widely used parsing or logging library just went public with a critical score, and a proof of concept is already circulating.

Retail makes this job harder in specific ways.

The estate is wide and mixed. A storefront (often Java or Node.js), iOS and Android apps, order management, loyalty, inventory and warehouse services, store systems that talk to point of sale terminals, and dozens of internal tools. Much of it is bought: POS software, payment gateways, a commerce platform, SaaS.

The calendar is unforgiving. The trigger in this post arrives in late October. Many retailers enter a peak season change freeze in early November that runs into the new year, ahead of Black Friday (27 November 2026) and Cyber Monday. A Friday night CVE in late October lands just before the freeze, which is the worst time to be told "we will patch in the next sprint".

PCI DSS scope is real. Any system that stores, processes or transmits cardholder data, or that can affect the security of the CDE, is in scope. A vulnerable library on the payment page or in a service that touches card data raises the stakes, both for the attacker's payoff and for your assessor's questions next spring.

Who is asking, and by when. Within an hour: the storefront on call, the CISO, the e-commerce product owner, and possibly legal if the company is public. By Monday morning the CISO wants a one page status: exposed, fixed, remaining risk, and what stops a repeat.

What a bad week looks like. Nobody can say with confidence which services use the library. The last SBOM export is from the spring. Each team is asked to check its own repos, half of them answer by Saturday afternoon, and two answer "we don't think so" without looking at transitive dependencies. On Tuesday a rebuilt image quietly pulls the old version back from a cached base layer. In February the PCI assessor asks for evidence that the critical patch was applied within the required time frame, and the evidence is a Slack thread.

The rules behind the weekend

This section is not legal, regulatory or audit advice. It sets out what the primary documents say so you can have a sharper conversation with your QSA, counsel and leadership.

PCI DSS v4.0.1: the clauses that apply to a library CVE

The PCI Security Standards Council published PCI DSS v4.0.1 on 11 June 2024 as a limited revision of v4.0, and v4.0 was retired at the end of 2024. The future dated requirements in v4.0 became effective after 31 March 2025, and v4.0.1 did not move that date. Four requirements matter on a Friday night:

If the library runs in payment page scripts, requirement 6.4.3 may also come up. One month is the outer limit for critical patches, not a target.

CISA BOD 26-04 as a triage model

CISA's Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk", was issued on 10 June 2026. It applies to federal civilian executive branch agencies and, unless a contract says so, not to contractors. It revokes BOD 22-01 (the 2021 directive that created the KEV catalog) and BOD 19-02. 22-01 is now history, and its fixed deadlines no longer apply.

The reason a retailer should read BOD 26-04 anyway is its decision model. It sets remediation urgency from four questions:

1. Asset exposure. Is the vulnerable asset publicly exposed?
2. KEV status. Is the CVE on CISA's Known Exploited Vulnerabilities catalog?
3. Exploit automation. Can an adversary automate every step of the exploit?
4. Technical impact. Does exploitation give partial or total control of the asset?

The directive's most urgent timeline is three calendar days plus a forensic triage to check whether the asset was already compromised before the fix landed. It also says the timeline is dynamic: taking a system off the internet changes "publicly exposed" from yes to no and relaxes the deadline, while a later KEV addition shortens it. CISA publishes the KEV, automation and impact answers through its Vulnrichment program.

Scores and catalogues: CVSS, EPSS and KEV

• CVSS v4.0 from FIRST describes severity. Version 4.0 names score combinations, such as CVSS-B for base only and CVSS-BTE with threat and environmental metrics. A "critical 9.8" in an advisory is usually a base score that knows nothing about your environment.
• EPSS from FIRST estimates the probability that a published CVE will be exploited in the wild in the next 30 days, as a value from 0 to 1 updated daily for every CVE.
• The KEV catalog is CISA's authoritative list of vulnerabilities exploited in the wild. If a CVE is on it, exploitation is not hypothetical.

None of the three tells you whether your build calls the vulnerable function. That is the reachability question, and it is where most of the weekend's time goes.

Incident response and patch management guidance

NIST SP 800-61 Revision 3 (April 2025) recasts incident response as a CSF 2.0 community profile, part of overall cybersecurity risk management. NIST SP 800-40 Revision 4 (April 2022) frames enterprise patch management as preventive maintenance and defines it as identifying, prioritising, acquiring, installing and verifying patches. The verify step is the one teams skip on a Friday night.

Disclosure: when "material" comes up

If your company is publicly traded, the SEC's 2023 rules added Item 1.05 to Form 8-K. A registrant must disclose a cybersecurity incident it determines to be material within four business days of that determination. A vulnerable library is not, by itself, an incident, and the materiality call belongs to leadership and counsel, not the on call engineer.

What you can ask of your vendors: VEX and CSAF

For bought software you depend on vendor statements. CSAF 2.0, an OASIS standard, is a machine readable format for security advisories, and its product status values include known affected, known not affected, fixed and under investigation. VEX (Vulnerability Exploitability eXchange) documents tell you whether a product is affected by a given CVE; CISA published minimum requirements for VEX in April 2023.

SBOMs: the inventory that makes the first hour short

On 29 July 2026 CISA, NSA, FBI and international partners released the 2026 Minimum Elements for a Software Bill of Materials, replacing the 2021 NTIA baseline. The update adds required fields such as component hash, license, SBOM tool name and SBOM generation context. Generation context matters in an incident: SBOMs built from a lockfile, an artifact and a running container can disagree.

How teams do it today and where it breaks

Most retailers handle a library CVE roughly like this. It works, slowly, and breaks in predictable places.

Each step depends on knowledge in someone's head or a stale export. The fix is not heroics: a current inventory, a ranking method decided in advance, fixes as pull requests, and a gate that prevents regression.

Step by step: the first 72 hours, with or without any particular tool

The plan below is tool neutral. Adapt the hours to your own on call model.

Hour 0 to 1: declare, assign and start the log

1. Declare a vulnerability incident, even before you know you are affected. Activating the 12.10.1 plan puts people and decisions on the record.
2. Name an incident lead and a scribe, the owners of each affected platform, and who can approve an emergency change.
3. Start a timestamped log. One document, one line per event: time, who, what, evidence link. Everything later depends on this log.
4. Capture the advisory facts: CVE ID, affected version range, first fixed version, whether a workaround exists, CVSS vector, EPSS value at the time you read it, and KEV status. Recheck KEV and EPSS twice a day.

Hour 1 to 4: how do you find every place the library runs?

Use every inventory source you have and record which ones you used.

Exposure checklist (copy and use):

• Source repositories: direct and transitive dependencies from lockfiles (package-lock.json, yarn.lock, pom.xml with its resolved tree, build.gradle lockfiles, go.sum, requirements files, Gemfile.lock, composer.lock)
• Built artifacts: fat jars and shaded jars, bundled JavaScript, mobile app binaries and their embedded SDKs
• Container images: application layers and base layers, including images built months ago that still run
• Running workloads: what is actually deployed in production now, not what main says
• Store systems: in store servers, kiosks and handheld devices, many of which are vendor managed
• Bought software and SaaS: POS, payment gateway, commerce platform, search, CDP, email and SMS providers
• Internal tools, batch jobs and build caches, which are often forgotten

For each hit, record the service, version, environment, owner, whether it is internet facing, and whether it is in or connected to the CDE.

Commands you can run without any vendor tool. These only read, and they are standard package manager commands, not Safeguard commands:

# Node.js: show every path that pulls the package in
npm ls <package-name> --all

# Maven: show the resolved tree filtered to one artifact
mvn dependency:tree -Dincludes=<groupId>:<artifactId>

# Gradle: show which configuration pulls it in and why
./gradlew dependencyInsight --dependency <artifactId>

# Python: show what depends on the package
pip show <package-name>

# Go: list the module and the version actually selected
go list -m all | grep <module-path>

Replace the placeholders with the library's coordinates. For containers, search an SBOM of each image, and compare production image digests with the ones you scanned, because a tag can move.

Hour 2 to 6: rank exposure and decide what happens tonight

Use a decision table agreed in advance. The one below borrows BOD 26-04's four factors and adds the two that matter most in retail: CDE scope and reachability.

Treat "unknown" reachability as reachable. Reflection, dynamic loading and configuration driven code paths are exactly where static analysis is weakest, and attackers do not care that your analyzer gave up.

Hour 2 to 8: contain where you cannot fix yet

If the fixed version is not available, will not build tonight, or the system is vendor owned, use compensating controls and record each one:

• A temporary web application firewall rule for the exploit pattern in the advisory
• Disabling the vulnerable feature through configuration if the advisory names one
• Removing a system from the internet, which BOD 26-04 explicitly treats as a valid mitigation that changes the urgency
• Tightening egress from affected services so a successful exploit cannot easily call out

Hour 4 to 24: fix with pull requests, not tickets

1. Upgrade to the fixed version through the normal pipeline, with tests, even if the pipeline is running in an emergency lane.
2. Pin the version where your package manager allows it, and override transitive versions explicitly (for example npm overrides, Maven dependencyManagement, Gradle constraints), so a downstream library cannot pull the old version back.
3. Rebuild images from fresh base layers. Do not rely on build caches.
4. Check the advisory again before merging. The first fixed version is not always the last: during Log4Shell in December 2021, CISA's guidance moved through several versions before settling on 2.17.1 for Java 8.

Should we break the code freeze?

Usually yes, for this class of issue, but on the record. If no written emergency path exists, use this template:

Emergency change request (template):

• Change: upgrade library X from version A to version B in services S1, S2, S3
• Reason: critical CVE, [KEV listed / public exploit available / internet facing], advisory link
• Risk of change: test results, breaking change notes, rollback plan
• Risk of not changing: exposure summary from the decision table
• Approver: name and role, time approved
• Verification: how and when the fix will be confirmed in production

Hour 24 to 48: verify and narrow

1. Rescan what you shipped, not what you merged: built artifacts, images and running workloads. Confirm the vulnerable version is gone.
2. Check for compromise on internet facing systems that were exposed before the fix. BOD 26-04's forensic triage expectation is a good model: look at logs for the exploit pattern from the advisory window onward, check for unexpected processes, new outbound connections and new accounts.
3. Chase vendor statements. For POS, the payment gateway, the commerce platform and SaaS, you cannot patch their code. Ask each vendor for a VEX or CSAF statement per product and version, add compensating controls on your side, and record "under investigation" honestly until they answer.
4. Recheck KEV and EPSS. A CVE added to KEV over the weekend moves systems up the table.

Hour 48 to 72: hand off from incident to record

1. Close the incident or move it to monitoring, with a list of what remains open and who owns it.
2. Write down every risk acceptance and workaround with an expiry date. A workaround with no expiry becomes permanent by default.
3. Add a policy that blocks the vulnerable version in CI so it cannot come back with the next dependency update.
4. Brief leadership with the one page status below.
5. Schedule the post-incident review within two weeks, before peak season absorbs everyone.

What goes in the Monday morning status?

Keep it to one page. The CISO needs to make decisions, not read a log.

Illustrative scenario: a Friday night CVE at a composite retailer

This is a composite example, not a customer. The company, its systems and every number below are invented example inputs to show the workflow. None of them are results.

The company. "Northfield Outfitters" is a fictional US specialty retailer with about 300 stores, an e-commerce site, mobile apps, roughly 120 repositories and a vendor supplied POS. The security team is four people.

The trigger. At 21:40 on a Friday in late October, an advisory goes public for a critical deserialization flaw in a widely used open source parsing library. The advisory gives a CVSS base score of 9.8, names an affected version range and a fixed version, and mentions a public proof of concept. It is not on KEV yet, and its EPSS value is low on day one, as is common for brand new CVEs.

Hour 0 to 1. The on call security engineer, Priya (a fictional engineer), declares a vulnerability incident under the company's 12.10.1 plan, starts the log and pages the storefront on call.

Hour 1 to 4. The company's inventory shows the library in 14 repositories (example input). In 11 of them it arrives transitively. Six container images carry it, including one base image used by several internal services. Two of the hits are internet facing: the storefront's product search service and the API gateway plugin that handles loyalty account requests. One service, the order capture service, sits in the CDE.

Hour 2 to 6. Using the decision table, Priya ranks the hits:

Hour 4 to 24. Pull requests upgrade the library in the two tonight services, with explicit transitive overrides. The search service builds and passes tests; the loyalty plugin needs a small code change because a deprecated method was removed in the fixed version. Both deploy through the emergency change path, with a WAF rule as a stopgap on the loyalty API until its fix ships.

Hour 24 to 48. Order capture and the base image are fixed on Saturday. Rescans of running images confirm the vulnerable version is gone, and log review on the internet facing services finds no exploit pattern before the fix. The POS vendor answers on Sunday with a CSAF statement: known not affected for the current store software version.

Hour 48 to 72. On Sunday evening the CVE is added to KEV (still an example). Nothing internet facing remains exposed, so it only pulls the "before freeze" tier forward. The inventory sync service's "not reachable" decision is recorded as a risk acceptance with a two week expiry, and a CI policy now warns on the vulnerable version everywhere and blocks it on the storefront and CDE repositories.

What Northfield's assessor sees in February: a dated log, a ranked exposure list, merged pull requests, an approved freeze exception, rescans, a vendor CSAF statement, a time limited risk acceptance and a CI policy.

How Safeguard does this

Safeguard does not run your incident, decide on disclosure or talk to your vendors for you. It shortens and documents the parts of the weekend that depend on knowing which components run where, whether the vulnerable code is reachable, and whether a fix shipped and 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 Incident Response with Safeguard.

1. Keep a current inventory before the CVE arrives

SBOM generation and analysis (GA) builds SPDX and CycloneDX SBOMs for your projects, and SCA with deep transitive dependency scanning (GA) resolves the full dependency tree across npm, PyPI, Maven and Gradle, Go, Cargo, NuGet, Composer and Bundler, plus container layers. Asset discovery (GA) finds repositories, images and SBOMs you did not register by hand.

The Continuous Scanning docs describe re-evaluation driven by feed and asset changes: vulnerability feed updates (a new CVE, GHSA or OSV entry, a CISA KEV addition or an EPSS change affecting a component you use), and asset changes (a new commit, a new image tag or a newly uploaded vendor SBOM). New advisories are matched to components you already have indexed, so affected assets are rescored without you starting a scan.

For repositories that cannot be connected, the CLI (GA) scans a local directory, a repository, an image or an existing SBOM, as the CLI Usage docs show:

safeguard scan --dir .
safeguard scan --image myregistry.azurecr.io/myapp:v1 \
  --registry-username "$REGISTRY_USER" \
  --registry-password "$REGISTRY_PASSWORD"
safeguard scan --sbom sbom.json

To see results in the platform, the docs say to scan from the interactive terminal with /scan . while signed in, which uploads the SBOM and findings, never your source.

2. Ask where the library is, in plain English

Griffin natural language search (GA) runs across every indexed SBOM, component and vulnerability. The Search docs show plain term lookups (a package name, a CVE ID or a package and version) and plain English filters such as "reachable and exploitable vulnerabilities only". You can scope a query to one project with an @ mention, ask follow up questions in the same conversation, star the search so the whole team reuses it all weekend, and export results as JSON, CSV or PDF for the incident log.

The docs note one honest limit: search runs against data that has already been scanned and processed, so a scan still in progress may not show up yet.

3. Rank by exploitation, reachability and business context

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

Reachability analysis and prioritisation (GA) is described in Vulnerability Prioritization. It combines static reachability (a call graph from source, lockfiles and bytecode), dynamic reachability from a runtime collector, and configuration reachability, and classifies each finding as reachable, conditionally reachable, unreachable or unknown. Unknown is treated conservatively as potentially reachable, which matches the decision table earlier. Runtime labels for environment, exposure and data class (including PCI) and business context declared through policy push regulated, internet facing production findings higher.

Two cautions from the same page: reachability is weakest with reflection, eval and dynamic dispatch, and with data driven flaws. Those are common in parsing and deserialization libraries, so read "unknown" carefully.

4. Open the 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 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 across all fixable findings. Breaking change detection grades each fix as Safe, Minor, Major or Critical, and pull requests carry the CVE reference and test results when tests are configured.

Autonomous remediation ships switched off, with every category set to Manual. On a Friday night that default is useful: your engineers review and merge each pull request through the emergency path, and nothing merges itself.

From a laptop, the CLI's interactive terminal can do the same work in one repository, and the docs note that it asks before any command that changes something.

5. Record workarounds, risk acceptances and vendor statements

The Mitigations tab records four types: risk acceptance, false positive, workaround applied and not applicable. Each record carries a justification, an approver, optional evidence, a scope and, for risk acceptances, an expiry date with reminders 14 days and 7 days before and on the day. Every action is logged, and reports export as PDF, CSV or Excel. That covers the WAF stopgap, the "not reachable" decision and its expiry from the scenario. (The page's /v1 REST examples are not available yet, so use the app.)

CSAF and VEX upload (GA), described in CSAF/VEX Upload, accepts CSAF 2.0, CycloneDX VEX, OpenVEX and CSAF VEX profile files from Integrations, filtered by Upload. A vendor's "known not affected" statement then sits in the platform against the product and version it covers.

6. 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 it pass with a warning naming the policy, and Notify lets it pass and sends a notification to your configured channels. Approval for a legitimate exception runs through the exceptions workflow: a request with 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:

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

It exits non zero when the gate fails, and also when the gate is in error or was not evaluated before the timeout, so a broken check never reads as a pass. One practical note from the docs: policy outcomes are turned on per workspace by Safeguard, so confirm the Outcome column appears before you rely on it during an incident.

7. Approve from wherever the incident lead is

The mobile app (GA) lets you send work to a computer running the CLI and approve each command on the phone with Allow once, Allow for turn or Deny. On a Friday night, when the person who can approve is not at a desk, that keeps approvals moving without handing out broader access.

The weekend, mapped

What to measure

Measures for your own program, not outcomes Safeguard promises. Capture them per incident and compare over time.

• Time to exposure list: from advisory publication to a complete list of affected services, including transitive and image hits
• Inventory coverage: share of production services and images with a current SBOM (generated since their last deploy)
• Time to fix per tier: from advisory to verified fix in production, measured separately for each row of your decision table
• Verification gap: time between merge and a rescan confirming the vulnerable version is gone from running workloads
• Regressions: number of times the vulnerable version reappeared after being fixed
• Unknown reachability share: hits that could not be classified
• Open workarounds and acceptances: count, oldest age, and how many lack an expiry date
• Evidence completeness: share of affected systems with dated evidence for detection, fix and verification

What Safeguard does not do

• It does not fix code you do not build. POS software, payment gateways, the commerce platform and SaaS providers have to ship their own fixes. Safeguard can hold their SBOMs and VEX statements; it cannot patch their products.
• It does not decide materiality, breach status or customer notice. Whether an incident is material under SEC rules, whether card data was exposed, and what you tell card brands, acquirers, customers or regulators are decisions for your leadership, counsel and forensic investigators.
• It does not replace a forensic investigation. Checking for compromise needs log review and host analysis by your team or a response firm.
• It does not see what was never scanned. A forgotten server or unregistered repository stays invisible until it is discovered and scanned.
• Reachability is not proof of safety. "Unreachable" comes from analysis that has known weak spots (reflection, dynamic dispatch, data driven flaws). Treat it as a ranking input with evidence, not as a reason to skip the upgrade.
• It does not merge on its own by default. Autonomous remediation ships switched off with every category set to Manual. Your engineers still review, test, merge and deploy, and your change process still approves freeze exceptions.
• It is not your PCI assessment. Your QSA decides whether controls are in place.

Common mistakes

• Starting with patching instead of exposure. Teams that open pull requests before they have a full list fix the obvious services and miss the transitive ones.
• Trusting direct dependency searches. Most library CVEs reach you transitively. A repo grep for the package name misses shaded jars, bundled JavaScript and base images.
• Sorting by CVSS base score alone. Every hit is critical by base score. Exposure, KEV, EPSS, reachability and CDE scope are what separate tonight from Monday.
• Patching production directly. The next deploy reverts the fix.
• Leaving workarounds without an expiry. A WAF rule with no end date becomes your permanent fix.
• Skipping the compromise check. A system that was exposed before the patch may already be compromised. Patching does not remove an attacker.

FAQ

How fast do retailers have to patch a critical vulnerability under PCI DSS?

PCI DSS v4.0.1 requirement 6.3.3 asks for patches for critical vulnerabilities to be installed within one month of the patch's release, with other patches on a time frame you set by risk. v4.0.1 limited the one month rule to critical vulnerabilities. For an exploited library on an internet facing system, most security teams act within hours or days, well inside that limit.

Does PCI DSS require an SBOM?

Not by that name. Requirement 6.3.2 asks for an inventory of bespoke and custom software and the third-party components incorporated into it, to support vulnerability and patch management. An SBOM is the most practical way to meet that, and CISA's 2026 Minimum Elements describe what a good one contains.

Does BOD 26-04 apply to retailers?

No. It binds federal civilian executive branch agencies and, unless a contract requires it, not their contractors. Its four factor model (public exposure, KEV status, automatable exploitation, technical impact) is still a sound way for any organisation to rank a CVE.

What is the difference between CVSS, EPSS and KEV?

CVSS describes how severe a vulnerability is. EPSS estimates the probability of exploitation in the next 30 days. KEV lists vulnerabilities CISA knows are exploited in the wild. Use all three, then add your own exposure and reachability.

Should we break the holiday code freeze for a critical CVE?

For an internet facing or CDE system with a public exploit, usually yes, through a written emergency change path with an approver, a test result and a rollback plan. Write that path before November so the decision on the night is about this CVE, not about process.

What should we ask our POS and SaaS vendors?

Ask whether each product and version you run is affected, fixed, not affected or under investigation, and ask for the answer as a VEX or CSAF document where they can. Record the answer and the date, and follow up on anything still under investigation.

Do we have to disclose a vulnerable library to the SEC?

A vulnerable library is not, by itself, a cybersecurity incident. If your investigation finds an incident that the company determines is material, a public company must file Form 8-K Item 1.05 within four business days of that determination. That decision belongs to leadership and counsel.

How do we prove to our assessor that the fix stayed in place?

Keep dated rescans of running workloads after the fix, a CI policy that blocks or warns on the vulnerable version, and a record of any risk acceptances with expiry dates. Together they show detection, remediation and prevention, which is what the 6.3.x questions are after.

Related reading: SBOM incident response: finding affected products fast, an incident response playbook for a compromised dependency, a Java critical library CVE response runbook, the first 72 hours of a dependency incident at a digital health company, PCI DSS 4.0 software security requirements and the Safeguard CLI as a security aware coding assistant.

The weekend plan above assumes a fixed version exists and that you build the affected code yourself. When neither is true, or when the fix exists but has not reached your builds yet, these are the options for closing the gap.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real CLI session. 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 the parsing library in this post, one repository at a time.

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

The second 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 who is away from a desk.

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

The third 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 a repository that cannot be connected still gets into the exposure list.

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: BOD 26-04
• CISA: Cybersecurity Directives
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Apache Log4j Vulnerability Guidance
• CISA: VEX minimum requirements
• CISA: 2026 SBOM Minimum Elements announcement
• FIRST: Exploit Prediction Scoring System (EPSS)
• FIRST: CVSS v4.0
• NIST SP 800-61 Rev. 3
• NIST SP 800-40 Rev. 4
• OASIS: CSAF 2.0
• PCI SSC: Just Published, PCI DSS v4.0.1
• PCI DSS 4.0.1 changes, secondary summary
• SEC: cybersecurity disclosure rules, press release 2023-139
• Safeguard: Incident Response use case
• Safeguard docs: Vulnerabilities
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: Continuous Scanning
• Safeguard docs: Search
• Safeguard docs: AI Remediate
• Safeguard docs: Mitigations
• Safeguard docs: CSAF/VEX Upload
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: CI/CD Integration
• Safeguard docs: CLI Usage
• Safeguard docs: Asset Discovery

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