Gitlab的“DevSecOps发展蓝图”概览

引子

印象中，Gitlab作为Github的竞品，是一款“仓库管理系统”。但，士别三日，当刮目相看。

2018年，Gitlab获谷歌母公司Alphabet投资，已拥有高盛、NASA、洛克希德马丁、拜耳、索尼等一众知名企业在内的客户。

图：Gitlab典型客户

背靠雄厚资本，All in DevOps。如今，Gitlab想成为贯穿企业研发流程的“全能助手”。

作为DevOps的重要一环，Gitlab公布的发展蓝图中，亦有对DevSecOps的布局。值得注意的是，其披露的对标厂商，包括：Fireeye、赛门铁克、Rapid7等一众知名传统安全公司，可谓“雄心勃勃”。

基于公开信息，笔者试图一探究竟。

一、总览：围绕“发布前安全检查、运营时纵深防御”设计

Gitlab的将DevOps分为10个阶段，包括：研发管理（Manage）、项目规划（Plan）、编码开发（Create）、项目验证（Verify）等。其中，安全相关的环节独占两席。分别是安全检查（Secure）和纵深防御（Defend）。

从布局上看，可将Gitlab的DevSecOps理念概括为，“发布前安全检查、运营时多维防御”。

安全检查手段方面，按重要性可分为“三大梯队”。重点投入四大模块，并计划一年内落地成熟解决方案，包括：静态应用安全测试（SAST）、应用依赖安全检查（Dependency Scanning）、容器安全扫描（Container Scanning）和授权协议管理（License Management）。与此同时，将敏感信息检查（Secret Detection）和动态应用安全测试（DAST）作为次重点发展。此外，还关注并计划开发交互式应用安全检测（IAST）、模糊测试（Fuzzing）和漏洞情报库（Vulnerability Database）。

安全防御手段方面，Gitlab希望在一年后基本可用，但整体优先级低于安全扫描。涉及7大功能模块，包括：RASP、WAF、威胁检测、行为分析、数据防泄漏（丢失）、容器网络安全、漏洞管理。

二、安全检查（Secure）方案概览

作为一家从开源起家的机构，Gitlab在建设安全检查手段过程中，并大量使用成熟的优秀开源解决方案，且希望对客户保持细节的透明。这点在SAST功能的实现上有直接体现，详参见2.1。

Gitlab的另一个愿景是，“将安全更好的揉入开发”。正如官方文档的一段原话所述，“Our goal is to provide SAST as part of the standard development process. This means that SAST is executed every time a new commit is pushed to a branch. ” Gitlab希望让安全检查手段融入DevOps流水线，与开发能更紧密贴合。即，每一次变更，都能经过安全扫描。通过DevOps“流水线”式的统一自动化手段，使安全真正意义上成为开发的标准环节之一。

在此领域，Gitlab给出的对标友商有：Synopsys、IBM Appscan、Qualys、Rapid7等。

2.1 静态应用安全测试（SAST）

SAST可以理解为“白盒扫描”，功能上，能自动检查项目每次新提交（Commit）的代码。

Gitlab的SAST功能主要依赖使用流行的开源项目，与CI/CD流水线联动，已面向用户开放使用。目前，支持包括Go、PHP、JavaScript、Node.js等在内的14种语言。概览如下：

总体来说，上述项目核心都依赖字符串或正则匹配敏感函数/缺陷代码特征。受篇幅限制，做简单导览：

2.1.1 Node.js

引用项目地址：https://github.com/ajinabraham/NodeJsScan

基于开源项目NodeJsScan，支持远程命令执行、远程代码注入、SSRF、路径穿越、任意URL跳转XSS、SQL注入等漏洞检测，特征存储于./core/rules.xml文件中。

图：NodeJsScan的SAST扫描规则

2.1.2 JavaScript

引用项目地址：https://github.com/nodesecurity/eslint-plugin-security

将JS独成一类，基于ESLint security plugin，原本以为是针对DOM XSS等问题的，仔细看项目简介也是用来扫描Node.js漏洞的，覆盖的类型少于NodeJsScan，特征以独立文件形式存储于./rules目录下。

其依托的ESLint，适用于检查所有场景的JS代码（比如：前端js、Node.js），但偏向语法规范检查，感兴趣可以看这里：https://cn.eslint.org/。

2.1.3 Python

引用项目地址：https://github.com/PyCQA/bandit

基于开源项目bandit，支持命令注入、SQL注入、以及特定框架漏洞（如，Django XSS）等漏洞检测。特征以独立插件形式，存储于./bandit/plugins目录下。

2.1.4 PHP

引用项目地址：https://github.com/FloeDesignTechnologies/phpcs-security-audit

基于开源项目phpcs-security-audit，项目较老切更新频率较慢，支持检查常见危险函数、框架通用漏洞等问题，特征位于./Security/Sniffs目录下。

2.1.5 Go

引用项目地址：https://github.com/securego/gosec

基于开源项目Gosec，项目更新频率高，支持SQL注入、SSRF等常见应用漏洞检测，特征位于./rules下。

从分析结果来看，现阶段，Gitlab的SAST已经比较全的覆盖了各类程序语言，不过质量效果良莠不齐。总体来说，可作为企业自研SAST、建设白盒扫描样本库的参考之一。

2.2 动态应用安全测试（DAST）

DAST可以理解为“黑盒扫描”，也就是为人熟知的“扫描器”。

DAST功能主要借助OWASP ZAProxy项目实现，依赖爬虫。默认情况下，是做“安全基线检查（ZAP Baseline Scan）”，简单来说就是，检查不会对服务产生影响的漏洞类型，比如：缺失Content-Type头、未添加CSRF Token防护、内网IP信息泄漏等。而SQL注入、命令注入等探测请求可能会产生影响的漏洞，需要用户配置确认后才会扫描，被称之为“主动扫描（Active Scan）”。

功能上，Gitlab DAST也支持用户自定义登陆认证信息、要扫描的URL等。使用方式见：https://docs.gitlab.com/ee/user/application_security/dast/index.html#manual-job-definition-for-gitlab-114-and-earlier-deprecated。

2.3 依赖库扫描

依赖库扫描（Dependency Scanning）主要用来检查，程序使用的第三方库是否存在安全风险。以此更好地发现已知的pip、npm包污染的情况。

主要依赖名为gemnasium的项目，该团队已经被Gitlab收购。目前，有关功能已面向用户开放，支持5种语言对应的6种包管理形式，Python、Ruby、PHP、Java和JavaScript（npm和yarn）。概览如下：

2.4 容器安全扫描（Container Scanning）

因为DevOps流水线高度依赖容器技术，容器安全扫描（Container Scanning）通过使用clair和clair-scanner两个项目，能检查容器使用的镜像是否存在已知的通用CVE漏洞。效果如下：

图：Gitlab容器安全扫描效果

2.5 授权协议管理（License Management）

主要用来自动化检查项目引用组建使用的授权协议，做交互式提醒，主要用于规避法务风险。

2.6 交互式安全测试（IAST）

交互式安全测试（IAST）原理是将RASP类似技术与动态安全扫描（DAST）组合联动。扫描的同时，监测程序内部处理扫描请求的逻辑，以此更精确有效的发现漏洞。

目前，Gitlab在该方向的功能细节，仍在规划中。进展可参见：https://gitlab.com/groups/gitlab-org/-/epics/344。

2.7 模糊测试（Fuzzing）

Gitlab在这块的规划和说明仍不明晰，从现有材料上看，希望提供发现应用未知的安全缺陷的能力，已将OSS-Fuzz和Peach Fuzzer纳入考察队列。

2.8 漏洞情报库/信息管理库（Vulnerability Database）

主要用来收录漏洞/安全情报，帮助上述包括SAST、DAST、容器安全扫描等在内的功能，更快、更全面的覆盖所有已知的安全风险。

三、安全防御（Defend）方案

安全防御方面，还处在调研期，Gitlab均还没有明确的计划和可供体验的功能。从公开资料上来看，整体优先级低于安全扫描（Secure）。不过，已经确定要做7方面的建设，包括：RASP、WAF、威胁检测、行为分析、数据防泄漏（丢失）、容器网络安全、漏洞管理。

在此领域，Gitlab给出的对标厂商有：赛门铁克、Fireeye等。

四、总结与思考

1. 排除营销夸大的成分，Gitlab现有的安全解决方案还不足以抗衡老牌的专业安全公司产品。
2. 整体上看，Gitlab也可以考虑将安全函数库（开发框架）、安全开发规范融入DevOps流程中。
3. 对我个人来说，继续“刷新”，了解新技术和方向。去探索、熟悉新项目，它们是怎么做的、该怎么做的更好。对团队或企业来说，Gitlab的布局仅作为参考，可以有独立的思考、布局和节奏。
4. 扫描和防护是做安全的两种最根本的手段，但结合不同场景，可以发挥愈来愈好的效果。比如SAST、DAST本质上仍然是黑白盒扫描，不过结合DevOps，增强安全手段的“自动化”和“强制性”（意味着，每次发布都自动做扫描），避免人为的“惰性”和疏忽，可以取得更好的效果。
5. 做好DevSecOps，需要持续、大量“累积”。无论是，SAST、容器安全扫描，还是依赖库扫描，效果很大程度上由特征库决定。需要结合威胁情报，快速且持续地更新。投入时间和耐心，总会开花结果。