CN115836278A - 基于热补丁和冷补丁的混合的系统合规 - Google Patents

Abstract

使用考虑冷补丁和热补丁的混合的评估来制定合规动作，包括基于软件组件的打补丁状态来识别定义合规条件的策略。确定软件组件的打补丁状态，包括识别适用于软件组件的(多个)冷补丁二进制文件和(多个)热补丁二进制文件的证据，以及使用该证据来确定(多个)热补丁二进制文件是否已被应用于软件组件的实例被加载到其中的存储器映像。基于策略并且基于软件组件的打补丁状态，针对合规条件制定合规动作。合规动作包括生成健康报告或健康证明、发起打补丁动作、发起执行控制动作，等等。

Description

基于热补丁和冷补丁的混合的系统合规

背景技术

计算机软件是复杂的，并且难以编写。因此，在已交付的软件应用中发现漏洞(包括安全漏洞、崩溃和其他不期望的行为)几乎是不可避免的。当发现错误时，开发人员承诺为该错误生成修复程序或“补丁”，并向用户提供这些软件补丁。此外，开发人员可能偶尔会通过软件补丁引入新功能或其他改进。因此，开发人员、管理员和安全专业人员经常通过安装软件补丁来修改现有系统以实现新的或改进的操作。

传统上，软件打补丁是通过“冷补丁”完成的。在冷打补丁的一些的实例中，原始二进制映像(例如，1.0版二进制文件)在磁盘上被包含一个或多个软件补丁的新代码/替换代码修改，从而生成一个冷补丁二进制文件(例如，1.1.版本二进制文件)。在其他实现中，原始二进制映像在磁盘上被冷补丁二进制替换。无论使用磁盘二进制文件修改还是替换，从原始二进制文件操作的任何软件组件都会利用冷补丁处理二进制文件中的新代码/替换代码重新启动。如果这些软件组件包括低级操作系统(OS)组件，例如OS内核，则重新启动软件组件通常需要重新启动OS。无论是否需要重新启动操作系统，软件组件重新启动都会导致系统停机和/或服务中断。

近来，已经开发了通过“热补丁”完成软件打补丁的技术。一些热补丁实例直接通过包括一个或多个补丁的新代码/替换代码修改软件组件的存储器内映像。在这些实例中，热补丁二进制的代码在存储器中应用于已加载的执行二进制文件(例如，先前已从原始二进制文件或冷补丁二进制文件加载的)。因此，这些实现可以在不需要重新启动这些软件组件的情况下将补丁应用于软件组件。其他热补丁实例在加载程序阶段补丁二进制文件，以便新启动的软件组件包括一个或多个热补丁。在这些实现中，当从原始二进制文件或冷补丁二进制文件启动软件组件时，OS加载器使用热补丁二进制文件的代码来“修复”原始二进制文件或者冷补丁二进制文件。

发明内容

当系统同时支持冷打补丁和热打补丁时，这些系统可以以各种打补丁状态存在，包括执行从冷补丁二进制文件和热补丁二进制文件的各种组合加载的软件组件。因此，这些系统可以处于不同的安全性、合规性和操作。本文描述的至少一些实施例涉及基于在计算机系统处可用和/或活动的冷补丁和热补丁的混合来评估和实施系统合规性。例如，实施例可以包括基于一个或多个策略来确定一个或多个软件组件的合规条件，至少基于哪些冷补丁和哪些热补丁被应用于这些软件组件的运行实例来确定这些更多的软件组件的健康状态，以及制定针对合规条件的一个或多个合规动作，例如生成针对这些软件组件的健康报告和/或健康证明、为这些软件组件发起打补丁动作、为这些组件发起执行控制动作等。

实施例涉及用于使用考虑冷补丁和热修混合的评估来制定合规动作的方法、系统和计算机程序产品。这些实施例包括基于软件组件的打补丁状态，来识别定义一个或多个合规条件的一个或多个系统策略，包括识别定义针对特定软件组件的特定合规条件的特定系统策略。这些实施例还包括确定特定软件组件的打补丁状态。确定打补丁状态包括识别多个证据，每个证据对应于多个二进制文件的已被应用于特定软件组件的二进制文件，该多个二进制文件包括(i)可从中加载特定软件组件的一个或多个冷补丁二进制文件，以及(ii)适用于特定软件组件的一个或多个热补丁二进制文件。确定打补丁状态还包括基于多个证据，确定一个或多个热补丁二进制文件的至少一个子集是否已被应用于计算机系统处的系统存储器内的存储器映像，特定软件组件的实例被加载到存储器映像中。这些实施例还包括：基于特定系统策略，并且基于所确定的特定软件组件的打补丁状态，制定针对特定合规条件的合规动作。合规动作包括以下至少一项：基于特定软件组件的打补丁状态，生成健康报告或健康证明中的至少一项；在特定软件组件上发起打补丁动作；或者在特定软件组件上发起执行控制动作。

提供该发明内容部分是为了以简化形式介绍选中的概念，这些概念将在下面的详细描述中进一步描述。该发明内容部分无意标识所要求保护的主题的关键特征或基本特征，也无意限制用作确定所要求保护主题的范围。

附图说明

为了描述可以获得本发明的上述和其他优点和特征的方式，将通过参考附图中所示的本发明的具体实施例来对上面简要描述的本发明进行更具体的描述。理解到这些附图仅描绘了本发明的典型实施例，因此不应被视为限制其范围，将通过使用附图以附加的具体性和细节来描述和解释本发明，其中：

图1A示出了一个示例计算机体系结构，该体系结构有助于基于热补丁和冷补丁的混合来评估和施行系统合规性；

图1B示出了一个示例计算机体系结构，该体系结构有助于基于热补丁和冷补丁的混合来评估和施行系统合规性，其中存储器被划分为(多个)OS存储器区域和(多个)受保护存储器区域；

图1C示出了图1A和图1B中所示的示例审计服务的进一步细节；以及

图2示出了用于使用考虑冷补丁和热补丁的混合的评估来制定合规动作的示例方法的流程图。

具体实施方式

本文描述的实施例针对基于计算机系统处可用和/或活动的冷补丁和热补丁的混合来评估和实施系统合规性。例如，实施例可以包括利用一个或多个策略来确定一个或多个软件组件的合规条件，至少基于哪些冷补丁和哪些热补丁被应用于这些软件组件的运行实例来确定这些更多的软件组件的健康状态，以及制定针对合规条件的一个或多个合规动作，例如为这些软件组件生成健康报告和/或健康证明、为这些软件组件发起打补丁动作、为这些软件组件发起执行控制动作等。

图1A和图1B示出了示例计算机体系结构100a/100b，其有助于基于热补丁和冷补丁的混合来评估和实施系统合规性。如图所示，每个计算机体系结构100a/100b包括对应的计算机系统101a/101b。每个计算机系统101a/101b又包括计算机硬件，例如一个或多个处理器(未示出)、系统存储器102和存储103(例如，持久存储器，例如磁驱动器、固态驱动器等)。系统存储器102存储有操作系统(OS)105的OS服务106和OS内核112的运行时二进制映像，以及在OS 105的上下文中执行的应用104的二进制映像(或多个应用的多个二进制映像)。

在图1A的计算机系统100a中，系统存储器102被示出为包括单个存储器分区，而在图1B的计算机系统101b中，系统存储器102被示出为被划分成至少一个OS存储器区域和至少一个受保护存储器区域。在实施例中，计算机系统101b执行虚拟化技术，例如管理程序，其在计算机系统101a中施行这些存储器分区。在计算机系统101b中，受保护存储器区域由安全内核119管理，并且包括一些服务，例如所描绘的审计服务108和热补丁引擎110(它们是计算机系统101a中OS服务106的一部分)。本领域普通技术人员可以理解，将审计服务108和热补丁引擎110放置在受保护存储器区域内可以将这些服务与应用104和OS 105隔离，有助于保护它们免受应用104或OS 105的篡改，审计服务108和/或热补丁引擎110包括OS存储器区域和受保护存储器区域中的每一个内的子组件。

无论系统存储器102是否被分区，系统存储器102内所示的各种软件组件都基于存储在存储103内的一个或多个冷补丁二进制文件114(在该示例中，其可以包括原始的未补丁二进制文件)来执行。在实施例中，这些软件组件中的一个或多个还基于一个或多个热补丁二进制文件115来执行，热补丁二进制文件115在存储器中被应用于从冷补丁二进制文件114加载的存储器映像。在一个示例中，在软件组件的初始化期间，热补丁引擎110指示加载器113用一个或多个热补丁二进制文件115的代码“修复”一个或多个冷补丁二进制文件114，从而生成包括一个或多个热补丁的软件组件的存储器二进制映像。在另一示例中，在软件组件初始化之后，热补丁引擎110使用一个或多个热补丁二进制文件115的代码修改现有的存储器二进制映像，从而产生包括一个或多个热补丁的软件组件的存储器二进制映像。

在实施例中，计算机系统101a/101b包括本地更新服务107，并与远程更新服务116(或多个远程更新服务)通信。在实施例中，本地更新服务107与远程更新服务116通信(例如，通过一个或多个网络)，以接收冷补丁二进制文件114和/或热补丁二进制文件115，并发起热补丁二进制文件115的应用(例如经由热补丁引擎110)。

如图所示，热补丁引擎110(以及潜在的加载器113)维护补丁日志111，补丁日志111被示为存在于系统存储器102内作为补丁日志111a和/或存在于存储103内作为补丁日志111b。尽管在各种实施例中，补丁日志111可以存储大量信息，但是在一些实施例中对于一个或多个正在执行的软件组件(例如，应用104、OS服务106、OS内核112等)，补丁日志112至少记录每次将热补丁应用于冷补丁和/或每次将热补丁应用于另一热补丁的记录。因此，补丁日志111可用于针对一个或多个正在执行的软件组件中的每一个验证软件组件从中执行的冷补丁和/或热补丁链。在实施例中，冷补丁二进制文件114和/或热补丁二进制文件115中的一个或多个与对应的数字签名相关联。在这些实施例中，这些数字签名由本地更新服务107和/或热补丁引擎110检查，并且这些检查被记录在补丁日志111中。在实施例中，补丁日志111由一种或多种防篡改技术(例如，加密、存储器分区、数字签名、存储在安全密码处理器中的密钥或散列等)保护。在一些实施例中，补丁日志111被存储在远程位置，例如文件共享；替代地或附加地，补丁日志111可以被实现为可以跟踪多个计算机系统的分布式补丁日志数据库的一部分。本领域普通技术人员将理解，存储在补丁日志111中的信息形成已安装补丁的“审计跟踪”。

在一些实施例中，加载器113从热补丁二进制文件115加载热补丁，并且热补丁引擎110将热补丁应用于系统存储器102内的一个或多个存储器映像。热补丁引擎110在补丁日志111中记录热补丁应用的记录。

在一些实施例中，加载器113从热补丁二进制文件115加载热补丁，并且热补丁引擎110验证热补丁的数字签名。如果签名有效，则热补丁引擎110将热补丁应用于系统存储器102内的一个或多个存储器映像。热补丁引擎110在补丁日志111中记录热补丁应用的记录和签名。在一些情况下，新的热补丁二进制文件115将可用，并且这些新的热补丁二进制文件115将重叠或取代现有的热补丁二进制文件115。在一些实施例中，假设新的热补丁二进制文件115被验证，加载器113和热补丁引擎110将卸载现有的热补丁二进制文件并加载新的热补丁二进制文件115。在一些实施例中，加载器113和热补丁引擎110将在现有热补丁二进制文件115之后加载新的热补丁二进制文件115。在一些情况下，计算机系统l0la/l0lb重新启动，并且同一组件有多个热补丁二进制文件115可用。在一些实施例中，加载器113和热补丁引擎110确保冷补丁二进制文件114和热补丁二进制文件115的加载本身是防篡改的。在一些实施例中，加载器113和热补丁引擎110确保冷补丁二进制文件114和热补丁二进制文件115的加载包括将非可选补丁日志记录到补丁日志111中。在一些实施例中，加载器113和热补丁引擎110确保按顺序(例如，构建日期、接收时间、签名日期等)加载热补丁，并将应用热补丁的顺序记录在补丁日志11中。在一些实施例中，加载器113和/或热补丁引擎110将检查策略109并根据策略加载热补丁二进制文件115的实例。在一些实施例中，计算机系统101a/101b可能不具有冷补丁，或者基于策略，对于特定时间窗口或环境因素可能不允许冷补丁。这可能是可用性要求的结果，也可能是带宽受限的结果(热补丁二进制文件比冷补丁二进制文件小得多)，或其他因素。

审计服务108分析计算机系统101a/101b以确定计算机系统101a/101b是否满足策略109内的一个或多个合规条件，策略109被示为存在于系统存储器102内作为策略109a和/或存储103内作为策略109b，并且潜在地施行一个或多个未满足的合规条件。在实施例中，合规意味着计算机系统101a/101b按照策略109中定义的条件操作给定的一组软件补丁。在一些实施例中合规还意味着应用104和/或OS 105按照策略109中定义的条件处于给定的配置。在一些实施例中，从远程更新服务116接收策略109，尽管它们可以从一个或多个其他源获得，它们也可以是用户定义的，等等。在一些实施例中，策略109被隐式地接收或编码在补丁中。这可以被实现为与单个补丁相关联的元数据、与一组补丁的元数据、补丁内的编码数据、分布在一组补丁上的编码数据等。在一些实施例中，策略109和补丁日志111被实现为相同的组件。

在实施例中，审计服务108结合补丁日志111检查冷补丁二进制文件114和/或热补丁二进制文件115，以确定计算机系统101b/101b的至少一个合规状态。在一些实施例中，审计服务108进一步分析系统存储器102以考虑一个或多个热补丁二进制文件115是否实际加载到系统存储器102中。系统存储器102的分析的示例包括调用某些应用编程接口(API)，或向各种可能补丁的组件提供适当的输入，以便区分合规性和不合规性和/或识别是否应用了热补丁。在一些实施例中，审计服务108还考虑其他系统配置信息，例如文件系统、注册表和其他存储工件。在一些实施例中，审计服务108还考虑附加信息，例如本地安全设置、防火墙设置和其他风险因素(例如用户简档、位置、应用信誉等)。使用该信息，审计服务108确定计算机系统101b/101b的一个或多个组件的健康状态。然后，审计服务108执行一个或多个合规动作，例如生成健康报告和/或健康证明、发起补丁动作(例如，应用冷补丁和/或冷补丁、下载和排队可用更新等)，或发起执行控制动作(例如，终止软件组件的实例、允许启动软件组件和/或从属组件的新实例、沙盒软件组件等)。

例如，在实施例中，针对给定漏洞(例如，在远程漏洞数据库118中标识的)寻址的软件补丁可以作为冷补丁或热补丁中的一个或两个而可获得。在一些实施例中，如果冷补丁和热补丁都解决了漏洞，并且冷补丁和热补丁中的每一个都以相同的方式解决了该漏洞。在这些实施例中，审计服务108可以确定冷补丁或热补丁中的一个是否应用于运行的软件组件，并基于该确定制定一个或多个合规动作。在其他实施例中，在通过冷补丁和热补丁两者来解决漏洞的情况下，冷补丁和热补丁以不同的方式来解决漏洞。例如，由于技术限制，热补丁和冷补丁以同等安全级别实现可能是不切实际的。因此，例如，热补丁可以提供缓解，而冷补丁提供修复。例如，如果网络数据包类型可用于攻击系统，则热补丁可以通过丢弃该类型的数据包来解决该漏洞，而冷补丁可以通过额外的数据包处理来解决该漏洞，以确保不允许该类型的包实施攻击。在这些实施例中，审计服务108可以基于是否应用了具有修复的缓解热补丁或冷补丁来确定不同的合规状态。审计服务108可以确定具有修复的缓解热补丁或冷补丁中的哪一个应用于运行的软件组件，并基于这些确定制定一个或多个合规动作。

因此，在实施例中，审计服务108确保冷补丁二进制文件114和热补丁二进制文件115的适当组合被安装并应用于运行的软件组件，以便提供运行时安全合规性保证，并且如果不能满足运行时安全合规性保证，则审计服务108可以对软件组件施行限制。在一些实施例中，审计服务108要求：在计算机系统100a/100b处加载其他软件组件之前应用一些热补丁。在一些实施例中，使用冷补丁二进制文件114的分析，审计服务108还要求：这些热补丁即使在系统重新启动或服务中断期间也在软件组件的生命周期内保持应用，从而提供“重置/重新启动”安全合规性保证。

为了说明审计服务108如何完成上述任务，图1C示出了图1A和图1B中审计服务108的其他细节。图1C中描绘的审计服务108包括各种组件(即，策略识别组件120、补丁状态确定组件121和合规施行组件122)，这些组件表示审计服务108可以根据本文描述的各种实施例实现的各种功能。可以理解，所描述的组件包括其身份、子组件和布置仅作为描述本文所描述的审计服务108的各种实施例的帮助而呈现，并且这些组件不限制软件和/或硬件如何实现本文所描述审计服务108，或其特定功能。

通常，策略识别组件120从存储103和/或从外部源(例如，远程更新服务116)访问策略109。从这些策略109中，策略识别组件120基于在计算机系统101a/101b处执行的一个或多个软件组件的打补丁状态，来识别一个或多个合规条件。在一些实施例中，策略识别组件120还从远程漏洞数据库118识别一个或多个漏洞。在这些实施例中，所识别的漏洞被用作对策略109内的条件的进一步输入。

一般地，补丁状态确定组件121考虑冷补丁状态和热补丁状态以确定至少一个软件组件的打补丁状态。在实施例中，补丁状态确定组件121确定存在于存储103内的冷补丁二进制文件114和热补丁二进制文件115，以及这些热补丁二进制文件115中的哪些已被应用于软件组件的一个或多个运行实例。在实施例中，补丁状态确定组件121基于查询补丁日志111和/或通过直接分析系统存储器102内的那些实例，分析哪些热补丁二进制文件115已被应用于软件组件的一个或多个运行实例。

一般地，基于补丁状态确定组件121的分析，合规施行组件122制定针对策略识别组件120所识别的合规条件的一个或多个合规动作。在实施例中，合规动作可以包括：生成健康报告和/或健康证明、发起打补丁动作、发起执行控制动作，等等。

现在结合图2提供审计服务108的这些组件的进一步描述，图2示出了用于使用考虑冷补丁和热补丁的混合的评估来制定合规动作的示例方法200的流程图。方法200将参考计算机体系结构100a/100b的其他组件和数据来描述。

方法200包括从策略识别合规条件的动作201。在实施例中，动作201包括基于软件组件的打补丁状态识别定义一个或多个合规条件的一个或多个系统策略，包括识别定义针对特定软件组件的特定合规条件的特定系统策略。在一个正在进行的示例中，策略识别组件120从策略109加载一个或多个策略。这些策略109为在计算机系统101a/101b处执行的软件组件(例如应用104、OS服务106、OS内核112等)提供合规条件。出于正在进行的示例的目的，假设策略109确定应用104的至少一个合规条件。

在一个策略示例中，策略109定义一组条件，使得如果给定的一组热补丁可用(在热补丁二进制文件115内或来自远程更新服务116)来解决漏洞(例如，在远程漏洞数据库118中标识的)，这些热补丁必须被应用于计算机系统101a/101b以保持合规性(如果不符合合规性，则可以终止软件组件)。在一些实施例中，策略109还定义了一个条件，即冷补丁二进制文件114被更新(例如，通过本地更新服务107)以解决漏洞(此时热补丁将不再适用于那些冷补丁二进制文件)。在实施例中，热补丁不适用于冷补丁二进制文件，因为冷补丁二进制文件已经包括由热补丁提供的补丁，或者冷补丁二进制文件包括冲突补丁(例如，冷补丁二进制文件中的补丁与热补丁中的缓解冲突)。在一些实施例中，策略109基于可靠性定义条件。在一个示例可靠性策略中，如果热补丁和冷补丁更新都可用，并且如果应用热补丁更新失败，则该策略施行应用冷补丁(反之亦然)。

在另一策略示例中，策略109定义一组条件，使得在操作环境中操作的软件组件仅在操作环境处于已知的合规状态时才被认为是合规的。在实施例中，如果操作环境满足某些安全引导要求和/或如果补丁日志111中存在适当的数字签名审计跟踪，则认为操作环境处于已知的合规状态。在一些实施例中，如果已经过了时间阈值和/或如果已经有阈值数量的热补丁应用于操作环境，则策略109要求在软件组件被视为合规之前对操作环境进行“重新基线化”。在实施例中，通过安装冷补丁、通过分析审计跟踪等来重新基线化操作环境。

在另一个策略示例中，策略109定义一组条件，这些条件基于系统是否存在安全目标或可用性目标来指导系统是否能够保持合规性。在实施例中，出于安全性的目的，策略109指示：如果可用的冷补丁比可用的热补丁更安全，则必须安装冷补丁以保持合规性(即使这意味着服务中断或甚至系统重新启动)。在实施例中，以可用性为目标，策略109指示：如果热补丁可用，则应优先于冷补丁(直到稍后的重新基线/重新启动时才应用冷补丁)。在实施例中，为了平衡安全性和可用性，策略109指示应当优先应用实施缓解的热补丁而不是实施修复的冷补丁。

在另一个策略示例中，策略109基于计算机系统101a/101b的属性来定义一组条件，这些条件指导系统是否能够保持合规性。在实施例中，这包括位置、用户信息、外围设备的存在、应用信息或其他属性中的一个或多个。例如，一些位置可能具有受限的带宽和/或其他环境因素，这些因素限制下载和应用一个或多个冷补丁。在另一示例中，对于某个组件，可以存在多个热补丁二进制文件115。基于策略109和计算机系统101a/101b的属性，加载器113和热补丁引擎110将加载一个(或一组)热补丁二进制文件115，其他热补丁二进制文件115可以在加载之前(例如以特定顺序)加载或不加载。在实施例中，策略109基于健康属性或功能性属性中的一个或多个来定义一组条件。例如，一个或多个策略109可以定义系统被认证为健康所需的一组热补丁，而一个或多个策略109可以定义系统被验证为具有所需功能所需的热补丁。在一些实施例中，策略109中的一个或多个甚至可以定义移除功能的一组热补丁。例如，如果存在提供存在未打补丁或不可打补丁的漏洞的功能的软件组件，则策略109可能要求应用从软件组件移除该功能的热补丁(从而移除该漏洞)。

在另一个策略示例中，策略109定义了考虑各种软件组件和/或依赖性的工作负载的一组条件。例如，由于其不同的工作负载，策略109可以允许具有正常运行时间优先级(例如，运行客户端服务)的虚拟机在具有安全优先级(例如运行服务器工作负载)的虚拟机器将需要冷补丁来保持合规性的情况下保持与热补丁的合规性。在另一示例中，策略109可以允许具有阈值数量的依赖性的软件组件在具有较少数量的依赖性的软件组件将需要冷补丁来保持合规性的情况下保持与热补丁的合规性。在另一示例中，策略109可以允许不具有冗余的软件组件在具有冗余(例如，通过集群)的软件组件将需要冷补丁来保持合规性的情况下保持与热补丁的合规性。

在另一个策略示例中，策略109定义了一组条件，这些条件指示实施缓解的一组热补丁足以保持合规性，但实施修复的冷补丁应被及时地下载并排队等待下一次安装的机会(例如，在计划维护期间)。

在另一策略示例中，策略109定义考虑与软件组件相关联的服务级别协议(SLA)的一组条件。例如，策略109可以允许对与更严格的SLA相关联的软件组件使用热补丁，但要求对与更不严格的SLA相关联的软件组件应用冷补丁。例如，该条件可以指定当且仅当SLA超过“三个9”(99.9％可用性)时，一组热补丁程序就足以满足给定的合规状态，或者可以指定当SLA低于95％时，需要一组冷补丁程序满足给定合规状态。注意，在一些实施例中，如果确定热补丁或冷补丁超出SLA，则在用户或管理员采取行动之前，可能不会安装新的热补丁二进制文件和冷补丁二进制文件。在一些实施例中，如果热补丁超出SLA，则卸载热补丁以提高可靠性。在一些实施例中，如果冷补丁超出SLA，则可以初始化回滚过程，其中卸载适当的冷补丁二进制文件114，之后可以重新启动运行该冷补丁的(多个)进程。

在另一个策略示例中，策略109定义一组条件，这些条件定义缓解热补丁何时不再充分。该组条件可以指示需要修复冷补丁来维持合规性，或者可以指示必须下载更新的策略(例如，将该组条件扩展到稍后的日期)以确定基于热补丁的合规状态。例如，该条件可以指定一组热补丁在预定日期或时间之前足够使用最少的小时数，或者如果该条件适用，则合规状态必须具有更短的有效期。

在另一个策略示例中，策略109定义了一组或多个条件，这些条件定义了必须应用两个或多个热补丁的顺序。作为示例，如果补丁日志111指示必须以特定顺序应用两个或多个热补丁，则条件可以指定计算机系统101a/101b或在其中执行的软件组件可以满足足以证明的健康条件。

如上所述，在实施例中，策略108被隐式地接收或被编码在补丁中。因此，在实施例中，在补丁文件内接收或编码一个或多个系统策略中的至少一个系统策略。

方法200还包括从冷补丁和热补丁确定软件打补丁状态的动作202。在实施例中，动作201包括确定特定软件组件的打补丁状态。在实施例中，确定打补丁状态包括识别多个证据，每个证据对应于多个二进制文件中的已被应用于特定软件组件的二进制文件，多个二进制文档包括(i)一个或多个冷补丁二进制文件，特定软件组件能够从一个或多个冷补丁二进制文件被加载，以及(ii)适用于特定软件组件的一个或多个热补丁二进制文件。在实施例中，多个证据中的每一个都可用于确定是否已将多个二进制文件应用于特定软件组件。例如，证据可以包括补丁文件的存储器或磁盘副本、补丁日志111等的密码散列。继续前述示例，在一个场景中，补丁状态确定组件121确定冷补丁二进制文件114中可应用于应用104的一个或多个冷补丁，以及热补丁二进制文件115中可应用于应用104的一个或多个热补丁。

在一些实施例中，冷补丁二进制文件114和/或热补丁二进制文件115中的一个或多个与数字签名相关联。因此，在动作202的一些实施例中，一个或多个冷补丁二进制文件和一个或多个热补丁二进制文件中的每一个与对应的数字签名相关联。在这些实施例中，补丁状态确定组件121可以确定这些签名的有效性，例如通过对照数字证书检查这些签名。

在一些实施例中，基于每个过程来衡量打补丁状态的确定。在一种情况下，计算机系统101a/101b在没有应用新的冷补丁二进制文件114的情况下启动，但是新的冷补丁二进制文件114是可用的，包括应用104。应用104的第一实例被加载并正在运行，并且加载器113和热补丁引擎110已经将热补丁二进制文件115应用于它。本地更新服务107已经确定将冷补丁二进制文件114应用到磁盘上的应用104是安全的。在应用冷补丁二进制文件114之后，加载并运行应用104的第二实例。在这种情况下，应用104的第一实例使用热补丁二进制文件115运行，而应用104第二实例使用冷补丁二进制文件114运行。在这些实施例中，审计服务108基于每个进程分析计算机系统101a/101b，以确定计算机系统101a/101b是否满足策略109内的一个或多个合规条件。策略109可以使用附加属性来确定应用104的两个或多个实例的风险，并且它被管理员使用，这可能会给计算机系统101带来更大的风险。然而，如果应用104的热补丁实例可能更具风险，但被访客用户(具有较少权限)使用，则可以确定其风险较低。有许多因素可以确定风险，包括补丁的漏洞减轻了哪些攻击、用户权限、软件依赖性等。在一些实施例中，审计服务108将确定应用104的热补丁实例风险太大，无法继续运行。审计服务108将终止该进程，或向OS内核112发出信号以终止该进程。在一些实施例中，本地更新服务107维护冷补丁处理二进制文件114内的软件组件的不同版本(例如，使用不同的文件路径)，每个版本在计算机系统101a/101b处支持该软件组件的运行实例/进程。在这些实施例中，本地更新服务107还可以在热补丁二进制文件115内维护适用于这些不同冷补丁二进制文件的各种热补丁。

在一些实施例中，确定打补丁状态还包括基于多个证据，确定一个或多个热补丁二进制文件的至少一个子集是否已被应用于计算机系统处的系统存储器内的存储器映像，特定软件组件的实例被加载到该存储器映像中。继续前述示例，在一个场景中，补丁状态确定组件121查阅补丁日志111，以确定对于应用104的至少一个运行实例，一个或多个热补丁二进制文件115是否已被应用于冷补丁二进制文件114中的一个(如适用)。

在一些实施例中，确定打补丁状态还包括验证热补丁是否确实被应用于特定软件组件的实例。因此，动作202的一些实施例包括分析特定软件组件的实例加载到其中的存储器映像，以验证一个或多个热补丁二进制文件的子集的应用。对存储器的访问可以包括获取存储器快照、收集实时存储器转储数据、执行读取适当存储器区域的内核驱动程序等。继续前述示例，补丁状态确定组件121被动地监视应用104和/或OS 105的行为，以确保应用适当的热补丁。在一些实施例中，补丁状态确定组件121调用API，或向各种补丁组件提供适当的输入，以确定它们是否被适当地补丁。

如上所述，在一些实施例中，冷补丁二进制文件114和/或热补丁二进制文件115中的一个或多个与数字签名相关联。在这些实施例中，补丁状态确定组件121可以从补丁日志111验证已经基于这些签名(例如，审计跟踪)应用了冷补丁和热补丁的适当序列。因此，在动作202的一些实施例中，确定特定软件组件的打补丁状态还包括从补丁日志验证对应数字签名中的两个或更多个数字签名的链的有效性。

方法200还包括基于打补丁状态来制定合规条件的动作203。在实施例中，动作201包括基于特定系统策略并且基于所确定的特定软件组件的打补丁状态，来制定针对特定合规条件的合规动作，合规动作包括以下至少一项(i)至少基于特定软件组件的打补丁状态，生成健康报告或健康证明中的至少一项；(ii)在特定软件组件上发起打补丁动作；或(iii)在特定软件组件上发起执行控制动作。继续前述示例，基于在动作201中由策略识别组件120确定的合规条件，并且基于在动作202中确定的应用104的实例的打补丁状态，合规施行组件122制定针对应用104的合规动作。

在一些实施例中，合规实施组件122至少基于特定软件组件的打补丁状态来生成健康报告。在实施例中，健康报告包括或基于计算机系统101a/101b内部的各种因素，例如特定软件组件在其中执行的底层操作环境的安全状态(例如，基于安全引导技术，例如使用可信平台模块)，哪些冷补丁和/或热补丁已经或尚未应用于特定软件组件、特定软件组件的配置状态等。特别参考打补丁状态，在一些实施例中，在动作203中生成健康报告包括至少基于已经确定一个或多个热补丁二进制文件的子集是否已被应用于系统存储器内的存储器映像来生成健康得分，特定软件组件的实例被加载到该存储器映像中。

在实施例中，健康报告还包括或基于计算机系统101a/101b外部的信息，例如远程漏洞数据库118中包含的信息。例如，冷补丁和热补丁的应用集合是否解决了远程漏洞数据库118所标识的漏洞可以影响健康评分。因此，在一些实施例中，在动作203中生成健康报告包括至少基于一个或多个热补丁二进制文件的子集是否解决了外部漏洞数据库中所标识的漏洞来生成健康得分。在一些实施例中，审计服务108将所生成的健康报告传送给外部实体，例如远程证明服务117。

在一些实施例中，合规施行组件122至少基于特定软件组件的打补丁状态来生成健康证明。类似于健康报告，在实施例中，健康证明的生成是基于计算机系统101a/101b内部和/或外部的各种因素。这些因素可以包括特定软件组件在其中执行的底层操作环境的安全状态、哪些冷补丁和/或热补丁已经或还没有应用于特定软件组件、特定软件组件的配置状态、特定软件组件的配置状态和/或特定软件组件所处的状态，冷补丁和热补丁的应用集合是否解决远程漏洞数据库118所识别的漏洞等。在实施例中，合规施行组件122仅在所生成的健康得分/报告足够高时(例如，根据所识别的合规条件)才生成健康证明。例如，在一些实施例中，在动作203中生成健康证明包括：仅当一个或多个热补丁二进制文件的子集已被应用于系统存储器内的存储器映像时才生成健康证明，特定软件组件的实例被加载到该存储器映像中。在其他实施例中，在动作203中生成健康证明还包括：仅当操作系统被确定为具有所识别的信任级别时才生成健康证明。

在一些实施例中，合规施行组件122随着时间的推移“降低”健康得分，甚至没有外部输入(例如，来自远程更新服务116的新策略109、来自远程漏洞数据库118的新漏洞信息等)。因此，例如，即使当软件组件已经接收到足以由合规施行组件122发布健康证明的得分时，该软件组件也可能随后仅由于时间的流逝(例如，基于策略109的时间)而接收到不足以发布持续健康证明的得分。如本领域普通技术人员将理解的，随着时间的推移降低健康得分对于确保断开或部分连接的情况下的安全性可能是有用的，其中计算机系统101a/101b仅以对远程更新服务116的间歇性或有限的访问来操作。特别地，随着时间的推移降低健康得分确保了计算机系统仅在其至少偶尔从远程更新服务116获得补丁的情况下才能保持合规性。

在一些实施例中，合规施行组件122向合规服务发送生成的健康报告和/或证明。例如，在实施例中，计算机系统101a/101b与第一或第三方漏洞评估和/或合规服务通信，该服务例如提供合规服务(“CaaS”)。在这些实施例中，该合规服务至少部分地基于计算机系统101a/101b的打补丁状态(包括已应用哪些热补丁)来认证计算机系统101a/101b是否继续运行。在实施例中，合规服务至少基于应用于计算机系统101a/101b的冷补丁和热补丁的组合是否解决了远程漏洞数据库118中标识的特定漏洞，来确定计算机系统101a/101b是否可以通过操作来认证。因此，通过向合规服务发送所生成的健康报告和/或证明，合规服务能够至少部分地基于在计算机系统101a/101b处应用的热补丁来认证计算机系统101a/101b以继续运行。参考方法200，在一些实施例中，在动作203中生成健康报告和/或健康证明因此包括将生成的报告或健康证明发送到合规服务。

在一些实施例中，合规施行组件122在特定软件组件上发起打补丁动作。例如，如果特定软件组件的实例尚未按照特定合规条件的要求用一个或多个热补丁二进制文件115进行补丁，但这些热补丁可用，则合规施行组件122指示热补丁引擎110将这些热补丁应用于特定软件组件实例。因此，在一些实施例中，在特定软件组件上发起打补丁动作包括发起将一个或多个热补丁二进制文件的子集应用于加载特定软件组件的实例的存储器映像。

在另一个示例中，如果特定软件组件的实例没有按照特定合规条件的要求用冷补丁二进制文件114之一启动，但是冷补丁是可用的，则合规施行组件122指示热补丁引擎110从适当的冷补丁重新启动软件组件。因此，在一些实施例中，发起特定软件组件上的打补丁动作包括发起特定软件组件的实例从一个或多个冷补丁二进制文件之一的重新加载。

在又一示例中，特定软件组件的特定合规条件所要求的冷补丁和/或热补丁可能还不存在于冷补丁二进制文件114和/或热补丁二进制文件115中。结果，合规施行组件122指示本地更新服务107从远程更新服务116下载这些补丁。因此，在一些实施例中，在特定软件组件上发起打补丁动作包括调度用于特定软件组件的一个或多个附加补丁文件的下载。

在实施例中，基于策略109选择要进行的打补丁动作。因此，在实施例，至少部分基于一个或多个系统策略来选择特定的打补丁动作。

在一些实施例中，合规施行组件122发起对特定软件组件的执行控制动作。例如，如果特定软件组件的特定合规条件所要求的所有冷补丁和/或热补丁存在于冷补丁二进制文件114和/或热补丁二进制文件115内，则合规施行组件122允许加载器发起特定软件组件的新示例。因此，在一些实施例中，在特定软件组件上发起执行控制动作包括允许加载特定软件组件的附加实例。在这些实施例中，合规施行组件122进一步确保在启动期间由加载器113应用所有所需的热补丁。因此，在实施例中，允许加载特定软件组件的附加实例包括施行一个或多个热补丁二进制文件的子集向加载特定软件组件的附加实例的附加存储器映像的应用。

在另一示例中，如果冷补丁二进制文件114和/或热补丁二进制文件115缺少特定软件组件的特定遵从条件所需的所有冷补丁和/或热补丁，则合规施行组件122拒绝由加载器113发起特定软件组件的实例。因此，在一些实施例中，在特定软件组件上发起执行控制动作包括拒绝加载特定软件组件的附加实例。类似地，如果冷补丁二进制文件114和/或热补丁二进制文件115缺少特定软件组件的特定合规条件所要求的所有冷补丁和/或热补丁，则合规施行组件122可以终止特定软件组件已经运行的实例。因此，在一些实施例中，在特定软件组件上发起执行控制动作包括终止特定软件组件的实例。如本领域普通技术人员将理解的，如果发现新的漏洞并且补丁仍然可用，则可能出现这种情况。

在又一示例中，可能存在依赖于特定软件组件进行操作的一个或多个其他软件组件(例如，当特定软件组件是库时)，并且如果存在和/或应用了特定软件组件的特定合规条件所要求的所有冷补丁和热补丁，则合规施行组件122仅允许那些其他软件组件启动。因此，在一些实施例中，在特定软件组件上发起执行控制动作包括允许加载依赖于特定软件组件的实例的其他软件组件。类似地，如果特定软件组件的特定合规条件所要求的冷补丁和热补丁不存在和/或不被应用，则合规施行组件122可以拒绝启动那些其他软件组件。因此，在一些实施例中，在特定软件组件上发起执行控制动作包括拒绝加载依赖于特定软件组件的实例的其他软件组件。

在又一示例中，如果冷补丁二进制文件114和/或热补丁二进制文件115缺少特定软件组件的特定合规条件所需的所有冷补丁和/或热补丁，则合规施行组件122允许加载器113发起特定软件组件的新实例，使该新实例在沙盒环境(例如，容器、虚拟机、监狱等)中运行。因此，在一些实施例中，在特定软件组件上发起执行控制动作包括沙盒化特定软件组件的附加实例。

在一些实施例中，方法200由驻留在与其运行的操作系统相同的存储空间中的审计服务执行。例如，参考图1A，审计服务108驻留在与OS 105相同的存储器区域内。在其他实施例中，方法200由驻留在存储空间中的审计服务执行，该存储空间受到保护，不受其运行的操作系统的影响。例如，参考图1B，审计服务108驻留在受保护存储器区域中，而OS 105驻留在单独的OS存储器区域中。因此，在后一实施例中，方法200至少部分地由驻留在受保护存储器区域中的组件执行。在一些实施例中，受保护存储器区域与硬件(例如Intel软件保护扩展(SGX)、ARM TrustZone等)隔离。在一些实施例中，受保护存储器区域由管理程序与特定软件组件所在的另一存储器区域隔离。

虽然本公开集中于软件补丁，但应当理解，本文所讨论的原理也适用于硬件更新/升级。例如，在实施例中，审计服务108在进行健康报告/证明时考虑计算机系统101a/101b的硬件配置信息，包括考虑自启动以来已添加到计算机系统101a/101b的硬件，自启动以来已从计算机系统101a/101b中删除的硬件，自启动以来已热交换到计算机系统101a/101b的硬件，硬件固件更新等等。因此，例如，如果固件过时或变得易受攻击，如果硬件过时或被认为易受攻击或不稳定，如果添加了未知硬件，如果移除了所需硬件等，则审计服务108可以拒绝合规性认证。

因此，本文描述的实施例基于在计算机系统处可用和/或活动的冷补丁和热补丁的混合来评估和施行系统合规性。这些实施例利用一个或多个策略来确定一个或多个软件组件的合规条件，至少基于哪些冷补丁和哪些热补丁应用于这些软件组件的运行实例来确定这些更多软件组件的健康状态，以及制定针对合规条件的一个或多个合规动作，例如生成针对这些软件组件的健康报告和/或健康证明、发起针对这些软件组件的打补丁动作、发起针对这些组件的执行控制动作，等等。

尽管主题已经以特定于结构特征和/或方法行为的语言描述，但是应当理解，所附权利要求中定义的主题并不局限于上述描述的特征或行为，或者上述行为的顺序。相反，所描述的特征和动作仅作为实现权利要求的示例的形式公开。

本发明的实施例可以包括或利用包括计算机硬件的专用或通用计算机系统，例如一个或多个处理器和系统存储器。如下面更详细地讨论的。本发明范围内的实施例还包括用于承载或存储计算机可执行指令和/或数据结构的物理和其他计算机可读介质。这种计算机可读介质可以是可由通用或专用计算机系统访问的任何可用介质。存储计算机可执行指令和/或数据结构的计算机可读介质是计算机存储介质。携带计算机可执行指令和/或数据结构的计算机可读介质是传输介质。因此，作为示例而非限制，本发明的实施例可以包括至少两种明显不同的计算机可读介质：计算机存储介质和传输介质。

计算机存储介质是存储计算机可执行指令和/或数据结构的物理存储介质。物理存储介质包括计算机硬件，如RAM、ROM、EEPROM、固态驱动器(“SSD”)、闪存、电阻RAM、相变存储器(“PCM”)、光盘存储、磁盘存储或其他磁存储设备，或可用于以计算机可执行指令或数据结构形式存储程序代码的任何其他硬件存储设备，其可由通用或专用计算机系统访问和执行以实现本发明的公开功能。

传输介质可以包括网络和/或数据链路，其可以用于以计算机可执行指令或数据结构的形式携带程序代码，并且可以由通用或专用计算机系统访问。“网络”被定义为一个或多个数据链路，用于在计算机系统和/或模块和/或其他电子设备之间传输电子数据。当信息通过网络或另一通信连接(硬连线、无线或硬连线或无线的组合)传输或提供给计算机系统时，计算机系统可以将该连接视为传输介质。上述内容的组合也应包括在计算机可读介质的范围内。

此外，在到达各种计算机系统组件时，计算机可执行指令或数据结构形式的程序代码可以自动地从传输介质传输到计算机存储介质(反之亦然)。例如，通过网络或数据链路接收的计算机可执行指令或数据结构可以缓冲在网络接口模块(例如，“NIC”)内的RAM中，然后最终传输到计算机系统RAM和/或计算机系统处的不易失性计算机存储介质。因此，应当理解，计算机存储介质可以包括在同样(或甚至主要)利用传输介质的计算机系统组件中。

计算机可执行指令包括例如指令和数据，当在一个或多个处理器处执行时，这些指令和数据使通用计算机系统、专用计算机系统或专用处理设备执行特定功能或功能组。计算机可执行指令可以是例如二进制文件、诸如汇编语言的中间格式指令，甚至是源代码。

本领域技术人员将理解，本发明可以在具有许多类型的计算机系统配置的网络计算环境中实践，包括个人计算机、台式计算机、膝上计算机、消息处理器、手持设备、多处理器系统、基于微处理器或可编程的消费电子产品、网络PC、，大型计算机、移动电话、PDA、平板电脑、寻呼机、路由器、交换机等。本发明还可以在分布式系统环境中实践，其中本地和远程计算机系统都执行任务，本地和远程系统通过网络链接(通过硬连线数据链路、无线数据链路或通过硬连线和无线数据链路的组合)。这样，在分布式系统环境中，计算机系统可以包括多个组成计算机系统。在分布式系统环境中，程序模块可以位于本地和远程存储器存储设备中。

本领域技术人员还将理解，本发明可以在云计算环境中实践。云计算环境可以是分布式的，尽管这不是必需的。当分布式时，云计算环境可以在一个组织内国际分布和/或具有跨多个组织拥有的组件。在本说明书和权利要求中，“云计算”被定义为用于实现对可配置计算资源(例如，网络、服务器、存储、应用和服务)的共享池的按需网络访问的模型。“云计算”的定义并不局限于在适当部署时可以从这种模型中获得的任何其他众多优势。

云计算模型可以由各种特征组成，如按需自助服务、广泛的网络访问、资源池、快速弹性、可测量的服务等。云计算模型也可以是各种服务模型的形式，例如，软件即服务(“SaaS”)、平台即服务(PaaS)、基础设施即服务(IaaS)、CaaS等。还可以使用不同的部署模型来部署云计算模型，例如私有云、社区云、公共云、混合云等。

一些实施例，例如云计算环境，可以包括一种系统，该系统包括一个或多个主机，每个主机都能够运行一个或多个虚拟机。在运行期间，虚拟机模拟运行计算系统，同时支持操作系统和可能一个或多个其他应用。在一些实施例中，每个主机包括管理程序，该管理程序使用从虚拟机的视图抽象的物理资源来仿真虚拟机的虚拟资源。管理程序还提供虚拟机之间的适当隔离。因此，从任何给定虚拟机的角度来看，管理程序提供虚拟机与物理资源交互的错觉，即使虚拟机仅与物理资源的外观(例如，虚拟资源)交互。物理资源的示例包括处理容量、存储器、磁盘空间、网络带宽、媒体驱动器等。

在不脱离本发明的思想或基本特征的情况下，本发明可以以其他特定形式实施。所描述的实施例在所有方面仅被认为是说明性的而非限制性的。因此，本发明的范围由所附权利要求而不是由前述描述来指示。在权利要求的含义和等效范围内的所有变更都应包含在其范围内。当在所附权利要求中引入元素时，条款“a”、“an”、“the”和“said”意在表示存在一个或多个元素。术语“包括”、“包括”和“具有”旨在具有包容性，意味着可能存在除所列元素之外的其他元素。术语“集合”和“子集”被缩进以排除空集，因此“集合”被定义为非空集，“子集”定义为非空子集。

Claims (13)

1.一种在包括处理器的计算机系统处实现的方法，所述方法用于使用考虑冷补丁和热补丁的混合的评估来执行合规动作，所述方法包括：

基于软件组件的打补丁状态，识别定义一个或多个合规条件的一个或多个系统策略，包括识别特定系统策略，所述特定系统策略定义针对特定软件组件的特定合规条件；

确定所述特定软件组件的打补丁状态，包括：

识别多个证据，每个证据对应于多个二进制文件中的已被应用于所述特定软件组件的二进制文件，所述多个二进制文件包括(i)一个或多个冷补丁二进制文件，所述特定软件组件能够从所述一个或多个冷补丁二进制文件被加载，以及(ii)适用于所述特定软件组件的一个或多个热补丁二进制文件；以及

基于所述多个证据，确定所述一个或多个热补丁二进制文件的至少一个子集是否已被应用于所述计算机系统处的系统存储器内的存储器映像，所述特定软件组件的实例被加载到所述存储器映像中；

基于所述特定系统策略，并且基于所确定的所述特定软件组件的所述打补丁状态，制定针对所述特定合规条件的合规动作，所述合规动作包括以下至少一项：

至少基于所述特定软件组件的所述打补丁状态，生成健康报告或健康证明中的至少一项；

在所述特定软件组件上发起打补丁动作；或

在所述特定软件组件上发起执行控制动作。

2.根据权利要求1所述的方法，其中所述方法至少基于所述特定软件组件的所述打补丁状态来生成所述健康报告，并且其中生成所述健康报告包括以下至少一项：

至少基于已经确定所述一个或多个热补丁二进制文件的所述子集是否已被应用于所述系统存储器内的所述存储器映像来生成健康得分，所述特定软件组件的所述实例被加载到所述存储器映像中；或

至少基于所述一个或多个热补丁二进制文件的所述子集是否解决了外部漏洞数据库中所标识的漏洞，来生成所述健康得分。

3.根据权利要求1所述的方法，其中所述方法至少基于所述特定软件组件的所述打补丁状态来生成所述健康证明，并且其中生成所述健康证明包括：仅当所述一个或多个热补丁二进制文件的所述子集已被应用于所述系统存储器内的所述存储器映像时，并且仅当操作系统被确定为具有所识别的信任级别时，生成所述健康证明，所述特定软件组件的所述实例被加载到所述存储器映像中。

4.根据权利要求1所述的方法，其中所述方法生成所述健康报告或所述健康证明中的至少一项，并且其中所述方法还包括：向合规服务发送所生成的所述报告或所述健康证明。

5.根据权利要求1所述的方法，其中所述方法在所述特定软件组件上发起所述打补丁动作，并且其中在所述特定软件组件上发起所述打补丁动作包括以下至少一项：

发起所述一个或多个热补丁二进制文件的所述子集向所述存储器映像的应用，所述特定软件组件的所述实例被加载到所述存储器映像中；

发起所述特定软件组件的所述实例从所述一个或多个冷补丁二进制文件之一的重新加载；或

调度用于所述特定软件组件的一个或多个附加补丁文件的下载。

6.根据权利要求5所述的方法，其中特定的打补丁动作至少部分地基于所述一个或多个系统策略而被选择。

7.根据权利要求1所述的方法，其中所述方法在所述特定软件组件上发起所述执行控制动作，其中在所述特定软件组件上发起所述执行控制动作包括以下至少一项：

允许所述特定软件组件的附加实例的加载；

拒绝所述特定软件组件的所述附加实例的加载；

允许依赖于所述特定软件组件的所述实例的其他软件组件的加载；

拒绝依赖于所述特定软件组件的所述实例的所述其他软件组件的加载；

终止所述特定软件组件的所述实例；或

沙盒化所述特定软件组件的所述附加实例。

8.根据权利要求7所述的方法，其中允许所述特定软件组件的所述附加实例的所述加载包括：施行所述一个或多个热补丁二进制文件的所述子集向附加存储器映像的应用，所述特定软件组件的所述附加实例被加载到所述附加存储器映像中。

9.根据权利要求1所述的方法，其中确定所述特定软件组件的所述打补丁状态还包括：分析所述存储器映像以验证所述一个或多个热补丁二进制文件的所述子集的应用，所述特定软件组件的所述实例被加载到所述存储器映像中。

10.根据权利要求1所述的方法，其中所述一个或多个冷补丁二进制文件和所述一个或多个热补丁二进制文件中的每一个与对应的数字签名相关联，并且其中确定所述特定软件组件的所述打补丁状态还包括：从补丁日志验证对应数字签名中的两个或更多个数字签名的链的有效性。

11.根据权利要求1所述的方法，其中所述方法至少部分地由驻留在受保护存储器区域中的组件执行，所述受保护存储器区域与所述特定软件组件驻留于其中的另一存储器区域相隔离。

12.根据权利要求1所述的方法，其中所述一个或多个系统策略中的至少一个系统策略在补丁文件内被接收或编码。

13.根据权利要求1所述的方法，其中所述特定系统策略包括健康策略或功能性策略中的至少一项。

Images