今年年初，为满足PCI-DSS和SOC-2合规要求，我们的团队需要增强现有的安全工具以及软件开发和测试实践。其中一个需要重点增强的领域，是针对基于K8s的微服务和几个单体服务开展漏洞扫描。因此，DevOps团队需要从几款商业工具和开源解决方案中进行选择，为软件实施漏洞扫描。这些工具的功能非常相似：扫描依赖项（项目库或OS软件包），并与漏洞数据库（如NIST的NVD等）进行比对。
自建还是购买？
您可以使用一些开源工具自行构建漏洞扫描解决方案，也可以选择商业产品。商业产品通常在基础扫描功能之外提供更多功能，有助于简化工作。例如：
- 直观的仪表板，可快速概览项目中的漏洞
- 通知（电子邮件、Slack等）
- 与Git代码仓库（GitHub、GitLab）集成
- 与其他服务集成（Docker镜像仓库、Kubernetes）
- 与项目管理工具集成（例如Jira）
- 自动创建合并请求以修复存在漏洞的依赖项
- 支持团队、项目和基于角色的访问控制（RBAC）
大多数商业解决方案都会使用自有漏洞数据库来补充公共漏洞数据库，以减少误报和漏报，并提供更相关的结果。不过，随着开发人员数量增加，这些商业工具的成本会大幅上升。因此，需要权衡哪种方式更合适：购买商业解决方案，还是利用现有开源工具自行构建解决方案。
起初，考虑到时间限制，我们认为商业工具更适合自身需求。然而，在花费3个月部署和测试一款业内较为领先的商业产品后，我们遇到了许多挑战，包括对golang的支持有限、会选择错误的依赖项且无法正常退出，以及从头构建的容器与基于基础镜像构建的容器存在差异等。因此，我们决定放弃该产品，转而利用现有的开源技术自行构建工具。
如果选择采用开源方案，本文将为您提供一个可靠的起点。此外，文末还附有我们的开源代码仓库链接，帮助您快速上手！
扫描哪些内容？
基本上，需要对以下两类对象进行漏洞扫描：
- 项目的代码依赖项（yarn.lock、Gopkg.lock等）
- Docker镜像中的操作系统依赖项（Debian软件包、Alpine软件包等）
未来可以添加更多功能，例如许可证检查或静态代码分析，但这些内容不在本文的讨论范围内。
何时扫描？
首先，需要确保代码或Docker镜像的更改不会引入新的漏洞，因此建议在合并前扫描每个合并请求。
但还需要定期扫描，因为随着时间推移，可能会出现新的漏洞。此外，严重性也可能发生变化。例如，随着新的攻击途径或漏洞利用方式被发现，最初忽略的低严重性漏洞可能会逐渐变为严重漏洞。商业工具会记录上次扫描，并在发现新漏洞时发出通知；而在我们的开源解决方案中，只需基于项目的master分支重复扫描。
选择工具
有许多开源工具可供选择，但我们选择了Trivy，因为它简单易用、仍在积极开发中，并且可以扫描多种项目和操作系统类型。
Trivy是一款简单而全面的漏洞扫描器，适用于容器及其他制品。软件漏洞是指软件或操作系统中存在的错误、缺陷或弱点。Trivy可检测操作系统软件包（Alpine、RHEL、CentOS等）和应用程序依赖项（Bundler、Composer、npm、yarn等）中的漏洞。Trivy使用简单，只需安装二进制文件，即可开始扫描。扫描时，只需指定目标，例如容器镜像名称。
Trivy易于安装，可在本地针对已构建的Docker镜像或项目根目录运行。它还支持多种输出格式，包括JSON和表格输出：
遗憾的是，有些项目（例如Golang项目）Trivy无法扫描，因此我们不得不依赖OWASP Dependency-Check，因为我们的许多代码都是用Golang编写的。
Dependency-Check是一款软件成分分析（SCA）工具，用于尝试检测项目依赖项中已公开披露的漏洞。它通过确定给定依赖项是否存在通用平台枚举（CPE）标识符来进行检测。如果找到该标识符，则会生成一份报告，其中包含指向相关CVE条目的链接。
它可以生成HTML格式的报告页面，以及JUnit、JSON等格式的输出。
报告和仪表板
现在，我们离更有趣的内容越来越近了 😊
由于我们的DevOps和SRE团队已经在使用Elasticsearch + Kibana + Fluentd，因此很自然地选择利用现有基础设施来分析安全扫描生成的JSON输出。
我们只需找到一种方法，将数据从不受信任的基础设施（CI运行器）发送到安全的Elasticsearch。为此，我们决定在两者之间设置消息队列。Fluentd提供in_sqs插件，可从Amazon SQS读取消息，而且使用简单，因此最终架构如下：
数据进入Elasticsearch后，即可轻松使用Kibana创建多个仪表板，或使用Discover按需查询漏洞及其所有详细信息。
应对漏洞
现在，我们已经有了扫描功能和一些实用的仪表板，接下来该怎么做？我们不能指望开发人员定期查看这些仪表板。因此，我们决定：如果发现严重级别为“高”或更高且已有修复方案的问题，就让 CI 失败。这样，开发人员和项目负责人就需要负责处理这些问题。
当然，我们需要提供一个选项，用于将某些CVE加入白名单，或按项目覆盖这一默认行为。因此，我们创建了一个安全扫描配置文件仓库，供扫描工具使用。该工具封装了Trivy的执行过程，并处理其行为和输出。
现在，任何开发人员都可以向此存储库提交合并请求并申请例外。kibana项目的配置文件示例：
未来改进
此安全扫描实现奠定了坚实基础，可在初始用例之外进一步扩展。例如：
- 添加Slack通知，并使用安全配置文件为每个项目指定频道和选项
- 添加与Gitlab Issues、Jira或任何其他工单系统的集成
- 创建简单的服务或边车，对部署在Kubernetes集群上的镜像执行扫描
复刻并使用
可在我们的GitLab公共代码库中找到Dockerfile和相关工具：https://gitlab.com/volterra.io/security-scanning
感谢Jakub Pavlík。
相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。