How security patches are selected - AWS Systems Manager

How security patches are selected

The primary focus of Patch Manager, a capability of AWS Systems Manager, is on installing operating systems security-related updates on managed nodes. By default, Patch Manager doesn't install all available patches, but rather a smaller set of patches focused on security.

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).

Note

On all Linux-based systems supported by Patch Manager, you can choose a different source repository configured for the managed node, typically to install nonsecurity updates. For information, see How to specify an alternative patch source repository (Linux).

Choose from the following tabs to learn how Patch Manager selects security patches for your operating system.

Amazon Linux 1, Amazon Linux 2, Amazon Linux 2022, and Amazon Linux 2023

Preconfigured repositories are handled differently on Amazon Linux 1 and Amazon Linux 2 than on Amazon Linux 2022 and Amazon Linux 2023.

On Amazon Linux 1 and Amazon Linux 2, the Systems Manager patch baseline service uses preconfigured repositories on the managed node. There are usually two preconfigured repositories (repos) on a node:

On Amazon Linux 1

  • Repo ID: amzn-main/latest

    Repo name: amzn-main-Base

  • Repo ID: amzn-updates/latest

    Repo name: amzn-updates-Base

On Amazon Linux 2

  • Repo ID: amzn2-core/2/architecture

    Repo name: Amazon Linux 2 core repository

  • Repo ID: amzn2extra-docker/2/architecture

    Repo name: Amazon Extras repo for docker

Note

architecture can be x86_64 or aarch64.

Amazon Linux 2023 (AL2023) instances initially contains the updates that were available in the version of AL2023 and the chosen AMI. By default, your AL2023 instance doesn't automatically receive additional critical and important security updates at launch. Instead, with the deterministic upgrades through versioned repositories feature in AL2023, which is turned on by default, you can apply updates based on a schedule that meets your specific needs. For more information, see Deterministic upgrades through versioned repositories in the Amazon Linux 2023 User Guide.

On Amazon Linux 2022, the preconfigured repositories are tied to locked versions of package updates. When new Amazon Machine Images (AMIs) for Amazon Linux 2022 are released, they are locked to a specific version. For patch updates, Patch Manager retrieves the latest locked version of the patch update repository and then updates packages on the managed node based on the content of that locked version.

On AL2023, the preconfigured repository is the following:

  • Repo ID: amazonlinux

    Repo name: Amazon Linux 2023 repository

On Amazon Linux 2022 (preview release), the preconfigured repositories are tied to locked versions of package updates. When new Amazon Machine Images (AMIs) for Amazon Linux 2022 are released, they are locked to a specific version. For patch updates, Patch Manager retrieves the latest locked version of the patch update repository and then updates packages on the managed node based on the content of that locked version.

On Amazon Linux 2022, the preconfigured repository is the following:

  • Repo ID: amazonlinux

    Repo name: Amazon Linux 2022 repository

Note

All updates are downloaded from the remote repos configured on the managed node. Therefore, the node must have outbound access to the internet in order to connect to the repos so the patching can be performed.

Amazon Linux 1 and Amazon Linux 2 managed nodes use Yum as the package manager. Amazon Linux 2022 and Amazon Linux 2023 use DNF as the package manager.

Both package managers use the concept of an update notice as a file named updateinfo.xml. An update notice is simply a collection of packages that fix specific problems. All packages that are in an update notice are considered Security by Patch Manager. Individual packages aren't assigned classifications or severity levels. For this reason, Patch Manager assigns the attributes of an update notice to the related packages.

Note

If you select the Include non-security updates check box in the Create patch baseline page, then packages that aren't classified in an updateinfo.xml file (or a package that contains a file without properly formatted Classification, Severity, and Date values) can be included in the prefiltered list of patches. However, in order for a patch to be applied, the patch must still meet the user-specified patch baseline rules.

For more information about the Include non-security updates option, see How patches are installed and How patch baseline rules work on Linux-based systems.

CentOS and CentOS Stream

On CentOS and CentOS Stream, the Systems Manager patch baseline service uses preconfigured repositories (repos) on the managed node. The following list provides examples for a fictitious CentOS 8.2 Amazon Machine Image (AMI):

  • Repo ID: example-centos-8.2-base

    Repo name: Example CentOS-8.2 - Base

  • Repo ID: example-centos-8.2-extras

    Repo name: Example CentOS-8.2 - Extras

  • Repo ID: example-centos-8.2-updates

    Repo name: Example CentOS-8.2 - Updates

  • Repo ID: example-centos-8.x-examplerepo

    Repo name: Example CentOS-8.x – Example Repo Packages

Note

All updates are downloaded from the remote repos configured on the managed node. Therefore, the node must have outbound access to the internet in order to connect to the repos so the patching can be performed.

CentOS 6 and 7 managed nodes use Yum as the package manager. CentOS 8 and CentOS Stream nodes use DNF as the package manager. Both package managers use the concept of an update notice. An update notice is simply a collection of packages that fix specific problems.

However, CentOS and CentOS Stream default repos aren't configured with an update notice. This means that Patch Manager doesn't detect packages on default CentOS and CentOS Stream repos. To allow Patch Manager to process packages that aren't contained in an update notice, you must turn on the EnableNonSecurity flag in the patch baseline rules.

Note

CentOS and CentOS Stream update notices are supported. Repos with update notices can be downloaded after launch.

Debian Server and Raspberry Pi OS

On Debian Server and Raspberry Pi OS (formerly Raspbian), the Systems Manager patch baseline service uses preconfigured repositories (repos) on the instance. These preconfigured repos are used to pull an updated list of available package upgrades. For this, Systems Manager performs the equivalent of a sudo apt-get update command.

Packages are then filtered from debian-security codename repos. This means that on each version of Debian Server, Patch Manager only identifies upgrades that are part of the associated repo for that version, as follows:

  • Debian Server 8: debian-security jessie

  • Debian Server 9: debian-security stretch

  • Debian Server 10: debian-security buster

  • Debian Server 11: debian-security bullseye

  • Debian Server 12: debian-security bookworm

Note

On Debian Server 8 only: Because some Debian Server 8.* managed nodes refer to an obsolete package repository (jessie-backports), Patch Manager performs additional steps to ensure that patching operations succeed. For more information, see How patches are installed.

Oracle Linux

On Oracle Linux, the Systems Manager patch baseline service uses preconfigured repositories (repos) on the managed node. There are usually two preconfigured repos on a node.

Oracle Linux 7:

  • Repo ID: ol7_UEKR5/x86_64

    Repo name: Latest Unbreakable Enterprise Kernel Release 5 for Oracle Linux 7Server (x86_64)

  • Repo ID: ol7_latest/x86_64

    Repo name: Oracle Linux 7Server Latest (x86_64)

Oracle Linux 8:

  • Repo ID: ol8_baseos_latest

    Repo name: Oracle Linux 8 BaseOS Latest (x86_64)

  • Repo ID: ol8_appstream

    Repo name: Oracle Linux 8 Application Stream (x86_64)

  • Repo ID: ol8_UEKR6

    Repo name: Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)

Oracle Linux 9:

  • Repo ID: ol9_baseos_latest

    Repo name: Oracle Linux 9 BaseOS Latest (x86_64)

  • Repo ID: ol9_appstream

    Repo name: Oracle Linux 9 Application Stream Packages(x86_64)

  • Repo ID: ol9_UEKR7

    Repo name: Oracle Linux UEK Release 7 (x86_64)

Note

All updates are downloaded from the remote repos configured on the managed node. Therefore, the node must have outbound access to the internet in order to connect to the repos so the patching can be performed.

Oracle Linux managed nodes use Yum as the package manager, and Yum uses the concept of an update notice as a file named updateinfo.xml. An update notice is simply a collection of packages that fix specific problems. Individual packages aren't assigned classifications or severity levels. For this reason, Patch Manager assigns the attributes of an update notice to the related packages and installs packages based on the Classification filters specified in the patch baseline.

Note

If you select the Include non-security updates check box in the Create patch baseline page, then packages that aren't classified in an updateinfo.xml file (or a package that contains a file without properly formatted Classification, Severity, and Date values) can be included in the prefiltered list of patches. However, in order for a patch to be applied, the patch must still meet the user-specified patch baseline rules.

AlmaLinux, RHEL, and Rocky Linux

On AlmaLinux, Red Hat Enterprise Linux, and Rocky Linux the Systems Manager patch baseline service uses preconfigured repositories (repos) on the managed node. There are usually three preconfigured repos on a node.

All updates are downloaded from the remote repos configured on the managed node. Therefore, the node must have outbound access to the internet in order to connect to the repos so the patching can be performed.

Note

If you select the Include non-security updates check box in the Create patch baseline page, then packages that aren't classified in an updateinfo.xml file (or a package that contains a file without properly formatted Classification, Severity, and Date values) can be included in the prefiltered list of patches. However, in order for a patch to be applied, the patch must still meet the user-specified patch baseline rules.

Red Hat Enterprise Linux 7 managed nodes use Yum as the package manager. AlmaLinux, Red Hat Enterprise Linux 8, and Rocky Linux managed nodes use DNF as the package manager. Both package managers use the concept of an update notice as a file named updateinfo.xml. An update notice is simply a collection of packages that fix specific problems. Individual packages aren't assigned classifications or severity levels. For this reason, Patch Manager assigns the attributes of an update notice to the related packages and installs packages based on the Classification filters specified in the patch baseline.

RHEL 7
Note

The following repo IDs are associated with RHUI 2. RHUI 3 launched in December 2019 and introduced a different naming scheme for Yum repository IDs. Depending on the RHEL-7 AMI you create your managed nodes from, you might need to update your commands. For more information, see Repository IDs for RHEL 7 in AWS Have Changed on the Red Hat Customer Portal.

  • Repo ID: rhui-REGION-client-config-server-7/x86_64

    Repo name: Red Hat Update Infrastructure 2.0 Client Configuration Server 7

  • Repo ID: rhui-REGION-rhel-server-releases/7Server/x86_64

    Repo name: Red Hat Enterprise Linux Server 7 (RPMs)

  • Repo ID: rhui-REGION-rhel-server-rh-common/7Server/x86_64

    Repo name: Red Hat Enterprise Linux Server 7 RH Common (RPMs)

AlmaLinux, 8 RHEL 8, and Rocky Linux 8

  • Repo ID: rhel-8-appstream-rhui-rpms

    Repo name: Red Hat Enterprise Linux 8 for x86_64 - AppStream from RHUI (RPMs)

  • Repo ID: rhel-8-baseos-rhui-rpms

    Repo name: Red Hat Enterprise Linux 8 for x86_64 - BaseOS from RHUI (RPMs)

  • Repo ID: rhui-client-config-server-8

    Repo name: Red Hat Update Infrastructure 3 Client Configuration Server 8

AlmaLinux 9, RHEL 9, and Rocky Linux 9

  • Repo ID: rhel-9-appstream-rhui-rpms

    Repo name: Red Hat Enterprise Linux 9 for x86_64 - AppStream from RHUI (RPMs)

  • Repo ID: rhel-9-baseos-rhui-rpms

    Repo name: Red Hat Enterprise Linux 9 for x86_64 - BaseOS from RHUI (RPMs)

  • Repo ID: rhui-client-config-server-9

    Repo name: Red Hat Enterprise Linux 9 Client Configuration

SLES

On SUSE Linux Enterprise Server (SLES) managed nodes, the ZYPP library gets the list of available patches (a collection of packages) from the following locations:

  • List of repositories: etc/zypp/repos.d/*

  • Package information: /var/cache/zypp/raw/*

SLES managed nodes use Zypper as the package manager, and Zypper uses the concept of a patch. A patch is simply a collection of packages that fix a specific problem. Patch Manager handles all packages referenced in a patch as security-related. Because individual packages aren't given classifications or severity, Patch Manager assigns the packages the attributes of the patch that they belong to.

Ubuntu Server

On Ubuntu Server, the Systems Manager patch baseline service uses preconfigured repositories (repos) on the managed node. These preconfigured repos are used to pull an updated list of available package upgrades. For this, Systems Manager performs the equivalent of a sudo apt-get update command.

Packages are then filtered from codename-security repos, where the codename is unique to the release version, such as trusty for Ubuntu Server 14. Patch Manager only identifies upgrades that are part of these 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)

Windows Server

On Microsoft Windows operating systems, Patch Manager retrieves a list of available updates that Microsoft publishes to Microsoft Update and are automatically available to Windows Server Update Services (WSUS).

Note

Patch Manager only makes available patches for Windows Server operating system versions that are supported for Patch Manager. For example, Patch Manager can't be used to patch Windows RT.

Patch Manager continually monitors for new updates in every AWS Region. The list of available updates is refreshed in each Region at least once per day. When the patch information from Microsoft is processed, Patch Manager removes updates that were replaced by later updates from its patch list . Therefore, only the most recent update is displayed and made available for installation. For example, if KB4012214 replaces KB3135456, only KB4012214 is made available as an update in Patch Manager.

Similarly, Patch Manager can install only patches that are available on the managed node during the time of the patching operation. By default, Windows Server 2019 and Windows Server 2022 remove updates that are replaced by later updates. As a result, if you use the ApproveUntilDate parameter in a Windows Server patch baseline, but the date selected in the ApproveUntilDate parameter is before the date of the latest patch, then the following scenario occurs:

  • The superseded patch is removed from the node and therefore can't be installed using Patch Manager.

  • The latest, replacement patch is present on the node but not yet approved for installation per the ApproveUntilDate parameter's specified date.

This means that the managed node is compliant in terms of Systems Manager operations, even though a critical patch from the previous month might not be installed. This same scenario can occur when using the ApproveAfterDays parameter. Because of the Microsoft superseded patch behavior, it is possible to set a number (generally greater than 30 days) so that patches for Windows Server are never installed if the latest available patch from Microsoft is released before the number of days in ApproveAfterDays has elapsed. Note that this system behavior doesn't apply if you have modified your Windows Group Policy Object (GPO) settings to make the superseded patch available on your managed nodes.

Note

In some cases, Microsoft releases patches for applications that don't specify an updated date and time. In these cases, an updated date and time of 01/01/1970 is supplied by default.