How the remediation cost is calculated

What the number means

Each priced vulnerability carries an estimate of the engineering time needed to write and validate its fix, based on the fix the project actually published. The estimate comes from a rubric with three dimensions, each scored 1 to 5. Their sum maps to engineer-days on a fixed curve, and days convert to dollars at a fixed daily rate. The same rubric is applied to every project.

The formula

D1 is measured from the fix itself. D2 and D3 come from what kind of vulnerability it is. Severity is not an input — see Severity and CVSS.

D1 — Implementation effort

How big and how spread out the change is: the lines added plus lines deleted, and the number of files, counting only code an engineer wrote (tests, documentation and generated files are excluded — see What counts as written code). The lines set the score: the first row whose line limit the fix fits within. The file count can raise it by one row at most, when the files exceed that row's file limit. When 90% or more of the lines are deletions — a fix that removes a feature — the lines column reads the added lines only; the reasoning and validation scores stay.

So a 74-line change spread over 15 files is D1 4 (lines row 3, raised one row by its files), not D1 5, and one line changed in three files is D1 2. A fix that only upgrades a dependency is set to D1 1 (see below). These rules are grading G7, used since 2026-10-11; before it the larger of the two rows set D1.

D2 & D3 — Reasoning and validation difficulty

D2 — reasoning: how hard it is to find the root cause and decide on the right fix. D3 — validation: how hard it is to confirm the fix works and breaks nothing else. Both are set by the vulnerability class. A use-after-free takes more reasoning than an open redirect, and a request-smuggling fix is harder to test than it is to reason about.

When a class name contains more than one listed term, the first term in the rubric's own list wins, and JIT comes first — so a record classed “JIT use-after-free” scores as JIT. 15 projects (Apache Cassandra, Apache Tomcat, Dify, Flowise, Frappe, GitLab, Grafana, Keycloak, Mattermost, Moodle, Nextcloud, OpenMRS, PostgreSQL, Redis, Strapi) define a few component adjustments of ±1 — for example, Tomcat's HTTP/2 and TLS code is one step harder on both dimensions, its Manager app one step easier. Scores always stay within 1–5. 328 of 11,652 priced records (3%) carry a D2 or D3 different from their class default, through these adjustments or project-level calibration.

Combined score → engineer-days → dollars

The combined score (3–15) maps to engineer-days on a curve that gets steeper toward the top: moving from 8 to 9 adds 2 days, moving from 14 to 15 adds 15. Hard fixes are disproportionately expensive, and the curve says so. The four difficulty buckets used in the charts are ranges of the combined score.

These are the published tables. The Effort Model page lets you change the D1 bands, the class table behind D2 and D3, the component adjustments and this curve, and see every figure recalculated. Those tables are kept in your browser only; this page and the published records always show the tables above.

Constants

One rate is used for every project and region. No productivity adjustment for AI-assisted coding is applied: nothing in the study measures one, and a modelled discount on a modelled cost would read as a finding.

Severity and CVSS

Severity is the rating the project or its advisory publishes, normalised to four levels: critical, high, moderate, low. The CVSS base score is recorded when the advisory provides one. Neither is used to compute cost — they are shown so cost can be compared against them.

• 10,217 of 11,652 priced records carry a CVSS score; 1,435 do not. 939 of those are Firefox, whose advisories rate impact on Mozilla's own four-level scale and carry no CVSS score.
• On 160 records the published label differs from the CVSS band (critical 9.0–10.0, high 7.0–8.9, moderate 4.0–6.9, low 0.1–3.9). We keep the project's label.
• 96 priced records have no published severity: on 73 it was assigned by our own grader from the vulnerability class, and on 23 the label is a placeholder ("moderate") because nothing published rates them. On 2026-10-11 the 48 corpus records whose "moderate" was a generator placeholder took the CVSS rating NVD publishes (one unpriced Keycloak record has none). The registry's severity_source column marks them (defaulted, inferred); the others read cvss or published.

How cost relates to severity

Cost has two parts: D1, measured from the fix, and D2+D3, set by the vulnerability class. Split that way, severity says almost nothing about how big a fix is. The weak link between severity and cost comes from the class table.

Rank correlation with severity (0 = none, 1 = perfect): engineer-days +0.12; written lines +0.08; D2+D3 +0.15. Memory-corruption, JIT and injection classes carry both higher severity ratings and higher reasoning and validation scores, so part of any severity–cost relationship is built into the rubric rather than measured from the fixes.

What counts as written code

D1 measures what an engineer wrote, so the raw diff is filtered first. Across priced records the median fix is 67 changed lines in the raw diff and 28 lines of written code.

• Excluded: tests; documentation, changelogs and release notes; files produced by tools (lockfiles such as package-lock.json or uv.lock, minified bundles, generated parsers, version headers); and third-party code copied into the repository.
• Dependency upgrades: when the fix is pulling in a patched third-party version — a wholesale update of a bundled library (more than 3 files or 200 lines), or a change recorded only in lockfiles — D1 is set to 1. The engineer chose and validated someone else's fix; the library's internals were not their work. 18 priced records are dependency upgrades. A small hand patch to bundled code does count.
• Backports: when the same fix lands on several release branches, it is counted once (the copy on the main branch). Several commits that fix the vulnerability one after another on the same branch all count.
• Since 2026-10-11: non-English translation files, requirements files for tests and static-analysis baselines do not count; a Python dependency manifest (requirements.txt) does; binary files are not counted as files.
• Moved code: lines relocated rather than written (for example, a refactor that moves a function into a shared helper in the same commit) are discounted. Detection uses git's moved-code comparison, which needs contiguous blocks, so coincidental matches of single lines such as a closing brace are not treated as moved. 66 priced records were adjusted.
• Commits that only mention a vulnerability — a later follow-up, a test added months afterwards, a commit citing an old vulnerability as background — are not treated as its fix.

Worked example

Shared fixes

Sometimes one change fixes several vulnerabilities. Charging its full effort to each would count the same work more than once. A commit is priced once: each record's own price is divided among its commits by the lines they change, and a commit — or the same patch on another branch — that several vulnerabilities share costs the largest share any of them gives it, split equally among them. When the vulnerabilities share exactly the same commits, that is the hardest grading among them, split equally. Today that is 542 shared commit groups covering 1663 records, removing 5736 engineer-days ($7,170,000) that would otherwise be counted twice. A further 244 records are duplicate advisories (one flaw published under two ids): the fix is priced on one id and the other points to it.

What is not priced, and why

3,584 of 15,236 records (24%) carry no cost. They stay in the data so “did you find CVE-X?” has an answer, but no estimate is invented for them. Unpriced does not mean the fix cost nothing; it means it cannot be measured from public information. Every total on these dashboards is therefore a floor.

Limitations

• The totals are floors, twice over. Unpriced records add nothing, and the record set itself is incomplete: NVD's product index misses CVEs that NVD has not yet analysed. A second search by product name and reference link found 141 in-window CVEs we do not yet hold (about 1% of the record count).
• Coverage follows disclosure practice. The share of records we can price runs from 0% (7-Zip) to 100% (AshAuthentication, Bouncy Castle (C#), Apache Cassandra, Django, Escargot, Fides, GitPython, Incus, Mastodon, Apache NiFi, OpenBao, OpenFGA, PhpSpreadsheet, Renovate, Spring AI, Tornado, Typebot, Undici, aiohttp, league/commonmark, http4s, Apache HTTP Server, pam_usb, pypdf (formerly PyPDF2), xmldom). Projects that name their fix commits get priced; projects that do not, mostly do not. Compare project totals with that in mind.
• It is a model. The rubric turns a fix's size and class into days; it is not time-tracking data. Where a project's engineers told us which files and lines a fix really was, their answer is used (13 records).
• Step boundaries. 1,679 of 11,634 measured records (14%) sit within 3 lines or 1 file of a lower D1 step, where a small measurement difference moves the cost by one row of the curve. Moving every one of them down a step would lower the total by $2,147,500 (5%). The model is deliberately coarse; the worked example is one of these records.
• Which commit is the fix. For 5,547 priced records (48%) the project itself names the fix — the commit cites the CVE, or the advisory links the commit. Those records carry 46% of the engineer-days. For the rest the match is ours: 28% of the days rest on links drawn from a shared key, such as an issue or pull-request number (inferred-high), and 26% on a choice among a release's candidate commits made by a model, an analyst or a title match (inferred-medium or -low). All of them count in the totals. Each record says which method was used and how confident the match is.
• CVSS is missing on 1,435 priced records, so any severity-versus-cost statistic covers a subset.

Questions