为什么开发人员应该在软件项目中使用 STRIDE 威胁模型？
如果你正在发送代码，管理 pipelines，或触摸 CI/CD 无论如何，STRIDE 威胁建模都应该成为您工具包的一部分。STRIDE 代表欺骗、篡改、否认、信息泄露、拒绝服务和特权提升，这六类安全威胁是开发人员在整个软件生命周期中必须考虑的。
由微软于 2000 世纪初创建STRIDE 威胁建模框架看似老派，但它的优势在于其永恒的简洁性：它可以帮助团队系统地思考：“这里可能出什么问题？” 尽管软件交付已经发生了巨大的变化，但随着云原生架构、容器化和 CI/CD pipelines，STRIDE 仍然高度相关。它完美契合了 现代 DevSecOps 通过提供一种实用的、开发人员友好的方法来主动识别和解决安全风险。
这并非专为审计或事后分析而设的理论模型。STRIDE 威胁模型能帮您在攻击者之前找到薄弱环节。无论您是编写部署脚本，还是审查 pull request或连接第三方服务，STRIDE 暴露了攻击者可能利用的角度。
DevSecOps 意味着从一开始就构建安全的软件。STRIDE 不会减慢您的速度，而是通过现在检查正确的内容来减少日后的意外。持续应用 STRIDE 威胁建模框架可以增强您及早预测和解决问题的能力。
快速细分：开发人员需要了解的 STRIDE 类别
STRIDE 威胁模型将威胁分为六类。每一类都对应着软件和基础设施中常见的痛点。
S: 欺骗 身份 （伪造真实身份）风险： 未经授权的用户或服务冒充他人。例如：被入侵的 CI 运行器冒充受信任的部署者并推送不安全的更改。 CI/CD 场景：攻击者获得 CI 代理的访问权限并触发看似来自受信任团队成员的作业。
T: 篡改 数据或代码（弄乱你的东西）风险： 攻击者在不被察觉的情况下更改代码、配置或工件。例如：恶意脚本在构建过程中修改容器镜像。 CI/CD 场景：构建步骤被悄悄改变，以部署来自未经授权来源的修改后的图像。
R：否认 （没有证据证明谁做了什么）风险： 缺乏问责制或审计线索。例如：合并操作发生时，并未核实谁批准或授权。 CI/CD 场景：构建和部署运行时没有记录发起者，因此很难追踪问题。
一、信息披露（泄露秘密） 风险： 日志、构建或工件中的敏感数据泄露。例如：脚本执行失败时打印到日志中的机密信息。 CI/CD 场景：包含机密的环境变量在 pipeline 日志或错误消息。
D: 拒绝服务 （消耗你的资源）风险： 由于逻辑不合理或滥用导致进程或服务不可用。例如：无限作业循环阻塞了 CI 队列。 CI/CD 场景：配置错误 pipeline 触发过于频繁，消耗了所有可用的跑步者容量。
E: 特权提升 （获取超出允许的访问权限）风险： 用户或服务获得不该获得的权限。示例：A pipeline 作业以不应具有的生产级访问权限运行。 CI/CD 场景：由于访问控制配置错误，贡献者的作业以提升的权限执行。
DevOps 中的 STRIDE 威胁建模：快速参考表
| 类别 | DevOps风险 | 真实示例 |
|---|---|---|
| 欺骗 | 冒充用户或服务 | CI 运行器欺骗生产部署者 |
| 篡改 | 未经授权的代码或配置更改 | 部署中的恶意脚本 pipeline |
| 否认 | 没有操作日志或审计跟踪 | 合并无 commit 签名或审计跟踪 |
| 披露信息 | 日志或构建中泄露机密 | 凭证打印到 CI 日志 |
| 拒绝服务 | 资源耗尽或工作流程中断 | 递归 pipeline 工作让跑步者不堪重负 |
| 特权提升 | 用户或进程的访问权限过多 | 开发 pipeline 具有产品访问权限的令牌 |
将 STRIDE 应用于 DevOps 工作流
DevOps 中的欺骗 CI/CD Pipelines
未经授权的进程冒充受信任的 pipeline 阶段。代码库：被盗用的贡献者账户会以合法用户名推送恶意代码。依赖项：恶意软件包使用与热门库类似的名称（域名抢注）来伪装成可信的库。
DevOps 中的篡改 CI/CD Pipelines
修改后的部署脚本会交换容器或插入恶意命令。存储库：强制推送 commit绕过代码审查，注入后门。依赖项：库的恶意更新会引入隐藏功能。
DevOps 中的否认 CI/CD Pipelines
部署触发时无需记录发起者。Repos：缺乏 commit 签名使得无法验证变更的来源。依赖项：软件包变更在提取时无需任何可验证的变更日志或签名。
DevOps 中的信息披露 CI/CD Pipelines
由于冗长的调试，日志输出中泄露的机密信息。存储库：意外泄露了 .env 文件或配置机密信息 commit已添加到源代码管理中。依赖项：权限配置错误的软件包会暴露敏感文件。
DevOps 中的拒绝服务 CI/CD Pipelines
由于无限触发器循环导致运行器过载。代码库：包含超大文件或复杂构建触发器的恶意贡献。依赖项：递归或优化不佳的库会消耗过多的系统资源。
DevOps 中的权限提升 CI/CD Pipelines
共享令牌允许非管理员作业执行管理任务。存储库：Git hooks 或自动化脚本以不必要的权限运行。依赖项：第三方库在构建期间以 root 权限执行安装脚本。
内联示例：应用 STRIDE 之前和之后
否认示例：未签名 Commit正在修复的问题：通过验证来防止未经审计的合并 commit 签名。
STRIDE 意识培训之前
# GitHub Actions - Merge workflow
jobs:
merge:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
STRIDE 意识培训后：
# GitHub Actions - Merge workflow with commit verification
jobs:
merge:
runs-on: ubuntu-latest
steps:
- name: Checkout with full history
uses: actions/checkout@v2
with:
fetch-depth: 0
- name: Verify commit signature
run: git verify-commit HEAD
信息泄露示例：日志中的秘密 正在修复的问题：避免直接打印敏感环境变量，防止秘密泄露。
STRIDE 意识培训之前：
# Pipeline step with possible secret leakage
steps:
- name: Run script
run: echo $DATABASE_PASSWORD
STRIDE 意识培训后：
# Pipeline step with secret masking
steps:
- name: Run script safely
env:
DATABASE_PASSWORD: ${{ secrets.DATABASE_PASSWORD }}
run: echo "[MASKED]"
开发人员如何在没有安全背景的情况下应用 STRIDE
如果你在 DevSecOps 工作， 威胁建模 应该成为第二天性。通过在审查和自动化设置过程中使用 STRIDE 威胁模型作为指导，您可以在问题影响生产之前进行预测。
您无需成为安全专家。只需在日常工作流程中提出基于 STRIDE 的问题即可：
代码审查期间：
- 有人可以在这里伪造身份吗？
- 这可以被篡改吗？
中 CI/CD 综述：
- 秘密是否在任何地方被暴露？
- 每一个动作都是可追溯的吗？
在依赖关系分析期间：
- 我们获取的信息是否来自经过验证的来源？
- 这种依赖关系可以提升其权限吗？
然后实现你能实现的自动化：
- 使用签名 commits
- 实施工件签名
- 设置机密扫描
- 监视依赖项更新
这些小步骤无需额外开销即可实现 STRIDE 威胁模型的运作。
在持续应用 STRIDE 威胁建模之前，了解它何时何地适合您的工作流程会有所帮助。
将 STRIDE 集成到威胁建模流程中
STRIDE 作为一种轻量级、可重复的视角，能够自然地融入开发生命周期，帮助及早发现潜在的安全威胁。在以下关键阶段持续应用 STRIDE 最为有效：
- 代码审查期间：询问诸如“这会被欺骗或篡改吗？”或“此更改是否有审计跟踪？”之类的问题。
- 配置时 CI/CD Pipelines：评估是否 秘密被揭露，如果作业可追踪，或者权限范围太广。
- In 依赖管理：检查第三方软件包是否经过验证、签名，并且没有危险的安装脚本或过度访问。
- 规划新功能或服务时，使用 STRIDE 威胁建模框架作为清单来集思广益，找出每个威胁类别可能出现的问题。
这使得 STRIDE 威胁建模成为您安全工作中一个实用且可操作的部分，而不是一个重量级的过程，而是一种嵌入到您的日常开发和 DevOps 工作流程中的思维方式。
STRIDE 在实际使用案例中的应用 Xygeni 不仅仅监控，它还能采取行动。
Xygeni 的 角色。以下是它在实际中如何捕获和阻止威胁 pipelines:
- 欺骗已被阻止：Xygeni 标记了 pipeline 某个作业使用过期凭证冒充管理员身份。该构建任务已暂停，凭证也已轮换。
- 防止篡改：Xygeni 检测到部署 YAML 文件突然更改，并插入了未经授权的脚本。它回滚了 commit 并通知了团队。
- 秘密受到保护：在一次例行扫描中，Xygeni 发现 CI 日志中存在一个因测试失败而暴露的密码。它立即阻止了日志访问，并删除了敏感行。
- 访问受限制: 贡献者的 pipeline 正在以完全管理员权限执行。Xygeni 标记了此问题，并自动将令牌范围调整到正确的环境。
- 强制审计追踪：Xygeni 强制分支保护并要求签名 commit在所有 PR 中。之前未签名的合并已被阻止，直至更正。
- 避免 DoS 攻击：错误配置的 cron 触发器开始启动数百个 pipeline 工作。Xygeni 限制了执行并立即向 DevOps 团队发出警报。
这些只是 Xygeni 将 STRIDE 威胁建模框架付诸实践的几种方式，可以在实际问题影响生产之前检测、阻止和修复它们。
结论：STRIDE 让威胁建模对开发人员切实可行
STRIDE 威胁建模框架为开发者提供了一个清晰、可操作的视角，帮助他们及早发现风险。无需过度思考，只需针对代码、代码库、 pipeline或依赖关系。
STRIDE 威胁建模可帮助您在安全漏洞上线前修复它们。Xygeni 等工具可帮助您自动化修复，避免不必要的麻烦。
将 STRIDE 威胁模型融入您编写、审查和交付代码的方式中。持续的 STRIDE 威胁建模有助于确保您的 pipeline即使规模扩大和发展，也是安全的。
