【云原生技术】sonar扫描出来的安全热点怎么处理？

SonarQube 把与安全相关的规则分成两类：
• Vulnerabilities —— 检测到的代码在当前状态下就能被利用，需要直接修复。
• Security Hotspots —— 代码位于“敏感区”，有被误用的风险，但是否真正成漏洞要靠人工判断。

处理 Security Hotspots 的核心不是“全部改掉”，而是“逐条评估、留下安全记录、必要时再修改”。下面给出一个常用、也较容易落地的流程。

---

一、建立最低限度的工作流

1. 报告收集
   • 在 CI 中跑 SonarQube，扫描完自动把热点列表推到合适的渠道（PR 检查、Jira、邮件等）。
2. 快速分派
   • 指派给代码所有者或安全 Champion。
3. 逐条评估（Review Hotspot）
   在 SonarQube Web UI 点进热点 → “Security Review” 面板，回答三类问题：
   a. 数据/参数是否来自不可信源？
   b. 是否已经有恰当的防护（校验、转义、访问控制等）？
   c. 攻击者在现实中能否利用？
4. 输出结论
   • Mark as “Safe”：说明防护充分，或业务不暴露风险，并给出简短理由（便于审计）。
   • Convert to “Vulnerability” 并修复：缺少防护或潜在影响大。
   • 留在 “To Review” 列表：实在拿不准时，让更资深的同事二次评估。
5. 固化政策
   • 设定 SLA：如高优先级 7 天内完成 Review，14 天内修复确认漏洞。
   • 把“所有热点必须有审计记录”写入质量门（Quality Gate），阻止 PR 合并。

---

二、常见热点及对应修复思路

1. SQL / NoSQL / LDAP / OS Command 组装
   • 使用参数化查询或 ORM；绝不用字符串拼接。
2. 反序列化
   • 禁用/替换 ObjectInputStream 等危险 API，或显式白名单。
3. 加密学使用
   • 避免裸用 MD5/sha1/ECB/RC4；改为 bcrypt/argon2, AES-GCM, HMAC-SHA-256 等现代算法。
4. 日志记录
   • 打日志前先脱敏或截断敏感数据；避免把异常栈直接返回到前端。
5. 随机数
   • 用加密安全随机源 SecureRandom / crypto.randomBytes；不要用 Math.random() 生成令牌。
6. 硬编码凭据
   • 迁移到环境变量或 Secrets Manager，并设定密钥轮换策略。

---

三、减少重复劳动的做法

• 自定义 Quality Profile：关闭对业务永远不适用的规则，减少噪声。
• 使用 // NOSONAR 或 @SuppressWarnings("java:Sxxxx") 对个别行做针对性抑制，并写清理由。
• 在 IDE 插件里即时扫描，开发阶段就能完成大部分 Review。
• 每季度做一次“热点沉淀”回顾，把长期标记为 Safe、理由一致的情况升级成代码规范或安全库封装。

---

四、示例：一次完整的 Review 记录

• 规则：S2078 – SQL Injection
• 位置：UserDao.java line 42
• 评估：该语句使用 MyBatis #{} 占位，参数 userId 来自经过 Long.parseLong() 的路径变量，且后台只暴露给内部网关。不存在拼接与外部输入传入的场景。
• 结论：Mark as Safe（已有参数化查询，风险可忽略）。

---

五、关键配置 & 参考

• Admin > Security > “Force user to provide review” 打开。
• 可以将 security_hotspots_reviewed 绑定到质量门阈值（100%）。
• 官方文档：docs.sonarsource.com → Clean as You Code → Security Hotspots.

只要把“扫描-评估-记录”固定到日常开发流程里，Security Hotspots 就不会演变成漏网的真正漏洞。