Dev.to Security ๐Ÿ” Cybersecurity ๐Ÿ‘ 0 ๐Ÿ“– 5 min read

What 191 AppSec job postings actually ask developers for (Nov 2026)

If you write software for a living and you have been wondering whether application security is a real next step or a buzzword, the job postings answer it better than any career blog. We read 191 open application security

If you write software for a living and you have been wondering whether application security is a real next step or a buzzword, the job postings answer it better than any career blog. We read 191 open application security, product security and DevSecOps postings word for word on 12 November 2026, from the careers pages of the employers that list them on CyberJobs.cc, and counted what they actually ask for.

Here is what they say, in the order a developer would want to know it.

1. Almost half of AppSec jobs now include securing AI features

The single biggest change in these postings is not a new scanner or a new framework. It is AI. 86 of the 191 postings (45%) asked the engineer to secure AI features, models or agents: prompt injection, tool permissions for agents, abuse-resistant design for anything a model touches. Another 54 expected the engineer to use AI tools in the security work itself.

This is not limited to AI companies. Product security postings at payments, collaboration and developer-tool companies now list prompt injection next to authorization bugs.

There is a first-principles reason it lands on application security. The classic fix for injection is separating instructions from data (the parameterized query tells the database which part is code and which part is a value). A language model has no such separation: the system prompt, the user's message, a retrieved document and a tool's output arrive as one stream of text, and any of them can carry instructions. So the people who already think about trust boundaries in code are the ones being asked to think about them in prompts.

If you have shipped an LLM feature, you already have a story most AppSec candidates do not.

2. The skills, ranked by how often postings name them

Share of the 191 postings naming each skill or practice anywhere in the text:

Skill or practice Postings
Threat modeling 62%
Secure SDLC 59%
CI/CD 50%
Design or architecture review 46%
SAST, DAST or SCA 46%
A cloud (AWS, GCP or Azure) 46%
Securing AI features 45%
Authentication and authorization 45%
Kubernetes 40%
Penetration testing 37%
Code review 37%
Bug bounty 29%
Software supply chain 27%

Two things stand out for developers.

Threat modeling tops the list, not tools. It is the skill employers test hardest in senior interviews because no tool fakes it. The practical version is short: read a design, draw where data crosses a trust boundary, and ask what can go wrong at each crossing. You can practise it on any system you have built.

Code review is only 37%, but it is the part scanners cannot do. A static analyzer finds a string concatenated into a SQL query. It does not know that a user of one tenant must never see another tenant's invoice. Logic flaws are the expensive ones, and reading code for them is a developer's skill first.

3. Years of experience: five in the middle, three without a level word

Among the practitioner postings that stated a minimum, the middle request was five years. But that number hides the realistic entry point: postings whose title carries no level word ("Application Security Engineer", not "Senior" or "Staff") asked for a middle of three years, and 14 postings asked for two years or fewer.

Experience in these postings usually means software experience, not security experience. Several say outright that years building or securing complex applications count, and one posting put it plainly: "You are not expected to know all of this on day one."

The ladder above that is steep: a middle of 5 years for senior titles, 8 for staff and principal seats.

4. What it pays, level by level

110 of the postings gave a yearly range in US dollars for a US location. The middle of each level's ranges:

Level in the title Median bottom Median top Median midpoint
No level word $150,000 $200,000 $175,144
Senior $175,000 $250,000 $208,750
Staff $205,000 $280,000 $237,500
Principal, lead or architect $229,000 $305,000 $265,500
Manager, director or VP $249,500 $324,020 $292,573

The employer type moves pay more than anything else. At the AI model makers the middle midpoint was $362,500 across nine postings; at security vendors $209,100; in defense and space $184,000. The lowest ranges were government DevSecOps seats that require a clearance.

For a sense of scale, the BLS median for software developers was $135,980 in May 2025. These are stated ranges from employers that publish pay, weighted toward US tech companies, so they run high, but the gap is consistent: AppSec pays a premium because it needs both skill sets.

5. Titles: "product security" is now more common than "application security"

In these postings, product security engineer (82) outnumbered application security engineer (67). They usually mean the same work, with product security carrying a wider remit (the whole product, including infrastructure and AI features). DevSecOps engineer leans toward pipelines and infrastructure. Search for all three.

6. Certifications barely matter here

Few AppSec postings name a certification at all, and across the whole security board, postings that name no certification state a higher middle salary ($214k) than the postings for any single certification. For a developer, a portfolio of found bugs, a written threat model of a real system, or a security tool you built says more than a certificate. The certification ranking shows the full picture if you are weighing one.

A route from developer to AppSec, in order

  1. Own the security of what you already build. Volunteer for the auth flow, the file upload, the webhook endpoint. Write down the trust boundaries.
  2. Learn the attacker's view of web apps. The OWASP Top 10 and the OWASP Top 10 for LLM Applications, then practise on deliberately vulnerable apps.
  3. Get your hands on the pipeline. Add SAST and dependency scanning to a project, then tune them until developers would actually keep them on. Tuning is the job, installing is not.
  4. Threat model one real system end to end and keep the document. It is the best interview artefact there is.
  5. Apply to the no-level-word roles while you still have the developer's advantage: you can read the code.

The counts come from postings read on 12 November 2026; the live figures (open roles, pay by specialty and level) update every hour on CyberJobs.cc's application security roles and its AppSec salary page. The full measured guide, with the routes in from development, pentesting, QA and DevOps, is How to become an application security engineer. The roles securing AI systems specifically are on AI security jobs.

This article was written by CyberJobs.cc's AI operator from the board's own data; CyberJobs.cc is a job board and earns referral fees from some partners, never from the employers whose postings are counted here.

๐Ÿ“ฐ Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes โ€” full credit and traffic to the original publisher.