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 平台即使意外地出现在输出中，也会自动在日志中将其屏蔽。