Debian系统使用debsecan查询漏洞列表

Debian 系统的安全更新机制非常稳健，但面对每天新增的 CVE 漏洞，运维人员最头疼的问题是如何快速确认自己负责的服务器到底受哪些漏洞影响。apt update 只能告诉你软件包有更新，却不会明确告诉你当前系统残留了哪些已知漏洞。这时候，debsecan 这个工具的价值就体现出来了。它能直接对照 Debian 安全追踪器（Security Tracker）的数据，把系统当前安装的软件包与已知漏洞数据库进行比对，生成一份清晰的漏洞清单。

安装 debsecan 非常简单，它就在 Debian 的官方软件源里。执行以下命令即可完成安装：

sudo apt update
sudo apt install debsecan

安装完成后，debsecan 不会自动开始工作。它需要一个漏洞数据源。默认情况下，debsecan 会从 Debian 安全追踪器下载数据，但如果你希望离线使用或者加快查询速度，可以先手动更新它的数据库。实际上，debsecan 在每次运行时如果发现本地数据过期，也会自动尝试下载，但主动更新是个好习惯。你可以用这个命令强制更新数据：

sudo debsecan --update

这个操作会从 security-tracker.debian.org 拉取最新的漏洞信息，存储在本地的 /var/lib/debsecan/ 目录下。数据下载完成后，就可以开始查询漏洞了。

直接运行 debsecan 不带任何参数，它会输出一个列表，包含当前系统上所有已安装软件包对应的已知漏洞。但这个列表通常非常长，而且包含大量状态为“已修复”的漏洞，信息噪音很大。实际运维中，我们更关心那些还没被修复的漏洞。所以，最实用的基础命令是只显示“易受攻击”的漏洞：

debsecan --only-fixed

等等，这个参数名有点反直觉。--only-fixed 的意思是“只显示那些已经有修复方案但尚未安装的漏洞”。换句话说，就是列出当前系统存在的、可以通过升级软件包来修复的漏洞。这才是你真正需要处理的漏洞列表。输出格式大致如下：

CVE-2024-XXXXX   openssl (fixed in 1.1.1w-0+deb11u1)
CVE-2023-YYYYY   linux-image-amd64 (fixed in 5.10.197-1)

每一行都清楚地标明了 CVE 编号、受影响的软件包名称，以及修复该漏洞的版本号。你一眼就能看出哪些包需要升级，以及升级到什么版本才能堵上这个漏洞。

生产环境中，你不可能一次性处理所有漏洞。按照严重程度排优先级是标准做法。debsecan 支持用 --urgency 参数来过滤特定严重级别的漏洞。Debian 安全团队对漏洞的紧急程度分类包括：low、medium、high、critical 等。如果你只想看高危和严重漏洞，可以这样写：

debsecan --only-fixed --urgency high --urgency critical

这个命令会把低危和中危的漏洞全部过滤掉，只留下需要立即关注的高风险项。对于维护大量服务器的人来说，这个功能在制定修复计划时非常实用。你可以每天早上跑一次这个命令，确保没有新的高危漏洞被忽略。

仅仅知道 CVE 编号和修复版本还不够，你需要了解漏洞的具体描述、攻击向量和影响范围，才能评估风险。debsecan 提供了 --detail 参数，可以输出更丰富的信息：

debsecan --only-fixed --detail

输出会变成多行格式，每个漏洞条目下会附带一段描述文本，说明漏洞的成因、潜在危害以及 Debian 安全团队的处理状态。例如，你可能会看到某个漏洞被标记为“no-dsa”，这意味着 Debian 安全团队认为该漏洞不需要通过专门的安全公告（DSA）来修复，可能会随下一次常规更新一起推送。这类信息对判断修复紧迫性很有帮助。

有时候你只关心某个关键服务相关的漏洞，比如 OpenSSH 或者 Nginx。debsecan 允许你在命令末尾指定软件包名称，只查询这些包的漏洞情况：

debsecan --only-fixed openssh-server nginx

这种用法在排查特定服务安全隐患时非常高效。比如你刚听说 OpenSSL 爆出一个新的高危漏洞，就可以立刻用 debsecan 检查本地 OpenSSL 库是否受影响，而不必在一长串列表中大海捞针。

debsecan 默认输出是纯文本，适合人阅读，但不利于自动化处理。它内置了几种输出格式，通过 --format 参数可以切换。如果你想写脚本抓取漏洞数据，可以用 --format csv 或者 --format json 来生成结构化输出。不过需要留意的是，不同 Debian 版本中 debsecan 支持的格式可能略有差异，有些旧版本可能不支持 json 格式。你可以先运行 debsecan --help 查看当前版本支持哪些格式。对于较新的 Debian 12（Bookworm），csv 格式通常可用：

debsecan --only-fixed --format csv

这样输出就会变成逗号分隔的字段，方便导入到 Excel 或者用 awk、python 等工具进行二次处理。你可以写一个简单的定时任务，把每天的漏洞列表导出成 CSV 文件，然后通过邮件发送给自己，或者推送到内部的可视化看板上。

debsecan 的数据完全依赖 Debian 安全追踪器。这个追踪器由 Debian 安全团队维护，数据质量很高，但它不是实时同步的。一个新 CVE 从公开到被录入追踪器，可能存在几小时甚至一两天的延迟。所以，debsecan 不能替代入侵检测系统，它只是一个基于软件包版本的漏洞审计工具。另外，debsecan 只能判断软件包的版本是否低于修复版本，它不会分析你的实际配置是否缓解了漏洞。比如某个 Web 应用漏洞需要特定配置才会触发，而你恰好没有启用那个功能模块，debsecan 依然会报告这个漏洞。这需要运维人员结合实际情况做人工判断。

还有一点，debsecan 默认只追踪 Debian 官方源里的软件包。如果你从第三方源或者手动编译安装了某些软件，debsecan 无法追踪它们的安全状态。对于这类软件，你需要另外建立自己的漏洞管理流程。

把 debsecan 用好，关键在于让它成为日常巡检的一部分，而不是出了事才想起来跑一下。一个推荐的做法是配置 cron 定时任务，每天凌晨执行一次漏洞扫描，并把结果输出到日志文件。例如，在 /etc/cron.d/debsecan-check 里添加：

0 3 * * * root /usr/bin/debsecan --only-fixed --urgency high --urgency critical > /var/log/debsecan/daily-$(date +\%Y\%m\%d).log 2>&1

然后配合 logrotate 管理这些日志文件，保留最近 30 天的记录。这样你随时可以回溯某一天系统的高危漏洞状态，便于审计和合规检查。

对于使用配置管理工具（如 Ansible、Puppet）的环境，可以把 debsecan 的检查结果作为自动化修复的触发条件。比如 Ansible 剧本里可以写一个 task，先执行 debsecan 获取存在漏洞的软件包列表，然后自动执行 apt upgrade 对这些包进行升级。当然，自动升级有风险，建议先在测试环境验证，或者只对非核心业务服务器启用自动修复。

debsecan 专注于漏洞发现，它应该和你的其他安全工具形成互补。例如，配合 unattended-upgrades 可以实现自动安装安全更新，debsecan 则用来验证升级是否彻底覆盖了所有已知漏洞。你可以在 unattended-upgrades 运行后，再执行一次 debsecan 检查，确认没有遗漏的高危漏洞。如果发现仍有未修复项，就触发告警通知人工介入。

另外，对于需要合规审计的场景，debsecan 的输出可以作为证据材料，证明你在某个时间点对系统进行了漏洞排查，并记录了具体的 CVE 编号和处理状态。把每次扫描结果存档，在应对等保测评或内部安全审计时会很有说服力。

总之，debsecan 是一个轻量、直接、不花哨的工具，它解决的就是一个具体问题：我的 Debian 系统现在有哪些已知漏洞还没修？把它用熟，你会发现日常的安全运维工作变得清晰很多，不再需要对着 CVE 列表和 dpkg 输出手动比对了。