将安全内建于开发流程中：威胁应对分步指南(Build Security In) - 上
在你的研发团队中，什么才构成“安全威胁”？又该如何有效地识别、分类并应对这些威胁？每个人都希望保障团队、系统和服务的安全，然而由于这个话题过于庞大且令人望而生畏，同时过往的讨论和研究成果离工程团队的日常工作依然存在结合不足的情况。本文将帮助你把安全威胁拆解为一系列可管理的步骤，从理解威胁、分类威胁，到有效地应对它们。我们从一个问题开始吧。
一、什么是威胁？
威胁的类型和严重程度往往取决于具体的上下文和视角，不同的研发团队可能得出大相径庭的结论。现实工作中存在的威胁多种多样，举几个常见的例子：
- 明文凭证存储: 密码、API 密钥或私钥被以明文形式保存在代码、配置文件甚至个人笔记中，极易被窃取和滥用。
- CI/CD ① 凭证暴露: 构建流水线的日志中输出了服务账户的访问令牌或密钥，任何有权限查看日志的人员都可能无意间获取这些敏感信息。
- 脚本误操作: 自动化脚本缺乏验证与回滚机制，一次执行就可能清空整个数据库、删除多张表或中断生产服务。
- 越权访问接口: 某个 API 缺乏严格的权限验证，用户 A 可以通过调整请求参数访问到用户 B 的数据，构成严重的数据泄露。
- 配置漂移: 不同环境下的配置未同步，导致测试环境正常但生产环境出错。典型如数据库连接字符串、缓存策略或服务依赖项配置差异。
- 第三方依赖漏洞: 系统中引入了已知存在高危漏洞的开源库，却因缺乏依赖监控机制而长期未被升级或替换，成为攻击者的可利用入口。
- 文件上传漏洞: 系统允许用户上传文件，但未对上传文件类型、大小、内容进行验证，导致恶意脚本或病毒被成功上传并执行。
- 功能开关误配: Feature Toggle 配置错误，导致半成品功能被意外上线，或关键功能被关闭，直接影响用户体验甚至引发生产事故。
- 日志泄露: 在调试过程中输出用户姓名、身份证号或访问令牌，且未在上线前清除调试代码，最终这些信息被写入生产环境的日志系统，如 AWS CloudWatch 或 SumoLogic，造成用户敏感信息暴露。
- 接口变更缺乏兼容性: API 接口更新未做向后兼容，集成方调用失败，引发连锁问题和用户投诉。
- 缺乏监控告警: 关键系统异常时，没有有效的监控和告警，导致问题迟迟未被发现，大大增加问题的影响范围和恢复成本。
- 个人账户混用: 开发人员在工作设备上登录了自己的 GitHub 或邮箱，可能导致私人数据泄露，也可能将公司代码误同步到个人账户中，造成代码泄露。
① 释义: CI/CD 是现代软件开发中的一种自动化实践，分别代表CI( Continuous Integration，持续集成)、CD(Continuous Delivery/Continuous Deployment，持续交付 / 持续部署) CI/CD 的目标是通过自动化流程，让代码从开发到上线更快、更稳定、更安全，缩短反馈环。
这些威胁虽看似细微，实则暗藏风险。一些源自日常操作的疏忽，一些源自架构设计的短板，另一些则隐藏在自动化和依赖管理中，像温水煮青蛙一样，直到爆发才引起注意。
而当这些威胁交织在一起、毫无规律地出现在工作流中时，我们很难聚焦重点，也难以知道该从哪一类威胁入手。因此，在接下来的部分，我们将介绍一个实用的方法：“威胁四象限分类法”。通过它，我们可以将这些威胁划分为几个关键维度，更有效地归类并应对。
二、威胁四象限分类法：聚焦安全威胁
上节中我们看到了几种类型的威胁，它们来源不同、形态各异，既包括日常开发操作中的疏忽，也包括系统层面的设计缺陷。面对这么多威胁，如果不加分类处理，容易陷入“到处是火却不知道先灭哪一个” 的困境。为更高效地识别、沟通及应对各类威胁，本文引入一种实用方法 —— 威胁四象限分类法（Threat Quadrant Classification），将常见威胁根据其来源与影响对象：开发人员 vs 系统开发，安全威胁 vs 非安全威胁 这两个维度进行划分，帮助团队快速聚焦安全威胁，划分规则如下：
- 开发人员相关的非安全威胁：这些问题虽然不涉及安全，但容易对交付质量、系统稳定性产生负面影响。例如配置不一致、测试脚本误删生产数据等，虽不属于安全威胁，但常常是生产事故的“根源”。
- 系统开发相关的非安全威胁：这类问题多发生在系统层级，虽不涉及安全，通常也不带来数据泄露的风险，但容易对交付质量、系统稳定性产生负面影响。如接口兼容性问题、缺乏监控导致系统异常难以被及时发现，或功能开关未正确配置导致系统出现意外行为等问题。
- 开发人员相关的安全威胁：这类威胁源于开发团队的日常行为、流程习惯或安全意识不足。比如凭证管理不当、将敏感信息暴露在日志中，或者混用个人与工作账户等。虽然这些问题看似微小，但在实际中非常常见，且极易引发严重的信息安全事故。
- 系统开发相关的安全威胁：这类威胁存在于系统架构设计、API 实现、文件管理策略或依赖管理中。通常是系统本身存在缺陷，攻击者可能利用这些漏洞越权访问、注入恶意代码或发动攻击等。
根据定义，我们可以将上一节中的不同威胁归类到四个象限中： 
威胁四象限
通过这种分类方式，我们可以清晰地聚焦 “开发人员相关的安全威胁” 与 “系统开发相关的安全威胁” 这两个象限中的问题，并在下一节深入探讨如何有效地识别和处理这些安全威胁，建立一套 “把安全内建进去” 的工作方式。
三、应对策略：针对性解决
通过前文的威胁示例与四象限分类，我们可以清晰地看出，不是每个威胁都需要以安全威胁来对待，也不是每张开发故事卡都涉及安全威胁。正因如此，我们才更需要一个系统性的方法来帮助团队识别重要的安全威胁，并采取合适的应对措施。
为了聚焦重点，我们将主要应对的范围聚焦在两个象限：
- 开发人员相关的安全威胁
- 系统开发相关的安全威胁
这两个象限所对应的威胁，往往具备以下两个特征：
- 对数据、系统或用户的安全有直接影响；
- 如果被攻击者利用，将可能导致数据泄露、服务中断或合规风险。
3.1 开发人员相关的安全威胁应对策略
对开发者面向的安全威胁，建议从流程规范、工具支持和文化建设三个方面入手，通过清晰可执行的措施，将安全理念融入日常开发工作中。
1. 建立开发安全基线
- 制定团队统一的安全开发准则：包括凭证管理、日志脱敏、个人账户隔离等要求，形成书面化规范，并进行版本管理。
- 将安全准则纳入 Onboarding 流程：确保新员工在入职阶段了解并签署安全使用协议，避免因认知差异造成安全疏漏。
2. 强化凭证与敏感信息管理
- 使用密码管理工具（如 1Password、Bitwarden）集中管理个人凭证，禁止在本地文件或纸质笔记中保存明文密码。
- 配置 IDE 插件或 Git hook脚本，在提交代码前自动检测凭证信息，阻止意外提交敏感数据。
- 为常见服务配置临时凭证并遵从最小权限访问控制（Least Privilege），降低凭证泄漏带来的潜在损害。
3. 规范日志使用和信息输出
- 设置合理的默认日志级别（如Info），并且确保任何情况下都不应该将用户邮箱、Token、手机号等敏感信息完整打印到日志中。
- 开发环境中启用日志脱敏中间件，在控制台或本地日志中自动屏蔽敏感字段。
- 定期运行日志扫描任务，识别并清理历史日志中的敏感数据，防止遗留风险。
4. 清理与隔离个人账户信息
- 在工作设备上禁用个人账号自动登录（如浏览器、GitHub、Slack），统一使用工作账号登录。
- 使用容器（如 Docker Desktop）或虚拟机隔离实验环境与生产环境，防止混用导致配置泄漏。
5. 工具与流程自动化
- 在 CI/CD 流程中集成凭证扫描和安全 Linter 工具（如 TruffleHog、Gitleaks），将安全检测左移到开发阶段。
- 设置强制分支保护与 Pull Request 检查，在合并前引导审查潜在的安全问题。
6. 安全意识融入日常
- 每月开展一次轻量化的“开发者安全午餐会”或案例分享，传播真实场景中的安全事件与应对措施。
- 通过安全问答、知识卡片等方式持续性提醒安全细节，将安全思维潜移默化地嵌入工作流程中。
为了降低认知负载并提升执行一致性，我们建议每个团队维护一个 “安全 Do’s & Don’ts 清单”，在新成员入职和项目启动阶段强调执行。如下面的例子： 
安全 Do’s & Don’ts 清单
小结
通过应用上述应对策略，我们发现在众多团队中安全内建效果得到了可喜的提升。在团队数量和成员规模扩大超过100%的背景下，得益于团队整体保有的安全意识，由于开发人员行为而导致的安全事故数量反而呈现下降趋势，并在截稿时保持年度 0 安全事故的成果。
到这里咱们讨论了在研发团队中如何识别、分类并应对安全威胁。引入了 “威胁四象限分类法” 并深入讨论了开发人员相关的安全威胁，下篇，咱们将继续分析如何应对系统开发相关的安全威胁。