为什么计算机安全如此困难

⚠️ 本文部分内容涉及较深入的技术细节。⚠️ 标记的段落或整节属于选读内容；如果您只想了解总体思路，可以跳过这些部分，不会影响理解文章的核心论点。

介绍

软件可能在人们尚未了解其在恶劣环境下的运行情况之前，就已看似完成。人工智能辅助工具可以帮助快速构建界面和功能，但演示仅涵盖预先选定的路径。它无法说明来自错误账户的请求是否会被拒绝、格式错误的文件是否会触发严重缺陷，或者依赖项失效是否会导致信息泄露。展示有用的行为和建立可信的界限需要不同的证据。

即使面对错误的指令、被盗的凭证、状态变更以及蓄意破坏，系统也必须坚持其既定的规则。这些规则不仅体现在应用程序的可见功能上，还延伸至身份系统、特权服务、库、操作系统、硬件以及维护等各个层面。每个组件表面上可能运行正常，但它们之间任何一个环节的决策失误都可能导致有害后果。

人们通常从机密性、完整性和可用性三个方面来讨论安全性：防止未经授权的披露、防止未经授权的篡改，以及确保服务在特定条件下可用。这些标签描述的是结果，而非保障措施。医疗记录、账户余额和交通时刻表各自遵循不同的规则，并承担不同的后果。安全工作的第一步是明确哪些内容必须受到保护，哪些行为可能违反其要求，以及这些行为可能采取哪些途径。即使访问控制措施本身健全，收集和保留敏感度较低的信息也能降低日后数据泄露造成的损失。[1]

安全控制的有效性取决于它实际控制的操作。网站可能阻止未经授权的下载，但导出功能却可能释放相同的文件。加密可能保护文件，但其解密密钥却可能被未经授权的第三方获取。应用程序可能批准一个文件，随后又以相同的名称打开另一个文件。在每种情况下，本地安全措施都可能使人误以为整个操作都受到保护，而实际上并非如此。

威胁模型可以识别哪些内容需要保护、攻击者可以更改哪些内容、特权决策发生在哪里以及哪些假设可能失效。它有助于揭示可能的危害途径，但并不声称能够预测每一种攻击。[2]

识别这些路径还能揭示系统的攻击面：攻击者可能输入信息、请求操作或获取信息的地方。网络服务、登录和管理界面以及文件导入功能都是可能的入口点，即使它们在屏幕上并不明显。缩小攻击面意味着禁用不必要的功能和服务，限制哪些人或哪些程序可以访问剩余的功能和服务，并拒绝授予他们不需要的权限。减少暴露的路径可以降低攻击机会，但剩余的路径仍然需要进行严格的检查和维护。

安全首先失效的地方

许多严重的安全事件并不需要特殊的技术手段。许多账户仍然使用制造商提供的密码，这些密码可能在多人之间共享，或者在不相关的服务中重复使用。一旦攻击者获知此类密码，系统可能仍然会按照预期接受登录。密码猜测、使用从其他地方泄露的凭据进行自动尝试以及欺诈性地请求一次性验证码，这些攻击利用的是身份验证方面的漏洞，而不是密码验证代码中的错误。使用独特且难以猜测的凭据、完善的账户恢复机制、速率限制以及更强大的登录方式可以减少这些攻击机会。多因素身份验证和通行密钥（passkeys）提供了重要的保护，但没有任何登录方式能够独立判断登录后发出的指令是否合理或合法。[3] [4]

人们有时会忘记密码或丢失用于登录的设备。服务需要提供一种方法帮助他们重新获得访问权限，但同时也必须区分合法账户持有者和试图盗用账户的人。如果重置访问权限只需要其他人可以轻易获取的信息，那么冒名顶替者甚至可能绕过强大的登录保护措施。因此，账户恢复必须为合法用户提供切实可行的恢复途径，同时又不能为攻击者提供更容易的途径。

登录只是保护账户的开始。为了避免每次操作都要求输入密码或通行密钥，许多服务会颁发一个会话标识符或访问令牌，代表已认证的会话。如果攻击者获得了此类可重用的凭据，服务就可以以已登录账户的身份接受请求，而无需再次要求输入原始登录信息。这就是会话劫持。因此，安全性取决于会话的颁发、存储、限制、过期和撤销方式，尤其是在怀疑账户遭到入侵或账户恢复之后。强大的登录保护和登录后保留的权限保护是不同的职责。[5]

社会工程学攻击的目标是决策中的人为因素。例如，恶意信息可能声称供应商已更改银行账户信息、账户必须紧急验证，或者登录页面后有文件等待查看。恶意链接可能指向以假乱真的合法服务，或者下载内容可能试图利用应用程序的漏洞。仅仅打开一个网址并不等同于泄露账户或感染计算机：最终结果取决于目标网站、浏览器和设备的防护措施、软件版本以及后续操作。关键的区别在于，网页是否通过安全连接传输，以及该网页本身是否可信。加密可以保护传输到实际访问网站的数据，但无法确定该网站是否是用户想要访问的网站。[3]

网络钓鱼并非仅仅是测试一个人能否识别可疑信息。Zhuo 及其同事在 2023 年发表的知识系统化综述（SoK）回顾了52项实证研究，并根据个人特征、情境条件以及接收信息的具体情况，梳理了与易受骗性相关的因素。该研究的综合分析并未得出普遍适用的易受骗人群画像。因此，防护措施应结合适当的身份验证、界面设计、后续指令的确认程序以及培训，而不是仅仅依靠警惕就能万无一失。[6]

配置方式既可能使系统暴露于不必要的风险，也可能缩小攻击者能够接触的范围。例如，一个原本只供某个团队使用的文件夹可能被设置为公开，一个本应仅限内部访问的管理界面可能可以从互联网访问，一个数据库可能保留了默认凭据，或者一个测试环境可能在权限限制较弱的情况下存储了真实数据。这些都是配置错误：软件可能完全按照程序运行，但其设置却允许访问或执行原本不该执行的操作。不安全的默认设置、复制的设置和累积的例外情况都会增加风险。

相反，精心配置可以缩小攻击面。这被称为安全加固：仅启用必要的服务和功能，限制其访问方式，并检查这些限制是否生效。例如，用于远程管理服务器的 SSH 服务可以限制为仅允许授权帐户和已批准的网络路径访问，配置为禁止在类 Unix 系统上直接使用 root 用户登录，并在适当情况下使用基于密钥的登录方式而非密码。如果不需要远程管理，则可以完全禁用 SSH。这些措施可以消除或缩小访问服务的途径，但无法确保剩余代码不存在漏洞。安全加固还必须保留合法访问权限，并在实际部署的系统上进行验证。[4]

凭证的范围也比密码更广。软件服务使用密钥和访问令牌进行通信，员工或承包商可能拥有强大的管理帐户。如果密钥意外泄露到代码库中、包含在日志中，或者在供应商合同结束后仍被保留，则无需尝试破解加密即可获得访问权限。如果攻击者获得必要的解密密钥或控制了有权泄露明文的服务，加密也无法阻止信息泄露。因此，保护​​存储的信息取决于密钥管理和解密访问，而不仅仅是加密算法。组织也可能赋予普通员工远超其职责所需的访问权限。正确的应对措施包括控制凭证的存储位置、限制其范围、在不再需要时撤回凭证，并能够识别可疑的使用情况。日志可以帮助确定发生了什么，但仅靠日志记录无法防止滥用，而且如果设计不当，日志本身也可能引入敏感信息。其根本问题与默认密码相同：技术上有效的凭证可能提供远远超出其颁发目的的权限。[2]

这些案例有一个共同的重要特征：被接受的凭证、看似合理的消息或宽松的设置都可能导致未经授权的操作。保护决策的有效性不仅仅在于提醒用户谨慎行事。服务可以限制猜测，将高风险权限设为例外，并为后续变更提供独立的验证。另一个难点在于如何确保这些控制措施能够有效约束实际操作，包括当更强大的组件代表另一方执行操作时。

身份、权限和委托权限

身份验证确定请求似乎来自哪个帐户或其他身份。授权决定该身份可以对特定记录或操作执行哪些操作。员工即使已正确登录，也可能无权读取其他员工的文件。知道记录编号或拥有链接本身并不构成检索记录的权限。如果系统隐藏了导出按钮，但允许底层界面自由导出相同的信息，那么它保护的是屏幕而非操作本身。所有相关路径，包括直接请求、后台作业和内部服务，都必须将必要的权限决策传递到受保护效果发生的位置。[7]

当软件利用其更广泛的权限执行调用者无权提出的请求时，就会出现“混淆代理”（confused deputy）问题。例如，记录服务可能被授权读取所有文件，而普通用户只能检索自己的文件。如果该服务在未检查调用者权限的情况下接受任何记录标识符，则可能会返回其他人的信息。用户从未获得该服务的全部权限；该服务代表用户滥用了这些权限。因此，如果一个拥有特权的中间机构可以为任何请求者获取受保护的记录，那么仅仅隔离这些记录是不够的。[8]

合理的委托接口缩小了特权组件同意执行的工作范围。它不接受不受限制的文件路径，而是接受与调用者权限相关的特定允许操作，或者接受能够证明对特定资源拥有权威性的、范围狭窄的功能。这是最小权限原则的应用：账户、组件和服务仅获得其职责所需的访问权限和操作。它还限制了错误的影响范围，即故障可能影响的信息和操作，包括其他愿意代表它执行操作的组件。一个组件可能没有直接访问私有文件的权限，但如果其请求限制不足，则可能通过功能更强大的服务间接暴露这些文件。[9] [10]

仅凭技术身份无法确定权限。合法员工可能收到篡改支付信息的欺诈指令，而真正的管理员也可能批准危险的配置。计算机可能正确验证了员工的账户，但却没有任何依据可以信任业务请求的来源。对于后果严重的更改，使用独立验证的联系方式进行确认可以确保指令来自预期方。此类程序有助于防范欺诈指令，但无法弥补应用程序中缺失的授权检查。不同的漏洞需要不同的保护措施。

另一个危险是故意滥用合法授予的访问权限。某人可能已正确登录并被允许查看敏感记录，但仍可能将其泄露给未经授权的第三方，或利用管理权限进行有害活动。身份验证和授权机制可能按配置运行，但它们无法确定个人的意图。限制权限范围、分离敏感职责、妥善记录后续操作以及独立审查可以限制或揭露此类内部人员滥用权限的行为。[11]

执行某项操作的权限并不意味着该操作在整个流程的每个阶段都有效。订单必须在满足必要的付款条件后才能进入履行阶段。仅供一次性使用的代金券不能仅仅因为每次请求格式正确且来自符合条件的账户而被重复兑换。这些都是业务逻辑上的缺陷：应用程序没有强制执行相关操作的前提条件、有效顺序或限制。此类规则必须在后续转换时根据权威状态进行检查，而不是从显示的屏幕或请求者声称的步骤中推断。即使没有竞争条件、恶意命令或被盗账户，也可能存在此缺陷。[12]

当正确的检查不再适用时

权限检查在执行时可能正确，但之后的操作却可能失效。例如，文件可能在程序打开之前被批准，但随后又被替换。两个工作进程可能都看到库存充足，然后都将其消耗掉。这些都是“检查时间与使用时间”（TOCTOU）问题：被检查的状态不再是后续操作所依据的状态。当其他方可以利用这种差距违反必要的规则时，就会出现安全漏洞。有些漏洞源于并发操作；另一些则涉及在工作进行过程中身份或权限发生变化的资源。[13]

假设有一个程序，它会检查文件路径是否在已批准的位置，然后稍后打开该路径。如果攻击者能够在这段时间内更改路径名称，程序可能会处理与已批准的文件不同的文件。补救措施是使该决定适用于实际使用的资源和状态。根据系统的不同，这可能意味着操作已打开并经过验证的文件句柄、使用原子操作或事务、持有合适的锁，或者定义撤销操作如何影响已开始的工作。重复检查而不填补下一个漏洞并不能保证万无一失。

并发性除了会导致文件访问故障外，还会导致其他相关故障。例如，如果多个单独有效的请求都基于过时的状态进行检查，则这些请求的总和可能会超过帐户限制。此外，在长时间运行的作业执行期间，权限可能会被撤销；或者，在另一个组件假定某个标识符仍然指向同一对象时，该标识符可能会被重新分配。因此，安全的设计必须明确规定哪个状态是权威状态，以及如何确保检查和后续操作的一致性。

当信息被允许指导工作时

程序会处理通过用户请求、导入文件、网络消息和其他服务提供的数据。一个值即使格式正确，也可能不适用于它所控制的操作。文件名可能指向预期文件夹之外的文件。记录标识符可能选择其他人的数据。一个很小的压缩文件在解压处理时也可能造成巨大的计算负担。将此类数据称为不可信输入意味着其特定用途所需的属性尚未确定。这并不意味着每个发送者都是恶意的。同样的缺陷也可能由故意篡改、文件损坏或普通错误造成。[14]

当数据被允许转化为指令时，就会发生危险的转变。通过将程序文本与外部值连接起来而构建的数据库查询或操作系统命令，可能会允许该外部值修改命令本身。这就是注入漏洞。类似的情况也发生在网页中，当外部提供的文本被嵌入到浏览器解释为代码而非显示为文本的内容中时。这就是跨站脚本攻击（XSS）；防止此类攻击需要针对浏览器将要解释的特定上下文来处理内容。更安全的接口会将预期操作与可变数据分开，例如在接口支持的情况下使用参数化数据库查询。解决方案并非提供一份通用的可疑字符列表：作为纯文本安全的数值，在被解释为命令、文件路径或另一种语言的一部分时，可能变得不安全。即使是正确构造的数据库查询，仍然需要单独检查请求者是否有权获取其结果。[15] [16]

有些有害输入根本不包含任何指令。例如，媒体解码器可能被要求分配超出预期的内存，复杂的文档可能消耗过多的处理时间，而重复的允许请求可能会使共享服务过载。资源限制必须在耗费资源的工作之前和期间执行，而不是在成本已经付出之后。由此导致的故障可能是受控拒绝、系统崩溃或服务对其他用户不可用。这就是为什么安全性也关注系统是否能够持续执行其合法任务。服务承诺保持可用的条件及其限制，应该与访问规则一样精确。[14]

这些故障的区别在于不受信任的信息跨越边界的位置。有时它会被解释为指令，有时它会耗尽资源，有时它会被无法安全管理自身内存的代码处理。最后一种情况值得特别关注，因为即使输入不包含任何命令，格式错误的文件或消息也可能利用程序存储和访问数据的方式进行攻击。

内存安全与编程语言的保障

每个运行中的程序都需要工作存储空间，称为内存。程序会将值存储在为其预留的区域中，使用这些值，并最终释放不再需要的存储空间。一个基本要求是，任何操作都不得读取或写入分配给它的区域之外的数据。另一个要求是，在对象的生命周期结束后，不得继续使用已分配给该对象的存储空间。这两项保护措施是内存安全的核心。它们关注的是内存操作的有效性，而不是用户最初是否拥有访问该内存的权限。

档案管理员（参见《计算机的工作原理：费曼的高速档案管理员》）提供了一个直接的类比。一个文件托盘可以容纳 100 张卡片，但一条指令要求插入 120 张。如果没有规则强制执行托盘的边界，多余的卡片可能会被放置在其他记录应该被放置的位置。在计算机中，未经检查的写入操作超出分配的区域可能会损坏无关的数据；未经检查的读取操作可能会暴露来自其他区域的信息。根据程序和周围的保护措施，后果可能从程序崩溃或结果错误到攻击者可以利用的漏洞不等。而经过检查的操作则会阻止无效访问。请求的归档任务可能会失败，但特定的边界得以保留。卡片是内存位置的隐喻，而不是声称每次溢出都会自动赋予攻击者控制权。

当程序在对象内存被释放后仍然保留对该对象的引用时，就会出现另一种内存错误。如果同一内存区域之后被另一个对象重用，那么这个过时的引用可能会读取或覆盖无关的信息。这就是释放后使用（use-after-free）错误。仅靠边界检查无法保证访问的有效性：地址可能位于已分配内存区域内，但最初使该引用有意义的对象已不存在。空间保护和生命周期保护分别针对不同的错误类型。

像 C 和 C++ 这样的老牌系统语言广泛使用，它们允许进行直接内存操作，但程序员必须为此设定必要的边界和生命周期规则。这种控制使得重要的软件得以开发，但沿着不安全路径执行的错误可能非常严重且难以检测。谨慎的实现、代码审查、自动化分析、保护性编译器选项和测试可以降低风险；但它们并不能保证每次执行都是安全的。此外，在产品中发现 C 或 C++ 代码也并不意味着该产品存在漏洞。真正重要的问题是：处理相关输入的特定代码，它使用了哪些检查或保护措施，以及如果发生错误，该代码拥有怎样的权限。

内存安全的语言机制将部分负担转移到语言或其运行时强制执行的规则上。例如，安全的 Rust 会在程序运行前拒绝许多无效引用，并根据需要检查索引访问。普通的 Swift 安全机制会强制执行边界和托管生命周期约束。Python 应用程序代码通常操作托管对象，而不是执行原始指针运算。这些语言并不能消除做出正确安全决策的必要性，而且它们的保护措施也不一定能覆盖所有原生组件。Rust 有显式的不安全区域；Swift 可能会调用 C 库或使用不安全指针；Python 可能会加载原生扩展。将数据传递给内存不安全代码的内存安全应用程序，也需要检查该边界及其之外的代码。语言的选择会改变重要的风险类别，但产品的评判标准必须基于其实际执行的操作。[17] [18] [19]

Szekeres、Payer、Wei 和 Song 在 2013 年发表的 SoK 论文中探讨了内存损坏攻击的演变过程以及不同的防御措施试图阻止哪些攻击。他们的分析区分了阻止无效内存操作、检测损坏以及在缺陷发生后增加利用难度这三种方法。这些是本质上不同的保障措施。该论文发表于较新的编译器和硬件缓解措施出现之前，但其分类解释了为什么阻止某种攻击技术并不能证明底层内存缺陷已被消除。[20]

更安全的语言固然有所帮助，但现有系统不可能在一夜之间被完全替换。C 和 C++ 深深嵌入操作系统、固件和专用库中，其中许多都面临性能、硬件或兼容性方面的限制。重写这些库可能会引入新的缺陷，而且团队需要具备相应的技能和工具来验证替代方案。但这并不能成为无限期接受不安全内存处理的理由。实际评估的关键在于：不受信任的数据在哪些环节会未经检查地进入操作？哪些原生依赖项仍然存在？这些组件拥有哪些权限？以及测试、缓解措施和维护如何应对这些风险？仅仅依靠语言标签无法解答这些问题。[2]

当设计本身存在安全漏洞时

设计漏洞的严重程度丝毫不亚于内存处理或沙箱机制缺陷。当系统预期的规则或工作流程允许有害结果时，即使软件本身正确地遵循了这些规则，设计漏洞依然会出现。内存安全的代码、精心限制的组件以及强大的加密都无法弥补设计缺陷，因为这种缺陷会将受保护的操作权限授予错误的人员。

设想一个虚构的加密备份服务。它的恢复功能要求用户登录，但随后会返回用户提供的任何备份标识符对应的恢复密钥，而不会检查该备份是否属于该用户。一个拥有普通账户的攻击者，只要得知其他用户的标识符，就能获取该用户的密钥。加密并未被破解，内存未被破坏，沙箱也未被突破。系统之所以会泄露密钥，是因为其设计中根本没有设置必要的授权检查。

密码学提供了另一个将正确的安全保障应用于不完整的安全决策的例子。加密可以保护计算机之间传输的信息，而无需确定另一端是哪个服务，也无需确定是否应该接受请求。这些都需要单独的检查。协议规定了通信系统预期使用的消息和检查；实现则是遵循这些规则的软件。实现可能会省略必要的检查，而协议本身也可能遗漏必要的要求。因此，一项安全保障措施的正确运行并不能保证整个操作的安全性。[21]

设想一个程序连接到某个网站。它可能建立加密连接并接受来自受信任颁发机构的证书，却不去检查该证书是否指向它想要访问的网站。加密虽然有效，但程序可能正在与冒名顶替者通信。类似的错误也发生在签名访问令牌上，这是一种数字凭证，某些服务用它来决定是否接受请求。程序可能验证了令牌的签名，但没有检查它是否来自受信任的颁发机构、是否是为该服务准备的，以及是否仍然有效。在这两种情况下，一项正确的检查导致另一项必要的判断无法完成。这两种故障都不需要加密失效或签名伪造。罗斯·安德森的《为什么密码系统会失败》一书探讨了密码保护与实际系统故障之间更广泛的差距。[22] [23] [24]

Clark 和 van Oorschot 于 2013 年发表的 SSL 与 HTTPS 安全知识系统化综述（SoK）调查了证书颁发、浏览器信任决策和基础设施实践如何影响加密连接的安全性。他们的研究将身份和证书信任置于更广泛的系统中进行考察，而不是将加密本身视为足够的安全措施。该研究考察的是当时的机制，而不是当今的 TLS 部署或后续引​​入的保护措施；当前的实现需要根据现行标准进行评估。[25]

秘密信息也可能通过并非有意为之的行为泄露。不同的错误信息可能揭示账户是否存在。如果检查所需时间因秘密信息而异，且这种差异能够被可靠地观察到，则可能通过时间侧信道泄露信息。这些泄露事件可能无需直接请求秘密信息或加密算法被破解即可发生。并非所有可测量的差异都可被利用；信号、条件以及可推断的信息都至关重要。[26]

安全机制与普通故障处理不同，因为攻击者可能会故意制造设计者认为不太可能发生的状况。例如，他们可以反复尝试格式错误的输入、异常的请求序列或被破坏的依赖项，直到找到一条能够产生预期效果的路径。常规测试可以展示已知案例的行为，但并不能排除所有恶意组合。关键在于，当某个假设失效时，哪些安全措施仍然有效。

设计漏洞也可能存在于协议本身：即使协议规则存在重放、重定向或滥用等漏洞，实现也可能忠实地遵循这些规则，从而导致原本有效的消息被滥用。Ross Anderson 和 Roger Needham 在《Programming Satan’s Computer》一书中探讨了这种对抗视角。[27] 即使是正确定义和实现的软件，也依赖于硬件来维护其预期的边界。

当硬件本身存在漏洞时

软件依赖于硬件来强制执行基本限制。一个程序不应该能够修改另一个程序的受保护内存，处理器限制的信息应该保持不可访问状态，设备应该从可信状态启动。但是，处理器、内存芯片以及启动设备的底层代码本身都是复杂的工程系统。即使其上层的应用程序编写正确，它们的行为也可能破坏安全规则。

⚠️ Rowhammer漏洞揭示了一种意想不到的物理弱点。在某些内存芯片中，反复访问特定的内存位置会干扰相邻的存储单元，导致存储的位发生变化。而这些变化并非由软件请求的。研究人员已经证明，在易受攻击的系统中，在特定条件下，这种效应可以被利用来绕过内存保护机制，从而获得更高的权限。即使程序遵守了写入权限的规则，物理内存仍然可以修改超出这些限制的信息。Rowhammer漏洞并非对所有内存设计都产生相同的影响，其实际可利用性和缓解措施取决于硬件和系统。[28] [29]

⚠️ 其他硬件漏洞可以在不改变信息的情况下泄露信息。现代处理器有时会预先执行一些工作，预测需要哪些指令以节省时间。这被称为推测执行。如果预测错误，暂定结果会被丢弃，但这些工作的痕迹可能会保留在缓存中。缓存是一个小型存储器，可以帮助处理器快速检索最近使用的信息。测量这些痕迹有时可以揭示程序无权读取的秘密信息。Spectre 漏洞利用了操纵预测结果来诱发此类泄露；Meltdown 漏洞则利用了某些处理器在访问违规生效前处理受保护数据的方式上的另一个漏洞。这些是处理器侧信道，与前面描述的时序泄漏相关。它们涉及处理器内部如何执行指令，而不仅仅是描述软件可能请求哪些操作的已发布指令集。受影响的处理器、条件和应对措施各不相同。[30] [31] [32]

安全漏洞也可能在操作系统启动之前出现。安全启动通过检查启动的各个阶段是否在运行前获得授权来建立信任链。某些设备将最早的启动代码存储在只读存储器 (ROM) 中，ROM 通常在制造完成后不可重写。这使得后续篡改更加困难，但也意味着原始验证或恢复例程中的缺陷可能无法在 ROM 中修复。

⚠️ 2018 年披露的 Fusée Gelée（Tegra X1 恢复模式漏洞）表明，该漏洞可通过物理 USB 访问，而非远程网络服务。软件更改和操作限制可以降低风险，但它们无法重写真正不可更改的启动 ROM。安全启动在其信任根的保证和其涵盖的攻击条件下仍然具有价值。[33] [34] [35]

⚠️ Glosner 和 Machiry 在 2026 年的 SoK 研究中分析了硬件信任根完成交接后、软件启动链中的 43 个引导加载程序。其 BOOTBENCH 数据集收集了 3,658 个已报告的漏洞及其相关变更，作者还指出了现有检测和加固技术的局限性。这些数据并不能证明每个引导加载程序都可被利用，也不能证明任何特定设备存在漏洞。它们表明，验证引导软件是否来自授权来源与验证授权实现是否存在可利用的缺陷是不同的。[36]

硬件体现了单层安全保障的局限性。应用程序的安全性部分取决于处理器的内存安全机制、启动链以及所宣称的硬件保护措施的实现。这些依赖关系并非意味着硬件防御毫无意义；它们只是界定了软件可以依赖这些防御措施的条件。

在失败扩散之前将其遏制住

安全工程还能限制未预防缺陷造成的后果。处理不熟悉的文件格式的程序不应自动获得与调用它的应用程序相同的访问权限，例如访问私有记录、网络服务和强大的操作。操作系统可以强制执行运行进程之间的边界，并限制它们的权限。沙箱就是一组这样的强制限制。关键问题在于，哪些运行组件被禁止访问哪些资源。将文件放在单独的源文件夹中、通过不同的编程语言调用函数或将库描述为隔离的，这些本身并不能建立操作系统边界。[10]

加载到主应用程序中的原生解码器通常会与该应用程序共享进程、内存和大部分权限。将解码操作移至单独的进程，可以为工作进程提供独立的地址空间。对该工作进程施加额外的、适当的限制，可以减少缺陷或安全漏洞直接影响的范围。两种版本都可以运行在同一个外部应用程序沙箱中；额外的保护来自工作进程自身的边界和权限。这种安排会增加通信、超时和恢复方面的开销，并且宿主仍然需要检查工作进程的结果。一个可以向宿主请求任意特权文件操作的受限工作进程，可能会在进程边界之外重现“混淆代理”问题。

关于这些边界在实践中如何成功或失败，已有大量研究。Lefeuvre 及其同事在 2025 年的 SoK 分析了 211 项研究成果和 61 个主流的隔离系统。该研究指出，在定义可用的隔离策略、将研究成果转化为生产应用以及评估涉及混淆代理和硬件限制的威胁方面，仍然存在诸多难题。如果一个进程的权限过大，或者特权主机对其发出的不受限制的请求做出反应，那么即使该进程是独立的，也不能证明其隔离措施有效。相关的工程任务是定义接口两侧可用的权限，并证明强制执行的边界与该设计相符。[37]

隔离机制体现了一个普遍原则：预防和损害控制各有侧重。输入检查旨在阻止有害操作的发生。内存安全规则阻止某些无效访问。沙箱机制限制了故障代码可以访问的资源。监控和恢复机制帮助服务识别并响应仍然可能发生的故障。多种保护措施可以减轻单一错误造成的后果，但它们的独立性必须得到证实，而不是想当然地认为它们彼此独立。因此，即使缺陷被成功利用，也可能仅限于某个受限组件；它并不会自动授予对系统所有部分的访问权限。诚实的安全声明应明确指出禁止的后果以及强制执行相关限制的机制，而不是罗列技术或大肆宣传“安全”二字。[38]

⚠️ 隔离和硬件保护的局限性

有些保护措施看似独立，因为它们名称和设置各不相同，但实际上却依赖于同一权威机构。应用程序沙箱、进程隔离和强制访问控制通常都依赖操作系统内核来强制执行其限制。内核是管理程序、内存和权限的核心组件。如果攻击者获得了对内核的足够控制权，就可能更改或忽略这些保护措施所依赖的规则。多层保护并不一定意味着多道独立的防线。[39]

硬件支持的缓解措施可以增加内核被攻破的难度。指针认证 (PAC) 对选定的指针进行签名和认证，从而挫败一些依赖于破坏指针的控制流攻击。在支持内存完整性强制执行 (MIE) 的 Apple 系统中，硬件内存标记、类型化分配和相关的操作系统限制可以阻止各类内存损坏攻击，包括针对受保护系统代码的攻击。然而，一旦攻击者获得了对内核的足够控制权，这两种机制都无法独立维护应用程序沙箱策略。[40]

某些保护措施在内核的常规控制之外运行。在受支持的 Apple 系统上，安全页表监视器 (SPTM) 与可信执行监视器配合使用，即使攻击者已获得内核写入权限，也能限制对页表的特定修改。这些是硬件支持的、范围较窄的内存和代码完整性限制，并非持续信任内核对用户、文件或网络访问的决策。哪些属性会持续存在取决于平台和攻击者的能力。[39]

安全隔区 (Secure Enclave) 是独立安全边界的一个例子。在支持的苹果设备上，它是一个安全处理器，拥有独立的安全启动、受保护的内存和微内核。它的设计目的是即使主操作系统内核遭到入侵，也能保护选定的机密信息。应用程序可以为安全隔区处理的操作生成私钥，并请求执行允许的加密操作，而无需接收密钥本身。哪些信息仍然受到保护取决于密钥的访问策略以及安全隔区负责执行的操作，而不仅仅是芯片的存在。[41] [42]

其他系统使用不同的硬件强制边界。可信平台模块 (TPM) 可以作为独立设备或集成在处理器中，用于保护选定的加密密钥，并可将其使用与系统启动方式的度量绑定；它并非运行应用程序代码的通用环境。Arm TrustZone 在支持的处理器上分离安全执行状态和正常执行状态，因此，如果系统设计正确，指定的软件和资源可以对普通操作系统保持不可访问状态。Intel 软件保护扩展 (SGX) 在支持的处理器上，将选定的应用程序代码和数据隔离在安全飞地中，使其与包括操作系统内核在内的特权软件隔离。与 Apple 的安全飞地不同，TrustZone 和 SGX 不需要单独的安全处理器。它们保护的资源也不同，不能互换使用。[43] [44] [45]

保持部分安全权限独立于主内核，也有助于在内核遭到入侵后恢复平台信任。一个不受内核控制的可信启动或恢复路径，可以在设备恢复服务之前检查授权的固件和操作系统软件。受保护的密钥和启动过程的测量数据可以支持这些检查。NIST区分了用于检测未经授权的更改、批准更新和恢复损坏的平台固件的信任根。这些要素必须组合成一个有效的恢复过程：TPM、安全隔区、TrustZone环境或SGX隔离区本身并不能恢复受损的操作系统。[35] [38]

只有在特定的威胁模型下，这种恢复才有可能发生。恢复固件、硬件信任根和替换软件的来源本身必须保持可信。在被入侵的内核被替换之前，即使某些密钥或安全区内存仍然无法访问，攻击者仍然可以操纵对安全组件的请求、拒绝服务或在保护之前或之后检查信息。恢复无法撤销已泄露的信息。区别在于，前者是在入侵期间保护选定的状态，而后者是在入侵后重建可信操作。

Zinkus、Jois 和 Green 在 2022 年的 SoK 报告中探讨了移动设备上的数据保密性，以应对强大的窃取攻击者，包括那些能够物理访问设备或相关云服务的攻击者。该报告的范围比密钥保护更为广泛：信息在加密之前、解密之后或通过依赖服务也可能被泄露。这项历史分析并不能验证当前的 SPTM 或安全隔区行为。它强调了明确哪些信息受到保护、能够抵御哪些攻击以及信息在哪些方面超出可信边界的必要性。[46]

内核相关保护的局限性

SPTM 可以在内核被攻破后保留选定的内存限制，而安全隔区可以保护指定的密钥。但两者都无法单独恢复操作系统信任。

iPhone 可能支持 MIE 和 PAC，但这并不意味着其上运行的每个应用都会同时使用这两种保护措施。Apple 会自动在选定的系统攻击面上部署 MIE，包括内核。但这种保护并不会自动扩展到每个第三方应用、扩展程序、辅助进程或库。因此，同一台支持 MIE 的 iPhone 上的两个应用可能具有不同的保护措施。MIE 结合了 Apple 设计的硬件、安全内存分配器和操作系统控制；它并非简单的通用 Arm 内存标记扩展 (MTE)。

要在自己的应用程序中使用硬件内存标记，开发者必须为相关的 Xcode 目标启用该功能，并确认硬件支持该功能。授权和运行时设置也至关重要：报告模拟故障的诊断模式与强制执行检查并不相同。PAC 是另一种独立的缓解措施。仅兼容的硬件并不意味着每个应用程序二进制文件都使用 PAC；相关代码必须针对相应的 arm64e 架构构建，并且外部原生库需要兼容的版本。开发者应验证实际版本（包括其组件和依赖项）中启用了哪些保护措施，并在受支持的物理设备上进行测试。设备规格并不能证明特定应用程序中的保护措施正在运行。[47] [48] [49]

架构图或功能列表无法确定已发布产品中哪些安全措施有效。相关的证据是：哪些流程实际受到保护，哪些机构负责执行每项限制，以及在所考虑的故障情况下，哪些内容仍然受到保护。

当安全措施失效时

即使必要的检查或操作失败，安全限制仍然必须有效。如果授权服务不可用，未能获得决策并不意味着可以继续执行。如果多步骤变更操作中途停止，部分更新的记录可能违反该操作旨在维护的规则。必须针对特定任务定义响应：拒绝或延迟未经验证的操作、保持一致的状态以及使中断的工作可恢复。将错误视为批准是一种失效时放行（fail-open）缺陷；将每个错误都视为永久性中断也不是一个合理的设计。[50]

入侵并不一定止步于第一个被攻破的账户或进程。攻击者可以利用这个立足点获取更高的权限（称为权限提升），或者进入其他系统（称为横向移动）。每一步都依赖于另一个可用的漏洞、凭证或信任关系；控制一个服务并不意味着自动控制其相邻服务。因此，初始立足点的权限、系统间的隔离程度以及对特权请求的检查决定了攻击的扩散范围。即使第一个组件已被攻破，隔离措施也可能阻止攻击的进一步发展。[51] [52]

当预防和遏制措施不足以应对攻击时，运营恢复就显得尤为重要。攻击者一旦获得管理权限，便可能篡改记录、删除文件或部署勒索软件，导致数据无法使用。备份可以减轻破坏或损坏造成的损失，但无法撤销已被窃取的信息。即使备份文件仍保留在被入侵的权限下，也可能被攻击者篡改或删除。因此，可恢复的、受到适当保护的副本以及验证恢复效果的演练，与安全补丁同样重要。监控可以检测异常活动并保存证据；事件处理流程明确规定了哪些人员可以隔离受影响的系统、撤销凭据以及恢复可信赖的服务。这些措施并非承认安全设计存在缺陷。它们表明，保护系统包括尽可能减少故障造成的损失，并将合法工作恢复到已知良好的状态。[38]

当供应链破坏安全时

即使是小型应用程序也依赖于他人编写、构建和维护的软件：操作系统组件、库、开发工具和外部服务。只有当受影响的版本存在且相关操作暴露时，报告的缺陷才可能重要，但要确定这一点可能很困难，因为依赖项的维护计划各不相同。因此，产品名称并不能说明其运行实际涉及的组件和服务。[53]

一个恰当的类比是成分清单。如果制造商无法识别产品成分，就很难确定新发现的问题是否与该产品相关。软件也面临同样的难题。软件物料清单（SBOM）记录组件及其版本，以提高可见性，包括通过其他依赖项获得的依赖项。它可以帮助组织判断是否存在已报告的易受攻击的库，但它并非安全证书。清单可能不完整，易受攻击的代码可能永远无法访问，或者某个组件在一个版本中缺失，却可能出现在下一个版本中。只有当清单得到维护，并与实际部署的内容关联起来，且有相应的流程来评估和修复受影响的系统时，它才能发挥作用。[54]

Abu Ishgair 及其同事在 2026 年发布的《软件知识体系》（SoK）中使用了 AStRA 模型来考察软件生产和分发过程中涉及的参与者、步骤、资源和工件。该模型区分了软件业务手册（SBOM）可以回答的问题和需要有关源代码变更、构建完整性、发布权限和交付的证据的问题。完整的清单并不能证明构建是可信的，而来源信息也不能证明最终程序没有缺陷。证据必须与正在评估的特定供应链风险相匹配。[55]

了解哪些组件存在并不能保证其内容或分发方式可信。攻击者可以将恶意行为引入依赖项、源代码库、构建过程或软件更新中，从而使用户在看似合法的版本中收到有害代码。这属于软件供应链入侵，与意外发现组件漏洞截然不同。检查软件包的来源和完整性有助于检测未经授权的替换，但即使是正确签名的版本，如果供应商或其构建过程遭到入侵，也可能包含恶意代码。因此，保护​​软件交付还需要控制哪些人可以更改代码和版本、如何处理构建凭证以及哪些证据可以将交付的工件与其预期来源关联起来。软件物料清单 (SBOM) 仅识别组件，并不保证其内容或交付路径的安全性。[53]

软件并非直接从程序员的编辑器传输到用户的设备。代码会经过维护者、代码库、构建工具、自动化服务、签名密钥、发布审批人和分发渠道。即使审查员检查了源代码，也可能忽略打包过程中引入的恶意更改；如果入侵者能够授权构建内容，那么即使是严格控制的构建工具也几乎无法提供任何保护。分离并验证这些职责至关重要，因为一个看似合法的版本可能在最终用户看不到的步骤中被篡改过。[56]

2024 年的 xz Utils 后门以异常清晰的方式暴露了这个问题。恶意代码被隐藏在发布版本中，并被设计成影响某些 Linux 软件包的构建，从而可能破坏具有特定依赖项的系统的远程登录认证。分发的发布版本并非简单地等同于审查人员在公共仓库中可能看到的源代码：构建过程决定了最终软件中包含的内容。该攻击在受影响版本在稳定的 Linux 发行版中普及之前就被发现，但它表明，看似获得授权的上游版本可以将故意引入的恶意功能带入下游软件包。这就是为什么仅仅信任一个熟悉的项目或其官方下载路径是不够的。这是一起软件供应链遭入侵事件，而非偶然的编程缺陷。[57] [58]

构建溯源旨在将交付的可执行文件与其源代码、工具、设置和服务关联起来。当独立方从同一源代码生成匹配的结果时，可复现的构建可以提供额外的证据。诸如 SLSA 之类的框架描述了记录和验证此历史的方法。但是，记录的可信度取决于生成它的系统以及用于验证它的独立预期。被篡改的源代码可以复现构建；损坏的构建服务可能会产生虚假的保证；未经验证的签名声明意义不大。溯源可以建立监管链的部分内容，但无法证明底层软件的行为是否安全。[59] [60]

发布签名和分发构成了一个独立的边界。有效的数字签名可以证明某个工件已使用特定密钥签名，且签名后未发生更改。但它无法证明签名者可信、密钥未被盗用或签名程序安全。已签名的发布版本是密钥授权的证据，而非安全证书。HTTPS 可以保护与下载网站的连接；但它并不能保证网站、其发布者帐户或下载本身未被入侵。在同一被入侵页面上显示的校验和几乎无法提供独立的保证。因此，安全的更新系统还会验证预期的发布者、可信的元数据、版本和授权的签名机构，并防止回滚到旧的易受攻击的版本。这些检查可以减少特定攻击，但并不能消除信任和保护发布流程的必要性。[61]

硬件供应链引入了一个更难检查的相关问题。芯片可能始于经过仔细审查的设计，然后整合其他供应商提供的电路或设计组件，并经历制造、测试、封装、运输和集成等环节。理论设计或许合理，但这并不能保证交付给客户的芯片与设计完全一致。理论上，能够访问相关环节的攻击者可以在制造或交付过程中更改电路、植入隐藏的硬件木马、替换组件或篡改相关固件。这些都是需要评估的已知威胁，但并不能证明特定制造商或设备已被攻破。[62] [63]

经过验证的蓝图并不等同于经过验证的芯片。检查正常运行、测试样品、审查生产记录、使用可信赖的供应商、维护保管记录以及验证组件，这些都能加强硬件的可靠性。但是，罕见的或故意隐藏的电路行为可能会逃过常规测试，而且设备自身的身份或认证机制依赖于硬件和密钥，而这些硬件和密钥的来源也必须可信。安全启动只能在验证的初始阶段可信的前提下，验证后续软件。没有任何单一的证书或检查能够证明整个链条中不存在恶意篡改。[62] [63]

维护与争分夺秒的漏洞修复

更新尤其值得关注，因为它们通常会修复一些已被充分了解、足以修复的缺陷。一旦漏洞细节公开，攻击者可能会寻找仍在运行受影响版本的系统。有些漏洞甚至在修复程序发布之前就已被利用。因此，延迟更新可能会使系统暴露于攻击者无需进行任何原始研究即可利用的攻击方法之下。必要的工作远不止点击更新按钮：组织必须了解其拥有哪些计算机和服务、它们运行的​​版本、是否存在厂商提供的修复程序、受影响的功能是否已暴露以及变更是否已成功部署。已停止厂商支持的设备和服务则会带来不同的问题，因为可能不再提供任何安全修复程序。[64]

更新责任不仅限于操作系统、浏览器、路由器、插件、服务器软件和固件等显而易见的应用。消费类设备可能自动更新，但企业也运营着一些不常用的机器、沿用下来的服务以及版本信息不明显的第三方系统。这些系统版本信息往往容易被忽略，因为它们看起来运行正常。准确的清单、明确的负责人以及更新已到达运行系统的证据，能够区分补丁程序和已发布的修复程序列表。

报告漏洞并不等同于修复漏洞。响应的关键环节是漏洞研判与处置优先级评估：查明受影响的软件是否存在、漏洞部分是否可以访问、攻击者可能利用该漏洞做什么，以及是否已有人在利用该漏洞。这有助于确定问题的紧迫性、需要采取行动的人员以及仍需核查的证据。严重性评分可以提供帮助，但它本身无法确定特定产品面临的风险。当出现新的事实或软件变更时，必须重新评估分级结果。如果漏洞已被利用，则可能需要在评估完成之前就开始采取保护措施。[65]

有时，漏洞尚无修复方案。即使很快发布了修复方案，也必须针对产品进行检查，测试以避免破坏重要功能，并在用户实际使用的版本中进行交付和验证。在此期间，已知的漏洞仍可能被利用。可能需要限制访问权限、禁用受影响的功能、隔离服务，或者在必要时将其离线。必须监控和审查这些临时措施，直到缺陷得到修复。安装补丁也无法撤销可能已经发生的攻击。[65]

攻击者的行动速度可能比修复程序到达需要修复程序的用户的速度更快。Mandiant 在对实际观察到的漏洞利用进行的研究中报告称，2018-2019 年的平均漏洞利用时间为 63 天，2021-2022 年为 32 天，2023 年为 5 天。其 2026 年的报告估计 2025 年的平均漏洞利用时间为负 7 天（−7 天），这意味着在研究案例中，首次观察到的漏洞利用平均早于补丁的发布。这些数据是针对特定已利用漏洞的测量结果，并非每个漏洞的利用时间线，也不是衡量客户安装更新速度的指标。零日攻击会影响平均值。此外，这种加速趋势早在当今的生成式人工智能系统出现之前就已经开始。[66] [67] [68]

人工智能辅助分析加剧了这场本已异常激烈的竞争。已发布的补丁或源代码变更可能会揭示易受攻击版本与其替代版本之间的区别。自动化工具可以帮助比较版本、开发候选测试用例并识别暴露的系统，从而减少追踪已知漏洞所需的工作量。2024 年的一项研究表明，在受控条件下，基于 LLM 的代理程序在给定漏洞描述的情况下，可以利用多个先前已披露的漏洞。2026 年 9 月，谷歌威胁情报报告称，观察到先前已披露的高风险漏洞利用事件有所增加，并将人工智能辅助分析列为可能的促成因素，但这并不能证明人工智能导致了所有事件。[69] [70]

这种能力并非仅限于运营商可以监控或限制请求的模型服务。一些功能强大的语言模型以可下载的权重发布，可以在其创建者控制范围之外运行或修改；它们的安全措施可能缺失、更改或移除。2026 年的公开评估发现，在网络安全任务中，开放权重模型的功能越来越强大。但这并不意味着每个模型都是有效的攻击者，也不意味着每个已知的漏洞都容易被利用。人工智能还可以帮助防御者审查代码、发现缺陷并准备应对措施。改变的是搜索漏洞的成本和潜在速度，包括那些无需遵守模型提供商限制的攻击者。[71] [72]

发布修复程序并不意味着用户已经收到。下游维护者、分发商和运营商可能仍需要集成、测试、批准和部署该变更。攻击者可以寻找遗留的安装，而仓促部署可能会造成新的故障。因此，快速故障排查、临时保护和验证部署是相辅相成的责任，而非相互冲突的替代。

安全设计之所以重要，恰恰是因为漏洞披露到修复部署之间的风险窗口并非总能消除。内存安全代码可以防止某些类型的内存错误；严格的权限控制和独立的沙箱可以限制受损组件的访问权限；输入和资源限制可以增加其他攻击的难度。这些保护措施在漏洞被发现之前以及在准备和测试修复程序期间都发挥着作用。承受某些故障、限制损失并进行恢复的能力是安全韧性的一部分；为应对这种情况而设计的系统也被称为能够在故障下维持或恢复必要功能。但这并不能证明存在漏洞的软件是安全的，也永远不能取代修复和验证缺陷的工作。[38]

外包并不能免除这些责任。供应商可以构建应用程序、运营云服务、管理办公设备或维护网站，而委托方仍然需要决定自身能够承担的风险水平。有些供应商能力强、管理严谨；而有些供应商则将有限的精力分散到过多的客户身上，或者在初始交付之后几乎没有提供任何维护证据。真正的问题不在于外部承包商的存在，而在于这种安排下，没有人能够清晰地识别系统的依赖关系、批准访问权限、发现缺陷、应用变更、验证版本发布，或者在出现问题时做出响应。合同、服务说明和标识可以帮助明确预期，但可观察的维护和责任归属远比空洞的措辞更为重要。[2]

开源软件提供了一种宝贵的审查机制，因为其代码可以被原始开发团队以外的人员检查和质疑。然而，许多人都能检查代码的说法并不能保证有足够多的合格人员真正参与其中，也不能保证已报告的缺陷能够得到及时解决。开源项目的规模各不相同，从资金雄厚的组织到维护广泛使用组件的小型团队都有；专有软件在审查和维护方式上也存在很大差异。PHP 2026 年 10 月的安全更新就体现了这种区别。在修复了两个关键漏洞后，PHP 基金会解释了由于技术上的权衡取舍困难、经验丰富的维护人员数量有限以及其决策流程，导致一个底层问题的修复工作被延误。基金会也肯定了受资助的工程师和外部研究人员在完成修复工作中所发挥的作用。这些漏洞涉及资源耗尽后的内存损坏以及请求间内部状态的过时，将之前讨论的内存和错误处理机制与修复广泛使用的运行时所需的专业维护联系起来。重点并非开源软件本质上更弱，或者封闭产品更安全。源代码的公开为审查提供了机会，而持续的专业知识、明确的责任和有效的维护则将审查结果转化为保护措施。[73]

软件还需要根据其实际使用环境进行测试。成功演示主要功能并不能说明当错误的账户请求记录、两个操作竞争、文件格式错误或特权辅助程序收到意外命令时会发生什么。安全验证会检查已定义的要求在实际部署的版本和配置中是否得到满足。它可以将代码和依赖项审查与禁止操作和合法操作的测试以及故障恢复测试相结合。测试无法证明不存在漏洞，开发人员计算机上的测试结果也可能无法确定已发布产品的限制。反之，没有公开审计并不能证明服务不安全。可信的证据应具体说明检查了哪些内容、使用了哪个版本和配置、发现了什么以及哪些方面仍不确定。[2]

如何判断安全警告

新闻报道经常将几种不同的情况混用到同一套耸人听闻的词汇中。弱点是指在某些情况下可能造成损害的缺陷或不安全状况。漏洞是指可以用来破坏安全属性的弱点；利用漏洞则是利用该弱点的方法。声称某个缺陷允许远程代码执行，意味着在特定条件下，攻击者可以使软件执行代码。但这本身并不能证明某个特定组织遭受了攻击或其所有数据都被窃取。已确认的入侵事件是未经授权的访问或其他破坏性事件发生的证据，尽管其全部影响可能仍在调查中。严重性标签、漏洞利用演示和事件调查结果回答的是不同的问题，不应被视为同义词。

公开的漏洞标识符（通常以 CVE 编号表示）有助于不同组织讨论同一个已报告的漏洞。它并非每个受影响安装的记录，也不能证明漏洞已被成功利用。严重性评分使用既定的评分模型来评估漏洞的特征；实际操作的紧迫性仍然取决于环境以及攻击者能够触及的范围。术语“零日漏洞”通常用于描述在有效修复程序发布之前或防御者知晓漏洞之前就被利用的漏洞，尽管报告惯例各不相同。它的意义在于防御者提前修复漏洞的机会有限，而非名称本身的神秘性。即使漏洞存在多年且已发布补丁，但如果攻击者利用从未更新的暴露机器来攻击该漏洞，仍然可能构成紧急威胁。[74] [75]

判断实际严重性的首要因素是漏洞可触达性。攻击者必须已经对一台锁定的机器拥有物理控制权，而攻击者只需向公共服务发送请求，两者面临的情况截然不同。一个很少使用的可选功能中的漏洞与一个面向互联网的服务中的相同漏洞也存在差异，尽管两者都可能需要修复。第二个因素是权限：后果取决于受影响的代码是否能够读取公共信息、访问私人记录、更改帐户、运行命令或通过委托服务影响管理员。第三个因素是暴露情况和证据：受影响的版本必须实际存在，易受攻击的路径必须在相关条件下可用，并且实际利用的报告比单纯的理论可能性更具直接意义。[1]

补救措施是第四个因素。供应商可能已经发布了修复程序，服务可能已经部署了修复程序，或者组织可能仍在调查哪些系统受到影响。补丁可以暂时消除缺陷，但无法证明每个可能受损的系统都已得到检查。如果漏洞利用发生在修复之前，则可能还需要进行调查、更改凭证并恢复可信状态。可信的声明能够区分已发现的漏洞、已阻止的攻击尝试、已确认的未经授权的访问以及已实际确定的损害。在事件发生期间，不确定性是正常的；没有证据支持的确定性不能代替证据。[65]

这些区别也使得评估供应商和承包商的安全声明变得更加容易。维护良好的组件清单、明确的补丁所有权、有效的版本测试、受控的特权访问以及可行的事件响应流程，比承诺完全安全更有说服力。无论这项工作是由大型科技公司、小型开发团队还是外部机构完成，同样的问题都适用。组织规模既不能证明其能力，也不能证明其疏忽。重要的是能够识别问题、解释问题的影响范围、纠正问题，并确保纠正措施已应用于人们实际依赖的系统中。[2]

总结

软件安全之所以困难，是因为即使操作在技术上有效，也可能在错误的情况下发生。例如，系统可能接受冒名顶替者提供的密码，特权服务可能被未经授权的调用者利用，检查机制可能失效，恶意数据可能被解读为代码，或者内存缺陷可能绕过其他地方强制执行的规则。依赖关系、构建过程、固件和维护工作都增加了安全措施缺失或失效的可能性。每次故障都有不同的原因，因此，要确保安全，就必须了解攻击者从施加影响到最终导致后果的整个路径。

最有效的安全声明应具体明确。它们应明确指出哪些内容必须受到保护、攻击者具备哪些能力、受影响的组件可能执行哪些操作、哪些安全措施独立运行，以及哪些证据来自对已发布配置的测试。此外，它们还应解释如何监控依赖项、如何对已报告的漏洞进行分类、如何在准备更新时限制风险以及如何验证部署。开发人员和运维人员仍然有责任提供这些保护措施。依赖该软件的用户无需成为安全研究人员，即可寻求可信的答案，而不是仅仅接受标签、证书或成功的演示作为证明。

你应该知道的事情：

参考文献

文中引用了编号的参考文献。n.d. 表示未注明出版日期。

1. National Institute of Standards and Technology (2012). Guide for Conducting Risk Assessments. NIST Special Publication 800-30 Rev. 1. DOI: 10.6028/NIST.SP.800-30r1.
2. National Institute of Standards and Technology (2022). Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities. NIST Special Publication 800-218. DOI: 10.6028/NIST.SP.800-218.
3. OWASP Foundation (n.d.). Authentication Cheat Sheet. OWASP Cheat Sheet Series.
4. Cybersecurity and Infrastructure Security Agency and Federal Bureau of Investigation (2025). Product Security Bad Practices: Updated Guidance. CISA/FBI advisory, 17 January 2025.
5. OWASP Foundation (n.d.). Session Management Cheat Sheet. OWASP Cheat Sheet Series.
6. Zhuo, S., Biddle, R., Koh, Y. S., Lottridge, D. and Russello, G. (2023). SoK: Human-centered Phishing Susceptibility. ACM Transactions on Privacy and Security, 26(3), Article 24. DOI: 10.1145/3575797.
7. OWASP Foundation (n.d.). Authorization Cheat Sheet. OWASP Cheat Sheet Series.
8. Hardy, N. (1988). The Confused Deputy (or Why Capabilities Might Have Been Invented). ACM SIGOPS Operating Systems Review, 22(4), pp. 36–38. DOI: 10.1145/54289.871709.
9. OWASP Foundation (n.d.). Authorization Patterns Cheat Sheet. OWASP Cheat Sheet Series.
10. The Chromium Project (n.d.). Sandbox Design. Chromium design documentation.
11. National Institute of Standards and Technology (n.d.). Insider Threat. NIST CSRC Glossary.
12. OWASP Foundation (n.d.). Business Logic Security Cheat Sheet. OWASP Cheat Sheet Series.
13. MITRE (n.d.). CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition. Common Weakness Enumeration.
14. OWASP Foundation (n.d.). Input Validation Cheat Sheet. OWASP Cheat Sheet Series.
15. OWASP Foundation (n.d.). SQL Injection Prevention Cheat Sheet. OWASP Cheat Sheet Series.
16. OWASP Foundation (n.d.). Cross Site Scripting Prevention Cheat Sheet. OWASP Cheat Sheet Series.
17. The Rust Project (n.d.). The Rust Programming Language: References and Borrowing; Unsafe Rust. Rust language documentation.
18. The Swift Project (n.d.). Memory Safety. The Swift Programming Language, Swift.org.
19. Python Software Foundation (n.d.). Extending and Embedding the Python Interpreter. Python 3 documentation.
20. Szekeres, L., Payer, M., Wei, T. and Song, D. (2013). SoK: Eternal War in Memory. IEEE Symposium on Security and Privacy, pp. 48–62. DOI: 10.1109/SP.2013.13.
21. Anderson, R. (1993). Why Cryptosystems Fail. Proceedings of the 1st ACM Conference on Computer and Communications Security, pp. 215–227. DOI: 10.1145/168588.168615.
22. Internet Engineering Task Force (2023). Service Identity in TLS. RFC 9525.
23. Internet Engineering Task Force (2020). JSON Web Token Best Current Practices. RFC 8725.
24. Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. IETF RFC 8446. DOI: 10.17487/RFC8446.
25. Clark, J. and van Oorschot, P. C. (2013). SoK: SSL and HTTPS: Revisiting Past Challenges and Evaluating Certificate Trust Model Enhancements. IEEE Symposium on Security and Privacy. DOI: 10.1109/SP.2013.41.
26. National Institute of Standards and Technology (n.d.). Side Channel. NIST CSRC Glossary.
27. Anderson, R. and Needham, R. (1995). Programming Satan's Computer. In Computer Science Today, pp. 426–440. DOI: 10.1007/BFB0015258.
28. Kim, Y., et al. (2014). Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors. Proceedings of the 41st International Symposium on Computer Architecture, pp. 361–372. DOI: 10.1109/ISCA.2014.6853210.
29. Seaborn, M. and Dullien, T. (2015). Exploiting the DRAM Rowhammer Bug to Gain Kernel Privileges. Google Project Zero research, March 2015.
30. Kocher, P., et al. (2018). Spectre Attacks: Exploiting Speculative Execution. arXiv:1801.01203, security research preprint.
31. Lipp, M., et al. (2018). Meltdown: Reading Kernel Memory from User Space. 27th USENIX Security Symposium.
32. Intel (n.d.). Analysis of Speculative Execution Side Channels. Intel Software Security Guidance.
33. NVIDIA (2018). Security Notice: NVIDIA Tegra RCM Vulnerability. NVIDIA Product Security Notice, 24 April 2018.
34. Temkin, K. and ReSwitched (2018). Fusée Gelée: Boot ROM Vulnerability Disclosure. Research disclosure.
35. National Institute of Standards and Technology (2018). Platform Firmware Resiliency Guidelines. NIST Special Publication 800-193. DOI: 10.6028/NIST.SP.800-193.
36. Glosner, C. and Machiry, A. (2026). SoK: All You Ever Wanted to Know About Bootloader Security but Were Afraid to Ask. IEEE Symposium on Security and Privacy. DOI: 10.1109/SP63933.2026.00163.
37. Lefeuvre, H., Dautenhahn, N., Chisnall, D. and Olivier, P. (2025). SoK: Software Compartmentalization. IEEE Symposium on Security and Privacy. DOI: 10.1109/SP61157.2025.00075.
38. Ross, R., Pillitteri, V., Graubart, R., Bodeau, D. and McQuaid, R. (2021). Developing Cyber-Resilient Systems: A Systems Security Engineering Approach. NIST Special Publication 800-160, Vol. 2 Rev. 1. DOI: 10.6028/NIST.SP.800-160v2r1.
39. Apple (n.d.). Operating System Integrity. Apple Platform Security.
40. Apple Security Research (2025). Memory Integrity Enforcement: A Complete Vision for Memory Safety in Apple Devices. Apple Security Research technical blog.
41. Apple (n.d.). Secure Enclave. Apple Platform Security.
42. Apple Developer (n.d.). Protecting Keys with the Secure Enclave. Apple Developer Documentation, Security.
43. Microsoft (n.d.). Trusted Platform Module (TPM) fundamentals. Microsoft Learn.
44. Arm (n.d.). TrustZone for Cortex-A. Arm Technologies.
45. Intel (n.d.). Intel Software Guard Extensions SDK for Linux OS. Intel Developer Documentation.
46. Zinkus, M., Jois, T. M. and Green, M. (2022). SoK: Cryptographic Confidentiality of Data on Mobile Devices. Proceedings on Privacy Enhancing Technologies, 2022(1), pp. 586–607. DOI: 10.2478/popets-2022-0029.
47. Apple Developer (n.d.). Enabling Enhanced Security for Your App. Apple Developer Documentation, Xcode.
48. Apple Developer (n.d.). Preparing Your App to Work with Pointer Authentication. Apple Developer Documentation, Security.
49. LLVM Project (n.d.). Pointer Authentication. Clang Compiler Documentation.
50. OWASP Foundation (2025). A10: Mishandling of Exceptional Conditions. OWASP Top 10: 2025.
51. MITRE (n.d.). Privilege Escalation (TA0004). MITRE ATT&CK knowledge base.
52. MITRE (n.d.). Lateral Movement (TA0008). MITRE ATT&CK knowledge base.
53. OWASP Foundation (2025). A03: Software Supply Chain Failures. OWASP Top 10: 2025.
54. Cybersecurity and Infrastructure Security Agency and international partners (2026). 2026 Minimum Elements for a Software Bill of Materials (SBOM). Joint government guidance.
55. Abu Ishgair, E., Gomez, J., Melara, M. S., Cárdenas, A. A. and Torres-Arias, S. (2026). SoK: A Defense-Oriented Evaluation of Software Supply Chain Security. IEEE European Symposium on Security and Privacy, pp. 836–859. DOI: 10.1109/EuroSP68448.2026.00059.
56. Boyens, J., et al. (2024). Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. NIST SP 800-161 Rev. 1, Update 1.
57. Arasaratnam, O., et al. (2024). xz Backdoor CVE-2024-3094. Open Source Security Foundation, 30 March 2024.
58. Cox, R. (2024). Timeline of the xz Open Source Attack. Research note, 2024.
59. Supply-chain Levels for Software Artifacts (n.d.). Provenance. SLSA Specification, version 1.2.
60. Supply-chain Levels for Software Artifacts (n.d.). Build: Verifying Artifacts. SLSA Specification, version 1.2.
61. The Update Framework (2024). Overview. TUF Documentation, last updated October 2024.
62. Rekhi, S., Amberiadis, K., Akib, A. A., and Srivastava, A. (2025). Analyzing Collusion Threats in the Semiconductor Supply Chain. NIST Cybersecurity White Paper 46. DOI: 10.6028/NIST.CSWP.46.
63. National Institute of Standards and Technology (n.d.). Supply Chain. NIST Mobile Threat Catalogue.
64. Cybersecurity and Infrastructure Security Agency (n.d.). Known Exploited Vulnerabilities Catalog. CISA vulnerability catalogue.
65. UK National Cyber Security Centre (n.d.). Vulnerability Management: Carry Out Assessments. NCSC vulnerability management guidance.
66. Charrier, C., and Semrau, J. (2023). Analysis of Time-to-Exploit Trends: 2021–2022. Mandiant / Google Threat Intelligence, 28 September 2023.
67. Charrier, C., and Weiner, R. (2024). How Low Can You Go? An Analysis of 2023 Time-to-Exploit Trends. Mandiant / Google Threat Intelligence, 15 October 2024.
68. Mandiant (2026). M-Trends 2026: Data, Insights, and Strategies From the Frontlines. Google Threat Intelligence.
69. Fang, R., Bindu, R., Gupta, A., and Kang, D. (2024). LLM Agents Can Autonomously Exploit One-Day Vulnerabilities. arXiv preprint 2404.08144.
70. Grunewald, R., Mazumdar, S., and Vanderlee, K. (2026). Vulnerability Discovery and Exploitation Trends in the AI Era. Google Threat Intelligence Group, 1 October 2026.
71. UK AI Security Institute (2026). How Far Behind the Frontier Are Leading Open-Weight Models on Cyber? AISI Work.
72. International AI Safety Report (2026). International AI Safety Report 2026. Section 3.4, Open-weight models.
73. The PHP Foundation (2026). Today's PHP Security Release, and How We're Strengthening PHP Security. The PHP Foundation Blog, 21 October 2026.
74. CVE Program (n.d.). Common Vulnerabilities and Exposures: CVE Program Mission and Records. CVE Program.
75. FIRST (n.d.). Common Vulnerability Scoring System (CVSS) v4.0: User Guide. FIRST.org, document version 1.2.