Last updated: September 1, 2026
By Mike Carter, Director of Partnership Success, KORE1
An application security engineer secures the code your own company writes, and in 2026 that means owning dependencies and build pipelines as much as reviewing source, because supply chain failures now rank third on the OWASP Top 10.
Pay lands between $150,000 and $200,000 for most mid-to-senior hires in US markets. The published sources disagree violently about that number, by more than $100,000, and I will get to why, because the disagreement turns out to be useful rather than annoying.
The money is not what breaks these searches. What breaks them is that most application security reqs on the market right now were written against a list that expired. Expired last year.
The List Changed and Your Job Description Did Not
OWASP published the Top 10:2025 after four years without a revision, and the update was not cosmetic. Software Supply Chain Failures entered at number three, widening the old “Vulnerable and Outdated Components” category to cover compromised dependencies, malicious packages, tampered builds, and insecure update channels. Mishandling of Exceptional Conditions arrived at number ten. Server-Side Request Forgery vanished as a standalone entry and folded up into Broken Access Control at number one. The ranking came out of data covering more than 2.8 million applications and roughly 175,000 CVE records mapped across 248 CWEs.
Read that list against the average job posting and the gap is obvious. Postings still lead with injection, cross-site scripting, and secure code review. Those are real. They are also the parts of the job that a static analysis tool has handled reasonably well for a decade. Table stakes now.
The work that moved is the work nobody scoped. Somebody has to know which of your 1,400 npm packages actually reach production, whether your build runners can be tampered with, and who signed the artifact that shipped last Tuesday. Somebody. Not everybody.
Verizon’s 2026 Data Breach Investigations Report, published in May, put vulnerability exploitation ahead of stolen credentials as the leading way into a breach for the first time in the report’s nineteen-year run. Thirty-one percent of breaches. Third-party and supply chain breaches climbed sixty percent over the same period and now account for nearly half the total.
The category OWASP just promoted and the category Verizon just measured are the same category. Two independent datasets, one conclusion. Act on it.
Four Titles Land in the Same Resume Pile
Post “application security engineer” and you will get four distinguishable populations of candidates, all of whom describe themselves accurately. The sorting problem is yours, not theirs. Entirely yours.
| What they call themselves | What they do all day | Hire them when |
|---|---|---|
| Application security engineer (product security) | Threat models a design, reviews the risky pull requests by hand, triages what the scanners produce, sits with the team that wrote the bug | You ship your own software and want defects caught before release |
| DevSecOps engineer | Builds security gates into CI/CD, owns scanner configuration and policy, handles secrets management and build provenance | The pipeline is the bottleneck and manual review does not scale |
| Penetration tester (offensive security) | Attacks a finished thing on a schedule, writes the report, hands it over | You need periodic validation, or a customer contract requires it |
| Security engineer (infrastructure) | Network, identity, endpoint, cloud posture, detection tooling | The risk you are worried about lives outside your codebase |
The third row is where budgets disappear quietly. A penetration tester is a genuinely valuable hire and a genuinely poor substitute for the first row, because the deliverable is a document rather than a fix. We placed a senior application security engineer at a logistics software company in Denver last spring who spent his first month doing nothing but working through two years of accumulated pentest reports. One engineer, one month. Ninety-one open findings when he started. Fourteen when he finished, and roughly thirty of those closures were duplicates or things that had been fixed years earlier and never marked. Nobody had owned the list.
Check yours. If your ratio of findings to fixes looks anything like that, another testing vendor is not the purchase.
For the pipeline-first version of this problem, our guide to hiring a DevSecOps engineer covers the second row in detail. Our cybersecurity staffing practice runs all four of these searches, and the intake call usually spends more time on which row you need than on anything else.
Nobody Agrees on What This Pays
Here is where the compensation research gets strange, and the strangeness is instructive. The spread is the point.
| Source | Figure | What it is actually measuring |
|---|---|---|
| Salary.com (August 2026) | $96,763 median base | Posted base pay across all seniority levels, heavy on generalist and compliance-flavored titles |
| Indeed (August 2026, 476 reported salaries) | $149,703 average base | Base pay drawn from job postings, spanning $100,378 to $223,266 |
| Levels.fyi | $204,000 average total compensation | Security software engineers, self-reported, weighted toward large technology employers that grant equity |
| O*NET, US Department of Labor (2025) | $129,180 median | Information security analysts, the federal occupation code this role reports under |
A $107,000 spread between the lowest and highest source is not measurement noise. It is four different jobs being counted under one search term, which is the table above showing up again in the payroll data.
Salary.com is reading postings, and a large share of postings that say “application security” describe junior or governance work. Levels.fyi is reading self-submitted total compensation from people who mostly work at companies that hand out stock. Neither is wrong. They are answering different questions, and averaging them gives you a number that describes nobody.
O*NET, the Department of Labor’s occupational database, puts the 2025 median for information security analysts at $129,180 and projects about 16,000 openings a year through 2034. Call that the honest floor for the broader occupation. Application security sits above it, because the population is smaller and the skill takes longer to build. Meaningfully above it.
Use $150,000 to $200,000 as the working band for a mid-to-senior hire outside the top-paying metros, and treat anything materially below that as a signal you are pricing the fourth row of the table rather than the first. Expect to go higher in the Bay Area, where Indeed’s city data shows $192,145. Atlanta came in at $186,835, which tends to surprise people who assume the premium is coastal. Not for a while now.
To sanity-check a band against the market you are actually hiring in, our salary benchmark assistant is free to use, and the security engineer salary guide breaks the adjacent specializations out further.
Read the Resume for Fix Rate, Not Finding Count
Application security attracts a particular kind of resume inflation. Findings are countable and fixes are not, so resumes fill up with findings. Predictably.
“Identified over 300 vulnerabilities across the application portfolio” tells you the candidate ran a scanner and probably opened 300 tickets. It says nothing about whether any of them closed, or whether the engineering team had stopped answering their messages by month four. That second outcome is the common one, and it is how most application security programs quietly die.
What to look for instead, none of which candidates think to volunteer unless asked:
- They can name a vulnerability class they stopped seeing in their codebase, and explain what changed to make it stop. Best question in the loop, by some distance.
- Language depth in whatever you actually write. Someone strong in Java and Spring is not automatically useful against a Go and Rust codebase, and the reverse is truer than people admit, because memory-safety habits transfer in one direction while framework-specific injection patterns do not really transfer at all.
- Evidence of having shipped a fix rather than filed a ticket about one. Pull requests, not Jira.
- Dependency and build-system fluency. Ask what they know about how their last employer’s artifacts got signed. A blank look there, in 2026, is disqualifying at senior level given where the OWASP list went.
- Willingness to call a finding low severity and close it. Engineers stop listening to people who label everything critical, and a candidate who cannot triage will spend your team’s goodwill inside a quarter.
Certifications come up on every intake call, so briefly. OSCP and GWAPT tell you somebody sat a hard practical exam. CISSP tells you somebody has five years of experience and passed a management-oriented test. Not one of the three tells you whether a developer will take that person’s pull request comment seriously. Tiebreakers, not filters.
The security engineer interview questions we use with clients cover the technical screen in more depth, and most of it transfers directly to this role.
The Script Inventory Nobody Has Built
One thing to check before you write the req, because it changes the shape of the hire and almost nobody raises it.
If you take card payments on a page you control, PCI DSS requirements 6.4.3 and 11.6.1 have been mandatory since March 31, 2025, per the PCI Security Standards Council. Every script that loads on a payment page needs an inventory, a written business justification, explicit authorization, and ongoing integrity verification. Those pages also need change detection with alerting on a defined cadence.
Assessors consistently report these two as among the hardest requirements in the whole standard to satisfy, which is less about technical difficulty than about the fact that almost nobody has an accurate list of what loads on their own checkout page. The reason is mundane. Marketing has been adding tags to the checkout page for six years and nobody kept a list. Nobody ever does.
That work is application security work that recurs forever rather than closing out at an audit, and it lands on whoever you hire regardless of what the job description said the role would cover. If it applies to you, put it in the posting. Candidates who have carried it before will self-select, and they cost you less time than the ones who discover it in week three.
A Search That Runs in Six Weeks
Seventeen days is what our IT searches average end to end. This one runs longer than that, and I would rather say so than quote you a number we miss. Six weeks from approved req to accepted offer is realistic, provided these happen in this order.
- Pick your row from the table above and write it down. One sentence, in the req, in the first paragraph. Just one. If two stakeholders would write different sentences, settle that first, because the disagreement will otherwise surface at the offer stage and cost you the candidate.
- Cut the requirements list to what you would genuinely reject someone over. Most application security reqs name eleven tools. Three matter to you. The other eight filter out good people whose last employer bought a competing product.
- Price it against this year. A band set from a 2024 budget cycle produces a pipeline of people you cannot close, and you will not find that out until week five.
- Source people who are not looking. The ISC2 2025 Cybersecurity Workforce Study found 59% of respondents reporting critical or significant skills shortfalls, up from 44% the year before, with application security named by 28% of them. Almost nobody qualified is sitting on the market. Almost nobody. Your inbound will skew heavily to the fourth row.
- Screen with your own code. Hand them a real pull request from your repository, sanitized, with a real defect in it, and talk through what they notice. Block forty-five minutes for it. That outperforms every take-home exercise we have watched clients use, and candidates prefer it, which matters when they have three other processes running.
- Decide within a week of the final panel. Two weeks of internal deliberation loses the hire. Every time. It costs us two or three placements a year. Always avoidable.
You Might Not Need This Hire Yet
Our revenue depends on you making this hire. Read the next three paragraphs knowing that, because they argue against our own invoice.
If you have fewer than about fifteen engineers, do not ship software to external customers, and have no compliance obligation forcing the question, a full-time application security engineer is probably premature. Better spend: buy the scanning tooling, send two senior developers to real secure-coding training, and bring a contractor in twice a year for a threat model and a dependency audit. That combination costs a fraction of a salaried hire and finds most of what matters at your stage. That is not a hedge.
The threshold moves when one of three things happens. You sign a customer whose security questionnaire runs forty pages. You start handling regulated data. Or your engineering org crosses roughly thirty people, at which point nobody holds the whole system in their head anymore and design flaws stop being visible to the team that built them.
For the middle case, where the need is real but not yet permanent, a contract engagement through our contract staffing practice gets the work done without committing the headcount. Plenty of clients run six months of contract before converting.
Six Things Hiring Managers Ask Us
We already pay a pentest vendor. Isn’t that the same coverage?
It is not the same coverage. A penetration test produces a report on a schedule, while an application security engineer produces fixes continuously and prevents whole categories of defect from being written. Neither replaces the other.
The tell is your open-findings count. If last year’s report still has items open when this year’s arrives, you have a remediation problem rather than a discovery problem, and buying more testing makes the number worse.
Our developers fix their own security bugs. What does a dedicated hire add?
Threat modeling before code exists, ownership of dependencies and the build system, and triage that keeps the team from drowning in scanner output. Developers can fix bugs. Few have time to decide which 1,200 alerts are real.
On a small team with strong senior engineers, “our developers handle it” holds up longer than security vendors like to admit. It stops holding up at the point where nobody can name every dependency reaching production.
How much of the OWASP 2025 change belongs in the job posting?
Name software supply chain security explicitly. It moved to number three in the 2025 revision, most competing postings have not been updated, and candidates strong in that area will notice yours immediately.
Concretely: mention dependency management, build provenance or artifact signing, and software bill of materials work where it applies. Two extra lines. It measurably changes who applies, because the people already doing that work scan postings for evidence you understand what they do.
We take card payments. Does that change the hire?
Yes, meaningfully. PCI DSS 6.4.3 and 11.6.1 have required payment page script inventory, authorization, integrity checking, and change monitoring since March 31, 2025, and that recurring work belongs to whoever you hire.
Prioritize candidates who have carried a PCI scope before. They exist. They will not need the requirement explained to them, and your first assessment after they start goes very differently.
What should the first ninety days actually produce?
A dependency inventory that reflects what reaches production, a triaged and de-duplicated backlog of existing findings, and one threat model on the highest-risk service. Not a new tool rollout.
Watch the candidate who wants to buy a platform in month one. Sometimes that is right. More often it is a way around the unglamorous inventory work, and the inventory is what makes every later decision cheaper.
The qualified ones all seem to have jobs already. So where do we look?
Direct outreach to people who are not applying, mostly. Application security specialists move through referral and recruiter contact rather than job boards, and inbound volume on these postings skews heavily toward adjacent skill sets.
This is where an agency earns its fee or does not. Our recruiters average 15+ years on the desk and hold a 92% twelve-month retention rate on placements, which matters more than speed on a role this specialized. Ask any firm you talk to for their retention number, not just their fill time. The ones who will not answer are telling you something. Loudly.
The Version of This Req That Fills
Write down which of the four rows you need. Set the band against 2026 data rather than last year’s. Say the words “supply chain” somewhere in the posting. Screen with a real pull request from your own repository. Decide fast.
The rest is detail.
If you want a second read on the req before it goes live, or a shortlist instead of a job board, put the search in front of our recruiting team. We run application security engineer searches on contract, contract-to-hire, and direct hire terms, and the first conversation is usually about scope rather than fees.
