干货 | 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计划阶段重要的一环，威胁建模在携程的实践方式是对接公司内部的看板团队协作平台，面对各业务产品经理&