10.2 风险、审计与保证

概述与动机

风险、审计与保证，是一门理解哪些地方可能出问题的实践：既包括你的软件，也包括构建和运行它的组织。你决定该如何应对。然后你要证明你所声称拥有的控制措施确实有效。你要向高管、监管机构、审计员和公众证明这一点。在一个小团队里，风险管理大多是隐性的，几个人把全局装在脑子里就够了。而在一个大型企业或政府机构中，你必须让风险变得显性化、系统化。没有一个人能看到全貌，失败的后果巨大，而且往往受到监管。信任必须被展示出来，而不是被假定存在。

这一点对大型组织尤为重要，原因有三。第一，规模会放大风险敞口。更多的系统、供应商、数据、人员和连接意味着更多的失败方式，一旦失败发生，爆炸半径也更大。第二，大型组织要向外部人士负责（监管机构、审计员、董事会、法院和公民），而这些人要的是证据，不是口头保证。第三，集中化会悄悄地渗入进来。共享平台、共用供应商和复用组件会造成单点故障，没有哪个单独的团队能注意到，然而它却可能瞬间拖垮整个企业。

本章旨在把企业级的风险管理纪律带入软件领域，同时又不让交付被官僚主义所窒息。做得好的话，风险与保证不是加在工程之上的一种税负，而是大型组织赢得大规模运营资格的方式。它们把”相信我们”变成了”证据在此”。

关键原则

风险是被管理的，而不是被消除的。 工作的目标是识别、评估、处置并监控风险，使其保持在可接受的水平，而不是假装它能被降到零。
风险在哪里产生，就由哪里拥有。 构建并运行一个系统的团队拥有其风险；中枢职能部门制定标准并进行检查，而不是把问责制吸纳到自己身上。
证据胜于断言。 一项你无法证明的控制措施，就等于你没有这项控制措施。
持续胜于时点性。 年度审计发现偏差为时已晚；应尽可能持续、自动地监控控制措施。
第三方会继承你的风险。 你的供应商的弱点会成为你的弱点；供应链风险就是你的风险。
集中化是一种一等公民级别的风险。 通过整合获得的效率，会悄悄制造出必须被指认和管理的单点故障。
相称性。 让控制的深度与后果相匹配；把每个系统都当作最高关键等级来对待，只会浪费精力并滋生规避行为。

建议

把企业级风险管理应用到软件上

在整个组织内采用一套通用的风险框架和词汇，这样你才能比较并汇总各项风险。为每个重要系统维护一份风险登记册，并把各个登记册汇总成一个组合层面的视图。对每一项风险，记录其可能性、影响、责任人、当前的控制措施，以及处置决定（接受、缓解、转移或规避）。使用“三道防线”模型来分离职责：团队拥有并管理自身的风险（第一道防线），风险与合规职能部门制定政策并进行质询（第二道防线），内部审计部门独立地提供保证（第三道防线）。在高层明确设定一个风险偏好，这样各团队就知道组织愿意承担多大的风险，而不必各自猜测。

保证第三方和供应链风险

清点你的供应商，同样重要的是，也要清点你的软件依赖项，包括传递性的开源组件。按每个供应商所承载的访问权限和关键程度，对其进行相应比例的评估。依靠已获认可的认证（例如 SOC 2，一份针对提供商安全控制的独立审计报告，或 ISO 27001 报告），而不是在已有良好证据的地方重新发明问卷调查。对你所使用的组件，要求提供软件物料清单（SBOM），这样在某个漏洞被曝出的那一刻，你就能立刻回答”我们是否受影响？“。把供应链完整性构建进你的流水线：验证来源、固定并签名制品，并控制进入构建过程的内容。把安全条款、违规通知条款、审计权条款和退出条款写进合同。定期重新评估供应商，而不是只在初次引入时评估一次。

构建审计轨迹、证据和持续的控制监控

设计系统时，让证据成为运行过程的自然副产品。捕获不可篡改、带时间戳、防篡改的重要操作审计日志：谁做了什么、对什么对象做的、何时做的、依据什么授权做的。保护这些日志，不让它们被日志所记录的当事人本人更改。优先采用自动化且持续受监控的控制措施：代码即政策，用来阻止不合规的变更；流水线关卡，用来强制执行必要的评审；以及能实时显示控制状态的仪表盘。持续的控制监控，把审计从一场周期性的、需要重建证据的手忙脚乱，变成一股稳定的保证之流。它能在数小时内、而不是等到下一次年度评审时，捕捉到偏差。

治理业务连续性与灾难恢复

弄清楚一旦系统出现故障，你的组织必须继续做哪些事，以及要多快恢复。运行一次业务影响分析，根据业务需要而非工程便利性，为每项服务设定恢复时间目标和恢复点目标（RTO/RPO）。然后维护业务连续性和灾难恢复（DR）方案，并且（这正是许多组织会跳过的部分）真正去测试它们。定期开展演练，包括完整的故障转移和从备份恢复的演练。未经测试的备份和未经测试的故障转移只是假设，而不是能力。要在企业层面治理这件事，这样你才能在真正的灾难发生之前、而不是发生之时，理解跨系统的依赖关系。

管理集中化风险与单点故障

有意识地去寻找那些许多服务都依赖于同一样东西的地方：单一云区域、单一身份认证提供商、单一关键供应商、单一数据库、单一个人。在组合层面绘制出这些集中化的地图，因为单个团队是看不到它们的。对于最关键的部分，通过冗余、多区域或多供应商策略以及优雅降级来降低集中化程度，同时诚实地权衡由此增加的成本和复杂性。在你为了效率而接受集中化的地方，要把它变成一个有意识的、有文档记录的、有专人负责的决定，并配有经过测试的备用方案。不要让它变成一个无人察觉、直到失效才被发现的意外。

权衡：优点与缺点

方法	优点	缺点
严格的正式控制	保证力度强；随时可应对审计和监管	拖慢交付；招致打勾式合规和规避行为
基于风险的轻量控制	快速；精力集中在真实风险敞口上	需要成熟的判断力；若风险评估不佳会出现缺口
时点性审计	熟悉、有明确的通过/不通过时刻	偏差发现得晚；诱使人只在审计当天做好准备
持续控制监控	早期发现偏差；减少审计时的手忙脚乱	需要前期自动化投入；工具和埋点成本
整合／单一供应商	成本更低；更简单；有采购量优势	集中化风险；单点故障；供应商锁定
冗余／多供应商	弹性强；没有单点故障	成本和复杂性更高；需要维护和保护的东西更多

反复出现的权衡是保证力度与速度之间的取舍。解决办法是相称性加自动化。一刀切的严格控制会拖慢所有人的速度，更糟的是，它会教会团队把合规当作可以被糊弄过关的表演。而纯粹的轻量级控制则依赖并非每个团队都具备的判断力。破解之道是：让控制深度与后果相匹配，并把控制措施自动化地嵌入交付流水线，这样保证就来自构建这一行为本身，而不是事后附加上去的。集中化方面的权衡（效率与弹性之争）没有普适答案。要针对每一项关键依赖，有意识地做出决定，并记录下被接受的风险，同时配有经过测试的备用方案。

与团队讨论的问题

你将如何按关键程度对系统进行分类，以使控制深度与后果相匹配？ 相称性是化解保证与速度之间张力的方法：把每个系统都当作最高关键等级来对待，会浪费精力并教会团队糊弄合规；而认为没有什么是关键的，则会让你猝不及防地暴露风险。你需要一套明确的分级体系，把每个系统与在高层设定的风险偏好挂钩起来，这样一个低风险的内部工具和一个面向公民的福利系统就不会承受同样的控制强度。把证据带到讨论中：列出你的各个系统、每个系统承载的数据和爆炸半径，以及当前施加的控制措施，然后寻找两个方向上的不匹配之处。这个答案应该决定你把什么自动化嵌入流水线、把什么留给人的判断，并应该给团队一个清晰的日常权衡依据，而不是让他们靠猜测。没有达成一致的分级，相称性就只是一句空话。
下一次某个关键依赖披露一个漏洞时，你能在几分钟之内回答”我们是否受影响？“吗？ 当一个被广泛使用的组件出问题时，反应迅速的组织早已建立了一份 SBOM 清单，能映射出该组件被使用的每一个地方，包括传递性的开源依赖。如果诚实的答案是要花几天，或者”我们得去查一下”，那么这个缺口，就是可控应对与手忙脚乱之间的差别。带上证据：挑一个你实际依赖的真实代码库，计时看看列出发布它的每一项服务需要多长时间。这个答案应该推动在流水线中生成 SBOM、固定并签名制品、验证来源的投入，这样风险敞口就是一次查询，而不是一场调查。这就是供应链风险，你的供应商的弱点，早已是你的弱点。
哪些服务会接受完整的故障转移和从备份恢复的演练？多久一次？谁来签字确认演练通过？ 未经测试的备份和未经测试的故障转移只是假设，而不是能力，而组织往往是在一场真正的灾难中才发现这一点，而不是在灾难之前。运行一次业务影响分析，根据业务需要为每项服务设定恢复时间目标和恢复点目标，然后把演练频率与这些等级挂钩。带上证据：对于你最关键的服务，上一次进行端到端的完整恢复演练是什么时候？它达到了所声明的 RTO 吗？这个答案应该产出一份常规的、跨系统灾难恢复演练的日程表，其结果要向领导层汇报，因为企业层面的治理正是揭示单个团队看不到的跨系统依赖关系的方式。在你为了效率而接受单一区域或单一供应商集中化的地方，要把它变成一个有意识的、有文档记录的、有专人负责的决定，并配有经过测试的备用方案。
你的哪些控制措施能在运行过程中自动产生证据？哪些仍然依赖有人在审计时临时拼凑证明？ 一项你无法证明的控制措施，就等于你没有这项控制措施，而那些能从容应对审计的组织，正是那些流水线能自动生成不可篡改、带时间戳的重要操作记录、而无需任何人费心收集的组织。这里存在真实的对立拉力：把控制措施自动化为代码即政策和持续监控，需要前期的工程投入，而时点性的证据收集看起来更便宜（）直到年度手忙脚乱到来、而偏差早已积累了数月之久。带上证据来讨论：对于你排名靠前的几项控制措施，问一问，证明它们的证据现在是否存在于一个防篡改的存储中，日志所记录的当事人能否更改它们，以及重建一个季度的活动记录需要多少小时。答案应该引导投入转向持续控制监控和流水线关卡，而不是人工出具证明。在企业和政府环境中，最强有力的姿态，是给审计员提供实时控制仪表盘的只读访问权限，把审计从周期性的重建，变成对一股稳定证据流的持续抽样。
三道防线是否真的作为分离的职责在运作？还是说所有权已经模糊到了构建系统的人也同时在为它提供保证？ 独立性正是这个模型的全部意义所在：团队在第一道防线拥有并管理自身的风险，风险与合规职能部门在第二道防线制定政策并进行质询，内部审计部门在第三道防线独立地提供保证，而当这些角色相互坍缩合并时，保证就变成了自己给自己的作业打分。这里的张力在于，把风险所有权推给交付团队，感觉起来可能比让一个中枢职能部门吸纳它更慢、更有争议，然而由中枢部门吸纳，却会悄悄地把问责制从风险实际产生的地方移走。带上证据：绘制出一项近期重大风险决策的过程，指出谁拥有它、谁质询了它、谁独立地为它提供了保证，然后检查是否有任何单一群体同时扮演了其中两个角色。讨论中还应该揭示，是否在高层明确设定了风险偏好，因为如果没有，每个团队就只能靠猜测来承担多少风险。对于受监管的企业或政府机构，一位正式接受剩余风险的问责官员（）不同于构建该系统的团队（）往往是一项硬性要求，而不是可有可无的锦上添花。
你的许多服务在哪些地方悄悄依赖于同一样东西？谁在组合层面拥有这种集中化的所有权？ 整合到单一云区域、单一身份认证提供商、单一关键供应商、单一数据库或单一个人身上，能带来真实的效率和采购量优势，但它同样可靠地制造出单点故障，而由于每个团队只能看到自己那一小片，没有哪个团队能单独看到这些故障点。这里诚实的权衡是效率与弹性之间的取舍，它没有普适答案：冗余以及多区域或多供应商策略能换来弹性，代价是金钱、复杂性以及更大的需要保护的攻击面。带上证据：尝试绘制一份组合层面的共享依赖关系图，寻找那些一旦出现单点故障就会波及众多服务的咽喉要道，然后检查这些集中化的地方是否真的有人负责。答案应该把意外的集中化，转变为针对最关键依赖项的、有意识的、有文档记录的、经过应急测试的决定。在企业和政府的产品组合中，一次区域性故障暴露出一个单一区域的面向公民的服务，正是监管机构和公众事后会仔细审视的那种失败，所以要在灾难之前、而不是灾难之中把它绘制出来。

行业视角

创业公司。 团队人少，也没有余力养一个风险部门，所以要让保证成为构建过程的自然副产品，而不是一个独立的职能。保留一份简短的风险登记册，每一项都有责任人和处置决定，依靠你云服务商的 SOC 2 报告，而不是从零开始编写控制措施，并在流水线中生成 SBOM，这样在某个依赖项的缺陷被曝出的当天，“我们是否受影响？“就是一次查询就能回答的问题。大声指出你那个最明显的集中化风险（）通常是那个唯一能部署上线的人（）并给他配一个搭档，这样知识就不会被困在一个人脑子里。

小型企业。 你没有专职的风险或审计专家，预算也紧张，所以要购买保证，而不是自己构建它：优先选择那些已经持有 SOC 2 或 ISO 27001 认证的供应商，这些认证本身就承载了你原本得自己生产的证据。把有限的精力花在后果最严重的地方，一份风险登记册加上每月一次的从备份恢复演练，胜过一套没人维护的精致框架。把合同当作一种控制手段，把违规通知条款和退出条款写进供应商协议里，这样你继承的对方风险盲区就会更少。

企业。 核心难题在于跨越众多团队的规模问题：运行三道防线模型，为每项服务维护风险登记册，并汇总成董事会层面的组合视图，同时在高层明确设定风险偏好，让团队不再靠猜测。把关键控制措施编码为在流水线中强制执行的代码即政策，给审计员提供实时控制仪表盘的只读访问权限，而不是为年度审计临时准备，并在组合层面绘制集中化风险，因为没有哪个单独的团队能看到共享的咽喉要道。通过明确的关键程度分级，让控制深度与后果相匹配，使相称性成为现实，而不只是一句口号。

政府。 采购规则、透明度和公共问责塑造着每一项选择。遵循一个正式的授权流程，由一位问责官员接受剩余风险，维持持续监控，这样授权就是一种持续的状态，而不是一张一次性的证书，并把审计权条款和数据可携带性条款写进供应商合同。由于一次暴露出单一区域面向公民服务的区域性故障会成为公共事件，要为最关键的服务强制要求多区域故障转移和经过测试的恢复能力，并按固定节奏向领导层汇报灾难恢复演练的结果。

示例

创业公司。 一家处理患者数据的六人规模健康科技创业公司，负担不起一个风险部门，所以它让保证成为构建过程的自然副产品。它在一份共享文档中维护一份简短的风险登记册，每一项都有责任人和处置决定，并在周五的站会上进行评审。它依靠云服务商的 SOC 2 报告，而不是从零开始编写自己的控制措施，在流水线中生成 SBOM，这样在某个依赖项的缺陷曝出的当天就能回答”我们是否受影响？“，并且每月运行一次从备份恢复的演练，因为未经测试的备份只是一种希望。它还大声指出了自己那个最明显的集中化风险：唯一能部署上线的创始人，并为他配了一名第二工程师，这样知识就不会被困在一个人脑子里。

企业。 一家支付公司在持续的监管审查下运营。它运行三道防线模型，维护按服务划分的风险登记册，并汇总成董事会层面的仪表盘。它把关键控制措施编码为代码即政策，在部署流水线中强制执行。变更审批、访问授权和配置变更都会向一个防篡改的存储发出不可篡改的审计事件。这家公司不是为年度审计做准备，而是给审计员提供实时控制仪表盘的只读访问权限，把审计变成了对持续证据流的抽样。当一个被广泛使用的开源库披露出一个严重缺陷时，公司的 SBOM 清单能在几分钟内回答”我们在哪里存在风险敞口？“。

政府。 一家国家级政府机构在任何系统投入运营之前，都要遵循一个正式的授权流程。它要求有文档记录的控制措施、一次独立评估，以及一位接受剩余风险的问责官员。它维持持续监控，这样授权就是一种持续的状态，而不是一张一次性的证书。一次区域性云故障，曾经暴露出一个面向公民的福利系统中单一区域的依赖关系。为此，该机构在其产品组合范围内绘制了集中化风险地图，为其最关键的服务强制要求多区域故障转移和经过测试的恢复能力，如今定期开展灾难恢复演练，并将结果向领导层汇报。

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

风险与保证的回报，主要来自避免的灾难性损失：一次重大数据泄露、一项监管处罚、一次关键服务的长时间停机，或一次供应链被攻陷的事件。这些事件单独看很罕见，但单独看又都是巨大的。一次被避免的事件，其价值就可能超过整个保证项目多年的成本。除了避免损失之外，成熟的保证体系还能降低合规的持续成本，因为证据是自动产生的，而不是在恐慌中临时拼凑出来的。它还能让你更容易赢得受监管的业务，通过客户的尽职调查。而且它能加快事件响应速度，因为你早已知道自己的风险敞口。

采用成本包括风险和审计人员的人力、用于监控和取证的工具，以及把控制措施自动化嵌入流水线的工程投入。而不采用的成本，则是你未能阻止的那些灾难的期望值，加上手动审计准备这项缓慢的税负，以及任何一次公开失败之后不断累积的声誉损害。当你向领导层说明理由时，要量化少数几个合理的最坏情况及其可能性。把持续控制监控定性为：用一种小额、稳定、可预测的成本，换掉一种巨大、不可预测、偶发的损失。强调总拥有成本：一项自动化一次的控制措施，此后每年都能省下审计成本。

反模式与陷阱

打勾式合规。 制作出能满足审计员的文件，而真正的控制措施并不起作用。
审计当天的表演。 系统只在年度审计前的几周内合规，一年中的其余时间都在悄悄偏离。
风险登记册变成坟场。 一份只填过一次、从未再被翻阅、与实际决策脱节的登记册。
未经测试的灾难恢复。 从未被演练过的备份和故障转移方案，因此在需要时并不起作用。
按品牌信任供应商。 假定一个知名供应商是安全的，却没有证据支撑，同时完全忽略传递性依赖。
看不见的集中化。 为了效率而整合到单一区域、单一供应商或单一个人身上，却没有人为由此产生的单点故障负责。
保证成为交付的阻碍。 没有相称性的严格中枢控制，团队会想办法绕开它，从而催生出完全没有保证的影子系统。
当事人自己能编辑的日志。 被审计的人能够更改的审计轨迹，什么也证明不了。

成熟度模型

第 1 级：启动。 风险在事件发生之后被被动地处理。不存在共享的框架或登记册。控制措施没有文档记录、也未经验证，审计是痛苦、手动的手忙脚乱。集中化风险和供应商风险未被审视，单点故障只有在失效时才会浮现。

第 2 级：发展。 基本实践开始出现，但因团队而异。一些重大系统建立了风险登记册，也采用了一套控制框架以便通过审计，但准备工作是手动的、时点性的。关键供应商只在引入时被评估，此后再无评估。备份是存在的，但很少被测试，只有部分单点故障是已知的。

第 3 级：标准化。 三道防线模型和一套通用框架在组织范围内有文档记录并被强制执行，形成一套统一的风险词汇，让你能够比较和汇总风险敞口。许多控制措施被自动化嵌入流水线，持续监控覆盖了关键控制措施。维护供应商和依赖项清单，包括 SBOM；灾难恢复按计划进行测试；集中化风险在组合层面被绘制出来，而不是留给单个团队自行处理。

第 4 级：管理。 保证依据基线被度量和管控，而不仅仅是被记录下来。控制覆盖率、偏差检测时间、灾难恢复演练相对于所声明的 RTO 和 RPO 的通过率、从披露到回答”我们是否受影响？“的平均耗时，以及剩余风险相对于所声明风险偏好的水平，都作为指标被追踪并向领导层汇报。偏离基线会触发行动，中止标准和补救期限依据证据被强制执行，每一项重大的通过／不通过决定都依据数字来做出，而不是依据断言。

第 5 级：编排。 保证在整个组织范围内被持续改进和整合。审计员对实时证据进行抽样，风险偏好驱动着相称的控制措施，并随风险状况的变化而调整，供应链完整性在流水线中得到验证。灾难恢复演练是常规化、跨系统进行的，集中化决策是有意识的、有专人负责的、经过应急测试的，风险与保证被编织进组合和战略规划之中，使组织能够随着自身风险敞口的变化而重新平衡控制措施。

讨论话题

你如何设定一个有意义的风险偏好，让团队能够真正用它来做日常权衡？
在流水线中自动化的控制措施，与需要人来判断的控制措施之间，正确的边界在哪里？
什么时候为了效率而接受集中化风险是正确的选择？你如何让这个决定长期保持诚实？
对于一个小型的传递性依赖，与一个拥有深度访问权限的关键供应商，多大程度的供应链保证才算相称？
持续控制监控能否完全取代独立审计？还是说独立性需要一个外部的人来把关？
你如何防止风险和保证职能变成一个交付瓶颈，让团队想方设法绕开它？

关键要点

风险被管理到一个可接受的水平，在产生它的地方就由那里拥有，并用证据而非断言来证明。
优先选择持续的、自动化的控制监控，而不是时点性审计，这样偏差能被早期发现，证据也作为运营的自然副产品被生产出来。
第三方和供应链风险（包括传递性开源依赖）就是你的风险；清点它、要求提供 SBOM、验证来源。
业务连续性和灾难恢复，只有经过测试才算是能力；未经测试的备份和故障转移只是假设。
集中化风险和单点故障是单个团队看不见的组合层面问题；把它们绘制出来，让整合成为一个有意识的、经过应急测试的决定。
商业理由主要来自避免的灾难；用一种小额、稳定、可预测的成本，换掉一种巨大、不可预测、偶发的损失。

参考文献与延伸阅读

ISO 31000, Risk Management: Guidelines
ISO/IEC 27001 and 27005, Information Security Management and Information Security Risk Management
NIST, Risk Management Framework (SP 800-37) and Security and Privacy Controls (SP 800-53)
NIST, Secure Software Development Framework (SP 800-218) and Cybersecurity Framework
Committee of Sponsoring Organizations of the Treadway Commission (COSO), Enterprise Risk Management: Integrating with Strategy and Performance
AICPA, SOC 2 Trust Services Criteria
The Open Group, FAIR (Factor Analysis of Information Risk)
Betsy Beyer et al., Site Reliability Engineering (Google)
Institute of Internal Auditors, The Three Lines Model