Ubuntu 22.04 漏洞扫描实战：Vuls 无代理深度检测与 USN 精准修复

1. 项目概述为什么在 Ubuntu 22.04 上用 Vuls 做漏洞扫描不是“可选项”而是“必选项”Vuls 是一个开源的、无代理agentless的 Linux/Unix 系统漏洞扫描器它不依赖于在目标主机上安装常驻进程而是通过 SSH 连接远程执行命令、读取软件包数据库、比对 NVD美国国家漏洞数据库、JVN日本漏洞数据库、OVAL 等多个权威源最终生成结构清晰、可审计、带修复建议的 HTML 或 JSON 报告。它不是那种点几下就出“高危漏洞17个”的黑盒工具而更像一位懂系统底层、会查 CVE 编号、能看懂 dpkg -l 输出、还知道 Ubuntu 官方安全公告USN发布时间线的资深运维同事。我第一次在客户生产环境部署 Vuls是为一家托管着 32 台 Ubuntu 22.04 LTS 服务器的 SaaS 公司做季度合规审计——他们之前用的是商业扫描器每次扫描都得重启服务、报告里堆满误报、修复建议写的是“升级到最新版内核”但没人告诉他们 Ubuntu 的内核更新策略是分 kernel-image 和 kernel-headers 两套包管理且 LTS 版本的内核更新有严格的 SRUStable Release Updates流程。Vuls 扫出来的结果直接标出了具体受影响的包名如linux-image-5.15.0-86-generic、对应 USN 编号USN-6421-1、补丁状态已发布/待发布/需手动回滚甚至附上了apt list --upgradable | grep linux-image这样的实操命令。这才是真正能进工单、能进变更评审会、能被开发和运维共同认可的漏洞数据。Ubuntu 22.04 LTS 作为当前主流的长期支持版本其生命周期将持续到 2027 年 4 月这意味着未来三年内它承载的业务系统将面临持续涌现的 CVE 漏洞。而 Vuls 的核心价值恰恰在于它把“漏洞”这个抽象概念精准锚定到了你/etc/os-release里那行VERSION_ID22.04对应的具体软件包版本上。它不扫描端口不爆破密码不模拟攻击只做一件事告诉你“你的系统此刻到底安不安全哪里不安全怎么修才最稳妥”。这正是 DevSecOps 流程中缺失的关键一环——不是等 CI/CD 流水线跑完才被告知镜像有漏洞而是让安全验证成为基础设施即代码IaC的一部分让每一次apt upgrade都有据可依。如果你还在用unattended-upgrades自动打补丁却从不验证补丁是否真生效、或者靠人工翻 USN 页面查公告那么 Vuls 就是你该立刻上手的“系统健康听诊器”。2. 核心设计思路与方案选型解析为什么 Vuls 是 Ubuntu 22.04 漏洞管理的“黄金搭档”2.1 为什么不是 OpenVAS、Nessus 或 Trivy很多人第一反应是“漏洞扫描用 Nessus 不香吗”——确实香但香在通用性不香在 Ubuntu 深度适配。Nessus 是基于网络探测的扫描器它会尝试连接目标端口、发送探测包、分析响应特征来推断服务版本再匹配 CVE。这种方式在 Ubuntu 22.04 上有两个硬伤一是它无法准确识别 Ubuntu 特有的包管理机制。比如nginx在 Ubuntu 上可能由nginx-full、nginx-light、nginx-core多个包提供每个包的版本号、编译参数、启用模块都不同Nessus 只能猜nginx -v的输出而 Vuls 直接读取dpkg -l | grep nginx拿到的是精确到.deb包的版本字符串二是它无法关联 Ubuntu 官方的安全更新节奏。Nessus 报告说“CVE-2023-1234 影响 nginx 1.22.0”但 Ubuntu 22.04 的nginx-full包版本可能是1.18.0-6ubuntu14.4这个版本是否已通过 USN 补丁修复了该 CVENessus 不知道它只会按上游版本号报警。而 Vuls 内置了 USN 数据库解析器它看到1.18.0-6ubuntu14.4会立刻去查 USN-6398-1确认该补丁是否已包含此修复并标记为“已修复”或“未修复”。OpenVAS 同理它是通用型扫描器缺乏对 Debian/Ubuntu APT 生态的原生理解。至于 Trivy它强在容器镜像扫描对运行中的 Ubuntu 主机Trivy 的fs模式需要挂载整个根文件系统权限要求高、扫描慢、且对内核模块、initramfs 等系统级组件覆盖不足。Vuls 的 agentless 设计让它只需一个具有sudo权限的 SSH 账户就能以最小侵入方式完成全系统扫描这正是生产环境最珍视的“零扰动”原则。2.2 为什么必须是 Ubuntu 22.04 LTS而不是其他版本Ubuntu 22.04 LTS代号 Jammy Jellyfish是 Vuls 发挥最大效能的“理想试验田”原因有三。第一数据源完备性。Vuls 的漏洞数据主要来自三个渠道NVD全球通用、JVN日本侧重、USNUbuntu 官方。前两者是公开数据库但 USN 是 Ubuntu 独有的、最权威的本地化漏洞通告。22.04 作为 LTS 版本其 USN 更新频率高、覆盖范围广、补丁质量经过严格测试。Vuls 的fetch-usn子命令能自动下载并解析最新的 USN XML 文件构建本地漏洞知识图谱。而 Ubuntu 20.04 的 USN 数据虽也支持但部分新出现的 CVE尤其是涉及较新内核子系统如 eBPF verifier 的漏洞在 20.04 的 USN 中可能只有简短描述22.04 的 USN 则会提供详细的补丁提交哈希、影响的源码文件路径这对深度分析至关重要。第二内核与用户空间的版本稳定性。22.04 默认搭载 Linux 5.15 内核这是一个被广泛验证、社区支持活跃的 LTS 内核版本。Vuls 的内核漏洞检测逻辑如检查CONFIG_BPF_JIT是否启用、/proc/sys/net/core/bpf_jit_harden的值是针对 5.15 系列深度优化的。相比之下Ubuntu 23.10 的内核是 6.5其 sysctl 参数、proc 接口、甚至 CVE 的触发条件都可能发生细微变化Vuls 的检测规则若未及时同步就容易漏报。第三APT 生态的成熟度。22.04 的apt命令输出格式、dpkg-query的字段定义、/var/lib/dpkg/status的结构都是 Vuls 解析逻辑的“训练集”。我曾用同一份 Vuls 配置扫描 22.04 和 23.0423.04 的报告里出现了 3 个关于snapd包的误报原因是 23.04 引入了新的snapd版本其dpkg -l输出中多了一个ii状态标识而 Vuls 的正则解析规则还没适配。这印证了一个朴素道理在安全领域稳定压倒一切。选择 22.04就是选择了 Vuls 规则库最成熟、误报率最低、修复建议最可靠的运行环境。2.3 Vuls 的核心工作流从“扫描”到“决策”的闭环Vuls 的工作流不是简单的“输入主机列表 → 输出报告”而是一个严谨的四步闭环信息采集 → 漏洞匹配 → 报告生成 → 修复验证。第一步信息采集vuls scan。Vuls 通过 SSH 登录每台 Ubuntu 22.04 主机执行一系列预设命令cat /etc/os-release获取发行版信息dpkg -l列出所有已安装包及其版本uname -r获取内核版本systemctl list-units --typeservice --staterunning获取运行中服务find /usr/lib/systemd/system/ -name *.service -exec systemctl is-enabled {} \; -print检查服务启用状态。这些原始数据被收集后不会直接用于匹配而是先进行标准化处理——例如将dpkg -l输出的ii nginx-full 1.18.0-6ubuntu14.4 amd64 nginx web server (full version)解析为{name: nginx-full, version: 1.18.0-6ubuntu14.4, arch: amd64}这样的结构化对象。第二步漏洞匹配vuls report。这是 Vuls 的“大脑”。它将上一步得到的结构化软件包列表与本地缓存的 NVD、JVN、USN 数据库进行交叉比对。匹配逻辑不是简单的字符串相等而是语义化的版本比较。例如USN-6398-1 声明“修复了nginx-full包在1.18.0-6ubuntu14.3及更早版本中的漏洞”Vuls 会调用dpkg --compare-versions命令这是 Ubuntu 系统自带的、最权威的 deb 包版本比较工具来判断1.18.0-6ubuntu14.4 1.18.0-6ubuntu14.3从而得出“已修复”结论。第三步报告生成。Vuls 支持多种输出格式但最实用的是--format-full-text生成的纯文本报告和--format-html生成的交互式 HTML 报告。HTML 报告里每个漏洞条目都包含 CVE ID、CVSS 评分、受影响的包名与版本、USN 链接、官方描述、修复建议精确到apt install nginx-full1.18.0-6ubuntu14.4这样的命令甚至还有“相关漏洞”推荐——如果一个 nginx 漏洞被修复它会提示你顺带检查openssl和pcre3这两个 nginx 依赖库是否也存在已知漏洞。第四步修复验证。这不是 Vuls 自动做的而是它赋予你的能力。当你根据报告执行apt update apt install --only-upgrade nginx-full后只需再次运行vuls scan vuls report就能看到该 CVE 条目状态从 “Not Fixed” 变为 “Fixed”形成一个可验证、可审计的闭环。这个闭环才是 Vuls 区别于其他扫描器的真正护城河。3. 实操细节与关键配置手把手搭建属于你自己的 Ubuntu 22.04 漏洞监控中枢3.1 环境准备扫描器主机与目标主机的“握手协议”Vuls 的架构是典型的“中心扫描边缘采集”。你需要一台独立的、安全加固过的 Linux 主机我推荐也用 Ubuntu 22.04 Server作为 Vuls 扫描器Scanner Host它负责运行 Vuls 二进制文件、存储漏洞数据库、生成报告其余所有需要被扫描的 Ubuntu 22.04 主机Target Hosts则作为“被扫描者”只需开放 SSH 端口并配置好访问凭证。这个设计的好处是扫描器主机可以离线更新漏洞数据库避免目标主机暴露在公网风险中。首先在扫描器主机上安装基础依赖sudo apt update sudo apt install -y golang-go git curl wget jq注意这里没有安装golang的旧版本因为 Vuls 1.0 要求 Go 1.19而 Ubuntu 22.04 仓库里的golang-go默认是 1.18所以必须手动升级。我试过用apt install golang-1.19-go但官方仓库没这个包最稳妥的方式是下载 Go 二进制包cd /tmp wget https://go.dev/dl/go1.21.5.linux-amd64.tar.gz sudo rm -rf /usr/local/go sudo tar -C /usr/local -xzf go1.21.5.linux-amd64.tar.gz echo export PATH$PATH:/usr/local/go/bin | sudo tee -a /etc/profile.d/golang.sh source /etc/profile.d/golang.sh go version # 应输出 go version go1.21.5 linux/amd64接着创建一个专用的非 root 用户vuls这是最佳实践避免因 Vuls 配置错误导致 root 权限泄露sudo useradd -m -s /bin/bash vuls sudo usermod -aG sudo vuls sudo su - vuls现在切换到vuls用户开始下载和编译 Vuls。Vuls 官方推荐从源码编译因为它能确保二进制文件与你的 Go 环境完全兼容且便于后续调试git clone https://github.com/future-architect/vuls.git ~/vuls cd ~/vuls make build sudo cp ./vuls /usr/local/bin/ vuls -version # 应输出类似 vuls-v0.25.0-build-20231201提示不要用go install github.com/future-architect/vuls/cmd/vulslatest因为这种方式下载的二进制可能缺少对 USN 数据库的完整支持我在测试中发现它生成的报告里 USN 链接是空的。3.2 配置文件详解config.toml是 Vuls 的“作战地图”Vuls 的灵魂在于它的配置文件config.toml。这个文件定义了“扫描谁、怎么扫、扫什么、结果放哪”。我把它拆解成四个核心区块每个都关乎扫描成败。第一区块[servers]—— 定义你的“作战目标”[servers] [servers.target1] host 192.168.1.101 port 22 user ubuntu keyPath /home/vuls/.ssh/id_rsa_target1 sudo true ignoreUnreachable false [servers.target1.knownHosts] file /home/vuls/.ssh/known_hosts这里host是目标主机 IPuser是 SSH 登录用户名强烈建议用非 root 用户如 Ubuntu 默认的ubuntukeyPath是私钥路径。关键点在于sudo true因为dpkg -l等命令需要sudo权限才能获取完整包列表ignoreUnreachable false意味着只要有一台主机连不上整个扫描任务就会失败并报错这能防止你忽略掉某台“失联”的关键服务器。knownHosts.file是为了绕过 SSH 首次连接时的交互式确认你必须提前用ssh-keyscan 192.168.1.101 /home/vuls/.ssh/known_hosts把目标主机的公钥指纹写入此文件否则扫描会卡住。第二区块[cveDict]和[ovalDict]—— 构建你的“弹药库”[cveDict] type sqlite3 sqlite3Path /home/vuls/db/cve.sqlite3 [ovalDict] type sqlite3 sqlite3Path /home/vuls/db/oval.sqlite3这两个区块指向 Vuls 的本地漏洞数据库。cveDict存储 NVD 和 JVN 的 CVE 数据ovalDict存储 OVALOpen Vulnerability and Assessment Language的检测规则后者对 Windows 和某些特定 Linux 发行版的漏洞检测更精准。Vuls 不会自动创建这些数据库你必须手动下载并初始化mkdir -p /home/vuls/db cd /home/vuls/db vuls fetch nvd jvn oval --dbpath ./cve.sqlite3 --debug # --debug 会显示详细下载日志便于排查网络问题 vuls fetch usn --dbpath ./usn.sqlite3 --debug # USN 数据库是 Ubuntu 专属必须单独 fetch注意vuls fetch命令会从互联网下载数百 MB 的数据首次运行可能耗时 10-20 分钟。如果公司网络有代理需在~/.bashrc中设置export HTTP_PROXYhttp://your-proxy:8080和export HTTPS_PROXYhttp://your-proxy:8080否则会超时失败。第三区块[report]—— 定义你的“战报样式”[report] format [html, json] html /home/vuls/reports/html json /home/vuls/reports/json cveDict /home/vuls/db/cve.sqlite3 ovalDict /home/vuls/db/oval.sqlite3 usnDict /home/vuls/db/usn.sqlite3这里指定了报告输出格式和路径。format [html, json]表示同时生成两种格式。HTML 报告是给运维和安全团队看的JSON 报告则是给自动化脚本如 Slack 机器人、Jira 工单系统消费的。usnDict是关键它必须指向你前面vuls fetch usn下载的数据库否则 HTML 报告里不会有 USN 链接。第四区块[slack]或[email]—— 设置你的“预警哨兵”可选但强烈推荐[slack] webhookURL https://hooks.slack.com/services/XXXX/YYYY/ZZZZ channel #security-alerts username Vuls Bot iconEmoji :shield:当扫描发现新漏洞时Vuls 可以自动发 Slack 消息。webhookURL是你在 Slack 创建 Incoming Webhook 后得到的地址。这个功能的价值在于它能把“漏洞发现”这个被动动作变成主动的、实时的、可追踪的事件。我把它配置成只有当扫描发现Critical或High级别的新漏洞时才告警避免信息过载。3.3 首次扫描与报告解读读懂 Vuls 给你的第一份“健康诊断书”一切配置就绪后就可以发起首次扫描了。记住Vuls 的扫描是分两步走的先scan再report。# 第一步扫描所有配置的服务器将原始数据存入 /home/vuls/results/ vuls scan -config/home/vuls/config.toml # 第二步基于扫描结果和本地数据库生成最终报告 vuls report -config/home/vuls/config.toml -format-html -format-json扫描完成后打开/home/vuls/reports/html/index.html你会看到一个清爽的仪表盘。顶部是概览总扫描主机数、发现的漏洞总数、按严重等级Critical/High/Medium/Low/Unknown分布的饼图。点击任意一个主机名进入详情页。这里就是精华所在。每一行代表一个 CVE 漏洞例如CVE-2023-45803 | Critical | nginx-full (1.18.0-6ubuntu14.3) | USN-6398-1 | Not Fixed我们来逐项解读CVE-2023-45803这是漏洞的全球唯一 ID你可以复制它去 https://nvd.nist.gov 搜索查看官方描述和 CVSS 评分。CriticalVuls 根据 CVSS v3.1 基础分计算出的严重等级9.0为 Critical。nginx-full (1.18.0-6ubuntu14.3)明确指出是哪个软件包、哪个具体版本有问题。注意这个版本号是dpkg -l输出的原始字符串绝对真实。USN-6398-1这是 Ubuntu 官方发布的安全通告编号点击它会跳转到 https://ubuntu.com/security/notices/USN-6398-1里面详细说明了漏洞影响、修复版本、以及如何验证修复。Not Fixed这是最关键的结论。它表示你当前安装的nginx-full版本1.18.0-6ubuntu14.3尚未被 USN-6398-1 修复。修复版本是1.18.0-6ubuntu14.4。实操心得我第一次扫描时发现报告里有 5 个Not Fixed的 Critical 漏洞但当我登录目标主机执行apt list --upgradable | grep nginx却发现nginx-full显示为upgradable。这说明apt update还没运行Vuls 扫描的是当前已安装的包版本它不会帮你执行apt update。所以标准操作流程应该是先在所有目标主机上运行sudo apt update再运行vuls scan。这样Vuls 才能准确判断“你有没有可用的修复包”。3.4 自动化与日常巡检让 Vuls 成为你团队的“数字守夜人”把 Vuls 当成一次性工具是巨大的浪费。它的真正威力在于融入日常运维。我为团队搭建了一套基于cron的自动化巡检体系每天凌晨 2 点自动执行结果邮件发送给安全负责人。第一步编写巡检脚本daily-scan.sh#!/bin/bash # /home/vuls/scripts/daily-scan.sh set -e SCAN_TIME$(date %Y%m%d_%H%M%S) LOG_FILE/home/vuls/logs/scan_${SCAN_TIME}.log echo Starting Vuls Daily Scan at $(date) | tee -a $LOG_FILE # 1. 更新漏洞数据库每周日执行避免每天下载几百MB if [ $(date %u) 7 ]; then echo Updating CVE/OVAL/USN databases... | tee -a $LOG_FILE vuls fetch nvd jvn oval --dbpath /home/vuls/db/cve.sqlite3 --debug $LOG_FILE 21 vuls fetch usn --dbpath /home/vuls/db/usn.sqlite3 --debug $LOG_FILE 21 fi # 2. 执行扫描 echo Scanning target servers... | tee -a $LOG_FILE vuls scan -config/home/vuls/config.toml $LOG_FILE 21 # 3. 生成报告 echo Generating reports... | tee -a $LOG_FILE vuls report -config/home/vuls/config.toml -format-html -format-json $LOG_FILE 21 # 4. 清理旧报告保留最近7天 find /home/vuls/reports/html -name index_*.html -mtime 7 -delete find /home/vuls/reports/json -name *.json -mtime 7 -delete # 5. 发送邮件摘要仅当发现 Critical/High 漏洞时 CRITICAL_COUNT$(grep -c Critical.*Not Fixed /home/vuls/reports/html/index.html 2/dev/null || echo 0) HIGH_COUNT$(grep -c High.*Not Fixed /home/vuls/reports/html/index.html 2/dev/null || echo 0) if [ $CRITICAL_COUNT -gt 0 ] || [ $HIGH_COUNT -gt 0 ]; then echo ALERT: Found $CRITICAL_COUNT Critical and $HIGH_COUNT High vulnerabilities! | mail -s Vuls Alert: $(hostname) security-teamexample.com fi echo Vuls Daily Scan completed at $(date) | tee -a $LOG_FILE第二步添加到 crontab# 切换到 vuls 用户 sudo su - vuls # 编辑 crontab crontab -e # 添加以下行每天凌晨2点执行 0 2 * * * /home/vuls/scripts/daily-scan.sh # 保存退出第三步配置邮件服务以 Postfix 为例sudo apt install -y postfix mailutils # 安装时选择 Internet SiteFQDN 填写你的域名如 vuls-monitor.example.com # 测试邮件 echo Test email from Vuls | mail -s Vuls Test your-emailexample.com这套自动化体系运行三个月后我们团队的平均漏洞修复周期从原来的 14 天缩短到了 3.2 天。因为安全负责人每天早上打开邮箱就能看到一份清晰的、带链接的、可操作的漏洞清单而不是一份需要花半天时间去解读的 PDF 报告。4. 常见问题与实战排障那些官方文档里不会写的“踩坑笔记”4.1 问题速查表高频故障与一键修复方案问题现象根本原因一键修复命令经验备注vuls scan报错failed to scan: failed to run command: ssh: connect to host X.X.X.X port 22: Connection refused目标主机 SSH 服务未启动或防火墙阻止了 22 端口sudo ufw allow 22(Ubuntu 默认防火墙) 或sudo systemctl start sshUbuntu 22.04 Server 默认安装openssh-server但 Desktop 版默认不安装需手动sudo apt install openssh-servervuls scan报错failed to scan: failed to run command: sudo: a password is requiredVuls 配置中sudo true但目标主机的ubuntu用户没有免密 sudo 权限echo ubuntu ALL(ALL) NOPASSWD: ALLsudo tee /etc/sudoers.d/vulsvuls report生成的 HTML 报告中USN 链接全部为#无法跳转config.toml中未配置usnDict或vuls fetch usn命令执行失败vuls fetch usn --dbpath /home/vuls/db/usn.sqlite3 --debug然后检查config.toml中usnDict路径是否正确vuls fetch usn会下载一个约 50MB 的 XML 文件如果网络不稳定会静默失败务必加--debug查看日志扫描报告中大量Unknown严重等级的漏洞Vuls 无法从 NVD 数据库中获取该 CVE 的 CVSS 评分通常是因为 CVE 还很新NVD 尚未完成评分手动访问 https://nvd.nist.gov/vuln/detail/CVE-XXXX-XXXX查看其 CVSS v3.1 分数这不是 bug是 NVD 的数据延迟。Vuls 会如实反映这一状态提醒你关注新漏洞vuls scan执行缓慢单台主机耗时超过 10 分钟目标主机dpkg -l输出行数过多如安装了上千个包或 SSH 连接延迟高在config.toml的[servers.xxx]区块下添加scanMode fastfast模式会跳过一些耗时的命令如systemctl list-units只扫描核心包速度提升 3 倍适合大规模巡检4.2 深度排障一次真实的“内核漏洞误报”溯源上周Vuls 报告在一台 Ubuntu 22.04 主机上发现了CVE-2023-1076Linux Kernelbpfsubsystem 漏洞严重等级为 Critical状态为Not Fixed。这让我非常紧张因为该主机运行着核心的 Kubernetes 控制平面。我立刻登录主机执行uname -r得到5.15.0-86-generic。然后我去查 USN-6421-1发现它明确写着“Fixes CVE-2023-1076 for kernel 5.15.0-86.91”而我的内核版本是5.15.0-86-generic看起来没毛病。但 Vuls 为什么说Not Fixed我决定深入日志。首先找到 Vuls 的扫描日志# Vuls 的扫描结果 JSON 文件里包含了所有原始命令输出 cat /home/vuls/results/192.168.1.101/20231201_020000.json | jq .ScannedCves[] | select(.CveIDCVE-2023-1076)输出中有一段关键信息Package: { Name: linux-image-5.15.0-86-generic, Version: 5.15.0-86.91, Status: Not Fixed }哦原来 Vuls 检测的不是uname -r的内核版本而是linux-image-*这个包的版本。我立刻在主机上执行dpkg -l | grep linux-image-5.15.0-86 # 输出ii linux-image-5.15.0-86-generic 5.15.0-86.90 amd64 Signed kernel image generic果然包版本是5.15.0-86.90而 USN 要求的是5.15.0-86.91。这就是问题根源内核包更新了但grub配置还没生效所以uname -r还显示旧版本而dpkg -l显示的是已安装的最新包。解决方案很简单sudo update-grub sudo reboot。重启后uname -r变为5.15.0-86-genericdpkg -l显示的包版本也变成了5.15.0-86.91Vuls 下次扫描就会标记为Fixed。这个案例教会我Vuls 的报告永远以dpkg的事实为准而不是uname的表象。在处理内核漏洞时一定要交叉验证dpkg -l、uname -r和grub-reboot的状态。4.3 性能优化与资源控制让 Vuls 在低配服务器上也能飞很多团队想把 Vuls 扫描器部署在一台 2 核 4GB 的云服务器上但发现扫描 20 台主机时内存占用飙升到 90%扫描时间长达 40 分钟。这不是 Vuls 的问题而是配置不当。Vuls 默认是并发扫描所有主机这会瞬间建立 20 个 SSH 连接每个连接都要执行dpkg -l输出可能上万行内存压力巨大。解决方案是精细控制并发度# 在 config.toml 的全局配置区文件开头添加 [default] maxConcurrentScan 3 maxConcurrentScanners 2maxConcurrentScan 3表示最多同时扫描 3 台主机maxConcurrentScanners 2表示每个主机内部最多并发执行 2 个扫描命令如dpkg -l和uname -r并行。这样20 台主机会被分成 7 批3333332内存峰值下降 60%总扫描时间只增加 15%。另一个技巧是对于只关心关键服务的场景可以定制扫描命令跳过耗时的全包扫描[servers.target1] # ... 其他配置 [servers.target1.scan] # 只扫描指定的几个关键包大幅提速 packages [nginx-full, openssl, python3, kernel, docker.io]packages [...]会让 Vuls 只执行dpkg -l | grep -E nginx-full|openssl|...而不是dpkg -l全量输出扫描时间从 3 分钟缩短到 20 秒。这在应急响应时非常有用——当你收到某个 CVE 的预警只想快速确认自己有没有受影响的包而不是做一次全盘扫描。5. 进阶应用与生态集成从单机扫描器到企业级安全中枢5.1 与 CI/CD 流水线集成在代码合并前就堵住漏洞Vuls 最强大的延伸是把它嵌入到软件交付的源头。我们团队将 Vuls 集成到了 GitLab CI 中实现了“代码提交即扫描”。原理很简单在 CI 流水线的build阶段之后deploy阶段之前插入一个vuls-scanjob它会扫描本次构建生成的 Ubuntu 22.04 Docker 镜像。第一步在 CI Runner 上预装 Vuls# 在 GitLab Runner 的 Docker executor 镜像中Dockerfile 添加 FROM ubuntu:22.04 RUN apt update apt install -y curl wget \ curl -L https://github.com/future-architect/vuls/releases/download/v0.25.0/vuls_0.25