通过资产识别、入口梳理、信任边界划分和攻击路径分析, 团队可以在代码编写前发现越权、注入、数据泄露和供应链风险。
从关键资产开始建模
先列出账号、权限、订单、配置、模型提示词、密钥、日志等关键资产, 再判断这些资产被篡改、泄露、冒用或不可用时的业务影响。资产优先级决定安全设计投入顺序。
画出入口和信任边界
接口、后台、移动端、定时任务、消息队列、AI工具调用都可能成为入口。威胁建模要标出用户区、服务区、数据区、第三方区之间的信任边界, 找出需要鉴权、校验和审计的位置。
把威胁转为整改任务
每个威胁都要对应缓解措施和责任人。例如越权风险对应对象级权限校验, 数据泄露风险对应脱敏和导出审批, Prompt 注入风险对应工具调用白名单和输出过滤。
形成设计评审证据
管理侧需要保存评审纪要和风险接受记录, 安全保障侧需要在测试阶段复核威胁缓解是否有效, 研发侧则把控制项写入开发任务和代码审查清单。
落地检查清单
- 关键资产有优先级
- 入口和信任边界已标注
- 每个高风险威胁有缓解措施
- 评审结论进入研发任务
方案建议将本文控制项写入软件安全建议方案, 并分别指定研发负责人、管理审批人和安全保障复测人, 形成可追溯闭环。
常见问题
这类文章适合放在项目方案还是组织基线?
通用规则建议进入组织级软件安全基线, 项目方案只保留与当前系统风险、业务范围和上线节奏直接相关的控制项。
如何判断措施是否真正落地?
看是否同时具备责任人、执行记录、工具或人工验证结果、例外审批和复盘改进记录。缺少证据的措施不宜作为已完成项。