安全左移理念，腾讯DevSecOps如何实践？

文｜腾讯研发安全团队

Martinzhou、Spine

引子

随着DevOps模式的落地，快字当头。研效提速也意味着出现安全漏洞的数量和概率随之上涨。过去安全风险的管控主要依赖于DAST类技术，即：采用黑盒测试技术，对待检查目标发起含检查用例的请求。

DevOps给这一模式带来了挑战，安全检查速度慢、周期长，容易给业务带来干扰，一定程度上有阻碍业务持续交付的风险。另据Capers Jones的研究结论：解决缺陷的成本，在研发流程中越靠后越高。

因此，安全机制的左移在开展DevSecOps建设时就变得更为重要了。左是指软件开发生命周期的早期，也就是设计、编码阶段。发生安全漏洞研发的早期阶段存在哪些问题？我们认为可以总结为三类：

(1) 开发人员不了解安全编写代码的知识

(2) 开发人员有一定安全意识，但因为赶进度或疏忽遗漏编写安全机制，或是错误地实现安全校验逻辑

(3) 代码编写是否安全仅凭开发人员自觉，缺乏检查和卡点机制

调研业界理念与实践基础上，团队进行了安全左移建设的探索，主要包括三个机制：面向开发人员的代码安全指南、默认安全框架组件、嵌入基础设施的代码安全检查。作为前述项目的参与者，我们想与业界同行分享交流其中的一些思考与经验。

Ⅰ. 代码安全指南

1.1 背景

首先是开发人员缺乏安全编写代码知识的问题。在开展日常安全运营过程中，常常会遇到如下与之关联的挑战：

一个业务被发现问题，如何把这种“踩坑”的经验沉淀下来，分享给其他业务以及新加入公司的同事？

如何帮助开发人员建立起安全编码意识，实现代码写出来就没有漏洞？

当检出安全漏洞时，如何给予开发人员详细、可操作的改进指引？

安全编码意识和漏洞修复指引，两份材料是否合二为一？

综合上述背景，去年梳理了一份统一代码安全指南。从开发人员视角讲述安全注意事项，并配套了丰富的代码示例。覆盖常见的8门编程语言，包括：C#、C,C++、Go、JavaScript、Java、Objective-C、PHP、Python。

1.2 设计理念

代码安全指南的内容呈树状结构展开，共分5层，如下：

 1.2.1 语言 

每种语言面临安全的风险种类不同，需要分别开展详述。如：go和javascript对比，go就不存在原型链污染的问题。

同时，由于公司内的代码风格规范亦分语言展开，安全规范采取相同的分语言方式能保持整体的连贯性。

 1.2.2 端 

这里的端是指不同的终端，如：Web、安卓客户端、iOS客户端、PC客户端。实践过程中，将内容按端区分的原因有：

1. 同一门编程语言，用在不同的终端应用开发，其面临的风险类型和数量有着天壤之别。

例如：

JavaScript应用于前端页面开发时，面临的主要风险是DOM XSS；但JavaScript亦可依托Node.js进行Web后端接口开发，如果编码不当，则存在命令注入、SQL注入等风险。

2. 大型互联网公司内，项目开发采取“流水线”化作业，分工往往精细明确，将不同端的场景作为主干目录，更便于开发人员检索、快速了解编码安全知识。

 1.2.3 场景

通过复盘历史漏洞，安全风险可按成因粗略归为两类：

1. 代码漏洞

指代码编写时，因不安全的API使用和逻辑编写产生的安全风险。

2. 运维漏洞

指代码的运行环境、配置和依赖等系统运维相关的安全风险。

如腾讯蓝军分享的《浅析软件供应链攻击之包抢注低成本钓鱼》一文，涉及的安全风险本质上是是：部分语言依赖包管理，当部分企业私有软件包仅在公司内部软件源注册时，攻击者就可以在外部公共软件源上抢注。

如果公司内员工使用包管理软件拉取时，未配置公司镜像源时，就会拉取到攻击者抢注的恶意包。

 1.2.4 功能 

在对内、外部发现的漏洞进行复盘过程中，我们发现安全风险与业务场景高度相关，例如：

由于代码安全指南的目标受众是开发人员看的。在撰写指南过程中，我们尝试将漏洞转化为功能场景，作为主干目录。由于与具体的业务场景关联，在开发时能更容易想起相关的注意事项，由此可降低认知、学习成本。

 1.2.5 API/sink点 

对于开发人员来说， 各类API是程序代码的基础组成部分。对安全团队来说，API也就是编写安全检查策略要收集整理的sink点。

1. 为什么要在代码安全指引中，枚举API/sink点？

对开发人员来说，API是实现业务逻辑时，高频接触对象。通常安全漏洞往往可归因为API的错误使用。对安全工程师来说，sink点是编写安全策略、组件是非常重要的一部分，直接决定了SAST系统的扫描能力。

业界也不乏类似的探讨，如Google在ICSE '21的论文《If It’s Not Secure, It Should Not Compile: Preventing DOM-Based XSS in Large-Scale Web Development with API Hardening》中，阐释了Google加固前端组件，使其Web页面能天然“免疫”DOM XSS漏洞的实践过程。

其中主要的思路是对.innerHTML等容易被误用产生安全问题的API做了加固，封装为前端组件中新的函数对象。形成了JavaScript公共库https://github.com/google/closure-library，并设计了对应的编译时检查工具。

自2018年在其内部逐步推广后，截止2020年Q2外部向Google报告全部漏洞类型中，DOM XSS已由原先的20%降低至2%。

在上述实践过程中，最为重要的一步是：XSS sink点的提取，也就是易被误用产生安全漏洞的API。