去年冬天，开源一个朋友的漏洞公司被拖库了。攻击者利用的扫描漏洞，早在半年前就被公开披露，系统补丁也发布了。开源问题出在他们根本不知道自己的漏洞服务器上跑着那个有漏洞的组件。这不是扫描个例。大部分被攻破的系统系统，不是开源因为遇到了多么高明的0day，而是漏洞因为已知漏洞没修。开源漏洞扫描系统，扫描就是系统用来解决这个“不知道”的问题。

这类工具的开源核心逻辑很直接：拿一个数据库，里面存着各种软件组件的漏洞已知漏洞信息，然后去你的扫描系统里“对答案”。数据库的权威性决定了扫描结果的可靠性。目前最常被引用的是NVD（美国国家漏洞数据库），它给每个漏洞分配CVE编号。但NVD有个毛病——更新滞后，而且只描述漏洞本身，不告诉你具体哪个版本的哪个文件受影响。所以实际干活时，大家会混用厂商自己的安全公告，比如Red Hat的OVAL、Ubuntu的USN。开源工具的优势就在这里：社区可以快速补充这些数据源，不用等某个商业公司排期。

拿Trivy来说。这工具最初是Aqua Security做的，现在完全开源。它扫描一个容器镜像，几秒钟就能列出所有带CVE的软件包。我试过扫一个基于Alpine的Nginx镜像，结果里有一条CVE-2023-44487，HTTP/2的Rapid Reset攻击。如果没扫，你可能根本不会想到一个基础镜像里藏着这种级别的漏洞。Trivy的数据库每天从多个源同步，包括GitHub Advisory、Red Hat、Alpine自己的secdb。这种多源聚合在实际使用中很关键——单一数据源总有盲区。

OpenVAS（现在叫Greenbone Vulnerability Management）走的是另一条路。它更像传统的网络扫描器，主动去探测目标主机开放的服务和版本，然后匹配漏洞库。适合扫那些你没法装agent的资产，比如网络打印机、老旧的Windows Server。但主动扫描有个代价：可能触发IDS告警，甚至把某些脆弱服务打挂。我见过有人拿OpenVAS扫生产环境，结果一个老旧的Tomcat直接无响应。所以用之前得想清楚，是想要全面性还是稳定性。

选型的时候，别只看漏洞库大小。要看更新频率。一个每月更新一次的扫描器，在Log4Shell那种级别的漏洞爆发时，可能一周内都是瞎子。社区活跃度也重要。Trivy的issue区里，经常有人提交新的漏洞数据源或者误报修正，维护者响应很快。反过来，有些开源项目已经半年没合并PR了，这种就要小心。另外，扫描器本身不能成为负担。如果部署一个扫描系统需要先搭一套Kubernetes集群，那对中小团队来说就本末倒置了。

集成到CI/CD里是另一个实用场景。在构建镜像的阶段就跑一次Trivy，设置严重级别为CRITICAL的漏洞直接让流水线失败。这比等到上线后再扫要有效得多。但别一刀切。有些CVE虽然标记为HIGH，实际利用条件很苛刻，比如需要本地访问加上特定配置。如果每个都卡，开发团队很快就会想办法绕过扫描。最好是根据资产暴露面来分级——公网服务严格，内网工具适当放宽。

开源漏洞扫描系统不是银弹。它只能告诉你“有什么”，不能告诉你“该怎么办”。一个CVE在扫描结果里出现，不代表你的系统真的可被利用。需要结合资产重要性、网络隔离情况、补偿性控制措施来判断。但至少，它把“未知”变成了“已知”。剩下的事，靠人。

(责任编辑：探索)