引子
印象中，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）。
功能 | 优先级 |
|---|---|
静态应用安全测试（SAST） | 高 |
应用依赖安全检查（Dependency Scanning） | 高 |
容器安全扫描（Container Scanning） | 高 |
授权协议管理（License Management） | 高 |
动态应用安全测试（DAST） | 中 |
敏感信息检查（Secret Detection） | 中 |
模糊测试（Fuzzing） | 一般 |
交互式应用安全检测（IAST） | 一般 |
漏洞情报库/信息管理库（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种语言。概览如下：
语言 | 项目名称 | 项目主页 |
|---|---|---|
.NET | Security Code Scan | https://security-code-scan.github.io/ |
Any | Gitleaks and TruffleHog | https://github.com/zricethezav/gitleaks https://github.com/dxa4481/truffleHog |
C/C | Flawfinder | https://www.dwheeler.com/flawfinder/ |
Elixir (Phoenix) | Sobelow | https://github.com/nccgroup/sobelow |
Go | Gosec | https://github.com/securego/gosec |
Groovy (Ant, Gradle, Maven and SBT) | SpotBugs with the find-sec-bugs plugin | https://spotbugs.github.io/ https://find-sec-bugs.github.io/ |
Java (Ant, Gradle, Mavenand SBT) | SpotBugs with the find-sec-bugs plugin | https://spotbugs.github.io/ https://find-sec-bugs.github.io/ |
Javascript | ESLint security plugin | https://github.com/nodesecurity/eslint-plugin-security |
Node.js | NodeJsScan | https://github.com/ajinabraham/NodeJsScan |
PHP | phpcs-security-audit | https://github.com/FloeDesignTechnologies/phpcs-security-audit |
Python (pip) | bandit | https://github.com/PyCQA/bandit |
Ruby on Rails | brakeman | https://brakemanscanner.org/ |
Scala (Ant, Gradle, Mavenand SBT) | SpotBugs with the find-sec-bugs plugin | https://spotbugs.github.io/ https://find-sec-bugs.github.io/ |
Typescript | TSLint config security | https://github.com/webschik/tslint-config-security/ |
总体来说，上述项目核心都依赖字符串或正则匹配敏感函数/缺陷代码特征。受篇幅限制，做简单导览：
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）。概览如下：
语言 | 使用项目 |
|---|---|
JavaScript (npm, yarn) | gemnasium, Retire.js |
Python (pip) (only requirements.txt supported) | gemnasium |
Ruby (gem) | gemnasium, bundler-audit |
Java (Maven) | gemnasium |
PHP (Composer) | gemnasium |
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等。
四、总结与思考
- 排除营销夸大的成分，Gitlab现有的安全解决方案还不足以抗衡老牌的专业安全公司产品。
- 整体上看，Gitlab也可以考虑将安全函数库（开发框架）、安全开发规范融入DevOps流程中。
- 对我个人来说，继续“刷新”，了解新技术和方向。去探索、熟悉新项目，它们是怎么做的、该怎么做的更好。对团队或企业来说，Gitlab的布局仅作为参考，可以有独立的思考、布局和节奏。
- 扫描和防护是做安全的两种最根本的手段，但结合不同场景，可以发挥愈来愈好的效果。比如SAST、DAST本质上仍然是黑白盒扫描，不过结合DevOps，增强安全手段的“自动化”和“强制性”（意味着，每次发布都自动做扫描），避免人为的“惰性”和疏忽，可以取得更好的效果。
- 做好DevSecOps，需要持续、大量“累积”。无论是，SAST、容器安全扫描，还是依赖库扫描，效果很大程度上由特征库决定。需要结合威胁情报，快速且持续地更新。投入时间和耐心，总会开花结果。
