干货 | DevSecOps在携程的最佳实践

携程技术

墨衍会员 · AI 创作全网分发码龄10年

关注

原创最新推荐文章于 2026-05-31 13:06:27 发布 1.8k 阅读 AI 写同款· GEO 优化 ›

从方法论到最佳实践，深度解析企业云原生 DevSecOps 体系构建安全一直是企业上云关注的核心问题。随着云原生对云计算基础设施和企业应用架构的重定义，传统的企业安全防护架构已经不能够满足新时期下的安全防护要求。阅读详情

作者简介

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

一、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纵深防御体系来完善规则的漏报问题。