CyberSecurityUPandClaude Opus 5 0422b8dc41 feat(cvss): grade by the impact actually demonstrated, not by the class name ...

"SQLi = Critical" was the shortcut. The same weakness is a different finding
depending on how far the evidence took it, and the report has to be able to
defend the difference.

A ladder is read off the recorded observations:
  reached the component  → the mechanic is proven, impact is not
  read data              → confidentiality impact is real
  read SENSITIVE data    → and it is high
  wrote (read-back)      → integrity impact is real
  executed code          → the system is compromised
  crossed to a second system → scope changes
The class now sets the CEILING and the evidence sets the score, so an injection
that reached the interpreter and extracted nothing no longer scores like one
that returned credentials.

Only observations climb it. "Could lead to remote code execution" stays at the
bottom rung — a test asserts exactly that, because prose is where inflation
enters.

Temporal metrics come from facts the engagement owns: E from whether a runnable
PoC exists, RC from the validation verdict (needs-review is Reasonable, never
Confirmed). They only ever lower the score.

A bug the tests caught: the first rung kept the class's availability impact, so
"reached" scored ABOVE "read data" — the ladder inverted at its first step.

Two older tests encoded the behaviour this replaces ("a bare CWE-89 must be
critical"). They now assert the new contract instead: a class name alone earns
no critical, and command execution scores like command execution only when
execution was observed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-14 00:39:35 -03:00

..

harness

feat(cvss): grade by the impact actually demonstrated, not by the class name

2026-09-14 00:39:35 -03:00