How to get hired as an application security engineer in 2026-27

What an application security engineer actually does, and which postings are really this job

The purpose of the role is to make shipping a vulnerability difficult and fixing one cheap. Everything else follows from that. A realistic week includes reviewing a design before any code exists, reviewing a small and carefully chosen set of pull requests rather than all of them, triaging the output of static analysis and dependency scanning, validating inbound bug bounty or penetration test findings, improving a shared library or CI check so a bug class stops recurring, answering 'is this safe?' in a chat channel for a few dozen engineers, and writing down one or two risk decisions that someone will read back to you in a year.

The thing that separates a strong candidate from an average one is the altitude of the deliverable. An average application security engineer produces findings. A strong one produces properties: tenancy enforced in the data access path so a handler cannot forget it, outbound HTTP available only through an egress proxy so server-side request forgery stops being reachable, a template layer that escapes by default, a build that fails on an unpinned dependency. Findings are consumed and forgotten. Properties persist after you leave, and interviewers listen specifically for whether you think in those terms.

Note the difference between application security and product security, because postings use both words. At a software-as-a-service company they are usually synonyms. At a company that ships hardware or firmware, product security is broader: memory safety in C and C++, secure boot and signing, hardware roots of trust, and a PSIRT function that receives external vulnerability reports and issues CVEs, often as a CVE Numbering Authority. If a posting mentions firmware, embedded or PSIRT, it is a different job with different interview rounds, and you should read it closely before tailoring anything.

Before you apply, work out which adjacent role the posting actually describes. The titles overlap in the market and the daily work does not.

• Penetration tester or offensive security engineer: a scoped, time-boxed assessment ending in a report. Overlaps heavily on vulnerability knowledge, differs on ownership. The AppSec engineer is still there three months later arguing about the fix.
• DevSecOps or platform security engineer: owns the pipeline, infrastructure as code, container and runtime posture, secrets infrastructure. Overlaps on CI, differs on whether anyone reads the application code.
• Cloud security engineer: identity and access management, account structure, workload identity, posture management. A posting that is mostly 'harden our AWS organisation' is this job, not AppSec.
• Security architect: sets patterns across many systems, reviews more and codes less, usually a level above and often a role you grow into from AppSec.
• Vulnerability management analyst: tracks, reports and chases findings produced by other people's tools. This is the job AppSec is sometimes wrongly reduced to, and a posting whose responsibilities are entirely dashboards and SLAs is honestly telling you what it is.
• Secure code reviewer at a consultancy: repeated, billable, broad exposure across many codebases, and no ownership of the fix. The fastest way to see a lot of code, the slowest way to learn what happens after a report lands.
• Software engineer on a security team: builds the authentication, authorization and cryptography services rather than reviewing other people's use of them. For a strong developer this is often the better paid and easier entry point, and it leads into AppSec naturally.
• Detection engineer and incident responder: work on what got through. You will hand them requirements, and a good threat model names the detections you want from them.

The two routes in, and what each one has to fix

Most application security engineers were developers first, and the reason is structural rather than cultural: the two interview rounds that decide the job both require reading code fluently under time pressure. If you can already do that, you own the expensive half of the skill set and the gap is a catalogue of attacks plus the judgement to separate plausible from exploitable. If you cannot, nothing else you do substitutes for it.

Understand the shape of the market before you plan. This role is structurally mid-level and above. Teams are small, often one application security engineer supporting anywhere from fifty to several hundred developers, and a team that size cannot absorb someone who needs a year of supervision. True graduate AppSec roles exist mainly at large technology companies, in rotational security programmes and at consultancies that hire in cohorts. Everywhere else the entry point is a software engineering job and the move happens afterwards. That is not gatekeeping, it is arithmetic, and planning around it beats applying into it.

Coming from development, the cheapest path is through your own employer. You already know the codebase, the deploy pipeline, the people and which service is held together with tape, which is most of what makes someone effective in their first year of AppSec. Ask the security team if you can sit in on design reviews, take the security champion role on your team if one exists, write three Semgrep rules for your own repository and show what they found, and volunteer to triage the scanner backlog for your service. Internal transfer is the most common route into this role and it skips the hardest part of the external loop, which is persuading a stranger in 45 minutes that you have judgement.

Coming from security operations, GRC, IT or audit, the gap is code and it is not optional. You will be handed a diff. Pick one language your target employers actually use (Java and TypeScript dominate enterprise, Python and Go dominate infrastructure-heavy shops, C# in Microsoft estates) and work until you can open an unfamiliar service and say, without help, where requests enter, where authentication happens, where authorization happens, and where data is read. Then build something small yourself with login, sessions and a database, because knowing what the mistakes feel like from the inside is what lets you rate severity rather than recite it.

Coming from penetration testing, the technical fit is immediate and the adjustment is cultural. Your interview failure mode is proving you are clever instead of helping the product ship. Collect evidence of fix work before you interview: a pull request you wrote, a library you hardened, a rule you shipped, a time you accepted a risk and said why. Hiring managers for AppSec have all met the candidate who reports a critical, refuses to help, and is never invited to a design review again.

Coming from QA, support or technical writing, the route is real but it runs through development first. Spend the time on the engineering job rather than on certificates; the certificates will not survive the code review round.

• From development, six markers that you are ready: you can explain the difference between authentication and authorization failures in your own codebase, you have read your service's auth middleware end to end, you have completed the access control and SSRF labs in PortSwigger's Web Security Academy, you have written a Semgrep rule, you have threat modelled a feature you shipped, and you can name one risk you accepted and why.
• From security operations, three markers: you can read a 300-line pull request in an unfamiliar framework and describe what it does, you have built and deployed something with a login flow, and you have found a real bug in someone else's code rather than in a scanner report.
• Do the PortSwigger Web Security Academy labs in full and in order rather than skipping to the exotic ones. It is free, it is exhaustive, and it is the de facto shared curriculum for this role, which means interviewers assume you know what is in it.
• Pick your target language before you train, not after. Reviewing Java Spring code and reviewing Express code require different instincts about where authorization lives.
• If your employer has a bug bounty programme, ask to help triage it. Reading other people's reports is the fastest way to calibrate what a real severity argument looks like.
• Local OWASP chapters and security meetups are where a disproportionate share of these roles get referred. Internal transfer and referral fill much of this market, so cold applications are the worst-performing channel available to you.

How hiring works, stage by stage, and how it differs by employer

The loop is reasonably consistent across software employers, and knowing what each stage screens for tells you what to prepare. The recruiter screen is keyword matching against the requisition plus a check on location, compensation and clearance. The hiring manager call is often the real filter: why AppSec, what you have shipped, and what you do when a team refuses to fix something. Then come the practical rounds, which are the ones people fail.

Two structural changes are worth knowing about going in. First, take-home exercises are being replaced by live shared-screen rounds at a growing number of employers, because a take-home no longer measures what it used to when assistance is one tab away. Expect to review code out loud with someone watching, and expect the exercise to be smaller and the questioning harder. Second, more employers now ask explicitly how you use AI assistance in your own work, and the question is not a trap: they want to hear a working practice with a verification step, not a refusal and not an enthusiasm.

The practical rounds are also where the role's split personality shows up. Half the interview is adversarial (find the bug, exploit it, rate it) and half is constructive (fix the class, design the control, convince the team). Candidates almost always prepare for the first half only, and then produce a fix in the code review round that would require every future engineer to remember something. That single answer separates mid from senior more reliably than any amount of vulnerability trivia.

Employer type changes the loop more than seniority does. A startup may make an offer in a week off two conversations and a short exercise, and the job will be AppSec plus cloud plus compliance plus whatever breaks. A large technology company runs five to seven rounds including a values or bar raiser interview and takes a month. A consultancy weights the writing sample heavily, because the deliverable is a document a client pays for. A bank or healthcare employer adds background screening and often a panel that cares about regulatory frameworks. Government and defence work is gated on clearance before anything technical matters.

• Recruiter screen, 15 to 30 minutes. Have a one-sentence version of what you do and one concrete thing you shipped. They are matching keywords, so your resume language should match the posting's language wherever that is honestly true.
• Hiring manager, 45 to 60 minutes. Expect: walk me through a vulnerability you found end to end including the fix; tell me about a team that did not want to fix something; what would your first 90 days look like here.
• Secure code review, 45 to 90 minutes live or two to four hours as a take-home. A small service or a pull request diff with planted flaws. Covered in detail below.
• Threat modelling or design review, 45 to 60 minutes. A system described verbally, a whiteboard or a shared document, and a ranked set of threats and controls expected by the end.
• Vulnerability depth, 45 to 60 minutes. Web and mobile fundamentals, exploitation mechanics, cryptographic misuse, and the authentication protocols: OAuth 2.x and the authorization code flow with PKCE, OpenID Connect, SAML, JWT validation, session management, and what actually goes wrong in each.
• Coding round at larger employers, 45 to 60 minutes. Usually Python or Go, usually tooling-flavoured (parse this, correlate these, build a small scanner), occasionally the standard software engineering bar including data structures.
• Cross-functional or influence round. How you get a fix landed without authority, how you handle a launch deadline against an unfixed critical, how you write a risk acceptance.
• Ask what the AI assistance policy is before you start a take-home, and follow it literally. Some employers now ask you to work unassisted, some ask you to use whatever you normally use and say what you used, and some replace the take-home with a live round for exactly this reason. Guessing wrong is an avoidable way to lose an offer.
• Values, leadership or bar raiser round at large employers. Prepare three stories with the decision you made in each, not just the outcome.

The secure code review round: what gets planted, and how it is graded

The exercise is usually a small web service with authentication, a database, some file handling and at least one outbound HTTP call, because that is enough surface to hide half a dozen defects without being unreadable. Expect a few hundred lines, or a pull request diff of one or two hundred, in Java with Spring, Node with Express, Python with Django or Flask, Go, or C# with .NET. Some of what is planted is deliberately not a bug, because they want to see whether you cry wolf.

The rubric is more consistent than candidates expect, and it is not a count of bugs found. Interviewers grade, roughly in this order: whether you asked about context before diving in, whether you found the access control bug, whether you avoided the decoys, whether your severity reasoning referenced reachability and blast radius rather than reciting a CVSS score, whether your fixes operate at the level of a control rather than a patch, and whether the way you said it would make the author defensive. A candidate who finds four of six defects with clear reasoning and systemic fixes beats a candidate who lists all six as critical with no argument.

Start with questions, and keep them to three or four so you are not stalling: is this endpoint reachable from the internet, is it behind authentication enforced somewhere I cannot see, is this multi-tenant, and what is the data. Then say out loud what you cannot determine from the code in front of you. 'If the gateway enforces authentication this is high; if it does not, this is critical and I would page someone' is a senior answer, and it is also honest, which in this round is the same thing.

The highest-value find is almost always broken access control, and it is planted deliberately because static analysis misses it. A handler takes an identifier from the request, fetches the object, and never checks that the caller owns it or belongs to the tenant. Pattern matching finds the ugly string concatenation; only a human who understands the application finds the missing check. If you spend 40 minutes on injection and never ask who is allowed to see this record, you have failed the round regardless of what else you found.

Below is the catalogue that actually gets planted. Learn the families rather than the instances, and for each one have a one-line systemic fix ready, because the follow-up question is always 'and how do you stop this happening again next quarter?'

• Broken object level and function level authorization: the request supplies an identifier and nothing verifies ownership or tenancy, or an admin-only route is protected only by the UI not rendering a link. Systemic fix: authorization in the data access layer, or a policy check a new handler inherits by default, never an if-statement bolted onto this one route.
• Injection: SQL built by string concatenation or f-string, command execution through a shell, server-side template injection, NoSQL operator injection through a JSON body. Systemic fix: a query layer that makes concatenation impossible, plus a CI rule so the next raw query fails the build.
• Server-side request forgery: the server fetches a user-supplied URL for a webhook, a logo, a preview or an import. Mention cloud metadata endpoints, internal admin services, and that naive URL validation loses to redirects and DNS rebinding. Systemic fix: a dedicated egress proxy with an allowlist, not a regular expression.
• Path traversal and unrestricted upload: a filename taken from the request, or from a database field that was originally user-controlled, joined onto a directory. Systemic fix: opaque server-generated identifiers, content type derived server-side, storage outside the web root or in object storage behind short-lived signed URLs.
• Insecure deserialization: Java readObject on untrusted bytes, Python pickle, .NET BinaryFormatter, unsafe YAML loading, or a JSON library configured with polymorphic type handling.
• Token and session handling: a JWT whose signature is not verified, an algorithm taken from the token header, a missing audience or issuer check, no expiry, no revocation path, a session token in a URL, a session that does not rotate on privilege change.
• Cryptographic misuse: ECB mode, a static or reused initialisation vector, MD5 or SHA-1 for passwords instead of a memory-hard function such as argon2id, bcrypt or scrypt, a non-constant-time comparison on a secret, tokens generated from a non-cryptographic random source.
• Race conditions and time-of-check to time-of-use on anything representing money or scarcity: balances, coupon redemption, invite codes, quota. Increasingly a standard plant, because it maps to real losses and tools do not find it.
• Mass assignment: a request body bound straight onto a model that has a role, tenant or is_admin field.
• Cross-origin and client-side trust: CORS reflecting the Origin header with credentials enabled, a postMessage handler with no origin check, an open redirect in the login flow which chains into OAuth token theft.
• Authentication surface: no rate limit or lockout on login, password reset or one-time-code endpoints, account enumeration through differing error messages or response timing, a reset token that is predictable or never expires.
• Secrets in source or in logs, and user input written unescaped into logs. The differentiating answer is not 'move it to a vault', it is naming the rotation, the blast radius and how you would find out whether the secret had already been used.
• Dependency and build issues: a pinned version with a known advisory, a lockfile the build does not actually enforce, a post-install script, an internal package name resolvable from a public registry.
• Deliberate non-issues: a missing security header on a JSON API, a verbose stack trace in a development configuration, a TODO comment. Call them out as low or not applicable and say why. Rating everything critical is itself a finding about you. One caution: a credential in a test fixture is only a non-issue once you have asked whether the value is real and whether those tests run against a shared environment. Asking is the right move; waving it away is not.

A worked code review, and what a strong answer sounds like

Take a concrete example of the kind of diff that gets handed over. A multi-tenant invoicing product adds an endpoint so customers can download an invoice as a PDF. The handler is decorated with a login_required check, takes the invoice identifier from the URL, runs a query built as 'SELECT * FROM invoices WHERE id = ' with that identifier interpolated into the string, joins the filename column from the resulting row onto an invoice directory, and returns the file. A second function in the same diff stamps the customer's logo onto the PDF by fetching a logo_url field from the customer record over HTTP.

The weak answer finds the SQL injection in ten seconds, declares it critical, and moves on. The strong answer starts with questions: is this internet-facing, is the login check doing anything beyond proving a session exists, is the invoice identifier sequential or a random token, and where did the filename column get its value. Those answers change the ranking entirely, and the interviewer is waiting to see whether you ask.

Then the ranked findings. First, missing tenancy enforcement: the login check proves the caller is somebody, not that they are the right somebody, so with sequential identifiers any customer who can sign up reads every invoice in the system. That is a cross-tenant data breach reachable by an ordinary user with no tooling, which is why it ranks first even though it is not the most impressive bug on the page. Second, the SQL injection, which reaches the same invoices plus everything else in the database and is the more severe technical flaw; both go out as critical, and you say plainly that the authorization bug is the one a customer will stumble into first. Third, path traversal through the filename column, if that value originated from a customer upload, which is stored input you cannot see in this diff, so you flag it as a question rather than a certainty. Fourth, server-side request forgery in the logo fetch, which is customer-controlled, server-side, and almost certainly able to reach the cloud metadata service. Fifth, the decoys: a missing cache control header on a sensitive response is worth a line, not a paragraph.

Then the fixes, and this is the part that gets you the offer. For the authorization bug, do not propose adding a tenant check to this handler. Propose that invoice lookups go through a repository function that takes the tenant from the request context and cannot be called without it, so the next handler someone writes inherits the check, and add a lint or Semgrep rule that fails the build on a direct invoice query outside that function. For the injection, the fix has the same shape: a query helper that only accepts parameters, plus a rule rejecting string-built SQL anywhere in the repository. For the file read, replace filenames with opaque identifiers and derive the content type server-side. For the logo fetch, route outbound requests through an egress proxy with an allowlist and say plainly that input validation alone will not hold.

Then say what you would do after the fix lands, because an interviewer who asks 'what next?' is testing whether you think in classes. Grep the repository for the same query pattern and count the other instances. Check whether a regression test exists for the tenancy check and write one if not. Check the logs for whether this endpoint has already been hit with identifiers outside the caller's tenant, which is an incident question rather than an engineering one and shows you know the difference. Ask whether a staging copy of production data exists, because that is where the same bug goes unnoticed for years.

Finally, say how you would write it up for the author. Two sentences, the impact in business terms rather than in vocabulary, a severity, a proposed timeline, and an offer to pair on the fix. The interviewer is one of the engineers whose code you would be reviewing, and they are listening for whether working with you would be pleasant.

The threat modelling round: how to run it out loud

The format is consistent. Someone describes a system in two or three minutes and you have about 40 to do something useful with it. Common prompts in 2026-27: we are adding file upload with scanning and preview, we are opening a public API to partners, we are adding a mobile app against the existing backend, we are letting customers install plugins, we are adding an assistant that can read customer data and take actions on their behalf, design our password reset. The last one looks easy and is not.

Run a visible loop, because the round grades process more than output. Ask three to five questions and then start drawing: what data is in play, which tenants and which users, what money or irreversible action is reachable, what regulatory regime applies, and what the blast radius is if the whole thing is compromised. Then draw the data flow rather than the org chart: components, data stores, the actual protocols, and the trust boundaries, which are the lines where something crosses from one level of trust to another. Internet to edge. Service to service. Application to data store. Tenant to tenant. First party to third party. Human to admin plane.

Work the boundaries, not the mnemonic. For each crossing, ask who can speak across it, what they are allowed to say, who checks, and what happens when the check is wrong. STRIDE is a fine checklist for catching what you missed, but a candidate who walks the diagram boundary by boundary sounds like a practitioner, and a candidate who recites spoofing, tampering, repudiation at the whiteboard sounds like someone who read a book last week.

Then rank, which is the step most candidates skip and the one interviewers care about most. Rank by who can reach it (an unauthenticated internet attacker is a different universe from a privileged insider), how hard it is to exploit, how large the blast radius is, and whether the control that currently prevents it is a property of the design or a habit people have. Say the ranking out loud and defend the top two. An unranked list of twenty threats is not a threat model, it is a vocabulary test you administered to yourself.

Propose controls at the right altitude and say where each one lives and who owns it. Prefer a property of the design to a rule people must remember: signed short-lived URLs rather than a reminder to check permissions, an egress proxy rather than URL validation guidance, tenancy in the query path rather than a code review checklist. Then say what you would accept and why, with the compensating detection, because an interviewer is specifically listening for someone who can accept risk out loud. The alternative is someone who blocks every launch, and that person gets routed around inside a month.

Close by naming what you want logged and alerted on, because prevention fails and the question 'how would we know?' separates people who have been on call from people who have not. Name the two or three events you would ask a detection engineer for: cross-tenant access attempts, bulk export, a privilege change made outside the admin console, an agent calling a tool it has never called before. Then say what you left out of scope and what you would follow up with a test rather than a guess.

• Ask before you draw, but stop asking after about four questions. Stalling reads as avoidance.
• Mark the trust boundaries explicitly on the diagram. A threat model with no boundaries drawn is the most common reason this round is failed.
• Do not forget the admin plane and internal support tooling. A large share of real breaches land through the back office, the impersonation feature, or a support agent's ability to read any account.
• Do not forget the non-production copy of the data. Staging with real customer records and weaker authentication is a standing finding at most companies and almost no candidate raises it.
• Treat the third party as a boundary, not a fact of life: what does the integration hold, what is its token scoped to, what happens when the vendor is compromised, and how would you turn it off.
• 'We should get it pentested' is not a finding. It is what you say after you have said what you think is wrong.
• Say the thing you are unsure about as unsure rather than hedging everything. Confident where you have grounds, explicit where you do not, is the tone that reads as senior.
• If the prompt involves an assistant or an agent, go straight to privileges and output handling rather than to prompt filtering. That is covered in the AI section below and it comes up often enough now to rehearse specifically.

The resume, the portfolio, and the credentials worth buying

A hiring manager reads the first four bullets of your most recent role and makes a provisional decision there. They are looking for a class of problem you removed, the scale you did it at, and whether you worked with engineers or at them. Everything else on the page is confirmation or noise. Rewrite those four bullets before you rewrite anything else.

Numbers help, but only ones you can defend in the room. Do not invent a percentage you cannot reconstruct. 'Cut the static analysis backlog by retiring rules that produced no true positives in six months and adding custom rules for our frameworks, which took us from a third of findings closed to most findings closed within a sprint' is better than a precise figure you will fumble when asked how it was measured. If you do not know the number, describe the shape and the method.

What gets ignored: a list of tools with no outcome attached, 'familiar with the OWASP Top 10', 'performed security assessments' with no scope, certification acronyms with nothing behind them, and capture-the-flag rankings, which are a mild positive at best for a defensive role. What gets read: the class of bug you removed, the control you shipped, the number of engineers you supported, the incident you handled, and the thing you decided not to fix and why.

The portfolio matters more here than in most security roles, because the interview is about judgement and judgement is hard to assert. One good artefact beats a dozen weak ones, and the most under-used artefact is a written threat model of a public, well-documented system: it costs a weekend, it demonstrates the exact skill the hardest round tests, and almost nobody produces one.

On certificates, be clear-eyed. Nothing is required. No general licence governs this work. The certificates vary enormously in how much they correlate with passing the interview, and the expensive ones are not automatically the useful ones. Check current pricing, prerequisites and exam format on the issuer's own page before paying, because all three change.

• Resume bullet shape that works: 'Replaced ad hoc SQL across N services with a parameterised data layer and a CI rule, removing SQL injection as a recurring class in our codebase.'
• Another: 'Built the design review intake for a 90-engineer organisation: wrote the risk rubric, reviewed designs before implementation, and took the median review turnaround under three days so teams stopped routing around it.'
• Another: 'Owned bug bounty triage: validated inbound reports, cut duplicate and invalid volume by rewriting the scope and the submission template, and drove three criticals from report to fix.'
• Burp Suite Certified Practitioner: practical, hands-on, web-focused, cheap relative to the rest, and taken seriously by practitioners because you cannot pass it by reading. The best first certificate for this role.
• OSWE, OffSec's Web Expert certification: white-box, source code to working exploit, the closest certificate in existence to what the code review round tests. Expensive and time-consuming, and worth it mainly if someone else is paying.
• GIAC GWEB and GWAPT: credible and well-constructed, priced for employer funding rather than for individuals. GIAC's secure programming certifications are offered by language and the lineup changes, so check what is currently available before planning around one.
• CSSLP: reads as secure development process and governance rather than hands-on skill. Useful in regulated and government environments, close to irrelevant in a product security interview.
• CISSP: an HR filter and a management-track signal, not a technical signal for AppSec. It also requires several years of verified experience for the full certification, so it is rarely the right first move.
• CompTIA Security+ and the US government baseline certification lists: relevant mainly where a contract requires a baseline. The approved lists and the directive wording change, so read the current contract or agency guidance rather than a summary.
• A cloud provider security specialty certificate helps when the posting is cloud-heavy, and does nothing for the code review round.
• A computer science degree is common and not required. The dominant signal in this role is code you can read and code you have written.

Where the jobs are, what to search, and a 12-week plan

Search more than one title. The same job is posted as Application Security Engineer, AppSec Engineer, Product Security Engineer, Software Security Engineer, and plain Security Engineer with application work buried in the responsibilities. At startups it is almost always just Security Engineer, and the posting will describe three jobs in one because you will be doing three jobs. At companies that ship software other people run, search PSIRT and vulnerability response as well.

Company job boards extract and read far more cleanly than aggregators, and Greenhouse, Lever and Ashby postings in particular carry the real requirements rather than a recruiter's summary. For US federal and defence work, USAJOBS is the route and the clearance determines the timeline more than anything on your resume does. For consultancies and assessment firms, applications are often open year-round and the bar is a timed code review plus a writing sample, because the deliverable is a document.

The uncomfortable fact is that cold applications are the weakest channel for this role. Internal transfers and referrals fill a large share of these jobs, because hiring managers are trying to buy judgement and judgement is easiest to verify through someone who has watched you work. Local OWASP chapters, security meetups, the open source projects you send fixes to, and the bug bounty programmes you report to all produce referrals. Treat them as part of the job search rather than as hobbies.

If you are starting from a development job with no security track record, 12 focused weeks is enough to be interview-ready for a mid-level role. The plan below assumes evenings and one weekend day, and it is deliberately weighted toward producing artefacts rather than consuming content.

• Weeks 1 to 3: work the PortSwigger Web Security Academy, in order, and finish the access control, authentication, SSRF, JWT, OAuth and deserialization tracks before touching anything exotic. Keep short write-ups as you go; they become your notes and your portfolio raw material.
• Weeks 2 to 6: pick one open source project in the language you will interview in and read its authentication and data access paths end to end. File one documented issue or send one fix. Reading a real codebase with intent is the exercise the code review round simulates.
• Weeks 4 to 7: write five Semgrep rules for a framework you know well, run them against three open source repositories, and publish the rules along with what they found and what they got wrong. The false positives are the interesting part, and saying so is the signal.
• Weeks 6 to 9: write and publish one full threat model of a documented public system. Boundaries drawn, threats ranked, controls with owners, risks explicitly accepted. This is the cheapest high-value artefact available to you.
• Weeks 8 to 10: take the Burp Suite Certified Practitioner exam if you want a certificate on the resume. It maps closely to the interview and it is hands-on, so preparing for it is not wasted time.
• Weeks 9 to 12: practise the live rounds out loud and timed. Review a real pull request from a public repository in 45 minutes while speaking your findings into a recording. Have someone describe a system and threat model it in 40 minutes on a whiteboard. Both rounds are performances and both get noticeably better after five repetitions.
• Throughout: rewrite the resume around classes removed rather than tools used, and ask two people who do this job to read it.
• Throughout: apply to a handful of roles early even if you are not ready, specifically to collect the interview formats. Finding out what a real code review round feels like in week 3 is worth more than another chapter of reading.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Application security
• AppSec
• Product security
• Secure code review
• Static application security testing
• SAST
• Dynamic application security testing
• DAST
• Software composition analysis
• SCA
• Application security posture management
• ASPM
• Reachability analysis
• Semgrep
• CodeQL
• Snyk
• Checkmarx
• Veracode
• Burp Suite
• OWASP ZAP
• Threat modelling
• Threat modeling
• STRIDE
• Data flow diagram
• Trust boundary
• Design review
• Security architecture review
• OWASP Top 10
• OWASP ASVS
• OWASP SAMM
• CWE
• CWE Top 25
• CVE
• CVSS
• EPSS
• CISA KEV catalog
• Broken access control
• Insecure direct object reference
• IDOR
• Authorization bypass
• Multi-tenant isolation
• SQL injection
• Command injection
• Server-side request forgery
• SSRF
• Cross-site scripting
• XSS
• Cross-site request forgery
• CSRF
• Path traversal
• Insecure deserialization
• XML external entity
• XXE
• Server-side template injection
• Race condition
• TOCTOU
• Mass assignment
• Open redirect
• CORS misconfiguration
• Session management
• OAuth 2.0
• OpenID Connect
• SAML
• PKCE
• JWT validation
• Cryptographic misuse
• Key management
• Secrets management
• HashiCorp Vault
• Secret scanning
• Secure SDLC
• Shift left security
• DevSecOps
• CI/CD security
• Policy as code
• Security guardrails
• Paved road
• Security champions programme
• Vulnerability management
• Bug bounty triage
• Penetration test coordination
• PSIRT
• CVE Numbering Authority
• Responsible disclosure
• Software bill of materials
• SBOM
• Supply chain security
• Dependency management
• SLSA
• Sigstore
• Artifact signing
• Java
• Spring
• Python
• Django
• Node.js
• Express
• Go
• C#
• ASP.NET
• TypeScript
• React
• Mobile application security
• API security
• GraphQL security
• Kubernetes security
• AWS security
• Azure security
• GCP security
• Infrastructure as code scanning
• Terraform
• Container security
• PCI DSS
• SOC 2
• HIPAA
• ISO 27001
• NIST SSDF
• NIST AI Risk Management Framework
• ISO/IEC 42001
• OWASP Top 10 for LLM Applications
• Prompt injection
• LLM application security
• AI agent security
• Model Context Protocol
• Security clearance
• OSWE
• Burp Suite Certified Practitioner
• GWEB
• GWAPT
• CSSLP
• CISSP

Mistakes that cost people this job

Questions people ask