6.4 安全与漏洞管理指标

概述与动机

本主题把这一部分已经建立起来的同一套可靠性纪律，目标设定、护栏配对、诚实的事件报告，延伸到一种不同但密切相关的风险上，为第6部分收尾：不是一个系统是否会自己出故障，而是是否会有人故意让它出故障，或故意利用它。漏洞管理指标衡量的是一个组织在安全弱点被利用之前发现并修复它们的能力有多强：存在多少漏洞，它们有多严重，以及关键的一点，一旦被发现，它们被补救的速度有多快，因为一个已知却未被修补的漏洞，是这个组织已经选择承担的一项常设的、可量化的风险，无论是刻意选择，还是出于疏忽。

本主题的核心关切，直接呼应了主题 4.4 对静态分析发现的处理方式：一个原始的漏洞数量是一个糟糕的指标，把琐碎和关键问题混为一谈，它也暴露在与主题 1.2 所概括描述的完全相同的操纵风险之下：定义收窄、压制，以及阈值操纵。安全指标所需要的具体补充，是按严重程度跟踪的补救时间，因为一个数月未被修补的关键漏洞，与同一个漏洞在一天内被发现并修复相比，代表的是一种根本不同的风险，而单单一个数量无法传达这种信息。

对大团队而言，安全指标所承载的后果超出了直接的技术风险：企业组织因一次数据泄露而面临合同和声誉方面的风险，政府组织则面临国家安全、法律和公众信任方面的后果，这让安全指标成为一项真正的公共利益事项，而不仅仅是一项内部工程关切。本主题以本书自始至终应用的同等严谨性和同等护栏配对纪律来对待漏洞管理，因为安全指标暴露在本书所描述的每一种操纵风险之下，而一旦这种操纵得逞，其代价也相应更高。

核心原则

按严重程度分类的补救时间，比一个原始的漏洞数量更重要。 一个数月未被修补的关键问题，与同一个问题被迅速发现并修复相比，是一种根本不同的风险。
安全指标暴露在与静态分析发现（主题 4.4）相同的操纵风险之下， 而一旦操纵得逞，风险相应更高。
严重程度分类需要在可能的情况下使用外部的、标准化的标准， 而不是纯粹依赖可能朝宽松方向漂移的内部判断。
一个被迅速披露并修复的漏洞，是一个健康流程的标志，而不是一次需要被隐藏的失败。 惩罚披露会劝阻整个系统所依赖的报告行为。
安全债务是技术债务（主题 4.5）的一个类别， 应当在同等明确、量化的基础上竞争有优先级的补救产能。

建议

把按严重程度分类的补救时间作为主要指标来跟踪

对每一个被发现的漏洞，记录它的严重程度（在适用的情况下使用一个标准化的量表，例如通用漏洞评分系统，CVSS），并跟踪从发现到真正补救之间的时间，而不是到一张工单被关闭，或一次修复被合并、却尚未部署为止。为不同严重程度设定明确的补救时间目标，常见的做法是关键问题以天计、严重程度较低的问题以周计，并把对照这些目标的合规情况，作为主要的安全健康指标来跟踪，而不是一个原始的、未加权的漏洞数量。

使用标准化的严重程度评分，而不是纯粹的内部判断

在有一个标准化的外部评分系统（如CVSS）可用的地方，把它用作严重程度分类的主要依据，而不是完全依赖可能不一致的内部判断。这呼应了主题 5.1 的逃逸缺陷分类纪律和主题 6.2 的事件分类纪律，只是专门应用在了安全上，它抵御了那些主题所警告的同一种宽松化漂移风险，因为一个以外部为锚点的评分，比一个纯粹内部的评分更难被悄悄向下重新定义。

建立一种真正非惩罚性的漏洞披露与内部报告文化

把主题 6.2 的无责事后分析原则直接应用到安全上：一名发现并报告了自己引入的漏洞的工程师，或一位负责任地披露一个从外部发现的漏洞的研究人员，应当被当作提供了一项有价值的服务，而不是在承认一次失败。惩罚披露，无论是内部还是来自外部研究人员的披露，都可靠地会劝阻整个漏洞管理系统所依赖的那种报告行为，把真正的风险驱赶到地下，而不是纳入一个受管理的补救流程。

把安全债务当作你技术债务积压清单中的一个类别来对待

把已知的、被接受为风险的漏洞，那些因为竞争性优先级而被刻意暂不补救的漏洞，纳入主题 4.5 所述的那份同样可见、量化的技术债务积压清单，采用同样的修复成本与背负成本框架。这防止了安全风险要么消失在一种不可见、未被记录的”我们知道这个问题”状态中，要么在没有一份明确、量化的优先级论证的情况下，不公平地与功能工作竞争。

把漏洞指标与暴露程度和可利用性背景结合起来

并非每一个拥有相同名义严重程度分数的漏洞，都承载着相同的真实风险：一个内部工具中、没有外部网络暴露的关键漏洞，与同样名义严重程度的、一个处理客户数据的面向互联网服务中的漏洞，是不同的风险。在可行的情况下，按真实的暴露程度和可利用性背景，而不只是严重程度分数，对优先级加权，这样补救产能才能首先集中在真正风险最高的条目上。

权衡取舍：利与弊

方案	优点	缺点
原始漏洞数量	报告起来简单	把琐碎和关键问题混为一谈；容易通过压制来操纵
按严重程度加权的补救时间跟踪	更准确地反映随时间变化的真实风险暴露	需要有纪律、一致的分类和跟踪
纯粹内部的严重程度判断	灵活，贴合具体情境	容易出现宽松化漂移和各团队之间的不一致
标准化外部评分（例如CVSS）加背景加权	一致，以外部为锚点，抵御操纵	需要额外的背景分析才能实现真正准确的优先排序

核心张力是一致性与背景之间的张力。一种纯粹标准化的评分方法是一致的、抵御操纵的，但可能遗漏决定真实风险的真正背景，暴露程度和可利用性；一种纯粹依赖情境、由内部判断的方法能捕捉细微差别，但容易出现本书对每一项依赖分类的指标都警告过的同一种宽松化漂移风险。解决这种张力的办法，是以标准化评分作为一致的基线来锚定，然后在其之上应用有文档记录、可审计的背景加权，而不是单独走任何一个极端。

与团队讨论的问题

我们是按严重程度跟踪补救时间，还是只有一个原始的漏洞数量？ 拉出你当前实际的指标，检查它是否能把一个数月未被修补的关键问题，与一个一天内被修复的关键问题区分开来，因为一个原始数量把这两种风险截然不同的情况同等对待。
我们使用的是一个标准化的外部严重程度评分系统，还是分类依赖纯粹的、可能不一致的内部判断？ 如果是纯粹内部的，讨论采用CVSS这样的标准会给你当前的分类实践带来什么改变。
一名引入并随后报告了一个漏洞的工程师，会觉得这样做安全吗，还是他们会害怕受到惩罚？ 这是主题 6.2 无责文化问题在安全领域的直接对应版本，在这里一个诚实的答案，对于你的漏洞数据是否可信而言，具有极大的重要性。
我们是否拥有一份可见的、量化的已知、被接受风险漏洞积压清单，还是”我们知道这个问题”的状态会随时间悄悄变得不可见、无人处理？ 检查你的安全债务是否被以与你一般技术债务积压清单（主题 4.5）同等的严谨性跟踪着。
我们的补救优先排序是否考虑了真实的暴露程度和可利用性，还是纯粹依赖一个不顾背景的名义严重程度分数？ 挑一个真实的例子，其中两个名义严重程度相似的漏洞承载着截然不同的真实风险，讨论你当前的流程是否会正确地为它们排定优先级。
一个漏洞的严重程度分类是否曾经随时间在没有明确理由的情况下向下漂移？ 这呼应了主题 1.2 和主题 6.2 都警告过的定义操纵模式；审计你近期分类的一个样本，检查是否存在这种具体风险。

行业视角

初创公司。 在很早期，正式的漏洞管理流程往往没有必要，但从一开始就采用基本的自动化依赖扫描和一项简单、诚实的内部报告规范，成本很低，也能防止安全债务在团队有能力系统性处理它之前，就不可见地累积起来。

小型企业。 大多数现代开发平台都包含免费或低成本的依赖自动化漏洞扫描；及早启用它，并对任何被标记为关键的问题跟踪补救时间，即使没有专门的安全职能或复杂的工具。

企业。 一致的、标准化的严重程度评分，以及真正非惩罚性的披露文化，两者都至关重要，也都更难在这个规模上维持，因为数十个团队之间的不一致，以及一次严重事件之后朝寻找问责对象方向的文化漂移，都是持续存在的风险。投资于一个专门的安全治理职能，以维持分类的一致性，并主动保护披露文化。

政府。 在这里，安全指标常常直接与国家安全、监管合规和公众信任相交织，一个被处理不当的严重漏洞，其后果可能远超一次典型的私营部门数据泄露。维持严谨的、以外部为锚点的严重程度分类，主动保护内部和外部的披露文化，并以本主题所建议的透明度和优先排序严谨性来对待安全债务，因为公共基础设施中一个未被记录、被悄悄接受的关键漏洞，是一项真正严重的、可被审计的风险。

案例

企业。 一家软件公司的安全团队多年来只向领导层报告一个原始的漏洞数量，这个数字一直呈持平趋势，给人一种虚假的稳定感。一次修订后的、按严重程度加权的补救时间分析揭示，尽管总数持平，关键漏洞的平均补救时间却超过了九十天，远超任何合理的目标，因为它们在每一个规划周期中，都在与功能工作的竞争中败下阵来，没有专门、受保护的产能。为关键漏洞建立一个硬性的7天补救目标，配以呼应主题 4.5 技术债务分配模型的受保护安全债务补救产能，在两个季度内把关键问题的平均补救时间降到了五天以内。

政府。 一家国家基础设施机构在一次外部安全审计之后发现，内部工程师一直非正式地回避报告他们在自己代码中发现的漏洞，担心这会对他们的绩效评估产生不良影响，这与主题 6.2 那种由问责驱动的事件少报模式如出一辙。该机构建立了一项明确的、公开传达的政策，保护内部漏洞报告者不受任何绩效后果的影响，直接以无责事件响应实践为蓝本，随后一年内内部漏洞报告大幅上升，该机构的领导层正确地把这解读为检测能力改善和诚实报告的证据，而不是代码质量下降的证据，避免了那种自然却错误的结论：数字上升一定意味着情况变得更糟了。

商业理由：动机、投资回报与总拥有成本

严谨、分类良好、诚实报告的漏洞管理的回报，是避免了数据泄露的代价，对一次严重的安全事件而言，这项代价常常数倍于主动补救的成本，还避免了监管、合同和声誉方面的损害。上面的软件公司案例展示了具体的机制：安全债务多年来一直在与功能工作的优先排序竞争中悄悄败下阵来，恰恰是主题 4.5 对技术债务整体所警告的那种模式，直到受保护的补救产能直接解决了这个问题。

总拥有成本包括自动化扫描工具、本主题所建议分配的受保护补救产能，以及对非惩罚性披露实践的持续文化投入。相比一次本可以被主动、有优先级的补救在被利用之前就捕捉并修复的严重的、成功被利用的漏洞所造成的代价，这份成本是适度的。

反模式与陷阱

只跟踪一个原始的漏洞数量： 把琐碎和关键问题混为一谈，无论真实风险如何，都给人一种虚假的稳定感或危机感。
纯粹内部、未标准化的严重程度分类： 容易出现宽松化漂移和各团队之间的不一致。
惩罚漏洞披露，无论内部还是外部： 把真正的风险驱赶到地下，而不是纳入一个受管理的补救流程。
安全债务没有一份可见的、量化的积压清单： 默认会在与功能工作的优先排序竞争中败下阵来。
仅按名义严重程度分数排优先级，忽视暴露程度和可利用性背景： 把有限的补救产能引导到了错误的地方。
在不检查报告本身是否有所改善的情况下，把漏洞报告数量的上升解读为质量下降的证据： 主题 1.6 混淆变量陷阱的一个具体实例。

成熟度模型

第一级，启动： 漏洞即使被跟踪，也只是作为一个原始数量，没有严重程度加权、没有补救时间跟踪，还带有一种惩罚性的披露文化。
第二级，发展： 存在一些严重程度分类，但标准不一致，补救时间也没有对照明确的目标被跟踪。
第三级，标准化： 标准化的、以外部为锚点的严重程度评分，以及按严重程度设定的明确补救时间目标，被一贯地应用，配以一种真正非惩罚性的披露文化。
第四级，管理： 安全债务在一份可见的、量化的积压清单中被跟踪，配有受保护的补救产能；优先排序考虑了暴露程度和可利用性背景，而不只是严重程度。
第五级，协奏： 组织能够指出关键补救时间方面具体的、可衡量的下降，并能够证明一种持续的、可信赖的披露文化，产生诚实、全面的漏洞数据。

讨论思路

我们当前关键漏洞的平均补救时间是多少，它是否达到了一个明确的目标？
一名引入了一个漏洞的工程师，会觉得自己报告它是安全的吗？
我们是否拥有一份可见的、量化的、已知的、被接受风险的安全债务积压清单？
我们的补救优先排序是否考虑了真实的暴露程度，还是只考虑名义严重程度？
一个严重程度分类是否曾经随时间在没有明确理由的情况下向下漂移？

要点回顾

把按严重程度分类的补救时间，而不是一个原始的漏洞数量，跟踪为主要的安全健康指标。
使用标准化的外部严重程度评分（如CVSS）作为一致的基线，抵御纯粹内部判断所招致的宽松化漂移风险。
建立一种真正非惩罚性的披露文化；惩罚报告会把真正的风险驱赶到地下。
把安全债务当作技术债务的一个类别（主题 4.5），公平地竞争受保护的补救产能。
按真实的暴露程度和可利用性、而不只是严重程度分数来加权优先级。

参考文献与延伸阅读

FIRST.org的通用漏洞评分系统（CVSS）规范：本主题自始至终引用的标准化严重程度评分框架。
OWASP基金会关于漏洞管理和安全软件开发生命周期实践的资源。
Site Reliability Engineering: How Google Runs Production Systems，Betsy Beyer、Chris Jones、Jennifer Petoff、Niall Richard Murphy编（本主题应用于安全披露的无责文化原则）。
NIST特别出版物800-40，Guide to Enterprise Patch Management Planning：关于漏洞补救实践的权威指导。