🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🧭 धडा 15 — Delivery line चे threat modelling: प्रत्येक टप्प्यावर एक रक्षक

📍 तुम्ही इथे आहात: 16 पैकी धडा 15 · मागील: lesson-14-artifacts · पुढील: lesson-16-ai-security

📦 या ब्रँचमध्ये काय आहे

धडे 01–14, आणि त्यांना जोडणारी सवय: threat modelling. तुम्ही delivery line वरून चालता — laptop → git → dependencies → CI build → container image → registry → deployment — आणि प्रत्येक टप्प्यावर सहा STRIDE प्रश्न विचारता. प्रत्येक टप्प्याला नाव दिलेला एक रक्षक मिळतो. मग ती घटना जी प्रत्येकाला कधी ना कधी भेटते: public commit मध्ये secret leak होते, आणि पहिल्या पायऱ्यांचा क्रम (आधी rotate).

sec/supply.py — stride_pipeline() (7 टप्पे, धोका → रक्षक) आणि leak_response() (6 पायऱ्या)
sec/cloud.py — धडा 07 मधले find_secrets(), इथे pre-commit रक्षक म्हणून वापरलेले
sec/demo.py — python3 sec/demo.py pipeline
sec/test_sec.py — धडे 07, 13 आणि 14 च्या तपासण्या इथे वापरलेल्या रक्षकांना cover करतात

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

स्वयंपाकी काम सुरू करतो तेव्हापासून डबा वर्गात पोहोचेपर्यंत दीपिका एका डब्याच्या मागे जाते, आणि प्रत्येक पायरीवर ती विचारते: "इथे काय चुकू शकते, आणि ते कोण थांबवते?"

🧑‍🍳 स्वयंपाक्याचे स्वतःचे स्वयंपाकघर — कोणीतरी स्वयंपाक्याची चावी चोरतो. → चावीला बोटाचा ठसाही लागतो (MFA, hardware keys).
📖 पाककृतींचे पुस्तक — कोणी एक पान फाडून नवे लिहितो. → बदलांवर दुसऱ्या स्वयंपाक्याची सही लागते (branch protection, reviews).
🥫 साहित्य — एक खराब बरणी. → परत मागवण्याची यादी आणि सील केलेल्या बरण्या (धडा 13).
🏗️ मोठे स्वयंपाकघर — स्वयंपाकघरातला अनोळखी माणूस मीठ बदलतो. → प्रत्येक batch साठी स्वच्छ, कुलूपबंद स्वयंपाकघर, आणि कुठेही पडलेली master चावी नाही (isolated CI, OIDC).
📦 डबा — त्यात काय आहे ते कोणालाच माहीत नाही. → सामानाची यादी (SBOM, धडा 14).
🚚 गाडी — वाटेत डबा बदलला जातो. → सील (signature, धडा 14).
🚪 वर्गाचे दार — सील नसलेला डबा येतो. → सील नाही, जेवण नाही (admission).

मग एके दिवशी ऐश्वर्याला शाळेच्या वर्तमानपत्रात स्वयंपाकघराच्या चावीचा फोटो दिसतो. आधी काय? "वर्तमानपत्र परत घ्या" नाही. कुलूप बदला, आत्ताच. मग कोण आत आले ते पाहा, मग फोटो काढून टाका, मग हे कसे घडले ते दुरुस्त करा.

🗺️ आकृती

flowchart LR
    l["💻 laptop<br/>MFA · hardware keys"] --> g["📖 git<br/>branch protection · secret scanning"]
    g --> d["🥫 dependencies<br/>lockfiles · audit"]
    d --> b["🏗️ CI build<br/>OIDC · isolated runners"]
    b --> i["📦 image<br/>minimal base · SBOM"]
    i --> r["🗄️ registry<br/>signed digests"]
    r --> k["☸️ deploy<br/>admission checks signature + provenance"]
    leak["🚨 secret leaked<br/>1 rotate · 2 find uses · 3 purge history<br/>4 contain · 5 fix cause · 6 postmortem"]

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/security/lesson-diagrams.html#l15

❓ काय

Threat model — चार प्रश्नांचे लिखित उत्तर (Adam Shostack ची आवृत्ती): आपण काय बनवत आहोत? काय चुकू शकते? त्याबद्दल आपण काय करणार? आपण चांगले काम केले का? हे team सोबत, system च्या आकृतीवर केले जाते, आणि अद्ययावत ठेवले जाते.

STRIDE — "काय चुकू शकते" चे सहा प्रकार, प्रत्येक अक्षरासाठी एक, प्रत्येक एखाद्या security गुणधर्माच्या विरुद्ध:

अक्षर	धोका	तो कोणता गुणधर्म तोडतो	Delivery-line उदाहरण
S	Spoofing	authentication	चोरलेला CI token "pipeline" म्हणून push करतो
T	Tampering	integrity	registry मध्ये बदललेली image
R	Repudiation	non-repudiation	force-push मुळे कोणी काय बदलले ते पुसले जाते
I	Information disclosure	confidentiality	CI log मध्ये print झालेले secret
D	Denial of service	availability	खराब build ने भरलेला runner
E	Elevation of privilege	authorization	CI चा cloud role IAM बदलू शकतो

Trust boundary — अशी रेषा जिथे data किंवा नियंत्रण एकमेकांवर वेगवेगळ्या प्रमाणात विश्वास ठेवणाऱ्या पक्षांमध्ये जाते (fork चा pull request → तुमचा CI; CI → तुमचे AWS account). बहुतेक धोके याच रेषांवर असतात.
Delivery line वरचे रक्षक:
- laptop — hardware keys सह MFA, अल्पायुषी credentials, disk encryption;
- git — branch protection किंवा rulesets (reviews, आवश्यक checks, force-push नाही), signed commits, push protection सह secret scanning;
- dependencies — धडा 13;
- CI — साठवलेल्या keys ऐवजी cloud कडे OIDC, किमान-अधिकार permissions:, commit SHA ला pin केलेले actions, forks मधून आलेल्या workflows ना secrets नाहीत, isolated runners;
- image — minimal base, scan, SBOM (धडा 14);
- registry — digest ने sign करा, push कोण करू शकतो ते मर्यादित करा;
- deploy — admission signature आणि provenance तपासते (धडे 12 आणि 14).
Secret leak प्रतिसाद — क्रम महत्त्वाचा आहे:
1. आधी secret revoke / rotate करा — मिनिटांत, दिवसांत नाही. Automated scanners push झाल्यानंतर काही मिनिटांतच public keys शोधतात;
2. ते leak झाल्याच्या वेळेपासून त्याचा प्रत्येक वापर शोधा (CloudTrail, access logs);
3. ते code आणि history मधून काढा — पण forks, clones आणि caches कडे ते आधीच आहे असे गृहीत धरा; काढून टाकणे म्हणजे साफसफाई, उपाय नाही;
4. त्याने काय केले गेले ते शोधा, आणि रोखा (contain) (त्याने तयार केलेले काहीही काढा);
5. कारण दुरुस्त करा — pre-commit आणि CI मध्ये secret scanning, अल्पायुषी credentials म्हणजे leak होण्यासारखे दीर्घायुषी काहीच उरत नाही;
6. दोषारोपविरहित postmortem लिहा.

🤔 का

कारण तुम्ही काय पाठवता तेच हल्लेखोर बदलू शकत असेल, तर त्यांना तुमचे app फोडायची गरजच नाही. विषारी dependency, चोरलेला CI token किंवा बदललेली image production च्या पूर्ण विश्वासासह production मध्ये पोहोचते. धडे 07–14 ने प्रत्येक टप्प्याला एक tool दिले; threat model खात्री करतो की कोणताही टप्पा विसरला जात नाही आणि प्रत्येक tool चालू आहे. आणि leak ही शर्यत असते: जिवंत key जितका प्रत्येक मिनिट public असते, तितका प्रत्येक मिनिट कोणीतरी ती वापरू शकतो — म्हणून पहिली पायरी नेहमी ती निरुपयोगी करणे असते, लपवणे नाही.

🔧 कसे (या repo मध्ये)

sec/supply.py मध्ये, stride_pipeline() सात टप्पे (stage, "threats → guards") असे परत देते, आणि leak_response() सहा पायऱ्या क्रमाने परत देते. sec/demo.py मधले pipeline() दोन्ही print करते.

Snippet प्रत्येक टप्प्यासाठी STRIDE अक्षरे जोडतो (यादीतल्या धोक्यांचे आपले स्वतःचे वाचन), आणि धडा 07 चे find_secrets() एका commit वर pre-commit रक्षक म्हणून चालवतो ज्यात एक key आणि database URL मध्ये एक password आहे — दोन्ही बनावट.

🧪 करून पाहा

python3 sec/demo.py pipeline
python3 - <<'EOF'
import sys; sys.path.insert(0, "sec"); from supply import stride_pipeline, leak_response; from cloud import find_secrets
STRIDE = {"developer laptop": "S E", "git": "T R I", "dependencies": "T", "build (CI)": "S T I E",
          "container image": "T I", "registry": "T", "deployment": "T E"}
for stage, line in stride_pipeline():
    print(f"{stage:<17} {STRIDE[stage]:<8} guard: {line.split(' → ')[1]}")
commit = {"deploy.sh": "export AWS_KEY=AKIAEXAMPLE0123456789", "README.md": "run make deploy",
          "ci.yml": "db: postgres://app:Winter2026pw@db.school.example/grades"}
found = find_secrets(commit)
print(f"pre-commit scan of {len(commit)} files → {found}")
print("→ commit blocked" if found else "→ commit allowed")
print("if a secret gets past the scan, step 1 is:", leak_response()[0])
EOF
python3 sec/test_sec.py

✅ तपासा — तुम्हाला काय दिसायला हवे

pipeline हे print करते:

═══ pipeline ═══
── STRIDE along the delivery line, one guard per stage:
   developer laptop   stolen token, malware → hardware keys, MFA, short-lived credentials
   git                force-push, secret committed → branch protection, reviews, secret scanning
   dependencies       malicious or vulnerable package → lockfiles, audit, allow-list, pinned versions
   build (CI)         poisoned runner, stolen CI secret → OIDC to the cloud, isolated runners, least privilege
   container image    vulnerable base, unknown content → minimal base, scan, SBOM
   registry           image swapped → sign images, verify digests on deploy
   deployment         unsigned or unreviewed artifact → admission policy that checks signature and provenance
── a secret leaked in a public commit — in this order:
   1. revoke / rotate the secret first (minutes, not days)
   2. find every place it was used (logs, CloudTrail)
   3. remove it from the code AND the git history; assume forks and caches already have it
   4. look for what the attacker did with it; contain
   5. fix the cause: secret scanning in pre-commit and CI, short-lived credentials
   6. write the blameless postmortem

✅ done — every door checked

तुमचा snippet हे print करतो:

developer laptop  S E      guard: hardware keys, MFA, short-lived credentials
git               T R I    guard: branch protection, reviews, secret scanning
dependencies      T        guard: lockfiles, audit, allow-list, pinned versions
build (CI)        S T I E  guard: OIDC to the cloud, isolated runners, least privilege
container image   T I      guard: minimal base, scan, SBOM
registry          T        guard: sign images, verify digests on deploy
deployment        T E      guard: admission policy that checks signature and provenance
pre-commit scan of 3 files → [('deploy.sh', 'AWS access key id'), ('ci.yml', 'password in a URL')]
→ commit blocked
if a secret gets past the scan, step 1 is: revoke / rotate the secret first (minutes, not days)

Tests शेवटी 16/16 passed दाखवतात. धडा 15 ची स्वतःची तपासणी नाही: त्याचे रक्षक म्हणजे धडे 07 (find_secrets), 13 आणि 14 च्या तपासण्या.

🏁 तुम्ही आत्ताच काय सिद्ध केले

T (tampering) प्रत्येक टप्प्यावर दिसतो — delivery line ही सगळ्यात आधी अशी जागा आहे जिथे वाटेत गोष्टी बदलल्या जाऊ शकतात, म्हणूनच signatures आणि digests (धडा 14) इतके महत्त्वाचे आहेत. CI कडे सर्वाधिक अक्षरे आहेत: त्याच्याकडे credentials असतात, तो अनेक ठिकाणचा code चालवतो आणि production पर्यंत पोहोचू शकतो. आणि scanner ने दोन secrets git पर्यंत पोहोचण्याआधीच थांबवली — सगळ्यात स्वस्त leak प्रतिसाद. Scan चुकला, तर यादी commit हटवण्याने नाही, तर rotation ने सुरू होते.

⚠️ नेहमीच्या चुका

commit हटवणे किंवा repo private करणे आणि काम झाले असे मानणे — key तरीही चालते
key rotate करणे पण जुनी "एक दिवस, सुरक्षिततेसाठी" active ठेवणे
audit साठी एकदा लिहिलेले आणि पुन्हा कधीच न उघडलेले threat model
permissions: write-all असलेले CI workflows आणि repository secrets मध्ये दीर्घायुषी cloud keys
fork चा code secrets सह checkout करून चालवणारे pull_request_target workflows
commit SHA ऐवजी हलत्या tag ला (@v1, @main) pin केलेले third-party actions
admins टाळू शकतात असे branch protection, अशा repo वर जिथे प्रत्येकजण admin आहे
leak होते तेव्हा CloudTrail नाही (किंवा त्यात search कसे करायचे हे माहीत असलेले कोणी नाही)

🏭 प्रत्यक्ष वापरात

खऱ्या account वर — GitHub OIDC ते AWS: workflow ला अल्पायुषी credentials मिळतात, आणि कोणतीही AWS key कुठेही साठवलेली नसते. IAM role फक्त याच repo च्या main branch वर विश्वास ठेवतो:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com" },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
        "token.actions.githubusercontent.com:sub": "repo:BaluRaut/school-app:ref:refs/heads/main"
      }
    }
  }]
}

name: deploy
on:
  push:
    branches: [main]
permissions:
  contents: read
  id-token: write
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4          # pin third-party actions to a full commit SHA
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/school-deploy
          aws-region: ap-south-1
      - run: aws sts get-caller-identity

main वर Branch protection — reviews, एक आवश्यक check, force-push नाही, deletion नाही, admins सुद्धा यात येतात:

gh api -X PUT repos/BaluRaut/school-app/branches/main/protection --input - <<'EOF'
{
  "required_status_checks": { "strict": true, "contexts": ["test", "dependency-review"] },
  "enforce_admins": true,
  "required_pull_request_reviews": { "required_approving_review_count": 1, "dismiss_stale_reviews": true },
  "restrictions": null,
  "allow_force_pushes": false,
  "allow_deletions": false
}
EOF

Push protection सह secret scanning (ओळखीच्या key format असलेला push GitHub नाकारते), आणि प्रत्येक laptop वर एक pre-commit hook:

gh api -X PATCH repos/BaluRaut/school-app \
    -f 'security_and_analysis[secret_scanning][status]=enabled' \
    -f 'security_and_analysis[secret_scanning_push_protection][status]=enabled'

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks

AWS key leak झाल्यानंतरचा पहिला तास — या क्रमाने:

# 1. make it useless — now
aws iam update-access-key --user-name ci-deploy --access-key-id AKIAEXAMPLE0123456789 --status Inactive
# 2. what did it do? (CloudTrail event history covers the last 90 days)
aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAEXAMPLE0123456789 \
    --max-results 50 --query 'Events[].{time:EventTime,name:EventName,source:EventSource}'
# 3. after the investigation — delete it, and move the job to OIDC so there is no key to replace
aws iam delete-access-key --user-name ci-deploy --access-key-id AKIAEXAMPLE0123456789
# 4. clean the history (then force-push, and ask GitHub support to clear cached views)
git filter-repo --replace-text <(echo 'AKIAEXAMPLE0123456789==>REMOVED')

🏭 Production मध्ये हे का महत्त्वाचे: test account मध्ये एका बनावट key ने दर तिमाहीत एकदा leak runbook चा सराव करा: पायरी 1 ला किती वेळ लागतो ते मोजा. रात्री 11 वाजता database password कोण rotate करू शकतो हे कोणालाच माहीत नसेल, तर हल्लेखोराआधी तुम्हाला खरी फट सापडली आहे.

⏭️ पुढे

एक खिडकी उरली आहे, आणि ती सगळ्यात नवी आहे: शाळेचा AI assistant, जो सूचना, web pages आणि upload केलेल्या files वाचतो — आणि tools वापरू शकतो. पुढे: मिळवलेला text म्हणजे data, आदेश नाहीत.

git checkout lesson-16-ai-security

🧭 Lesson 15 — Threat modelling the delivery line: a guard at every stage

📍 You are here: Lesson 15 of 16 · Previous: lesson-14-artifacts · Next: lesson-16-ai-security

📦 What's in this branch

Lessons 01–14, plus the habit that joins them: threat modelling. You walk the delivery line — laptop → git → dependencies → CI build → container image → registry → deployment — and at each stage ask the six STRIDE questions. Each stage gets a named guard. Then the incident everyone meets one day: a secret leaks in a public commit, and the order of the first steps (rotate first).

sec/supply.py — stride_pipeline() (7 stages, threat → guard) and leak_response() (6 steps)
sec/cloud.py — find_secrets() from lesson 07, used here as a pre-commit guard
sec/demo.py — python3 sec/demo.py pipeline
sec/test_sec.py — the checks of lessons 07, 13 and 14 cover the guards used here

🧒 Explain like I'm 5

Dipika follows one lunch box from the moment the cook starts until it reaches the classroom, and at every step she asks: "What could go wrong here, and who stops it?"

🧑‍🍳 The cook's own kitchen — someone steals the cook's key. → The key needs a fingerprint too (MFA, hardware keys).
📖 The recipe book — someone rips out a page and writes a new one. → Changes need a second cook's signature (branch protection, reviews).
🥫 The ingredients — a bad jar. → The recall list and sealed jars (lesson 13).
🏗️ The big kitchen — a stranger in the kitchen swaps the salt. → A clean, locked kitchen for each batch, and no master key lying around (isolated CI, OIDC).
📦 The box — nobody knows what is in it. → The packing list (SBOM, lesson 14).
🚚 The van — the box is swapped on the way. → The seal (signature, lesson 14).
🚪 The classroom door — an unsealed box arrives. → No seal, no lunch (admission).

Then one day Aishwarya sees the kitchen key photographed in the school newspaper. What first? Not "take the newspaper back". Change the lock, right now. Then look at who came in, then take the photo down, then fix how it happened.

🗺️ Diagram

flowchart LR
    l["💻 laptop<br/>MFA · hardware keys"] --> g["📖 git<br/>branch protection · secret scanning"]
    g --> d["🥫 dependencies<br/>lockfiles · audit"]
    d --> b["🏗️ CI build<br/>OIDC · isolated runners"]
    b --> i["📦 image<br/>minimal base · SBOM"]
    i --> r["🗄️ registry<br/>signed digests"]
    r --> k["☸️ deploy<br/>admission checks signature + provenance"]
    leak["🚨 secret leaked<br/>1 rotate · 2 find uses · 3 purge history<br/>4 contain · 5 fix cause · 6 postmortem"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/security/lesson-diagrams.html#l15

❓ What

Threat model — a written answer to four questions (Adam Shostack's version): What are we building? What can go wrong? What will we do about it? Did we do a good job? It is done with the team, on a drawing of the system, and kept up to date.

STRIDE — six kinds of "what can go wrong", one per letter, each the opposite of a security property:

Letter	Threat	Property it breaks	Delivery-line example
S	Spoofing	authentication	a stolen CI token pushes as "the pipeline"
T	Tampering	integrity	an image swapped in the registry
R	Repudiation	non-repudiation	a force-push erases who changed what
I	Information disclosure	confidentiality	a secret printed in a CI log
D	Denial of service	availability	a runner filled by a bad build
E	Elevation of privilege	authorization	CI's cloud role can change IAM

Trust boundary — a line where data or control passes between parties that trust each other differently (a fork's pull request → your CI; CI → your AWS account). Most threats sit on these lines.
Guards on the delivery line:
- laptop — MFA with hardware keys, short-lived credentials, disk encryption;
- git — branch protection or rulesets (reviews, required checks, no force-push), signed commits, secret scanning with push protection;
- dependencies — lesson 13;
- CI — OIDC to the cloud instead of stored keys, least-privilege permissions:, actions pinned to a commit SHA, no secrets for workflows from forks, isolated runners;
- image — minimal base, scan, SBOM (lesson 14);
- registry — sign by digest, restrict who can push;
- deploy — admission checks signature and provenance (lessons 12 and 14).
Secret leak response — the order matters:
1. revoke / rotate the secret first — minutes, not days. Automated scanners find public keys within minutes of a push;
2. find every use of it (CloudTrail, access logs) from the time it leaked;
3. remove it from the code and the history — but assume forks, clones and caches already have it; removing it is cleanup, not the fix;
4. look for what was done with it, and contain (remove anything it created);
5. fix the cause — secret scanning in pre-commit and CI, short-lived credentials so there is nothing long-lived to leak;
6. write a blameless postmortem.

🤔 Why

Because attackers do not need to break your app if they can change what you ship. A poisoned dependency, a stolen CI token or a swapped image lands in production with all of production's trust. Lessons 07–14 gave each stage a tool; the threat model makes sure no stage is forgotten and that each tool is on. And a leak is a race: every minute a live key is public is a minute someone can use it — so the first step is always to make it useless, not to hide it.

🔧 How (in this repo)

In sec/supply.py, stride_pipeline() returns the seven stages as (stage, "threats → guards"), and leak_response() returns the six steps in order. pipeline() in sec/demo.py prints both.

The snippet adds the STRIDE letters for each stage (our own reading of the threats in the list), and runs lesson 07's find_secrets() as a pre-commit guard on a commit with a key and a password in a database URL — both made up.

🧪 Try it

python3 sec/demo.py pipeline
python3 - <<'EOF'
import sys; sys.path.insert(0, "sec"); from supply import stride_pipeline, leak_response; from cloud import find_secrets
STRIDE = {"developer laptop": "S E", "git": "T R I", "dependencies": "T", "build (CI)": "S T I E",
          "container image": "T I", "registry": "T", "deployment": "T E"}
for stage, line in stride_pipeline():
    print(f"{stage:<17} {STRIDE[stage]:<8} guard: {line.split(' → ')[1]}")
commit = {"deploy.sh": "export AWS_KEY=AKIAEXAMPLE0123456789", "README.md": "run make deploy",
          "ci.yml": "db: postgres://app:Winter2026pw@db.school.example/grades"}
found = find_secrets(commit)
print(f"pre-commit scan of {len(commit)} files → {found}")
print("→ commit blocked" if found else "→ commit allowed")
print("if a secret gets past the scan, step 1 is:", leak_response()[0])
EOF
python3 sec/test_sec.py

✅ Verify — what you should see

pipeline prints:

═══ pipeline ═══
── STRIDE along the delivery line, one guard per stage:
   developer laptop   stolen token, malware → hardware keys, MFA, short-lived credentials
   git                force-push, secret committed → branch protection, reviews, secret scanning
   dependencies       malicious or vulnerable package → lockfiles, audit, allow-list, pinned versions
   build (CI)         poisoned runner, stolen CI secret → OIDC to the cloud, isolated runners, least privilege
   container image    vulnerable base, unknown content → minimal base, scan, SBOM
   registry           image swapped → sign images, verify digests on deploy
   deployment         unsigned or unreviewed artifact → admission policy that checks signature and provenance
── a secret leaked in a public commit — in this order:
   1. revoke / rotate the secret first (minutes, not days)
   2. find every place it was used (logs, CloudTrail)
   3. remove it from the code AND the git history; assume forks and caches already have it
   4. look for what the attacker did with it; contain
   5. fix the cause: secret scanning in pre-commit and CI, short-lived credentials
   6. write the blameless postmortem

✅ done — every door checked

Your snippet prints:

developer laptop  S E      guard: hardware keys, MFA, short-lived credentials
git               T R I    guard: branch protection, reviews, secret scanning
dependencies      T        guard: lockfiles, audit, allow-list, pinned versions
build (CI)        S T I E  guard: OIDC to the cloud, isolated runners, least privilege
container image   T I      guard: minimal base, scan, SBOM
registry          T        guard: sign images, verify digests on deploy
deployment        T E      guard: admission policy that checks signature and provenance
pre-commit scan of 3 files → [('deploy.sh', 'AWS access key id'), ('ci.yml', 'password in a URL')]
→ commit blocked
if a secret gets past the scan, step 1 is: revoke / rotate the secret first (minutes, not days)

The tests end with 16/16 passed. Lesson 15 has no check of its own: its guards are the checks of lessons 07 (find_secrets), 13 and 14.

🏁 What you just proved

T (tampering) appears at every stage — the delivery line is, above all, a place where things can be changed on the way, which is why signatures and digests (lesson 14) matter so much. CI carries the most letters: it holds credentials, runs code from many places and can reach production. And the scanner stopped two secrets before they ever reached git — the cheapest possible leak response. When a scan misses, the list starts with rotation, not with deleting the commit.

⚠️ Common mistakes

deleting the commit or making the repo private and calling it done — the key still works
rotating a key but leaving the old one active "for a day, for safety"
a threat model written once for an audit and never opened again
CI workflows with permissions: write-all and long-lived cloud keys in repository secrets
pull_request_target workflows that check out and run a fork's code with secrets
third-party actions pinned to a moving tag (@v1, @main) instead of a commit SHA
branch protection that admins can skip, on a repo where everyone is an admin
no CloudTrail (or no one who knows how to search it) when the leak happens

🏭 In production

On a real account — GitHub OIDC to AWS: the workflow gets short-lived credentials, and no AWS key is stored anywhere. The IAM role trusts only this repo's main branch:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com" },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
        "token.actions.githubusercontent.com:sub": "repo:BaluRaut/school-app:ref:refs/heads/main"
      }
    }
  }]
}

name: deploy
on:
  push:
    branches: [main]
permissions:
  contents: read
  id-token: write
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4          # pin third-party actions to a full commit SHA
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::111122223333:role/school-deploy
          aws-region: ap-south-1
      - run: aws sts get-caller-identity

Branch protection on main — reviews, a required check, no force-push, no deletion, admins included:

gh api -X PUT repos/BaluRaut/school-app/branches/main/protection --input - <<'EOF'
{
  "required_status_checks": { "strict": true, "contexts": ["test", "dependency-review"] },
  "enforce_admins": true,
  "required_pull_request_reviews": { "required_approving_review_count": 1, "dismiss_stale_reviews": true },
  "restrictions": null,
  "allow_force_pushes": false,
  "allow_deletions": false
}
EOF

Secret scanning with push protection (GitHub refuses a push that contains a known key format), and a pre-commit hook on every laptop:

gh api -X PATCH repos/BaluRaut/school-app \
    -f 'security_and_analysis[secret_scanning][status]=enabled' \
    -f 'security_and_analysis[secret_scanning_push_protection][status]=enabled'

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks

The first hour after an AWS key leaks — in this order:

# 1. make it useless — now
aws iam update-access-key --user-name ci-deploy --access-key-id AKIAEXAMPLE0123456789 --status Inactive
# 2. what did it do? (CloudTrail event history covers the last 90 days)
aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAEXAMPLE0123456789 \
    --max-results 50 --query 'Events[].{time:EventTime,name:EventName,source:EventSource}'
# 3. after the investigation — delete it, and move the job to OIDC so there is no key to replace
aws iam delete-access-key --user-name ci-deploy --access-key-id AKIAEXAMPLE0123456789
# 4. clean the history (then force-push, and ask GitHub support to clear cached views)
git filter-repo --replace-text <(echo 'AKIAEXAMPLE0123456789==>REMOVED')

🏭 Why this matters in production: practise the leak runbook once a quarter with a fake key in a test account: time how long step 1 takes. If nobody knows who can rotate the database password at 11 p.m., you have found the real gap before an attacker did.

⏭️ Next

One desk is left, and it is the newest: the school's AI assistant, which reads notices, web pages and uploaded files — and can use tools. Next: retrieved text is data, not orders.

git checkout lesson-16-ai-security

← Previousartifacts Next →ai security

This page is the lesson's README from the lesson-15-pipeline-threats branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.