Application security is the discipline of finding and removing weaknesses in code before adversaries do, and building the pipelines that keep them out. OWASP's 2025 Top 10 keeps broken access control in first place, promotes security misconfiguration to second, and names software supply chain failures third . The practice now reaches from source review to runtime testing to dependency control and API surface defense, structured by frameworks like NIST's SSDF, which observes that few development lifecycles address security in detail on their own . The hiring market mirrors that breadth: one "Application Security Engineer" opening can be five different jobs. Secure software development sits at the process end, static and dynamic testing at the tooling end, software composition analysis in the dependency graph, and API security on the surface area between products. Each of them hires a different person.
Challenges in Application Security Recruiting
Secure software development moved the review left into pipelines
NIST's Secure Software Development Framework organizes its practices into four groups: preparing the organization, protecting the software, producing well-secured software, and responding to vulnerabilities . That framing captures what happened to the role. Security used to arrive after the feature, as a review before release; now it sits inside pull requests, build jobs and release gates. The consequence for hiring is that secure software development experience means owning a pipeline, not auditing one: writing checks developers will accept, keeping gates from becoming ceremonial, and negotiating a bug bar with delivery pressure on the other side of the table. The evidence shows in the workflow details: how findings are suppressed with a rationale, how exceptions expire, how a broken build escalates. Candidates who have only ever reviewed finished code, however well, are being asked to move upstream into work they have not done, and the interview has to establish whether they ever owned the gate rather than passed through it.
Static application security testing (SAST) drowns in false positives
The tools are widely deployed and the noise is the problem. Organizations reporting significant security gains run SAST at 69%, against 55% in organizations whose posture barely moved , yet every serious AppSec team still carries a tuning workload the tools never mention. The scarce skills are semantic judgment and rule authorship: knowing which CWE classes the engine flags well, writing custom rules for framework-specific patterns, and triaging fast enough that a finding queue never becomes a museum. A resume can list four SAST products and say nothing about any of that. The interview question that separates the populations is simple: what was the false-positive rate when you inherited the tooling, and what did you leave it at? Owners answer in numbers, sometimes embarrassingly specific ones; tourists answer in adjectives.
Dynamic application security testing (DAST) still owns the runtime
Static analysis reads source; dynamic application security testing (DAST) exercises the running system, which is where session handling, deployment misconfigurations and deserialization flaws actually live. Adoption tracks maturity the same way: 63% of the significantly-more-secure organizations run web application scans against 38% of the unchanged group . The work has quietly specialized, and hiring briefs rarely say which specialization they mean. Authenticated crawling, API-aware scanning, handling modern single-page applications, and deciding which findings a DAST run can even reach are all judgment calls a configured scanner does not make. There is also a platform split: people who run DAST against web estates and people who run it against APIs live in adjacent tools and different mental models of what a session even is. Candidates who describe DAST as a scheduled scan they ran against a login wall are describing the tool, not the discipline.
Software composition analysis chases transitive dependencies and SBOMs
Software composition analysis moves the search down the dependency graph. The organizations reporting real security gains run SCA at 67% against 45% elsewhere , and the motivating incident class is well documented: Log4Shell arrived as a transitive dependency, and organizations without dependency visibility spent weeks on manual searches for a library they could not locate . CISA's 2026 SBOM minimum elements now require coverage that includes transitive dependencies, with component producer and dependency relationships spelled out . Hiring for this work means finding people who think in graphs: tracing a CVE through three levels of dependencies, judging reachability, and knowing which fixes a patch, a version bump or a renegotiated license. Dependency confusion attacks add a supply-chain instinct to the same profile, and private registries, pinning and provenance checks are now part of the interview vocabulary rather than a niche. The role has also absorbed the paperwork side of supply chain security, since SBOM generation and maintenance live wherever the dependency graph does.
API security is an object-level authorization problem
The OWASP API Security Top 10 keeps broken object level authorization at number one: endpoints that take an object ID from the client and never check whether the requester may touch that object . That is a business-logic flaw, which is why scanners find so little of it. Defending APIs means schema discipline, an inventory that stays current as endpoints proliferate, and authorization checks written into the code that owns each object. The hiring split follows: engineers who can design the checks into a product, and testers who can demonstrate the breach with a manipulated ID. Most API security openings need the first population and will interview the second for weeks without noticing. One sharp screen cuts through it: ask which endpoint in their own product took a client-supplied ID, what the authorization check looked like in the code, and how they verified it held. Testers describe the bug; owners describe the fix and the regression test that keeps it closed.
Triage ownership settles static application security testing (SAST) claims
Verification in application security runs through the queue. Ask the candidate to walk a real finding from alert to fix: which rule fired, why it mattered, what they changed, and what test kept it closed. Ask for the false-positive numbers, the custom rules they authored, and the CWE classes they could personally triage in a language the team ships. The strongest evidence is a gate that developers still respect: engineers who tuned SAST until the noise stopped killing the signal, so releases stopped being exceptions. Ask what a developer shipped that a weaker gate would have caught, and what a gate caught that saved the team, and the two answers tell you whether the candidate ever ran a real program. The cost of a miss is a pipeline nobody trusts, a findings backlog nobody triages, and release pressure that quietly reopens the vulnerabilities the seat was hired to close.
References
- OWASP Top 10:2025 — OWASP Foundation. (accessed 2026-09-28)
- SP 800-218, Secure Software Development Framework (SSDF) Version 1.1 — National Institute of Standards and Technology (NIST). (accessed 2026-09-28)
- The state of security in cloud native development 2024 — Cloud Native Computing Foundation (CNCF). (accessed 2026-09-28)
- API1:2023 Broken Object Level Authorization - OWASP API Security Top 10 — OWASP Foundation. (accessed 2026-09-28)
- 2026 Minimum Elements for a Software Bill of Materials (SBOM) — Cybersecurity and Infrastructure Security Agency (CISA). (accessed 2026-09-28)
- A Shared Vision of Software Bill of Materials (SBOM) for Cybersecurity — Cybersecurity and Infrastructure Security Agency (CISA). (accessed 2026-09-28)