Lessons 48.1–48.3 secured your own code: threat model, inputs, secrets, access, limits, failure. Now look outward. Your application also *is* its dependencies, its configuration, and the pipeline that ships it — and AI can review all of it, provided you ask precisely and understand what the review is worth.

The supply chain is part of your app

Modern software is mostly other people's code. A typical Research Desk install pulls a web framework, an auth client, a database driver, chart and date libraries, test tooling — and each of those pulls its own dependencies (transitive dependencies you never chose directly). Add generated code, editor plugins, deployment integrations, and the CI pipeline's secrets, and the "attack surface" extends well beyond files you wrote.

Concretely, the supply chain includes:

• Packages and versions — what you installed and which release.
• Lockfiles (package-lock.json, pnpm-lock.yaml, equivalents) — the exact resolved tree that makes installs reproducible. Committed, reviewed, and the basis for every deploy.
• Transitive dependencies — the packages your packages pulled in. You inherit their bugs; the lockfile and advisories are how you see them.
• Generated code and scaffolds — AI- or template-produced files with pinned, sometimes ancient, versions inside.
• CI secrets and build configuration — the tokens your pipeline uses to test, build, and deploy. A leaked CI token can push code as you.
• Vendor integrations — analytics snippets, auth providers, storage buckets. Each is a trust relationship with its own permissions.

A compromise or mistake anywhere in this chain ships as your product. That is why the review below covers diffs and config, not just route logic — and why the OWASP Top 10 includes vulnerable and outdated components as a standing category.

"Latest" is not a safety strategy

The beginner reflex — "just update everything to latest and we're secure" — fails in both directions. Blindly chasing latest can pull a breaking change, a compromised release, or a rewritten API the night before launch; never updating leaves known holes open indefinitely. Replace the reflex with intention:

1. Know what each dependency does. If nobody can say why a package exists, it is a candidate for removal. Unused dependencies are pure risk with zero benefit. 2. Keep the lockfile committed and review dependency diffs. A pull request that adds three packages actually adds thirty transitive ones — read what arrived. 3. Update intentionally, not continuously. Schedule updates; read changelogs and advisories with your package tooling (npm audit and equivalents); update, test, and ship as a focused change. 4. Remove before you add. Every cleanup pass (Class 53) should retire at least one unused package, flag, or integration. 5. Pin and verify automated updates. Dependency bots are useful servants and terrible masters — let them propose, make tests and a human dispose.

Same discipline for AI-generated code: ask which packages a scaffold pulled in and why, and refuse the ones with no justification.

Configuration: prod versus preview, public versus server-only

Most "my app leaked data" stories are configuration stories, not code stories. Review this checklist on every deploy:

• Production versus preview values — preview deployments must point at test data, test keys, and sandboxed providers. A preview build with production keys spends production money and touches production records.
• Public versus server-only variables — frameworks distinguish variables embedded in the browser bundle from server-only ones. Anything public is published; audit which names carry the public prefix and what values they hold.
• Debug modes off in production — verbose errors, introspection endpoints, and development consoles exist to help you and therefore help attackers equally.
• Storage visibility — object-storage buckets and CDN paths default the way they default, not the way you assume. Verify private means private: attempt anonymous access to a watchlist export and confirm denial.
• Database policies in every environment — the ownership rules from Class 47 must exist in preview, staging, *and* production, not just where you tested.
• Allowed origins and CORS lists — each entry is a site permitted to call your API from a browser. Prune them.
• Deployment permissions — who can promote to production, who holds CI secrets, and what happens when someone leaves.

Write the answers down per environment. Configuration that lives only in someone's memory is configuration that drifts.

The useful AI review: exact files, exact lines

AI makes a tireless, literal-minded reviewer — excellent at pattern-matching across a whole repo, incapable of certifying anything. Get the good half with a precise request. Adapt this prompt to your stack:

Inspect this repository for security issues. Check: exposed secrets or
key-shaped strings; privileged keys reachable from client-side code;
mutation routes missing authentication; user-data reads/writes missing
server-side ownership checks; unsafe redirect targets; weak or missing
input validation; dependencies added or changed in this PR; sensitive
fields (tokens, passwords, private content) in logs. For each finding cite
exact file paths and line numbers. Separate EVIDENCE (quoted code/config)
from GUESSES (what you could not confirm). List what you checked and found
clean. Do not modify files.

What makes this work: a bounded scope (this repo, this PR), a named checklist (the failure classes from this class), evidence discipline (file:line plus quoted code, guesses labeled), and a read-only constraint. Run it with a model or context different from the one that wrote the code when you can — the original author, human or AI, is the worst grader of its own homework. File the findings like any bug report: severity, evidence, owner, fix, regression test, retest.

Review the review, too. AI reviewers produce false positives (flagging a placeholder example key) and false negatives (missing a novel ownership path). Your threat model and route safety cards are the answer key: every High-tier story should map to either a finding or a test that proves it clean.

A review is not a certificate

Say this plainly in your docs and to any stakeholder who asks:

It catches real issues cheaply and early — the echoed secret, the missing ownership check, the debug flag left on. It does not prove the absence of issues, does not replace tests with two identities, does not evaluate your provider's posture, and does not satisfy anyone who needs independent assurance. Medium- and high-risk systems — money movement, financial guidance people act on, sensitive personal data, meaningful user scale, privileged integrations, a serious public launch — still need qualified human review and often external testing, which is exactly what Class 49 (penetration testing and independent review) prepares you to commission.

Calibrate by tier: Low-tier marketing page, AI review plus tests may suffice. High-tier watchlist-and-spending app at public launch: AI review, human review, *and* scoped professional testing, each recorded. The risk tier from Lesson 48.1 decides, not your confidence level.

Exercise: the versioned review

Create a versioned security-review checklist (start at v1 in your repo) covering: secrets, client-side keys, auth on mutations, ownership checks, validation, redirects, CORS/origins, env separation, storage visibility, database policies, dependency diff, and log hygiene. Run the AI review prompt against your current code or one focused PR. Record every finding with file:line evidence, fix each accepted finding on its own task card with a regression test, and note explicitly what remains risky and who owns it.

Finish line: a versioned checklist plus one focused review PR or commit: findings listed, fixes linked, tests added, remaining risk named with an owner.

Verify: pick one finding and confirm the fix with a failing-before/passing-after test. Confirm the checklist version is recorded alongside the reviewed commit.

Common failure: running the review once, fixing nothing, and citing "AI reviewed" as assurance. A review with no linked fixes and no remaining-risk note is theater.

Check your understanding

1. Why is the lockfile a security artifact, not just a build convenience? 2. Name three configuration pairs (prod/preview, public/server-only, …) and what goes wrong when each is mixed up. 3. What four qualities make the AI review prompt useful, and what can its output never be?

That closes Class 48. You can now model threats, validate inputs, guard secrets, enforce ownership, limit cost, fail safely, audit your supply chain, and extract an honest review from an AI. Class 49 takes the final step outward: knowing when to hire qualified strangers to try to break in — and how to scope, receive, and prove the fix for everything they find.