Vulnerabilty Reporting Mechanics

Vulnerability Reporting Mechanics is directly linked to Patch Reporting component. 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

Compliance do not scan devices directly for vulnerabilities. The vulnerability of a device is derived from its patch applicability status.

Table 1. patch applicability status
Security patch applied Vulnerabilty Status of the device
Yes Remediated
No Not remediated

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

Supersedence chain

Supersedence is a recent patch that the vendor releases replacing the previous patches. Following is an example model:

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 the security fixes that were included previously. Applying Patch C fixes both the vulnerabilities and resolves the security vulnerabilities of the device

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 flag provides the option in a patch to override its default property where the content in the Patches for Windows site has a relevance that disables evaluation on the superseded patches.

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, to determine the vulnerability status, Compliance do not distinguish whether this superseded patch has been previously applied and unable to utilize the "Supersedence chain".

Compliance operates 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 an incomplete data about the vulnerability posture. As Compliance is installed for a longer duration, it observes details about which patches were previously applied, it becomes better able to infer which vulnerabilities are remediated or not.

Compliance may have incomplete data about the vulnerability posture if it is a fresh installation or Patch enablement or Vulnerability Reporting. As Compliance is installed longer and gathers details about which patches were previously applied, it infers which vulnerabilities are remediated or not.