Vulnerability Reporting Mechanics up to 2.0.10

This section describes mechanics in version ealier than 2.0.10.

The vulnerability data for Compliance is extracted from the following sources:

  • The vulnerability CVEs listed in the patch Fixlet metadata (CVENames, MIME_x-fixlet-cve).
  • The supersedence information in the patch Fixlet metadata (MIME_x-fixlet-superseded-id).
  • Vulnerability details from the external NVD feeds.
  • The patch Fixlet evaluation result.

Compliance does not conduct direct scans on devices directly for vulnerabilities. Instead, the vulnerability status of a device is determined based on its patch applicability.

Table 1. Patch applicability status
Fixlet Status Patch Application Status Vulnerability Status
Not Relevant Applied Remediated
Relevant Not Applied Not Remediated

The following sections explains how the Vulnerability Reporting mechanism works and how it affects reporting.

Supersedence chain

Vendors may release patches that include fixes found in previous patches (now obsolete). This process is knows as supersedence, the old obsolete patch is now regarded, and flagged as "superseded".

In the above image:

Patch A is superseded by Patch B and then Patch B is superseded by the current Patch C.

Patch C is the superseding patch that replaces the previous two patches and contains all of their security fixes. If Patch C is applied, it is no longer necessary to apply Patch A or Patch B.

However, if Compliance checks the metadata for Patch C, it cannot determine that it also resolved the vulnerabilities described in A and B. Therefore, Compliance creates a Supersedence chain during the import process and gathers information about an endpoint's vulnerability status. Using the Supersedence chain, Compliance associates implicitly resolved vulnerabilities with their respective patches. Thus, when Patch C is applied, all the vulnerabilities in A, B, and C patches are accurately marked as Remediated.

Patches for Windows and EnableSupersededEval

The EnableSupersededEval is a client setting used by the Patches for Windows site. By default, it is disabled, which prevents superseded patches in the site from being evaluated.

The default behavior of patch applicability evaluation (with the flag turned off) is typically desirable. When a newer patch is available, the superseded patch should no longer be applied. However, when determining the vulnerability status, Compliance cannot distinguish between an applied superseded patch Fixlet and a superseded Fixlet with evaluation disabled.

Compliance handles the above described situation in the following ways:
  • If a patch is detected for the first time and is superseded. Compliance cannot determine the patch status and may display the resolution as Never Relevant indicating a state of ambiguity and that it cannot determine whether or not the patch has been applied to a given endpoint.
  • If a patch that was observed previously becomes superseded. Compliance takes forward the previous evaluation for any endpoints that had evaluated it. For example, a patch that was applied on an endpoint previously still retains a status of remediated.
  • If the endpoint has turned on the EnableSupersededEval flag. Compliance continues to respect the live evaluation status for superseded patches.

In effect, a fresh install or enablement of Patch and Vulnerability Reporting in Compliance has incomplete data about the vulnerability posture. As Compliance is installed for a longer duration, it gathers information on previously applied patches, enhancing its ability to infer the status of vulnerabilities and whether they have been remediated or not.