漏洞扫描器
像攻击者一样思考，像专家一样防御。2025 威胁态势认知。
🔧 运行时脚本
执行以进行自动化验证：
| 脚本 | 用途 | 用法 |
|---|
scripts/security_scan.py | 验证已应用的安全原则 | python scripts/security_scan.py <project_path> |
📋 参考文件
1. 安全专家思维模式
核心原则
| 原则 | 应用 |
|---|
| 假设已被入侵 | 像攻击者已经在内部一样进行设计 |
| 零信任 | 从不信任，始终验证 |
| 纵深防御 | 多层防护，无单点 |
| 最小权限 | 仅授予所需的最小访问权限 |
| 安全失败 | 出错时拒绝访问 |
威胁建模问题
在扫描之前，先问：
- 我们在保护什么？（资产）
- 谁会攻击？（威胁行为者）
- 他们会如何攻击？（攻击向量）
- 影响是什么？（业务风险）
2. OWASP Top 10:2025
风险类别
| 排名 | 类别 | 思考要点 |
|---|
| A01 | 失效的访问控制 | 谁能访问什么？IDOR、SSRF |
| A02 | 安全配置错误 | 默认值、标头、暴露的服务 |
| A03 | 软件供应链 🆕 | 依赖项、CI/CD、构建完整性 |
| A04 | 加密失败 | 弱加密、暴露的密钥 |
| A05 | 注入 | 用户输入 → 系统命令 |
| A06 | 不安全设计 | 有缺陷的架构 |
| A07 | 认证失败 | 会话、凭据管理 |
| A08 | 完整性失败 | 未签名的更新、被篡改的数据 |
| A09 | 日志与告警 | 盲点、无监控 |
| A10 | 异常情况 🆕 | 错误处理、失效开放状态 |
2025 关键变化
2021 → 2025 Shifts:
├── SSRF merged into A01 (Access Control)
├── A02 elevated (Cloud/Container configs)
├── A03 NEW: Supply Chain (major focus)
├── A10 NEW: Exceptional Conditions
└── Focus shift: Root causes > Symptoms
3. 供应链安全（A03）
攻击面
| 向量 | 风险 | 要问的问题 |
|---|
| 依赖项 | 恶意软件包 | 我们是否审计新依赖项？ |
| 锁文件 | 完整性攻击 | 它们是否已提交？ |
| 构建管道 | CI/CD 被攻陷 | 谁可以修改？ |
| 注册表 | 域名抢注 | 来源是否已验证？ |
防御原则
- 验证软件包完整性（校验和）
- 锁定版本，审计更新
- 对关键依赖项使用私有注册表
- 签名并验证制品
4. 攻击面映射
要映射什么
| 类别 | 元素 |
|---|
| 入口点 | API、表单、文件上传 |
| 数据流 | 输入 → 处理 → 输出 |
| 信任边界 | 检查认证/授权的位置 |
| 资产 | 密钥、PII、业务数据 |
优先级矩阵
Risk = Likelihood × Impact
High Impact + High Likelihood → CRITICAL
High Impact + Low Likelihood → HIGH
Low Impact + High Likelihood → MEDIUM
Low Impact + Low Likelihood → LOW
5. 风险优先级排序
CVSS + 上下文
| 因素 | 权重 | 问题 |
|---|
| CVSS 评分 | 基础严重性 | 漏洞有多严重？ |
| EPSS 评分 | 利用可能性 | 它正在被利用吗？ |
| 资产价值 | 业务上下文 | 什么处于风险之中？ |
| 暴露面 | 攻击面 | 是否面向互联网？ |
优先级排序决策树
Is it actively exploited (EPSS >0.5)?
├── YES → CRITICAL: Immediate action
└── NO → Check CVSS
├── CVSS ≥9.0 → HIGH
├── CVSS 7.0-8.9 → Consider asset value
└── CVSS <7.0 → Schedule for later
6. 异常情况（A10 - 新增）
失效开放 vs 失效关闭
| 场景 | 失效开放（不好） | 失效关闭（好） |
|---|
| 认证错误 | 允许访问 | 拒绝访问 |
| 解析失败 | 接受输入 | 拒绝输入 |
| 超时 | 永远重试 | 限制 + 中止 |
要检查什么
- 捕获所有异常并忽略的异常处理器
- 安全操作上缺少错误处理
- 认证/授权中的竞态条件
- 资源耗尽场景
7. 扫描方法
基于阶段的方法
1. RECONNAISSANCE
└── Understand the target
├── Technology stack
├── Entry points
└── Data flows
2. DISCOVERY
└── Identify potential issues
├── Configuration review
├── Dependency analysis
└── Code pattern search
3. ANALYSIS
└── Validate and prioritize
├── False positive elimination
├── Risk scoring
└── Attack chain mapping
4. REPORTING
└── Actionable findings
├── Clear reproduction steps
├── Business impact
└── Remediation guidance
8. 代码模式分析
高风险模式
| 模式 | 风险 | 关注点 |
|---|
| 查询中的字符串拼接 | 注入 | "SELECT * FROM " + user_input |
| 动态代码执行 | RCE | eval()、exec()、Function() |
| 不安全的反序列化 | RCE | pickle.loads()、unserialize() |
| 路径操纵 | 遍历 | 文件路径中的用户输入 |
| 禁用安全机制 | 多种 | verify=False、--insecure |
密钥模式
| 类型 | 指示符 |
|---|
| API 密钥 | api_key、apikey、高熵 |
| 令牌 | token、bearer、jwt |
| 凭据 | password、secret、key |
| 云 | AWS_、AZURE_、GCP_ 前缀 |
9. 云安全注意事项
责任共担
| 层 | 你负责 | 提供商负责 |
|---|
| 数据 | ✅ | ❌ |
| 应用 | ✅ | ❌ |
| 操作系统/运行时 | 视情况而定 | 视情况而定 |
| 基础设施 | ❌ | ✅ |
云特定检查
- IAM：是否应用了最小权限？
- 存储：是否有公开存储桶？
- 网络：安全组是否已收紧？
- 密钥：是否使用密钥管理器？
10. 反模式
| ❌ 不要 | ✅ 要 |
|---|
| 在不了解的情况下扫描 | 先绘制攻击面 |
| 对每个 CVE 都告警 | 按可利用性 + 资产进行优先级排序 |
| 忽略误报 | 维护经验证的基线 |
| 只修复症状 | 解决根本原因 |
| 部署前扫描一次 | 持续扫描 |
| 盲目信任第三方依赖 | 验证完整性、审计代码 |
11. 报告原则
发现结构
每项发现都应回答：
- 是什么？ - 清晰的漏洞描述
- 在哪里？ - 确切位置（文件、行、端点）
- 为什么？ - 根本原因解释
- 影响？ - 业务后果
- 如何修复？ - 具体修复措施
严重性分类
| 严重性 | 标准 |
|---|
| 严重 | RCE、认证绕过、大规模数据泄露 |
| 高 | 数据泄露、权限提升 |
| 中 | 范围有限，需要特定条件 |
| 低 | 信息性、最佳实践 |
记住： 漏洞扫描发现问题。专家思维会优先考虑重要的事项。始终问自己：“攻击者会利用这个做什么？”
