Debian 系的补丁源要成对检查
Debian 与 Ubuntu 把安全更新放在单独的 -security 源里，与普通功能更新的 -updates 分开维护。补丁管理的第一步不是升级，而是确认安全源确实启用：只写了普通镜像源、漏掉安全源的机器看上去能升级，实际长期缺少安全补丁。之后用待升级清单区分安全与普通更新，报告中把两类分开统计，处置优先级一目了然。
基本信息
| 加固项 | 安全补丁获取与积压监控 |
|---|---|
| 适用平台 | Linux（Debian、Ubuntu 及衍生版） |
| 权限要求 | root 或 sudo |
| 达标判据 | 安全源启用、无长期积压的安全更新 |
| 关键文件 | /etc/apt/sources.list 与 /etc/apt/sources.list.d/ |
典型使用场景
- 例行巡检统计待升级包数量与其中安全类占比
- 新装系统检查软件源是否完整（含安全源）
- Ubuntu LTS 长期运行的服务器确认补丁没有积压
- 升级前预览影响范围，避免误触发大版本变化
- 离线内网环境确认自有镜像是否同步安全仓库
清单与源核查
清单与源核查
apt update # 先刷新元数据
apt list --upgradable 2>/dev/null | head -30 # 待升级清单
apt list --upgradable 2>/dev/null | wc -l # 总数，用于趋势跟踪
/usr/lib/update-notifier/apt-check --human-readable # 待升级与安全更新数量摘要
grep -R 'security' /etc/apt/sources.list /etc/apt/sources.list.d/ | head # 安全源是否存在分批升级与复核
分批升级与复核
apt-get upgrade -s | head -20 # 模拟执行，先看会动哪些包
apt-get install --only-upgrade <包名> # 按包逐个升级，便于回滚与分批
apt-get upgrade -y # 常规升级（不删除、不新增依赖）
apt-get dist-upgrade -s | head -20 # 预览依赖变化较大的场景
ls /var/run/reboot-required 2>/dev/null && cat /var/run/reboot-required.pkgs # 重启需求阅读要点
| 项目 | 含义 | 判读 |
|---|---|---|
| -security 源 | 安全补丁仓库 | 缺失即代表长期无法获取安全更新 |
| -updates 源 | 常规缺陷修复 | 与安全源分开统计，避免混淆 |
| apt list --upgradable | 可升级包清单 | 关注数量趋势与异常积压 |
| apt-check 摘要 | 待升级与安全更新数 | 报告中最直观的两个数字 |
| reboot-required | 内核与关键库升级后的重启提示 | 存在时需排窗口重启才真正生效 |
Ubuntu LTS 的 -security 与 -updates 分开维护，报告里把两类分开统计更专业，也便于解释“为什么有 30 个待升级但只有 3 个是安全类”。内网自建镜像环境要额外确认镜像同步了安全仓库，否则源地址写在配置里也不代表有补丁可装。
apt upgrade 与 dist-upgrade 行为不同：前者不会因依赖变化删除或新增包，后者可能移除现有包。跨大版本或依赖变化大的场景应当预览输出后按变更流程执行，而不是在业务高峰直接执行。