Reports arrive with a severity claim and a partial description. The industry is moving away from treating CVSS scores as decisions, toward exploitability evidence, because the score alone answers neither the engineering question (what do we fix) nor the communication question (what do we tell customers).
The technical questions behind every report are concrete: Does the behavior reproduce, and under which conditions, lab configuration or production defaults? What does an attacker actually achieve, full remote code execution, or a limited effect in an unlikely state? Which product versions are affected, not the whole catalog, the specific set? Where does the weakness originate, and does the proposed fix close the attack path, or only the reported instance?
Answering these under time pressure is the hard part. A report that arrives on Friday with the word "unauthenticated" triggers communication before analysis. The cost of a wrong answer runs both directions: underreacting ships an exploitable product; overreacting burns an emergency release on a non-issue and erodes the credibility of the next advisory.
The product decision depends on several technical answers.
- Reproduction Does the reported behavior reproduce under documented conditions, and do those conditions exist in deployed products?
- Exploitability What can an attacker actually achieve, with what access and complexity, beyond the severity label?
- Affected scope Which versions, variants and configurations are affected, established by evidence, not by release proximity?
- Root cause Where does the weakness originate, implementation, architecture or configuration, and what else shares that cause?
- Variant reach Does the same root cause produce other exploitable paths the report did not find?
- Fix verification Does the proposed fix close the original attack path, and the variants, when tested against the reproduction?
The Friday report was critical on paper, limited in the product.
The report describes an unauthenticated command injection, severity critical, remote, no conditions. The team prepares an emergency release and a customer advisory over the weekend.
Reproduction shows the behavior requires a diagnostic mode that ships disabled, enabled only on internal test firmware. The affected scope is zero production versions. The emergency release is cancelled on Monday. The variant check finds a related parser weakness on the production path, medium severity, actually reachable, that the original report missed entirely.
Replace severity with evidence, then verify the fix.
We take the report and produce the missing facts: reproduction under field-representative conditions, exploitability beyond the label, evidence-based affected scope, root cause with variant analysis, and verification that the fix closes the path, the original and the variants.
- An external researcher reports a product vulnerability
- A customer reports a security issue
- An internal review finds suspicious behavior
- Exploitability of a reported issue is disputed
- A fix needs independent verification before release
- An advisory needs defensible affected-version data