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

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

📦 धडा 13 — Dependencies: तुमच्या app मधला इतरांचा code

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

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

धडे 01–12, आणि supply chain ची पहिली खिडकी: dependencies. आधुनिक app मधला बहुतेक code दुसऱ्या कोणीतरी लिहिलेला असतो — libraries, आणि त्यांच्या libraries. तुम्ही software composition analysis (SCA: versions ना advisories शी जुळवणे), hashes सह lockfiles, आपोआप येणारे update PRs, आणि supply chain मधल्या दोन युक्त्या — typosquatting आणि dependency confusion — आणि त्या कशा थांबवायच्या हे शिकता.

sec/supply.py — छोट्या ADVISORIES यादीविरुद्ध vulnerable(installed), आणि POPULAR विरुद्ध typosquat(name)
sec/demo.py — python3 sec/demo.py dependencies
sec/test_sec.py — check L13

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

शाळेच्या जत्रेसाठी स्वयंपाकघर सगळे काही स्वतः बनवत नाही. ते ब्रेड, जॅम आणि रस बाहेरून विकत घेते. वितरण खिडकीसाठी दीपिकाचे नियम:

📋 परत मागवलेल्या मालाची यादी. रोज सकाळी बातम्या तपासा: "batch 5.3 मधला जॅम खराब आहे — 5.4 किंवा नवा वापरा." आपला जॅम batch 5.3 चा असेल, तर तो फेकून द्या आणि नवा आणा. हेच advisories तपासणे.
🧾 नेमकी order. प्रत्येक बरणीचा नेमका brand, batch आणि सील क्रमांक लिहून ठेवा. माल आल्यावर प्रत्येक सील तपासा. वेगळा सील असलेली बरणी परत जाते — label बरोबर दिसत असले तरी. हीच hashes सह lockfile.
👀 सारखे दिसणारे brands. "Nestel" म्हणजे "Nestlé" नाही. "Reqeusts" म्हणजे "Requests" नाही. घाईतल्या स्वयंपाक्याला फसवण्यासाठी कोणीतरी सारखे दिसणारे बनवले आहे. हेच typosquatting.
🏫 आपल्या स्वतःच्या पाककृती. शाळेची स्वतःची जॅमची पाककृती आहे, तिचे नाव "school-jam". जर एखाद्या अनोळखी माणसाने public दुकानात जास्त batch क्रमांकासह "school-jam" याच नावाची बरणी विकली, तर निष्काळजी स्वयंपाकी त्याची बरणी घेऊ शकतो. म्हणून स्वयंपाकघर "school-jam" फक्त शाळेच्या स्वतःच्या कपाटातूनच घेते. हेच dependency confusion थांबवणे.
🔁 दर आठवड्याला माल भरणे. आठवड्यातून एकदा एक मदतनीस नव्या batches ची यादी आणते, आणि स्वयंपाकी स्वीकारण्याआधी चव घेतो (आपोआप update PRs, CI मध्ये tested).

🗺️ आकृती

flowchart LR
    req["📄 requirements / package.json"] --> lock["🧾 lockfile<br/>exact versions + sha256 hashes"]
    lock --> audit{"📋 audit vs advisories<br/>pip-audit · npm audit · Dependabot"}
    audit -->|"requests 2.28.1 → ≥ 2.31.0<br/>pyyaml 5.3.1 → ≥ 5.4"| fix["🔁 update PR + tests"]
    name{"👀 new package name"} -->|"reqeusts ≈ requests"| stop["⛔ typosquat: review"]
    idx["🏫 one index / proxy<br/>internal names from internal only"] --> lock

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

❓ काय

Direct आणि transitive dependencies — तुम्ही यादीत लिहिलेली packages, आणि त्यांना लागणारी packages. छोट्या web app मध्ये अनेकदा काही direct dependencies आणि त्याहून कितीतरी जास्त transitive असतात. त्यांपैकी कोणत्याही एकातली समस्या म्हणजे तुमच्या app मधली समस्या.
Advisory — एखाद्या package च्या versions मध्ये ज्ञात vulnerability आहे, आणि ती कोणत्या version पासून दुरुस्त झाली याची public सूचना (CVE आणि GHSA ids; OSV database त्या वेगवेगळ्या ecosystems मधून गोळा करतो).
SCA (software composition analysis) — तुमच्या dependencies ची यादी करून त्यांना advisories शी जुळवणारी tools: pip-audit, npm audit, Dependabot / GitHub dependency review, OSV-Scanner, Trivy, Grype, Snyk.
Lockfile — direct आणि transitive अशा प्रत्येक dependency चे नेमके version: package-lock.json, poetry.lock, uv.lock, किंवा pinned versions सह compile केलेली requirements.txt. Hashes असतील तर installer हे सुद्धा तपासतो की download झालेली प्रत्येक file तुम्ही तपासलेलीच नेमकी file आहे (pip install --require-hashes, npm ci).
आपोआप updates — नवे version किंवा fix आले की एक bot (Dependabot, Renovate) pull request उघडतो. CI tests चालवते; एक व्यक्ती merge करते.
Typosquatting — लोकप्रिय package च्या नावात छोटी typo असलेल्या नावाने malicious package publish करणे (reqeusts, numpyy), आणि कोणी चुकीचे टाइप करेपर्यंत वाट पाहणे.
Dependency confusion — तुमची company एक internal package वापरते, school-utils. एक attacker public index वर जास्त version सह school-utils publish करतो. दोन्ही indexes पाहणारा build public package निवडू शकतो. ते एकाच index ने थांबवा (AWS CodeArtifact किंवा Artifactory सारखा proxy जो internal आणि public packages देतो, आणि internal नावांना प्राधान्य देतो), scoped नावे (npm मध्ये @school/utils, scope तुमच्या registry शी जोडलेला), आणि तुमची नावे public मध्ये राखून ठेवणे.
Install scripts — काही ecosystems package install होत असतानाच code चालवतात (npm postinstall, Python source builds). Malicious package त्याच वेळी आपले काम करते — तुमचे app सुरू होण्याआधीच.

🤔 का

कारण तुम्ही तुमच्या dependencies ची प्रत्येक ओळ तुमच्या app च्या permissions आणि तुमच्या users च्या data सह production मध्ये पाठवता. Library मधली ज्ञात, आधीच दुरुस्त झालेली vulnerability हा आत शिरण्याचा सर्वात नेहमीचा मार्ग आहे — fix आधीच उपलब्ध आहे, आणि attackers जुने version शोधत scan करतात. आणि malicious packages दुर्मीळ नाहीत: सारखी दिसणारी नावे आणि ताब्यात घेतलेली maintainer accounts public registries मध्ये दर आठवड्याला दिसतात. बचाव म्हणजे "libraries कधीच वापरू नका" असा नाही. तो म्हणजे तुम्ही नेमके काय वापरता ते माहीत असणे, ते अद्ययावत ठेवणे, आणि नवे नाव न पाहता आत येऊ न देणे.

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

sec/supply.py मध्ये:

vulnerable(installed) प्रत्येक installed version ची तुलना ADVISORIES शी करते (requests, jinja2 आणि pyyaml साठी तीन नमुना नोंदी, प्रत्येक एका version मध्ये "fixed") आणि प्रत्येक सापडलेल्यासाठी (name, version, "upgrade to ≥ fixed", what) परत करते. Versions ची तुलना text म्हणून नाही, तर संख्या म्हणून होते (2.30.0 < 2.31.0).
typosquat(name) POPULAR मधली अशी नावे परत करते जी 1 किंवा 2 बदलांच्या अंतरावर आहेत (Levenshtein distance). नेमके तेच नाव (distance 0) flag होत नाही.

sec/demo.py मधले dependencies() चार installed packages चा audit करते आणि चार नावे तपासते.

🧪 करून पाहा

python3 sec/demo.py dependencies
python3 - <<'EOF'
import sys; sys.path.insert(0, "sec"); from supply import vulnerable, typosquat
for installed in ({"requests": "2.30.0"}, {"requests": "2.31.0"}, {"jinja2": "3.1.2", "pyyaml": "6.0.1"}, {"flask": "3.0.0"}):
    print(f"{str(installed):<38} → {vulnerable(installed) or 'no known advisory'}")
for name in ("request", "reqests", "pandsa", "djnago", "numpy", "boto3", "leftpad"):
    print(f"typosquat check {name:<8} → {typosquat(name) or 'no close popular name'}")
EOF
python3 sec/test_sec.py

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

dependencies हे छापते:

═══ dependencies ═══
── audit of {'requests': '2.28.1', 'jinja2': '3.1.4', 'pyyaml': '5.3.1', 'flask': '3.0.0'}
   requests 2.28.1: leaks Proxy-Authorization on redirect → upgrade to ≥ 2.31.0
   pyyaml 5.3.1: arbitrary code via full_load → upgrade to ≥ 5.4
   typosquat check reqeusts  → ['requests']
   typosquat check numpyy    → ['numpy']
   typosquat check flask     → no close popular name
   typosquat check boto4     → ['boto3']
   lockfiles with hashes · automated updates · an allow-list for new packages · audit in CI

✅ done — every door checked

तुमचा snippet हे छापतो:

{'requests': '2.30.0'}                 → [('requests', '2.30.0', 'upgrade to ≥ 2.31.0', 'leaks Proxy-Authorization on redirect')]
{'requests': '2.31.0'}                 → no known advisory
{'jinja2': '3.1.2', 'pyyaml': '6.0.1'} → [('jinja2', '3.1.2', 'upgrade to ≥ 3.1.3', 'XSS via xmlattr filter')]
{'flask': '3.0.0'}                     → no known advisory
typosquat check request  → ['requests']
typosquat check reqests  → ['requests']
typosquat check pandsa   → ['pandas']
typosquat check djnago   → ['django']
typosquat check numpy    → no close popular name
typosquat check boto3    → no close popular name
typosquat check leftpad  → no close popular name

Tests मध्ये ✅ L13 advisories and typosquats are caught आहे आणि शेवट 16/16 passed ने होतो.

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

दुरुस्त version (2.31.0) पास होते आणि त्याच्या अगदी आधीचे (2.30.0) होत नाही — रेषा नेमकी आहे. Demo मध्ये jinja2 3.1.4 पास झाले, पण 3.1.2 fail होते: package चे नाव नाही, तर तुमचे version महत्त्वाचे आहे. एक अक्षर कमी, जोडी अदलाबदल किंवा एक अक्षर जास्त — हे सगळे "लोकप्रिय नावाच्या जवळ" म्हणून दिसतात. आणि leftpad पास होते — ते सुरक्षित आहे म्हणून नाही, तर ते या यादीतल्या नावांच्या जवळ नाही म्हणून. नावांची तपासणी सारखी दिसणारी नावे पकडते; package चांगले आहे हे ती सिद्ध करत नाही. त्यासाठी अजूनही एक व्यक्ती, एक allow-list आणि एक lockfile लागते.

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

lockfile नाही, किंवा CI न वापरत असलेली lockfile (npm ci ऐवजी npm install)
सगळीकडे >= असलेले pip install -r requirements.txt — प्रत्येक build काहीतरी नवे आणू शकतो
audit चालवणे, 40 warnings पाहणे, आणि audit बंद करणे
tests शिवाय प्रत्येक update PR आपोआप merge करणे — malicious किंवा बिघडलेले version थेट production मध्ये जाते
internal index कडे निर्देश करणारे --extra-index-url — pip त्याच नावाचे public package निवडू शकतो
package चे नाव न वाचता blog वरून install command copy करणे
container ची base image विसरणे — तिचे OS packages सुद्धा dependencies च आहेत
कायमचे pin करणे: कोणी update न करणारी lockfile जुने bugs pin करून ठेवते

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

खऱ्या account वर — pinned versions आणि hashes सह Python (pip-tools), अशा प्रकारे install केलेले की इतर कोणतीही file नाकारली जाते, मग audit:

pip install pip-tools pip-audit
pip-compile --generate-hashes --output-file requirements.txt requirements.in
pip install --require-hashes -r requirements.txt
pip-audit -r requirements.txt --strict

तयार झालेल्या requirements.txt ची एक ओळ अशी दिसते (hash हा खऱ्या file चा SHA-256 आहे):

requests==2.32.4 \
    --hash=sha256:<sha256 of the requests-2.32.4 wheel>

Node.js — npm ci नेमकी lockfile install करते आणि package.json व lock जुळत नसतील तर fail होते; high-severity issues असतील तर audit build fail करतो:

npm ci --ignore-scripts        # add scripts back only for packages that need them
npm audit --audit-level=high

Dependabot — Python, npm, Docker base images आणि GitHub Actions साठी दर आठवड्याचे update PRs (.github/dependabot.yml):

version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule: { interval: "weekly" }
    groups:
      minor-and-patch: { update-types: ["minor", "patch"] }
  - package-ecosystem: "npm"
    directory: "/web"
    schedule: { interval: "weekly" }
  - package-ecosystem: "docker"
    directory: "/"
    schedule: { interval: "weekly" }
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule: { interval: "weekly" }

प्रत्येक pull request वर Dependency review — vulnerable package जोडणारा PR block करा:

name: dependency-review
on: pull_request
permissions: { contents: read }
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/dependency-review-action@v4
        with: { fail-on-severity: high }

Dependency confusion थांबवा — सगळ्यासाठी एकच index (उदाहरणार्थ public index कडे upstream असलेले AWS CodeArtifact), आणि npm मध्ये तुमच्या स्वतःच्या registry शी जोडलेला scope (.npmrc):

@school:registry=https://school-111122223333.d.codeartifact.ap-south-1.amazonaws.com/npm/internal/

aws codeartifact login --tool pip --domain school --domain-owner 111122223333 --repository internal

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: main branch वर audit हा required check करा, आणि अपवादांसाठी लिखित नियम ठेवा (finding कोण स्वीकारू शकतो, आणि कधीपर्यंत). कोणीही वगळू शकेल असा audit म्हणजे फक्त एक सूचना.

⏭️ पुढे

साहित्य तपासले गेले. पण तयार डबा वर्गात पोहोचल्यावर, तो आपल्याच स्वयंपाकघराने बनवलेला आहे आणि त्यात काय आहे हे शिक्षिकेला कसे कळते? पुढे: signatures, SBOMs आणि provenance.

git checkout lesson-14-artifacts

📦 Lesson 13 — Dependencies: other people's code in your app

📍 You are here: Lesson 13 of 16 · Previous: lesson-12-admission · Next: lesson-14-artifacts

📦 What's in this branch

Lessons 01–12, plus the first desk of the supply chain: dependencies. Most of the code in a modern app was written by someone else — libraries, and their libraries. You learn software composition analysis (SCA: matching versions against advisories), lockfiles with hashes, automated update PRs, and two supply-chain tricks — typosquatting and dependency confusion — and how to stop them.

sec/supply.py — vulnerable(installed) against a small ADVISORIES list, and typosquat(name) against POPULAR
sec/demo.py — python3 sec/demo.py dependencies
sec/test_sec.py — check L13

🧒 Explain like I'm 5

For the school fair, the kitchen does not make everything itself. It buys bread, jam and juice from outside. Dipika's rules for the delivery desk:

📋 The recall list. Every morning, check the news: "Jam from batch 5.3 is bad — use 5.4 or newer." If our jam is batch 5.3, throw it out and get a new one. That is checking advisories.
🧾 The exact order. Write down the exact brand, batch and the seal number of every jar. When the delivery comes, check each seal. A jar with a different seal goes back — even if the label looks right. That is a lockfile with hashes.
👀 Look-alike brands. "Nestel" is not "Nestlé". "Reqeusts" is not "Requests". Someone made a look-alike to trick a busy cook. That is typosquatting.
🏫 Our own recipes. The school has its own jam recipe, called "school-jam". If a stranger sells a jar also called "school-jam" in the public shop, with a higher batch number, a careless cook might buy his. So the kitchen only buys "school-jam" from the school's own shelf. That is stopping dependency confusion.
🔁 Weekly restock. Once a week a helper brings a list of newer batches, and the cook tastes before accepting (automated update PRs, tested in CI).

🗺️ Diagram

flowchart LR
    req["📄 requirements / package.json"] --> lock["🧾 lockfile<br/>exact versions + sha256 hashes"]
    lock --> audit{"📋 audit vs advisories<br/>pip-audit · npm audit · Dependabot"}
    audit -->|"requests 2.28.1 → ≥ 2.31.0<br/>pyyaml 5.3.1 → ≥ 5.4"| fix["🔁 update PR + tests"]
    name{"👀 new package name"} -->|"reqeusts ≈ requests"| stop["⛔ typosquat: review"]
    idx["🏫 one index / proxy<br/>internal names from internal only"] --> lock

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

❓ What

Direct and transitive dependencies — the packages you list, and the packages they need. A small web app often has a few direct dependencies and many more transitive ones. A problem in any of them is a problem in your app.
Advisory — a public note that versions of a package have a known vulnerability, and from which version it is fixed (CVE and GHSA ids; the OSV database collects them across ecosystems).
SCA (software composition analysis) — tools that list your dependencies and match them against advisories: pip-audit, npm audit, Dependabot / GitHub dependency review, OSV-Scanner, Trivy, Grype, Snyk.
Lockfile — the exact version of every dependency, direct and transitive: package-lock.json, poetry.lock, uv.lock, or a requirements.txt compiled with pinned versions. With hashes, the installer also checks that each downloaded file is the exact file you reviewed (pip install --require-hashes, npm ci).
Automated updates — a bot (Dependabot, Renovate) opens a pull request when a new version or a fix appears. CI runs the tests; a person merges.
Typosquatting — publishing a malicious package whose name is a small typo of a popular one (reqeusts, numpyy), waiting for someone to mistype.
Dependency confusion — your company uses an internal package, school-utils. An attacker publishes school-utils on the public index with a higher version. A build that looks at both indexes may pick the public one. Stop it with one index (a proxy like AWS CodeArtifact or Artifactory that serves internal and public packages, with internal names taking priority), scoped names (@school/utils in npm, with the scope mapped to your registry), and reserving your names publicly.
Install scripts — some ecosystems run code while a package installs (npm postinstall, Python source builds). A malicious package does its work then — before your app even starts.

🤔 Why

Because you ship every line of your dependencies to production, with your app's permissions and your users' data. A known, fixed vulnerability in a library is one of the most common ways in — the fix already exists, and attackers scan for the old version. And malicious packages are not rare: look-alike names and hijacked maintainer accounts appear in public registries every week. The defence is not "never use libraries". It is knowing exactly what you use, keeping it current, and not letting a new name in without a look.

🔧 How (in this repo)

In sec/supply.py:

vulnerable(installed) compares each installed version with ADVISORIES (three sample entries for requests, jinja2 and pyyaml, each "fixed in" a version) and returns (name, version, "upgrade to ≥ fixed", what) for every hit. Versions are compared as numbers (2.30.0 < 2.31.0), not as text.
typosquat(name) returns the names in POPULAR that are 1 or 2 edits away (Levenshtein distance). The exact name itself (distance 0) is not flagged.

dependencies() in sec/demo.py audits four installed packages and checks four names.

🧪 Try it

python3 sec/demo.py dependencies
python3 - <<'EOF'
import sys; sys.path.insert(0, "sec"); from supply import vulnerable, typosquat
for installed in ({"requests": "2.30.0"}, {"requests": "2.31.0"}, {"jinja2": "3.1.2", "pyyaml": "6.0.1"}, {"flask": "3.0.0"}):
    print(f"{str(installed):<38} → {vulnerable(installed) or 'no known advisory'}")
for name in ("request", "reqests", "pandsa", "djnago", "numpy", "boto3", "leftpad"):
    print(f"typosquat check {name:<8} → {typosquat(name) or 'no close popular name'}")
EOF
python3 sec/test_sec.py

✅ Verify — what you should see

dependencies prints:

═══ dependencies ═══
── audit of {'requests': '2.28.1', 'jinja2': '3.1.4', 'pyyaml': '5.3.1', 'flask': '3.0.0'}
   requests 2.28.1: leaks Proxy-Authorization on redirect → upgrade to ≥ 2.31.0
   pyyaml 5.3.1: arbitrary code via full_load → upgrade to ≥ 5.4
   typosquat check reqeusts  → ['requests']
   typosquat check numpyy    → ['numpy']
   typosquat check flask     → no close popular name
   typosquat check boto4     → ['boto3']
   lockfiles with hashes · automated updates · an allow-list for new packages · audit in CI

✅ done — every door checked

Your snippet prints:

{'requests': '2.30.0'}                 → [('requests', '2.30.0', 'upgrade to ≥ 2.31.0', 'leaks Proxy-Authorization on redirect')]
{'requests': '2.31.0'}                 → no known advisory
{'jinja2': '3.1.2', 'pyyaml': '6.0.1'} → [('jinja2', '3.1.2', 'upgrade to ≥ 3.1.3', 'XSS via xmlattr filter')]
{'flask': '3.0.0'}                     → no known advisory
typosquat check request  → ['requests']
typosquat check reqests  → ['requests']
typosquat check pandsa   → ['pandas']
typosquat check djnago   → ['django']
typosquat check numpy    → no close popular name
typosquat check boto3    → no close popular name
typosquat check leftpad  → no close popular name

The tests include ✅ L13 advisories and typosquats are caught and end with 16/16 passed.

🏁 What you just proved

The fixed version (2.31.0) passes and the one just before it (2.30.0) does not — the line is exact. jinja2 3.1.4 passed in the demo, but 3.1.2 fails: your version is what matters, not the package name. A missing letter, a swapped pair or an extra letter all come out as "close to a popular name". And leftpad passes — not because it is safe, but because it is not near this list. Name checks catch look-alikes; they do not prove a package is good. That still needs a person, an allow-list and a lockfile.

⚠️ Common mistakes

no lockfile, or a lockfile that CI does not use (npm install instead of npm ci)
pip install -r requirements.txt with >= everywhere — every build can pull something new
running an audit, seeing 40 warnings, and turning the audit off
auto-merging every update PR with no tests — a malicious or broken version goes straight to production
--extra-index-url pointing at an internal index — pip may choose the public package with the same name
copying an install command from a blog without reading the package name
forgetting the container base image — its OS packages are dependencies too
pinning forever: a lockfile that nobody updates pins old bugs

🏭 In production

On a real account — Python with pinned versions and hashes (pip-tools), installed so that any other file is refused, then audited:

pip install pip-tools pip-audit
pip-compile --generate-hashes --output-file requirements.txt requirements.in
pip install --require-hashes -r requirements.txt
pip-audit -r requirements.txt --strict

A line of the resulting requirements.txt looks like this (the hash is the real file's SHA-256):

requests==2.32.4 \
    --hash=sha256:<sha256 of the requests-2.32.4 wheel>

Node.js — npm ci installs exactly the lockfile and fails if package.json and the lock do not agree; the audit fails the build on high-severity issues:

npm ci --ignore-scripts        # add scripts back only for packages that need them
npm audit --audit-level=high

Dependabot — weekly update PRs for Python, npm, Docker base images and GitHub Actions (.github/dependabot.yml):

version: 2
updates:
  - package-ecosystem: "pip"
    directory: "/"
    schedule: { interval: "weekly" }
    groups:
      minor-and-patch: { update-types: ["minor", "patch"] }
  - package-ecosystem: "npm"
    directory: "/web"
    schedule: { interval: "weekly" }
  - package-ecosystem: "docker"
    directory: "/"
    schedule: { interval: "weekly" }
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule: { interval: "weekly" }

Dependency review on every pull request — block a PR that adds a vulnerable package:

name: dependency-review
on: pull_request
permissions: { contents: read }
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/dependency-review-action@v4
        with: { fail-on-severity: high }

Stop dependency confusion — one index for everything (for example AWS CodeArtifact with an upstream to the public index), and in npm a scope mapped to your own registry (.npmrc):

@school:registry=https://school-111122223333.d.codeartifact.ap-south-1.amazonaws.com/npm/internal/

aws codeartifact login --tool pip --domain school --domain-owner 111122223333 --repository internal

🏭 Why this matters in production: make the audit a required check on the main branch, with a written rule for exceptions (who may accept a finding, and until when). An audit that anyone can skip is only a suggestion.

⏭️ Next

The ingredients are checked. But when the finished lunch box reaches the classroom, how does the teacher know it is the one our kitchen made, and what is inside it? Next: signatures, SBOMs and provenance.

git checkout lesson-14-artifacts

← Previousadmission Next →artifacts

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