Certificate
A wrap-up screen for the OWASP track.
OWASP skills + portfolio checklist
EXAMPLE
# ===== Skills checklist ===== # After the OWASP track you should be able to: # [x] Name the Top 10 + the one-line fix for each category # [x] Run a security code review on a feature in 15 minutes # [x] Identify common bug patterns (sinks, missing checks, weak defaults) # [x] Write CI rules (Semgrep / ESLint) that prevent regressions # [x] Design an authentication flow with MFA + session rotation # [x] Validate inputs + escape outputs in the right context # [x] Set defensive headers (CSP, HSTS, secure cookies) # [x] Configure least-privileged DB roles # [x] Plan + run an incident response (see owasp/incident) # [x] Ship an SBOM + a dependency-update pipeline # [x] Run an annual pen test OR a bug bounty programme # ===== Bookmark ===== # - https://owasp.org/www-project-top-ten/ # - https://cheatsheetseries.owasp.org/ the practical reference # - https://owasp.org/www-project-asvs/ Application Security Verification Standard # - https://owasp.org/www-project-samm/ Software Assurance Maturity Model # ===== Portfolio project (8-16 hours) ===== # Audit a real (small) open-source app — your own or a friend's: # 1) Threat model the data flow (STRIDE) # 2) Walk the Top 10 with the cheatsheet # 3) Ship at least one fix per category found # 4) Add CI rules that block regressions (Semgrep + ESLint) # 5) Document the review + fixes in a SECURITY.md # 6) Open issues for items deferred (with grading) # 7) Recommend an incident playbook tailored to the project # Bonus: # - Pair with a colleague; review each other's commit history # - Submit findings via responsible disclosure (with permission) # - Write a blog post on lessons learned # ===== What 'good' looks like ===== # - SECURITY.md exists with the reporting channel + supported versions # - CI blocks risky patterns (eval, raw SQL, dangerouslySetInnerHTML, etc.) # - Cookies HttpOnly + Secure + SameSite=Lax # - CSP + HSTS + X-Frame + Referrer-Policy headers set # - argon2id for passwords; MFA available # - Dependency updates landed in the last week # - Incident playbook in the repo + at least one tabletop drill done # ===== Common mistakes to avoid ===== # - 'We patch later' culture -> patch latency is the breach metric # - Security tickets always deprioritised -> they accumulate; pay periodically # - Pen test as a one-off -> annual cadence at minimum # - 'Production has different code' -> staging must mirror prod # - Tests for happy paths only -> add tests for the bug class you fixed # ===== Next steps ===== # - Take the OWASP ASVS verification level for your app # - Set up a bug bounty programme (HackerOne / Intigriti) # - Threat-model every new feature for 20 minutes # - Read 'Building Secure & Reliable Systems' (Google SRE) # ===== Self-test ===== # If you can: # 1) Walk a junior through a SQLi review in 15 minutes and ship the fix # 2) Tabletop an incident: detect -> contain -> eradicate -> learn # 3) Justify each header in your Content-Security-Policy to a stakeholder # you have completed the track. Ship the audit and call it done. # ===== Track wrap-up ===== # OWASP is the floor, not the ceiling. The realistic posture for a small team: # - Parameterised SQL, escaped output, argon2id passwords # - CSP + HSTS + secure cookies as defaults # - CI rules that prevent the bug class # - Dependabot + weekly review # - Backups (off-host, encrypted, restore-tested) # - Incident playbook + quarterly drill # Reach that and you are ahead of most teams.
Why it matters
Treat each Top 10 category as a CI rule, a unit test, or both. The next reviewer who would have re-introduced the bug fails the build instead of shipping; the class of vulnerability gets harder to land over time. After a couple of quarters of that habit, your security posture is the byproduct of "trying to get a green PR".
Tip: Tweak the snippet with Try it Yourself », then sit the quiz at the bottom of the page.
Discussion
Loading…