A CFO's guide to the cost of open source risk and security tooling

Open source risk costs what a bad week costs you: response hours, interrupted revenue, contract fallout and a disclosure clock, weighted by how likely that week is. Security tooling should cost less than the slice of that expected loss it removes, measured on total cost of ownership rather than the invoice. If nobody can show you which slice a tool removes, the right price for it is the price of the tool you already own that does the same thing.

That is the whole argument. The rest of this guide gives a controller or CFO the method behind it: where the reliable loss numbers come from, how to turn an engineering backlog into a figure that belongs on the risk register, how to cost a security stack properly, and which questions separate spend that changes outcomes from spend that only changes dashboards.

Key takeaways

• Price the distribution, not the average. The best public loss data now comes from insurance claims, and it shows a modest median with a very long tail. Budget for the tail you cannot insure, not for the mean.
• Open source is a concentration risk. A small number of widely used components and maintainers carry most of the value your products depend on, so one bad component can touch most of your revenue at once.
• Response labor is the cost nobody books. A federal review of Log4j found one cabinet department spent 33,000 hours on the response. Your version of that number sits in engineering time that never shows up as a security line item.
• Cost tools on total cost of ownership. License or usage fees are often the smaller part. Integration, triage hours, duplicate findings, evidence collection and exit cost decide whether a tool is cheap.
• Fund what changes the tail. Spend that shortens time to fix exploited vulnerabilities in revenue systems is worth more than spend that grows a findings count.
• Ask for unit costs. Cost per covered application, cost per fixed known exploited vulnerability and cost per audit control evidenced make security spend comparable to every other line in your budget.
• Safeguard capabilities covered here, all GA: SBOM generation and SCA, vulnerability management with EPSS and KEV, reachability prioritisation, policies and gates, autonomous remediation (ships switched off, every category set to Manual), analytics dashboards and exports, the compliance and GRC suite, TPRM, and deployment choices including Zero AI mode.
• This is a financial method, not legal, accounting or audit advice. Materiality, disclosure and capitalisation calls belong to you, your counsel and your auditors.

The situation

Budget season is open. The CISO has asked for more money and brought a slide that says the company has thousands of open vulnerabilities in open source components. The controller has a stack of renewals: a dependency scanner, a code scanner, a container scanner, a compliance tool, a vendor risk tool, and a line of professional services from last year's audit. Two of those renewals are up this quarter and both vendors say their price is rising.

Meanwhile the board's audit committee wants to know whether cyber risk is in the enterprise risk register, how it is sized, and whether the company could meet a four business day disclosure clock if something went wrong. The insurance broker has sent the renewal questionnaire, which asks about patching cadence and software inventory. And a large customer's security review has stalled a contract until the company can produce a software bill of materials (SBOM).

None of these questions is about technology. Each is about money: how big is the exposure, how much is insured, what are we paying to reduce it, and is that payment working. A bad week for a finance leader is not the breach itself. It is the board meeting after the breach where someone asks what the security budget bought, and the honest answer is a pile of tools that each reported a different number.

The rules and reference points behind the numbers

Finance leaders do not need to read security standards line by line, but four sets of documents shape what "good" looks like and what a board, regulator or insurer will ask.

SEC disclosure: Regulation S-K Item 106 and Form 8-K Item 1.05

For US public companies, Regulation S-K Item 106 asks for a description of the processes used to assess, identify and manage material risks from cybersecurity threats, including whether those processes cover risks from third-party service providers, whether the company engages assessors, consultants or auditors, and how the board oversees cybersecurity risk and which management roles are responsible. Form 8-K Item 1.05 requires disclosure of a material cybersecurity incident within four business days of the company determining that it is material.

Two consequences matter for budgeting. First, the risk management process itself is a disclosed fact, so a security program that cannot describe how it finds and ranks risk becomes a disclosure weakness, not just an operational one. Second, the materiality determination needs facts fast: what is affected, which products, which customers. A company that cannot answer "do we use this component, and where" within a day will struggle with a four business day clock that starts when materiality is decided. Private companies are not bound by these rules, but lenders, acquirers and enterprise customers increasingly ask the same questions.

NIST IR 8286: cybersecurity risk inside enterprise risk management

NIST's IR 8286 series is the clearest public guide to putting cyber risk on the same register as every other enterprise risk. It describes cybersecurity risk registers that roll up into the enterprise risk register, and later volumes cover identifying and estimating risk, prioritising it, and (in IR 8286D) using business impact analysis to quantify the organisational impact. NIST publishes a risk register schema alongside the series. For a CFO this is useful because it frames security as a portfolio of risks with owners, likelihoods, impacts and responses, which is how finance already thinks.

NIST SP 800-218, the Secure Software Development Framework

The SSDF is the reference most enterprise customers and US agencies use when they ask how software is built. Two practice groups matter for cost. PW.4 asks producers to reuse existing, well-secured software where feasible instead of duplicating functionality, which is the formal case for using open source at all. The RV practices (respond to vulnerabilities) ask producers to identify and confirm vulnerabilities on an ongoing basis and to assess, prioritise and remediate them. In plain terms, using open source is expected, and so is a working process for keeping it patched. The cost of that process is a cost of doing business, not an optional extra.

Exploitation signals: CISA KEV and FIRST EPSS

Two free public feeds tell you which vulnerabilities attackers actually use. CISA's Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with evidence of exploitation in the wild. FIRST's Exploit Prediction Scoring System (EPSS) publishes, every day and for every published CVE, a probability that it will be exploited in the next 30 days. These matter to finance because they turn "thousands of vulnerabilities" into a short list with a likelihood attached, which is the input any expected loss calculation needs.

What open source risk actually costs: the evidence

There is more bad data about breach costs than good. The sources below are primary, recent and transparent about method. Each is named in full in the Sources list at the end.

Open source carries most of the value, and the value is concentrated

A Harvard Business School working paper on the value of open source software estimated the cost to recreate widely used open source once at about $4.15 billion, and the value to the firms that use it (the cost each would bear to build it internally) at about $8.8 trillion. The same paper found that 96% of the demand-side value was created by only 5% of open source developers.

Read that as a finance person would. Your products depend on assets you did not pay for, that you could not afford to rebuild, and whose upkeep rests on a small number of people you have no contract with. That is a concentration risk. When one of those components breaks, it rarely breaks for one product; it breaks for most of them at once.

Breach losses are a long-tailed distribution

The most useful new source for finance teams is the 2026 Breach Impact Study, written by the authors of the annual Data Breach Investigations Report from about 70,000 US cyber insurance claims (of which about 38,000 recorded paid losses) covering incidents from 1 January 2019 to 31 October 2025. It reports medians and percentiles of "ground-up loss" (the claim plus the deductible), and the authors note that insurable loss is likely a conservative lower bound of true economic loss.

The headline figures:

Three points follow. The typical claim is survivable; the tail is not. Software supply chain incidents are rare in the claims data but have a median roughly three times the overall median, and the study notes that the extreme cases represent coverage caps rather than the victims' real economic loss. And half of the known loss in supply chain or third-party incidents is business interruption, which is exactly the cost your policy may sublimit and your income statement absorbs.

For context, the 2026 Cost of a Data Breach study, run with the Ponemon Institute, puts the global average cost of a data breach at $4.99 million, up 12% on the prior year. That is an average across surveyed breaches, so it sits far above the claims median. Both can be right: averages are pulled up by the tail. When someone quotes you a single "cost of a breach" figure, ask whether it is a mean or a median, and from what sample.

Software vulnerabilities are now the top way in

The 2026 Data Breach Investigations Report says 31% of breaches now start with the exploitation of software vulnerabilities, ahead of stolen credentials as the leading initial access route. Open source components are a large share of the software most companies run, so the patching process for those components is now a primary control, not a hygiene task.

Response labor is real money

The US Cyber Safety Review Board's report on the Log4j event recorded that one federal cabinet department dedicated 33,000 hours to the Log4j response, and that responses sustained over weeks and months delayed other mission-critical work. The board judged Log4j an "endemic vulnerability" likely to remain in systems for a decade or longer.

Put 33,000 hours against a fully loaded engineering rate and the cost is large before a single attacker shows up. Most of that cost was not breach cost. It was the cost of not knowing where the component was. That distinction is the centre of this guide: much of open source risk is paid as response labor and delayed roadmap work, and it lands in engineering budgets where nobody labels it security.

Step by step: put a number on open source risk

This method works with a spreadsheet and whatever tools you already have. It follows the NIST IR 8286 idea of a risk register with likelihood, impact and response, and uses the claims data above to calibrate. Every figure in the worked example is illustrative.

1. Get an inventory you trust

You cannot price what you cannot list. Ask engineering for an SBOM for each product or major application: the list of components, including transitive dependencies (the components your components pull in). If they cannot produce one in a week, record that as a finding in its own right. A missing inventory is the root cause behind most of the Log4j response hours.

2. Map software to money

For each application, write down the revenue or business process it supports, whether it is customer-facing, what regulated data it touches, and what one day of downtime costs. This is a business impact analysis, the subject of NIST IR 8286D. Finance usually has better data for this than security does: revenue by product, contract penalties, service credits, and the cost of manual workarounds.

3. Build three loss scenarios per critical application

Use a frequency times magnitude frame. For each critical application, sketch:

• A routine incident: a known vulnerability in an open source component is exploited, contained in days. Calibrate magnitude against the claims median for your revenue band.
• A bad incident: exploitation with a few days of interruption and customer notification. Calibrate against the top 10%.
• A tail incident: a widely used component fails across most of your products at once, with interruption and contract fallout. Calibrate against the top 2.5% and the software supply chain figures.

For frequency, start with your own incident and near-miss history, then adjust with the external signals: the share of breaches that start with exploited software, and how many KEV-listed or high EPSS vulnerabilities sit in your inventory today.

4. Break each scenario into cost lines

5. Compute expected loss and the retained tail

For each scenario, expected annual loss is annual probability times magnitude. Sum across scenarios for an expected figure, but keep the tail scenario visible on its own line, because the board cares about survivability, not just the mean.

Illustrative worked example (invented round numbers, not a benchmark). A company with $200 million revenue runs one critical customer platform.

The tail scenario is a fifth of the probability mass of the routine one and most of the expected loss. Now subtract what insurance would pay after the retention and sublimits. If the policy has a $1 million retention and a $5 million sublimit on business interruption, a large part of the tail is retained. That retained tail is the figure to manage.

6. Add the carrying cost of the backlog

Open source risk also costs money when nothing happens. Ask engineering for two numbers: hours per month spent triaging security findings (reading, deduplicating, arguing about severity), and hours per month spent applying fixes. Multiply by a loaded rate. In many companies the triage figure is larger than the fix figure, which is a sign that tooling is generating work rather than removing it. Record it as an operating cost of the risk, separate from the expected loss.

7. Put it on the register

Each critical application gets a register line with an owner, the expected loss, the retained tail, the current response (accept, mitigate, transfer, avoid), and the indicators you will watch. This is the line you take to the audit committee.

What security tooling should cost: a method, not a number

There is no defensible universal figure for what a company should spend on application security. Percent-of-IT-budget benchmarks hide wildly different software estates, and a company that ships software for a living carries a different exposure from one that buys most of its systems. What you can defend is a method.

Start from the risk you are buying down

The economic logic is simple: a control is worth buying when the reduction in expected loss (plus the reduction in carrying cost) exceeds its total cost. For a tool, ask which cost lines from step 4 it changes, and how you would know. A tool that only produces findings changes nothing on its own; it creates a carrying cost until someone acts on the findings. A tool that shortens the time from "exploited vulnerability disclosed" to "fixed in production" for revenue systems changes the frequency and magnitude of the bad and tail scenarios directly.

This is why finance should ask about outcomes in time, not counts. "We found 12,000 vulnerabilities" is a cost. "Known exploited vulnerabilities in production systems are fixed within a set number of days, and here is the trend" is a reduction in risk.

Cost every tool on total cost of ownership

When you add the hidden lines, the cheapest invoice is often not the cheapest tool. A scanner with a low seat price that produces duplicate findings across three repositories can cost more in triage hours than its subscription. For a deeper model of the dependency scanning line, see what to model in the TCO of SCA platforms, and for the triage line, the economics of triage time and cost per finding.

Prefer billing units that track your risk

Every pricing model shifts cost growth somewhere. Per developer seat pricing grows with hiring, not with risk. Per application or per project pricing grows with your estate. Usage-based pricing grows with scanning, inference or storage, which is predictable only if you can see the usage. None is inherently better; pick the unit you can forecast and the one that does not penalise coverage. A model that makes it expensive to scan everything will quietly lead teams to scan less.

Consolidate where outputs overlap, not where logos overlap

Consolidation is the most common finance lever and the most commonly mishandled. List every tool, then list its outputs: SBOMs, dependency findings, code findings, container findings, license findings, policy decisions, evidence for audits, vendor assessments. Where two tools produce the same output for the same assets, you are paying twice and triaging twice. Where one tool produces an output nothing else does, removing it opens a gap, whatever its logo overlap with another product.

Fill this in with your own tools. The value of the exercise is that it moves the conversation from brand to function. Our security tool consolidation strategy post covers the migration side in more detail.

Use unit costs to compare security with everything else

Ask the security leader to report three unit costs each quarter:

1. Cost per covered application: total security tooling TCO divided by the number of applications with a current SBOM and active scanning. Falling cost with rising coverage is good.
2. Cost per fixed known exploited vulnerability in production: TCO plus remediation labor, divided by KEV-listed vulnerabilities fixed in production systems in the period. This is the closest thing security has to a unit of risk removed.
3. Cost per audit control evidenced: compliance tooling and labor divided by the controls with current evidence. It makes audit preparation comparable year to year.

None of these is perfect. Each is better than a findings count.

Decide what not to fund

A finance leader can say no with confidence to: tools whose outputs another tool already produces for the same assets; renewals with no usage data; programs measured only by findings found; and any spend that cannot name the cost line it changes. A finance leader should say yes, even under budget pressure, to inventory (because every other answer depends on it), exploitation-aware prioritisation, and anything that turns findings into fixes in revenue systems.

The questions finance teams ask most

How much should we spend on application security?

Spend up to the point where the next unit of spend removes less expected loss and carrying cost than it costs. In practice that means funding inventory and prioritisation first, remediation capacity second, and breadth of scanning third. If you need a sanity check, compare your security tooling TCO with your expected annual loss and retained tail from the method above. Spending a large multiple of the expected loss suggests waste; spending a small fraction while the retained tail is large suggests under-investment.

Isn't cyber insurance enough?

Insurance transfers part of the loss and is worth having. It does not transfer the retention, sublimited business interruption, uninsurable fines in some jurisdictions, roadmap delay, or reputational harm. The claims study is itself a reminder: insurable loss understates economic loss. Insurers also price your controls, so the inventory and patching evidence you build for risk reduction also feeds the renewal questionnaire.

How do I know the tools are working?

Look for trends that track risk, not activity: coverage of applications with current SBOMs; known exploited vulnerabilities open in production (the target is zero); time to remediate for critical issues, on a rolling 30 and 90 day basis; exceptions open and expiring; and triage hours per month. If the tools are working, coverage rises, exploited vulnerabilities in production fall, time to remediate shortens, and triage hours flatten or fall even as the estate grows.

Do we need to disclose our open source risk?

US public companies describe their cybersecurity risk management processes, including third-party risk, under Regulation S-K Item 106, and disclose material incidents under Form 8-K Item 1.05. Whether a specific open source exposure is material is a legal judgment. The finance contribution is making sure the facts (what is affected, which revenue depends on it, what it would cost) can be assembled in hours, not weeks.

Should we build our own tooling from free open source scanners?

Free scanners are real options and many are good. The licence is free; the TCO is not. Count the integration work, the maintenance, the triage labor, the evidence exports and the risk that the one engineer who built it leaves. Build when you have unusual needs and the people to own it. Buy when the main cost is labor you would rather spend on your product.

How do we treat security tooling in the accounts?

Treatment depends on contract type and your accounting framework, and implementation costs for hosted software have their own rules. This is a question for your controller and auditors. What security can provide is clean data: contract terms, implementation hours, and usage over time.

What should we ask a security vendor in a renewal?

Ask for usage data by billing unit, the overlap with your other tools, the share of findings that led to a change, the time to remediate trend for exploited vulnerabilities, the export formats for your data, and what happens to price if you double coverage. A vendor who cannot answer the last two is pricing against your lock-in.

What about vendors and suppliers who ship software to us?

Third-party software is part of the same exposure; Item 106 asks about third-party risk specifically, and contingent business interruption is a separate claims category in the study above. Tier suppliers by the revenue they touch, ask critical suppliers for SBOMs, and track their response to exploited vulnerabilities the way you track your own.

Metrics for the quarterly review

Use this as the one page that goes to the CFO and the audit committee each quarter. For how security leaders usually present it, see board-level supply chain security reporting; for the remediation time line, how to build a vulnerability SLA dashboard.

How Safeguard does this

Everything above works without Safeguard. This section shows how the same method maps to Safeguard's product, using only what Safeguard's documentation and offering describe. It contains no prices and no claimed savings; run your own numbers with the method above.

1. Build the inventory. Safeguard's SBOM generation and analysis (GA) produces SPDX and CycloneDX SBOMs, and its software composition analysis (GA) covers the full transitive dependency tree, with continuous scanning on push, on a schedule or on release. This is step 1 of the method, and it is the input every later figure depends on.

2. Rank by exploitation, not count. Vulnerability management (GA) enriches findings with EPSS and CISA KEV, and reachability analysis and prioritisation (GA) combines four signals described in Safeguard's docs: whether your code actually reaches the vulnerable function, exploitability from EPSS and KEV, runtime context (environment, exposure and data class such as PII or PCI), and business context you declare through policy, such as which assets are regulated. The output is one ranked backlog. For finance, this is the link between the security queue and the business impact analysis in step 2: the asset labels carry your view of which systems matter.

3. Turn risk appetite into rules. Policies, gates and guardrails (GA) let the organisation state thresholds (for example, no critical vulnerabilities, or no actively exploited CVEs) and enforce them at checkpoints in CI and release. Per Safeguard's docs, each policy's action is Block (the gate fails), Warn (the gate passes with a warning) or Notify (the gate passes and a notification is sent). When a team needs to ship despite a failed policy, it requests an exception with a business justification and an expiry date, approvers decide, and the decision is recorded in an audit trail. For a CFO, an exception is a risk acceptance with a named owner and an end date, which is exactly what the risk register needs.

4. Turn findings into fixes. Autonomous remediation (GA) has Safeguard's Griffin model open tested fix pull requests, singly or in bulk. It ships switched off: every category is set to Manual until an administrator enables it, and teams choose which categories to automate. This is the part of the stack that acts on the remediation labor line in the TCO table rather than adding to triage.

5. Report in the numbers finance reads. Safeguard's analytics dashboards (GA) live under Home, then Dashboards. The docs describe a Program Overview with SBOM coverage, open critical and high findings by environment, KEV-listed findings in production, time to remediate on rolling 30 and 90 day windows, and auto-fix pull request activity; a Vulnerability Backlog view with aging buckets and resolved versus new trends; a Compliance view with readiness by framework, evidence completeness and exceptions open and expiring; and a Costs view of the platform's own usage (inference calls, workflow runs, artifact storage and runner minutes) broken down by team and environment. Dashboards can be scheduled as email reports, and data exports in common formats including CSV, Excel and PDF. Most of the quarterly review table above can be read from these views.

6. Keep evidence and the register in one place. The compliance and GRC suite (GA) covers frameworks, controls, evidence, monitoring, tests, questionnaires, risks and vendors, with continuous evidence mapping. It is where the cost per audit control evidenced metric can be measured, and where the risk register lines from step 7 can live alongside the controls that answer them.

7. Extend the method to suppliers. Third-Party Risk Manager, or TPRM (GA), keeps a vendor directory, requests SBOMs from suppliers, analyses them, scores risk and monitors vendors continuously. The docs suggest tiering vendors by criticality, with SBOMs required and refreshed quarterly for critical vendors and annually for high-tier vendors. That gives finance a defensible answer to the third-party question in Item 106.

8. Choose where it runs and whether AI is in the loop. Safeguard deploys as SaaS, in a private VPC, on-premises or fully air-gapped (GA), and can run in Zero AI mode (GA) with no large language model at all, or with a model you bring (GA). For finance this is a TCO lever as much as a security one: it decides which infrastructure and inference costs you carry, and whether a regulated business can use the platform at all.

9. Read the bill with the TCO template. Safeguard publishes its pricing on its website. Apply the TCO table above to it like any other vendor: billing unit, growth with coverage, integration effort, triage and remediation labor, evidence labor, and exit (the export formats in step 5).

What Safeguard does not do

• It does not price your risk. Safeguard ranks vulnerabilities and shows trends; it does not calculate your expected loss, your retained tail or your insurance gap. The scenario and cost line work in this guide stays with finance and risk.
• It does not decide materiality or disclosure. Faster facts help, but whether an incident is material, and what you file, is a judgment for management, counsel and the board.
• It does not set your risk appetite. Policies enforce thresholds you choose. Choosing them, and approving exceptions, remains a business decision with a named owner.
• It does not account for your people time. The dashboards report platform activity and its own usage costs. Triage and remediation hours, loaded rates and roadmap delay are yours to measure.
• It does not replace insurance, legal review or vendor contracts. TPRM collects and analyses supplier SBOMs and scores risk; contract terms, audit rights and indemnities are negotiated by your teams.
• It does not change anything without your switch. Autonomous remediation ships off, every category Manual. Nothing is fixed automatically until you enable it, and what it produces arrives as pull requests subject to your normal review and merge rules.
• It does not make accounting or tax determinations about how its own cost, or any security spend, is treated in your accounts.

Common mistakes

• Using an average as a budget. A single mean breach cost tells you little about your tail. Use the distribution and your own revenue band.
• Counting findings as progress. More findings is more carrying cost until something is fixed. Measure exploited vulnerabilities in production and time to remediate.
• Treating response labor as free. The engineers who spent weeks on Log4j were paid. Put an hourly rate on incident response and include it in scenarios.
• Consolidating by logo. Two products from the same category may produce different outputs. Map outputs to assets before you cancel anything.
• Ignoring exit cost. If you cannot export your history in standard formats, the renewal price will reflect it.
• Leaving exceptions open-ended. An accepted risk with no expiry date becomes permanent without anyone deciding it should be.
• Assuming insurance covers interruption. Business interruption is half of known supply chain loss in the claims data and is often sublimited. Read the schedule.
• Funding scanning breadth before inventory. More scanners on an incomplete inventory produce confident numbers about part of the estate.

FAQ

What is the cost of open source risk for a mid-sized company?

There is no single number. Build it from scenarios: the 2026 Breach Impact Study gives a median of about $96,000 for companies with $25 million to $250 million in revenue, with a far longer tail, and software supply chain claims have a median of $252,666. Combine those anchors with your own revenue at risk and response labor.

How do I calculate expected loss from vulnerabilities?

Multiply the annual probability of each loss scenario by its magnitude and sum the results. Keep the tail scenario on its own line. Use exploitation signals (KEV listings and EPSS probabilities in your inventory) to adjust frequency, and your own business impact analysis to set magnitude.

What percentage of the IT budget should go to security?

Percent-of-budget benchmarks are weak because estates differ so much. A better test compares security tooling TCO with expected annual loss and the retained tail, and checks unit costs such as cost per covered application over time.

What is total cost of ownership for security tools?

Subscription or usage fees, plus implementation, integration, triage labor, remediation labor, overlap with other tools, evidence and audit labor, training, infrastructure and exit cost. Triage labor is often the largest hidden line.

How should a CFO evaluate a security tool consolidation?

Map every tool's outputs to the assets it covers. Keep one source for each output, fund real gaps, and migrate history before cancelling. Check exit formats and whether the billing unit penalises full coverage.

Does cyber insurance cover open source supply chain attacks?

Often in part. Check retentions, sublimits on business interruption and contingent business interruption, waiting periods and exclusions. The claims study notes that the largest supply chain losses it saw reflected coverage caps rather than full economic loss.

What metrics should the board see on software supply chain risk?

SBOM coverage of critical revenue, known exploited vulnerabilities in production, time to remediate critical issues, exceptions open and expiring, triage hours, tooling TCO with unit cost, and the retained tail from the risk register.

Why are breach cost figures so different between reports?

Different samples and statistics. Survey-based studies often report averages, which the tail pulls upward. Claims-based studies report medians of insured losses, which understate total economic loss. Use both, and know which you are quoting.

Is free open source security tooling good enough?

It can be, for inventory and basic scanning. The question is TCO: who integrates it, who triages it, who maintains it and who produces audit evidence from it. Free licences with high labor costs are not free.

Every scenario in the method above gets cheaper when the time between a vulnerability becoming known and a fix running in production gets shorter, and most expensive when no upstream fix exists yet. The section below describes how Safeguard approaches both gaps, which is the operational side of the retained tail on your risk register.

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 connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. For a finance leader, this is the route to asking questions of your own security data in plain language from an assistant you already use, with an administrator controlling exactly which tools the assistant can reach.

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

The second demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal with safeguard, and asks it to fix a lodash CVE in a repository. The CLI reads the finding and the 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. This is what the remediation labor line looks like when a fix is prepared for an engineer rather than written from a ticket.

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

The third demo is a real Android session: work is sent to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. It shows that a person stays in the approval loop for every change, which is the control an auditor or insurer will ask about.

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

Quick check

Sources

• The Value of Open Source Software, Harvard Business School working paper
• 2026 Breach Impact Study (Verizon DBIR team, with CyberAcuView claims data)
• 2026 Data Breach Investigations Report (Verizon)
• Cost of a Data Breach Report 2026 (IBM and Ponemon Institute)
• Cyber Safety Review Board, Review of the December 2021 Log4j Event
• 17 CFR 229.106, Regulation S-K Item 106, Cybersecurity
• SEC final rule, Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure, 88 FR 51896 (4 August 2023)
• NIST IR 8286 Rev. 1, Integrating Cybersecurity and Enterprise Risk Management
• NIST SP 800-218, Secure Software Development Framework
• CISA Known Exploited Vulnerabilities Catalog
• FIRST Exploit Prediction Scoring System (EPSS)
• Safeguard docs: Policies and Gates
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard docs: Analytics and Dashboards
• Safeguard docs: Third Party Risk Manager

Download Safeguard at safeguard.sh/download and read the documentation at docs.safeguard.sh/docs.

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