STRIDE 위협 모델: "무엇이 잘못될 수 있을까?" 프레임워크

부인 방지 예시: 부호 없는 Commits

What's being fixed: preventing unaudited merges by verifying 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)

There's no signature, no required reviewer, and no way to later prove who authored this change or whether it was tampered with in transit.

// 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

Now every commit on main carries a verifiable signature, and unsigned commits are rejected at the branch level, closing the repudiation gap.

Information Disclosure Example: Secrets in Logs

What's being fixed: preventing secret leakage by avoiding direct printing of sensitive environment variables.

// 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

If this job fails or a teammate has log access, $API_KEY is now sitting in plaintext in the CI history, visible to anyone with read access to the 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 }}

The key is pulled from the CI secret store at runtime, never echoed to stdout, and most CI platforms will automatically mask it in logs even if it appears in output by accident.