Docs

Elastic Compute Service

Managing patch baselines

Creating patch baselines

By default, preset patch baselines are provided. You can also create your own custom patch baseline based on your business requirements, to serve as the installation baseline for your patch plans.

A custom patch baseline allows you to precisely control the approval and rejection of patches in your environment, enabling more flexible patch lifecycle management. Additionally, corresponding compliance levels can be assigned to all "Unspecified" patches installed based on the custom baseline.

Concept

Concept	Description
Patch exceptions	A special processing mechanism outside the regular rules of a patch baseline. It grants temporary or long-term exemption or approval for patches that do not meet default baseline requirements but require differentiated control due to business or technical constraints.
Approved patches	Patches allowed for installation, which are applicable to emergency remediation or small-scale calibration. Even if a patch does not match preset rules, you can force-install it by adding it to the approval list.
Rejected patches	Patches blocked from installation, which are applicable to emergency remediation or small-scale calibration. Even if a patch matches preset rules, you can forcibly block it by adding it to the rejection list.
Patch sources	The server address from which the operating system obtains patches and packages. Patch source configuration determines patch acquisition efficiency, version compliance, and system security.

Usage notes

Item	Description
Patch exceptions	In the same patch baseline, if a patch is included in both the approved and rejected patch lists, the rejection rule takes precedence. Patch exception rules have higher priority than the baseline default logic. If an exception is configured, it overrides the default baseline rules.
Patch baseline	Only one default patch baseline can be set for each operating system type. Setting a new default baseline will replace the current one (including any preset system baseline).
Severity level	The severity level of the patch is based only on the rating officially provided by the system software vendor. CVSS, NVD, and other third-party platform vulnerability or patch severity scores are not used.

Procedure

In the left-side navigation pane, select "Maintenance & Monitoring > Patch Management".

In the top menu bar, select the region where your business is located.

On the Patch management page, click the "Patch baseline" tab.

Click the "Create patch baseline" button. Configure the parameters described in the following table.

Basic information

Parameter	Description	Sample value
Baseline name	Enter the name of the patch baseline.	Debian security patch baseline V1.0
Operating system	Select the operating system type to which this patch baseline applies. Supported: "Ubuntu" and "Debian".	Debian
Set as default	Select whether to set this patch baseline as the default patch baseline. Not selected If you do not select "Set this patch baseline as default baseline", the baseline will not become the global default benchmark for the corresponding OS type. It will only be used as a custom benchmark for target patch plans to perform patch tasks. tip If you do not select "Set this patch baseline as default baseline", after this patch baseline is created, you can manually set it as the default patch baseline. Selected If you select "Set this patch baseline as default baseline", the baseline will become the global default benchmark for the corresponding OS type. And target patch plans will have patch tasks executed based on this baseline.	Selected

OS installation rule

OS installation rules are full-process control standards for patch deployment developed for certain OS types. You can use this feature to specify patch targets (such as target products), execution order (such as priority), exemptions (such as non-security patches), and other configurations to ensure compliance and business continuity.

One installation rule item is displayed by default. You can click "Add rule" to create more rules (up to 10 rules).

Parameter	Description	Sample value
Product	Select the corresponding version of the target operating system. You can select one or multiple versions, or select "All" to meet patch installation requirements for different versions of the operating system. Learn more. tip When "All" is selected, newly added product versions that meet the criteria will automatically be matched to this patch baseline.	Debian
Component	Select one or more components of the target operating system, or select "All", to meet the patch installation requirements for different OS components. tip When "All" is selected, any newly added product components that meet the criteria will automatically be matched to this patch baseline. Only native Ubuntu/Debian components are supported.	Select all
Priority	The priority of the patch installation rule, which determines the order in which multiple candidate rules take effect. Installation logic is based on the descending priority order. Priority order: Required > Important > Standard > Optional > Extra Required Applies to core packages that the system must install. If the packages are missing, the system cannot start or operate normally. Important Applies to key packages required for normal system operation. If the packages are missing, system functions will be severely impaired and basic usage requirements cannot be met. Standard Applies to packages for the system standard configuration, forming the default environment for Debian or Ubuntu installations. Missing these packages does not affect system startup, but impacts daily usage. Optional Applies to optional packages not required by the system, which can be used to extend system functions (not installed by default). Extra Applies to optional packages that conflict with or have special dependencies on other packages, or packages with duplicate functions.	Required
Compliance severity level	Based on the risk impact and the degree of compliance clause violation when patches preset in the installation rule are not installed, classify the compliance status level to clarify remediation priority and compliance risk. The higher the level, the greater the risk of the resource deviating from the patch baseline and installation rules, and the more urgent the need for remediation. Compliance severity level order: Critical > High > Medium > Low > Informational > Unspecified Critical The highest compliance risk level, applicable to scenarios where uninstalled patches may lead to system intrusion, data leakage, full business interruption, and expose the enterprise to compliance penalties. High High-priority level, applicable to scenarios where uninstalled patches may be exploited by attackers to cause security incidents, lead to core function exceptions, and directly affect compliance check results. Medium Regular remediation priority level, applicable to scenarios where uninstalled patches have a low probability of being exploited, affect only non-core functions, and have a minor impact on compliance check results. Low Deferred remediation priority level, applicable to scenarios where uninstalled patches have an extremely low probability of exploitation, affect only edge functions, and do not cause compliance violations. Informational Non-risk supplementary annotation level. This applies to assets with no patch compliance issues or security risks, and only additional details about patches or special asset status need to be noted. Unspecified Temporary level for pending classification, applicable to scenarios where asset patch compliance status cannot be accurately classified due to insufficient information, scan failures, or uncovered rules.	High
Include non-security updates	By default, only security-type patches are installed based on preset installation rules. To install non-security patches to fix compatibility issues, system feature defects, and other issues, check the "Install non-security patches that comply with the approval rules" option as needed.	Retain the default value

Patch exceptions (optional)

Approved or rejected patches are only applicable to scenarios where baseline automatic rules (approval rules) cannot cover certain patches, or where default rules conflict with business requirements. If automatic rules support precise control over the target patches, you do not need to add them to the approval or rejection lists.

Parameter	Description
Approved patches	Enter the list of patch program names or numbers of patches to be explicitly approved. Separate multiple patches with commas (,). tip The configuration format of approved patches in the patch baseline varies by operating system type you are patching. Learn more. Patches you add to the approval list will be deployed based on the priority of the installation rule, regardless of whether they meet the configured filtering rules. If they are not installed, the corresponding level of compliance risk will be triggered.
Compliance severity level	To clarify remediation priority and compliance risk, classify the compliance status level of approved but not installed patches based on the risk impact and degree of compliance clause violation of the patches. For details on compliance severity levels, refer to the relevant definitions in the "OS installation rule" section.
Include non-security updates	By default, only security-type ones in the approved patches are installed. To install non-security patches to improve compatibility, fix system feature defects and resolve other issues, check the "Install non-security patches that comply with the approval rules" option as needed.
Rejected patches	Enter the list of patch program names or numbers of patches to be explicitly rejected. Separate multiple patches with commas (,). tip The configuration format of rejected patches in the patch baseline varies by operating system type you are patching. Learn more. The specified patch program will be installed only when it meets the dependency condition and the "Action for rejected patches" parameter is set to "Allow dependency". Otherwise, the patch program will not be installed.
Action for rejected patches	If parameter "Rejected patches" is configured, select the corresponding action for the rejected patches. Allow dependency (default) A package in the "Rejected patches" list will be installed only if the package is a dependency of another package, and its status will be "Installed (does not meet the baseline)" Block In any circumstance, the system does not install packages included in the "Rejected patches" list or packages that contain those packages as dependencies. If a package was installed before it was added to the "Rejected patches", its status will be "Installed (rejected patch)".

Patch sources (optional)

For ECS instances deployed with a Volcano Engine official image, the Volcano Engine default patch source (mirror site) is used by default. There is no need to configure the patch source.

For ECS instances deployed with a non-Volcano Engine official image, you can manually configure a third-party mirror site for the official software packages of the corresponding operating system by clicking the "Add patch source" button.

tip

You can add up to 20 patch sources.

Parameter	Description	Sample value
Source name	Enter the name of the patch source.	Debian patch source
Product	Select one version or multiple versions of the operating system. This allows you to meet patch installation requirements for different versions of the operating system. Learn more.	Select all
Configuration	Enter the configuration information of the patch source. The information is used in the source configuration file to specify the address for obtaining patches/software packages. Ubuntu configuration format: deb http://security.ubuntu.com/ubuntu jammy main deb: Required field. This source provides binary packages (patches or programs that can be installed directly). http://security.ubuntu.com/ubuntu: Official security patch source address, used to obtain patches to fix system vulnerabilities. jammy: Codename for Ubuntu 22.04, which must strictly match the system version. main: Enables only fully open-source and officially supported core components with maximum security. Debian configuration format: deb https://site.example.com/debian distribution deb: Required field. This source provides binary packages (patches or programs that can be installed directly). https://site.example.com/debian: Official security patch source address, used to obtain patches to fix system vulnerabilities. distribution: System distribution version code name/alias (for example, focal for Ubuntu 20.04, bullseye for Debian 11), which must strictly match the instance system version. component: Software component category of the source. Patch management mainly uses main (official core packages/patches). tip The patch source must strictly correspond to the operating system distribution and version number. For example, Ubuntu 22.04 (Jammy) must use the jammy version source, and Debian 12 (Bookworm) must use the bookworm version source. Cross-version configuration may cause patch installation failures or dependency conflicts.	-

Click "Confirm" to complete the procedure.

Subsequent steps

After configuration, you can create a patch scan plan based on this patch baseline, or scan for patches and install patches based on the plan. Learn more.

Last updated: 2026.06.18 17:48:27