Hand Exploited Dependency Findings to Your Security Operations Team

To get your SOC to act when a library in production lands on CISA's Known Exploited Vulnerabilities (KEV) list, stop sending it "CVE in library X" and start sending it "this internet facing service runs exploitable code, here is the owner, here is what exploitation would look like, watch for it until the fix ships on this date". Hand over only the findings that clear a written bar (KEV listed or high EPSS, reachable, on a production asset that is exposed), deliver them by event or ticket into the queue the SOC already works, and close the record automatically when the fixed version is verified in production.

Most AppSec teams already know which dependencies are vulnerable. The gap is the handoff. A dependency finding is written for a developer: a package, a version, a pull request. A security operations center works in assets, exposure, detections and incidents. Without translation, the SOC either ignores the finding or drowns in every CVE in every repository.

This post is for the vulnerability management or AppSec lead at a US bank, insurer or SaaS company where a separate SOC owns detection and response.

Key takeaways

• Do not forward every CVE. Hand over a finding only when exploitation is known or likely (KEV listed, or a high EPSS probability) and the vulnerable code is reachable on an exposed production asset.
• The handoff record is about the asset, not the package: service, owner, exposure, component and version, exploit status, reachability, compensating controls, fix date and a stable ID for deduplication.
• NIST puts both jobs in one model. SP 800-61 Rev. 3 (April 2025) maps incident response onto the six CSF 2.0 Functions, so vulnerability identification (ID.RA) feeds detection (DE) and response (RS) instead of living in a separate silo.
• BOD 26-04 is a useful federal model, not a private sector rule. Its four urgency factors (asset exposure, KEV status, exploit automation and technical impact) and its forensic triage guidance translate well into a bank or SaaS handoff policy.
• Push urgent items, pull the rest, and close on verified resolution in what is running, not on a merged pull request.
• Safeguard capabilities covered, with maturity labels: vulnerability management with EPSS and KEV enrichment (GA); reachability analysis and prioritisation (GA); asset discovery (GA); policies and gates (GA); webhooks and events, created on the Webhooks page in the app (GA); Slack, Microsoft Teams and Discord notifications and Jira ticketing (GA, notification first, with limits below); Portal audit trails with SIEM export (GA); autonomous remediation with Griffin fix pull requests (GA, ships switched off); Gold Open Source (GA); the Safeguard MCP server and CLI (GA); the mobile app.

Why does the handoff between AppSec and the SOC break?

The two teams look at the same vulnerability through different lenses, and each lens is reasonable on its own terms.

AppSec sees the software bill of materials: a parsing library at a vulnerable version, three levels deep in the transitive tree of a payments service. The next step is a ticket and a pull request. Success is time to fix.

The SOC sees the running estate: network flows, processes, authentication events, web requests. Its unit of work is an alert or case tied to a host, container or account. Success is time to detect and contain.

When that library's CVE is added to the KEV catalog, both views matter at once. The fix may take days if the upgrade is a major version or the service is in a change freeze, and only the SOC can notice exploitation attempts in the meantime. Usually it never hears about the finding, or hears in a form it cannot use.

Three failure patterns show up again and again.

The firehose. Every new finding goes to the SOC queue. Within a week the analysts mute it, and the one KEV listed finding on an internet facing payment API arrives in the muted stream.

The silent fix. AppSec handles the KEV finding inside engineering and the fix merges four days later. Nobody told the SOC, so nobody watched the exposed service. If an attacker got in on day two, the fix closes the door behind them and the compromise goes unnoticed.

The orphaned alert. The SOC opens a case and adds a watch rule, then never hears that the fix shipped. The rule stays forever and the case ages in the queue.

A good handoff design fixes all three: a narrow, written entry bar; a record shaped for the SOC; and an automatic close.

How do NIST SP 800-61 Rev. 3 and NIST CSF 2.0 link vulnerability management and incident response?

NIST published SP 800-61 Rev. 3, "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile", in April 2025. It supersedes Rev. 2 from 2012 and makes a structural change that matters for this handoff.

Rev. 2 described incident response as its own life cycle. Rev. 3 maps it onto the six Functions of the NIST Cybersecurity Framework 2.0: Govern, Identify, Protect, Detect, Respond and Recover. NIST treats Govern, Identify and Protect as broader risk management work that also prepares for incidents, and Detect, Respond and Recover as incident response itself, with lessons flowing back through the Improvement category (ID.IM).

For the AppSec to SOC handoff, that means vulnerability management is not a neighbouring discipline. It is the Identify half of the same model.

The CSF 2.0 outcomes that frame the handoff

The relevant CSF 2.0 subcategories, as worded in the framework and profiled in SP 800-61 Rev. 3, are these:

SP 800-61 Rev. 3 also spells out the four classic risk responses under ID.RA-06: accept, mitigate, transfer and avoid. "Mitigate" in its wording explicitly includes deploying additional security controls to reduce exploitation, which is the SOC's role while the patch is pending. The handoff record is how the mitigate decision reaches the people who carry it out.

What BOD 26-04 adds as a model

On 10 June 2026 CISA issued Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk". It revokes and supersedes BOD 22-01 (the 2021 directive that created the KEV catalog) and BOD 19-02. It binds federal civilian executive branch agencies, not banks, insurers or SaaS companies, and CISA's KEV page says plainly that other organizations are not bound by it but are strongly encouraged to prioritise KEV remediation. So treat it as a well designed public model, not as your compliance requirement.

Three parts of it are worth borrowing.

Four urgency factors. BOD 26-04 sets remediation urgency from four variables: whether the asset is publicly exposed, whether the CVE is on the KEV catalog, whether exploitation can be automated, and whether it gives an adversary partial or total control. CISA publishes the last three for every CVE through its Vulnrichment program, and the directive's Table 1 (published as an image; read it on CISA's page) turns the combinations into timelines. The lesson for a private company: exposure and exploitation status together decide urgency, not CVSS alone.

Asset tagging. Phase III of the directive asks agencies to tag every asset that can be reached from outside with its organization, environment (production or development), exposure (public or internal) and asset type. Those are exactly the fields a SOC needs on a dependency finding, and exactly the fields most SCA output lacks.

Forensic triage. CISA's implementation guidance for BOD 26-04 sets out six forensic triage steps after a KEV addition: scoping, preserving and collecting evidence, critical patching and stabilization, containing and controlling, triage analysis, and an escalation decision backed by a written triage report. The guidance attaches recommended hour targets to each step, starting from the moment of the KEV addition, and states that the requirement is an adequate triage, not the specific timeline. This is a direct statement that a KEV addition is a SOC event as well as a patching event: someone has to ask whether the vulnerable system was already compromised.

Which dependency findings justify SOC attention?

Write the entry bar down, agree it with the SOC lead, and keep it narrow. A good bar uses the same signals CISA uses, adapted to application dependencies.

The five signals

1. KEV listing. CISA lists a CVE when it has a CVE ID, reliable evidence of active exploitation in the wild, and a clear remediation action. A listing ends the "is this real?" debate. The catalog held more than 1,700 entries when we checked on 25 October 2026; each carries a date added, a federal due date, a known ransomware use flag and a notes field.

2. EPSS probability. FIRST's Exploit Prediction Scoring System estimates the probability that a CVE will see exploitation activity in the wild within the next 30 days, as a score from 0 to 1, updated daily. It is a forward looking signal for CVEs that are not yet on KEV. FIRST's FAQ is careful to separate the probability from the percentile: a probability of 0.10 sits around the 95th percentile, because most CVEs score very low. Pick a probability threshold, not a percentile, and review it quarterly.

3. Reachability. A vulnerable function that your code never calls is a much weaker case for SOC time than one on the request path. Static reachability from a call graph tells you whether a path exists. It does not prove exploitability, and it is weakest for reflection, dynamic dispatch and data driven bugs, so "unknown" must count as reachable for this purpose.

4. Exposure and environment. The SOC's detection value is highest on services untrusted users can reach: public web apps, APIs, partner integrations, upload endpoints. Production beats staging; internet facing beats internal.

5. Fix status. A fix shipping today means a short watch. No fix, or a breaking major upgrade, means a long watch where compensating controls matter more. It changes what you ask the SOC to do, not whether you ask.

A decision table you can adopt

The tiers below borrow the outcome names CISA uses in its Stakeholder Specific Vulnerability Categorization (SSVC) guide, where Track means routine handling, Attend means supervisory attention, and Act means immediate action by leadership level stakeholders. Adjust the thresholds to your own risk appetite.

Two rules keep the table honest. A finding moves up a tier the moment its inputs change, such as a new KEV listing, so the handoff must be event driven, not monthly. And any Act tier item with no fix available gets a recorded compensating control decision, because the watch will be long.

What should the handoff record contain?

The handoff record is the contract between the teams. If a field is missing, an analyst has to go and find it at three in the morning, and most will not. Build the record around the asset and the watch decision.

Fields the SOC needs

The "what exploitation would look like" field should describe observable behaviour in plain words: which route receives attacker controlled input, and what success might cause (an unexpected child process, new outbound connections, new files in a web root, a spike in errors). No exploit code or payloads; analysts write the detections.

An illustrative record

Here is an illustrative handoff record. The field names are ours, not a standard, and the values are invented:

{
  "handoff_id": "vm-2026-10-25-0042",
  "tier": "act",
  "asset": {
    "service": "payments-api",
    "environment": "production",
    "exposure": "internet-facing",
    "image_digest": "sha256:...",
    "owner_team": "payments-platform"
  },
  "finding": {
    "cve": "CVE-YYYY-NNNNN",
    "component": "example-parser",
    "installed_version": "2.3.1",
    "fixed_version": "2.3.4",
    "kev_listed": true,
    "kev_date_added": "2026-10-24",
    "epss": 0.41,
    "reachability": "reachable"
  },
  "watch": {
    "exploitation_signals": "Malformed document bodies on the upload route; parser errors followed by outbound connections from the service",
    "compensating_controls": ["request size limit on upload route"],
    "fix_eta": "2026-10-28"
  },
  "close_when": "fixed_version verified in production image"
}

If your SOC normalises events to the Open Cybersecurity Schema Framework (OCSF), the closest event class is Vulnerability Finding, class 2002, in the Findings category. OCSF defines its activity as Create, Update or Close, which maps neatly onto the life of a handoff: open the watch, change the tier, stand down. Mapping your record onto that class saves the detection engineering team from writing a custom parser.

Push or pull: which delivery suits a SOC?

There are four common delivery shapes, and most mature programs use more than one.

For a SOC, push beats pull for anything urgent. Analysts work a queue fed by their own tooling; they do not poll a vulnerability console. Send a signed event for each Act or Attend tier change into the SOC pipeline, let it open or update a case, and mirror the finding into the engineering tracker as a ticket carrying the fix plan. Chat is the human echo, not the system of record. And filter at the source: a feed of only KEV listed findings on production assets beats a full feed filtered downstream.

What can the SOC do before the fix ships?

This is the part of the handoff that justifies the SOC's time. A dependency fix might take hours or weeks. During that window the SOC has real options, ordered here from lightest to heaviest.

Triage for prior compromise. As CISA's forensic triage guidance implies, first ask whether the vulnerability was already used: scope which hosts run the vulnerable version, preserve logs before they roll over, and look back for the signals in the handoff record.

Heightened monitoring. Retain edge request logs, raise logging on the affected route, and add detection logic for the exploitation signals, including behaviour the service has never shown before. It is cheap, reversible and almost always justified for an Act tier handoff.

Temporary blocking rules. Where the attack surface is a specific route or input shape, a web application firewall rule or API gateway rule can block or rate limit it. This is often called virtual patching; our explainer on what virtual patching is and when it helps covers when it works and when it gives false comfort. Every temporary rule needs an owner and a removal date tied to the fix.

Feature or route disablement. If the vulnerable code sits behind a feature that can be switched off, the service owner can disable it. That is an "avoid" risk response under ID.RA-06; the SOC should know it happened.

Isolation. If triage finds signs of exploitation, the case leaves the handoff process and enters normal incident response under the RS Function: pulling instances, rotating the service's credentials, rebuilding from a known good image.

Compensating controls reduce risk but never justify dropping the fix, and each one must be recorded on the handoff or closure will leave it behind.

How do you close the loop and stop duplicate alerts once the fix is deployed?

Closure is where most handoff programs leak. Design it before the first handoff goes out.

Define "resolved" as verified in production. NIST SP 800-40 Rev. 4 (April 2022) defines patch management as identifying, prioritizing, acquiring, installing and verifying the installation of patches. Handoffs forget the last verb. A merged pull request is not a fix in production. A deployed image is closer. The strongest evidence is a fresh scan of what is running (the deployed container image, or the service's current SBOM) showing the fixed version. Only that should flip the SOC case to "stand down".

Use one stable ID end to end. Every event, ticket and chat message about the same finding on the same asset carries the same handoff ID. The SOC pipeline treats a second event with that ID as an update, not a new case. If your delivery mechanism is at least once, which most webhook systems are, deduplication on an event ID is mandatory, not optional.

Close the compensating controls too. The closing step should list the temporary rules recorded on the handoff for removal, or they become unexplained rules in two years.

Keep reopening cheap. If the vulnerable version returns in a later build, reopen the same handoff ID. Our post on stopping a fixed vulnerability from being reintroduced covers the gate side of that problem.

Record exceptions with expiry. A risk acceptance needs an approver, an expiry date and a decision on whether the SOC watch continues.

How Safeguard does this job, step by step

Safeguard covers the AppSec side of the handoff: finding the vulnerable component, enriching it with exploitation and reachability data, deciding what crosses over, and delivering and closing the record. The SOC's detection and response tooling stays the SOC's. Here is the flow using what Safeguard's docs describe today.

1. Get what is actually deployed into Safeguard

Connect source control so projects are scanned continuously, and scan the artifacts you deploy, not only repositories. The Safeguard CLI (GA) scans a directory, a container image or an existing SBOM:

safeguard scan --dir .
safeguard scan --image <name>
safeguard scan --sbom <file>

Scanning the image you run in production lets you say "this service runs the vulnerable version", not "this repository mentions it". Asset discovery (GA) inventories repositories, images, packages, SBOMs and workloads, which catches services nobody registered.

2. Let continuous scanning and enrichment run

Vulnerability management (GA) re-evaluates projects as new CVEs are published; the docs describe daily continuous scanning against the NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins. Each vulnerability shows CVE ID, CVSS, EPSS, an Exploitable flag for known exploitation in the wild, affected component and version, fixed version and reachability. The Vulnerabilities tab groups findings into Critical, High, Medium, Low and Exploitable; the last is the bucket the SOC cares about.

3. Rank by reachability, exploitability and exposure

Reachability analysis and prioritisation (GA) combines four signals: reachability, exploitability (EPSS and KEV), runtime context and business context. How much it shrinks the urgent queue depends on your codebase, so measure it on your own projects during evaluation. Static reachability is listed for JVM languages, Python, JavaScript and TypeScript, Go, Rust, C and C++, C# and .NET, Ruby, PHP, Swift and Objective C. Findings the analyser cannot decide are marked unknown and not suppressed.

Each finding gets a Priority Score from 0 to 100. Per the docs, the default ordering puts reachable, KEV listed findings in production at the top band, with weights configurable under Settings › Prioritization. The Vulnerabilities table supports filters that map directly onto the Act tier above:

env:production reachable:true kev:true

The docs call that filter "the P0 backlog". The exposure label (internet facing or internal) is one of the runtime context inputs; check during evaluation how those labels are populated for your services, because the tier decision depends on them.

4. Turn the entry bar into a policy

Policies and gates (GA) let you encode the bar instead of keeping it in a wiki. Safeguard's reachability docs show this production admission policy as an example:

- id: no-reachable-kev-in-prod
  condition: |
    env == "production"
    AND any(vulnerabilities,
      reachability_class in ["reachable", "conditional"]
      AND kev == true
    )
  effect: BLOCK

The same condition does double duty: as a gate it stops releases that would add a reachable KEV listed component, and a violation on a running service produces a policy.violation event you can route to the SOC.

5. Subscribe the SOC pipeline to events

Webhooks and events (GA) are how a handoff reaches the SOC's own tooling. The docs say webhook subscriptions are created on the Webhooks page in the app, with no CLI command yet. A subscription takes an endpoint URL, the event types, a signing secret and an optional filter.

The event types that matter for this handoff, as named in the docs:

The docs show server side filters written in a subset of the policy expression language, for example:

severity in ["critical","high"] AND env == "production" AND finding.kev == true

Filtering at the source is what keeps the SOC feed narrow. Per the docs, payloads carry an event ID, type, timestamp and a data object holding the finding and the asset. Delivery is at least once, with exponential backoff retries over 24 hours and a dead letter queue you can replay from the UI. Consumers are expected to deduplicate on the X-Safeguard-Event-Id header, and every payload is signed in an X-Safeguard-Signature header. The docs include a short Python example that checks the signature and rejects events older than five minutes.

The docs also describe direct delivery into managed cloud streaming services, and into Kafka and similar systems through a webhook sink. Build on webhooks for dashboards.

On the SOC side, a small receiver you write and run verifies the signature, maps the payload to your handoff record (or OCSF Vulnerability Finding), and creates or updates a case keyed on finding and asset.

6. Add a human echo in chat

Slack, Microsoft Teams and Discord notifications are configured under Settings › Integrations: click Connect on the tile, choose an authentication type, let Safeguard validate the credentials, then choose a default channel. The ChatOps docs are candid about limits today. Every integration sends to one default channel (or team and channel, for Teams). Per event channel routing exists in the data model but has no UI yet, so severity filtering happens upstream through webhook filters rather than in the chat settings. Teams is notification only. Inbound slash commands for Slack and Discord exist in the data model but cannot be switched on from Settings. The offering files also list Google Chat for notifications.

Use chat as a shared awareness channel; keep the record in events and tickets.

7. Open and sync the engineering ticket

The Jira integration is set up under Settings › Integrations › JIRA: click Connect JIRA, enter the instance URL, email or username and API token, click Test Connection, then Save, and map Safeguard organizations to Jira projects with an issue type and default assignee. Safeguard's ESSCM Jira page says a separate Jira integration guide lists the exact token permissions and current setup steps, and that the guide wins where the two differ.

Trigger rules create issues for new critical or high vulnerabilities, gate failures and policy violations. Two way status sync, when enabled, marks a finding resolved when its issue moves to Done or Resolved, creates a risk acceptance on Won't Fix, transitions the issue to Done when the finding resolves, and updates priority on a severity change. The docs also describe rescanning the project when a Jira issue closes, which is the right shape for "verified, not just closed". Manual creation is under Actions › Create JIRA Issue in the Findings tab. The offering files list Notion, Microsoft Planner, Linear and Asana as other ticketing destinations.

8. Ship the fix

Autonomous remediation (GA) uses Griffin to open a tested, policy gated pull request that moves the dependency to the fixed version, on one repository or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs automatically. From the Vulnerabilities page, AI Remediate generates remediation plans for review before any pull request is created. Gold Open Source (GA) at gold.safeguard.sh is free, needs no login, and gives CVE intelligence with affected and fixed versions, which helps confirm the safe version quickly.

The remediation.pr_opened and remediation.pr_merged events let the SOC case show fix progress without anyone updating it by hand.

9. Close on verified resolution

When a rescan confirms the fixed version, Safeguard emits findings.vulnerability.resolved, described in the docs as upgrade, patch or removal verified. That event is your stand down signal. Your receiver closes the SOC case, lists the temporary controls recorded on it for removal, and the Jira issue transitions to Done through the status sync. If the vulnerable version reappears, a new finding fires and, keyed on the same component and asset, your receiver can reopen the case.

If the business accepts the risk instead, the Accept Risk action in the Vulnerabilities tab records a justification and an expiration date and can require approval. The policy.exception_expired event tells the SOC when the acceptance lapses.

10. Keep the evidence

Portal audit trails (GA) log timestamp, actor, action, resource, IP address and result. View them under Settings › Audit Logs, export CSV, JSON or PDF, or send them to a SIEM under Settings › Integrations › SIEM, where the docs list several SIEM destinations and a custom webhook. With ticket history and webhook delivery records, that gives a timeline of who knew what, and when.

Requirement, Safeguard, and what you still own

How do you measure the handoff?

Measure the handoff, not just the patch. Four numbers tell you whether it works.

Time from KEV addition to SOC awareness. Start the clock at the catalog's "date added" and stop it when the SOC case opens. An event driven pipeline should measure this in hours; days means a manual step somewhere.

Findings open past their exposure window. For every Act tier handoff, compare the agreed fix ETA with the date the findings.vulnerability.resolved event fired. Count how many ran over and by how much. This is the number leadership should see, because it measures how long exposed, exploited code stayed in production.

Watch coverage. The share of Act tier handoffs where the SOC recorded a monitoring or blocking action. A low number usually means the record lacks asset or exploitation fields.

Stale cases and orphaned controls. SOC cases still open after the finding resolved, and temporary rules still active after closure. Both should trend to zero once the closing event is wired up.

Safeguard's reachability docs describe a Prioritization dashboard with time to remediate by priority band and backlog aging. The SOC side comes from your case management system, joined on the stable handoff ID.

What Safeguard does not do

Be clear about the boundaries before you design around them.

• It does not detect exploitation attempts in this flow. Safeguard tells you a service runs exploitable code. Watching network traffic, web logs and process behaviour for attacks is the SOC's tooling. This post deliberately does not rely on Safeguard's newer runtime and SecOps engines, which are generally available.
• It does not write your SOC's detection rules or runbooks. The "what exploitation would look like" field comes from advisories and your own analysis. Translating it into detections, deciding on blocking rules and running triage are SOC work.
• Webhooks are configured in the app. Webhook subscriptions are created on the Webhooks page in the app; there is no CLI command for subscriptions or polling. Plan on webhooks.
• Chat routing is coarse. Each chat integration sends to one default channel; per event routing and inbound commands are in the data model but not self-service. Teams is notification only.
• Service mapping depends on what you scan. If you scan repositories but not the images you deploy, Safeguard cannot know which version runs in production, and exposure labels are only as good as the asset data behind them.
• Reachability is a prioritisation signal, not proof. It is weaker for reflection, dynamic dispatch and data driven bugs, and static analysis depth varies by language.
• It does not fix code in appliances, hosted services or operating system packages you do not build. The fix flows apply to dependencies and images you build and ship.
• It does not own your SOC tooling. Case management, paging, SIEM content and retention policies stay in your own systems.

Common mistakes

Forwarding every new CVE. The SOC mutes the feed within days, and the real KEV handoff drowns. Filter at the source on KEV, exposure and environment.

Handing over package names instead of assets. The record must name the service, hosts or image digest, and owner.

Using CVSS as the bar. CVSS describes severity, not likelihood. A medium score on KEV on an internet facing API outranks an unreachable critical.

Closing on merge. A merged pull request may sit undeployed for a week. Close the SOC case on verified resolution in what is running.

Forgetting the temporary controls. Blocking rules added during the watch window become permanent unless the closing event lists them for removal.

No dedup on at least once delivery. Webhook retries create duplicate cases unless the receiver keys on the event ID.

Ignoring the look back. A KEV listing means exploitation is happening somewhere already. If the service was exposed before you knew, the SOC should check for prior compromise, not only watch forward.

FAQ

What is the CISA KEV catalog and who has to follow it?

CISA's list of vulnerabilities with reliable evidence of exploitation in the wild. Federal civilian agencies must remediate listed entries under BOD 26-04; private companies are not bound, but CISA recommends everyone use it to prioritise.

Should the SOC get every vulnerability finding?

No. Send only findings that combine exploitation (KEV listed or a high EPSS probability), a reachable or undecided code path, and a production asset that is exposed. Everything else is engineering's backlog.

Is BOD 22-01 still in force?

No. BOD 26-04, issued on 10 June 2026, revoked and superseded BOD 22-01 and BOD 19-02. It carries the KEV catalog criteria forward and adds risk based timelines from four factors.

How does NIST SP 800-61 Rev. 3 connect vulnerability management to incident response?

It maps incident response onto the six CSF 2.0 Functions: vulnerability identification and risk responses (ID.RA) in Identify, monitoring in Detect (DE), containment in Respond (RS), with lessons flowing back through Improvement (ID.IM).

Can the SOC do anything before a patch is available?

Yes: triage for prior compromise, raise monitoring, add temporary blocking rules at the edge, or disable the affected feature with the service owner. If exploitation is found, incident response takes over.

How do we stop duplicate alerts when the same finding fires again?

Give each handoff a stable ID and make the SOC receiver treat repeat events with that ID as updates. Safeguard's webhooks are delivered at least once, and its docs ask consumers to deduplicate on the event ID header.

How do we know when the SOC can stand down?

When a rescan of what is actually running confirms the fixed version. In Safeguard, that is the findings.vulnerability.resolved event, which the docs describe as upgrade, patch or removal verified.

Can Safeguard send findings straight into our SIEM?

Safeguard's documented paths are signed webhooks (and stream delivery) for findings and events, and audit log delivery to a SIEM from the Portal audit trails settings. Plan on webhooks configured in the app.

When the fix itself is the bottleneck

Every handoff in this post exists because a fix takes time to reach production, and the SOC carries the risk for as long as that takes. Shortening that window, or covering the case where no fix exists yet, shrinks the watch the SOC has to keep.

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

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. 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 Claude connected to the Safeguard MCP server (GA) with OAuth, and how you choose which Safeguard tools Claude can use. For a SOC handoff, the same connection lets an analyst ask an assistant about the findings and projects in scope, for example which production findings are KEV listed, without learning the vulnerability console.

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

The second demo is a real Android session with the Safeguard mobile app: you send work to a computer running the Safeguard CLI and approve the command on the phone with Allow once, Allow for turn or Deny. When a KEV listing lands out of hours, an on call engineer can start the fix from a phone and still approve each command.

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

The third demo is a real Safeguard CLI session: install, run safeguard and ask it to "fix the lodash CVE in this repo". 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, prints a summary and pushes nothing, then shows /permissions, /model and /scan. That is the fix half of the handoff: the faster it runs, the shorter the SOC's watch.

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 .

For more on the SOC side, see how SIEM tools change an alert queue, how to route security alerts by on call hours and severity, and how big the KEV watch job is day to day. On the contract side, see keeping a contract promise of no known exploited vulnerabilities.

Quick check

Sources

• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Reducing the Significant Risk of Known Exploited Vulnerabilities
• CISA: BOD 26-04, Prioritizing Security Updates Based on Risk
• CISA: BOD 26-04 Implementation Guidance
• CISA: Stakeholder Specific Vulnerability Categorization (SSVC)
• NIST SP 800-61 Rev. 3 publication page
• NIST SP 800-61 Rev. 3 (PDF)
• NIST Cybersecurity Framework 2.0 (NIST CSWP 29, PDF)
• NIST Cybersecurity Framework
• NIST SP 800-40 Rev. 4
• FIRST: Exploit Prediction Scoring System
• FIRST: EPSS FAQ
• OCSF schema
• OCSF: Vulnerability Finding class
• Safeguard docs: Webhooks and Events
• Safeguard docs: Slack, Teams and Discord
• Safeguard docs: ESSCM Vulnerabilities
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: Portal Audit Trails
• Safeguard docs: JIRA Integration
• Safeguard Gold Open Source

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