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 検証可能な署名があり、署名がない commitはブランチレベルで拒否され、否認ギャップが解消されます。

情報漏洩の例：ログに含まれる秘密情報

修正内容： 機密性の高い環境変数を直接出力することを避けることで、機密情報の漏洩を防ぐ。

// 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プラットフォームでは、たとえ誤って出力に表示されたとしても、ログ内で自動的にマスクされます。