评审里的安全视角
安全评审的重点不是把每个漏洞都翻出来，而是形成固定的检查顺序：输入处理、认证授权、密钥与敏感数据、依赖引入。这四类问题覆盖了绝大多数真实事故，也最容易在评审阶段以很低成本拦下。评审人的任务是提出可验证的怀疑，而不是替代安全团队做完整渗透测试。
基本信息
| 输入处理 | 走查询参数、命令、模板的外部输入是否校验与转义 |
|---|---|
| 权限 | 接口是否鉴权、是否校验越权（横向与纵向） |
| 密钥 | 是否把令牌、证书、内网地址写进代码或日志 |
| 依赖 | 新增依赖的来源、版本与许可证是否合规 |
| 报告渠道 | 疑似漏洞走私下渠道，不写进公开评论 |
典型使用场景
- 新增对外接口时检查是否鉴权与限流，越权分支是否覆盖
- 拼接查询语句、Shell 命令、模板渲染的改动优先人工过一遍
- 引入或升级依赖时核对来源与版本，警惕名字相近的仿冒包
- 改动涉及日志与错误信息时，检查是否输出用户敏感字段
- 涉及文件上传、反序列化、路径拼接的改动，逐处确认边界处理
- 数据导出与批量查询类改动，检查是否可以被普通用户放大利用
快速自查
快速自查
git diff origin/main...HEAD --stat # 先看这次改动了哪些文件
git diff origin/main...HEAD # 逐段阅读改动内容
git diff origin/main...HEAD | grep -nE '(password|token|secret|api[_-]?key|PRIVATE KEY)' || true # 粗筛疑似泄露
git log --oneline origin/main..HEAD # 确认本 PR 的提交范围
git diff --name-only origin/main...HEAD # 列出改动文件，人工判断是否含配置四类高风险面
| 风险面 | 要问的问题 | 常见表现 |
|---|---|---|
| 输入处理 | 外部输入是否校验与转义 | 直接拼接查询、命令、模板 |
| 认证授权 | 是否鉴权、是否校验越权 | 缺少对象级权限判断 |
| 密钥数据 | 是否写入代码或日志 | 硬编码令牌、打印敏感字段 |
| 依赖引入 | 来源版本许可证是否可信 | 来源不明的同名包 |
自动扫描只能兜底：逻辑层的越权、业务规则绕过、校验顺序错误这类问题扫描器通常发现不了，必须靠人理解代码意图后再判断。
发现疑似漏洞时不要写进公开的 PR 评论，先按项目安全策略私下联系维护者，避免在修复完成前扩大暴露面。