How Patcharo turns security information into informed decisions.

1. 01

   Collect

   Official sources are read on fixed cadences: CISA KEV, NVD, the CVE records and CERT-FR at every synchronisation, every three hours; the Fortinet and Palo Alto Networks PSIRT feeds every fifteen minutes; the vendors’ release catalogs every six hours; their life-cycle and recommendation pages about once a day. Every read keeps its time, its digest and its parser version.

   What it gives you You know where each fact comes from and when it was read.

2. 02

   Structure

   Records are parsed by rules: affected and fixed releases are read from the vendor’s documents in the vendor’s own numbering (PAN-OS hotfixes, Check Point Takes), scores are kept as published, exploitation as stated. No language model decides a fact; texts are only translated, and every translation is checked before it is shown.

   What it gives you Comparable facts, never invented ones.

3. 03

   Match

   Each version you follow, in your inventory or in a watch, is compared with the affected ranges: Affected, Fixed, Not affected, Needs review or Unknown. Missing data never becomes a reassuring result, and a watch without a version only says that a vulnerability is relevant.

   What it gives you One status per device, with its evidence.

4. 04

   Prioritise

   The elements of a decision sit side by side: known exploitation (CISA KEV or the vendor’s own statement), probability of exploitation (EPSS), severity (CVSS), the exposure and criticality you declared. The priority score adds up visible reasons; it does not replace your judgement.

   What it gives you You see why now.

5. 05

   Fix and follow

   For each vulnerability: the fixed release the vendor names, its workaround, the action CISA requires, the CERT-FR recommendation. In the application, actions carry a workflow (new, in progress, deferred, accepted risk) and material changes alert you by e-mail.

   What it gives you An action, not a list.

• Severity

  Source · CVSS base score, versions 2.0 to 4.0, from NVD or the vendor’s CVE record

  What it says

  The technical impact of the flaw on a scale from 0 to 10, with its vector; four levels: critical, high, medium, low.

  What it does not say

  Whether anyone exploits it, nor whether your device is affected.

• Probability of exploitation

  Source · FIRST EPSS, read about once a day

  What it says

  The probability that the vulnerability is exploited within the next 30 days, with its percentile among all CVEs and the date of the estimate.

  What it does not say

  A measure of your exposure, nor a verdict: it complements CVSS, it does not replace it.

• Known exploitation

  Source · CISA KEV at every synchronisation; the vendor’s own bulletins (Fortinet, Palo Alto Networks)

  What it says

  That exploitation is observed: the KEV listing with its date, due date and ransomware flag, or the vendor’s sentence as written.

  What it does not say

  That an unlisted vulnerability is safe. Absence of evidence is never read as absence of risk.

• Matching status

  Source · Patcharo’s matcher, on the vendor’s affected and fixed ranges

  What it says

  Affected, Fixed, Not affected, Needs review or Unknown for a given version; a watch without a version is only told that the vulnerability is relevant.

  What it does not say

  A status for a custom or unverified value, and never a clean result from missing data.

• Fix availability

  Source · The vendor’s CVE record and advisories, Check Point’s Jumbo Hotfix notes, Cisco’s fixed software tables, FortiGuard

  What it says

  The first fixed release the vendor names per branch, a migration when the branch has none, the workaround as written, CISA’s required action, the CERT-FR solution.

  What it does not say

  A fix the vendor did not name: a release derived from an exclusive bound is marked as such, and a contradiction between documents stays a conflict.

• Priority and action

  Source · Patcharo’s rules, on the facts above and the exposure, environment and criticality you declared

  What it says

  An additive score capped at 100 whose every point has a visible reason (known exploitation 35, critical severity 20, internet exposure 12…), and an action: Action required, Plan, Monitor, Needs review, No action.

  What it does not say

  A business risk estimate. Fixed and Not affected records score zero; Unknown and Needs review never become No action.

• Latest public release

  The newest release the vendor’s own documentation lists for a branch, with its publication date when the vendor states one. Being the newest says nothing about whether the vendor recommends it.

• Vendor recommendation

  A release the vendor itself designates, with the date of the statement and its scope: for every deployment (Check Point’s recommended release), for the maintenance of one branch (the recommended Take), or for named models (Fortinet). Palo Alto Networks and Cisco publish their guidance behind a sign-in Patcharo does not read: their pages say so instead of guessing.

• Fixed release for a vulnerability

  The first release of a branch the vendor names as fixing a given CVE. It is a fact of the vulnerability, not of the branch: a branch’s recommended release may or may not contain a given fix.

• Support

  The branch’s and the appliance model’s life-cycle dates, as the vendor publishes them. A supported release is not necessarily recommended, and a recommended release may be nearing its end of support.

• Conditions and gaps

  A recommendation may be tied to a model or a platform: the condition is shown with it. When no public source exists, or the vendor published none, the page says which, and never fills the gap.

Check Point: its website (SK articles, Jumbo Hotfix notes, recommended release, support life cycle) is not read automatically since 23 Oct 2026, because its terms subject automated reading to Check Point’s written permission. Check Point CVEs come from the records Check Point publishes through the CVE Program, updates included, cross-checked with NVD, CERT-FR and CISA KEV. The facts read on its website until then stay, each with its document and date of verification. A fixed Take is shown only where a document names it: a CERT-FR advisory consistent with the record, or Check Point’s own document read before. Otherwise a Take after the last affected one stays “not confirmed”, never “not affected”.

The state is the source’s: a recent read of a source does not mean every fact of that vendor was checked again; each fact carries its own date.

Is a version absent from the catalog necessarily safe?

No. The catalog lists what the sources read say. A version Patcharo cannot match is Unknown, and Unknown never becomes Not affected.

Is the latest published release always the recommended one?

No. The newest release is an availability fact; a recommendation is the vendor’s statement, with its date and scope. The two are shown apart, and some vendors publish no public recommendation.

Does a recommendation apply to every device?

Not necessarily. Check Point’s recommended release is vendor-wide, a recommended Take belongs to one branch, Fortinet’s recommendations are per model. The scope is shown with each statement.

Why does a verification date change when the content is identical?

Because the page was read again and found identical: the fact was checked, not changed. When the content changed, the analysis date moves too and the change is recorded.

What does Patcharo not do?

It does not scan or connect to your devices, does not apply patches, and does not have a model judge a fact. It reads official sources and matches them with the versions you declare; the vendor advisory remains the reference before any change.