Security in Practice: Code Review Checklist, Testing, Incidents and Interview Answers

Lesson 0 gave you the mindset and the OWASP map. Lesson 1 covered injection. Lesson 2 covered XSS, CSRF and headers. Lesson 3 covered passwords and login. Lesson 4 covered access control. Lesson 5 covered secrets, encryption and data. Lesson 6 covered the supply chain. Lesson 7 covered APIs and servers. This last lesson ties all of that into things you can use tomorrow: a review checklist, the four kinds of scanning tools (and what each can never find), a workflow file that runs them, an incident checklist, some team habits, and a long set of interview questions with model answers.

For the lead's view, read Team Lead Lesson 14 (A Security Mindset for Team Leads) and Team Lead Lesson 4 (Incidents, Team Health and Growing as a Lead). For CI/CD that deploys see DevOps Lesson 14. For writing the tests that guard these fixes see Testing Lesson 3. For the code review habit see Git and GitHub Lesson 3.

Words used in this lesson

• Code review is when another person reads your change before it is merged.
• SAST (static application security testing) reads your source code, without running it, and looks for dangerous patterns.
• DAST (dynamic application security testing) attacks a running app from the outside, like a very patient stranger, and looks at the responses.
• SCA (software composition analysis) checks the packages you use against a list of known vulnerabilities. npm audit and Dependabot do this.
• Secret scanning looks for keys, tokens and passwords in code and Git history.
• False positive is an alarm for something that is not a problem. False negative is a real problem the tool did not see.
• Triage is the first sorting: is this alert real, how bad, who fixes it, how soon.
• Incident is an event that harms, or may harm, the confidentiality, integrity or availability of your system or data.
• Contain means stop the damage from growing (cut access, take a service offline). Rotate means replace a secret with a new one and kill the old one.
• Post-mortem is a written review after an incident: what happened, why, and what we change. A blameless one asks "what in our system let this happen?" and not "who did it?".
• Threat model is a short, structured answer to "what are we building, what can go wrong, what do we do about it?"
• Defence in depth means several layers of protection, so one failure is not the end.
• Security champion is a developer on a team who takes extra interest in security and helps the others, without being a full-time security person.
• Shift left means finding problems earlier in the process, for example at code review instead of in production.

A code review checklist

Most security bugs do not need a special tool to spot. They need a reviewer who asks the right question at the right line. Use this table in pull requests. The "smell" column is something you can actually see in a diff.

Three habits make the checklist work:

1. Review the diff for new "doors". A new route, a new input, a new file read, a new outbound call, a new permission, a new package. The bug is nearly always at a door, not in the middle of a room.
2. Ask the threat-model questions out loud. "What if this ID belongs to someone else?" "What if this string is ../../etc/passwd?" "What if this request is sent 10,000 times?"
3. Do not review only the green lines. A security fix often removes a line (a check). If a PR deletes a check, ask why.

The four kinds of scanners

New developers hear "run a security scan" and think of one tool. In truth there are four kinds, and each sees something different. Each also has blind spots, and the blind spots are the part to remember.

None of them finds a design flaw ("anyone with the link can see the invoice") and none replaces a person thinking. They are good at the boring 80 percent, so humans can spend their time on the other 20.

SAST, for real: Semgrep on a toy file

I wrote a small Express file with four routes: a user lookup that builds SQL with +, a command runner that builds a shell command with +, a safe query with a placeholder, and an orders route that has an IDOR (no owner check):

app.get("/user", (req, res) => {  const id = req.query.id;  // BAD: user input is glued into the SQL text  db.query("SELECT * FROM users WHERE id = " + id, (err, rows) => res.json(rows));});app.get("/run", (req, res) => {  // BAD: user input goes to a shell  require("child_process").exec("ls " + req.query.dir, (e, out) => res.send(out));});app.get("/safe", (req, res) => {  db.query("SELECT * FROM users WHERE id = ?", [req.query.id], (err, rows) => res.json(rows));});app.get("/orders/:id", (req, res) => {  // BAD (IDOR): no check that this order belongs to the logged-in user  db.query("SELECT * FROM orders WHERE id = ?", [req.params.id], (err, rows) => res.json(rows));});

And two rules in Semgrep's YAML format. A rule is a code pattern with holes: $X matches any expression and ... matches anything. The rules say "a .query() call whose first argument is a string plus something" and the same for .exec():

rules:  - id: sql-string-concat    languages: [javascript]    severity: ERROR    message: SQL text is built with + from a variable. Use placeholders (parameterised query).    pattern: $DB.query("..." + $X, ...)  - id: exec-with-concat    languages: [javascript]    severity: ERROR    message: A shell command is built from a variable. Use execFile with an argument list.    pattern: $CP.exec("..." + $X, ...)

semgrep scan --metrics=off --config rules.yml .

This is the real output (the ASCII box lines trimmed a little):

┌─────────────────┐│ 2 Code Findings │└─────────────────┘    app.js   ❯❯❱ sql-string-concat          SQL text is built with + from a variable. Use placeholders (parameterised query).            7┆ db.query("SELECT * FROM users WHERE id = " + id, (err, rows) => res.json(rows));   ❯❯❱ exec-with-concat          A shell command is built from a variable. Use execFile with an argument list.           12┆ require("child_process").exec("ls " + req.query.dir, (e, out) => res.send(out)); • Findings: 2 (2 blocking) • Rules run: 2 • Targets scanned: 1Ran 2 rules on 1 file: 2 findings.

Two findings, with the file and line, and the safe query on line 16 is not reported. That is what a good SAST rule gives you. Now look at what is missing. I added the /orders/:id route (the IDOR) after the first run and ran the scan again: still Findings: 2. The IDOR has no bad pattern. Every line looks fine. The absence of an ownership check is invisible to a pattern matcher. Only a reviewer, a test, or a DAST run with two different users can find it. (Semgrep's own README says the Community Edition can analyse only within the boundaries of a single function or file, and that the paid product goes further. I used only the free one and my own two rules, which are small. Real rule packs have thousands of rules.)

Secret scanning, for real: gitleaks

I made a Git repository with two commits. In the first, a file with a fake token: I generated 36 random letters and digits and put ghp_ in front, so it has the shape of a GitHub personal access token but is not one. In the second commit I deleted the file. Then I ran gitleaks:

gitleaks git -v --no-banner --redact .

Finding:     const ghToken = "REDACTED"; // random, fake, ...Secret:      REDACTEDRuleID:      github-patEntropy:     4.784184File:        token.jsLine:        1Commit:      bceb7c262154b3b3066bc48011e72386042cf753Author:      tEmail:       a@b.cDate:        2026-10-11T18:08:14ZFingerprint: bceb7c262154b3b3066bc48011e72386042cf753:token.js:github-pat:1INF 2 commits scanned.WRN leaks found: 1

The exit code was 1, so a CI job fails. (--redact hides the secret in the output, which is a good habit for CI logs. -v shows the findings.) Now the important part. After I deleted the file in a new commit, I scanned two ways:

$ gitleaks dir --no-banner --redact .        # the files as they are nowINF no leaks found$ gitleaks git --no-banner --redact .        # the whole Git historyINF 2 commits scanned.WRN leaks found: 1

The current files are clean, but the history still has the secret. Anyone who clones the repository can run git log -p and read it. That is why Lesson 6 says: rotate first. Deleting the file changes nothing about who already has the key. The gitleaks README lists the three modes I used: git (scans commits with git log -p), dir (scans files) and stdin.

A small trap I found: my first test used the well-known AWS example key AKIAIOSFODNN7EXAMPLE from the AWS documentation, and gitleaks said "no leaks found". Tools skip well-known example values to reduce noise. That is good for you, but remember it when you write a test for your own pipeline: use a random value with the right shape.

SCA and DAST

For SCA, Lesson 6 has the real npm audit output for an old lodash. In CI, npm audit --audit-level=high exits with a non-zero code when it finds something at that level or above, which fails the job.

For DAST, the best-known free tool is OWASP ZAP. It acts as a proxy and a scanner: you point it at a running copy of your app (a test environment, never a production system you do not own), and it crawls pages and sends many modified requests, then reports findings with the request and response as proof. I could not run it here (see the note). Use it against your own staging site, with permission, and with test data. A good first step is its "baseline" scan, which is a passive check that does not attack. Remember what it cannot do: it cannot know that user A should not see user B's order unless you give it two logins and a rule.

A workflow that runs the cheap checks

Here is a GitHub Actions workflow with three small jobs: a dependency audit (SCA), a secret scan (gitleaks), and CodeQL (SAST). It uses the safe habits from Lesson 6: actions pinned to commit hashes (I took the hashes from git ls-remote on the day I wrote this), a contents: read token by default, and persist-credentials: false. I checked that it is valid YAML. I could not run it, because it needs GitHub.

name: Security checkson:  pull_request:    branches: [main]  push:    branches: [main]  schedule:    - cron: "17 3 * * 1"   # every Monday, 03:17 UTCpermissions:  contents: readjobs:  audit:    name: Dependency audit    runs-on: ubuntu-latest    timeout-minutes: 10    steps:      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1        with:          persist-credentials: false      - uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # v7.1.0        with:          node-version: 22          cache: npm      - run: npm ci --ignore-scripts      - run: npm audit --audit-level=high  secrets:    name: Secret scan    runs-on: ubuntu-latest    timeout-minutes: 10    steps:      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1        with:          fetch-depth: 0          # the scan needs the full history          persist-credentials: false      - uses: gitleaks/gitleaks-action@e0c47f4f8be36e29cdc102c57e68cb5cbf0e8d1e # v3.0.0        env:          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}          GITLEAKS_LICENSE: ${{ secrets.GITLEAKS_LICENSE }}  # only for organisation repos  codeql:    name: CodeQL    runs-on: ubuntu-latest    timeout-minutes: 20    permissions:      contents: read      security-events: write    # lets CodeQL upload its results    steps:      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1        with:          persist-credentials: false      - uses: github/codeql-action/init@24c54180a607b1449ed407dd24f251e4e9147c8d # v4.38.3        with:          languages: javascript-typescript      - uses: github/codeql-action/analyze@24c54180a607b1449ed407dd24f251e4e9147c8d # v4.38.3

Where each tool fits in time

Threat modelling in ten minutes

You met this in Lesson 0. The OWASP Threat Modeling cheat sheet (quoting the Threat Modeling Manifesto) says the work answers four questions:

1. What are we working on? Draw it: users, your app, the database, the third parties, and the arrows between them. Mark where data crosses a trust boundary (from the internet to your server, from your server to a partner).
2. What can go wrong? Walk each arrow and box. A memory aid is STRIDE: Spoofing (pretending to be someone), Tampering (changing data), Repudiation (denying an action), Information disclosure (leaking), Denial of service (making it unavailable), Elevation of privilege (gaining rights).
3. What are we going to do about it? For each threat: fix it, reduce it, accept it (and write that down), or avoid the feature.
4. Did we do a good enough job? Check that each fix exists and has a test, and review again when the design changes.

A tiny example for "add a profile picture by URL": the arrow from the user to the server carries a URL (threat: SSRF, Lesson 7); the file we store (threat: a script in an SVG, Lesson 7); who can see it (threat: access control, Lesson 4); how many can be uploaded (threat: disk filling, rate limit). Five minutes, a whiteboard, and you already have four tickets before any code is written.

The first hour of an incident

Something bad has happened: a key is public, an account is hijacked, a server is acting strangely, a package you use was reported as malicious. This is the moment when people panic and make it worse. A short written plan helps, so write it before you need it. This is a simple version for a small team. For the people side (staying calm, roles, blameless reviews), read Team Lead Lesson 4.

Notes:

• Logs are your memory. You can only investigate what you recorded. OWASP's Logging cheat sheet says to log the events that matter for security (failed logins, access-control failures, input validation failures, admin actions) with time, user and request ID, and not to log passwords, tokens or keys. If you have no logs, add them now so the next incident is easier. OWASP's A09:2025 is named "Security Logging & Alerting Failures" on purpose: logs without alerts that someone reads have little value.
• A leaked key is the most common incident. The recipe is in Lesson 6 and Lesson 5: rotate, check provider logs for use, remove from code, add scanning. For a token stolen from a developer's machine (as in the Shai-Hulud worm), rotate everything that machine could reach.
• A bad package. If a dependency was reported as malicious: find which versions you installed (the lock file tells you), treat any machine or CI run that installed the bad version as exposed, rotate the secrets they had, pin to a clean version, and check the registry's and the maintainers' notices. The ua-parser-js advice at the time was to treat machines that installed the bad versions as fully compromised.
• Practise. Once a year, run a one-hour pretend incident ("a key was found on GitHub") and see who knows what to do. You will find gaps, such as nobody knowing how to rotate the database password.

Security champion habits

A security champion is not a security expert and not a gatekeeper. It is a developer who cares a bit more, and makes it easy for the team to do the right thing. You can start now, whatever your job title. Small habits:

1. Ask one security question in every design talk and PR. "What if this input is hostile?" Asking is the habit.
2. Keep a one-page team checklist (the table above), in the PR template, short enough to be used.
3. Own the dependency and alert routine. One day a week, look at the Dependabot PRs and the audit. Write down what you decided.
4. Make the safe way the easy way. A shared function that does the upload checks, a middleware for auth and rate limits, a helper that makes error IDs. People copy what is easy.
5. Write the test with the fix. A security bug fixed without a test comes back.
6. Read one incident report a month. Real post-mortems (public ones from big companies) teach more than slides.
7. Learn the tools of an attacker, safely. Try the exercises on practice sites (like PortSwigger's Web Security Academy) and only on systems you own or have written permission to test.
8. Stay kind. When someone finds a hole in your code, thank them. A team that punishes the finder stops finding holes.
9. Report, don't hide. If you made a mistake (pushed a key), say so fast. Fast reports turn into a 10-minute fix, slow ones into an incident.
10. Keep learning in small bites. The OWASP Top 10, the OWASP Cheat Sheet Series (short pages on one topic each) and the Node.js security guide are free and good.

Try it

1. Take a pull request from your own project (or an open source one). Go through the review table and find the first three "doors" in it. Which row of the table applies?
2. Install gitleaks. Make a new Git repository, add a file with a random ghp_ plus 36 letters or digits, and commit. Run gitleaks git. Delete the file, commit, and run gitleaks dir and gitleaks git again. What is different?
3. Write a Semgrep rule that finds eval(...) of a non-constant argument in JavaScript. Try it on a file with a safe and an unsafe call.
4. Copy the workflow above into a practice repository. What do you need to create for the secret-scan job if the repository belongs to an organisation?
5. Draw a data-flow diagram for a feature you know (login, checkout, comments). Mark every trust boundary. List two STRIDE threats for each.
6. Write a one-page "key leaked" runbook for your own project: who is the lead, where each secret lives and how to rotate it.
7. Run a 20-minute pretend incident with a friend: "our database password is in a public repo". Time how long until the password is rotated.
8. Pick any five questions from the interview section below. Answer them out loud without reading, then compare.

Answers

1. Typical doors: a new route, a new field, a new package, a changed workflow. Match each to a row: input to query (1), route without owner check (4), package.json change (6).
2. gitleaks dir reports no leaks (the file is gone), but gitleaks git still reports one, because the history has it.
3. Something like pattern: eval($X) plus pattern-not: eval("..."). Check that the constant call is not reported.
4. A GITLEAKS_LICENSE repository secret. The README says organisations need a licence key (free to get) and personal accounts do not.
5. Trust boundaries are where data crosses from outside to inside, such as browser to server, server to database, and server to a third party. Any threat that fits one of the six STRIDE letters is fine.
6. A good runbook has names, links, and the exact steps. The test is that someone who has never done it can follow it.
7. The first time is slow, usually because nobody knows who can change the database password. That is the point of practising.
8. Speaking aloud finds gaps that reading hides.

Interview questions

These are the security questions I would expect for a developer role. The answers are in first person and short enough to say out loud.

Key takeaways

• Review for doors: new inputs, routes, outbound calls, packages and permissions. Use the checklist table, and also look at deleted lines.
• Four kinds of scanners, four blind spots. SAST (Semgrep, CodeQL) misses missing checks; DAST (ZAP) misses code no request reaches; SCA (npm audit) only knows known problems; secret scanning (gitleaks) needs a recognisable shape. None replaces a reviewer and a test.
• Deleting a secret does not remove it. My gitleaks run found the token in history after the file was gone. Rotate first.
• Run cheap checks automatically in a workflow with pinned actions and minimal permissions, and make sure someone reads the failures.
• Threat model in ten minutes with four questions and STRIDE. Fix the design before the code.
• First hour of an incident: declare, contain, rotate, preserve logs, scope, tell people, plan the fix. Then a blameless post-mortem with owned actions. Write the plan before you need it.
• Be a security champion: ask the question, keep the checklist, make the safe way the easy way, write the test with the fix, and say thanks to people who find holes.
• Only test what you own or may test.

What's next

This is the last lesson of the series. To go deeper, pick the area where your work is:

• Servers and APIs: Backend Lesson 3 (Validation at the Edge), Backend Lesson 4 (Error Handling), Backend Lesson 5 (Logging and Observability) and Backend Lesson 6 (Authentication and Authorization on the Server).
• Pipelines and deploys: DevOps Lesson 14 (CI/CD with GitHub Actions) and Git and GitHub Lesson 5 for branch protection and CODEOWNERS.
• Tests that guard the fixes: Testing Lesson 3 (Integration and API Tests).
• Leading a team on security: Team Lead Lesson 14, Team Lead Lesson 1 for the dependency decision, and Team Lead Lesson 4 for incidents.
• Interview practice across the stack: Full-Stack Lesson 24.

And then practise: add the workflow from this lesson to a real project, write a one-page runbook for "a key was leaked", and ask one security question in your next pull request review. Revisit Lesson 0 after a month and see how much more of the map you can fill in.