在软件交付的流程中，漏洞扫描已经成为了最基本的步骤。通过一些扫描工具自动识别部署制品中的一些已知漏洞，减少有风险的组件发布到生产环境中。

但是保护交付过程不仅仅是要依靠一个扫描工具这么简单，就算是这个工具可以识别所有的漏洞。我们在交付安全的过程中还应该以充分的管理手段来配合漏洞扫描工具。

 

什么是漏洞扫描？

 

漏洞扫描是分析软件交付制品包所包含的漏洞。

这个扫描可以包含任何类型包，比如Docker容器镜像，Linux操作系统上的RPM包还有Maven、Npm的编译构建的依赖等。

一般的扫描工具都是检查软件包里面的内容，然后基于一个收录了已知漏洞的漏洞数据库进行文件比对。比如漏洞库里面已知某个包的特定几个版本有漏洞，并且制品中包含这个文件信息，扫描工具这时候会提示制品也包含了这个漏洞。

 

基于漏洞库扫描的局限性

 

虽然漏洞扫描程序是在软件中查找多种类型安全风险的重要工具，但它们只检查已在漏洞数据库中识别的漏洞。

它们通常无法检测到存在于开发人员内部编写的源代码中的安全漏洞，例如缓冲区溢出漏洞，这个是代码扫描工具的能力。当然也不会监视应用程序行为是真的会触发产生安全漏洞，也就是我们常说的运行时监控，这个一般是由渗透性安全测试的工具来完成的。

还有就是漏洞扫描程序可能检测出大量的漏洞信息，包括我们运行的环境中，以及一些传递依赖。这期间有些漏洞的信息甚至也不是非常的完备，比如有些漏洞的漏洞级别评分等信息在社区中也是没有的。所以，我们还是需要了解哪些漏洞是不影响我们的使用，以及哪些看起来是级别很低的漏洞，但是会给我们带来极大的风险。

 

充分利用漏洞扫描工具

 

简单地将自动化包漏洞扫描器部署为 CI/CD 流水线的一部分是领先于安全问题的第一步。但是团队应该采取额外的步骤来最大限度地提高他们在包中找到所有潜在漏洞的机会。

 

给我们的制品瘦身

 

制品中的代码和依赖项越多，漏洞扫描器就越难解压所有层并检测漏洞。如果制品中包含许多项目，则修复安全问题和重建制品也更加困难。

最佳实践是确保您创建的每个包仅包含部署功能的一个方面所需的代码和其他资源。拒绝将应用程序的多个组件塞入单个包的这种操作。

例如，不要创建包含多个微服务的 Docker 镜像，而是为每个微服务生成不同的镜像。或者，不要将应用程序前端和应用程序逻辑都打包到同一个 Debian 包中，而是将它们分开到不同的包中。这样最大限度减少我们单个制品的大小。

 

在开发生命周期的早期扫描

 

与其等到部署之前才扫描包，不如在构建包后立即执行扫描。

 

尽早扫描有两个好处。首先，在 CI/CD 的早期更容易解决漏洞，因为这时候改动相对较少。如果等待扫描直到已经对包执行了其他类型的测试，并且检测到漏洞必须重建制品时，将需要再次运行这些测试，这会产生大量的时间浪费。

 

其次，早期扫描可将不安全的应用程序用于生产的风险降至最低。可以阻止将有问题的制品上传到制品仓库中，或者阻止用户下载有问题的依赖，这样在开发的过程中引用至少就是安全的。

 

当然尽管集成了开发阶段扫描，但是部署前的扫描仍然是一个必不可少的步骤，这对于确保评估实际投入生产的软件风险也很重要。但在开发阶段扫描也将帮助潜在漏洞进入持续交付流水线之前阻止引入。

优先级

 

如上所述，如果我们的团队确定哪些漏洞严重到足以使程序包无法使用，那么程序包中的一长串漏洞将没有多大帮助。通过投资扫描器来避免此问题，该扫描器可基于对每个漏洞的实际安全影响的分析进行有效的漏洞风险评估和优先级排序。这样，我们就可以轻松确定哪些漏洞是阻碍因素，哪些是可以忽略的问题。

 

信任来源同需扫描

 

有时，部署的工具来自第三方而不是内部的自研软件，比如我们常用的一些工具类软件XXL-JOB等。在这种情况下，扫描也是非常重要的，无论这个工具有多常用或者普及率有多高。

 

漏洞数据库

 

最后就是漏洞数据库的完善程度，一个大而全的漏洞库是漏洞扫描工具的基本盘。这直接决定了扫描工具的识别有效性。如果我们的漏洞库很少，那么扫描的识别率将大大降低。尤其是使用公共免费的漏洞库的工具。比如CVE、NVD漏洞信息并不是最新的，而且数量整体上也较少。JFrog Xray不仅仅包含开源漏洞库的数据，同时还包含全球通用的商业漏洞库VulnDB，这个是其他扫描工具所不具备的。