Vulnerability Scanner

漏洞扫描与分析

> 像攻击者一样思考，像专家一样防守。保持对 2025 威胁态势的感知。

运行时脚本

用于自动化验证：

| 脚本 | 用途 | 用法 | |------|------|------| | scripts/security_scan.py | 验证安全原则是否已落地 | python scripts/security_scan.py |

参考文件

| 文件 | 用途 | |------|------| | [checklists.md](checklists.md) | OWASP Top 10、认证、API、数据保护检查清单 |

---

1. 安全专家思维

核心原则

| 原则 | 应用 | |------|------| | Assume Breach（假设已失陷） | 按“攻击者已在内网”来设计 | | Zero Trust（零信任） | 永不默认信任，始终验证 | | Defense in Depth（纵深防御） | 多层防护，避免单点失败 | | Least Privilege（最小权限） | 仅授予必要访问权限 | | Fail Secure（安全失败） | 出错时默认拒绝访问 |

威胁建模问题

开始扫描前先问：

1. 我们要保护什么？（Assets 资产）
2. 谁会攻击我们？（Threat Actors 威胁主体）
3. 他们会如何攻击？（Attack Vectors 攻击向量）
4. 影响是什么？（Business Risk 业务风险）

---

2. OWASP Top 10:2025

风险类别

| 编号 | 类别 | 关注点 | |------|------|--------| | A01 | 访问控制失效（Broken Access Control） | 谁能访问什么？IDOR、SSRF | | A02 | 安全配置错误（Security Misconfiguration） | 默认配置、Header（响应头）、暴露服务 | | A03 | 软件供应链安全 🆕（Software Supply Chain） | 依赖、CI/CD、构建完整性 | | A04 | 密码学失效（Cryptographic Failures） | 弱加密、密钥暴露 | | A05 | 注入（Injection） | 用户输入是否可进入系统命令 | | A06 | 不安全设计（Insecure Design） | 架构层缺陷 | | A07 | 认证失效（Authentication Failures） | 会话与凭据管理 | | A08 | 完整性失效（Integrity Failures） | 未签名更新、数据篡改 | | A09 | 日志与告警缺失（Logging & Alerting） | 监控盲区、缺少告警 | | A10 | 异常条件处理失效 🆕（Exceptional Conditions） | 错误处理、Fail-open（失效即放行）状态 |

2025 关键变化

2021 -> 2025 变化：
+-- SSRF 并入 A01（访问控制）
+-- A02 权重提升（云/容器配置）
+-- A03 新增：供应链（重点）
+-- A10 新增：异常条件
+-- 重心迁移：根因优先于症状

---

3. 供应链安全（A03）

攻击面

| 向量 | 风险 | 需要确认的问题 | |------|------|----------------| | 依赖（Dependencies） | 恶意包投毒 | 新依赖是否审计？ | | 锁文件（Lock files） | 完整性攻击 | 是否已提交并受保护？ | | 构建流水线（Build pipeline） | CI/CD 被入侵 | 谁有修改权限？ | | 包仓库（Registry） | Typosquatting | 来源是否可信可验证？ |

防御原则

• 校验包完整性（checksum）
• 锁定版本并审计升级
• 关键依赖使用私有仓库
• 对构建产物签名并校验

---

4. 攻击面建模

需要建模的对象

| 类别 | 内容 | |------|------| | 入口点（Entry Points） | API、表单、文件上传 | | 数据流（Data Flows） | 输入 -> 处理 -> 输出 | | 信任边界（Trust Boundaries） | 鉴权/授权校验位置 | | 资产（Assets） | 密钥、PII、业务数据 |

优先级矩阵

风险 = 可能性 × 影响

高影响 + 高可能性 -> CRITICAL（严重）
高影响 + 低可能性 -> HIGH（高）
低影响 + 高可能性 -> MEDIUM（中）
低影响 + 低可能性 -> LOW（低）

---

5. 风险优先级排序

CVSS + 业务上下文

| 因素 | 权重 | 问题 | |------|------|------| | CVSS Score（评分） | 基础严重度 | 漏洞本身多严重？ | | EPSS Score（利用概率） | 被利用概率 | 是否正在被利用？ | | Asset Value（资产价值） | 业务权重 | 风险资产价值多高？ | | Exposure（暴露面） | 暴露面 | 是否公网可达？ |

优先级决策树

是否正在被利用（EPSS > 0.5）？
+-- 是 -> CRITICAL：立即处理
+-- 否 -> 检查 CVSS
         +-- CVSS ≥ 9.0 -> HIGH
         +-- CVSS 7.0-8.9 -> 结合资产价值评估
         +-- CVSS  排期处理

---

6. 异常条件处理（A10 - New）

Fail-Open 与 Fail-Closed

| 场景 | Fail-Open（不安全） | Fail-Closed（安全） | |------|--------------------|---------------------| | 鉴权异常 | 允许访问 | 拒绝访问 | | 解析失败 | 继续接受输入 | 拒绝输入 | | 超时处理 | 无限重试 | 限次后中止 |

重点检查项

• 全量捕获并吞掉异常的处理器
• 安全关键操作缺失错误处理
• 鉴权/授权中的竞态条件（Race Condition）
• 资源耗尽场景

---

7. 扫描方法论

分阶段方法

1. RECONNAISSANCE（侦察）
   +-- 理解目标系统
       +-- 技术栈
       +-- 入口点
       +-- 数据流

2. DISCOVERY（发现）
   +-- 识别潜在问题
       +-- 配置审查
       +-- 依赖分析
       +-- 代码模式检索

3. ANALYSIS（分析）
   +-- 验证与优先级排序
       +-- 排除误报
       +-- 风险评分
       +-- 攻击链映射

4. REPORTING（报告）
   +-- 输出可执行结论
       +-- 清晰复现步骤
       +-- 业务影响
       +-- 修复建议

---

8. 代码模式分析

高风险模式

| 模式 | 风险 | 关注点 | |------|------|--------| | 查询拼接字符串 | 注入风险（Injection） | "SELECT * FROM " + user_input | | 动态执行代码 | RCE | eval(), exec(), Function() | | 不安全反序列化 | RCE | pickle.loads(), unserialize() | | 路径拼接可控 | 路径穿越（Traversal） | 用户输入参与文件路径 | | 关闭安全校验 | 多类风险 | verify=False, --insecure |

密钥泄露模式

| 类型 | 指标 | |------|------| | API Keys（密钥） | api_key、apikey、高熵字符串 | | Tokens（令牌） | token、bearer、jwt | | Credentials（凭据） | password、secret、key | | Cloud（云平台） | AWS_、AZURE_、GCP_ 前缀 |

---

9. 云安全考量

责任共担模型

| 层级 | 你负责 | 云厂商负责 | |------|--------|------------| | 数据（Data） | [OK] | [FAIL] | | 应用（Application） | [OK] | [FAIL] | | 系统/运行时（OS/Runtime） | 视情况而定 | 视情况而定 | | 基础设施（Infrastructure） | [FAIL] | [OK] |

云侧专项检查

• IAM：是否落实最小权限？
• 存储：是否存在公开桶？
• 网络：安全组是否收敛？
• 密钥：是否使用 secrets manager（密钥管理服务）？

---

10. 反模式

| [FAIL] 禁止（Don't） | [OK] 推荐（Do） | |-----------------|-------------| | 不理解系统就开始扫描 | 先做攻击面建模 | | 对每个 CVE 都同级告警 | 按可利用性 + 资产价值排序 | | 忽略误报管理 | 维护经验证的基线 | | 只修症状不修根因 | 追到根因并修复 | | 仅在上线前扫描一次 | 持续扫描 | | 盲目信任第三方依赖 | 校验完整性并审计代码 |

---

11. 报告编写原则

漏洞项结构

每条发现都应回答：

1. What?（是什么） - 清晰漏洞描述
2. Where?（在哪里） - 精确位置（文件、行号、端点）
3. Why?（为什么） - 根因解释
4. Impact?（影响） - 业务后果
5. How to fix?（怎么修） - 明确修复方案

严重性分级

| 严重性 | 标准 | |--------|------| | Critical（严重） | RCE、认证绕过、大规模数据泄露 | | High（高） | 数据暴露、权限提升 | | Medium（中） | 影响范围有限且需特定条件 | | Low（低） | 信息提示/最佳实践类问题 |

---

> 牢记： 漏洞扫描负责“发现问题”，专家思维负责“优先级决策”。始终追问：“攻击者会怎样利用它？”

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: MisonL
• Source: MisonL/Ling
• License: MIT
• Homepage: https://www.npmjs.com/package/@mison/ling

Install and usage instructions live in the source repository linked above.