4. 脆弱性分析：技术脆弱性与管理脆弱性、漏洞扫描基础、脆弱性评估标准（CVSS）
脆弱性分析，说白了就是回答一个问题：“我们的系统到底哪里容易出问题？”
很多人一听到“脆弱性”，第一反应就是漏洞——CVE、缓冲区溢出、SQL注入。但我在实际项目中踩过不少坑，发现真正让安全团队头疼的，往往不是技术漏洞本身，而是那些管理上的“软肋”。比如，服务器补丁打得挺勤，但离职员工的账号三个月都没回收——你说这算不算脆弱性？
所以这一章，我们把脆弱性掰开来看：技术层面的、管理层面的，以及怎么用工具和标准去衡量它们。
4.1 技术脆弱性与管理脆弱性
脆弱性不只是代码里的bug。我习惯把它分成两类：
| 类型 | 典型例子 | 发现方式 | 修复难度 |
|---|---|---|---|
| 技术脆弱性 | 未打补丁的OpenSSL、弱口令、开放的非必要端口 | 漏洞扫描、渗透测试 | 通常有补丁或配置方案 |
| 管理脆弱性 | 缺乏变更审批流程、备份策略缺失、安全培训不足 | 审计、访谈、文档审查 | 涉及流程和制度，周期长 |
关键认知：技术脆弱性是“点”，管理脆弱性是“面”。一个管理混乱的团队，即使技术漏洞修得再快，也会不断产生新的脆弱性。
举个例子。我曾经给一家金融科技公司做评估，他们的WAF规则配得很严，SQL注入基本打不进去。但我去机房一看，运维人员把数据库备份的明文文件直接放在了一个匿名可读的共享目录里——这就是典型的管理脆弱性。技术防得再好，管理上漏个洞，全白搭。
4.1.1 技术脆弱性：常见的“硬伤”
- 配置不当：默认口令、调试接口未关闭、错误信息泄露。我记得有个项目，Tomcat的管理后台用的是admin/admin，扫描器五分钟就进去了。
- 版本滞后：依赖库或操作系统存在已知漏洞。比如Log4j爆发时，很多团队连自己用了哪些版本的Log4j都说不清。
- 设计缺陷：认证机制薄弱、加密算法过时、权限校验缺失。
4.1.2 管理脆弱性：看不见的“内伤”
- 人员管理：权限未定期复核、离职账号未清理、第三方人员缺乏监管。
- 流程缺失：变更管理混乱、应急响应预案从未演练、安全开发流程形同虚设。
- 意识不足：员工对钓鱼邮件毫无防备、密码写在便签纸上贴在显示器旁。
我的习惯：做脆弱性分析时，我会同时拉两份清单——一份是扫描器出的技术漏洞报告，另一份是访谈和文档审查出的管理缺陷清单。两份合在一起，才能看清全貌。
4.2 漏洞扫描基础
漏洞扫描是发现技术脆弱性的主要手段。说白了，就是让工具去“敲门”，看看哪些门是虚掩的。
4.2.1 扫描器的工作原理
- 资产发现：先搞清楚目标网络里有哪些活着的IP和开放端口。
- 服务识别：识别端口背后的服务类型和版本（比如Apache 2.4.49）。
- 漏洞匹配：将服务版本与漏洞库（如CVE、NVD）进行比对。
- 验证尝试：部分扫描器会尝试模拟攻击，确认漏洞是否真实存在。
注意：扫描器不是万能的。它只能发现已知漏洞，对逻辑漏洞、业务漏洞基本无能为力。我曾经见过一个团队完全依赖扫描器，结果被一个简单的越权漏洞搞垮了——因为扫描器根本测不出“用户A能看到用户B的订单”这种问题。
4.2.2 常见扫描工具对比
| 工具 | 类型 | 适用场景 | 特点 |
|---|---|---|---|
| Nessus | 商业/社区版 | 企业内网、合规检查 | 报告详尽，插件丰富 |
| OpenVAS | 开源 | 预算有限的团队 | 功能强大，但配置复杂 |
| Nmap + NSE | 开源 | 快速探测、定制化扫描 | 灵活，但需要脚本编写能力 |
| Qualys | SaaS | 多云环境、持续监控 | 无需部署，按需付费 |
我个人习惯在项目初期先用Nmap做快速资产梳理，再用Nessus或OpenVAS做深度扫描。这样效率最高，不会一上来就被海量告警淹没。
4.2.3 扫描的“坑”与避坑
- 误报：扫描器说存在漏洞，但实际是误判。我遇到过扫描器把Tomcat的示例页面报成严重漏洞，其实那个页面根本没部署。
- 漏报：扫描器没发现，但漏洞真实存在。尤其是那些需要多步触发的漏洞。
- 业务影响：某些扫描方式（如尝试登录、发送畸形包）可能导致服务宕机。记得在非生产环境先试一把。
避坑指南：我曾经因为没做扫描策略调优，直接把一个老旧ERP系统扫挂了。从那以后，我定了个规矩：扫描前必须确认目标系统的容灾能力，关键系统先做“低烈度”扫描。
4.3 脆弱性评估标准：CVSS
发现一堆漏洞之后，怎么排优先级？总不能所有漏洞都立刻修吧？这时候就需要CVSS（Common Vulnerability Scoring System）出场了。
CVSS，说白了就是给漏洞打分。分数越高，越要优先处理。目前主流是CVSS v3.1，分数范围0-10。
4.3.1 CVSS的三大维度
| 维度 | 含义 | 关键指标举例 |
|---|---|---|
| 基础指标 | 漏洞本身的固有属性 | 攻击向量（网络/本地）、攻击复杂度、权限要求 |
| 时间指标 | 随时间变化的因素 | 漏洞利用代码成熟度、补丁是否可用 |
| 环境指标 | 在特定环境下的影响 | 资产价值、安全要求（机密性/完整性/可用性） |
重点：基础指标是“出厂设置”，环境指标才是“定制化评分”。同一个漏洞，在互联网-facing的服务器和在内网测试机上，环境评分可能差很多。
4.3.2 评分等级
- None（0.0）：无风险。
- Low（0.1-3.9）：低风险，可延期处理。
- Medium（4.0-6.9）：中等风险，建议在计划内修复。
- High（7.0-8.9）：高风险，应尽快修复。
- Critical（9.0-10.0）：严重风险，必须立即响应。
嗯，这里要注意：CVSS分数只是一个参考，不能完全替代人工判断。我见过一个CVSS 9.8的漏洞，但因为攻击条件极其苛刻（需要物理接触），实际风险远低于一个CVSS 7.5但可以远程无认证利用的漏洞。
4.3.3 实战中的评分策略
我在做风险评估时，通常不会直接用CVSS原始分。我会做一次“环境校准”：
- 先拿到漏洞的基础评分。
- 再根据资产重要性调整：核心数据库的漏洞，分数上浮20%。
- 结合攻击面分析：如果漏洞暴露在公网，分数再上浮。
- 最后形成一张“修复优先级矩阵”。
举个例子：一个CVSS 7.5的RCE漏洞，如果只在内网管理段，且管理段有严格的ACL，我会把它降级为“高”而不是“紧急”。但如果这个漏洞在公网API网关上，那不用犹豫，立刻修。
4.4 本章知识结构图
下面这张图，把脆弱性分析的核心脉络串起来了。你可以把它当作一个检查清单：
4.5 小结
脆弱性分析不是简单地跑一遍扫描器就完事。你得同时看技术和管理的短板，用CVSS做初步排序，再结合业务环境做人工校准。嗯，说白了，就是“工具打底，人工兜底”。