findscripter 何时使用
- 对系统/服务/架构做安全设计评审或威胁建模会议，需要系统化、无遗漏地枚举攻击面时使用。
- 评估既有架构的安全决策、绘制数据流图（DFD）识别信任边界跨越点、为合规/审计准备威胁文档时使用。
- 目标产物：一份结构化威胁模型（资产清单、信任边界、按 STRIDE 分类的威胁矩阵、风险评分排序、对应缓解措施）。
不该用：
- 扫第三方依赖的已知漏洞（CVE）、许可证与供应链风险 → 用
dependency-auditor。 - 审查自有代码的具体逻辑漏洞（注入实现、鉴权代码缺陷）→ 用
code-reviewer。 - 渗透测试、运行时入侵检测、密钥泄露扫描 → 超出范围；STRIDE 是设计期/评审期的威胁枚举方法，不替代动态测试。
STRIDE 六类（核心速查）
每一类对应一种被破坏的安全属性与控制族，逐类提问才不会漏：
| 类别 | 提问 | 被破坏属性 | 控制族 |
|---|---|---|---|
| S 假冒 Spoofing | 攻击者能冒充他人/他系统吗？ | 真实性 | 身份认证 |
| T 篡改 Tampering | 能修改传输中/存储中的数据吗？ | 完整性 | 完整性校验 |
| R 抵赖 Repudiation | 能否抵赖自己做过的操作？ | 不可否认 | 日志/审计 |
| I 信息泄露 Information Disclosure | 能访问到未授权数据吗？ | 机密性 | 加密 |
| D 拒绝服务 Denial of Service | 能破坏可用性吗？ | 可用性 | 限流/扩容 |
| E 权限提升 Elevation of Privilege | 能获得更高权限吗？ | 授权 | 访问控制 |
步骤 / 指令
- 画系统与数据流图（DFD）：标出四类元素——外部实体（external entity）、处理过程（process）、数据存储（data store）、数据流（data flow），并标注每条流的协议与是否加密。
- 标信任边界：典型边界为 外网→DMZ、DMZ→内网、应用→数据库。重点关注跨边界的数据流，尤其跨边界且未加密的流。
- 列资产并定敏感度：如用户凭据/PII（高）、会话数据（中）、配置与密钥（高）、日志（中），明确数据分类。
- 按元素类型套用 STRIDE：不同元素适用的威胁类别不同——外部实体只看 S、R；处理过程六类全看（S/T/R/I/D/E）；数据存储看 T/R/I/D；数据流看 T/I/D。逐元素（或逐交互）提问。
- 逐类提问枚举威胁：对每个组件按六类各问 3~4 个问题（见示例问卷），不跳过任何一类——每类揭示不同威胁。
- 评风险并排序：风险分 = 影响(1
4) × 可能性(14)。分级：≥12 严重、≥6 高、≥3 中、其余低。仅列前若干高风险项作为处置重点。 - 给缓解并跟踪状态：每条威胁配缓解措施与状态（open/mitigated）。不要止于「发现」，必须跟到处置。
- 输出文档：结构为 系统概述与 DFD → 信任边界 → 资产 → 六类威胁矩阵（ID/威胁/目标/影响/可能性）→ 风险排序 → 分阶段建议（立即/30 天/90 天）。威胁模型是活文档，需随架构演进定期更新。
示例
风险评分与威胁分级（Python，照搬源约束）：
from enum import Enum
class StrideCategory(Enum):
SPOOFING = "S"; TAMPERING = "T"; REPUDIATION = "R"
INFORMATION_DISCLOSURE = "I"; DENIAL_OF_SERVICE = "D"; ELEVATION_OF_PRIVILEGE = "E"
# 风险分 = 影响 × 可能性（各 1~4）
def risk_level(impact: int, likelihood: int) -> str:
score = impact * likelihood
if score >= 12: return "Critical"
if score >= 6: return "High"
if score >= 3: return "Medium"
return "Low"
按元素类型映射适用威胁（DFD 分析）：
threat_mapping = {
"external": ["S", "R"],
"process": ["S", "T", "R", "I", "D", "E"],
"datastore":["T", "R", "I", "D"],
"dataflow": ["T", "I", "D"],
}
# 重点：找出跨信任边界且未加密的数据流 —— 高优先级 I/T 威胁
逐组件 STRIDE 问卷（节选，每类 3~4 问）：
S 假冒：能否冒充合法用户？认证令牌是否被正确校验？会话 ID 可被预测/窃取吗？是否有 MFA？
T 篡改：传输中能否被改？静态能否被改？输入校验是否充分？应用逻辑能被操纵吗？
R 抵赖：所有安全相关操作都记日志了吗？日志可被篡改吗？归属是否充分？时间戳可靠同步吗？
I 泄露：静态/传输是否加密？错误信息会泄露敏感信息吗？访问控制是否落实？
D 拒服：是否限流？恶意输入能否耗尽资源？有无放大攻击防护？有无单点故障？
E 提权：授权检查是否一致？能访问他人资源吗（IDOR）？参数操纵能否提权？是否最小权限？
威胁矩阵片段（最小格式）：
| ID | 威胁 | 目标 | 影响 | 可能性 |
|----|---------------|--------------|----------|--------|
| T1 | SQL 注入 | 数据库查询 | Critical | Medium | → 风险 12 严重：参数化查询 + 输入校验
| E1 | IDOR | 用户资源 | High | High | → 风险 9 高：服务端授权校验
| S3 | 撞库 | 登录端点 | High | High | → 风险 9 高：MFA + 账户锁定
注意事项
- 不要跳过任何一类：六类各对应不同安全属性，遗漏一类即遗漏一类攻击面；每个组件都逐类过一遍。
- 质疑每个组件：不要默认任何组件安全；可视化的 DFD 帮助发现被忽视的信任边界跨越点。
- 协作而非闭门：拉上安全、研发、运维三方视角共同建模，单人建模易盲区。
- 现实地排优先级：聚焦高影响威胁，但低概率 × 高影响项不可忽视。
- 缓解措施按生命周期落地：常见缓解——S：MFA/安全会话/密码学令牌；T：参数化查询/HMAC/CSP；R：防篡改集中审计日志/数字签名；I：传输与静态加密/最小化错误信息；D：限流/自动扩容/熔断/配额；E：RBAC/最小权限/服务端权限校验。
- 活文档：架构变更后须更新威胁模型，否则评分与缓解会过期失效。
互见
- related：
dependency-auditor—— STRIDE 看系统设计层的威胁面，依赖审计看第三方包层的已知漏洞，二者在安全/审计维度互补。 - related：
code-reviewer—— STRIDE 在设计/评审期枚举威胁，code-reviewer 在实现期找具体代码缺陷，前者定方向后者落实现。
本条采编自 wshobson/agents（MIT）。