Patch compliance state values - AWS Systems Manager
Patch compliance values for Debian Server, Raspberry Pi OS, and Ubuntu ServerPatch compliance values for other operating systems

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-security (Ubuntu Server 20.10 STR), jammy-security (Ubuntu Server 22.04 LTS), 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

INSTALLED_PENDING_REBOOT can mean either of two things:

  • The Patch Manager Install operation applied the patch to the managed node, but the node has not been rebooted since the patch was applied. 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.

  • A patch was installed outside of Patch Manager since the last time the managed node was rebooted.

 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. There are two possible reasons for this:

  1. The patch might have been installed manually.

  2. Linux only: The package might have been installed as a required dependency of a different, approved patch. If you specify Allow as dependency as the Rejected patches action, patches that are installed as dependencies are given the reporting status INSTALLED_OTHER.

    Note

    Windows Server doesn't support the concept of patch dependencies. For information about how Patch Manager handles patches in the Rejected patches list on Windows Server, see Rejected patch list options in custom patch baselines.

 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

INSTALLED_PENDING_REBOOT can mean either of two things:

  • The Patch Manager Install operation applied the patch to the managed node, but the node has not been rebooted since the patch was applied. 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.

  • A patch was installed outside of Patch Manager since the last time the managed node was rebooted.

 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

¹ For patches with the state INSTALLED_OTHER and NOT_APPLICABLE, Patch Manager omits some data from query results based on the describe-instance-patches command, such as the values for Classification and Severity. This is done to help prevent exceeding the data limit for individual nodes in Inventory, a capability of AWS Systems Manager. To view all patch details, you can use the describe-available-patches command.