Understanding patch compliance state values - AWS Systems Manager

Understanding patch compliance state values

The information about patches for a managed node include a report of the state, or status, of each individual patch.

Note

If you want to assign a specific patch compliance state to a managed node, you can use the put-compliance-items AWS Command Line Interface (AWS CLI) command or the PutComplianceItems API operation. Assigning compliance state isn't supported in the console.

Use the information in the following tables to help you identify why a managed node might be out of patch compliance.

Patch compliance values for Debian Server, Raspberry Pi OS, and Ubuntu Server

For Debian Server, Raspberry Pi OS, and Ubuntu Server, the rules for package classification into the different compliance states are described in the following table.

Note

Keep the following in mind when you're evaluating the Installed, Installed Other, and Missing status values: If you don't select the Include nonsecurity updates check box when creating or updating a patch baseline, patch candidate versions are limited to patches included in trusty-security (Ubuntu Server 14.04 LTS), xenial-security (Ubuntu Server 16.04 LTS), bionic-security (Ubuntu Server 18.04 LTS), focal-security (Ubuntu Server 20.04 LTS), groovy-gorilla (Ubuntu Server 20.10 STR), or debian-security (Debian Server and Raspberry Pi OS). If you do select the Include nonsecurity updates check box, patches from other repositories are considered as well.

Patch state Description Compliance status
Installed

The patch is listed in the patch baseline and is installed on the managed node. It could have been installed either manually by an individual or automatically by Patch Manager when the AWS-RunPatchBaseline document was run on the managed node.

Compliant
Installed Other

The patch isn't included in the baseline or isn't approved by the baseline but is installed on the managed node. The patch might have been installed manually, the package could be a required dependency of another approved patch, or the patch might have been included in an InstallOverrideList operation. If you don't specify Block as the Rejected patches action, Installed_Other patches also includes installed but rejected patches.

Compliant
Installed Pending Reboot

The Patch Manager Install operation applied the patch to the managed node, but the node has not been rebooted since the patch was applied. (Note that patches installed outside of Patch Manager are never given a status of INSTALLED_PENDING_REBOOT.) This typically means the NoReboot option was selected for the RebootOption parameter when the AWS-RunPatchBaseline document was last run on the managed node. For more information, see Parameter name: RebootOption.

Non-Compliant
Installed Rejected

The patch is installed on the managed node but is specified in a Rejected patches list. This typically means the patch was installed before it was added to a list of rejected patches.

Non-Compliant
Missing

Packages that are filtered through the baseline and not already installed.

Non-Compliant
Failed

Packages that failed to install during the patch operation.

Non-Compliant

Patch compliance values for other operating systems

For all operating systems besides Debian Server, Raspberry Pi OS, and Ubuntu Server, the rules for package classification into the different compliance states are described in the following table.

Patch state Description Compliance value
INSTALLED

The patch is listed in the patch baseline and is installed on the managed node. It could have been installed either manually by an individual or automatically by Patch Manager when the AWS-RunPatchBaseline document was run on the node.

Compliant
INSTALLED_OTHER

The patch isn't in the baseline, but it is installed on the managed node. The patch might have been installed manually, or the package could be a required dependency of another approved patch. If you don't specify Block as the Rejected patches action, Installed_Other patches also includes installed but rejected patches.

Compliant
INSTALLED_REJECTED

The patch is installed on the managed node but is specified in a rejected patches list. This typically means the patch was installed before it was added to a list of rejected patches.

Non-Compliant
INSTALLED_PENDING_REBOOT

The Patch Manager Install operation applied the patch to the managed node (or a patch was applied to a Windows Server managed node outside of Patch Manager), but the node hasn't been rebooted since the patch was applied. (Note that patches installed outside of Patch Manager are never given a status of INSTALLED_PENDING_REBOOT.) This typically means the NoReboot option was selected for the RebootOption parameter when the AWS-RunPatchBaseline document was last run on the managed node. For more information, see Parameter name: RebootOption.

Non-Compliant
MISSING

The patch is approved in the baseline, but it isn't installed on the managed node. If you configure the AWS-RunPatchBaseline document task to scan (instead of install), the system reports this status for patches that were located during the scan but haven't been installed.

Non-Compliant
NOT_APPLICABLE

The patch is approved in the baseline, but the service or feature that uses the patch isn't installed on the managed node. For example, a patch for a web server service such as Internet Information Services (IIS) would show NOT_APPLICABLE if it was approved in the baseline, but the web service isn't installed on the managed node. A patch can also be marked NOT_APPLICABLE if it has been superseded by a subsequent update. This means that the later update is installed and the NOT_APPLICABLE update is no longer required.

Note

This compliance state is only reported on Windows Server operating systems.

Not applicable
FAILED

The patch is approved in the baseline, but it couldn't be installed. To troubleshoot this situation, review the command output for information that might help you understand the problem.

Non-Compliant