Resumes for Security Engineers
Security engineering has two resume problems at once. The interesting work is usually the work you are least allowed to describe, and the successful outcome is an attack that did not happen. Neither fits a template built around shipped features.
The result is a genre of resume that reads as either a compliance checklist or a tool roster: SAST, DAST, Burp, Nessus, SIEM, SOAR, and a line about “hardening”. None of it tells a security reviewer whether you can find a real bug or stop a real one.
First, say which security you do
The field is at least three jobs, and reviewers hire for one of them:
- Offensive — application testing, red team, exploit development, research. Judged on what you found and how.
- Defensive — detection engineering, incident response, threat hunting, log and telemetry work. Judged on what you would catch and how fast. If you have a specific response worth describing, the bullet about an incident covers the shape, with the caution below about what a security incident must not disclose.
- Product and platform security — building the controls: authentication and authorisation systems, secrets handling, tenancy isolation, supply-chain and build integrity, paved-road libraries other engineers use. Judged as software engineering with a security specialism.
A resume that averages all three reads as none of them. Put the answer in the summary line and let the bullets stay consistent with it: “application security, mostly manual review and authorisation logic in Go and TypeScript services” is a position. “Cybersecurity professional with experience across the security lifecycle” is not.
The confidentiality problem has a standard solution
You cannot name the client, the system, or the unpatched detail. You can almost always name the class of the bug, the mechanism of the fix, and why it was possible — which is the part a reviewer wanted anyway.
Weak, and also a confidentiality risk: Discovered critical vulnerability in client payment portal allowing account takeover.
Stronger, illustrative: Found a chain in a payments web application where a server-side session was rebuilt from a client-supplied identifier after step-up authentication, so a valid low-privilege session could be upgraded. Reported with a reproduction, and worked with the owning team on a fix that moved the privilege decision server-side rather than filtering the input.
The second version discloses no system and no live weakness, and it shows something the first cannot: you understood why the bug existed. Reviewers read the second one as evidence and the first one as an assertion.
The same discipline applies to defensive work. Describe the detection logic and the evasion you had to handle, not the internal hostnames.
A finding is not the accomplishment
The most common structural mistake on a security resume is a list of findings. Findings are the input. What a hiring team wants to know is what happened next.
Three things worth more than the finding itself:
The fix that removed the class. “Added a linter rule and a request-scoped authorisation helper so the pattern could not be reintroduced” is stronger than any single bug report, because it scales past you.
The thing you got other engineers to do. Security work is mostly persuasion carried out by technical means. A paved-road library that teams adopted because it was easier than the unsafe path is a real achievement, and it is invisible on most security resumes.
The measurement you set up. If you built the means to know how many services were on the safe path, say so. Coverage of a control is a much better story than a count of tickets closed.
Numbers, in a field that invents a lot of them
Security marketing has trained everyone to expect big percentages, and almost none of them survive a question. Use the figures your tooling genuinely produced and describe the rest structurally.
Defensible, if you had the dashboard: patch or remediation times for a defined severity band, the number of services onto a control, the count of production secrets removed, alert volumes and false-positive rates on a detection you owned. Not defensible: risk reduced by a percentage, breaches prevented, money saved. If another engineer asked how you measured it, you could not answer the second set at all — the standard from when the numbers belong to another team.
Severity ratings are worth a note. “Critical” means what a particular scoring system and a particular customer decided it meant. Say who rated it, or describe the impact in one clause instead.
Public artefacts, used properly
Security is one of the few specialisms with genuinely verifiable public work: advisories you authored, CVEs credited to you, a tool other people use, conference talks, write-ups of bugs that are now fixed and disclosed.
Link them, and understand what a link proves — the reviewer will read it as your writing sample and your judgement sample, not as a trophy. That is the argument in what a link to your code actually proves, and it applies twice over to a disclosure write-up, where a reviewer is also watching how carefully you handled the disclosure.
Two cautions. A credited CVE in a dependency nobody uses is a weaker signal than a careful write-up of an ordinary authorisation bug, and reviewers know the difference. And a bug bounty history is a strong signal only if you can talk about the interesting reports rather than the volume; a large number of low-severity duplicates reads as scanning.
Certifications, briefly
Certifications carry very different weight across employers — heavily in government, defence, and regulated consultancies, lightly in product companies where practical work is the signal. Because the variation is real, list them plainly in their own line and let the experience section do the arguing. A practical certification that involved building or breaking something can also be described by what you did in it, which converts it from a credential into evidence.
Where security work belongs when it isn’t your job
Plenty of ordinary engineers do real security work and describe it badly. If you led an authentication rewrite, added tenant isolation, or fixed the way the service handled tokens, that is a security bullet inside a software engineering role and it should read as engineering: the problem, the mechanism, the constraint.
What does not work is claiming a compliance exercise as security engineering. Producing evidence for an audit is legitimate work, but write it as what it was — an evidence and process exercise — rather than as a control you designed. A security reviewer will separate those in the first minute of a call, and it is much better if your resume did it first.
The check
Cover the technology names on your resume and read what is left. Security resumes carry the longest tool rosters of any specialism, and the roster has the same weakness it has everywhere else — see the tech stack list problem. If the remaining text still says which security you do, one bug class you understand deeply, and one control you made harder to bypass, the page works.
If covering the tool names leaves a compliance summary, the specific material is missing — and it is almost certainly material you are allowed to describe, once you describe the mechanism rather than the system.