原文地址：https://qiita.com/knqyf263/items/dc179f9223fc31b5a51c
概要
向大家介绍一款可以扫描DockerContainer内部漏洞的方法。
这里的漏洞是指安全更新提供的漏洞(有CVE-ID的漏洞)，而不是网络服务的漏洞诊断提供的漏洞。
闲话不多说，先上工具
knqyf263/trivy
为了方便在CI上使用，只需指定DockerImage名称便可可执行扫描，只需一行命令。
$ trivy [YOUR_IMAGE_NAME]
灰常简单。
- 无需下载DockerImage(自动从Registry取得相应的Image)
- 无需安装Docker（此工具不依赖Docker）
- 支持AWS/GCR等私人Registry
有AWS/GCR的Credentials时自动取得相应Image。
当然，DockerDaemon中存在的Image也会成为扫描对象。
扫描不会花很久时间，
只有第一次扫描时需要构建漏洞DB所以会花10分钟，可以先喝杯咖啡小憩一下。
用官方的Image举个栗子。
$ trivy ruby:2.3.0
2019-05-16T23:21:11.306+0900 INFO Updating vulnerability database...
2019-05-16T23:21:24.338+0900 INFO Detecting Debian vulnerabilities...
ruby:2.3.0 (debian 8.4)
=======================
Total: 8137 (UNKNOWN: 6, LOW: 326, MEDIUM: 6021, HIGH: 1679, CRITICAL: 105)
+------------------------------+---------------------+----------+----------------------------+----------------------------------+-----------------------------------------------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE |
+------------------------------+---------------------+----------+----------------------------+----------------------------------+-----------------------------------------------------+
| apt | CVE-2019-3462 | CRITICAL | 1.0.9.8.3 | 1.0.9.8.5 | Incorrect sanitation of the |
| | | | | | 302 redirect field in HTTP |
| | | | | | transport method of... |
+ +---------------------+----------+ +----------------------------------+-----------------------------------------------------+
| | CVE-2016-1252 | MEDIUM | | 1.0.9.8.4 | The apt package in Debian |
| | | | | | jessie before 1.0.9.8.4, in |
| | | | | | Debian unstable before... |
+ +---------------------+----------+ +----------------------------------+-----------------------------------------------------+
| | CVE-2011-3374 | LOW | | | |
+------------------------------+---------------------+----------+----------------------------+----------------------------------+-----------------------------------------------------+
| bash | CVE-2019-9924 | HIGH | 4.3-11 | 4.3-11+deb8u2 | bash: BASH_CMD is writable in |
| | | | | | restricted bash shells |
+ +---------------------+ + +----------------------------------+-----------------------------------------------------+
| | CVE-2016-7543 | | | 4.3-11+deb8u1 | bash: Specially crafted |
| | | | | | SHELLOPTS+PS4 variables allows |
| | | | | | command substitution |
+ +---------------------+----------+ + +-----------------------------------------------------+
| | CVE-2016-0634 | MEDIUM | | | bash: Arbitrary code execution |
| | | | | | via malicious hostname |
+ +---------------------+----------+ +----------------------------------+-----------------------------------------------------+
| | TEMP-0841856-B18BAF | LOW | | | |
+ +---------------------+ + +----------------------------------+-----------------------------------------------------+
| | CVE-2016-9401 | | | 4.3-11+deb8u2 | bash: popd controlled free |
+------------------------------+---------------------+----------+----------------------------+----------------------------------+----------------------------------------------------
...
主要用途还是针对自己建立的DockerImage进行扫描。
截图如下
特征
Trivy的主要特征如下
- 支持范围广泛
- 可检测OS Package的漏洞, Application依赖的Library的漏洞
- 可检测Red Hat Universal Base Image - 使用简单
- 只需指定DockerImage名称 - 安装简单
- 无需安装DB
- 只需用apt-get, yum, brew安装便可 - 高精度
- 特别对Alpine Linux，RHEL/CentOS的检测精度高 - DevSecOps
- 方便在CI/CD上使用
检测漏洞
Trivy首先检测OSPackage漏洞。
当发现apt-get，yum安装的Package中存在漏洞时，我们会进行安全更新。
Trivy会自动对其进行检测。
而且，还会检测出还没有提供安全更新的漏洞。
这些漏洞不能通过更新来修补，只能通过改变设置或防火墙的设置进行弥补。
与现存的漏洞检测服务最大的区别是，Trivy可以检测到Application依赖的Library的漏洞。例如，用Bundler安装的Gem，用Pipenv安装的Python等。
Docker用户会在上述环境中部署Application，可以通过lock文件自动检测这些依赖关系并对其进行漏洞扫描。
即可以对如下的Dockerfile进行漏洞扫描。
FROM ruby:2.6
RUN apt-get update -y && apt-get install -y build-essential nodejs
RUN gem install bundler
WORKDIR /tmp
ADD Gemfile Gemfile
ADD Gemfile.lock Gemfile.lock
RUN bundle install
ENV APP_HOME /app
RUN mkdir -p $APP_HOME
WORKDIR $APP_HOME
ADD . $APP_HOME
CMD ["rails", "server", "-b", "0.0.0.0"]
通过Debian的PackageManager安装Package的漏洞与
通过bundle安装的Gem的漏洞
会被检测出来。(第二张截图)
对已经Build好的DockerImage也可以简单的进行扫描。
$ docker build -t myapp:1.2.3 .
$ trivy myapp:1.2.3 .
OSPackage
支持如下的OS。
| OS | Version | 支持的Package | UnFixable |
|---|---|---|---|
| Alpine Linux | 2.2 - 2.7, 3.0 - 3.10 | 通过apk安装 | NO |
| Red Hat Universal Base Image | 7, 8 | 通过yum/rpm安装 | YES |
| Red Hat Enterprise Linux | 6, 7, 8 | 通过yum/rpm安装 | YES |
| CentOS | 6, 7 | 通过yum/rpm安装 | YES |
| Debian GNU/Linux | wheezy, jessie, stretch, buster | 通过apt/apt-get/dpkg安装 | YES |
| Ubuntu | 12.04, 14.04, 16.04, 18.04, 18.10, 19.04 | 通过apt/apt-get/dpkg安装 | YES |
只有通过PackageManager安装的Package可以进行扫描，
自行通过make install安装的Package无法进行扫描。
Application依赖的Library
支持如下文件的依赖检测
- Gemfile.lock
- Pipfile.lock
- composer.lock
- package-lock.json
- yarn.lock
- Cargo.lock
如Gemfile_web01.lock等自行修改过的文件名无法被检测。
将来会对其进行改善，增加指定文件功能或者自动识别对应文件。
简单
不仅使用简单（仅需指定DockerImage名称），构成也很简单。
Trivy不用准备DB，不须启动服务器，不需要通过客户端进行扫描。
只要安装了Trivy命令即可执行。
安装
可以通过下载二进制文件进行安装，更可以通过apt,yum进行安装（只需追加相应的
Repository）。
Mac OS X / Homebrew
Mac用户可以通过Homebrew进行安装。
$ brew tap knqyf263/trivy
$ brew install knqyf263/trivy/trivy
RHEL/CentOS
在/etc/yum.repos.d中加入Repository设定即可。
$ sudo vim /etc/yum.repos.d/trivy.repo
[trivy]
name=Trivy repository
baseurl=https://knqyf263.github.io/trivy-repo/rpm/releases/$releasever/$basearch/
gpgcheck=0
enabled=1
$ sudo yum -y update
$ sudo yum -y install trivy
或
$ rpm -ivh https://github.com/knqyf263/trivy/releases/download/v0.0.13/trivy_0.0.13_Linux-64bit.rpm
Debian/Ubuntu
登录GPG后加入到sources.list即可。
[CODE_NAME] 部分根据用户的OS进行变更
CODE_NAME: wheezy, jessie, stretch, buster, trusty, xenial, bionic
$ sudo apt-get install apt-transport-https gnupg
$ wget -qO - https://knqyf263.github.io/trivy-repo/deb/public.key | sudo apt-key add -
$ echo deb https://knqyf263.github.io/trivy-repo/deb [CODE_NAME] main | sudo tee -a /etc/apt/sources.list.d/trivy.list
$ sudo apt-get update
$ sudo apt-get install trivy
或
$ sudo apt-get install rpm
$ wget https://github.com/knqyf263/trivy/releases/download/v0.0.13/trivy_0.0.13_Linux-64bit.deb
$ sudo dpkg -i trivy_0.0.13_Linux-64bit.deb
其他OS
从这里下载文件，或者用Go自行Build
精度
与现存的其他漏洞扫描服务进行了比较。
比较对象： Clair, Quay, MicroScanner(Free), Docker Hub, Anchore Engine
在Alpine Linux上进行扫描的结果Trivy的True Positive最多。
False Positive几乎不存在。Docker Hub的漏洞扫描很粗糙，False Positive的结果很多。GCR不支持Alpine所以结果是0。
至于为什么会在Alpine Linux上有不同的精度，之后会追诉。
对详细结果感兴趣的人可以戳下面的连接
https://docs.google.com/spreadsheets/d/16uj9vGh2PHMcVwb_D4h0nYUSvzCAxcnUz9UgQaDCYs4/edit#gid=0
CentOS上的结果差距太大了以至于有点怀疑？
这是有原因的，现存的扫描服务不检测RHEL/CentOS的未修正的漏洞。
即Red Hat未提供安全更新/补丁的漏洞，或无关紧要的漏洞。
也包括刚刚公开不久还没有补丁，upstream等漏洞所以同样存在危险。
只看已修正的漏洞的话没有太大区别。
DevSecOps
最近流行说DevSecOps，其实是方便利用CI进行push前的测试。
如果有危险的漏洞可以让CI的测试失败。
也可以用过滤功能让存在CRITICAL漏洞的测试失败，HIGH漏洞的测试成功。
这里举个Travis CI和CircleCI的栗子。
其实也有做CircleCI的Orbs和Jenkins插件，下次再公开。
Travis CI
$ cat .travis.yml
services:
- docker
env:
global:
- COMMIT=${TRAVIS_COMMIT::8}
before_install:
- docker build -t trivy-ci-test:${COMMIT} .
- wget https://github.com/knqyf263/trivy/releases/download/v0.0.13/trivy_0.0.13_Linux-64bit.tar.gz
- tar zxvf trivy_0.0.13_Linux-64bit.tar.gz
script:
- ./trivy --exit-code 0 --severity HIGH --quiet trivy-ci-test:${COMMIT}
- ./trivy --exit-code 1 --severity CRITICAL --quiet trivy-ci-test:${COMMIT}
cache:
directories:
- $HOME/.cache/trivy
Demo: https://travis-ci.org/knqyf263/trivy-ci-test
Repository: https://github.com/knqyf263/trivy-ci-test
CircleCI
jobs:
build:
docker:
- image: docker:18.09-git
steps:
- checkout
- setup_remote_docker
- restore_cache:
key: vulnerability-db
- run:
name: Build image
command: docker build -t trivy-ci-test:${CIRCLE_SHA1} .
- run:
name: Install trivy
command: |
wget https://github.com/knqyf263/trivy/releases/download/v0.0.13/trivy_0.0.13_Linux-64bit.tar.gz
tar zxvf trivy_0.0.13_Linux-64bit.tar.gz
mv trivy /usr/local/bin
- run:
name: Scan the local image with trivy
command: trivy --exit-code 0 --quiet trivy-ci-test:${CIRCLE_SHA1}
- save_cache:
key: vulnerability-db
paths:
- $HOME/.cache/trivy
workflows:
version: 2
release:
jobs:
- build
Demo: https://circleci.com/gh/knqyf263/trivy-ci-test
Repository: https://github.com/knqyf263/trivy-ci-test
Option
一般不会用到，所以就不加赘述了。
NAME:
trivy - A simple and comprehensive vulnerability scanner for containers
USAGE:
main [options] image_name
VERSION:
0.0.13
OPTIONS:
--format value, -f value format (table, json) (default: "table")
--input value, -i value input file path instead of image name
--severity value, -s value severities of vulnerabilities to be displayed (comma separated) (default: "UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL")
--output value, -o value output file name
--exit-code value Exit code when vulnerabilities were found (default: 0)
--skip-update skip db update
--reset remove all caches and database
--clear-cache, -c clear image caches
--quiet, -q suppress progress bar
--ignore-unfixed display only fixed vulnerabilities
--refresh refresh DB (usually used after version update of trivy)
--debug, -d debug mode
--help, -h show help
--version, -v print the version
附上各种栗子有兴趣的可以去看看
https://github.com/knqyf263/trivy#examples
与其他漏洞扫描服务的比较
用过漏洞扫描服务的人都知道，基本都是初始设置超级麻烦。
至于Clair是不知道用哪个客户端（经常变）
而且，服务器端/客户端的构成比较多，不方便用CI。虽然可以用，但是很麻烦。
还有就是上述的精度问题。
Debian/Ubuntu的结果基本都差不多，但Alpine Linux/Red Hat Universal Base Image/RHEL/CentOS的结果大不同。
Alpine Linux的结果不同是因为使用的漏洞情报不同。
Clair等参照的是backport的漏洞，不是全部的漏洞。
Alpine基本都升级版本，所以DB很少。
Trivy参照的是Alpine的Redmine这里有关于安全的Ticket，从中找出关于安全更新的Ticket。说起来貌似很简单，其实还调查过git的diff看看版本怎么变的之类的让人内牛满面的努力等等，要细说恐怕篇幅不够，下次再说。
啥也不说了，能检测Application的依赖Library的漏洞检测服务的不是别的是Trivy，Trivy，Trivy，重要的事情说三遍(Anchore Engine姑且可以扫描到一点)。
虽然Quay，GCR方便使用，但只能扫描Push到Registry的DockerImage不能用CI实现测试（可能将来会实现），而且会限制特定的Registry。
总结
详细请参照README
https://github.com/knqyf263/trivy
想用CI扫描Container内的漏洞
或者对现存的扫描服务有不满的
或者有其他的想说的
欢迎反馈，谢谢
1126
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
