Vulnerabilities (CVE lookup)

Security > Vulnerabilities answers the question a security team asks after every headline vulnerability: which of our machines are exposed to it, and is there a fix?

A CVE (Common Vulnerabilities and Exposures) id names one published vulnerability, for example CVE-2024-3094.

Look up a CVE#

1. Open Security > Vulnerabilities.
2. Type the CVE id in Look up a CVE and choose Look up.

The machines come in sections, exposed first: Exposed, fix available, Exposed, no fix published yet, Not checked and Not exposed (folded until you open it), each with its count, a search box and pages. The Machines list further down works the same way, machines with a fix to install first.

Each machine shows one of:

The page also lists the CVEs found on the most machines (actively exploited first, then new, then fixable by exploit chance and severity) and each machine's count. Download CSV exports every exposed CVE per machine, with whether it is actively exploited, CISA's due date, whether ransomware groups use it, and its EPSS score.

When machines are checked#

Gardience checks every machine once a day. Check all machines now starts a check at once; it takes a few minutes. Each check is recorded in the audit log.

Fix one CVE#

Under Look up a CVE, a CVE that is exposed with a fix available shows Fix on N machines. It starts the runbook Fix a CVE on the group All machines, which changes only the machines the last check found exposed, and only the updates for that CVE, plus any package those updates require (for example, a newer PHP may need a newer library): other pending updates stay pending. It goes through your approvals and change windows like any patch run.

You can also run Fix a CVE on any node group from Automation > Runbooks; machines in the group that are not exposed are left alone. Run a CVE check afterwards (or wait for the daily one) to see the result.

Your scanner's findings#

If you run a vulnerability scanner, import its findings on the Vulnerabilities page with Import scan file (admins):

• ACAS or Nessus: the scan file itself (.nessus), or a zip of several, up to 1 GB. This is what DoD's ACAS produces. The file streams to disk as it uploads, is read, and is then deleted: Gardience keeps only the findings (machine, CVE, severity). A 460 MB scan with 640,000 findings reads in seconds.
• Any scanner's CSV export (Tenable, Qualys, Rapid7 InsightVM and others with a host and a CVE column), up to 25 MB.

Gardience matches each host to a machine by its full name, short name, NetBIOS name or IP address. Hosts that match no machine are counted and listed.

For each CVE the scanner reported, the card shows on how many machines, how many of those Gardience's own check confirms, and Fix on N: Fix a CVE on the confirmed machines, through your approvals. A scanner finding alone never makes Gardience change a machine; the fix uses Gardience's own data for what to install. A new import replaces the previous one; Remove import deletes it. Imports and removals are recorded in the audit log.

New on your machines#

Gardience remembers when each CVE with a fix was first found on your fleet. For 14 days it is marked new and listed first, even when the vendor has not rated its severity yet (a brand-new CVE often has no rating for a day or more). When a check finds new CVEs with a fix, Gardience sends one alert naming them, at the "action" level, to the Slack or Teams webhook, email and PagerDuty you set up under Settings. The first check after installing only records what is already there, so it does not alert. GARDIENCE_CVE_ALERT_MIN (default 1) sets how many machines a new CVE must reach before it is alerted.

Actively exploited (CISA KEV)#

Most CVEs are never used in a real attack. CISA (the US Cybersecurity and Infrastructure Security Agency) keeps the Known Exploited Vulnerabilities catalog, the CVEs with reliable evidence of attacks in the wild. Gardience downloads it once a day and marks every CVE in it:

• exploited: in the catalog. Hover for the date CISA added it.
• ransomware: CISA lists it as used in ransomware campaigns.
• CISA due: the date US federal agencies must fix it by (under CISA's directive BOD 26-04, often three days). It is a useful deadline for anyone; it binds only federal agencies.

Exploited CVEs are listed first, earliest due date first, and the first figure on the page counts the machines that have at least one. Looking up a CVE says whether it is in the catalog. The first time a check finds an exploited CVE on your machines (including one CISA adds to the catalog later), Gardience sends one alert naming it at the "failure" level, the most urgent: the webhook, email and PagerDuty you set up under Settings.

On a network with no internet, download the catalog's JSON file from cisa.gov elsewhere, carry it in, and choose Import CISA or EPSS file on the Vulnerabilities page (admins). Gardience accepts only a file that reads as the catalog, keeps the previous one otherwise, and records the import in the audit log. Import a fresh copy at least weekly: CISA adds entries most weekdays.

Likely to be exploited (EPSS)#

Most CVEs are never exploited, so severity alone sends teams after the wrong fixes. FIRST's EPSS (Exploit Prediction Scoring System) gives each CVE the chance it is exploited in the next 30 days, recalculated daily from real attack data. Gardience downloads the free scores once a day and shows them as Exploit chance in the list and in a lookup. The list orders fixable CVEs by that chance (in steps of 10%, then by severity) after actively exploited and new ones. A brand-new CVE may have no score for a day or two; the new mark covers it.

On a network with no internet, download epss_scores-current.csv.gz from first.org/epss elsewhere and choose Import CISA or EPSS file on the Vulnerabilities page; Gardience tells the two files apart and accepts only a file that reads as one of them.

Machines waiting for a restart#

A kernel fix protects a Linux machine only once it runs the new kernel, and a package check sees only what is installed. So each Linux machine also says whether it needs a restart: a newer kernel is installed than the one running, Debian updated the running kernel in place, Ubuntu or Debian asks for one (/var/run/reboot-required), or on RHEL and its rebuilds dnf needs-restarting -r says core packages changed. Those machines are marked restart needed in the Machines list (hover for the reason and both kernel versions) and counted at the top of the page. Run Reboot a node group or the Patch, reboot, wait, verify workflow when it suits you. A container, or a machine with no kernels under /boot, cannot tell and is not marked.

Fix requests opened for you#

Each daily check can open the fix for you. Open fix requests automatically on the Vulnerabilities page (admins) chooses which CVEs:

• Actively exploited CVEs (the default): every CVE in CISA's catalog that has a fix and is on your machines.
• Actively exploited and critical CVEs: those, plus every CVE the vendor rates critical that has a fix.
• Off.

The check puts the CVEs it finds into one request under Automation > Workflows and approvals, at most 20, actively exploited first, earliest CISA due date first. It waits there for an admin to approve: nothing installs before that. When approved, it runs Fix a CVE for each one: only the exposed machines, only that CVE's updates, with change windows and locks applied. A failed CVE does not stop the others. Rejecting the request means those CVEs are not asked about again; a CVE still exposed three days after its fix ran (a machine was off, for example) is asked about again. Kernel fixes protect after a restart: see above. Every request is in the audit log.

Where the answers come from#

The Gardience server downloads the Debian data and Canonical's data once a day (Canonical's only for the Ubuntu releases your machines run) and Microsoft's data once a week (the last 12 months; a cumulative update fixes everything before it). It downloads CISA's catalog and the EPSS scores once a day. The server therefore needs HTTPS access to security-tracker.debian.org, security-metadata.canonical.com, api.msrc.microsoft.com, www.cisa.gov and epss.empiricalsecurity.com (where FIRST publishes the EPSS file). Canonical's file for one release is large (over 200 MB of XML); the server reads it in a separate short process, so it never stays in the service's memory.

On Debian, the kernel is checked as the one running: its version (from /proc/version) against the security tracker's entries for the linux source package. The installed kernel packages come from linux-signed-amd64 (or -arm64), which the tracker does not list, so a package list alone would miss kernel CVEs. A newer kernel installed but not yet running still shows as exposed until the machine restarts.

On Ubuntu, a CVE that Canonical lists for an installed package without a fix yet shows as exposed with no fix available. Kernel vulnerabilities are checked the way Canonical defines them: against the kernel the machine is running (its type, such as generic or aws, and its version), so they show under that kernel's package, for example linux-image-6.8.0-111-generic. Canonical lists thousands of kernel CVEs, many with no fix planned; the first check after upgrading to 1.19 records the fixable ones already there without calling them new. On Windows, the check covers Windows itself, not other software such as Office or PHP.

A machine that joined moments ago gets Gardience's agent functions during the check and is checked in the same run.

Other systems (for example SUSE) are listed as not checked for now.

Related#

• Patching
• STIG compliance
• Reports, evidence and audit