DevSecOps在携程的最佳实践

一、DevSecOps 面临的挑战

作为业务覆盖机票、酒店、度假、汽车票、火车票、支付等各个方面，为全球用户提供服务的在线旅游网站，携程每周都会有数以万计的应用发布次数，如何保证每一次发布代码的安全性成为了 DevSecOps 实践中最大的挑战。

不同于软件行业的 SDL，DevOps 和微服务在互联网行业的兴起使得安全不再是安全团队可以独立完成的任务，如何把安全嵌入 DevSecOps 的每一个流程，保证代码的安全，首先面临的问题是人力。

在软件行业，一个版本的发布从涉及到开发、测试、发布动辄数月，每个版本的发布都可以按照 SDL 流程完整地做一次安全评估，包括需求评审、威胁建模、安全开发、安全扫描。而在 CI／CD 模型下，每天都有几千次的发布，持续集成、持续部署，如何避免持续引入漏洞，仅仅靠人力是无法解决的。

另一个很重要的问题是如何培养安全意识——避免两次踩进同一个坑。相信做安全的同学都会遇到这样的问题：昨天刚找开发修了一个 SQL 注入，今天又写了另一处有注入的接口；昨天刚补了一处撞库接口，今天又来了一个验证码绕过。安全沦为救火队长，疲于奔命。其实本质还是需要提高业务团队的整体安全意识，避免安全变成被动的修补角色。

第三个问题是安全项目的推动难，对于安全工程师来说最差的体验是，“在甲方提工单和在乙方贴发票”。为什么推动这么困难，原因在于对业务团队来说这似乎是增加了额外的工作量，仅仅是修复一个漏洞就需要开发、测试甚至产品一起沟通拉齐，确定修复方案、排期，更不要说大规模的推动底层的框架、中间件的升级，一轮一轮的推动更是难上加难。而解决这些需要与公司框架、与 CI／CD 流程更紧密的结合，提供温和嵌入流程的默认安全方案。

二、携程 DevSecOps 实践

2.1 安全团队建设 &安全意识培养

今年年初我们在携程内部组建了安全 BP 制，即每个事业部指定一名安全负责人，负责 BU 内部的安全事项，协助安全部推动研发团队的安全建设。担任安全 BP 的通常是研发团队的开发 leader 或者测试 leader。指定安全 BP 的好处在于：安全 BP 作为 BU 研发团队成员，更了解 BU 内部开发测试流程，相比安全部门能够更方便推动 BU 内部的安全项目落地。安全 BP 也是 DevSecOps 流程里面安全左移的重要角色，让安全更早介入 DevOps 流程。

在携程内部安全 BP 的运作方式是每月有一次各 BU 安全 BP 的交流会，安全部会在 BP 会上提出需要 BP 协助推动的工作，同时 BP 也会反馈安全建设遇到的各种问题，以及提出安全诉求。

目前在携程内部通过 BP 推动落地的项目有 IAST、fastjson 升级等。以 IAST 项目的落地为例，如果没有安全 BP，推动接入 IAST 的流程就是安全部->应用负责人。对于应用负责人来说，大多数不了解也不理解安全项目的需求，推动难度可想而知。

而在有安全 BP 的场景下，对接流程变为了安全部->安全 BP->应用负责人，安全 BP 以提升自身业务安全的角度去推进，解决了安全与研发之间的矛盾，从而更加高效地推动安全项目的落地。安全 BP 作为安全部门与业务研发部门之间沟通的桥梁，也向安全部反馈了项目落地中遇到的问题以及 BU 的诉求。比如说安全部的 Web 黑盒扫描，对于 BU 来说，需要解决扫描过程中产生脏数据的问题，这样的诉求都是通过 BP 来反馈到安全部的。

2.2 安全评审 &威胁建模

作为 DevSecOps 计划阶段重要的一环，威胁建模在携程的实践方式是对接公司内部的看板团队协作平台，面对各业务产品经理（即用户）。用户在看板平台上提交需求的时候，可以按照业务场景选择威胁建模的场景，系统根据内置模型中每种（业务）场景对应的威胁给出缓解措施。其对应关系是：

场景——标签（多对多）

标签——威胁（一对多）

威胁——缓解措施（一对一）

场景和标签的对应关系如下：

以“爆破”这个标签为例，“爆破”对应的（业务）场景有“登录”、“注册”、“忘记密码”、“验证码”、“支付”，而“登录”、“注册”、“忘记密码”、“验证码”这几个场景又同时对应了“用户名猜解”的标签，这就形成了多对多的关系。

在标签与威胁的对应关系上，“爆破”标签对应的威胁有“验证码爆破”和“万能验证码”，具体的威胁模型如下：

威胁建模里的标签和场景都是可以复用的模型，以这样的方式，我们可以建立几十种常见业务场景的威胁模型，从而实现威胁建模的自动化。产品经理在创建需求的时候，只要勾选对应场景即可自动完成建模并给出风险提示和对应的缓解措施。

2.3 SCA

SCA（Software Composition Analysis），第三方组件的安全检查。作为携程落地比较早的项目，在应用 CI 的过程中进行扫描分析，对于扫描发现中高危级别漏洞的应用就会进行发布的拦截。在项目的初期，最大的问题是动辄上万的漏洞告警，哪些漏洞需要修复，哪些漏洞不需要修复，哪些需要优先修复。

为了解决漏洞修复问题，我们进行了一些维度的划分，包括：

• 漏洞等级（高、中、低）

• 对应CVE是否有POC

• 应用内外网属性

对于外网应用中有 POC 的漏洞会优先修复，而内网应用和没有 POC 的漏洞紧急性会比较低。除此之外，还按照漏洞归属进行了划分，区分框架漏洞和应用漏洞。对于框架引入的第三方组件漏洞，会协调公司内部框架修复。通过这样的方式减少了大量的漏洞告警，使得 SCA 嵌入 CI/CD 流程对发布流程的影响降到最低。

2.4 SAST

SAST（Static Application Security Testing）静态应用测试，对应的是研发阶段的代码扫描。在携程，SAST 有两套不同的代码扫描引擎，一个是基于文本扫描的正则规则扫描，一个是基于构建的数据流、控制流扫描。

正则扫描用于在 CI/CD 流程中的快速检测，每个项目的扫描时间平均在 10 秒左右，可以完全串入 CI/CD 流程，对于开发流程几乎不会增加额外的时间。正则扫描代码的好处在于快速，这也就意味着可以用于应急响应中的全量代码扫描，比如说对于一些代码中配置的扫描或者特殊函数的调用检测。

同时其缺点也很明显，对于一些需要理解代码上下文的漏洞误报率高，比如 SQL 注入。对于这样的漏洞，使用正则扫描器扫到不会直接推给开发，而是会先经过安全运营的确认。在漏洞确认前，CI/CD 流程不会被阻拦，漏洞确认后如果下一次扫描仍然扫到同样漏洞才会拦截。

基于数据流、控制流的代码扫描与 CI/CD 流程的关系可以说是“旁路”。在 CI/CD 的过程中，代码同步进行扫描，但 CI/CD 不会等待扫描结束。因为扫描时间通常较久，根据项目的代码量从几分钟到几十分钟不等。这种扫描对于 SQL 注入、命令执行这样的漏洞检测准确率是比较高的，在我们优化过规则之后准确率可以到 95%以上。对于这部分扫描到的漏洞，会通过内部的漏洞管理平台提交给代码 owner 进行修复。

关于白盒扫描的规则优化

误报：在内部 SAST 平台上，我们会统计每个类型规则的准确率，并且定一个阈值（比如 90%），对于准确率超过阈值的规则，后续扫出来的漏洞都会直接推送给代码 owner 进行修复。而准确率低于阈值的规则，则会先经过安全内部运营审核，确认之后再推送，以确保推送给开发的安全漏洞不会有太多误报。此外，在运营的过程中不断地提炼规则，提高准确率，当准确率达到直接推送的准确率后就会完全自动化运行，降低安全运营的人力成本。

漏报：对于通过其他渠道检测到而白盒扫描未检测到的漏洞，如果是通用代码漏洞规则未能覆盖的，通常是因为应用代码使用了内部框架提供的 api，对应数据流的 source 和 sink 未能被通用规则覆盖。这部分漏洞我们会针对内部框架增加对应的 source 和 sink 规则，以提高白盒扫描的漏洞覆盖率，通过外部白帽子、src、iast、dast、dbaudit 等 sdl 纵深防御体系来完善规则的漏报问题。

2.5 IAST/DAST

IAST/DAST 在携程的实践是 IAST agent 被动检测+分布式扫描器主动扫描的方式。可以分为这么几个部分：

1）IAST agent

集成到测试环境应用 docker 容器的 agent，hook tomcat 底层调用，用来检测应用中的漏洞，同时会把所有访问到应用 docker 的 http 流量复制回传到用于收集流量的 kafka 队列。

2）IAST 服务端

管理 IAST agent 和漏洞的控制台。

3）流量 kafka 队列

用于收集待扫描的流量，除了从 IASTagent 回传的流量，还有来自主动爬虫、chrome 插件以及提测平台调用 api 发送过来的流量。

4）分布式扫描器

消费 kafka 里的流量并且按照 url 去重，调用扫描器进行漏洞扫描。

这样一套架构的好处在于：

• 扫描覆盖率高：只要正常功能测试能覆盖的流量都能被扫到

• 漏洞检出率高：IAST+DAST双重检测

• 误报率低：IAST的特性决定的低误报

这套扫描系统在少量应用灰度期间就发现了内部存在已久未被发现的通用型漏洞，对于内部安全检测能力的补齐提供了很好的帮助。

2.6 漏洞管理

作为 DevSecOps 流程中重要的一环，漏洞管理平台是不可或缺的一部分，携程内部使用的自研漏洞平台实现了从漏洞发现、修复，到复盘的整个流程跟踪。漏洞管理流程包括：

1）漏洞跟踪

从漏洞发现生成工单到修复完成关闭工单。

2）漏洞统计

按漏洞类型、时间、严重等级、来源各个维度进行统计和分析。

3）漏洞复盘

携程内部对于内外部发现的漏洞都会进行复盘。对于外部漏洞，会复盘内部工具、流程是否能发现，记录未能发现的原因和改进措施。对于内部发现的漏洞，比如黑盒扫到的漏洞，会考虑白盒是否也能发现。如果不能，是否可以通过改进规则发现，通过这样的方式提高内部工具的漏洞检出率。

目前在携程 SAST、SCA 每周的扫描量约 3 万任务数，安全评审数量每周约 100，内部发现的漏洞数占全部漏洞数的 95%以上，其中 99%以上为工具自动发现，漏洞闭环率 100%。

总的来说，DevSecOps 的关键在于嵌入 CI/CD 流程，更少地对开发流程的阻碍、自动化的测试工具以及与业务研发更紧密的合作。

作者介绍：

Living，携程高级基础安全工程师，关注应用安全、渗透测试方面的技术。

本文转载自公众号携程技术（ID：ctriptech）。

原文链接：

https://mp.weixin.qq.com/s?__biz=MjM5MDI3MjA5MQ==&mid=2697270150&idx=1&sn=94d056f478f5c4d3d336e692fcc3f897&chksm=8376ecb2b40165a46723c2747fe46b89e8aa57f49ebe6a733674560a25f875b2df4261862333&scene=27#wechat_redirect