Security Engineering & Tooling · Chapter 7 of 8
The job — four tracks, no junior door, and what is actually scarce
What 5,197 postings say the work is, why the entry-level pipeline is 1.9%, and the question to ask that 97% of employers cannot answer.
Role distribution: Security Engineer (general) 28.8%, Application Security 22.9%, Product Security 12.6%, Cloud Security 4.7%, DevSecOps 3.4% — declining as a title while persisting as a function — and AI Security 1.6%.
What the job actually is
Not “run the scanner.” 78.6% of full descriptions frame remediation as human coordination, 72% use shift-left language, 59.9% name developer friction, and 55.5% reference managing multiple scanning tools. The work is getting other teams to fix things: routing findings to owners, negotiating priority, and building the paved road so the vulnerability class stops recurring.
And a detail that should change how you prepare: more than eighty security vendors appear across the corpus with no dominant player. That is precisely why postings emphasise Python, CI/CD, Terraform and Kubernetes rather than named products. Learn the primitives, not the consoles.
The four tracks, and how each one fails
| Track | The core question | Primary skill | Fails when |
|---|---|---|---|
| AppSec / Product Security | Is this code and design safe to ship? | Read code fluently in the org's languages; threat modelling; developer influence | You are seen as a gate rather than an enabler |
| Cloud Security | Is this infrastructure and identity configured safely? | IAM depth, Terraform, Kubernetes, the cloud control plane | You know the CSPM console but not policy evaluation logic |
| Detection Engineering | Will we notice, and can we act on it? | Data pipelines, detection-as-code, ATT&CK, writing high-precision rules | You optimise coverage over precision and drown the SOC |
| GRC | Can we demonstrate it, to whom, against which framework? | Frameworks, evidence, audit — increasingly automation | It stays document-driven instead of control-driven |
Genuinely scarce, in order
- Cloud IAM depth. People who can reason about policy evaluation, trust relationships, cross-account assumption and privilege-escalation paths — not just read a posture finding. Cloud security engineers out-earn generalist security engineers at equivalent seniority, and this is why.
- Detection engineers who write code. Detection-as-code, versioned, tested, with measured precision. Most postings using the title are SOC analyst roles with better branding; the real version is rare.
- Security engineers who can actually ship software — the ones who build the paved road rather than filing tickets about it. Highest leverage, rarest profile.
- AI and ML security with real depth. Currently a title-inflation zone, but the demand curve is steep and supply is genuinely thin: references grew from 2.1% of enriched descriptions in November 2025 to 7.2% in May 2026, a 3.4× acceleration in seven months, and the roles carry roughly an 11% pay premium.
Not scarce, despite the noise: people who can operate a scanner and forward its output. That is the job being automated, and it is also the job with the 1.9% entry-level pipeline. The overlap is not a coincidence.
The question to ask them
“What are your vulnerability fix SLAs, and what percentage do you hit?”
Only 3% of companies publish fix SLAs. 5% mention a security champions programme; 15% reference developer education. So 97% of employers have no answer — and how they handle not having one tells you everything.
It separates a programme that measures outcomes from one that measures scan counts, and it is a strong signal in the other direction too: it says you have run a programme rather than staffed one.
The corpus caveat: only 5.3% of these postings disclosed salary, and 48.5% of fields were null. Treat compensation figures as directional and the structural findings as solid.
Check yourself