How Ovesion decides
Where Ovesion’s answers come from, why it never says “safe”, and how each fix gets one of four public urgency decisions.
1. Where the answers come from
Ovesion trusts the product’s own vendor first, then NVD, then others. New and changed vulnerabilities are collected every 15 minutes.
| Source | What it gives |
|---|---|
| Red Hat | For each package, the fixed version per release stream, Red Hat’s own states (such as “will not fix”) and its advisories. |
| Microsoft | Each month’s security updates: the fixed build for each Windows product, per vulnerability. |
| Vendor CVE records (CVE.org) | The issuing vendor’s own affected and fixed versions, for vendors such as Fortinet and Oracle. |
| Cisco | Security advisories, including the first fixed builds. |
| NVD | New and changed vulnerabilities, and version ranges where NVD has them. |
| CISA | The Known Exploited Vulnerabilities list, and CISA’s ratings of exploitation, automation and impact. |
| FIRST EPSS | The daily estimate of the chance of exploitation in the next 30 days. |
2. Three answers, never “safe”
For each vulnerability and each version you run, the answer is one of:
- Affected: your version is in the affected range. The vulnerability joins a fix.
- Not affected: your version is outside it, so it is left out.
- Can’t confirm: the records do not settle it. It is listed under Can’t confirm with the reason and who can settle it: you, the vendor or Ovesion. It is never dropped.
Rules Ovesion keeps
- Not enough evidence means Can’t confirm, never “not affected”.
- A version later than every listed release is never assumed safe.
- A machine that stops reporting is never treated as patched.
- Ovesion never says an environment is safe.
Matching depends on what vendors and NVD publish. Treat Ovesion as a strong first filter, not a guarantee that nothing has been missed.
3. Collected and typed technologies
Machines that report through a collector
- Red Hat Enterprise Linux: each installed package is checked against Red Hat’s statements for the machine’s own release stream. A fix Red Hat has shipped at or below the installed version counts as fixed.
- Windows: the machine’s build and update level are matched to Microsoft’s own product (Windows Server 2025 and Windows 11 share a build number and are kept apart), then answered from Microsoft’s fixed builds. A build Microsoft’s monthly data does not list goes to Can’t confirm, never to affected.
Technologies typed in by hand
Ovesion compares the version you entered with the vendor’s own statements and records first, then NVD, using each vendor’s own version rules. A typed Windows build is answered from Microsoft’s data like a collected one.
4. One fix per technology
Each affected vulnerability’s fixed version comes from its vendor or NVD record. The fix targets the highest of them on your release line; vulnerabilities fixed only on a later line are listed per line. Red Hat ships fixes per package, so a Red Hat technology’s fix is its package updates, with their advisories. Where no fix exists, the row is a mitigation.
5. How urgent: four decisions
Ovesion uses SSVC, a public decision method from CERT/CC (its deployer model). For each vulnerability it asks four questions:
- Is it exploited? Active if it is on CISA’s Known Exploited Vulnerabilities list, CISA rates it exploited, or the vendor says it is. A public proof of concept if one is published. Otherwise none.
- Is it exposed? Open if you declared the technology internet-facing or have not said; controlled if you declared it internal only.
- Can an attacker automate it? CISA’s rating where there is one; otherwise from the CVSS details: reachable over the network, with no privileges and no user interaction.
- What is the impact? From how critical you said the technology is; not answered counts as standard.
| Decision | What to do |
|---|---|
| Immediate | Act now: put everything into applying the fix. |
| Out of cycle | Apply it before your next maintenance window, at the next opportunity. |
| Scheduled | Apply it in your regular maintenance window. |
| Watching | No action yet. Ovesion keeps watching and emails you if the fix becomes urgent. |
A fix takes the decision of its most urgent vulnerability. Where CISA has not rated a vulnerability, it counts as not exploited and not automatable, and the fix says so.
6. Order, and what is shown but not scored
Within a decision, fixes are ordered by exploited vulnerabilities, then public exploits, the highest EPSS, the highest CVSS, then how many vulnerabilities they close. EPSS and CVSS are evidence, not a second score.
Also shown, but not used in the decision: known use in ransomware, CISA’s deadline (a US federal deadline, a benchmark rather than your due date), Microsoft’s exploitability rating, the vendor’s severity, workarounds and mitigations, and how EPSS moved.
After you record an upgrade, Ovesion checks every vulnerability again at the new version.