04 漏洞从哪里来？——认知局限

方向一：不同角色的认知局限

（纵向分层分析）

1. 软件开发人员

• 安全编码意识不足
• 不了解OWASP Top 10漏洞原理（如未防范XSS、CSRF）
• 对内存管理、输入验证等底层机制理解不深刻（如C语言指针误用）
• 对第三方代码依赖风险缺乏认知
• 未审核开源组件漏洞（如Log4j2漏洞）
• 忽略依赖库的许可证合规性问题

2. 软件测试人员

• 安全测试能力缺失
• 仅关注功能测试，未覆盖渗透测试（如未检测SQL注入）
• 对模糊测试（Fuzz Testing）工具使用不熟练
• 漏洞评估标准模糊
• 对漏洞严重性分级错误（如误判高危漏洞为低风险）

3. IT运维人员

• 安全配置知识局限
• 未关闭冗余服务端口（如Redis未授权访问漏洞）
• 未及时更新补丁（如永恒之蓝漏洞利用）
• 应急响应经验不足
• 对入侵痕迹分析能力弱（如未识别隐蔽后门）

4. 业务需求人员

• 安全需求缺位
• 需求文档中未明确安全约束（如未要求密码复杂度策略）
• 过度追求功能交付速度，挤压安全设计时间

5. 业务部门人员

• 安全意识薄弱
• 使用弱密码、明文传输敏感数据（如邮件泄露客户信息）
• 忽视数据分类管理（如将生产数据同步至测试环境）

6. 基层管理人员

• 安全流程执行偏差
• 未严格执行代码审查规范（如跳过安全审计环节）
• 忽视团队安全培训（如未组织安全编码培训）

7. 中层管理人员

• 资源分配失衡
• 安全预算不足（如未采购WAF、IDS等防护设备）
• 安全团队与技术团队协作断层

8. 高级管理人员

• 战略级安全认知缺失
• 未建立安全文化（如企业内无安全考核机制）
• 对供应链安全、合规性要求（如GDPR）重视不足

方向二：不同认知领域的知识盲区

1. 操作系统层

• 内核机制误解
• 未限制特权进程（如Linux capabilities配置错误）
• 文件权限设置不当（如关键文件权限设为777）

2. 数据库系统

• 安全配置盲点
• 未配置安全验证机制（如MongoDB、Redis等）
• 应用系统使用最高权限账号（如MySQL的root、SQL Server的Administrator等）或者存在弱口令
• 未分离生产/测试数据库账号权限（如越权访问）

3. 中间件

• 协议实现漏洞
• 未禁用危险HTTP方法（如PUT/DELETE导致文件篡改）
• 对Web服务器（如Nginx/Apache）的HTTPS配置错误

4. 组件

• 版本管理缺失
• 使用含已知漏洞的旧版本组件（如Fastjson反序列化漏洞）
• 未监控CVE漏洞公告（如Struts2远程代码执行漏洞）

5. 网络协议

• 协议安全特性忽略
• 使用较弱加密算法的协议（如TLS 1.0、SSHv1）
• 未防范ARP欺骗、DNS劫持等中间人攻击

6. 开发框架

• 框架特性误用
• 未启用框架内置安全机制（如Spring Security配置不当）
• 过度依赖框架默认配置（如Django DEBUG模式暴露敏感信息）

总结与改进方向

1. 角色认知局限的改进

• 建立分层安全培训体系（开发人员学安全编码，高管学风险管理）
• 推行安全责任到人制度（如DevSecOps中的安全左移）

2. 技术认知局限的改进

• 构建领域知识图谱（如操作系统安全配置清单、组件漏洞数据库）
• 引入自动化工具（如组件依赖分析工具、代码安全检查工具）

- End -

下期分享

05 漏洞从哪里来？——体系痼疾（制度化）

从管理角度初探体系痼疾（谈制度化问题）

推荐阅读