Lynis的Hardening index仅为内部加权通过率，非合规得分；不映射ISO27001/PCI DSS/CIS条款，需显式启用测试组、人工映射TEST ID至标准控制项，并结合环境验证建议可行性。
硬编码的 hardening index 不代表合规得分
Lynis 输出的 Hardening index（如 “Hardening index: 72”）是内部加权计算值，不是合规性分数。它不映射到 ISO27001、PCI DSS 或 CIS Benchmarks 的任意一条要求，也不做条款对齐——只是对已触发检查项的“通过率 + 权重”粗略汇总。如果你看到报告里写 “Compliance: PCI-DSS (68%)”，那其实是 Lynis 自己虚构的标签，背后没有标准基线比对逻辑。
真正生成合规建议必须启用具体测试组
默认运行 sudo lynis audit system 只会激活基础检查（用户、文件权限、服务状态），大量合规关键项根本不会执行。例如：kernel 组不启用，kernel.kptr_restrict 和 fs.suid_dumpable 就标为 NOT SCORED；ssh 组不启用，sshd_config 中 PermitRootLogin、MaxAuthTries 等 CIS SSH 要求就完全不扫描。
实操必须显式启用：
sudo lynis audit system --enable-tests "kernel,ssh,firewall,boot,fileintegrity"- 多个组名用英文逗号分隔，且必须用双引号包裹，否则 shell 解析失败
- 旧版 Lynis（≤3.0.5）加
--no-network防止卡在 NTP 检测上
加固建议要按 test ID 过滤并验证上下文
Lynis 每条建议都带唯一 TEST ID（如 SSH-7408 对应 UsePAM yes 缺失，BOOT-5122 对应 GRUB 缺少 mitigations=on）。但直接照搬建议可能出错：
-
SSH-7408建议开启 PAM，但若系统用 SSSD 或 LDAP 认证，强制开 PAM 可能导致登录中断 -
FILE-6310要求/tmp挂载noexec,nosuid,nodev，但某些 Java 应用临时解压依赖到/tmp，加noexec会崩溃 - 所有
kernel.*类建议（如kernel.yama.ptrace_scope = 1）必须确认当前内核是否支持该参数——老内核没编译 YAMA 模块时设了也无效
修复前先查参数是否生效：sysctl kernel.yama.ptrace_scope，再查模块：lsmod | grep yama。
合规输出需人工映射+外部聚合
Lynis 本身不输出标准合规报告（如 XCCDF、ARF 格式），它的 .dat 日志和终端输出全是自由文本。想对接 OpenSCAP 或上传到 SIEM，得靠外部工具解析：
- 用
--report-file /tmp/lynis.json --json（Lynis ≥3.0.6）生成结构化 JSON，再用脚本提取test_id、status、suggestion - 把
TEST ID映射到 CIS 控制项编号（例如SSH-7408 → CIS 5.2.13），这一步没有自动映射表，必须人工维护 - FABRIC 测试平台中用 UCA（Unified Compliance Aggregator）归一化 Lynis + OpenSCAP + AIDE 输出，才能得到可比的 0–100 分——单靠 Lynis 永远拿不到真实合规得分
最易被忽略的一点：Lynis 从不校验“建议是否真能落地”。比如它建议禁用 ipv6 模块来减小攻击面，但很多云厂商的元数据服务（如 AWS IMDSv2）强依赖 IPv6 地址，关了反而断服务。每条建议背后，都得有环境上下文验证。
