将安全内建于开发流程中：威胁应对分步指南 (Build Security In) - 下
上篇中，咱们解释了什么是威胁，列举了常见的安全威胁，引入了“威胁四象限分类法”，将威胁分为开发人员相关和系统开发相关。针对性的讨论了开发人员相关的安全威胁，强调了通过工具与流程自动化以及将安全意识融入日常工作的重要性。本篇咱们将继续讨论如何应对系统开发相关的安全威胁。
三、应对策略：针对性解决
3.2 系统开发相关的安全威胁应对策略
软件系统开发过程中相关的安全威胁多源于系统设计、架构实现或基础设施层面的不当决策，这类问题一旦产生，影响范围广，回滚成本高。应对这类威胁的策略需围绕 设计前置、评审规范、持续建模与自动化防御四个方面进行。
3.2.1 风险识别前移至故事卡片级别
- 在 Backlog Grooming 阶段加入“安全影响评估”环节：安全冠军或资深开发协助识别本卡片可能带来的系统性安全风险。
- 标记具有“外部影响面”的卡片为“需安全建模”，例如：
- a,新增或暴露 API 接口
- b.调整权限控制逻辑
- c.改变日志记录内容结构
- d.修改云资源（如开启公网访问、调整安全组规则）
- e.引入新库或第三方服务
3.2.2 引入轻量级威胁建模流程
- 采用卡片级威胁建模清单（可基于 STRIDE、LINDDUN 等模型简化），如：
- a.是否可能造成越权访问？
- b.是否引入了未受控的外部输入？
- c.是否改变了攻击面或暴露新入口？
- 风险明确的卡片需填写对应的 Security Acceptance Criteria (SecAC)，并作为“完成标准”之一纳入开发流程。
3.2.3 标准化的 SecAC ① 使用流程
- 建立团队共享的 SecAC 模板库，涵盖常见情境（如日志脱敏、WAF 配置、API 限流、安全头设置等）以便快速复用。
- 将 SecAC 明确记录在 Jira 的 Checklist 或 Acceptance Criteria 中，避免仅口头讨论，确保开发与测试一致遵循。
- 通过 PR 审查机制验证 SecAC 实施情况，提升责任闭环。
① 释义: SecAC 安全验收标准（Security Acceptance Criteria）是指在软件开发过程中的用户故事（User Story）、技术任务或功能需求中，明确定义的、可验证的安全性标准，用于确保交付的系统功能在满足业务目标的同时，也符合相应的安全要求。 它是“验收标准”的一个子集，专注于安全方面的需求，用于帮助团队系统性地防范潜在的安全风险。
3.2.4 加强架构与平台安全对齐
- 建立与平台团队的 “安全设计对齐机制”：如变更云架构、API 网关策略、微服务边界等，应通过架构审查会获取平台安全建议。
- 使用基础设施即代码（IaC）模板规范安全配置：例如默认启用 WAF、防止 S3 公共读、限制出入站流量。
- 在部署流水线中自动扫描配置与依赖漏洞（如 Dependabot, Checkov、Snyk、AWS Inspector），降低人为疏漏概率。
3.2.5 数据与外部接口安全
- 引入数据分类机制，区别处理敏感数据与公开数据，控制日志记录和数据共享。
- 为对外接口统一配置流量限制、认证机制和异常告警阈值，防止 API 滥用或被攻击。
3.2.6 安全持续演进与知识回流
- 每个发布周期定期回顾 “系统变更带来的潜在安全影响”，整理为知识库条目，避免重复踩坑。
- 推动团队参与内部 “系统安全诊断练习” 或 “设计回顾”，形成安全设计文化。
四、利用 Security AC 应对系统安全威胁
在我们的实践中发现应对系统开发相关安全威胁（System Facing Security Threats），最大的挑战往往在于：这类威胁隐藏在系统行为、架构设计、配置策略或第三方集成等技术细节中，容易被忽略，且一旦发生，往往影响范围广、损害严重。传统的风险控制手段，如开发流程控制、威胁建模、渗透测试或个人经验很难系统性地识别和防范这些威胁，或者存在反馈不及时、成本高昂等不足。
在敏捷项目管理流行的今天，应对系统安全威胁也可以从敏捷中获取思路，采用轻量级、快速反馈的机制。安全验收标准（SecAC） 正是一种结构化的手段，能够将安全要求明确地嵌入功能需求和交付流程中。我们已经在多个客户项目中长期应用SecAC作为安全内建的核心手段，得到了较为可喜的成果。尤其是在设计和开发阶段，通过 SecAC 明确 “系统应该如何防止 XX 类型的威胁”，团队可以：
- 将安全风险的识别 “左移”，减少后期返工；
- 促进团队在评审、测试、发布环节中有一致的安全判断依据；
- 将抽象的安全关注点具象化为具体、可验证的交付标准，降低成员的认知负担；
- 通过标准化和文档化，提升团队整体安全意识和知识积累。
SecAC 不仅是规范交付质量的手段，更是团队在应对系统安全风险时建立 “工程化防线” 的关键机制。
SecAC 的使用情况与挑战
我们抽取了20来个团队2024年一整年的 SecAC 数据并对其进行了调研，调研结果表明，尽管 70% 的团队已开始使用 SecAC，但大多数团队仅将其应用于少部分卡片 (20%左右)。应用率低是 SecAC 执行中的一大瓶颈。究其原因，受访团队表示挑战主要在于：容易忘记加入SecAC、验收标准描述模糊、忽视小任务等问题。
此外，团队普遍希望获得更多的培训，学习SecAC的成功案例，及得到更易用的工具支持。
五、如何进一步提升 SecAC 使用效率
基于一线团队对应用SecAC的反馈，为了进一步提升 SecAC 的应用效率，我们提出以下几种参考策略：
5.1 简化与自动化 SecAC 的编写
当前，SecAC 的使用仍然依赖开发人员在每个任务卡上手动添加安全准则，虽然这有助于强化安全意识，但由于繁琐的流程与不一致的模板，很多团队可能忽略或未能有效执行。为了改变这一现状，我们可以通过以下方法来提升 SecAC 的效率：
- 简化模板：制定统一且简洁的 SecAC 模板，减少不必要的细节，明确标注哪些卡片需要添加 SecAC，以及如何快速生成合适的安全准则。
- 智能提示：在任务卡的创建流程中，根据已经总结的模版或者知识库自动化的添加安全检查和建议。如果该卡片涉及到任何潜在的安全威胁，系统能够提示并生成相应的安全需求，从而降低人工判断的负担。
- AI辅助生成SecAC：随着人工智能技术的发展，AI 在提升 SecAC 编写效率方面具备巨大的潜力。例如，Thoughtworks 推出的 AI 工具 Haiven 可以根据项目的特点和卡片的内容，自动识别出其中的安全风险，并生成相应的 SecAC。这不仅大大提高了开发团队在日常开发中的安全意识，也减少了人力投入，确保了更多的卡片能够达成安全要求。
5.2 整合团队反馈与案例
此外，及时获取团队的反馈也是提高 SecAC 使用效率的一个重要方面。团队成员在实践中不断遇到不同的挑战和需求，通过定期收集反馈并根据实际案例进行改进，能够帮助团队优化 SecAC 的适用性。可以通过以下方式增强反馈机制：
- 安全案例库：建立一个共享的安全案例库，其中包括以往项目中成功应用 SecAC 的实例，以及失败案例的教训。这能够帮助团队成员更好地理解如何在具体的开发卡片中有效应用 SecAC。
- 定期培训与回顾：定期为团队举办关于 SecAC 的培训与回顾会议，分享最佳实践，讨论团队在实施过程中的困惑和难点，从而不断完善整个流程。
5.3 鼓励文化转变：安全作为每个人的责任
除了技术层面的改进，文化层面的转变同样至关重要。安全不应仅仅由安全专家负责，而应当是每个开发者和团队成员的共同责任。通过以下方式，可以推动团队文化的转变，进一步提升 SecAC 的有效性：
- 安全冠军（Security Champion） 的引导：团队的安全冠军可以通过定期检查 SecAC 的应用情况，强调其在项目中的重要性，并对未能执行的团队成员进行指导与帮助。
- 激励机制：对那些积极执行 SecAC、主动识别安全风险并提供改进建议的团队成员，给予奖励或表彰，激励团队文化的变革。
通过文化与技术手段的双管齐下，SecAC 的应用将会变得更加高效、更加普及，最终使得整个开发过程中的安全性得到了进一步的提升。
小结
通过本文的分析，我们可以看到构建安全内建并不是一项单纯的技术工作，而是需要通过合理的威胁分类、精细的策略落实和文化引导来推动的。通过四象限分类模型和SecAC等方法，团队可以更加高效地识别和应对软件开发中的安全威胁，同时通过引入 AI 技术提高 SecAC 编写效率，确保交付物的安全能够在每个开发环节中得以保障，从而构建起一个更安全、更高效的开发环境。