信一半。debsums和rpm-va仅校验文件与包数据库一致性，不防内存马、rootkit或运行时篡改，且校验数据本身可被特权攻击者篡改，需结合可信环境扫描、基线比对和行为上下文判断。
debsums 校验失败但软件正常运行，该信吗？
信一半。debsums 检查的是 /var/lib/dpkg/info/*.md5sums 里记录的文件哈希，不是当前包管理器状态的权威来源——它不感知 postinst 脚本改写的配置、不跟踪 systemd 单元覆盖、也不管你手动 touch 过的 /etc/default/foo。
常见误报场景：/etc 下被管理员修改的配置、logrotate 创建的 .1 备份、systemctl daemon-reload 后自动生成的 symlink。真问题往往藏在 debsums -c 输出里那些非 /etc 路径（比如 /usr/bin/xxx 或 /lib/systemd/system/xxx.service）的变更。
实操建议：
- 先跑
debsums -l看哪些包自带 md5sums —— 很多官方包（尤其安全敏感组件如openssl、openssh-server）压根没提供校验信息，debsums 对它们直接跳过 - 对关键服务，优先用
debsums -s <package></package>单独校验，避免全盘扫描干扰判断 - 若发现
/usr下二进制被改，别急着重装；先dpkg -L <package> | grep bin</package>定位原始路径，再md5sum手动比对磁盘文件和dpkg-deb -c解包出来的原始哈希
rpm -Va 报 “S” “T” “5” 到底哪个要处理？
rpm 的验证输出像密码：一行里 S（大小变）、T（时间戳变）、5（MD5 哈希变）意义完全不同。生产环境里，T 几乎总可忽略——内核更新后 /boot/vmlinuz-* 时间戳必然刷新；S 在日志轮转或临时缓存写入时也常见。真正危险的是 5，尤其出现在 /usr/bin/ 或 /lib64/ 下的 ELF 文件上。
实操建议：
- 过滤掉噪音：
rpm -Va 2>/dev/null | grep -E '^[^ ]{8}[^5]'排除所有含5的行，剩下的基本不用管 - 区分动静：对
/etc下文件报5，先查rpm -qf /etc/xxx确认归属包，再rpm -Vc <package></package>专看配置文件变更 - 注意 SELinux 上下文：某些 rpm -Va 会把 context 变更标为
c（但默认不显示），需加--setcaps或--setcontexts参数重验
debsums 和 rpm -Va 都不能替代入侵检测
两者只校验已安装文件是否与包数据库一致，完全不防内存马、rootkit 的内核模块注入、或 /tmp 下静默执行的恶意进程。更致命的是：debsums 的 md5sums 文件本身可被篡改（若攻击者已获 root），rpm 的数据库（/var/lib/rpm/）同样可被 rpm --force --nodeps 绕过。
实操建议：
- 校验动作必须在可信环境中运行：从只读 USB 启动 Live 系统再挂载原盘扫描，或使用
chroot到干净镜像里检查宿主机文件系统 - 定期导出基线：
rpm -qa --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' | sort > pkglist-baseline.txt，配合aide或tripwire做增量监控 - 不要依赖单次结果：把
debsums -c和rpm -Va | grep '^..5'加入 cron，输出到隔离日志，观察趋势——突然增多的5比单次异常更值得警觉
容器环境里这些命令基本失效
Debian/Ubuntu 容器镜像通常删掉了 /var/lib/dpkg/info/*.md5sums（减小体积），debsums 直接报 “no md5sums file”；RHEL/CentOS 容器则常以 --nodocs --noconflicts 构建，rpm 数据库不完整，rpm -Va 大量报 “file not owned by any package”。这不是误报，是设计如此。
实操建议：
- 镜像构建阶段就做完整性控制：用
apt-get install --download-only+apt download提前拉取 deb 包，用dpkg-deb --info校验签名后再解压 - 运行时换方案：在容器启动前，用
cosign verify-blob校验镜像层 digest，或集成trivy filesystem扫描挂载目录 - 若必须用 debsums/rpm-Va，得在基础镜像里显式保留校验数据：Debian 加
dpkg-reconfigure dpkg并选中 “Include MD5 checksums”，RHEL 加rpm --rebuilddb并确保/var/lib/rpm不被 .dockerignore 排除
真正难的不是跑通命令，是分辨哪一行输出背后是运维操作、哪一行背后是权限失控。校验工具永远只告诉你“不一样”，而“为什么不一样”得靠上下文补全——比如 /usr/bin/python3 的 5 是因为刚打了安全补丁，还是因为有人替换了它。
