Make the AppSec Renewal Case With Fix Metrics, Not Finding Counts

Finance does not renew a security tool because it found things. It renews because things got fixed, faster, with less of your team's time, and because the fixes stayed fixed. Build the case on five fix metrics (fix rate, median and p90 time to remediate, KEV exposure days, reintroductions and exception aging), define each one so a skeptical analyst can recompute it, and show the trend from before the tool to now.

That is the whole argument. The rest of this post is how to make it hold up in the room: the definitions, the baselines, the payments angle under PCI DSS v4.0.1 requirement 6.3.3, how to separate what the tool did from what your engineers did, a one page memo you can adapt today, and the honest cases where the numbers say renegotiate, switch or cut.

Key takeaways

• Finding counts are an input, not an outcome. A renewal case built on "we found 40,000 issues" invites the question "and how many are still there?"
• Five fix metrics carry the case: fix rate, median and p90 time to remediate (by severity), KEV exposure days, reintroduction rate and exception aging. Report medians and the 90th percentile, never the mean alone.
• Define every metric with NIST SP 800-55v1's measure template (goal, scope, formula, target, data source, frequency, owner) so finance can audit it.
• For payments teams, PCI DSS v4.0.1 requirement 6.3.3 starts the clock at patch release, not at detection. Track both clocks.
• Separate tool value from team effort with a before and after baseline and a split of tool-generated fixes versus manual fixes. You will not separate them perfectly; say so.
• The honest answer is sometimes "renegotiate" or "cut". A memo that admits that is more credible than one that never does.
• In Safeguard, the executive dashboard with drill-through and exports (GA), vulnerability management with EPSS and CISA KEV (GA), reachability analysis (GA), autonomous remediation with Griffin fix pull requests (GA, ships switched off with every category set to Manual), policies and gates with Block, Warn and Notify (GA) and mitigations with expiry dates (GA) cover most of the data you need.

The situation

The AppSec tooling contract renews next quarter. Procurement has flagged it, and finance has sent the question every Head of Application Security at a fintech or payments company gets sooner or later: what did we get for the money?

You can show findings. Lots of them. Every scanner produces a big number, and the big number went up this year because you onboarded more repositories. But finance is not asking how much the tool saw. They want to know what got fixed and how fast, and whether the spend is the reason.

A bad week looks like this. You pull a screenshot of the vulnerability count, a pie chart by severity and a slide that says "risk reduced". The finance partner asks three questions. Reduced compared with what? How do you know it was the tool and not the two engineers you hired in March? Why are there still critical items older than ninety days if the tool is working? You do not have answers, the renewal slips into a "let's revisit" email thread, and the notice window you needed to negotiate passes.

A good week looks different. You arrive with five numbers, each with a one line definition, a baseline from before the tool, a current value, and a data source finance could query if they wanted to. You show where the tool helped and where it did not. You propose a renewal at the current scope, or a reduced one, or a switch, with the reasoning attached. The meeting takes twenty minutes.

The rest of this post gets you to the good week.

The rules and standards behind fix metrics

You do not need a regulation to justify measuring remediation, but citing the right sources does two things. It shows the metrics are not invented to flatter the tool, and for payments it ties the numbers to obligations your QSA already tests. This section is general information, not legal or audit advice; your QSA and counsel decide what applies to your environment.

NIST SP 800-55 (December 2024): how to define a measure

NIST published SP 800-55 in two volumes in December 2024, superseding SP 800-55 Rev. 1 from 2008. Volume 1 covers identifying and selecting measures; Volume 2 covers building a measurement program.

Volume 1 sorts measures into four types:

1. Implementation measures show progress of a control, such as the share of systems with up to date patches.
2. Effectiveness measures show whether controls meet their desired outcome.
3. Efficiency measures look at timeliness: how fast controls give feedback and how quickly issues are addressed.
4. Impact measures tie security to the mission: cost savings, costs of incidents, cost effectiveness, business value, fines and penalties.

That split maps cleanly onto a renewal case. Coverage (how many repositories are scanned) is implementation. Fix rate and reintroductions are effectiveness. Time to remediate and KEV exposure days are efficiency. Cost per fix and avoided losses are impact. NIST notes impact measures are the ones executives seek, and also that they need extra analysis before they can be shown to a non technical audience. That is a warning, not a dead end: impact is where most renewal decks overreach.

Volume 1 also gives a measure template. Each measure should state a goal, scope, the measure itself (a numeric statement beginning with words like "percentage" or "average"), its type, a formula, a target, the implementation evidence, when it was taken and how often, responsible parties, the data source and the reporting format. If every metric in your memo has those fields filled in, finance has nothing to argue about except the numbers themselves.

NIST SP 800-40 Rev. 4 (April 2022): what an actionable patch metric looks like

SP 800-40r4, the enterprise patch management guide, has the most useful paragraph in the whole field for a renewal case. It says overly simple metrics, such as counting vulnerabilities and the percentage patched, are not actionable, because they do not tell you whether the unpatched items are your most important assets or your least.

Its alternative is a matrix. Rows are vulnerability importance (low to critical), columns are asset importance (low to high), and each cell reports three things: the percentage patched by the maintenance plan's deadline, the mean time to patch and the median time to patch. The publication marks its figures as notional. The shape is what matters: deadlines that differ by importance, and both mean and median per cell.

SP 800-40r4 also lists four risk responses: accept, mitigate, transfer and avoid. That matters for exception aging, because an accepted risk is a legitimate outcome, not a failure, as long as it is documented and revisited. And it warns that low level data quality drives everything above it: if you scan monthly, your counts will be lower than reality and your enterprise metrics will mislead.

PCI DSS v4.0.1 requirements 6.3.1, 6.3.2 and 6.3.3: what "patched in time" means for payments

PCI DSS v4.0.1 was published in June 2024 and is the current version in the PCI SSC document library. The standard's full text sits behind the council's licence agreement, so read it from the document library yourself and check the wording with your QSA. In outline:

• 6.3.1 requires that new security vulnerabilities are identified from industry recognised sources and that each is given a risk ranking. Your ranking method (CVSS alone, or CVSS plus exploitation signals) is yours to define and defend.
• 6.3.2 requires an inventory of bespoke and custom software and the third party components incorporated into it. In practice that is an SBOM kept current.
• 6.3.3 requires applicable security patches and updates. Patches for critical vulnerabilities, as identified through your 6.3.1 risk ranking, must be installed within one month of release. Other applicable patches follow a timeframe the entity determines. Version 4.0 had extended the one month rule to high risk vulnerabilities as well; v4.0.1 narrowed it back to critical.

Two details change how you measure. First, the 6.3.3 clock starts at the release of the patch, not at the moment your scanner noticed. A team that detects late and fixes fast can still miss the month. So track time from fix availability alongside time from detection. Second, "critical" is whatever your 6.3.1 ranking says is critical. If your ranking is CVSS only, your critical queue is large and the month is hard. If your ranking adds exploitation evidence and reachability, the queue is smaller and the reason for each item is documented. Either is defensible if written down; the second is easier to meet and easier to explain.

CISA's KEV catalog and BOD 26-04: a clock you can borrow

CISA maintains the Known Exploited Vulnerabilities catalog, its list of vulnerabilities exploited in the wild. On 10 June 2026 CISA issued Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, which replaces BOD 22-01. BOD 26-04 binds federal civilian agencies, not a private fintech, and it does not apply to contractors unless their contract says so.

It is still useful to you. It sets remediation urgency from four variables: whether the asset is publicly exposed, whether the CVE is in the KEV catalog, whether exploitation can be automated, and whether the attacker gains partial or total control. Its timelines start when CISA adds the CVE to KEV or when the agency first identifies it on an asset, whichever is first. Borrowing that start rule gives you a clean definition for KEV exposure days.

FIRST EPSS: probability, not risk

FIRST's Exploit Prediction Scoring System publishes, daily, a probability between 0 and 1 that a CVE will see exploitation activity in the next 30 days, with a percentile alongside. FIRST is explicit that EPSS is not a complete risk score: it does not know your environment, your compensating controls or the damage exploitation would cause. Use it to rank and to explain why you fixed some high CVSS items later than others. Do not present it as a measure of your risk.

OWASP SAMM: metrics as a practice

OWASP SAMM's Defect Management practice has a Metrics and Feedback stream. At maturity 1 you derive quick wins from basic metrics; at maturity 2 you collect standardised defect metrics and use them to prioritise central initiatives; at maturity 3 you improve the metrics and correlate them with other data. The Strategy and Metrics practice adds that metrics should give insight into the effectiveness and efficiency of the program (maturity 1) with targets and KPIs set (maturity 2). If your board or audit committee already uses SAMM, frame the renewal metrics as your Defect Management maturity evidence.

Step by step: build the renewal case in two weeks

This works with whatever tools you have. You need an export of findings with timestamps, an export of fixes or pull requests, and a list of exceptions.

1. Write down the decision you are asking for. Renew at current scope, renew at a different scope, renegotiate, switch or cut. Finance needs a decision, not a status update.
2. Pick the period and the baseline. Use the most recent twelve months as the current period. The baseline is the six to twelve months before the tool was rolled out, or, if the tool has been in place for years, the first full quarter you have data for.
3. Freeze the scope. List the repositories, services and container images in scope for both periods. If scope grew, report metrics on the common set first, then on the full set. Otherwise growth will hide improvement.
4. Export raw records, not dashboards. For each finding you want: identifier, component and version, severity, KEV status and date added, EPSS at detection, first detected date, fix available date, fixed date, how it was fixed (tool generated pull request or manual), and whether it reappeared later.
5. Compute the five metrics with the definitions in the next section, per severity band.
6. Compute the two clocks for critical items. Days from detection to fix, and days from fix release to fix in production. The second is the PCI 6.3.3 clock.
7. Split tool and team. Count fixes that came from tool generated pull requests versus manual changes, and compare throughput per engineer before and after.
8. Write the trade-offs. What the tool did not help with, and what you would lose by cutting it.
9. Fill in the one page memo (template below) and the backup appendix with every definition.
10. Rehearse the three hostile questions. Compared with what? Was it the tool or the people? Why are there still old criticals?

Which metrics show value

Five metrics, each tied to a question finance actually asks. The table gives the short form; the subsections give the definitions.

Fix rate

Definition. Findings fixed in the period, divided by findings open at the start of the period plus findings opened during it. Fixed means verified by a rescan, not "pull request merged" and not "ticket closed".

Why the denominator matters. If you divide fixed by opened only, a quarter with few new findings looks heroic. Including the opening balance makes the metric reflect backlog burn-down.

Cut it by severity. A 70 percent fix rate overall can hide a 30 percent rate on criticals because the easy lows dominated. Report critical and high separately.

Watch for. Findings that disappear because a repository was archived or a service decommissioned. Those are "avoid" responses in SP 800-40r4 terms and are legitimate, but label them separately from fixes.

Median and p90 time to remediate

Definition. For each finding fixed in the period, days from first detection in your estate to verified fix. Report the median and the 90th percentile by severity.

Why not the mean. Remediation times are skewed: most items close quickly and a few drag on for months. A mean is dragged up by the tail and moves around when one old item finally closes. The median tells finance what usually happens; the p90 tells them how bad the slow cases are. Show both. If someone asks for the mean, give it as a third figure, never alone.

The censoring trap. Items still open at the end of the period are not in the "fixed" set, so a naive median ignores your oldest problems. Report the count and age of still open items next to the median, or use the share fixed within target (the SP 800-40r4 "by deadline" figure) which counts open items as misses.

The second clock for payments. For critical items, also report days from fix release to fix in production. That is the PCI DSS 6.3.3 view.

KEV exposure days

Definition. For each finding whose CVE is in the CISA KEV catalog, count days from the later of two dates (the date CISA added it to KEV, or the date the component first appeared in your estate) to the date the fix was verified, or to the end of the period if still open. Sum across items for a total, and give the median per item.

Why it persuades. It is the most attacker-shaped number you have. Finance does not need to understand CVSS to understand "we were exposed to vulnerabilities that criminals were actively using for 600 days in total last year, and 90 this year". Those figures are illustrative; use your own.

Borrow the BOD 26-04 start rule if you want an independent anchor: the clock starts at KEV addition or first identification, whichever comes first.

Reintroduction rate

Definition. Of the findings fixed in the period, the percentage where the same vulnerability in the same component reappears in the same repository or image within 90 days.

Why it matters. Reintroductions are the clearest sign of wasted effort: you paid for the fix twice. They usually come from lockfiles regenerated against old ranges, base images rolled back, or a second service copying an old dependency manifest.

What drives it down. Gates in CI that block known vulnerable versions from merging, and pinned base images. If your tool has gates and you have not turned them on, this metric will tell you.

Exception aging

Definition. For active risk acceptances, waivers and false positive marks: the count, the median age, and the percentage past their expiry date or without one.

Why it matters. An exception is a legitimate risk response (accept, in SP 800-40r4 terms). An exception without an expiry or an owner is a hiding place. A falling vulnerability count with a rising exception count is not an improvement, and finance's internal audit colleagues will spot it.

Report alongside. The number of exceptions reviewed and renewed versus closed in the period. Reviews prove the process runs.

How to define and baseline each metric so it survives scrutiny

Use the NIST SP 800-55v1 template for every metric in the memo appendix. Here is one filled in, ready to adapt.

Measure:        Median days to remediate critical findings
Goal:           Reduce time that critical vulnerabilities stay exploitable in
                production code and images
Scope:          Repositories and container images tagged in-scope for the
                cardholder data environment; excludes archived repositories
Type:           Efficiency (NIST SP 800-55v1, section 3.3.3)
Formula:        median( verified_fix_date - first_detected_date ) over
                critical findings fixed in the quarter
Target:         Interim: 30 days by Q2. Final: 14 days by Q4
Evidence:       Findings export with first_detected and verified_fix dates;
                rescan record proving the fix
Taken / freq:   Computed on the first business day of each quarter;
                reported quarterly
Owner:          Information owner: Head of AppSec. Collector: AppSec analyst.
                Customer: CFO office and CISO
Data source:    Scanner findings export; pull request history
Reporting:      Line chart by quarter with p90 shown as a band

Baselining rules that keep the numbers honest:

1. Same scope, both periods. Compute the baseline on the repositories that existed then and still exist now.
2. Same detection depth, both periods. If the new tool sees transitive dependencies the old process did not, the baseline undercounts. Say so, and where you can, rescan old commits with the current tool to rebuild the baseline.
3. Same definition of "fixed". Verified by rescan in both periods.
4. Same severity source. If you changed from CVSS only to a ranking that adds exploitation signals, recompute the baseline with the new ranking or present both.
5. Record the date you took each number. NIST's template asks for it, and it stops a later recalculation from quietly replacing an earlier one.

Separating tool value from team effort

This is the question that sinks most renewal cases, because the honest answer is that the two cannot be fully separated. Engineers fix things; tools make it easier, faster or more likely. Here are four ways to get close, in order of strength.

1. Tool generated fixes. Count fixes that arrived as pull requests the tool opened and your engineers merged, versus fixes written by hand. The tool's share is not "value" on its own (an engineer still reviewed and merged it), but it is the most direct attribution available.
2. Throughput per engineer. Fixes verified per AppSec or platform engineer per month, before and after. If headcount rose 20 percent and fixes rose 60 percent, the difference is a reasonable claim for the tool. If both rose together, the tool may be adding little.
3. Queue quality. The number of items in the "act now" queue after prioritisation, and the share of those that turned out to need action. A tool that ranks by exploitation evidence and reachability should give you a smaller, more accurate queue. Measure the queue, not a vendor's percentage.
4. Time to first action. Days from detection to the first pull request or ticket. That is mostly tool and workflow; time from pull request to merge is mostly team.

A worked example, entirely illustrative, with round numbers you should replace:

On these invented numbers, headcount rose by a quarter and per engineer throughput doubled. A fair memo claims the per engineer change for the tool and process together, notes that one extra engineer accounts for part of the volume, and does not claim the 1,200 tool generated fixes as "work the tool did alone", because people reviewed every one.

What the one page renewal memo should look like

Finance wants one page with the decision first, then the evidence, then the risks. Put definitions in an appendix. Here is a template.

To:       CFO office; cc CISO, Procurement
From:     Head of Application Security
Re:       AppSec tooling renewal, decision needed by [date of notice window]

Decision requested
  Renew at [scope] for [term]. Alternatives considered: renew at reduced
  scope; switch; cut. Recommendation and reason in one sentence.

What changed since the baseline (common scope, [n] repositories)
  Fix rate, critical+high:            [baseline]% -> [current]%
  Median / p90 days to remediate:     [b] / [b] -> [c] / [c]
  KEV exposure days (total):          [b] -> [c]
  Reintroduction rate (90 days):      [b]% -> [c]%
  Exceptions past expiry:             [b] -> [c]

Payments obligation (PCI DSS v4.0.1 6.3.3)
  Critical patches installed within one month of release: [x] of [y]
  Misses and reason: [one line each]

What the tool did versus what the team did
  Fixes from tool generated pull requests: [n] of [total]
  Fixes per engineer: [b] -> [c]; headcount [b] -> [c]

What the tool did not do
  [two or three honest lines]

Cost view
  Annual cost / verified critical+high fixes = [cost per fix]
  Cost to replace with process or headcount: [estimate and assumptions]

Risks of each option
  Cut: [what stops; what metric would regress first]
  Switch: [migration time; baseline reset]
  Renew: [what we will hold the vendor to next year]

Appendix: metric definitions (NIST SP 800-55v1 template), data sources,
scope list, date each number was taken.

Three style rules for the memo. Use the same five metrics every year so trends are comparable. Show the misses, because a memo with no misses is not believed. And never put a dollar figure on "breaches avoided": you cannot show a counterfactual, and finance knows it.

When the metrics say switch, renegotiate or cut

The renewal is a decision, and the metrics should be allowed to say no. Use this table as a first cut.

Two warnings. A switch resets your baseline, so plan a quarter of overlap if you can afford it. And a cut that saves money can be reversed in a quarter by a rise in KEV exposure days; name the metric you will watch after the cut and the threshold that would bring the tool back.

How Safeguard does this

The steps above work with any tooling. This section shows how the same job maps to Safeguard, using only what the Safeguard docs describe. Every capability named here is GA.

1. Start from the dashboard, not the findings list. The Safeguard dashboard (GA) gives an organisation wide view: a security score from 0 to 100 that the docs say is based on vulnerability severity and count, fix rate and remediation speed, policy compliance and component health; a vulnerability summary with trend over time; and a Top Risks list that includes actively exploited CVEs and aging vulnerabilities. The executive risk dashboard spans the whole platform, and every number on it drills through to the underlying results, so a finance question about any figure can be answered by clicking it. Dashboards are editable, with rearrangeable widgets and time filters, which is how you set the period to your baseline and current quarters.

2. Read the Fix Rate and Vulnerability Trends charts. The docs describe a Fix Rate chart showing vulnerabilities fixed per week, AI Remediate versus manual fixes, and time to fix by severity, and a Vulnerability Trends chart that includes mean time to remediation. The "AI Remediate versus manual" split is the closest thing to the tool versus team attribution in the step by step above. The trend chart reports the mean; for the median and p90 the memo needs, export the records (step 7) and compute them.

3. Rank with exploitation evidence and reachability. Vulnerability management (GA) re-evaluates projects daily as new CVEs are published and pulls from NVD, GitHub Security Advisories, OSV, CISA KEV and vendor bulletins. Each vulnerability carries its CVSS score, EPSS score, whether it is exploited in the wild, the fixed version and reachability status. Reachability analysis (GA) asks whether the vulnerable code is actually called, alongside runtime and configuration context. You can filter by EPSS range, exploitable status, fix availability and reachability, which is how you build a defensible 6.3.1 style risk ranking and a short "act now" queue.

4. Turn on fixes deliberately. Autonomous remediation (GA) uses Griffin to analyse a vulnerability, choose an upgrade path, assess breaking changes, open a pull request and run validation. The docs call this flow AI Remediate. You can run it on one vulnerability, in bulk (one pull request per repository), or from the top of the Vulnerabilities page. It ships switched off, with every category set to Manual; nothing runs on its own until you enable it. Under Settings, AI Remediate, the docs list options to auto-create pull requests for safe fixes, require approval before pull requests, run tests before creating them, and set a breaking change policy. For a renewal case, the pull requests it opens are your tool generated fixes, already labelled with the CVE they address.

5. Stop reintroductions with gates. Policies and gates (GA) let you write conditions such as no critical CVEs, a CVSS ceiling, or an EPSS condition, and each policy's action decides what a failure does to the gate: Block fails the gate, Warn passes it with a warning, Notify passes it and sends a notification. Approval runs through exceptions. In CI, the docs show this command failing a job when a gate fails, with policy outcomes switched on for the workspace:

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

We did not run this command for this post; check the CI/CD integration page for your setup. Once a Block gate is in place, the reintroduction rate is the metric that shows it working.

6. Keep exceptions honest. On the Vulnerabilities page, Accept Risk asks for an expiration date and a business justification and submits for approval. The Mitigations tab (GA) records risk acceptances, false positives, workarounds and not applicable marks, with a required justification and approver, an optional expiry, and statuses including Active and Expired. The docs say Safeguard notifies you 14 days and 7 days before an acceptance expires and on the day. Exception aging is a filter on that tab: count Active items, their age, and the share Expired.

7. Export what finance will check. Safeguard supports bulk export of reports and data in formats including CSV, Excel, PDF and JSON. The dashboard docs list PDF export of the formatted dashboard and scheduled weekly or monthly email reports. The Findings tab has a Findings Report export with an executive summary, findings by severity and type, resolution status and trend analysis, filtered by date range. Export the records, compute the five metrics in your own sheet, and attach the sheet to the memo so the numbers can be recomputed.

8. Map to PCI DSS 4.0. The Safeguard PCI DSS 4.0 framework page in Compliance and GRC (GA) lists scan requirements for 6.3.1 (continuous vulnerability identification), 6.3.2 (a maintained component inventory) and 6.3.3 (patch applicability data, which needs current version data on all components). That gives you evidence that inventory and version data exist; it does not decide whether you met the one month window. That remains your calculation and your QSA's judgment.

9. Ask the questions in plain English. The docs show Griffin natural language search across vulnerabilities, for example asking for critical vulnerabilities in production that are actively exploited. If you connect Claude to the Safeguard MCP server (GA), you can ask the same questions from Claude, with tool access you choose. That is useful when finance sends a follow up question the day before the decision.

What maps to what

What Safeguard does not do

• It does not produce impact measures. No dashboard shows breaches avoided, incident cost saved, fines avoided or business value. Those are NIST's impact measures, and they need your finance and risk data. Safeguard does not publish an ROI or hours saved figure, and you should not put one in the memo on its behalf.
• It only measures what it scans. Repositories, images and SBOMs that are not connected are not in the numbers. A rising fix rate on half the estate says nothing about the other half. Report coverage alongside the metrics.
• It does not separate tool value from team effort for you. The AI Remediate versus manual split is helpful, but every tool generated pull request was reviewed and merged by a person. The attribution argument is yours to make.
• It does not set your PCI scope or replace your QSA. The PCI DSS 4.0 framework page records evidence for 6.3.1 to 6.3.3; whether a system is in the cardholder data environment and whether you met 6.3.3 is decided by you and your assessor.
• It does not compute every metric in this post out of the box. The docs describe a mean time to remediation trend and time to fix by severity; median, p90, KEV exposure days and reintroduction rate as defined here come from your own calculation on exported data.
• It does not fix vendor appliances, hosted services or operating system runtimes you do not build. Those fixes come from the vendor, and their timeliness belongs in a different part of your patch metrics.
• It does not merge or deploy on its own by default. Autonomous remediation ships switched off with every category set to Manual, and even when enabled, merges and releases follow your own review and change control.

Common mistakes

1. Leading with the finding count. It grows with scope and with detection depth, so it rewards the tool for making your backlog look bigger.
2. Reporting only the mean. One ancient item closing can make a good quarter look bad or a bad quarter look good.
3. Ignoring still open items. A median over fixed items alone hides the oldest risks. Show open ages too.
4. Counting "PR merged" as fixed. A merged pull request on a branch that never shipped is not a fix. Verify by rescan of what is deployed.
5. Changing scope between periods without saying so. Always show the common scope first.
6. Using only the detection clock for PCI. Requirement 6.3.3 counts from patch release.
7. Letting exceptions absorb the backlog. Falling open counts with rising exceptions is a red flag to any auditor.
8. Claiming dollar figures for breaches avoided. You cannot show the counterfactual, and it costs you credibility on every other number.
9. Presenting EPSS as risk. FIRST says it is a probability of exploitation activity, not a complete risk score.
10. Never recommending cut. If no data could ever lead you to recommend cutting, finance will discount the data.

FAQ

How do I justify an AppSec tool renewal with metrics?

Show what got fixed, how fast, and whether fixes stuck, compared with a baseline from before the tool. Use fix rate, median and p90 time to remediate, KEV exposure days, reintroduction rate and exception aging, each defined with a formula and data source, and include the misses.

What is a good fix rate for vulnerabilities?

There is no universal benchmark. A fix rate above 100 percent of new findings means the backlog is shrinking; below it means it is growing. Set targets per severity from your own baseline rather than borrowing a number from a report.

Should I report mean or median time to remediate?

Report the median and the 90th percentile, by severity. Remediation times are skewed, so the mean is pulled by a few long running items. If someone asks for the mean, give it as a third figure.

What are KEV exposure days?

For each vulnerability in CISA's Known Exploited Vulnerabilities catalog found in your estate, the days between the later of its KEV addition or its first appearance in your estate and its verified fix. Summed, it shows how long you were exposed to vulnerabilities attackers actually use.

Does PCI DSS 6.3.3 require high vulnerabilities to be patched in 30 days?

In PCI DSS v4.0.1, the one month requirement applies to critical vulnerabilities as identified by your 6.3.1 risk ranking. Version 4.0 had included high risk vulnerabilities; v4.0.1 removed them. Other applicable patches follow a timeframe you set. Confirm against the standard's text and with your QSA.

How do I show the tool helped and not just my team?

Compare fixes per engineer before and after, count fixes that arrived as tool generated pull requests, and track time from detection to first action. Say plainly that people reviewed every fix, so the split is an estimate.

Can I put an ROI number in the renewal memo?

You can put a cost per verified fix, which is factual. Avoid "breaches avoided" or "losses prevented" figures; they rest on a counterfactual you cannot show. NIST SP 800-55v1 treats impact measures as organisation specific and needing extra analysis.

When should we cut an AppSec tool instead of renewing?

When a year of full adoption shows flat fix metrics, when two tools cover the same inventory, or when detection rises but nothing from the tool helps fixes happen. Name the metric you will watch after cutting so the decision can be revisited.

How often should we report fix metrics?

Quarterly to finance and leadership, monthly inside the security team. NIST's template asks you to record when each number was taken and how often, so the trend is reproducible.

Do exceptions count against the fix metrics?

Track them separately. An accepted risk with an owner and an expiry is a legitimate response. Report the count, median age and share past expiry next to the fix metrics so parked risk is visible.

Fix it, and keep it fixed

Every metric in the renewal memo improves for the same reason: fixes reach production sooner and do not slip back. The section below describes the Safeguard routes for closing both remediation gaps, the wait for a fix to ship and the wait for a fix to exist at all.

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 shows how you choose which tools Claude can use. For a renewal, that is how you answer finance's follow up questions in plain language the night before the meeting, against your own Safeguard data, without building a new report.

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

The second demo is a real desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with the upgrade done and tests passing. Every fix done this way is a verified fix in your metrics, made with a person approving each step.

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

For more on the metrics themselves, see mean time to remediate: mean vs median vs p90 and the vulnerability management metrics glossary. For the contract side, read AppSec renewal auto-renew and notice windows, and if the numbers point toward a change, signs it's time to switch your dependency scanner.

Quick check

Sources

• NIST SP 800-55 Vol. 1, Measurement Guide for Information Security: Identifying and Selecting Measures (December 2024)
• NIST SP 800-55v1 full text (PDF)
• NIST SP 800-55 Vol. 2, Developing an Information Security Measurement Program (December 2024)
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning (April 2022)
• NIST SP 800-40r4 full text (PDF)
• PCI Security Standards Council document library (PCI DSS v4.0.1 and Summary of Changes v4.0 to v4.0.1)
• CISA Known Exploited Vulnerabilities Catalog
• CISA BOD 26-04, Prioritizing Security Updates Based on Risk (10 June 2026)
• FIRST Exploit Prediction Scoring System
• FIRST EPSS FAQ
• OWASP SAMM model
• OWASP SAMM Defect Management
• OWASP SAMM Strategy and Metrics
• Safeguard docs: Dashboard
• Safeguard docs: Vulnerabilities
• Safeguard docs: AI Remediate
• Safeguard docs: Findings
• Safeguard docs: Policies and Gates
• Safeguard docs: Mitigations
• Safeguard docs: PCI DSS 4.0 framework

To try the flows in this post, download Safeguard and read the Safeguard docs.

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