核心用法
Security Best Practices 是一套面向开发团队的代码安全审查工作流，强调"secure-by-default"原则与务实可操作的修复路径。其核心工作模式包含四个阶段：
1. 范围界定与证据收集：在输出任何结论前，必须确认系统边界、技术栈上下文及威胁假设——无证据则无发现。
2. 基线化风险评估：针对认证授权边界、输入验证、密钥管理、依赖供应链、日志与错误处理五大维度进行系统化扫描，避免临时性的 ad-hoc 检查。
3. 可验证的发现输出：每个漏洞需包含严重等级、代码位置、证据片段、影响说明及最小修复方向，杜绝推测性结论。
4. 可利用性优先的修复：按"可达性-权限需求-爆炸半径-滥用难度"排序，优先处理高置信度、可实际利用的问题；修复时采用单问题单批次策略，确保小 diff、行为保留、测试覆盖。
显著优点
- 工程友好：拒绝"重写架构"式建议，专注最小化 diff 修复，降低安全工作在迭代中的摩擦成本
- 证据驱动：强制要求代码级证据，避免 CVSS 评分或合规清单的纸上谈兵
- 本地优先：审查历史与例外记录存储于本地
~/security-best-practices/，默认零外泄 - 可审计的例外管理：明确的风险接受流程，支持带到期时间的例外登记
潜在局限
- 依赖人工上下文输入：技术栈、部署环境需用户主动提供，自动化程度有限
- 无实时漏洞情报：不集成 CVE 数据库或依赖扫描服务，需配合其他工具使用
- 修复保守主义："最小化变更"原则可能遗漏深层架构缺陷的根治机会
- 学习曲线：证据标准与严重度模型需要团队磨合
适合人群
- 需要集成安全审查到日常开发的工程团队
- 缺乏专职安全工程师的中小规模技术组织
- 对"安全报告洪水"感到疲劳、希望聚焦可行动项的技术负责人
常规风险
- 范围蠕变：用户可能期望该技能替代渗透测试或合规审计，实则定位为代码级辅助工具
- 例外累积：若例外登记缺乏治理，可能形成"永久例外"债务
- 过度自信：单次审查通过不代表系统安全，需建立持续回归验证机制