Web Security (OWASP Top 10:2025) Module 17 – Secure code review and routine
Making security routine on a small team
Put a security section in pull requests, gate only what is new, keep a living threat model, rehearse an incident, and use ASVS and SAMM to pick the next step.
What you will learn
- Add a security section to the pull request template and check that risky changes answer it
- Set gates that block what a change adds, with code owners, secret scanning and a dependency bot that holds new releases back
- Maintain a living threat model and a risk register, and run a tabletop exercise on a schedule
- Track ASVS coverage as data and use SAMM to choose the next improvement
Before you start
What you’ll learn · Before you start
What you will learn
- Add a security section to the pull request template and check that risky changes answer it
- Set gates that block what a change adds, with code owners, secret scanning and a dependency bot that holds new releases back
- Maintain a living threat model and a risk register, and run a tabletop exercise on a schedule
- Track ASVS coverage as data and use SAMM to choose the next improvement
Before you start
On this page
A team of four ships twice a week and has no security engineer. What it can have is a routine: a few habits, set up once, that keep working when nobody is thinking about security. A question in every pull request, an owner for every risky file, gates that block only what is new and serious, and a list of what is still not done.
This lesson sets up that routine in nine habits and checks its pieces with programs that ran: a pull request check, three configuration files, a status file for the 70 requirements of ASVS Level 1, and two honest numbers. It ends with SAMM, which helps to choose the next habit to add.
A routine is nine habits that keep working when nobody is thinking about them
OWASP’s A06:2025 says that secure design is neither an add-on nor a tool that you can add to software. It asks for a lifecycle with threat modelling, a paved road of safe defaults, tooling, and post-incident reviews that improve the process. NIST’s Secure Software Development Framework describes a core set of practices that fit whichever development model a team already uses. A team of four cannot run a programme, but it can run nine habits, and each answers a failure that earlier lessons showed:
| Habit | What it stops |
|---|---|
| A security section in every pull request | A change adds a route, a sink or a dependency that nobody asked about |
| A file in the repository that lists, for each path, the people or teams that GitHub asks to review a change to it. for risky files | A change to sign-in, payments or the pipeline merges without the person who knows it |
| Gates in CI | A new secret, a new serious finding or a lost header reaches the main branch |
| A dependency bot with a A delay between the release of a package version and the update that proposes it, so that a bad release can be noticed first. | Packages go stale, or a brand-new release is installed before anyone has looked at it |
| A quarterly review of access and secrets | Leavers keep their access and old keys stay valid |
| SECURITY.md and security.txt | A reporter cannot find anyone to tell |
| A runbook and a tabletop twice a year | The first rehearsal of an incident is the incident |
| A threat-model update per major feature | A design flaw ships because nobody asked what could go wrong |
| A few honest numbers | Nobody can say whether any of this works |
The habits run at different rhythms, from every change to twice a year, and the point of the routine is that none of them needs a person to remember it:
- Every change
A question, an owner and the gates template, owners, gates
The pull request template asks its security questions, the owners of a risky file are asked to review, and the gates run. Nobody has to remember any of it.
- Every week
A bot proposes the updates dependency bot
The dependency bot opens a pull request for each new version, and a cooldown holds a brand-new release back for a few days.
- Every night
A baseline scan of a test copy baseline scan
A passive scan reads the pages of a copy you own and reports what is new.
- Every feature
The threat model changes with the code threat model
A major feature changes its threat model in the same pull request as the feature itself.
- Every quarter
Access and secrets are reviewed access review
The team reviews who still has access to the repository, the pipeline and production, and which keys are old.
- Twice a year
A tabletop exercise tabletop
The team talks through a made-up incident with the runbook open.
- Always on
A way to be told, and a few honest numbers SECURITY.md, numbers
SECURITY.md and security.txt tell a reporter where to write, and a few numbers tell the team whether the rest is working.
The timeline has 7 events, from Every change to Always on.
Key idea
A routine is the set of habits that run without anyone deciding to run them, and it is judged by what it blocks and by a short, honest list of what is still open.
Checkpoint
Check: The nine habits and their rhythm
Flashcards · 4 cards
Recall it, then check
Say the answer to yourself before you look: recalling it is what makes it stick.
-
Which nine habits make security routine on a small team?
Nine: put a security section in every pull request; name code owners for risky files; run gates in CI; let a dependency bot work with a cooldown; review access and secrets every quarter; publish SECURITY.md and security.txt; keep a runbook and rehearse it with a tabletop exercise twice a year; update the threat model for each major feature; and track a few honest numbers. Each answers a failure that earlier lessons showed.
-
What is a security routine, and how is it judged?
The habits that keep running without anyone having to decide to run them, at rhythms from every change to twice a year. It is judged by what it blocks and by a short, honest list of what is still open. A06:2025 says secure design is neither an add-on nor a tool: it asks for a lifecycle with threat modelling, a paved road of safe defaults, tooling and post-incident reviews that improve the process.
-
What do code owners do for risky files?
A file in the repository that names, per path, who GitHub asks to review a change there, so a change to sign-in, payments or the pipeline does not merge without the person who knows it.
-
What is a dependency cooldown?
A delay between the release of a package version and the update that proposes it, so that a bad release can be noticed first and packages neither go stale nor get installed before anyone has looked at them.
A pull request template asks the questions that a diff cannot answer Pro: opens with a Pro, Premium or Ultimate pass
In this part:
- Gates block what is new and serious, and say nothing about the rest
- A threat model and a risk register that change with the code
- Rehearse an incident twice a year, and clean up on a schedule
- ASVS coverage as data, and SAMM to choose the next step
- Honest numbers: time to fix and the age of what is open
- Practise: check a routine’s records
- Find the owner of a file in a CODEOWNERS list
- List the next actions from an ASVS status file
- Interview questions
- You join a team of five that has no security process, and you are asked to fix that within a quarter. What do you set up first, in what order, and how do you know that it is working?
- A security gate in CI fails on 200 old findings, and the team has started to merge with the override. What do you change, and what do you do about the 200?
- A customer asks a startup of three developers which ASVS level its product meets. How do you decide what to answer, and what do you show?
- Key takeaways
1 diagram · 4 runnable examples (JavaScript, Python, asvs-status.json, fixed: CODEOWNERS, fixed: dependabot.yml, fixed: pre-commit, weak: CODEOWNERS, weak: dependabot.yml, weak: pre-commit) · 2 exercises with sample tests · 3 interview answers · about 44 minutes
Opening this part with your pass…
This part opens with any MySmartCoPilot pass.
- Pro pass · 1 week₹79$2.99
- 30 days₹179$5.99
- 1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so this part can’t be opened at the moment. The free part above stands on its own. If you have a pass, enter your licence key.
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
Terms in this lesson
- ASVS status file
- A file with one entry for each ASVS requirement the team has looked at: its status, the evidence for it and an owner. It turns "are we secure?" into a list of requirements that still lack evidence.
- code owners
- A CODEOWNERS file lists, for each path, the people or teams whom GitHub asks to review a change to it. The last matching pattern takes precedence, and branch protection can require an approval from an owner.
- cooldown
- A delay between the release of a new package version and the pull request that proposes it, so that a bad release can be noticed and pulled first. Dependabot's cooldown holds version updates and never security updates.
- risk register
- A table of the risks a team has decided not to fix yet. Each row has the finding, its rating, the decision, a named owner who can change it and the day it will be looked at again.
- SAMM
- OWASP's Software Assurance Maturity Model: five business functions with three security practices each, and three maturity levels per practice. A team uses it to assess where it stands, set a target for each practice and plan a roadmap.
References
- A06:2025 Insecure Design (OWASP Foundation)
- A09:2025 Security Logging and Alerting Failures (OWASP Foundation)
- A03:2025 Software Supply Chain Failures (OWASP Foundation)
- OWASP Software Assurance Maturity Model (SAMM) v2 (OWASP Foundation)
- ASVS 5.0.0: what is the ASVS (levels and tailoring) (OWASP Foundation)
- ASVS 5.0.0: requirement numbers and levels (OWASP Foundation)
- Dependabot options reference (cooldown) (GitHub Docs)
- About code owners (GitHub Docs)
- gitleaks README (pre-commit hook and baseline) (Gitleaks project)
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1 (NIST)
- 15 Elemental Cyber Defense Controls for Micro, Small and Medium Enterprises (MSMEs), version 1.0 (Indian Computer Emergency Response Team (CERT-In))
Related tools
Report a problem with this lesson
Kept only in this browser. Your Learn progress