The same CVE in three different releases of your product can carry three different ratings, and all three can be correct. That is not a bug in the process. It is the point. A vulnerability's severity depends on the architecture, the controls, and the attack surface of the specific release it lands in.
This is why per-release context is the only honest way to score. A finding that is unreachable in the shipped v2.0 because a service was removed is genuinely not affected there, even if the same CVE is critical in v2.4 where the feature came back. Score the product as one blob and you will be wrong in both directions.
Every finding, rating, clock, and metric should be scoped to a release. When a finding moves between releases, it should carry forward as a clone with its own context, not a copy-paste of a rating that no longer applies. That is what makes postmarket metrics like time-to-remediation meaningful instead of misleading.
If your tool gives one product one score, it is telling you a comfortable fiction.
Start with one device. We build the twin from documentation your quality system already produces, run AI discovery remotely, and show you the graph: the handful to fix, and the evidence for everything else.
One issue a month on AI, exploitability, and FDA cybersecurity review. No spam, unsubscribe anytime.
Yes, and all of the ratings can be correct. Severity depends on the architecture, the controls and the attack surface of the specific release the vulnerability lands in. A finding that is unreachable in a shipped v2.0 because a service was removed is genuinely not affected there, even if the same CVE is critical in v2.4.
Score the product as one blob and you will be wrong in both directions, inflating findings that a given release already mitigates and hiding findings another release genuinely exposes. If a tool gives one product one score, it is telling you a comfortable fiction.
The release. Every finding, rating, clock and metric belongs to a specific release, because the release is the unit of context that decides whether a vulnerability is exploitable at all. Per-release context is the only honest way to score a connected product.
It should carry forward as a clone with its own context, not a copy-paste of a rating that no longer applies. The new release has its own architecture and attack surface, so the finding gets judged against those rather than inheriting a verdict from a version it no longer describes.
Yes. Scoping every finding, rating and clock to a release is what makes measures like time-to-remediation meaningful instead of misleading. A clock that runs across a whole product family mixes versions where the finding mattered with versions where it never applied.