STRIDE 威胁模型：“可能出现什么问题？”框架

否认示例：未签名 Commits

正在修复的问题： 通过验证防止未经审计的合并 commit 签名。

// Anyone can commit and push, no verification of who or with what identity
 git commit -m "update deploy config"
 git push origin main
 
 // No branch protection: unsigned, unverified commits merge freely
 // .github/settings.yml (missing or absent)

没有签名，不需要审核人，也无法事后证明是谁做的更改，或者更改过程中是否被篡改过。

// Commit signing enabled and enforced locally
 git config commit.gpgsign true
 git commit -S -m "update deploy config"
 git push origin main
 
 // Branch protection requires signed commits before merge
 // .github/settings.yml
 branches:
   - name: main
     protection:
       required_signatures: true
       required_pull_request_reviews:
         required_approving_review_count: 1

现在每个 commit on main 带有可验证的签名，以及未签名 commits 在分支级别被拒绝，从而弥合了拒绝缺口。

信息泄露示例：日志中的秘密

正在修复的问题： 通过避免直接打印敏感环境变量来防止机密信息泄露。

// CI job prints the secret directly to logs for "debugging"
 steps:
   - name: Deploy
     run: |
       echo "Using API key: $API_KEY"
       curl -H "Authorization: Bearer $API_KEY" https://api.example.com/deploy

如果此任务失败或队友拥有日志访问权限， $API_KEY 现在它以明文形式保存在 CI 历史记录中，任何具有读取权限的人都可以看到。 pipeline.

// Secret is referenced, never printed, and CI masks it by default
 steps:
   - name: Deploy
     run: |
       curl -H "Authorization: Bearer ${{ secrets.API_KEY }}" https://api.example.com/deploy
     env:
       API_KEY: ${{ secrets.API_KEY }}

密钥在运行时从 CI 密钥存储中取出，永远不会回显到标准输出，大多数 CI 平台即使意外地出现在输出中，也会自动在日志中将其屏蔽。