JPJobPrepfull-stack interview
RoadmapsJS CompilerStar on GitHub
Career Roadmaps · AppSec

Career roadmap

Application Security Engineer

Stop vulnerabilities being written, not just found: reviews, tooling and secure defaults inside the development process.

Time
7-10 months part-time
Entry bar
Real development experience. This role reads and writes code daily.
Stages
5 · 25 topics
0/25 studied0%
All roadmaps

Before you start AppSec

  • Professional software development experience
  • Comfort reading code in more than one language
  • Understanding of web protocols and authentication

Vulnerability classes in depth

5-7 weeks · 0/5 topics

Know the mechanics well enough to spot them in code review, not just in a scanner report.

  1. Still the highest-impact class, and the one candidates explain least precisely.

    • SQL injection and parameterisation
    • Command and template injection
    • Deserialization vulnerabilities
    • XXE and parser configuration

  2. The most common serious finding in real applications.

    • IDOR and object-level authorisation
    • Function-level access control
    • Multi-tenancy isolation
    • Centralised authorisation design

  3. Getting login right is harder than it looks, and everyone builds it.

    • Password storage and credential stuffing defence
    • Session fixation and rotation
    • JWT pitfalls: algorithm confusion, expiry
    • OAuth and OIDC misconfiguration

  4. Same-origin policy, CSP and cookies — the controls that contain client-side flaws.

    • Same-origin policy and CORS
    • XSS variants and contextual encoding
    • Content Security Policy design
    • Cookie attributes and isolation

  5. Scanners never find these, which is precisely why the role exists.

    • Race conditions and TOCTOU
    • Workflow bypass and state manipulation
    • Price and quantity manipulation
    • Rate limiting and abuse cases

BuildWrite a deliberately vulnerable application demonstrating ten classes, plus the fixed version.

Secure design

5-6 weeks · 0/5 topics

Preventing whole classes of bug through design beats finding them one at a time.

  1. The highest-leverage AppSec activity, and a standard interview exercise.

    • STRIDE against a data flow diagram
    • Trust boundaries and assumptions
    • Abuse cases alongside user stories
    • Recording decisions and accepted risk

  2. Choosing and using primitives correctly, and spotting misuse in review.

    • Encryption at rest and field-level encryption
    • Key management and rotation
    • Signing, verification and replay protection
    • Common misuse patterns

  3. Hardcoded credentials remain one of the most common findings in real repositories.

    • Secret management services
    • Preventing secrets in version control
    • Rotation without downtime
    • Environment separation

  4. Making the safe path the easy path is how AppSec scales past one reviewer.

    • Framework security features
    • Secure library wrappers
    • Paved-road templates
    • Deprecating unsafe internal APIs

  5. Increasingly part of the role as regulation tightens.

    • Data minimisation and retention
    • PII classification and handling
    • Consent and deletion flows
    • Logging without leaking

BuildThreat model a real service and implement three of the resulting controls yourself.

Security testing and tooling

5-6 weeks · 0/5 topics

Automate what can be automated so human review goes where it matters.

  1. Useful when tuned, ignored when noisy. Tuning is the actual skill.

    • SAST tool selection and configuration
    • Writing custom rules with Semgrep
    • False positive triage workflow
    • Baseline and incremental scanning

  2. Most application code is third party. That is where much of the risk sits.

    • SCA and vulnerable dependency detection
    • Reachability analysis to cut noise
    • SBOM generation and use
    • Dependency pinning and update policy

  3. Testing the running application, including authenticated flows.

    • DAST in CI against a staging deploy
    • Authenticated scanning setup
    • API testing from an OpenAPI spec
    • Fuzzing inputs and parsers

  4. The core interview exercise: here is a diff, what is wrong with it.

    • Reviewing for authorisation gaps
    • Spotting injection sinks and taint flow
    • Reviewing cryptographic usage
    • Giving feedback developers act on

  5. Security that slows delivery gets disabled. Design for the developer's day.

    • Fast feedback and pre-commit hooks
    • Break-the-build criteria
    • Findings in the pull request
    • Exception and risk acceptance workflow

BuildAdd a security pipeline to a real repository with tuned tooling and a triage process.

Running an AppSec programme

4-5 weeks · 0/5 topics

One reviewer cannot cover fifty teams. The job becomes leverage.

  1. The framework that turns ad-hoc reviews into a repeatable programme.

    • Security requirements and design gates
    • Risk-based review triggers
    • Release criteria
    • Measuring programme coverage

  2. Scaling through embedded engineers is the standard answer, and interviews expect it.

    • Selecting and training champions
    • Keeping the network engaged
    • Escalation paths
    • Measuring impact

  3. Running the intake process for externally reported issues.

    • Disclosure policy and safe harbour
    • Triage and severity assignment
    • Researcher communication
    • Feeding findings into prevention

  4. Proving the programme works, in language leadership understands.

    • Mean time to remediate by severity
    • Vulnerability density and escape rate
    • Coverage of critical services
    • Reporting to leadership

  5. The cheapest long-term control, and the hardest to make stick.

    • Targeted training on real findings
    • Secure coding guidelines that get read
    • Hands-on workshops and CTFs
    • Onboarding for new engineers

BuildDefine a secure development lifecycle and get one team to adopt it end to end.

Interview preparation

3-4 weeks · 0/5 topics

AppSec interviews are code review, threat modelling, and deep protocol questions.

  1. The signature AppSec interview. Real code, real time pressure.

    • Finding the bug in an unfamiliar diff
    • Explaining exploitability clearly
    • Proposing a correct fix
    • Prioritising multiple findings

  2. Given an architecture diagram, identify threats and controls out loud.

    • Systematic coverage under time pressure
    • Prioritising realistic threats
    • Proposing proportionate controls
    • Handling incomplete information

  3. Expect protocol-level questions on TLS, OAuth and the browser model.

    • Explain OAuth flows and their risks
    • Same-origin policy and CORS precisely
    • How does CSRF protection actually work
    • JWT verification pitfalls

  4. You are an engineer first. Expect to write working code.

    • Implementing a secure primitive
    • Writing a Semgrep rule
    • Automating a security check
    • Tests that prove the fix

  5. The role is influence-heavy. Conflict stories are directly relevant.

    • Convincing a team to fix a finding
    • Blocking a release and the fallout
    • Handling a disagreement on severity
    • Building trust with engineering

BuildA public vulnerable-and-fixed application, plus a written threat model.

AppSec tools on your CV

  • Semgrep
  • Burp Suite
  • OWASP ZAP
  • Snyk / Dependabot
  • OWASP ASVS
  • Threat Dragon
  • GitHub Advanced Security

What AppSec employers ask to see

  • A vulnerable-and-fixed application with explanations
  • Custom static analysis rules you wrote
  • A published threat model for a real system
  • A security pipeline adopted by a real team

Sits between engineering and security, and is paid accordingly. Companies shipping their own software hire for it as soon as compliance or customers demand a secure development lifecycle.

Content last reviewed 2026-08-31. Guidance only — no institute or paid placement is endorsed anywhere in this book.