How patch baseline rules work on Linux-based systems - Amazon Systems Manager
How patch baseline rules work on Amazon Linux 1, Amazon Linux 2, and Amazon Linux 2023How patch baseline rules work on CentOS and CentOS StreamHow patch baseline rules work on Debian Server and Raspberry Pi OSHow patch baseline rules work on macOSHow patch baseline rules work on Oracle LinuxHow patch baseline rules work on AlmaLinux, RHEL, and Rocky LinuxHow patch baseline rules work on SUSE Linux Enterprise ServerHow patch baseline rules work on Ubuntu Server
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

How patch baseline rules work on Linux-based systems

The rules in a patch baseline for Linux distributions operate differently based on the distribution type. Unlike patch updates on Windows Server managed nodes, rules are evaluated on each node to take the configured repos on the instance into consideration. Patch Manager, a capability of Amazon Systems Manager, uses the native package manager to drive the installation of patches approved by the patch baseline.

For Linux-based operating system types that report a severity level for patches, Patch Manager uses the severity level reported by the software publisher for the update notice or individual patch. Patch Manager doesn't derive severity levels from third-party sources, such as the Common Vulnerability Scoring System (CVSS), or from metrics released by the National Vulnerability Database (NVD).

How patch baseline rules work on Amazon Linux 1, Amazon Linux 2, and Amazon Linux 2023

On Amazon Linux 1, Amazon Linux 2, and Amazon Linux 2023, the patch selection process is as follows:

  1. On the managed node, the YUM library (Amazon Linux 1 and, Amazon Linux 2) or the DNF library ( and Amazon Linux 2023) accesses the updateinfo.xml file for each configured repo.

    Note

    If no updateinfo.xml file is found, whether patches are installed depend on settings for Include non-security updates and Auto-approval. For example, if non-security updates are permitted, they're installed when the auto-approval time arrives.

  2. Each update notice in updateinfo.xml includes several attributes that denote the properties of the packages in the notice, as described in the following table.

    Update notice attributes
    Attribute Description
    type

    Corresponds to the value of the Classification key attribute in the patch baseline's PatchFilter data type. Denotes the type of package included in the update notice.

    You can view the list of supported values by using the Amazon CLI command describe-patch-properties or the API operation DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.
    severity

    Corresponds to the value of the Severity key attribute in the patch baseline's PatchFilter data type. Denotes the severity of the packages included in the update notice. Usually only applicable for Security update notices.

    You can view the list of supported values by using the Amazon CLI command describe-patch-properties or the API operation DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.
    update_id

    Denotes the advisory ID, such as ALAS-2017-867. The advisory ID can be used in the ApprovedPatches or RejectedPatches attribute in the patch baseline.
    references

    Contains additional information about the update notice, such as a CVE ID (format: CVE-2017-1234567). The CVE ID can be used in the ApprovedPatches or RejectedPatches attribute in the patch baseline.
    updated

    Corresponds to ApproveAfterDays in the patch baseline. Denotes the released date (updated date) of the packages included in the update notice. A comparison between the current timestamp and the value of this attribute plus the ApproveAfterDays is used to determine if the patch is approved for deployment.

    Note

    For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

  3. The product of the managed node is determined by SSM Agent. This attribute corresponds to the value of the Product key attribute in the patch baseline's PatchFilter data type.

  4. Packages are selected for the update according to the following guidelines.

    Security option Patch selection

    Pre-defined default patch baselines provided by Amazon and custom patch baselines where the Include non-security updates is not selected

    For each update notice in updateinfo.xml, the patch baseline is used as a filter, allowing only the qualified packages to be included in the update. If multiple packages are applicable after applying the patch baseline definition, the latest version is used.

    For Amazon Linux 1 and Amazon Linux 2, the equivalent yum command for this workflow is:

    sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y

    For and Amazon Linux 2023, the equivalent dnf command for this workflow is:

    sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y

    Custom patch baselines where the Include non-security updates check box is selected with a SEVERITY list of [Critical, Important] and a CLASSIFICATION list of [Security, Bugfix]

    In addition to applying the security updates that were selected from updateinfo.xml, Patch Manager applies nonsecurity updates that otherwise meet the patch filtering rules.

    For Amazon Linux and Amazon Linux 2, the equivalent yum command for this workflow is:

    sudo yum update-minimal --security --sec-severity=Critical,Important --bugfix -y

    For and Amazon Linux 2023, the equivalent dnf command for this workflow is:

    sudo dnf upgrade-minimal --security --sec-severity=Critical --sec-severity=Imporant --bugfix -y

For information about patch compliance status values, see Understanding patch compliance state values.

How patch baseline rules work on CentOS and CentOS Stream

The CentOS and CentOS Stream default repositories do not include an updateinfo.xml file. However, custom repositories that you create or use might include this file. In this topic, references to updateinfo.xml apply only to these custom repositories.

On CentOS and CentOS Stream, the patch selection process is as follows:

  1. On the managed node, the YUM library (on CentOS 6.x and 7.x versions) or the DNF library (on CentOS 8.x and CentOS Stream) accesses the updateinfo.xml file, if it exists in a custom repository, for each configured repo.

    If there is no updateinfo.xml found, which always includes the default repos, whether patches are installed depends on settings for Include non-security updates and Auto-approval. For example, if non-security updates are permitted, they're installed when the auto-approval time arrives.

  2. If updateinfo.xml is present, each update notice in the file includes several attributes that denote the properties of the packages in the notice, as described in the following table.

    Update notice attributes
    Attribute Description
    type

    Corresponds to the value of the Classification key attribute in the patch baseline's PatchFilter data type. Denotes the type of package included in the update notice.

    You can view the list of supported values by using the Amazon CLI command describe-patch-properties or the API operation DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.
    severity

    Corresponds to the value of the Severity key attribute in the patch baseline's PatchFilter data type. Denotes the severity of the packages included in the update notice. Usually only applicable for Security update notices.

    You can view the list of supported values by using the Amazon CLI command describe-patch-properties or the API operation DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.
    update_id

    Denotes the advisory ID, such as CVE-2019-17055. The advisory ID can be used in the ApprovedPatches or RejectedPatches attribute in the patch baseline.
    references

    Contains additional information about the update notice, such as a CVE ID (format: CVE-2019-17055) or a Bugzilla ID (format: 1463241). The CVE ID and Bugzilla ID can be used in the ApprovedPatches or RejectedPatches attribute in the patch baseline.
    updated

    Corresponds to ApproveAfterDays in the patch baseline. Denotes the released date (updated date) of the packages included in the update notice. A comparison between the current timestamp and the value of this attribute plus the ApproveAfterDays is used to determine if the patch is approved for deployment.
    Note

    For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

  3. In all cases, the product of the managed node is determined by SSM Agent. This attribute corresponds to the value of the Product key attribute in the patch baseline's PatchFilter data type.

  4. Packages are selected for the update according to the following guidelines.

    Security option Patch selection

    Pre-defined default patch baselines provided by Amazon and custom patch baselines where the Include non-security updates is not selected

    For each update notice in updateinfo.xml, if it exists in a custom repository, the patch baseline is used as a filter, allowing only the qualified packages to be included in the update. If multiple packages are applicable after applying the patch baseline definition, the latest version is used.

    For CentOS 6 and 7 where updateinfo.xml is present, the equivalent yum command for this workflow is:

    sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y

    For CentOS 8 and CentOS Stream where updateinfo.xml is present, the equivalent dnf command for this workflow is:

    sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y

    Custom patch baselines where the Include non-security updates check box is selected with a SEVERITY list of [Critical, Important] and a CLASSIFICATION list of [Security, Bugfix]

    In addition to applying the security updates that were selected from updateinfo.xml, if it exists in a custom repository, Patch Manager applies nonsecurity updates that otherwise meet the patch filtering rules.

    For CentOS 6 and 7 where updateinfo.xml is present, the equivalent yum command for this workflow is:

    sudo yum update --sec-severity=Critical,Important --bugfix -y

    For CentOS 8 and CentOS Stream where updateinfo.xml is present, the equivalent dnf command for this workflow is:

    sudo dnf upgrade --security --sec-severity=Critical --sec-severity=Important --bugfix -y

    For default repos and custom repos without updateinfo.xml, you must select the Include non-security updates check box in order to update operating system (OS) packages.

For information about patch compliance status values, see Understanding patch compliance state values.

How patch baseline rules work on Debian Server and Raspberry Pi OS

On Debian Server and Raspberry Pi OS (formerly Raspbian), the patch baseline service offers filtering on the Priority and Section fields. These fields are typically present for all Debian Server and Raspberry Pi OS packages. To determine whether a patch is selected by the patch baseline, Patch Manager does the following:

  1. On Debian Server and Raspberry Pi OS systems, the equivalent of sudo apt-get update is run to refresh the list of available packages. Repos aren't configured and the data is pulled from repos configured in a sources list.

  2. If an update is available for python3-apt (a Python library interface to libapt), it is upgraded to the latest version. (This nonsecurity package is upgraded even if you did not select the Include nonsecurity updates option.)

    Important

    On Debian Server 8 only: Because Debian Server 8.* operating systems refer to an obsolete package repository (jessie-backports), Patch Manager performs the following additional steps to ensure that patching operations succeed:

    1. On your managed node, the reference to the jessie-backports repository is commented out from the source location list (/etc/apt/sources.list.d/jessie-backports). As a result, no attempt is made to download patches from that location.

    2. A Stretch security update signing key is imported. This key provides the necessary permissions for the update and install operations on Debian Server 8.* distributions.

    3. The apt-get operation is run at this point to ensure that the latest version of python3-apt is installed before the patching process begins.

    4. After the installation process is complete, the reference to the jessie-backports repository is restored and the signing key is removed from the apt sources keyring. This is done to leave the system configuration as it was before the patching operation.

  3. Next, the GlobalFilters, ApprovalRules, ApprovedPatches and RejectedPatches lists are applied.

    Note

    Because it isn't possible to reliably determine the release dates of update packages for Debian Server, the auto-approval options aren't supported for this operating system.

    Approval rules, however, are also subject to whether the Include nonsecurity updates check box was selected when creating or last updating a patch baseline.

    If nonsecurity updates are excluded, an implicit rule is applied in order to select only packages with upgrades in security repos. For each package, the candidate version of the package (which is typically the latest version) must be part of a security repo. In this case, for Debian Server, patch candidate versions are limited to patches included in the following repos:

    These repos are named as follows:

    • Debian Server 8: debian-security jessie

    • Debian Server and Raspberry Pi OS 9: debian-security stretch

    • Debian Server 10: debian-security buster

    • Debian Server 11: debian-security bullseye

    • Debian Server 12: debian-security bookworm

    If nonsecurity updates are included, patches from other repositories are considered as well.

    Note

    For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

To view the contents of the Priority and Section fields, run the following aptitude command:

Note

You might need to first install Aptitude on Debian Server systems.

aptitude search -F '%p %P %s %t %V#' '~U'

In the response to this command, all upgradable packages are reported in this format: 

name, priority, section, archive, candidate version

For information about patch compliance status values, see Understanding patch compliance state values.

How patch baseline rules work on macOS

On macOS, the patch selection process is as follows:

  1. On the managed node, Patch Manager accesses the parsed contents of the InstallHistory.plist file and identifies package names and versions.

    For details about the parsing process, see the macOS tab in How patches are installed.

  2. The product of the managed node is determined by SSM Agent. This attribute corresponds to the value of the Product key attribute in the patch baseline's PatchFilter data type.

  3. Packages are selected for the update according to the following guidelines.

    Security option Patch selection

    Pre-defined default patch baselines provided by Amazon and custom patch baselines where the Include non-security updates is not selected

    For each available package update, the patch baseline is used as a filter, allowing only the qualified packages to be included in the update. If multiple packages are applicable after applying the patch baseline definition, the latest version is used.

    Custom patch baselines where the Include non-security updates is selected

    In addition to applying the security updates that were identified by using InstallHistory.plist , Patch Manager applies nonsecurity updates that otherwise meet the patch filtering rules.

For information about patch compliance status values, see Understanding patch compliance state values.

How patch baseline rules work on Oracle Linux

On Oracle Linux, the patch selection process is as follows:

  1. On the managed node, the YUM library accesses the updateinfo.xml file for each configured repo.

    Note

    The updateinfo.xml file might not be available if the repo isn't one managed by Oracle. If there is no updateinfo.xml found, whether patches are installed depend on settings for Include non-security updates and Auto-approval. For example, if non-security updates are permitted, they're installed when the auto-approval time arrives.

  2. Each update notice in updateinfo.xml includes several attributes that denote the properties of the packages in the notice, as described in the following table.

    Update notice attributes
    Attribute Description
    type

    Corresponds to the value of the Classification key attribute in the patch baseline's PatchFilter data type. Denotes the type of package included in the update notice.

    You can view the list of supported values by using the Amazon CLI command describe-patch-properties or the API operation DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.
    severity

    Corresponds to the value of the Severity key attribute in the patch baseline's PatchFilter data type. Denotes the severity of the packages included in the update notice. Usually only applicable for Security update notices.

    You can view the list of supported values by using the Amazon CLI command describe-patch-properties or the API operation DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.
    update_id

    Denotes the advisory ID, such as CVE-2019-17055. The advisory ID can be used in the ApprovedPatches or RejectedPatches attribute in the patch baseline.
    references

    Contains additional information about the update notice, such as a CVE ID (format: CVE-2019-17055) or a Bugzilla ID (format: 1463241). The CVE ID and Bugzilla ID can be used in the ApprovedPatches or RejectedPatches attribute in the patch baseline.
    updated

    Corresponds to ApproveAfterDays in the patch baseline. Denotes the released date (updated date) of the packages included in the update notice. A comparison between the current timestamp and the value of this attribute plus the ApproveAfterDays is used to determine if the patch is approved for deployment.
    Note

    For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

  3. The product of the managed node is determined by SSM Agent. This attribute corresponds to the value of the Product key attribute in the patch baseline's PatchFilter data type.

  4. Packages are selected for the update according to the following guidelines.

    Security option Patch selection

    Pre-defined default patch baselines provided by Amazon and custom patch baselines where the Include non-security updates is not selected

    For each update notice in updateinfo.xml, the patch baseline is used as a filter, allowing only the qualified packages to be included in the update. If multiple packages are applicable after applying the patch baseline definition, the latest version is used.

    For version 7 managed nodes, the equivalent yum command for this workflow is:

    sudo yum update-minimal --sec-severity=Important,Moderate --bugfix -y

    For version 8 and 9 managed nodes, the equivalent dnf command for this workflow is:

    sudo dnf upgrade-minimal --security --sec-severity=Moderate --sec-severity=Important

    Custom patch baselines where the Include non-security updates is selected with a SEVERITY list of [Critical, Important] and a CLASSIFICATION list of [Security, Bugfix]

    In addition to applying the security updates that were selected from updateinfo.xml, Patch Manager applies nonsecurity updates that otherwise meet the patch filtering rules.

    For version 7 managed nodes, the equivalent yum command for this workflow is:

    sudo yum update --security --sec-severity=Critical,Important --bugfix -y

    For version 8 and 9 managed nodes, the equivalent dnf command for this workflow is: 

    sudo dnf upgrade --security --sec-severity=Critical, --sec-severity=Important --bugfix y

For information about patch compliance status values, see Understanding patch compliance state values.

How patch baseline rules work on AlmaLinux, RHEL, and Rocky Linux

On AlmaLinux, Red Hat Enterprise Linux (RHEL), and Rocky Linux, the patch selection process is as follows:

  1. On the managed node, the YUM library (RHEL 7) or the DNF library (AlmaLinux 8 and 9, RHEL 8 and 9, and Rocky Linux 8 and 9) accesses the updateinfo.xml file for each configured repo.

    Note

    The updateinfo.xml file might not be available if the repo isn't one managed by Red Hat. If there is no updateinfo.xml found, no patch will be applied.

  2. Each update notice in updateinfo.xml includes several attributes that denote the properties of the packages in the notice, as described in the following table.

    Update notice attributes
    Attribute Description
    type

    Corresponds to the value of the Classification key attribute in the patch baseline's PatchFilter data type. Denotes the type of package included in the update notice.

    You can view the list of supported values by using the Amazon CLI command describe-patch-properties or the API operation DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.
    severity

    Corresponds to the value of the Severity key attribute in the patch baseline's PatchFilter data type. Denotes the severity of the packages included in the update notice. Usually only applicable for Security update notices.

    You can view the list of supported values by using the Amazon CLI command describe-patch-properties or the API operation DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.
    update_id

    Denotes the advisory ID, such as RHSA-2017:0864. The advisory ID can be used in the ApprovedPatches or RejectedPatches attribute in the patch baseline.
    references

    Contains additional information about the update notice, such as a CVE ID (format: CVE-2017-1000371) or a Bugzilla ID (format: 1463241). The CVE ID and Bugzilla ID can be used in the ApprovedPatches or RejectedPatches attribute in the patch baseline.
    updated

    Corresponds to ApproveAfterDays in the patch baseline. Denotes the released date (updated date) of the packages included in the update notice. A comparison between the current timestamp and the value of this attribute plus the ApproveAfterDays is used to determine if the patch is approved for deployment.
    Note

    For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

  3. The product of the managed node is determined by SSM Agent. This attribute corresponds to the value of the Product key attribute in the patch baseline's PatchFilter data type.

  4. Packages are selected for the update according to the following guidelines.

    Security option Patch selection

    Pre-defined default patch baselines provided by Amazon and custom patch baselines where the Include non-security updates check box is not selected in any rule

    For each update notice in updateinfo.xml, the patch baseline is used as a filter, allowing only the qualified packages to be included in the update. If multiple packages are applicable after applying the patch baseline definition, the latest version is used.

    For RHEL 7, the equivalent yum command for this workflow is:

    sudo yum update-minimal --sec-severity=Critical,Important --bugfix -y

    For AlmaLinux 8 and 9, RHEL 8 and 9, and Rocky Linux 8 and 9, the equivalent dnf command for this workflow is:

    sudo dnf upgrade-minimal --sec-severity=Critical --sec-severity=Important --bugfix -y

    Custom patch baselines where the Include non-security updates check box is selected with a SEVERITY list of [Critical, Important] and a CLASSIFICATION list of [Security, Bugfix]

    In addition to applying the security updates that were selected from updateinfo.xml, Patch Manager applies nonsecurity updates that otherwise meet the patch filtering rules.

    For RHEL 7, the equivalent yum command for this workflow is:

    sudo yum update --security --sec-severity=Critical,Important --bugfix -y

    For AlmaLinux 8 and 9, RHEL 8 and 9, and Rocky Linux 8 and 9, the equivalent dnf command for this workflow is:

    sudo dnf upgrade --sec-severity=Critical --sec-severity=Important --bugfix -y

For information about patch compliance status values, see Understanding patch compliance state values.

How patch baseline rules work on SUSE Linux Enterprise Server

On SLES, each patch includes the following attributes that denote the properties of the packages in the patch:

  • Category: Corresponds to the value of the Classification key attribute in the patch baseline's PatchFilter data type. Denotes the type of patch included in the update notice.

    You can view the list of supported values by using the Amazon CLI command describe-patch-properties or the API operation DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.

  • Severity: Corresponds to the value of the Severity key attribute in the patch baseline's PatchFilter data type. Denotes the severity of the patches.

    You can view the list of supported values by using the Amazon CLI command describe-patch-properties or the API operation DescribePatchProperties. You can also view the list in the Approval rules area of the Create patch baseline page or Edit patch baseline page in the Systems Manager console.

The product of the managed node is determined by SSM Agent. This attribute corresponds to the value of the Product key attribute in the patch baseline's PatchFilter data type.

For each patch, the patch baseline is used as a filter, allowing only the qualified packages to be included in the update. If multiple packages are applicable after applying the patch baseline definition, the latest version is used.

Note

For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

How patch baseline rules work on Ubuntu Server

On Ubuntu Server, the patch baseline service offers filtering on the Priority and Section fields. These fields are typically present for all Ubuntu Server packages. To determine whether a patch is selected by the patch baseline, Patch Manager does the following:

  1. On Ubuntu Server systems, the equivalent of sudo apt-get update is run to refresh the list of available packages. Repos aren't configured and the data is pulled from repos configured in a sources list.

  2. If an update is available for python3-apt (a Python library interface to libapt), it is upgraded to the latest version. (This nonsecurity package is upgraded even if you did not select the Include nonsecurity updates option.)

  3. Next, the GlobalFilters, ApprovalRules, ApprovedPatches and RejectedPatches lists are applied.

    Note

    Because it's not possible to reliably determine the release dates of update packages for Ubuntu Server, the auto-approval options aren't supported for this operating system.

    Approval rules, however, are also subject to whether the Include nonsecurity updates check box was selected when creating or last updating a patch baseline.

    If nonsecurity updates are excluded, an implicit rule is applied in order to select only packages with upgrades in security repos. For each package, the candidate version of the package (which is typically the latest version) must be part of a security repo. In this case, for Ubuntu Server, patch candidate versions are limited to patches included in the following repos:

    • Ubuntu Server 14.04 LTS: trusty-security

    • Ubuntu Server 16.04 LTS: xenial-security

    • Ubuntu Server 18.04 LTS: bionic-security

    • Ubuntu Server 20.04 LTS: focal-security

    • Ubuntu Server 20.10 STR: groovy-security

    • Ubuntu Server 22.04 LTS (jammy-security)

    • Ubuntu Server 23.04 (lunar-security)

    If nonsecurity updates are included, patches from other repositories are considered as well.

    Note

    For information about accepted formats for lists of approved patches and rejected patches, see About package name formats for approved and rejected patch lists.

To view the contents of the Priority and Section fields, run the following aptitude command:

Note

You might need to first install Aptitude on Ubuntu Server 16 systems.

aptitude search -F '%p %P %s %t %V#' '~U'

In the response to this command, all upgradable packages are reported in this format: 

name, priority, section, archive, candidate version

For information about patch compliance status values, see Understanding patch compliance state values.