Living，携程高级基础安全工程师，关注应用安全、渗透测试方面的技术。
作为业务覆盖机票、酒店、度假、汽车票、火车票、支付等各个方面，为全球用户提供服务的在线旅游网站，携程每周都会有数以万计的应用发布次数，如何保证每一次发布代码的安全性成为了DevSecOps实践中最大的挑战。不同于软件行业的SDL，DevOps和微服务在互联网行业的兴起使得安全不再是安全团队可以独立完成的任务，如何把安全嵌入DevSecOps的每一个流程，保证代码的安全，首先面临的问题是人力。在软件行业，一个版本的发布从涉及到开发、测试、发布动辄数月，每个版本的发布都可以按照SDL流程完整地做一次安全评估，包括需求评审、威胁建模、安全开发、安全扫描。而在CI／CD模型下，每天都有几千次的发布，持续集成、持续部署，如何避免持续引入漏洞，仅仅靠人力是无法解决的。另一个很重要的问题是如何培养安全意识——避免两次踩进同一个坑。相信做安全的同学都会遇到这样的问题：昨天刚找开发修了一个SQL注入，今天又写了另一处有注入的接口；昨天刚补了一处撞库接口，今天又来了一个验证码绕过。安全沦为救火队长，疲于奔命。其实本质还是需要提高业务团队的整体安全意识，避免安全变成被动的修补角色。第三个问题是安全项目的推动难，对于安全工程师来说最差的体验是，“在甲方提工单和在乙方贴发票”。为什么推动这么困难，原因在于对业务团队来说这似乎是增加了额外的工作量，仅仅是修复一个漏洞就需要开发、测试甚至产品一起沟通拉齐，确定修复方案、排期，更不要说大规模的推动底层的框架、中间件的升级，一轮一轮的推动更是难上加难。而解决这些需要与公司框架、与CI／CD流程更紧密的结合，提供温和嵌入流程的默认安全方案。
今年年初我们在携程内部组建了安全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来反馈到安全部的。
作为DevSecOps计划阶段重要的一环，威胁建模在携程的实践方式是对接公司内部的看板团队协作平台，面对各业务产品经理（即用户）。用户在看板平台上提交需求的时候，可以按照业务场景选择威胁建模的场景，系统根据内置模型中每种（业务）场景对应的威胁给出缓解措施。其对应关系是：
以“爆破”这个标签为例，“爆破”对应的（业务）场景有“登录”、“注册”、“忘记密码”、“验证码”、“支付”，而“登录”、“注册”、“忘记密码”、“验证码”这几个场景又同时对应了“用户名猜解”的标签，这就形成了多对多的关系。在标签与威胁的对应关系上，“爆破”标签对应的威胁有“验证码爆破”和“万能验证码”，具体的威胁模型如下：
威胁建模里的标签和场景都是可以复用的模型，以这样的方式，我们可以建立几十种常见业务场景的威胁模型，从而实现威胁建模的自动化。产品经理在创建需求的时候，只要勾选对应场景即可自动完成建模并给出风险提示和对应的缓解措施。
SCA（Software Composition Analysis），第三方组件的安全检查。作为携程落地比较早的项目，在应用CI的过程中进行扫描分析，对于扫描发现中高危级别漏洞的应用就会进行发布的拦截。在项目的初期，最大的问题是动辄上万的漏洞告警，哪些漏洞需要修复，哪些漏洞不需要修复，哪些需要优先修复。为了解决漏洞修复问题，我们进行了一些维度的划分，包括：
对于外网应用中有POC的漏洞会优先修复，而内网应用和没有POC的漏洞紧急性会比较低。除此之外，还按照漏洞归属进行了划分，区分框架漏洞和应用漏洞。对于框架引入的第三方组件漏洞，会协调公司内部框架修复。通过这样的方式减少了大量的漏洞告警，使得SCA嵌入CI/CD流程对发布流程的影响降到最低。
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纵深防御体系来完善规则的漏报问题。
IAST/DAST在携程的实践是IAST agent被动检测+分布式扫描器主动扫描的方式。可以分为这么几个部分：集成到测试环境应用docker容器的agent，hook tomcat底层调用，用来检测应用中的漏洞，同时会把所有访问到应用docker的http流量复制回传到用于收集流量的kafka队列。用于收集待扫描的流量，除了从IASTagent回传的流量，还有来自主动爬虫、chrome插件以及提测平台调用api发送过来的流量。消费kafka里的流量并且按照url去重，调用扫描器进行漏洞扫描。
- 扫描覆盖率高：只要正常功能测试能覆盖的流量都能被扫到
这套扫描系统在少量应用灰度期间就发现了内部存在已久未被发现的通用型漏洞，对于内部安全检测能力的补齐提供了很好的帮助。
作为DevSecOps流程中重要的一环，漏洞管理平台是不可或缺的一部分，携程内部使用的自研漏洞平台实现了从漏洞发现、修复，到复盘的整个流程跟踪。漏洞管理流程包括：按漏洞类型、时间、严重等级、来源各个维度进行统计和分析。携程内部对于内外部发现的漏洞都会进行复盘。对于外部漏洞，会复盘内部工具、流程是否能发现，记录未能发现的原因和改进措施。对于内部发现的漏洞，比如黑盒扫到的漏洞，会考虑白盒是否也能发现。如果不能，是否可以通过改进规则发现，通过这样的方式提高内部工具的漏洞检出率。
目前在携程SAST、SCA每周的扫描量约3万任务数，安全评审数量每周约100，内部发现的漏洞数占全部漏洞数的95%以上，其中99%以上为工具自动发现，漏洞闭环率100%。总的来说，DevSecOps的关键在于嵌入CI/CD流程，更少地对开发流程的阻碍、自动化的测试工具以及与业务研发更紧密的合作。【推荐阅读】
关注公众号：拾黑（shiheibook）了解更多
[广告]赞助链接：
四季很好，只要有你，文娱排行榜：https://www.yaopaiming.com/
让资讯触达的更精准有趣：https://www.0xu.cn/
携程安全应急响应中心
关注网络尖刀微信公众号
