DevSecOps安全评估：如何检验流水线信任边、证据与复测

设想开发团队中的一个假设场景。一名开发人员提交了一个小而完全合法的修改：提交已签名，另一名工程师审查并批准了拉取请求，所有必需检查均已通过，代码本身没有任何问题。然而，CI工作流通过可变标签而不是固定引用来拉取第三方动作；作业被分配到一台由多个仓库共用的常驻自托管运行器上，而此前某个作业在缓存目录中留下了被篡改的构建工具；运行器向该作业发放了一个长期有效的云凭据，其权限远超构建所需。生成的镜像以可复用标签推送，凭借同一标签从预发布环境晋级到生产环境，再由一个可写入所有环境的部署身份完成发布。生产审批界面向审批人展示的是流水线摘要，而不是制品摘要值。每一项控制都显示为“绿色”，却没有人能够证明生产环境运行的正是经过审查的代码。

DevSecOps安全评估要揭示的正是这种缺口。真正有用的问题不是流水线中是否部署了安全工具，而是从提交到生产的每一条信任边是否受到约束、是否可观测、是否有证据支撑。本文说明如何界定此类评估的范围、以哪些公开参考资料为依据、如何安全地检验流水线信任边，以及如何评判服务商交付的证据。

DevSecOps安全评估涵盖哪些内容

DevSecOps安全评估同时考察两件事：一是交付过程能否在发布前后稳定地发现、排序并修复安全弱点；二是流水线本身是否值得信任，能否准确交付经过审查的内容。应用渗透测试在某一时间点检查约定范围内的应用，这一范围可能并不包括交付流水线；流水线评估考察的是软件抵达生产的路径，包括源代码管理、CI定义、运行器、密钥、构建输入、制品、镜像仓库、部署身份和环境关卡，以及把发现转化为风险决策的治理机制。

流程审计与技术评估

这两部分回答的是不同问题，不应在报告中混为一谈。流程审计关注每项控制由谁负责、例外由谁批准、哪些证据表明审批确实发生，审查对象是政策、职责矩阵、变更记录和例外日志。技术评估考察的是信任边本身：哪个身份可以推送代码，作业获得了什么令牌，运行器是否隔离，制品在构建后能否被替换，部署能否绕过审批。流程审计无法证明运行器是临时性的，技术测试也无法说明谁接受了残余风险。如果您主要关注治理层面，可参阅我们关于DevSecOps流程审计的指南，其中详细讨论了责任人、审批与证据。本文聚焦技术层面。

评估不是什么

评估或渗透测试不是认证、鉴证，也不是保证意见。其发现描述的是在约定范围内、某一时间点、经系统所有者书面授权后观察到的情况。任何技术测试都必须以书面授权、约定范围和约定规则为前提。本文不授予任何授权，也不包含漏洞利用操作说明。

标准与证据基础

没有任何一份公开文件能够单独构成完整的DevSecOps评估标准。站得住脚的方法会为每份参考资料分配角色，并在报告中保留每份资料的版本信息。

NIST SP 800-115：规划、执行与执行后

NIST SP 800-115《信息安全测试与评估技术指南》于2008年发布，取代了SP 800-42。它帮助组织规划和实施技术测试、分析发现并制定缓解策略，并结合各项具体技术的优势与局限加以讨论。其正式评估阶段为规划、执行和执行后三个阶段。NIST本身将该指南定位为关键要素概述，而非完整的测试项目方案；加之发布年代较早，它描述的是流程，而不是当前的CI工具。本文后文若介绍包含更多环节的修复循环，那是供日常使用的编辑性改编，并非NIST官方模型。

NIST SP 800-204D：CI/CD中的供应链安全

NIST SP 800-204D讨论如何将软件供应链安全集成到DevSecOps CI/CD流水线中。对评估人员而言，它提供了把流水线视为攻击面一部分、而非中性管道的依据：构建步骤、制品和部署都是具有各自信任关系的供应链控制。后续各节中的具体检查项是基于这一框架提出的编辑建议，并非对该文件的引述，也不是从中推导出的合规清单。

OWASP、CWE与CSF 2.0：角色而非清单

OWASP应用安全验证标准（ASVS）提供可验证的需求，带有v5.0.0-1.2.5这类版本化标识符，需求清单还以CSV、JSON等机器可读格式提供。项目提醒标识符可能随版本变化，因此必须固定版本。OWASP Web安全测试指南（WSTG）为说明执行了哪些Web测试提供统一术语，报告应注明所用版本以及是否采用了草案内容。OWASP Top 10是意识类文件，OWASP自己将其定位为迈向安全编码文化的第一步，因此“对照Top 10检查”达不到验证深度。MITRE的CWE Top 25依据公开CVE记录对严重且普遍的弱点进行排名；配套的Top 10 KEV弱点清单则依据CISA已知被利用漏洞（KEV）目录，对实际被积极利用的弱点进行排名。NIST CSF 2.0把技术结果转化为风险管理成果，配置文件用于描述当前状态和目标状态。

绘制流水线信任边

信任边是输入或权限在组件之间传递、且安全性取决于接收方如何验证和约束它们的位置。评估首先为范围内的交付路径绘制这些信任边，然后针对每一条提出问题：信任的是什么，什么会破坏这种信任，哪些证据表明这条边受到约束。下表汇总了本文后续讨论的信任边。

提交身份与审查

评估人员检查组织能否把每一次变更与可问责的身份以及覆盖最终内容的审查关联起来。相关证据包括分支保护设置、新提交出现时既有批准是否失效、谁拥有管理员绕过权限，以及是否要求并验证提交签名。有效签名只能确认使用了相应密钥，不能证明变更安全。要归因到具体人员，还需核实密钥与身份的绑定关系及密钥保管情况。这也是开篇场景从一个完全有效的提交开始的原因。

CI定义与第三方动作

流水线定义是带有特权运行的代码，理应接受与应用代码同等的审查。评估人员检查谁能修改工作流文件、此类修改是否需要单独批准、第三方动作或插件是否固定在不可变引用而非可移动标签上，以及每个作业默认申请哪些权限。如果工作流可以在它所把关的同一个拉取请求中被修改，那就相当于自己审查自己。

托管运行器与自托管运行器

托管运行器把隔离责任转移给服务提供方，但仍需审查每个作业获得的网络访问和凭据。自托管运行器则完全由组织负责。评估人员检查运行器是临时的还是常驻的，是否由信任级别不同的多个仓库共用，来自复刻或不受信任分支的作业能否调度到其上，以及运行器在内部网络中可以访问哪些资源。一台同时服务公开仓库和生产部署流水线的常驻运行器，是最值得优先检查的信任边。

密钥发放与权限范围

评估人员梳理密钥如何进入作业：存储在CI系统中的静态值、通过工作负载身份联合签发的短期令牌，或在运行时从密钥库获取的凭据。对每一种方式，都要关注有效期、权限范围、哪些分支和事件可以申请，以及密钥值是否可能通过日志、制品或缓存泄露。按作业签发、范围狭窄的短期凭据可以降低被攻陷步骤造成的损害，但并不能免除检验该步骤实际能力的必要。

构建输入、制品与镜像仓库晋级

构建所消耗和产出的一切，都可能切断经过审查的源代码与运行中软件之间的联系。这部分评估与更广泛的软件供应链安全评估有所重叠，后者还涵盖流水线之外的供应商和第三方组件。

依赖与构建输入

评估人员检查依赖版本是否锁定并经过校验，构建能否从任意公共来源下载还是只能使用经批准的镜像源，基础镜像如何选择和更新，以及缓存是否可能把内容从一个作业或分支带到另一个作业或分支。目的是确认组织能否准确还原某个制品究竟使用了哪些输入。

制品来源与不可变性

制品应能通过内容摘要值唯一识别，并附有来源记录，说明它由哪份源代码、哪个工作流和哪个构建器生成。评估人员检查此类记录是否存在，是否由构建系统而非开发人员可编辑的步骤生成，下游环节是否对其进行验证，以及已发布的制品能否被覆盖。没有人验证的来源记录只是文档，而不是控制。

镜像仓库晋级

从一个环境晋级到下一个环境，通常通过重新打标签实现。评估人员检查晋级是否引用不可变的摘要值，晋级的制品是否正是通过测试的那一个，谁可以直接推送到生产仓库，以及标签能否被移动或删除。如果生产环境可以接收从未经过预发布环境的制品，那么预发布关卡就只是建议性的。

部署身份、环境与基础设施即代码

最后一批信任边位于流水线与其所变更的环境之间。

部署身份

评估人员检查哪些身份可以变更各个环境，是否存在一个身份可以部署到所有环境，哪些流水线和分支可以承担生产身份，以及这些权限是否有时间限制。按环境分离部署身份，可以限制低等级环境中被攻陷的作业所能触及的范围。

环境审批

审批关卡的强度取决于它展示的信息以及绕过路径是否被堵住。评估人员检查谁有审批权，变更作者能否批准自己的部署，审批人看到的是制品摘要值和变更集还是仅仅一份摘要，以及能否通过工作站直接部署或经由另一条流水线跳过关卡。

IaC扫描能证明什么、不能证明什么

基础设施即代码的静态扫描可以发现源文件中的配置错误，但无法证明线上环境与源代码一致：手工修改、紧急修复和未纳管资源都会造成漂移。要主张生产环境反映的是经过审查的IaC，评估人员需要以只读方式从线上环境获取证据，并与声明状态进行比对。我们关于基础设施即代码安全评估的指南对这种比对有详细说明。并非每个暴露的端点都是问题：真正公开的端点，例如公开下载页或状态页，可能本就设计为无需认证。评估人员需要确认这种暴露是有意为之且有记录，并确认该端点不提供构建、部署或管理功能。

安全的否定测试与复测

配置审查说明的是声明了什么，否定测试说明的是实际执行了什么，它们是技术评估的核心。

设计安全的否定测试

否定测试是在书面授权和约定规则范围内，尝试执行一项本应被正确配置的控制拒绝的操作。例如：确认由复刻触发的作业无法读取受保护的密钥；未签名或未经测试的制品无法晋级到受保护环境；在指定的非生产仓库中无法覆盖已有标签；低等级环境的部署身份在生产环境中被拒绝；检查一个作业留下的无害标记是否对下一个作业可见，并将结果与运行器生命周期记录和隔离设置相互印证。单个标记不可见，本身并不能证明运行器已被完全清理或替换。测试应当是非破坏性的，使用约定的测试资产，在约定时间窗口内进行，并把尝试的操作和被拒绝的结果一并记录为证据。目标是验证控制是否得到执行，而不是利用其弱点。

复测与关闭证据

只有当复测表明原有的否定测试现已被拒绝、且在既定复测范围内检查的相邻路径中未观察到绕过时，发现项才算关闭。关闭证据应写明重复执行的测试、修复所对应的配置或代码变更，以及复测的日期和范围。我们关于漏洞修复管控的文章说明了如何长期跟踪并证明修复效果。下面的循环是供实际使用的编辑性改编，并非NIST官方模型；SP 800-115的正式阶段仍是规划、执行和执行后。

1. 规划约定范围、信任边、测试资产和书面授权
2. 执行审查配置，并对明确授权且适合测试的信任边开展否定测试
3. 分析记录行为、影响、适用的CWE或控制类别以及负责人
4. 修复修正控制本身，而不只是修补发现的单个实例
5. 复测重复原有测试，并把被拒绝的结果记录为关闭证据

发现、证据与验收

只有当发现项可以追溯、可以跨时间比较、并能依据明确标准接受或拒绝时，流水线评估才真正有价值。下表列出评估人员应当期待的证据，以及不应被视为替代证据的内容。

发现项规范与可追溯性

每个发现项都应包含适用的CWE标识符或受影响的控制类别、受影响的信任边、适用时带版本的ASVS引用、明确的负责人、修复计划以及验证修复的方法。SP 800-115强调分析发现并制定缓解策略，而一份工具告警清单两者都做不到。反复出现的弱点类别应促使流水线设计层面的改变，而不是产生源源不断的相同工单。

排序视角：CWE Top 25与KEV

CWE Top 25反映公开CVE记录中弱点的严重性与普遍性，基于KEV的弱点清单反映实际观察到的利用情况。两者结合，可以为优先级排序提供外部起点。但它们都不描述特定组织的代码或流水线，最终顺序应由组织自身的发现、暴露面和业务背景决定。

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

数字化的成熟度评分看似精确，但在流水线评估中，它通常只是把主观判断换算成数字。本文不会把此类评分作为实测结果呈现。如果服务商使用评分模型，应询问每个分值的依据是什么、其他评估人员能否复现，以及哪些发现会改变该分值。对CISO而言，一份清晰列出已测试信任边、观察到的行为和未关闭风险的清单，比一个缺乏解释的数字更有用。

取舍与局限

时效性：SP 800-115发布于2008年，描述的是流程，而非现代CI平台。

版本变动：ASVS标识符可能随版本变化，WSTG同时存在稳定内容和草案内容，因此未固定版本的报告无法在不同周期之间比较。

广度与深度：Top 10这类意识文件只设定较浅的基线，而需求级验证和否定测试需要更多时间和访问权限。

Web导向：大多数OWASP资料聚焦于应用，运行器、令牌和镜像仓库需要流水线专属的框架以及平台自身的文档。

数据边界：CWE清单来源于公开CVE记录，只能作为初始依据，而不是内部代码的画像。

时间点：评估反映的是工作期间观察到的配置，而流水线变化很快。

安全限制：非破坏性测试有意在完整利用之前停止，因此部分影响结论是经过推理得出而非实际演示的，报告应明确说明这一点。

如何选择DevSecOps安全评估服务商

采购DevSecOps评估服务时，应要求服务商在方案中区分流程审计与技术测试，说明所用参考资料及其版本，并描述将检验哪些信任边以及如何检验。

应当提出的问题

• 哪些交付路径、仓库、运行器和环境在范围内，哪些被排除？
• 哪些信任边将通过安全的否定测试检验，哪些只做文档审查？
• 使用哪个版本的ASVS和WSTG，发现项如何映射到CWE？
• 线上环境证据如何与基础设施即代码进行比对？
• 书面授权、约定规则、测试资产和数据处理如何记录？
• 是否包含修复复测，将提供哪些关闭证据？
• 评估结果如何对应CSF 2.0成果或组织的风险登记册？

警示信号

以下情况都应引起警惕：把“Top 10合规”作为唯一交付物；参考资料不注明版本；只提供未经分析的扫描器导出结果；给出一个不加解释的成熟度评分；或暗示报告可以证明流水线是安全的。服务商关于认证、经验和过往成果的说法应独立核实。如果流水线变更与产品发布同时进行，我们关于产品上线前渗透测试的指南中关于时间安排的问题同样适用。如需与Pentest.red沟通，可以先在渗透测试范围页面整理仓库、运行器、环境和限制条件。

实用决策框架

以下步骤把方法转化为具体决策，既适用于内部自评，也可用于编写工作说明书。

• 依据CSF 2.0确定风险背景：评估需要支撑哪些成果，哪些交付路径最为关键。
• 区分流程审计与技术评估，并为两部分分别指定负责人。
• 为范围内的每条路径绘制从提交到生产的信任边。
• 固定参考资料版本：ASVS需求集合、WSTG版本和CWE清单。
• 针对每条信任边规划技术手段，记录目的、优势和局限，并选定安全的否定测试。
• 在测试开始前确定验收标准和关闭证据。
• 根据内部团队已能用证据证明哪些信任边，在自建、外包或混合模式中做出选择。
• 修复后进行复测，并在流水线或参考资料版本变化时重新评估。

如果内部团队无法用证据证明各条信任边，开展外部技术评估是合理的；如果能够证明，则对风险最高的信任边进行有针对性的外部验证可能就已足够。

结论：让评估可重复

可重复的DevSecOps安全评估会区分流程审计与技术测试，以SP 800-115和SP 800-204D为方法依据，让OWASP、CWE和CSF 2.0各司其职，对明确获准且适合测试的信任边使用安全的否定测试，对其余信任边则审查配置与证据。固定的版本、可追溯的发现项和复测证据，使结果在不同周期之间可以比较。开篇那条假设的流水线通过了所有检查；好的评估，恰恰会追问经过审查的提交能否被证明就是生产环境中运行的制品。