Last updated: November 7, 2026
By Robert Ardell, Co-Founder and Strategic Advisor, KORE1
An application security engineer job description should name the languages to be reviewed, the developers covered, where the work arrives from, and who writes the fix, with 2026 base pay of $150,000 to $200,000 for mid-level and senior hires. The postings that reach our intake calls usually list three scanners and the OWASP Top 10 and stop there. Candidates learn which tools exist. They learn nothing about Monday morning.
On a Tuesday in March, a payroll software company in Salt Lake City posted its first application security role. Ten days later it had 118 applications and nine worth a phone call.
The posting named the OWASP Top 10, three scanners (Snyk, SonarQube, and a Burp Suite license somebody’s predecessor had bought), a SOC 2 Type II audit, and “excellent communication skills.” It skipped the job itself. Seventy-four developers, mostly C# and TypeScript. Two senior engineers hand-writing answers to customer security questionnaires, about thirty a quarter, because nobody else would and sales kept promising a reply inside five business days. A pen test report from the previous spring with 61 findings still open, the oldest eleven months old. “We figured the Top 10 would do the work,” the VP of engineering told our recruiter, a little sheepishly. It did the work of producing 118 résumés. Not the good ones.
The nine worth a call had mostly done this job somewhere else and could read between the lines. The other 109 had applied to a role that doesn’t exist, a generic security job with “application” stapled on the front. A SOC analyst. A GRC specialist. One very earnest recent graduate with four certifications and no commit history.
The rewrite took an afternoon, most of it spent in Jira. Languages by share of the codebase. The questionnaires, with a count. The 61 findings and the age of the oldest. One sentence on who writes fixes, which was the new hire for the shared authentication library and the owning developer for everything else. The second posting drew 34 applications and 12 calls. The company hired a product security engineer out of a Utah fintech at $168,000, and by her second month questionnaire turnaround had dropped from nine days to three, mostly because she wrote the answer library nobody had thought to write.
I’m writing this as someone whose company earns a fee when a hire goes through our application security engineer staffing practice, so weigh it accordingly. The template at the bottom doesn’t require that you ever call us.
Whether a company needs this role at all is a different question, and our guide to hiring an application security engineer takes it on, pay data and search plan included. The security engineer job description template covers the broader title in four archetypes. The DevSecOps engineer template is about pipelines and who can bypass a failed check. This page starts later, with a company that has settled on someone who works on code its own people write and is about to describe the seat in public.
What an Application Security Engineer Posting Is Actually Hiring For
An application security engineer finds and prevents security flaws in software a company writes itself, working through design review, code review, testing, and the handling of reported vulnerabilities. The job sits closer to software engineering than to a security operations center, and its output is fixed code and safer designs more than reports.
I went looking for a count of application security engineers and found that the Bureau of Labor Statistics doesn’t keep one. The nearest category, information security analysts, had a median wage of $129,180 in May 2025 across 190,650 jobs, and it holds SOC analysts watching alert queues and compliance staff writing policy alongside the engineers who read code. Software developers, the same month, had a median of $135,980 across 1,687,890 jobs (BLS occupational wage tables). Two things jumped out. There is one analyst for every nine developers across the whole field of security, SOC included, so a thin ratio at a given company is the market and not an oversight. And the developers most likely to become application security engineers would be moving to a category that pays $6,800 less at the median than the job they hold now.
Titles are a mess. Product security engineer, software security engineer, AppSec engineer, and candidates search for all three. What has worked when we rewrite a posting is one title in the headline and the other two in the first paragraph.
Describe the Queue, Not the Duties
An application security engineer’s week is a queue, and almost none of it is self-assigned. Design reviews come from product teams. Escalated pull requests come from developers who aren’t sure about a regular expression. Questionnaires arrive from sales by way of a customer’s procurement office, and pen test findings arrive as a vendor’s PDF. A duties list (“conduct secure code reviews, perform threat modeling”) has room for all of it and says nothing about how much there is, which is the first thing a good candidate asks.
| Where work arrives | Count it by | How it reads in the posting |
|---|---|---|
| Design reviews and threat models | New services and big changes reviewed per month | “About 15 design reviews a month, mostly new services and changes to authentication.” |
| Pull requests sent to security | Escalations per week | “Developers tag you on roughly 25 pull requests a week. Most take under ten minutes.” |
| Scanner findings that need a human | Open findings, and the age of the oldest | “Static analysis shows about 2,300 open findings. Nobody has triaged them since the engineer who set it up left.” |
| Customer questionnaires and vendor assessments | Per quarter, and hours each | “About 30 customer security questionnaires a quarter. Each now costs a senior engineer four to six hours.” |
| Reported vulnerabilities | Reports per quarter, plus the open pen test backlog | “Two or three real reports a month through the disclosure inbox, and 61 open items from the last pen test.” |
| Incidents that begin in code | On-call rotation | “On call for application incidents one week in four.” |
The middle column came from the Salt Lake team’s calendars and ticket export. Asked how many design reviews they did a month, the engineers said “a few.” Jira said 15.
The fourth row was the one the hiring manager wanted to cut. Questionnaires, he argued, weren’t a security task. He was half right. They’re a sales-support task that lands in security because the security team is the only group that can answer question 14 of a 200-line spreadsheet (“Describe your SDLC security controls”) without walking down the hall to ask someone. Some arrive as the Cloud Security Alliance’s CAIQ or the Shared Assessments SIG, and some arrive as a customer’s own invention. The new hire becomes the person who knows how the application works, so the work finds them inside a month. At the Salt Lake company it ran about a third of the week, and the engineer they hired told us afterward that she would have liked to know before the second interview, not after the offer. Postings that hide the questionnaires let candidates find out in week three, from a colleague, over lunch.
Headcount mattered too, though it never needed a row. A first application security hire among 74 developers is a different job from the fourth among 400. I’ve known engineers who waited years to be the first and engineers who did it once and swore it off, and a posting that stays quiet about the numbers attracts both and sorts them out at the offer stage.
Languages by Share of the Codebase
Application security skill is annoyingly language-specific. A reviewer who lives in Java and Spring will spot an unsafe Jackson deserialization from across the room, then read a Go service for a week without noticing that text/template was used where html/template belonged. The Node engineer next to them keeps finding prototype pollution in code the other two would read as fine. The failure patterns and the framework defaults all differ. When we rewrite a posting, the languages go in as shares of production code, largest first. The Salt Lake director of engineering produced his from a repository language report in about ten minutes. “About 55 percent TypeScript on Node and React, 30 percent C# on .NET, 10 percent Python, and the rest Terraform” matches a résumé in four seconds. The sentence it replaced, “experience with modern programming languages,” matched nothing, and I still see it constantly.
Then comes the standard. The OWASP Application Security Verification Standard reached version 5.0.0 on May 30, 2025, and it keeps a three-tier model, which gives a customer’s security team an easy way to ask a vendor how deep its testing goes. I tell clients to name the level, because it gives a candidate something to check against their own experience. Where reviews run against nothing in particular, I tell them to say that too, and to say the choice belongs to the new hire. A fair number of strong candidates want exactly that job.
Who Writes the Fix
Three different jobs get posted under this one title, and they attract different people.
| Version of the seat | What happens to a finding | Who applies |
|---|---|---|
| Finder | The engineer ranks it and files it. The owning team fixes it on the schedule in the remediation policy. | Penetration testers and code auditors, mostly |
| Fixer for shared code | The engineer owns authentication, cryptography and input handling and patches those directly. Everything else goes to the owners. | Software engineers who moved toward security |
| Builder of defaults | The engineer writes the libraries and checks that make a whole class of bug impossible to ship, and reviews less. | Platform-minded engineers, some from DevSecOps |
None of the three is wrong. Mixing them is the problem. “Secure code review” is a Finder phrase, “remediate vulnerabilities” is a Fixer phrase, and “build security tooling” is a Builder phrase. A posting with all three in the first six bullets describes three people.
A telehealth company in Nashville used the word “remediate” twice in its posting. The hiring manager meant “get the owning team to fix it.” Candidates read it as “fix it.” The engineer the company hired, a former backend developer from Franklin, Tennessee, asked in her first week for write access to the patient portal repository. The director of engineering said no. Nobody had ever thought about it. Five months later she took a job where she could merge to the authentication service, and Nashville started over with a posting that spelled it out, in plain words, “You do not merge to product repositories. You review, rank, and sit with the owning team until it’s fixed.”
The second posting drew fewer applicants. They were the right ones.
Name the Standard and the Clock
I’ll skip the framework tour, because two documents are all that come up whenever a federal buyer or a large enterprise customer is involved. NIST’s Secure Software Development Framework, SP 800-218, is one. Version 1.1 has been final since February 2022, and version 1.2 has sat in draft since December 17, 2025, with NIST’s publications page still listing it that way. Its four practice groups are Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities, and the practices an application security engineer touches most sit in two of them. PW.2 is design review, PW.7 is code review, and RV.1 through RV.3 cover finding, ranking, and root-causing vulnerabilities. OWASP SAMM is the other, a model that scores a program across five business functions and fifteen practices, among them Threat Assessment, Architecture Assessment, and Defect Management. Companies already running it say so on the first call. I’ve learned not to push it on the ones that aren’t, since a maturity-model project written into a posting is something the new hire discovers in week two.
The other document is a clock. For any company that sells a product with software in it into the European Union, the Cyber Resilience Act changed this job on September 11, 2026. From that date, according to the European Commission, manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA’s Single Reporting Platform. The early warning is due within 24 hours of becoming aware. A fuller notification follows within 72 hours, and the final report lands no later than 14 days after a fix is available.
A Minneapolis maker of building-automation software told us in October that nobody owned that clock. Legal assumed engineering did. Engineering assumed security did, and security was two people who had never been told. The application security engineer they were hiring would own it by default, they realized, about three weeks before the first interview. The posting changed that afternoon.
Pay Sits Where the Queue Puts It
| Source | Figure | What it covers |
|---|---|---|
| KORE1 security engineer salary guide | $135,000 to $200,000 base | The application security specialization across experience levels |
| KORE1 hiring guide | $150,000 to $200,000 base | Working band for mid-level to senior hires outside the top-paying metros |
| BLS, May 2025 | $129,180 median | Information security analysts, the closest federal occupation, SOC and policy staff included |
Our own numbers disagree with each other, and I’d rather show that than smooth it over. The hiring guide spends a few hundred words on why published sources for this role diverge by more than $100,000, and the short version is that they count different jobs under one search term. Averaging them describes nobody. Our application security engineer salary guide takes the wider view, $105,000 to $250,000 in base, by how many lifecycle stages a seat owns.
A working developer is the likeliest hire, and the BLS median for software developers in May 2025 was $135,980, so a band that opens below that asks the best candidates to take a pay cut for a harder job. Where a seat lands inside the band depends on the queue that got counted. In Salt Lake the offer came in at $168,000 with 74 developers, thirty questionnaires a quarter, and no reporting clock. A seat serving 400 developers with a European clock attached would sit near the top of the range. A seat serving 40, with tooling somebody already tuned, would sit near the bottom, and neither number would be wrong. I told the Salt Lake team to print the range, because several states require it for jobs located there and because a missing range tells candidates in this field that finance and the hiring manager haven’t settled it. Our free salary benchmark tool gives finance a defensible opening figure for a given metro.
Application Security Engineer Job Description Template
Every bracket below has a real number behind it somewhere in a ticket system, a repository setting, or an HR file. Anything marked “Hiring manager only” is a note to the person writing, and it comes out before the posting goes live.
Job Title
[Application Security Engineer / Senior Application Security Engineer / Product Security Engineer] ([first language], [cloud or platform], [N] developers) [Hiring manager only. The parenthetical is the first filter. Put the main language and the developer count in it.]
The Team and the Code
[Company] builds [product] for [customers]. [N] developers on [N] teams write about [N] percent [language], [N] percent [language], and [N] percent [language] across roughly [N] services. This seat is our [first / second / Nth] application security engineer and reports to the [Director of Engineering / Head of Security / CISO].
Where the Work Comes From
In a typical month you will see about [N] design reviews, [N] pull requests developers escalate to security, [N] customer security questionnaires, and [N] reported vulnerabilities. Today [N] findings are open in [tool], the oldest from [month and year]. [Hiring manager only. Pull every number from your ticket system. A rough guess reads as a rough job.]
The First Six Months
- Run threat models on [the N highest-risk services / the new payments flow] and leave behind a template other teams can reuse
- Triage the open backlog down to findings someone can act on, starting with code that is [internet-facing / handling payment or health data]
- Cut questionnaire turnaround from [N] days to [N] by writing and maintaining an answer library
- Review the pull requests developers escalate in [language], and explain the reasoning so the same flaw doesn’t come back
- Take ownership of [the authentication library / session handling / input validation helpers]
- [Run our vulnerability intake, including the 24-hour reporting clock under the EU Cyber Resilience Act]
Who Writes the Fix
[You write patches for [named shared code] and open pull requests against everything else. / You review and rank, and you stay with the owning team until each finding is fixed. You do not merge to product repositories.] [Hiring manager only. Pick one. If the honest answer changes by service, say which services.]
What You Bring
- At least [N] years writing production software in [language], enough to review a pull request in a framework you haven’t used
- Secure code review that finds the flaws scanners can’t, such as broken authorization when two features interact
- Threat models you ran with engineering teams, and the mitigations that got built afterward
- Working knowledge of [OWASP ASVS / NIST SSDF / OWASP SAMM], whichever we review against
- Comfort telling a team its feature has a flaw, and telling a VP the flaw isn’t bad enough to hold a release
Optional
- [OSCP / GWAPT / CSSLP] [Hiring manager only. These are tiebreakers and should never be requirements.]
- Prior work under [PCI DSS / HIPAA / FedRAMP / the Cyber Resilience Act]
- Experience reviewing AI-assisted code and tuning the checks that cover it
Pay, Location, and Standards
Base salary of $[low] to $[high], plus [an N percent target bonus / no bonus] [and equity, if any]. [A sentence on health coverage, retirement, and time off.] [Remote within [time zones or states] / hybrid at our [metro] office [N] days a week.] Our reviews follow [ASVS level N / SSDF / no formal standard yet, and you will propose one]. [Hiring manager only. Where the range is required by law, the benefits summary usually is too.]
Questions Hiring Managers Ask Before They Post
Application security engineer or product security engineer, which title do we post?
Post application security engineer, because that is the phrase candidates search for, and mention product security engineer in the first paragraph so the other half of the market finds you too.
I’ve never seen the two titles describe different jobs at a software company. At one that ships on a device they do, because firmware and supply chain come with the longer title.
Does a senior developer who “likes security” count as a candidate?
Often the strongest one, as long as the posting says the work is mostly design conversations and code review and not scanner reports.
In my experience a developer with six years in the stack and a few threat models behind them can beat a career security hire in the first year, because they already know where the code is ugly. The posting only has to promise the security training. Internal moves cost less than anything we sell, and I’d say so even if the fee were larger.
Should the posting say anything about AI-generated code?
One line, yes, saying who reviews AI-assisted pull requests and whether the engineer is expected to tune the checks that cover them.
When I ask a hiring manager how the team reviews code written with Copilot or Cursor, the pause tells me most of what I need. Developers at plenty of companies use those tools whether or not policy permits it, and candidates ask the same question on the first call. A posting with the answer already printed saves a round of that conversation.
We sell into Europe. What changes in the posting?
Add the Cyber Resilience Act reporting clock. Since September 11, 2026, manufacturers have had to send an early warning within 24 hours of learning that a vulnerability is being actively exploited.
The 72-hour notification and the 14-day final report follow, all through ENISA’s platform. We’ve started telling clients to name the person who owns the clock in the posting. Candidates who have run an incident process before spot it and apply, and the rest at least know what they would be signing up for.
Contract or direct hire for this seat?
Direct hire for a standing queue of reviews and questionnaires, contract for bounded work with an end date, such as a pre-audit review or clearing a backlog.
Plenty of contract engagements turn into permanent seats once a company sees what the queue looks like with someone working it. We run both through our direct hire and contract staffing practices. KORE1 fills IT searches in 17 days on average, and 92 percent of the people we place are still with the client twelve months later.
How many developers can one application security engineer cover?
No ratio holds across companies, so anyone quoting you one is guessing. Count the monthly queue, and when it fills more than a full week, you are hiring a second engineer.
The ratio moves with how much revenue rides on customers trusting your security, how old the codebase is, and whether the engineer also owns the questionnaires. A fintech and an internal HR tool with the same headcount don’t need the same coverage, and I’d be suspicious of a vendor deck that says they do.
Count the Queue Before You Write a Word
The Salt Lake company’s first draft took forty minutes and said nothing. The second took an afternoon, mostly in the ticket system, and drew people who already knew what they were walking into. That’s the whole trick. I wish it were more interesting.
Once a posting is live, our application security engineer interview questions pick up where it leaves off, the security engineer interview questions cover the wider role, and the cybersecurity staffing page lists the other security roles we fill. Once the numbers are in, send the draft to our recruiters, who will read it as a candidate would and say which engineers it is likely to pull in.
