How to Become an Application Security Engineer: Lessons From 191 Open AppSec Roles

What it takes to become an application security engineer, counted from 191 open AppSec, product security and DevSecOps postings read word for word on 12 November 2026: the duties, languages, tools, years, certifications and salaries employers put in writing.

An application security engineer keeps exploitable flaws out of the software a company builds and ships. In practice that means reviewing designs before they are coded, reading code for the mistakes scanners cannot see, wiring security checks into the build pipeline, triaging whatever still slips through, and making the safe way to write software the easiest way for every developer in the building. The honest route in runs through software itself: most people hired into the job spent years building applications (or breaking them) before they specialized, and they layered threat modeling, secure design and the tooling of the trade on top of that base. The open postings agree. Only 2 of the 191 were for students or new graduates, the typical practitioner posting that stated a number asked for five years, 64% named Python, and fewer than a quarter mentioned any certification at all.

How the sample was drawn. CyberJobs.cc reads about 2,150 open security roles from the careers systems of roughly 300 employers every hour. On 12 November 2026, 210 of them sat in its application and product security specialty. Another 29 roles were filed under other specialties (leadership, offensive security, research, identity) while their titles named product security, application security, AppSec, DevSecOps or software supply chain, so they joined the pile. All 239 postings were read in full, and 13 were set aside because the job was not security engineering: four sales engineers, four program or product managers, a support engineer, a customer success engineer, a backend manager building a vendor's own AppSec product, a FedRAMP compliance director and a warehouse and transport security manager. Where an employer listed one posting in several cities ( SpaceX listed most of its Starlink security roles three or four times), it counts once. That leaves 191 distinct postings from 124 employers, the base of every count below unless a sentence names another one. The board re-reads each employer hourly, so today's numbers have moved: as you read this, 181 application and product security roles are open on CyberJobs.cc, 56 of them remote, with a typical stated band of $184k/yr to $346k/yr.

A note on names, because searchers use several. Application security engineer and AppSec engineer are the same job. Product security engineer is the more common title in today's postings (82 against 67) and usually means the same work with a wider remit. DevSecOps engineer leans toward pipelines and infrastructure, and software security engineer toward building security systems in code. Section 2 sorts them out, and the board's shorter application security overview summarizes the specialty on one page.

Contents

1. What an application security engineer actually does
2. AppSec, product security, DevSecOps: the titles and who hires them
3. What 191 open postings ask of applicants
4. How much coding the job takes
5. The skills ladder, in the order it pays off
6. Four routes in: development, pentesting, QA and DevOps
7. Certifications: what postings name, and how rarely
8. Application security engineer salary, level by level
9. AI and LLM applications: the attack surface every posting is adding
10. An eighteen-month plan from where you stand
11. Application security engineer questions, answered

1. What an application security engineer actually does

Start with the arithmetic that creates the job. A software company may have hundreds of developers and a handful of security people. Every one of those developers can introduce a flaw with any change, and the price of a flaw depends almost entirely on when it is found: a missing authorization check costs a sentence to fix on a design document, an afternoon to fix in a pull request, and a breach notice to fix after an attacker finds it in production. Attackers have noticed which door is weakest. Verizon's 2026 Data Breach Investigations Report says 31% of breaches now start with software vulnerabilities, ahead of stolen passwords as the most common way in - Verizon DBIR 2026. Governments now argue the burden belongs with the people who write the software: CISA's Secure by Design program says the cybersecurity burden has fallen disproportionately on consumers and small organizations rather than on the producers of technology - CISA, Secure by Design.

Put those facts together and the job description writes itself. One AppSec engineer cannot look at every change, so the role is about leverage: spending each hour where it removes the most risk. That means three places. Early, at design time, where one conversation prevents a whole family of bugs. Wide, in the shared libraries, defaults and pipeline checks that every team inherits. And at the edges, in triage, where reports from scanners, testers and outside researchers have to be sorted into the few that matter. NIST's Secure Software Development Framework, version 1.1 of February 2022, frames the goal in the same terms: fewer vulnerabilities in released software, less impact from the ones that remain, and fixing root causes so they do not recur - NIST SP 800-218. Here is how that shows up in an ordinary week.

Design review and threat modeling

This is the most frequently requested activity in the sample: 118 of 191 postings (62%) asked for threat modeling, and 88 (46%) for design, architecture or security reviews. A threat model is a structured argument about what can go wrong with a system before anyone builds it. The Threat Modeling Manifesto reduces it to four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job - Threat Modeling Manifesto. In practice the engineer reads a design document, draws the trust boundaries (where data crosses from a user, a partner, a model or another service into something that trusts it), and asks what an attacker could do at each crossing. Mistral AI's product security posting describes the duty plainly: lead threat modeling, architecture reviews and risk assessments for new features, APIs and major architectural changes. A few postings name a method; STRIDE appeared in 6, CrowdStrike's among them.

The value of this work is easy to underrate because nothing visible happens. The best outcome of a design review is a bug that never exists. That is also why it is the skill employers test hardest in senior interviews: it cannot be faked with a tool.

Code review

Seventy postings (37%) asked for code review, and 27 used the stronger phrase secure, manual or security code review. Code review exists because the most damaging flaws in modern applications are logic flaws, and logic is what scanners read worst. A static analyzer can spot a string concatenated into a SQL query; it cannot know that a user of one tenant should never see an invoice from another, or that a refund endpoint skips the ownership check the payment endpoint performs. CrowdStrike asked for proven experience in manual secure code review of applications built in Go, Python or JavaScript. Apollo.io's staff posting set the bar at finding design flaws in unfamiliar codebases and landing fixes that hold up against bypass attempts. Reviewing is not reading every line: the skill is knowing where to look, which usually means authentication, authorization, input that crosses a trust boundary, cryptography and anything that touches money.

Security tooling in the pipeline

Automated testing appeared constantly. Static analysis (SAST) was named in 80 postings, dynamic testing (DAST) in 55, software composition analysis (SCA, which checks third-party dependencies) in 52, and 88 named at least one of the three. Ninety-five named CI/CD or continuous integration. The part outsiders miss is that installing a scanner is the easy step. The job is making its output trustworthy: tuning rules so developers are not buried in false alarms, deciding which findings block a merge, and writing custom rules for the patterns specific to the company's code. Liftoff's posting put a number on the ambition, asking for a code-security triage pilot that produces findings at a false-positive rate engineering will accept. Rubrik wanted scan configuration kept as code, the same way the rest of the infrastructure is.

Secure defaults and paved roads

Sixty-one postings (32%) talked about guardrails, paved roads or paths, secure-by-default patterns or secure frameworks. This is the highest-leverage work in the field and the clearest sign of a mature team. Instead of finding the same bug in forty services, the engineer builds the component that makes it impossible. Apollo.io listed examples: shared authorization, safe OAuth and token handling, and HTTP clients that cannot be tricked into server-side request forgery, so whole classes of issues stop appearing. Reddit's staff posting described the mission as making the secure path the easiest path for engineers and for AI agents. Rubrik's team summarized the philosophy in its first line: software should be secure because of how it was built, not because someone checked it afterwards.

Triage, bug bounty and disclosure

Something always gets through, so every AppSec team runs an intake. Bug bounty programs, where outside researchers are paid for valid reports, came up in 56 postings, and in 41 of them running or triaging the program was part of the job. Twenty-two mentioned a product security incident response team (PSIRT) or a vulnerability disclosure program. Okta's PSIRT posting made the day-to-day operation of the bug bounty program a core responsibility, including engagement with researchers. Esri asked its incident response product security engineer to work through the incident response lifecycle using the FIRST PSIRT framework. Triage is a craft of its own: reproducing a report, judging severity honestly, finding every variant of the same flaw across the codebase, and explaining the risk to the team that has to fix it.

Teaching developers

The last duty is the one that compounds. Forty-nine postings mentioned training, education, awareness or office hours for engineers, and 22 named security champions, the developers in each team who act as the security group's first point of contact. Instructure's posting listed documentation, office hours and design consultation as part of the role. Good AppSec engineers treat this as product work: the audience is developers, the product is guidance they will actually follow, and success is measured in bugs that stop recurring.

What the first seat looks like

Two postings show the junior version of the job clearly. Checkout.com's application security specialist role, described inside the posting as a junior analyst, asks the hire to run SAST and SCA scans, test APIs, take part in threat modeling sessions, triage and track vulnerabilities from automated scans, and help maintain secure coding guidelines based on the OWASP Top 10, with one to three years of experience. Illumio's product security internship pays $37 an hour and covers secure code reviews, threat modeling alongside senior engineers, scripts that speed up triage, and remediation guides. Neither asks for brilliance on day one. Both expect a person who can read code and is curious about how it fails.

2. AppSec, product security, DevSecOps: the titles and who hires them

The titles overlap so much that many searchers assume they are synonyms. They mostly are, with real differences in emphasis that matter when you read a posting.

Three further postings fit the family without a family word in the title, such as Wiz's security engineer for product and production infrastructure.

Product security is the title to watch. At a software company it is close to application security with extra duties: vulnerability response for customers, security features in the product itself, and sometimes compliance evidence. At a hardware or defense company it means something broader. Firmware, embedded systems, secure boot or connected devices came up in 23 postings (12%), nearly all at companies that ship physical products: 9 at SpaceX for its Starlink satellites and terminals, 7 at Anduril for its defense systems, and single postings at Figure AI (humanoid robots), Apex (spacecraft), Samsara (connected devices), OpenAI (consumer devices) and others.

DevSecOps postings read differently from the rest. They ask for years in DevOps, site reliability or platform engineering first, then security on top. Tekion wanted eight years across DevOps, site reliability or security engineering; Payoneer's senior posting asked for six years as a DevOps, DevSecOps or security engineer. They are also where most of the US government work in this sample sits, with clearances and mandatory certifications (section 7).

Who is hiring

The employers in the sample cluster into a few kinds, and the kind shapes the job more than the title does. The board groups its employers by type, and the 191 postings split this way.

Two patterns stand out. Defense and space is concentrated: six employers produced 24 postings, led by SpaceX (9 distinct postings, 28 listings) and Anduril (8). And AI model makers pay in a different league from everyone else, which section 8 examines. Security services firms, the consultancies that sell application security assessments to clients, posted few roles and rarely published pay, so the figure in that row rests on two DevSecOps postings and says little about consulting in general.

3. What 191 open postings ask of applicants

This section is the measurement. Each count records whether a posting names a requirement anywhere in its text, as a requirement, a preference or a description of the work, because most postings blur those lines.

Seniority: a mid-career specialty

By the level written into the title, 67 postings (35%) carried no level word, 52 (27%) were senior, 28 (15%) were staff, 27 (14%) were principal, lead or architect seats, 15 (8%) were managers, directors or vice presidents, and 2 (1%) were for students or new graduates: Illumio's internship and SpaceX's new graduate software security engineer for the classes of 2026 and 2027. Five of the no-level postings carried a "II", which in most engineering ladders marks the step after the first job.

Postings without a level word are the realistic first targets, and they are less forbidding than the overall numbers suggest. Among the 50 of them that stated years, the middle request was three.

Years of experience: five in the middle

Among the 176 practitioner postings (everything but the managers and directors), 138 stated a minimum number of years. The middle request was five, and the spread looks like this.

The 14 postings at two years or fewer are worth knowing by name. Checkout.com and GuidePoint Security's regional application security engineers started at one to three years. Sentry asked for two to five years of industry experience designing, building or securing complex applications, and Flexport's product security engineer for typically two to five years in product or application security or software development. Delinea and Bloomreach set two years. SpaceX's non-senior Starlink security roles asked for a STEM degree, or two years of professional security software development in its place. Affirm's identity-focused product security engineer asked for two years of software engineering or an internship with strong projects. Read those carefully: in most of them, the years can come from software work, not security work.

Rubrik's application security engineer stated no years at all, and said so: "You are not expected to know all of this on day one," with a stated range of $124,200 to $186,200 in Palo Alto. Postings like that are rare and worth an application the day they appear.

The ladder above is steep. The middle request was 5 years for senior titles, 8 for staff, 8 for principal, lead and architect seats, and nine and a half for managers and directors.

Skills and practices

Design work outranks testing. Threat modeling (118 postings) and a secure development lifecycle (113) led the list, ahead of any single testing technique. That ordering is the clearest difference between this job and penetration testing: the employer wants someone who prevents flaws more than someone who finds them, although 71 postings (37%) still mentioned penetration testing, as a skill, a duty or a vendor relationship to manage.

Identity is the core technical subject. Authentication and authorization, including OAuth, OIDC and SAML, appeared in 85 postings (45%). Broken access control has topped the OWASP Top 10 again in its 2025 edition, which says 3.73% of applications tested had at least one of the 40 weaknesses in that category, and folds server-side request forgery into it - OWASP Top 10:2025. If you learn one subject deeply, learn how an application decides who someone is and what they may touch.

Cloud and containers are assumed. AWS, Google Cloud or Azure appeared in 87 postings (46%), containers in 77 and Kubernetes in 76 (40%), and Terraform or infrastructure as code in 47. Applications now run on infrastructure defined in code, and AppSec teams review that code too. The cloud security guide covers that neighbouring specialty in depth.

Software supply chain is now mainstream. Fifty-one postings (27%) mentioned supply chain security, 18 named software bills of materials (SBOMs), 18 named provenance or signing, and 11 named SLSA, the industry framework for build integrity whose current approved specification is version 1.2 - SLSA. OWASP's 2025 list made software supply chain failures a category of its own at number three, noting it has few occurrences in the data but the highest average exploit and impact scores from CVEs. Docker's senior supply chain security engineer, for one, maintains hardened packages and container images, triages vulnerabilities including cases with no upstream fix, and writes Go tests and policy checks that prove the images behave.

Frameworks are named less than you might expect. OWASP came up in 72 postings (38%), and an OWASP Top 10 list (web, API or LLM) in 50. Beyond that, names were scarce: the OWASP SAMM or BSIMM maturity models appeared in 9, NIST's SSDF in 9, the OWASP Application Security Verification Standard in 5 ( Acronis, Agoda, Altruist, ESET and Solidgate), CWE in 8 and CVSS in 8. ASVS is worth knowing anyway: version 5.0.0, published 30 May 2025, is a framework of security requirements for designing, developing and testing web applications and web services - OWASP ASVS.

Named tools: Burp leads, and three quarters name none

Specific products appeared less often than skills. Fifty-two postings (27%) named at least one scanner or testing tool. Burp Suite, the intercepting proxy used for manual web testing, led with 26, followed by OWASP ZAP with 17. Among code and dependency scanners, Snyk appeared in 13 and Semgrep in 10 (counting neither vendor's own postings), Wiz in 9 (again excluding Wiz's own), GitHub Advanced Security or Dependabot in 7, SonarQube in 6, CodeQL, Checkmarx and Trivy or Grype in 5 each, and Veracode in 4. Fortify did not appear once.

The lesson is not to collect tools. Employers name a tool when they already run it, and every team runs a different one. What transfers is the category knowledge: how a static analyzer models data flow, why dependency scanners produce so much noise, what a dynamic scanner can and cannot reach without credentials. GitHub Actions, named in 12 postings, is the most common pipeline platform by name, which makes it a sensible place to learn how checks are wired into a build.

Bug bounty, CVEs and public proof

Public evidence of skill came up often. Twenty-nine postings mentioned CVEs, and of the 56 that mentioned bug bounty, the 15 that did not make it a program to run mostly treated a bounty record as proof of ability. Harvey and WorkOS both asked for vulnerabilities found and fixed, demonstrated through CVEs, bug bounty awards, blog posts or prior work. Capture-the-flag competitions were named in 8. Section 10 turns this into a plan.

What the postings stopped naming

One pattern in the counts runs against intuition. Classic web vulnerability classes by name (cross-site scripting, SQL injection, server-side request forgery, cross-site request forgery, XML external entities, insecure deserialization, IDOR, remote code execution) appeared in only 8 of 191 postings. Prompt injection, a flaw specific to applications built on language models, appeared in 22. That does not mean the old classes are solved. MITRE's 2025 CWE Top 25, built from 39,080 CVE records, still ranks cross-site scripting first, SQL injection second and cross-site request forgery third - MITRE CWE Top 25 2025. It means employers treat the classic classes as table stakes, folded into "OWASP Top 10", and spend their words on what is new. Applicants should do the reverse of what the postings suggest: know the old classes cold, because interviews test them, and show you have thought about the new ones, because postings ask for them.

Remote work, location, degrees and clearances

Remote is common but mostly national. Sixty-nine postings (36%) were listed as remote. Of those, 45 were open to people in the United States (some alongside Canada), 17 only to people in other countries, and 7 carried no country limit. The remote share held near two in five from the no-level seats through staff (26 of 67, 20 of 52 senior and 11 of 28 staff) and dropped for principal and management roles (8 of 27 and 4 of 15). The board's remote application security list shows today's remote roles with the countries each accepts.

The United States dominates. 117 postings (61%) had a US location. The rest spread across India, Canada, the United Kingdom, Israel, Poland and more than a dozen other countries, which reflects where the board's employers hire as much as where the field lives.

Degrees are named in 40%, often with an exit. Seventy-six postings named a degree, and 37 of those accepted equivalent experience in its place. SpaceX's Starlink roles took two years of professional security software development in lieu of a degree.

Clearances are concentrated in defense. Fifteen postings (8%) asked for a security clearance or eligibility for one, eight of them at Anduril. Another group required US person status for export-control reasons, mostly at SpaceX: 23 postings named US citizenship, US person status or export rules.

4. How much coding the job takes

This is the question people ask most, and the postings answer it more clearly than any other: a lot more than most security jobs, and the bar is rising.

Most postings name a language, and most name more than one. 138 of 191 (72%) named at least one programming language. Python led with 123 (64%), Go followed with 89 (47%), then JavaScript or TypeScript with 63 (33%), C or C++ with 40, Java with 31, Rust with 27, Ruby with 18 and C# or .NET with 14. Go's position is the striking one: it appears in nearly half the postings, far more often than its share of application code in general would predict, because so much security tooling and cloud infrastructure is written in it.

A third ask for real software engineering, in so many words. Seventy-one postings (37%) explicitly asked for software engineering or development experience, production-quality code, or strong programming skills. The wording is often pointed. Figure AI asked for strong software engineering skills and added, in parentheses, "not scripting or automation". Abnormal Security wrote: "You write and read production code, not just review it." Cloudflare's application security team required at least five years of hands-on professional experience as a software developer and proficiency in Go or Rust. Nebius published its hiring process, which opens with a 60-minute live-coding interview to assess basic coding skills before any security interview.

Three levels of coding, and which one you need

It helps to separate three kinds of coding the postings describe, because they correspond to different seats.

Reading code. Every AppSec engineer needs this, in the languages the company ships. Code review and threat modeling both depend on it. Writer's postings asked for expertise in at least two languages and the ability to read and review code across many. Apollo.io's staff posting singled out Ruby on Rails, because that is what Apollo runs. The practical consequence: the second and third languages you learn should be chosen by the employers you are targeting, not by fashion.

Writing tools. Most postings want automation: scripts that pull scanner results into tickets, custom static analysis rules, integrations between the bug bounty platform and the issue tracker, small services that check configuration. Python and Go dominate here. Rubrik asked for tooling in Python plus one of Go, TypeScript or JavaScript; Chainguard for strong proficiency in Go or Python with the ability to write, review and debug production-quality code.

Building platforms. At the top end, the job is software engineering whose product happens to be security. Anthropic's staff application security posting describes a builder's role on a senior team, hiring engineers who would rather build the system that finds vulnerabilities than find them one at a time. GitLab's code security team hires a senior backend engineer to ship analyzers and dependency parsing in Go and Rust. Vercel wants product security engineers who build the systems that triage and validate externally reported findings, "not to work the queue". These seats pay the most (section 8) and are closest to a developer's job.

So how much coding do you need? Enough to read the company's code fluently and to build reliable tools in Python or Go is the floor for most postings. If you are a developer already, you are further along than most security people trying to enter this specialty. If you are a security person who does not code, this is the gap to close first, and nothing else on the ladder below will substitute for it.

5. The skills ladder, in the order it pays off

The postings list skills as a flat inventory. They are not flat. Each one below rests on the one beneath it, and learning them out of order is why so many people spend a year on scanners without ever being trusted with a design review.

Rung 1: how web applications actually work

Before you can secure an application you need a working mental model of one: what an HTTP request carries, how a browser decides what a script may read (the same-origin policy, cookies and their attributes, CORS), how sessions and tokens prove identity between requests, and how a backend talks to its database, its queues and other services. The fastest way to learn this is to build a small application with a login, user roles and an API, deploy it, and then look at its traffic through an intercepting proxy. Everything later is a variation on what you see there.

Rung 2: one language to build with, one to read

Python first for most people, because 123 postings name it and it carries every automation task that follows. Then a second language chosen by direction: Go for tooling and cloud platforms, JavaScript or TypeScript for web-heavy product companies, Java or C# for large enterprises and banks, C, C++ or Rust for systems, devices and browsers. The standard is the one Chainguard and Abnormal set: write it, review it and debug it at production quality.

Rung 3: vulnerability classes by root cause

Learn the OWASP Top 10:2025 categories by why they happen rather than by name. The 2025 list runs from broken access control, security misconfiguration and software supply chain failures through cryptographic failures, injection and insecure design to authentication failures, integrity failures, logging and alerting failures and a new category for mishandling exceptional conditions - OWASP Top 10:2025. Injection is a confusion between data and instructions. Broken access control is a missing question at the moment of access. Misconfiguration is an unsafe default nobody changed. If you understand the root cause, you will recognise new variants that no list has named yet, which is the actual skill. OWASP's deliberately insecure Juice Shop, which covers the entire Top Ten and is written in Node.js, Express and Angular, is a free target for practice - OWASP Juice Shop.

Rung 4: identity, sessions and authorization

This deserves a rung of its own because it is where real breaches live and where 85 postings point. Learn OAuth 2.0 and OIDC flows well enough to spot a misused one, understand how a JSON Web Token is verified and where verification is skipped, and practise designing authorization models for multi-tenant products. Anthropic's secure frameworks posting asked for a deep understanding of authentication and authorization systems, and Okta's review posting for deep knowledge of the protocols themselves.

Rung 5: threat modeling and design review

Now the most-requested skill becomes possible, because you can reason about a design only once you know how its parts fail. Practise on real systems: take the architecture of an open-source project or your own employer's service, draw its trust boundaries, and write down the four answers the manifesto asks for. Then do it again for a feature that involves money, a partner integration and an AI model. Write each one up as if a development team will act on it, because that is the deliverable.

Rung 6: scanners and pipelines

With the foundations in place, tools make sense. Wire a static analyzer, a dependency scanner and a secrets scanner into a CI pipeline for a project you own, then do the unglamorous part: tune them until a developer would not mute them. Write two or three custom rules for patterns specific to the code. Secrets scanning appeared in 21 postings and is the easiest win to demonstrate.

Rung 7: cloud, containers and infrastructure as code

Applications run on infrastructure defined in code, so 87 postings name a cloud and 76 name Kubernetes. Learn enough to review a Terraform change and a Kubernetes manifest for the classic errors: public storage, over-broad identity permissions, containers running as root, secrets in environment variables.

Rung 8: the software supply chain

Dependencies, build systems and artifacts are now a top-three risk on OWASP's list. Learn how a lockfile pins a dependency and how attackers abuse names and updates, how an SBOM is produced and read, how artifacts are signed and how provenance lets a consumer verify where a build came from. The SLSA specification is the clearest single reference.

Rung 9: secure defaults and influence

The senior rung is not a technical subject, and it is the one that separates staff engineers from everyone else. It is the ability to change how many teams build: designing the shared library, the paved road or the pipeline control that removes a class of bugs, and persuading engineering leaders to adopt it. Reddit's staff posting asked for experience building secure frameworks, libraries or guardrails that improve security across many teams at once; Apollo.io's for a track record of strategy that changed how several engineering teams build, with measurable results.

Rung 10: AI and LLM applications

The newest rung sits on top of all the others, because securing a feature built on a language model uses every skill below it, plus a few new ones. Section 9 covers it.

6. Four routes in: development, pentesting, QA and DevOps

Almost nobody starts their career in application security. The postings show four common doors, and they are not equally wide.

From software engineering: the widest door

The structural argument for this route is simple. The job is mostly reading and changing other people's code, persuading developers, and building tools, and a developer already does all three. The pool is also large: software developers held about 1.7 million US jobs in 2025, against about 192,900 for information security analysts - BLS, software developers. Security teams recruit from it on purpose. Vercel's product security posting says outright that the role suits a software engineer moving into security. Affirm's identity-focused product security engineer calls software engineering a must-have and accepts two years of it, or an internship with strong projects. Cloudflare required five years as a developer before anything else.

What a developer has to add is narrower than it looks: the vulnerability classes by root cause (rung 3), threat modeling (rung 5) and the habit of thinking about how a feature can be abused rather than how it should work. The most effective move is usually internal. Volunteer for security reviews on your own team, become the security champion your company's AppSec group relies on (22 postings mentioned champions programs), fix the findings nobody else wants, and ask to shadow a threat model. A year of champion work gives you exactly what the no-level and level II postings ask for: security experience gained inside software work, with references who watched you do it.

From penetration testing: a strong door that needs a second half

Seventy-one postings mentioned penetration testing and 18 asked explicitly for offensive or penetration testing experience. Offensive skills transfer directly to code review, triage and the hardest bug bounty reports. Altruist's senior application security engineer is a red team seat; Okta hired a staff product security engineer for offensive security work against its own identity platforms, including AI and LLM-integrated features; Saviynt's vice president of application security asked for 15 years of hands-on penetration testing and offensive work. Bugcrowd's five-month contract application security engineers, remote from Brazil and India, triage the submissions to client bug bounty programs and become fluent in obscure XSS, SQL injection, XXE, IDOR, SSTI and SSRF along the way, which is about as direct an apprenticeship in vulnerability assessment as the market offers.

The second half a tester has to add is building and influencing. A penetration tester's deliverable is a report; an AppSec engineer's deliverable is a codebase that no longer produces the bug. That means writing code to production standards, designing fixes rather than recommending them, and working with the same developers for years rather than weeks. Testers who make the switch successfully usually have one thing in common: they started fixing what they found. The penetration tester guide covers the offensive side in full.

From QA and test automation: narrow, but real

Quality assurance is an underrated starting point, and the postings show both why and why it is narrow. Only 3 of 191 postings named test-automation experience directly. PlayStation's senior application security engineer accepted experience in penetration testing, automated testing or testing frameworks such as JUnit, pytest, REST Assured and Playwright. Qualys's web application security engineer in Pune asked for Selenium and Postman scripting. TRM Labs wanted eight years in software development and testing. The argument for the route is that a QA engineer already thinks in edge cases, already writes automated tests, and already sits in the delivery pipeline where security checks run. Dynamic testing, regression tests for fixed vulnerabilities and API test suites are a natural bridge.

The pay gap is real and worth stating: the US median wage for software quality assurance analysts and testers was $104,300 in May 2025 - BLS, well under the stated ranges in section 8. The step that makes the route work is writing code beyond test scripts. A QA engineer who builds a security test harness, owns the DAST configuration and writes regression tests for every confirmed vulnerability is doing AppSec work already, and can say so in an interview.

From DevOps, site reliability or platform engineering: the DevSecOps door

The 19 DevSecOps postings were written for people who already run pipelines and infrastructure. They asked for years of DevOps, SRE or platform work first, Terraform and Kubernetes fluency, and CI/CD platforms by name. A platform engineer moving into security has the infrastructure half already and needs the application half: vulnerability classes, code review and threat modeling. From DevSecOps, the move into broader product security is common, because supply chain and pipeline security are now core AppSec subjects.

From university or a security operations seat

The direct door from university is tiny in this sample: one internship and one new-graduate program, the latter at SpaceX with a stated $140,000 to $175,000 at its first level in Palo Alto for 2026 and 2027 graduates with a STEM degree and experience in Python, C++ or Go. Students should treat internships, open-source contributions and a portfolio of tooling as the route, and be ready to start in a software engineering role.

From a security operations center or IT role, the route is longer because the coding gap is larger. The workable path is to automate your current work first, in Python, and move toward detection engineering or vulnerability management, where code review and tooling become part of the job. The cybersecurity career paths guide maps how people move between specialties, and the security engineer guide covers the broader engineering track this one branches from.

7. Certifications: what postings name, and how rarely

The most useful number in this section is the smallest one. 150 of the 191 postings (79%) named no certification at all. Of the 41 that did, almost all named them as one acceptable option among several, a preference or a "plus". Only four made a certification a condition, and all four were US government DevSecOps roles under the Department of Defense's workforce rules: Trace3's two DevSecOps engineers and Applied Intuition's required an IAT Level II certification such as Security+, and Anduril's DevSecOps engineer may need to obtain a DoD 8140/8570 qualifying one.

The ranking hides two different ideas of the job. The offensive pair, OSCP (23 postings) and OSWE (15), appears in postings that value hands-on testing: Altruist, Apollo.io, Forward Financing, Nebius, Cato Networks and Netskope among them. The lifecycle and management pair, CSSLP (17) and CISSP (17), appears in postings that frame the job as running a secure development program, often at larger or more regulated employers: Acronis, Commvault, Delinea, AlphaSense and AEG. Cloud and container certifications (AWS's security specialty in 7, the Certified Kubernetes Security Specialist in 7, CCSP in 6) turn up where the role reaches into infrastructure, several DevSecOps postings among them.

Employers who named certifications often undercut them in the same sentence. Cribl listed a row of credentials and then wrote that demonstrated practical impact matters more than certifications. Saviynt's head of application security called the OSCP preferred but not a must. Druva accepted certifications or active community contributions such as OWASP chapters and security conferences.

The practical advice follows from the numbers. If you are a developer moving into AppSec, a certification is the last thing to spend money on: your code, a portfolio of findings and tooling, and a threat model you can talk through will carry more weight with 79% of these employers. If you are aiming at offensive-leaning AppSec seats, the OSCP or OSWE is the most-named credential. If you are targeting US government DevSecOps work, Security+ is not optional. The board's certifications page counts how often every certification appears across all open security roles, not just this specialty.

8. Application security engineer salary, level by level

Of the 191 postings, 121 (63%) stated pay in some form, and 110 gave a yearly range in US dollars for a US location, the base for the figures below. Where one posting listed different ranges for different cities, the median of its cities' ranges counts once. Across all 110, the middle bottom of the stated ranges was $184,000 and the middle top $258,000, with a middle midpoint of $220,800. Today's live figures for the specialty: a median of $220k/yr, in a typical band of $184k/yr to $346k/yr.

The two student postings sit apart: Illumio's internship at $37 an hour, and SpaceX's new graduate program at $140,000 to $175,000 in Palo Alto and $130,000 to $165,000 in Redmond.

Why two offers for the same title differ

Employer type moves it most. The middle midpoint at AI model makers was $362,500 across 9 postings: Anthropic's staff-plus application security engineers listed $320,000 to $485,000, and OpenAI's application security engineer $266,000 to $445,000. Cloud and data infrastructure firms ($231,250) and software and internet companies ($230,500) came next, finance and crypto at $217,575, security vendors at $209,100, and defense and space at $184,000. The lowest ranges in the sample were government DevSecOps seats: Trace3's DevSecOps engineer in Colorado Springs listed $65,000 to $100,000 and required an active Secret clearance.

Level moves it steadily. Each step from no level word to manager added roughly $27,000 to $34,000 to the middle midpoint. The jump from senior to staff ($28,750) is where the work changes from doing reviews to designing the systems that make reviews unnecessary.

Ranges are wide. MongoDB's senior product security engineer listed $126,000 to $248,000; Figure AI's application security engineer $150,000 to $350,000. Ranges this wide often cover more than one internal level (SpaceX's new graduate posting prints two levels with separate bands), so the offer depends on where the interviews place you more than on the title.

Against the national figures

These are not typical US salaries; they are the stated ranges of employers that publish pay, weighted toward technology companies on the US coasts. For a broader comparison, the US median wage for information security analysts was $129,180 in May 2025 - BLS, information security analysts, and for software developers it was $135,980 - BLS, software developers. Application security sits above both in this sample because it combines the two skill sets and is hired mostly by companies that pay engineers well. The board's application security salary page breaks the live figures down by seniority, workplace and employer, and the highest-paying security jobs ranking shows where the specialty sits against the rest of the field.

9. AI and LLM applications: the attack surface every posting is adding

If one finding defines application security in late 2026, it is this: 86 of 191 postings (45%) asked the engineer to secure AI features, models or agents, and 54 (28%) expected the engineer to use AI tools in the security work itself. Together, 104 (54%) did one or the other. The duty was not confined to AI companies. Asana's product security engineers in Warsaw and Vancouver are asked to address prompt injection, insecure tool permissions and abuse-resistant design in Asana's AI and agentic features. Plaid, Brex, Sentry, Roblox and Metropolis all wrote AI security into application and product security roles.

Why AI features break the old model

There is a first-principles reason this is a new discipline rather than a new checklist. Many of the classic application security defences work by separating instructions from data. The standard fix for SQL injection is the parameterized query, which tells the database exactly which part of a request is code and which 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 all arrive as one stream of text, and any of them can carry instructions. That is why prompt injection sits first on OWASP's Top 10 for LLM applications, and why the same list includes excessive agency, the risk of giving a model-driven system more power than it needs - OWASP Top 10 for LLM Applications 2025.

With no equivalent of the parameterized query yet, the controls move to the boundaries around the model, and that is exactly what the postings describe. Cohere framed the open questions as what authorization means when an agent acts on a user's behalf, how to contain tools that consume untrusted input, and whether tenant boundaries hold. Endor Labs asked its product security engineer to harden its own AI agents by enforcing least privilege across MCP, credentials, filesystem and network. Notion's AI product security engineer, at $270,000 to $340,000 remote, builds automated red-team and regression testing for prompt injection, indirect instruction following, data exfiltration, tool misuse, cross-tenant leakage and unsafe workspace changes. Rubrik's early-career posting asked candidates who had set up controls on an AI coding agent (permissions, sandboxing, hooks, tool restrictions) to describe the risk each control reduced.

The underlying skills are the ones from the ladder: authorization, trust boundaries, least privilege, output handling and testing. What is new is the threat model. A useful habit is to treat every model as an untrusted user with the permissions of whatever tools it can call, and then ask what the worst sentence in any input it reads could make it do. NIST published a companion to its SSDF for generative AI and dual-use foundation models in July 2024 that adds AI-specific practices to the same lifecycle - NIST SP 800-218A.

AI as the engineer's own tool

The second half of the story changes the job from the inside. AI coding agents are increasing the volume of code faster than human review can absorb, which Reddit's staff posting named directly, and the response is AppSec built on models. Anthropic's application security team says it uses Claude as its primary tool across the job: driving static analysis, drafting fixes as pull requests, performing first-line bug bounty triage and assisting threat modeling, with humans handling judgment. Vercel's product security engineer builds LLM and agent-based tooling that validates reported findings, traces them to root cause and opens fixes for well-understood classes behind human review gates. BeyondTrust's senior posting asked for hands-on experience with LLM-based code analysis platforms. Fifty-four postings expected something in this vein.

This cuts both ways for someone entering the field. The routine half of triage and scanning is automating fastest, so the entry-level version of the job is shrinking in volume. But the people building those systems need exactly the AppSec skills on the ladder plus software engineering, and the pay reflects it.

Does AI security pay more?

At first glance, yes. Among practitioner postings with stated US pay, the 49 that asked the engineer to secure AI features had a middle midpoint of $235,000, against $204,600 for the 51 that did not. Look closer and the gap is mostly about who is hiring. At the senior level the two groups were nearly identical ($210,500 against $208,750). The difference opens at staff and principal levels, where AI model makers and AI-native companies dominate the AI group. The honest reading is that AI security skills open the door to the highest-paying employers, rather than adding a premium at any given employer. The board's AI security jobs page tracks those roles across every specialty.

10. An eighteen-month plan from where you stand

The plan below assumes you are employed in a technical role and can give the work steady time. Adjust the pace to your starting point: a working developer can compress the first months, someone starting from IT should expect them to take longer.

Months 1 to 3: the application foundation. Build and deploy a small web application with login, roles, an API and a database, in Python or the language of the employers you want. Watch its traffic through an intercepting proxy. If you already build software for a living, skip ahead and spend these months reading your own company's code with a security eye instead.

Months 4 to 6: vulnerability classes and your first findings. Work through the OWASP Top 10:2025 by root cause, attacking a deliberately insecure application such as Juice Shop and then your own. Write up five findings the way a developer would want to read them: what is wrong, how to reproduce it, why it matters, how to fix it and how to stop it recurring. Volunteer for security review work on your team.

Months 7 to 9: threat modeling and identity. Threat model three systems: your own application, an open-source project with a published architecture, and a feature involving payments or an AI model. Go deep on OAuth, OIDC and authorization design. Become your team's security champion if your company has a program; propose one if it does not.

Months 10 to 12: the pipeline and a public tool. Wire SAST, dependency and secrets scanning into a CI pipeline (GitHub Actions is the most-named platform), tune them until they are quiet, and write custom rules for two patterns. Publish the configuration and rules in a public repository with a short write-up. This is the single most persuasive artifact for an AppSec interview, because it shows the job rather than describing it.

Months 13 to 15: cloud, supply chain and AI. Review Terraform and Kubernetes configuration for common errors, produce and read an SBOM for your project, and sign a build artifact. Then threat model an LLM feature end to end and build a small regression test for prompt injection against it. If you want public proof beyond your own code, report a vulnerability through a disclosure program or contribute a fix to an open-source security tool; 29 postings mentioned CVEs.

Months 15 to 18: applications. Apply before you feel ready, starting with postings that carry no level word or a "II", ask for two to four years, and accept software experience as the years. Internal moves come first if your employer has a security team. Prepare to walk an interviewer through a threat model and a code review live, the two activities at the heart of what the postings describe; Nebius, which published its process, follows a live-coding round with a security interview and a 90-minute security system design interview. The cybersecurity resume guide shows how to present development or testing experience as security experience, and the interview questions guide covers the technical rounds. The board's application security engineer title page and application and product security roles list who is hiring today.

Eighteen months is not a guarantee. What the plan does is put each month into something the 191 postings asked for, in an order where each step makes the next one easier, and leave you with public evidence an employer can check.

11. Application security engineer questions, answered

What does an application security engineer do?

They keep vulnerabilities out of the software a company builds: threat modeling designs (asked for in 62% of postings), reviewing code, running and tuning security scanners in the build pipeline, triaging findings from scanners, testers and bug bounty researchers, building secure defaults other teams reuse, and teaching developers. Senior engineers spend most of their time on design and on systems that prevent whole classes of bugs.

How do I become an application security engineer with no experience?

Usually by getting software experience first. Only 2 of 191 postings were for students, and the realistic first targets asked for one to four years that could often come from development work. The most common path is a developer or QA engineer who becomes their team's security champion, builds a portfolio of findings and tooling, and moves internally. Section 10 sets out an eighteen-month plan.

How much does an application security engineer make?

In 110 US postings with stated ranges on 12 November 2026, the middle range ran from $184,000 to $258,000, rising from a $175,144 midpoint for roles with no level word to $265,500 for principal and lead roles. AI model makers paid the most and government DevSecOps seats the least. Today's live band is $184k/yr to $346k/yr. These are ranges published by mostly technology employers; the BLS median for information security analysts was $129,180 in May 2025.

Do application security engineers need to code?

Yes, more than most security roles. 72% of postings named a programming language, Python in 64% and Go in 47%, and 37% asked explicitly for software engineering experience or production-quality code. At minimum you need to read the company's languages fluently and build reliable tools in Python or Go.

What is the difference between application security, product security and DevSecOps?

They overlap heavily. Application security focuses on the code and design of a company's applications. Product security covers everything the company ships, including vulnerability response for customers and, at hardware companies, firmware and devices; it was the more common title (82 postings against 67). DevSecOps focuses on the security of build pipelines and infrastructure and usually asks for DevOps or platform experience first (19 postings).

Which certification is best for application security?

For most employers, none: 79% of postings named no certification, and only four required one, all US government DevSecOps roles needing Security+ or an equivalent. When postings did name one, OSCP (23) and OSWE (15) led among offensive-leaning roles, and CSSLP and CISSP (17 each) among lifecycle and program roles.

Is application security a remote job?

Often. Sixty-nine of 191 postings (36%) were remote, most of them open to people in the United States. Defense, hardware and AI lab roles were more likely to require an office.

Is application security a good career?

On the evidence, it is a well-paid specialty with steady demand and a clear senior track. Verizon's 2026 breach report found software vulnerabilities have overtaken stolen passwords as the most common way attackers get in, and the US Bureau of Labor Statistics projects information security analyst jobs to grow 21% from 2025 to 2035 - BLS. The specialty also has a defined path above senior, with staff and principal roles that stay hands-on.

Will AI replace application security engineers?

It is changing the job faster than it is removing it. Forty-five percent of postings now ask engineers to secure AI features, and 28% expect them to use AI tools in their own work, including systems that triage bug reports and draft fixes. Routine scanning and triage are automating fastest; threat modeling, authorization design, judgment about risk and building the automated systems themselves are where demand is growing.