The CVSSF is a risk-exposure metric created by Fluid Attacks that turns a CVSS base score into an exponential value through the formula CVSSF = 4^(CVSS−4). It exists because severity does not add up in a straight line: ten findings scoring 1.0 are not the equivalent of one scoring 10.0.
The gap is arithmetic, not rhetorical. Those ten low-severity findings are worth about 0.2 CVSSF units between them. The single critical one is worth 4,096. In Fluid Attacks’ State of Attacks 2026, built on 1,119,396 vulnerabilities reported across client systems between January 1 and December 31, 2025, the 4.5% that were high or critical carried 79.9% of all reported risk exposure.
This page covers what the CVSSF is, how its formula and its two constants work, what the metric does and does not measure, how it sits next to CVSS, EPSS and the KEV catalog, and how Fluid Attacks uses it — including inside a contractual service-level agreement.
Ten CVSS 1.0 vulnerabilities do not equal one CVSS 10.0 vulnerability
What is the CVSSF?
The CVSSF is a metric that expresses how much risk exposure a vulnerability adds to a system, rather than how severe that vulnerability is on its own. Fluid Attacks created it, and its documentation defines it as a transformation of the CVSS base score built to help organizations prioritize vulnerability remediation. The “F” stands for “a la Fluid Attacks.”
It answers a question a severity score cannot: when you add up everything open in a system today, how much exposure is that? CVSS scores do not survive addition. A list of 400 findings averaging 5.2 tells you nothing about whether the system is in trouble, because the average hides both the long tail and the outlier. A CVSSF total does tell you: the aggregate is built so one critical finding outweighs hundreds of minor ones by orders of magnitude.
Three things the CVSSF is not. It is not a standard: the Forum of Incident Response and Security Teams (FIRST) maintains CVSS, Fluid Attacks maintains the CVSSF, and no standards body recognizes it. It is not a probability, because a deterministic transformation of a severity score says nothing about whether anyone will exploit the flaw. And it is not a replacement for a vulnerability count, which teams still need to plan capacity; vulnerability prioritization works best with both numbers on screen. The questions about exploitation belong to EPSS and to CISA’s catalog of known exploited vulnerabilities, covered further down.
How the CVSSF is calculated
The general form is CVSSF = P^(CVSS−R), where P and R are constants an organization chooses. Fluid Attacks sets both to 4, which gives the working formula 4^(CVSS−4).
The general form of the CVSSF, with its two constants.
The formula and its two constants
P stands for proportionality. It sets how many vulnerabilities of a given CVSS base score equal one vulnerability scoring a point higher. Fluid Attacks’ security experts settled on 4 by consensus, and the value has been published here since the metric was introduced: four findings at CVSS 9.0 equal one at 10.0. R stands for range, and it anchors the curve so the output stays in numbers a team can work with. With R at 4, a CVSS 4.0 finding is worth exactly 1 unit, and everything below that threshold lands in fractions.
Those two choices are the only judgment calls in the model, and they are explicit on purpose. An organization that believes severity escalates faster can raise P; one that wants a flatter curve can lower it. Nothing is hidden behind the number.
The working form Fluid Attacks applies to every finding it reports.
The equivalence ladder
Running the formula across the CVSS range makes the curve concrete:
CVSS base score | CVSSF = 4^(CVSS−4) | Equivalent in CVSS 1.0 findings |
|---|---|---|
1.0 | 0.02 | 1 |
2.0 | 0.06 | 4 |
3.9 | 0.87 | 56 |
4.0 | 1 | 64 |
5.0 | 4 | 256 |
6.9 | 55.7 | 3,566 |
7.0 | 64 | 4,096 |
8.0 | 256 | 16,384 |
8.9 | 891.4 | 57,052 |
9.0 | 1,024 | 65,536 |
10.0 | 4,096 | 262,144 |
CVSSF values across the CVSS range, calculated with 4^(CVSS−4). The third column divides each value by the 0.02 units of a CVSS 1.0 finding.
Two rows deserve attention. The jump from 8.9 to 9.0 — the line where CVSS stops calling a finding “high” and starts calling it “critical” — is worth 132.6 units. The jump from 9.0 to 10.0, entirely inside the critical band, is worth 3,072. The qualitative severity rating scale changes at the smaller gap and stays put through the larger one.
A worked example: Log4Shell against a thousand low-severity findings
Picture an organization with 1,000 open findings at CVSS 3.0 and no critical ones. On December 10, 2021, CVE-2021-44228 lands in one of its dependencies. The NVD assigns it a CVSS v3.1 base score of 10.0 and a severity rating of Critical.
By count, the backlog moves from 1,000 to 1,001 — a rise of 0.1%, invisible on any dashboard. By exposure, the 1,000 findings at CVSS 3.0 are worth 250 units, and the new one is worth 4,096. Total exposure rises by more than 1,600% overnight, and the single new finding accounts for 94% of it. That is the argument for the metric in one event.
The same 1,001 findings, counted two ways. Own work.
Two points of precision. Log4Shell carries a CVSS v3.1 score, while Fluid Attacks’ 2025 figures use CVSS v4.0 ranges, so values produced under different CVSS versions should not be compared without saying so. And 4,096 here is the result of applying the formula to a public score, not an official rating published for that CVE.
Why counting vulnerabilities hides risk
A vulnerability count treats every finding as one unit, which is the one thing a severity score tells you is false. Teams know this, which is why most vulnerability management programs group findings into low, medium, high and critical buckets and work the buckets separately. That produces four numbers that cannot be added, and a view of the system that never resolves into a single answer. Risk-based vulnerability management asks for one figure, and a bucketed count cannot produce it.
Severity bands are arbitrary; exposure is not
A finding is critical only at 9.0 and above, so an 8.9 is labeled high. That 0.1 of difference decides which one gets escalated, while an 8.9 and a 7.0 share a label despite sitting 827 CVSSF units apart. The bands are a communication device, not a measurement, and prioritizing by them means prioritizing by where someone once drew a line.
FIRST says as much in its CVSS v4.0 User Guide, under a section titled “CVSS Base Score (CVSS-B) Measures Severity, not Risk.” The guide states that base scores are designed to measure the severity of a vulnerability, and that the score is independent of any factor associated with threat or the computing environment. The organization that publishes the scoring system is explicit that the score alone is not a risk figure.
That leaves a gap between what CVSS produces and what a security program has to report, and the CVSSF is one way of closing it: keep the scoring work FIRST already standardized, then change the scale on which the results are added together.
What our 2025 data shows
Fluid Attacks’ State of Attacks 2026 covers 1,119,396 vulnerabilities reported in client systems between January 1 and December 31, 2025, representing 27,440,146 CVSSF units of exposure. The split:
High and critical findings: 50,495 vulnerabilities, 4.5% of the total, carrying 79.9% of all reported risk exposure.
Low-severity findings: 807,169 vulnerabilities, 72.1% of the total, carrying 29,839 CVSSF units — roughly one thousandth of the aggregate.
Systems with at least one high or critical finding: 70%, up from 53.3% the year before.
The mean system in that dataset held 1,266 vulnerabilities and 31,041 CVSSF units. Cut the count in half by clearing the low-severity tail and the exposure barely moves. Mean exposure per system rose 8.5% year over year while the median rose 33.5%, which says the increase was broad rather than driven by a handful of outliers.
The CVSSF at Fluid Attacks
Fluid Attacks reports every finding with its CVSSF value, aggregates those values into the aggregated risk exposure shown across the platform, and measures its own accuracy against them in a contractual SLA. The metric is not a label added at the end of a report; it is the unit the work is graded in.
Where the metric appears in the platform
In the Groups section of the Fluid Attacks platform, the vulnerability summary for an organization shows four figures, and one of them is, in the words of the documentation, “The total CVSSF units corresponding to open vulnerabilities.” It sits beside the count of open vulnerabilities rather than replacing it, because the two answer different questions: how much work is queued, and how much exposure is live.
The platform shows the count and the exposure side by side.
The input to that total is published openly. The Fluid Attacks Database lists every weakness type with its CVSS 4.0 base metrics, its threat metrics and the full vector string, so anyone can rebuild the score a finding of that type starts from before judging the number it produces.
The base metrics and vector string published for each weakness type.
Our Accuracy SLA is written in CVSSF
Since January 2025, Fluid Attacks has held an Accuracy SLA for groups on the Advanced plan, with two thresholds. Reports of a client’s exposure commit to an F2 score of at least 90%, and reports of its vulnerabilities to an F0.5 score of at least 90%. The documented breach condition is narrow: the SLA is broken when both accuracies fall below 90%.
The first of those is calculated in CVSSF. The procedure in the documentation is explicit: compute the value of each vulnerability with 4^(CVSS−4), total the figures for the true positives, false positives and false negatives, derive precision and recall from those totals, and apply the F2 formula. F2 weights recall over precision, so the measure punishes a missed critical finding far harder than a false alarm — the correct shape for a number a security team has to trust.
The second threshold uses plain vulnerability counts and an F0.5 score, which weights precision. One commitment protects the people managing risk; the other protects the developers working the queue.
Manual and automated testing, measured in CVSSF
Switching the unit of measurement changes what the results say about security testing methods. Manual testing here means penetration testing carried out by Fluid Attacks’ pentesters. From State of Attacks 2026:
Measure | Automated tools | Manual testing |
|---|---|---|
Share of vulnerabilities found | 88.4% | 11.6% |
Share of exposure found | 55.8% | 44.2% |
Mean CVSSF per finding | 15.5 | 93.2 |
Tool figures cover the Advanced and Essential plans; manual testing figures cover the Advanced plan only. State of Attacks 2026, data from 2025.
By count, automation does almost nine tenths of the work. By exposure, it does a little over half. A finding reported by a pentester carried six times the exposure of one reported by a scanner across that dataset.
The number we would rather not publish
In Fluid Attacks’ benchmark of 36 third-party AppSec tools against a deliberately vulnerable web application holding 1,201 known vulnerabilities across 105 CWE categories — 461,500 CVSSF units in total — Fluid Attacks’ own scanner had the best automated recall at 22.7%, with 99% precision. Weighted by exposure, that same scanner reached 8.8% recall. The best third-party tool in the published table reached 7.0%, and the benchmark notes that the exposure-weighted recall of all 37 evaluated tools, added together, would not reach 60% of the total.
The pentester in the same study found 1,076 of the 1,201 vulnerabilities with zero false positives: 89.6% recall, and 98.9% once weighted by exposure. The 743 findings no automated tool detected — 61.9% of the universe — accounted for 86.8% of the total risk exposure.
Read plainly, that cuts against automation, ours included. A clean scan is not evidence of a secure application; it is evidence that the fast layer finished. This is the second reason the metric matters: it surfaces false negatives that a vulnerability count papers over, because the findings a scanner misses are disproportionately the expensive ones.
What the metric does not tell you
The metric transforms severity. It does not know whether a vulnerable function is reachable, whether the input is attacker-controlled, or whether anyone is exploiting the flaw today. Fluid Attacks’ account of how AI-assisted static analysis findings get validated describes researchers tracing the source-to-sink flow and reproducing the issue locally before it is confirmed — work no score performs for you. A 4,096 on an unreachable path is still a 4,096, and only context tells you otherwise.
CVSSF, CVSS, EPSS and KEV are not alternatives
These four answer four different questions, and a prioritization process that uses only one of them is missing information the others carry.
Metric | Question it answers | Maintained by | Range |
|---|---|---|---|
CVSS base score | How severe is this vulnerability in the abstract? | FIRST | 0.0 – 10.0 |
CVSSF | How much does it add to aggregated risk exposure? | Fluid Attacks | ≈0.005 – 4,096 |
EPSS | How likely is exploitation in the next 30 days? | FIRST | 0 – 1 |
KEV | Is there evidence of exploitation in the wild? | CISA | Yes / No |
What each metric measures, and who maintains it.
CVSS is the input and the CVSSF is the aggregation, so the two are sequential rather than competing. EPSS, also from FIRST, estimates exploitation probability from observed data. CISA’s Known Exploited Vulnerabilities catalog records what attackers are using right now, and its three inclusion criteria are public: the vulnerability has an assigned CVE ID, there is reliable evidence of active exploitation in the wild, and there is a clear remediation action.
A KEV entry with a moderate CVSS score can deserve attention before a 9.8 that nothing is exploiting. The CVSSF tells you how much exposure is on the table; the other two tell you how fast it is likely to come due. Pairing the CVSSF with both is cheap, because they are independent inputs to the same sort.
How to put the CVSSF to work
Start by reporting exposure and count side by side, not one instead of the other. Risk-based vulnerability management needs both: the count to plan capacity, and the CVSSF to decide order. Replacing one with the other trades a known blind spot for a new one.
Set your own P, then leave it alone. Fluid Attacks uses 4 because its experts converged on it, and the constant is published so anyone can disagree with it. Pick the value that matches how your organization weighs an extra point of severity, write down the reasoning, and keep it stable — a curve that changes every quarter makes trends meaningless.
Track open exposure over time, not exposure closed. Remediation numbers look best when teams clear low-severity findings in bulk. Open CVSSF only moves when something that mattered gets fixed.
Set vulnerability remediation targets in CVSSF, not in percentage of findings closed. “Reduce open exposure by 60% this quarter” survives contact with a backlog. “Close 60% of findings” is a goal a team can hit while leaving every critical issue open.
Cross the top of the list with exploitability signals. Sort by CVSSF, then check the leading findings against exploitation data and the KEV catalog. The metric orders the queue; exploitability evidence decides what jumps it.
Expect misses to dominate your error budget. If your highest-recall scanner finds under a tenth of your exposure, the gap does not close by tuning it. It closes by adding manual penetration testing on top, which Fluid Attacks delivers as Pentesting as a Service (PTaaS).
Conclusions
The CVSSF is a small idea with a large consequence. Raising 4 to the power of a CVSS score minus 4 turns a severity label into a quantity that can be added, compared across systems and tracked over time — which is what every security program needs and what a vulnerability count never provided. Vulnerability remediation stops being a queue to drain and becomes a CVSSF number to move.
The cost of not measuring this way shows up in Fluid Attacks’ own 2025 data: 4.5% of findings carried 79.9% of total exposure, so a program graded on count was grading the 95.5% that barely mattered. The limit of the CVSSF is equally clear. It ranks exposure, not likelihood, and it inherits whatever a CVSS score got right or wrong. Used next to EPSS and the KEV catalog, the CVSSF gives a remediation queue an order that holds up when someone asks why. Two CVSSF numbers — open exposure now and open exposure a quarter ago — say more about a security program than any count of findings ever did.
Frequently asked questions
What is the CVSSF formula?
The CVSSF formula is 4^(CVSS−4), a specific case of the general form P^(CVSS−R) with both constants set to 4. A CVSS 4.0 finding is worth 1 unit, a 7.0 is worth 64, a 9.0 is worth 1,024, and a 10.0 is worth 4,096. Below 4.0 the values are fractions: a CVSS 1.0 finding is worth 0.02 units, so ten of them total about 0.2.
Is the CVSSF a security standard like CVSS?
No. Fluid Attacks created and maintains the CVSSF, while FIRST maintains CVSS, and no standards body recognizes it. It is a transformation applied to a CVSS score, which means it depends on CVSS rather than competing with it. Treat it as a reporting and vulnerability prioritization metric with a published formula, not as an industry standard.
How is the CVSSF different from EPSS?
The CVSSF measures how much risk exposure a vulnerability contributes; EPSS estimates how likely it is to be exploited within 30 days. One is a deterministic function of a severity rating, the other a probability derived from observed exploitation data. They disagree often and usefully: a high-exposure finding that nothing is exploiting may wait behind a moderate one listed in CISA’s KEV catalog.
Does a lower vulnerability count mean lower risk?
No, and Fluid Attacks’ own data shows why. Across 1,119,396 vulnerabilities reported in client systems during 2025, the 4.5% rated high or critical carried 79.9% of total risk exposure, while the 72.1% rated low carried about one thousandth of it. A team that closes hundreds of low-severity findings can cut its count sharply and leave its exposure essentially unchanged.
Does Fluid Attacks use the CVSSF in its service-level agreements?
Yes. The Accuracy SLA, in force since January 2025 for the Advanced plan, commits risk exposure reports to an F2 score of at least 90%, calculated by totaling the values of true positives, false positives and false negatives. A second threshold commits vulnerability reports to an F0.5 score of at least 90% on plain counts, and the SLA is breached when both fall below 90%. The metric is a contractual commitment, not a presentation layer.
Measure the exposure, not the queue
Our AI, scanners and pentesters report every finding with its CVSSF value, so your team can fix what moves the number instead of clearing a backlog. Start free trial · Contact us
Get started with Fluid Attacks' RBVM solution right now
