secure-software-engineering

安全软件工程

在缺陷进入生产环境之前，就将安全纳入决策。这是一套以预防为导向的工作流，并不意味着设计或发布已安全。记录假设、收集到的证据、剩余风险，以及任何已接受例外的负责人。

适用场景

在开发新功能、集成、服务、API、租户边界、AI 能力或发布时，如果要回答“我们如何安全地构建它？”，请使用此技能。尽早开始；当架构、数据流、依赖项或威胁发生变化时，重新审视受影响的决策。

对于已授权的构建后评估，请勿使用此技能：请使用 security-audit-methodology。请勿将此技能用作现有代码库的漏洞扫描器；请使用经授权的扫描工具或专业安全评估。如果任务是将最终需求和阶段门槛正式化，请使用 spec-driven-development；如果要提出有证据支持的完成声明，请使用 verification-methodology。

不适用场景

对于端到端租户模型、控制平面与应用平面的部署位置、商业生命周期和 SaaS 运营架构，请使用 multi-tenant-saas-architecture；此技能负责威胁建模和可强制执行的隔离控制。对于租户需求量化、配额设定、公平性、负载/浸泡测试证据和单位成本权衡，请使用 capacity-and-cost-engineering。隐私生命周期和删除验证产物请交由 privacy-engineering 处理。

工作流

1. 需求：识别资产、参与方、危害、数据分类、法规或合同约束，以及安全目标。在选择控制措施之前，先编写可测试的验收标准。
2. 威胁建模：绘制数据流和信任边界；说明假设、滥用场景、缓解措施和剩余风险。STRIDE 是可选的术语体系，并非穷尽一切的方法。
3. 设计：选择符合信任模型的控制措施，包括服务端授权、数据隔离、安全故障处理行为和 AI 能力边界。说明为何不采用其他方案。
4. 实施：确保代码和配置能够强制执行每条边界；保护输入、输出、凭据、依赖项、日志和运维路径。
5. 评审与发布：通过直接证据验证控制措施，检查变更是否存在绕过途径，保留发布证据，并将事故或未遂事件反馈到需求和测试中。

如果证据与某项假设相矛盾，或设计发生变化，请返回受影响的阶段。当每项重大决策都有明确负责人、直接证据或明确的证据缺口，以及对剩余风险的处理结论时，即可结束。

参考文件

加载时机	文件
需要带版本固定的来源及其决策用途时	references/source-index.md
定义资产、边界、滥用场景或安全标准时	references/security-requirements-threat-modeling.md
选择身份、会话、权限或服务访问方式时	references/authentication-authorization.md
处理请求、文件、URL、序列化数据、输出或 AI 内容时	references/input-validation-data-handling.md
添加密钥、令牌、凭证或签名材料时	references/secrets-lifecycle.md
添加、更新、构建或发布依赖项时	references/dependency-supply-chain.md
设计日志、审计事件、监控或取证证据时	references/secure-logging-audit.md
在租户之间共享基础设施或数据时，包括控制平面／应用平面、租户上下文、支持访问或租户生命周期证明	references/multi-tenant-isolation.md
审查变更或定义安全审查门禁时	references/secure-code-review.md
为发布准备构件、例外、回滚或响应时	references/release-evidence.md；加载 release-engineering，以便在构建、注册表、晋级和部署门禁中贯彻这些控制与证据
从事故、险些发生的事故或已流出的缺陷中吸取经验时	references/incident-learning.md
设计 LLM、RAG 流水线、模型集成或 Agent 工具时	references/ai-llm-security.md

模板

使用时机	文件
开始功能或系统威胁建模时	templates/lightweight-threat-model.md
为规范或变更编写安全验收标准时	templates/security-acceptance-criteria.md
审查与安全相关的代码变更时	templates/secure-code-review-checklist.md

防护准则

• 在边界验证之前，将提示词、检索内容、工具输出、webhook、文件，以及客户端提供的身份或租户字段视为不可信内容。
• 框架、扫描、SBOM、签名、来源证明或检查清单，只能证明有限范围内的主张，不能证明软件安全。
• 不要将某项控制措施设为通用要求：身份验证协议取决于信任模型；行级安全是一种隔离机制；密钥轮换应根据事件和风险进行；控制措施需要在实际部署中验证。
• 完成的威胁模型和安全验收标准若暴露系统边界或弱点，应予以保密。使用占位符，绝不要使用真实凭证或私有部署详情。

可移植性

使用宿主环境的常规机制来创建构件、运行测试并获取批准。不要假设使用了特定供应商、云服务、身份提供商、数据库、CI 系统或部署拓扑。