EGAD! (Errata Gathered, Appraised & Documented) is Secur0’s public record of how we score vulnerabilities under CVSS 4.0.
Not the obvious calls. The ones that start arguments.
Why it exists
CVSS 4.0 is a specification, not a decision procedure. It defines the metrics and leaves the judgment to whoever is holding the report. That judgment is where triage teams differ from each other, where the same team differs from itself on a bad week, and where a researcher and an analyst end up talking past one another for three rounds.
Our own scoring is subject to the same problem. The way we deal with it is to write the judgment down, publish it, and apply it.
That gives three things:
- A researcher can see how a class of flaw scores before submitting, and can read the reasoning behind a verdict instead of being told the conclusion.
- Our analysts start from a written position rather than from whatever the report proposes, which is what keeps two similar reports from receiving two different answers.
- Anyone who disagrees has something specific to disagree with.
What a leaf contains
The folder tree is the taxonomy. Each leaf covers one class of weakness and holds:
- the full CVSS 4.0 Base vector for each realistic scenario in that class,
- the reasoning behind each metric, stated so that a specific sentence can be challenged,
- and where the line sits: why the scenario does not score higher, and what the case would look like if it did.
Scores and severities are derived from the vectors rather than written by hand, so a typographical error cannot quietly change a verdict.
Every leaf ends with a corrections log. It records, with dates, the occasions on which we changed our position and why. A registry that shows only its current opinion is not showing its reasoning.
What it is not
EGAD! is not a standard and is not intended to become one. It does not replace the FIRST CVSS 4.0 specification, which remains the authority. Where our reading departs from a natural reading of the specification, the leaf says so and gives the reason.
It is not exhaustive either. It covers the classes we score often enough to have argued about.
Chains
Leaves describe individual weaknesses, not chains. A finding such as “XSS that causes a user to perform a sensitive action” is two weaknesses: the injection, and the missing request validation that allows the action. Each is scored as what it is, and assembling the chain belongs to the report.
Where an individual weakness begins and ends is not something the specification settles. We draw those boundaries using CWE, the OWASP Top 10 and API Top 10, and our own analysis. Those boundaries are as open to challenge as the scores.
Disagreeing with a leaf
Scoring positions are revised on evidence and reasoning. To propose a change, open an issue or a pull request identifying the leaf and scenario, the interpretation as it currently stands, the interpretation you propose, and the reasoning for each metric that moves.
An accepted proposal changes how the class is scored in every subsequent Secur0 report, not only in the report that prompted it. It does not reopen decisions already taken, which are assessed under the version of the leaf current at the time.
Proposals that do not identify what should change and why cannot be evaluated and will be closed with a pointer to the contribution guide.
Scope of a decision
A decision is made under the version of the leaf in force when it was taken. Leaves are cited by path and by their updated date, for example injection/client_side/xss (2026-07-11). The version in force at any given moment is the most recently published one.
Disagreement with how a leaf was applied to a specific report is handled through the report or a support ticket. Disagreement with the leaf itself is handled here.