DevSecOps流程审计：安全关卡、例外与修复由谁负责

设想一个假设的产品团队，他们每天多次发布一个B2B Web平台。流水线看起来相当成熟：每个合并请求都会运行静态分析，另有依赖项扫描、基础设施即代码扫描和容器镜像检查。仪表盘一片绿色。然后，一家大客户在采购环节提出了一个简单的问题：你们能否证明交付流程中的安全确实在发挥作用，而不只是装好了工具？

安全负责人开始顺藤摸瓜。几个月前，静态分析关卡因为一波误报从阻断模式改成了建议模式，却没人说得清是谁做的决定，也不知道这是否本来只是临时措施。一个高危依赖项问题挂着一条没有到期日的例外，批准人正是提出申请的那名工程师。Terraform代码通过了扫描，但在一次事件处理中，有人直接在云控制台放宽了一条防火墙规则，这项变更始终没有回写到代码仓库。

这个故事里的每一个工具都在正常工作，出问题的是围绕工具的流程。DevSecOps流程审计要发现的，正是这种差距。

DevSecOps流程审计到底审查什么

DevSecOps流程审计关注的是，安全是否已经融入软件的需求定义、构建、测试、发布和修复方式之中。审查对象不是某个单独的应用，也不是某一次扫描结果，而是一条决策链：谁制定安全需求，哪些检查在运行、拥有怎样的权限，谁可以绕过它们，例外如何批准又如何撤销，以及当某次发布带着已知问题上线时，由谁接受剩余风险。

责任人才是审计的真正单位

工具产生信号，做决定的是人和角色。对每一项控制，审计都需要找到一位能够修改它的具名责任人，而不只是一个负责运维它的团队。没有责任人的关卡往往会逐渐漂移：阈值被放宽，规则被静音，而流水线依然显示绿色，所以没人察觉。如果审计人员查不出是谁决定了某个关卡当前的模式，这本身就是一项发现。

流程证据与技术评估

有两类经常被混为一谈的工作，最好分开看待。流程审计证据关注的是决策和记录：责任人、审批、真实发布的抽样、例外登记册、修复工单及其验证。对流水线的技术评估关注的则是信任边界：谁或什么能够修改流水线定义，构建执行器如何隔离，密钥在哪里暴露，以及制品能否追溯到生成它的源代码。

NIST SP 800-204D讨论的是如何将软件供应链安全融入DevSecOps的CI/CD流水线，当工作转向这些信任边界时，它是一个合理的参考。它不能替代流程审计，流程审计也不能替代它。一份可靠的计划会写明两者中哪一项在范围之内；如果两项都在，还要写明哪些结论来自哪一部分。技术层面的内容，可参阅我们关于DevSecOps安全评估的文章。

规划：先确定范围、样本和衡量标尺

NIST SP 800-115即《信息安全测试与评估技术指南》，将一次评估分为三个阶段：规划、执行和执行后。该指南明确说明，它是对各类技术及其优势和局限的概述，而不是一套完整的测试计划。本文同样不是一套完整的DevSecOps审计方案。这三个阶段提供的是一种结构，防止流程审计退化为单纯的工具盘点。

规划阶段在很大程度上决定审计质量。审计是一项经过授权的评估，具备双方确认的范围和实施规则。通常纳入范围的有：安全需求、流水线关卡、问题分级与修复、例外处理、发布治理，以及对依赖项和供应商的监督。未经明确授权则不在范围内的有：生产环境测试、社会工程以及对第三方服务的测试。流程审计并不意味着可以测试组织并不拥有或未授权评估的系统。

如何选择样本

抽样胜于清点。与其索要一份全部工具的清单，不如从不同产品和团队中挑选几次近期发布，并且务必至少包括一次紧急变更和一次带着已知例外上线的发布。每一次被抽中的发布都是一条线索，审计人员沿着它从需求一路追到部署。样本应由审计人员选定，而不是由被审计团队提供，这样它反映的才是日常做法，而不是文档最完善的那个案例。

动手之前先固定标尺

事先确定审计发现将引用哪些参考文件，并固定其版本。OWASP ASVS是一套可验证的安全需求；对于选定的版本，例如5.0.0，项目建议在引用需求时加上版本前缀，例如v5.0.0-1.2.5，因为不同版本之间的编号会发生变化。OWASP Top 10是一份提升安全意识的文件，而不是需求集合；Web安全测试指南则是一种测试方法。这一区分会改变发现的措辞：「团队接受过Top 10培训，但工单中没有与ASVS对应的需求」是精确的结论，「安全不成熟」则不是。

如果管理层希望用治理语言描述当前状态和目标状态，可以为开发与交付职能建立一份NIST CSF 2.0配置文件。只有当确实有人会依据目标配置文件来确定优先级时，它才值得投入精力。

执行：追踪真实发布，而不是清点工具

在执行阶段，审计人员让每一次被抽中的发布走完整个生命周期，并针对每项控制记录证据是通过哪种技术获得的。SP 800-115描述了一组审查类技术，包括文档审查、日志审查、规则集审查和系统配置审查，它们构成了流程审计的主干。如果计划允许，对一个具有代表性的应用开展有限且经授权的技术检查，可以说明某项控制能否发现它应当发现的问题。构建通过的绿色标识只是配置层面的产物，并不能证明其背后的测试覆盖了相关风险。

下表把主要流程领域与审计应当找出的责任人、值得抽样的证据以及常见的失效方式对应起来。

需求与设计

审计要从源头开始。CISA的安全设计指南主张在设计阶段就应用安全原则，以便在产品交到客户手中之前减少可被利用的缺陷。审计的问题很具体：被抽中的这次发布，其安全需求从何而来？挂在工单上、注明版本的ASVS级别是可以审计的；非正式约定或无人引用的维基页面只能提供较弱证据，需要通过访谈、发布记录和实际做法加以佐证。

安全关卡及其绕过权限

对每个关卡，记录它的模式（阻断还是建议）、它应当拦截的弱点类别、谁可以修改模式或阈值，以及最近一次修改发生在什么时候。阻断式关卡提高了信心，却增加了绕过的压力；建议式检查保住了速度，却可能沦为噪音。审计不应脱离背景去评判这个选择，而应询问：该模式是否与弱点类别的风险相匹配，对它的修改是责任人做出的决定，还是逐渐漂移的结果。

CISA还指出，产品应当默认安全，多因素认证、日志记录和单点登录等功能应免费提供。审计人员可以检查安全默认配置和日志记录是否被纳入发布就绪标准，而不是等到以后再补上。

基础设施即代码与实际运行环境

基础设施代码的静态扫描检查的是源代码，它无法证明实际运行环境与这些源代码一致。事件处理中在控制台做的手工修改、计划外的脚本、只部分应用的变更计划，都会造成配置漂移，而干净的扫描结果永远显示不出这种漂移。这里需要索取的流程证据是：漂移能否被发现、由谁负责消除，以及针对一两个关键资源，对声明配置和实际配置做一次抽样比对。技术层面可参阅我们关于基础设施即代码安全评估的文章。

依赖项与构建链

这里的流程问题关乎责任归属和变更控制：谁来决定一个存在漏洞的依赖项可以随发布上线，谁有权修改流水线定义，这些修改是否与应用代码经过同样的评审。更深入的技术问题，例如制品来源证明和构建执行器隔离，属于软件供应链安全评估的范畴，SP 800-204D在那里最直接适用。

例外：文档流程与实际流程在这里分道扬镳

例外是DevSecOps审计中信息量最大的部分。文档化的流程描述的是正常路径，而例外展示的是在截止日期压力下实际发生了什么。紧急修复、人工放行和延期处理的问题，往往正是政策与实践之间的差距暴露出来的地方。

一条可用的例外记录应包含什么

一条可用的例外记录要写明风险责任人、原因、补偿性控制、到期日，以及一位不同于申请人的审批人。到期时应当复审，而不是悄悄续期。审计会抽取尚未关闭和近期关闭的例外，逐条检查上述要素。没有到期日的例外，实际上等于一次永久性的政策变更，而没有任何人决定过要修改政策。

紧急变更与人工放行

紧急通道是正当的：生产事故不会等流水线完整跑完。审计要问的是，紧急通道用完之后是否被关闭：是否在约定时间内做了回顾复盘，是否为跳过的检查建立了后续工单，手工修改的基础设施是否已回写到代码中。如果紧急变更频繁发生且从未复盘，那么紧急通道就已经成了真正的流程。

第二张表汇总了审计可以用于发布和例外的验收检查，并指出哪些证据看似有说服力、单独来看却并不充分。

反馈与修复：流程是否在学习

一条能发现问题却从不改变团队工作方式的流水线，只是一套报告系统，而不是安全流程。审计的这一部分关注的是问题出现之后发生了什么。

按弱点类别排序，而不是按问题数量

MITRE CWE Top 25列出了近期CVE记录背后最危险、最普遍的弱点类别。MITRE强调，理解根本原因可以反馈到软件开发生命周期和架构规划之中，有助于消除整类缺陷，例如内存安全和注入类问题。在Top 25之外，MITRE还依据CISA已知被利用漏洞目录发布了一份清单，对正在被积极利用的漏洞背后的弱点进行排名。对审计而言，这把问题从「扫描器报告了多少问题」转变为「我们的流程在设计上能够预防哪些弱点类别，对于出现在漏洞利用数据中的类别，修复时限是否更严格」。

CISA的安全设计警报也指向同一方向，内容涉及消除跨站脚本、操作系统命令注入和目录遍历。ASVS中有一条关于防范操作系统命令注入的需求，这说明一个弱点类别可以从令人担忧的话题，变成团队能够验证的事项。

关闭工单不等于完成修复

修复的证据是复测，而不是已合并的拉取请求。审计会抽取已关闭的问题，要求出示证明：修复之后重新按原始方式复现了该问题，确认它不再出现，并且工单关联了这一结果。如果工单在代码合并时自动关闭，组织衡量的就只是活动量，而不是风险的降低。具体做法可参阅我们关于漏洞修复控制的文章。

让发现回流到需求

学习型流程最有力的标志，是反复出现的问题会改变上游的产物。如果同一类注入问题在连续三次发布中都出现，合理的回应应当是一条需求、一种设计模式或一次库的选型，而不是第三轮工单。审计要寻找的就是这条轨迹：一类问题、一项决定、一条被修改的需求或关卡，以及此后一次该类问题不再出现的发布。

执行后：把观察转化为有人负责的决策

在SP 800-115中，执行后阶段涵盖分析、缓解建议和报告。对流程审计而言，这一阶段最大的风险是产出一长串技术工单，而有决策权的人根本不看。每一项发现都应当沿着同一条简短路径，从观察走到决策。

1. 观察在样本中看到了什么：哪次发布、哪项控制，以及与文档化流程有何偏离。
2. 证据与技术哪个产物支持该结论、通过何种方式获得（文档审查、日志审查、配置审查或经授权的测试），以及该技术无法证明什么。
3. 责任人能够改变流程的具名个人或角色，而不只是负责处理表面症状的团队。
4. 决策修复、附带到期日和补偿性控制予以接受，或重新设计控制；每种情况都记录由谁决定。
5. 复查下一轮如何、何时依据相同的注明版本的引用来验证这项变更。

CISA强调，技术提供商应当在高管层面承担产品安全责任。用审计的语言来说，每份报告都需要一位高管责任人，由他接受或拒绝报告中描述的剩余风险。没有这样一个人，报告就会变成一份待办清单。

让审计发现经得起标准更新

审计发现应引用注明版本的参考：ASVS v5.0.0编号、CWE编号，以及在使用时的CSF 2.0成果。每项发现还应说明它依据的是哪些样本，以及所用技术无法证明什么，例如：「配置审查确认该关卡处于阻断模式；但这并不能说明其规则集能够检测出相关弱点类别。」这样，即使标准发生变化，报告依然清晰无歧义，下一次审计也能用同样的标尺比较状态变化。

为什么这里没有成熟度评分

用一个数字为报告收尾很有诱惑力。然而，根据少量样本和访谈拼凑出的成熟度分数，会把主观判断包装成测量结果，并引出错误的比较。更有用的标准是：组织能否说明自己预防了哪些弱点类别、如何验证，以及由谁接受剩余风险。如果企业内部用分数来跟踪进展，应当明确标注这是评估人员的判断，而不是测量得出的数值。

这类审计无法告诉你什么

旧指南，新流水线

SP 800-115发布于2008年，早于现代持续集成与持续交付实践。它的规划与分析逻辑依然适用，但针对流水线的具体技术需要从其他来源获取，这也是SP 800-204D对技术层面很重要的原因之一。ASVS和WSTG以Web应用为重点，其他类型的系统需要补充额外的需求。

样本不等于总体

流程审计根据发布、例外和工单的样本得出结论。它可以说明某项控制在某个具体案例中失效，或在整个样本中表现一致，但无法证明所有发布都是如此。报告应当说明样本是如何选取的。

意图不等于结果

采用某个框架或签署CISA安全设计承诺之类的承诺，只是表明意图，并不能证明结果。审计依赖的是可观察的证据。同样的道理，无论是流程审计还是渗透测试，都不是安全认证、鉴证或保证；它们都是对所审查范围内各项控制实际表现的有依据的判断。

如何为外部流程审计做准备

如果计划引入外部团队，准备工作主要是让流程可追溯，而不是打磨文档。为每个关卡和每类例外指定责任人。确保关卡配置的变更留有版本记录。整理出一份带有到期日的例外登记册。确定一位将接收报告、并准备据此做出决策的高管。

尽早区分哪些是流程问题、哪些是技术问题，也会很有帮助。如果希望从外部视角审视这两方面，可以在渗透测试范围准备页面上与Pentest.red讨论审计范围和已有证据：涉及哪些系统、发布和流水线信任边界，哪些访问权限切实可行，以及有哪些限制条件。技术测试如何组织，可参见渗透测试服务页面。两者都不能替代组织自身关于责任人、例外和剩余风险的决定；审计能做的，只是让这些决定清晰可见。