What belongs on an application security engineer resume?

Why is application security hiring heating up right now?

Because discovery just got automated and triage didn't. On 21 October 2026 the industry took three hits in a single day: two critical PHP remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 on CVSS v4.0 and both rooted in how PHP handles fatal out-of-memory errors; a Node.js security release patching ten vulnerabilities, four of them high severity across DNS, TLS and Brotli decompression; and a supply-chain compromise of the LiteLLM package that shipped a credential stealer and a dormant backdoor. The PHP pair was surfaced with help from frontier AI models by research teams at OpenAI and Google-owned Wiz. Hiring follows pain like that, and it follows it quickly.

The scope is what made the day ugly. PHP runs roughly 70% of websites, and the flaws reach back to version 5.4, so WordPress, Drupal and Joomla installations were all in range — unauthenticated remote code execution was demonstrated against current container images of all three, with passwords, tokens and API keys readable from process memory. Anything serving web requests was exposed, and Apache mod_php setups were worst off. Fixes landed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, plus source backports for the end-of-life 7.4, 8.0 and 8.1 branches. Government websites in Europe went dark while operators scrambled. Node.js shipped 26.12.1, 24.22.1 and 22.23.4 the same day.

Here's the hiring consequence most candidates miss. Automation is eating detection, not remediation. An analysis of more than 5,000 AppSec job postings in 2026 found roughly three mentions of scanners for every mention of a fix workflow, and the large majority of detailed descriptions framed remediation as coordination work between humans. Open roles reflect that: senior application security engineer bands around $111K–$144K base, product security engineer postings at $175K–$210K, and senior product security listings reaching $200K–$250K. Nobody pays that for someone who forwards a scan report. They pay for the engineer who decides what gets patched tonight, what waits, and how the fix ships without breaking the release.

What skills and tools must an AppSec resume name in 2026?

Name three layers explicitly: the languages you can read in production, the tooling you've configured rather than merely opened, and the frameworks you use to prioritise. In practice that means Python, Go, Java, TypeScript or C/C++ for code review; SAST and SCA wired into CI with Semgrep, CodeQL, Snyk, Trivy or Grype; Burp Suite and OWASP ZAP for grey-box web and API testing; secret scanning with gitleaks or TruffleHog; and SBOM work in CycloneDX or SPDX. Then the judgment layer — OWASP Top 10 and ASVS, CWE classes, CVSS, EPSS scores and the CISA Known Exploited Vulnerabilities catalogue. That last group is what separates a scanner operator from an engineer.

Supply-chain and pipeline detail now carries real weight, and the LiteLLM incident is exactly why. Say which CI platform you secured — GitHub Actions, GitLab CI, Azure DevOps — and whether you enforced artifact signing with Sigstore and cosign, pinned dependencies, or worked toward SLSA provenance levels. Name your threat modelling practice too: STRIDE sessions, pytm models, abuse-case workshops with product teams. If you built paved-road tooling so secure defaults shipped automatically, that belongs in a bullet, not buried in a skills list. Container and cloud specifics help as well: Kubernetes admission policies, OPA, IaC scanning on Terraform, and whichever cloud you genuinely know rather than all three.

Keep the block parseable. Use the heading "Technical Skills", group by category, and spell each acronym once — "SCA (software composition analysis)" — so a keyword filter and a human recruiter both get a match. Certifications earn a short line, not a banner: OSCP and OSWE dominate pentest-leaning AppSec postings, while CSSLP and GWAPT show up more in secure-SDLC and DevSecOps roles, and the highest-paying product security listings treat all of them as nice-to-have. My blunt opinion: one custom CodeQL query you wrote and shipped beats three certification acronyms. If you want the structure handled for you, a cybersecurity CV builder that puts certs, stack and incident work in the right order saves an evening of fiddling.

Skip generic security buzzwords entirely. "Security-minded", "passionate about defence" and "strong analytical skills" consume prime space and survive no scrutiny in a screen. Replace each with a concrete noun a hiring manager can interrogate: a rule you authored, a class of bug you hunted, a pipeline you gated, a service you threat-modelled before launch.

How do you list CVEs on a resume without breaching an NDA?

Give CVEs their own section — "Vulnerability Research and Disclosures" — and write one line each containing the CVE ID, the affected product and version range, the vulnerability class with its CWE, and your specific role. Something like: "CVE-2026-XXXXX — unauthenticated server-side request forgery in an open-source API gateway, versions up to 2.4.1 (CWE-918); discovered, reported and coordinated a 90-day disclosure." That single line tells a hiring manager you can find a real bug, write it up credibly and handle a vendor relationship without drama. Three good lines beat a list of twelve where you were the eleventh reporter on a duplicate.

No CVEs yet? Plenty of evidence counts. Bug bounty work with the platform named and severity tiers stated, security patches merged upstream into a library people use, published Semgrep or CodeQL rules, a write-up of an exploit chain, placing in a CTF with the category you carried. Be precise about credit — "co-reported with two colleagues" reads stronger than an implied solo find, because interviewers will ask and the truth surfaces in four minutes. Also resist padding with low-value findings: a wall of reflected XSS reports on forgotten subdomains signals volume-chasing, which is the opposite of the triage judgment these roles pay for.

Internal work under NDA is still usable, you just strip the identifiers. Describe the class, the blast radius and the outcome without naming the system, the customer or the exact stack: "found a pre-authentication authorisation bypass in a payments API during design review; blocked the release and drove a fix across four services in eleven days." Never paste internal ticket numbers, internal CVSS worksheets or customer names, and don't attribute a company's unpublished incident to yourself in writing. If a finding is still embargoed, say "disclosure pending" with the class and date, and keep the details for the conversation.

How do you quantify vulnerability management in resume bullets?

Quantify four dimensions — volume, time, coverage and signal quality — because those are the numbers an AppSec interviewer can actually probe. Volume is findings triaged per quarter and repositories in scope. Time is mean time to patch for critical and high severity, stated as a before-and-after. Coverage is the share of services onboarded to scanning, secret detection or SBOM generation. Signal quality is your false-positive rate after rule tuning, which is the metric most candidates never think to track and the one that most impresses a team drowning in alerts. Add a design-stage number if you have one: services threat-modelled before launch, issues caught pre-release.

Don't have the numbers? They exist, you just haven't pulled them. Jira and Linear hold ticket counts and cycle times. The GitHub security tab, your Dependabot or Renovate history and your DefectDojo instance hold finding volumes and closure rates. Sprint retrospectives and quarterly security reviews usually contain the coverage percentages someone else already calculated. Reconstruct conservatively, round down, and write only figures you'd defend under questioning — "roughly 300 findings a quarter" survives an interview, an invented 72% reduction with no baseline does not. If you're switching roles, do this archaeology before you lose access to the systems that hold it.

Two bullet patterns to retire. The first is the tool inventory: "used Burp Suite, Snyk and OWASP ZAP" names your login list, not your contribution. The second is the invisible verb: "helped improve the company's security posture" hides whether you led the work or attended the meeting. Rewrite both as a security decision with a consequence — what you found, what you changed, what it cost the release schedule, what the number was afterwards. If you want a second opinion on whether your bullets land, a free CV analysis that scores impact and ownership alongside ATS compatibility will tell you where your evidence reads as vague.

Keep percentages anchored to a baseline. "Cut critical findings 40%" means nothing without the starting count and the window; "cut open criticals from 85 to 51 across two quarters" is the same claim made verifiable, and verifiable claims survive reference checks.

How do you show you can review AI-generated code, not just scan output?

Show it as review work with named artifacts, the same way you'd show any other code review. Write the bullet around what you caught and how: the AI-authored pull requests you reviewed, the rule you wrote after spotting a recurring pattern, the guardrail you added to the pipeline. This matters because 2026 testing of AI code generation found roughly 44% of tasks produced code carrying a known vulnerability, with injection flaws and server-side request forgery dominating, and other research puts design flaws or known vulnerabilities in a majority of AI-written samples. Syntactically clean, semantically unsafe — which is precisely the review problem employers are hiring for.

Validating AI-found bugs is the other half, and the PHP disclosures proved why. When a model surfaces a candidate flaw, somebody has to reproduce it, judge reachability, write the proof of concept and decide whether it warrants an emergency patch cycle. Say so if you've done it. The AI toolchain itself is now part of the attack surface too: the LiteLLM gateway flaws this month included an authentication bypass in its MCP handling and remote code execution as root through custom guardrail code, alongside the compromised package build. Dependency pinning, provenance checks and hallucinated-package defences are AppSec work with a 2026 label on it.

Now the contrarian part: don't rebrand yourself an AI security engineer. Postings mention scanners three times more often than fix workflows, and "AI security" is simultaneously the most-asked-about and most-overstated hiring trend of the year. Keep the classic AppSec spine — code review, threat modelling, triage judgment, pipeline work — and let AI-related evidence sit inside it as two or three concrete bullets. If your current document is a 2019 file with new roles appended, rebuild it instead of patching it; an AI CV builder that exports an ATS-friendly single-column layout will get the structure right faster than wrestling a template, and single-column still parses most reliably.

Frequently asked questions