Roadmap
AppSec / Security Software Engineer
The engineer who embeds security into the software development lifecycle. Performs threat modeling, integrates automated security testing into CI/CD pipelines, conducts code reviews, manages vulnerability programs, and acts as the trusted security partner for development teams building the product.
OPTIMISTIC 2-3 years · REALISTIC 3-4 years
Stage 00
Programming Fundamentals
AppSec engineers read code in multiple languages every day. You cannot identify security flaws you cannot read. This is the non-negotiable prerequisite that separates AppSec from general security work.
Why Programming Depth is Mandatory
- AppSec engineers review code in pull requests. You must read it faster than developers write it.
- You write custom Semgrep rules, automation scripts, and security test harnesses.
- You explain to developers exactly which line is vulnerable and why, which requires reading the code yourself.
- The developer path to AppSec is faster because programming fluency is already present.
Python — Primary AppSec Language
- All fundamentals — variables, types, control flow, functions, classes, modules
- File I/O, JSON, XML, HTTP requests (requests library)
- Regular expressions — re module; pattern matching in security tool rules
- Subprocess — executing external tools from Python
- requests — HTTP client; testing APIs, automated scanning
- Flask/FastAPI — understanding web frameworks from developer perspective
- SQLAlchemy — understanding ORM patterns and SQL injection risks
- cryptography / pycryptodome — implementing and analyzing cryptographic operations
- bandit — Python SAST tool; using and extending
- semgrep — Python API for custom rule writing
- Writing security automation — scanning pipelines, vulnerability validation scripts, custom scanners
JavaScript / TypeScript
- Node.js fundamentals — modules, async/await, Express.js
- Frontend JavaScript — DOM manipulation, event handling, fetch API
- Prototype pollution — understanding why it matters
- XSS patterns — innerHTML, dangerouslySetInnerHTML, eval()
- CSRF — SameSite cookies, token patterns
- Dependency chains — npm package security implications
- TypeScript — type safety and its security benefits; understanding tsconfig
Java
- Object-oriented fundamentals — classes, inheritance, interfaces
- Spring Boot basics — MVC pattern, annotations, dependency injection
- Deserialization — ObjectInputStream; why it's dangerous; gadget chains
- XXE — XML parsing without entity restriction
- SSRF patterns in Spring RestTemplate
- JDBC injection — parameterized queries vs string concatenation
- Reading Java stack traces — essential for triaging SAST findings
Additional Languages to Read (Not Necessarily Write)
- Go — growing web service language; goroutines, defer, error handling patterns
- C/C++ — memory safety issues: buffer overflows, use-after-free, format strings
- PHP — legacy web applications; injection patterns; register_globals legacy
- Ruby/Rails — Rails security patterns; mass assignment, SQL injection in ActiveRecord
Resources
- Python.org tutorial (free)
- JavaScript.info (free)
- "The Web Application Hacker's Handbook" (book)
- OWASP code examples (free)
Stage 01
Web Application Security — Deep
Web applications are the primary AppSec attack surface. Deep understanding of every OWASP Top 10 category at the code level is the core job requirement.
HTTP and Web Fundamentals
- HTTP/1.1 and HTTP/2 — methods, status codes, headers
- HTTPS / TLS — certificate validation, HSTS, certificate pinning
- Cookies — Secure, HttpOnly, SameSite (Strict/Lax/None) attributes; purpose of each
- Sessions — session ID generation, storage, fixation, invalidation
- Same-Origin Policy (SOP) — what it prevents; origin = scheme + host + port
- CORS — Access-Control-Allow-Origin/Credentials, preflight OPTIONS, origin reflection / null origin / wildcard+credentials misconfigs
- CSP — directives (default-src, script-src, style-src, connect-src, frame-ancestors); bypasses (unsafe-inline, unsafe-eval, JSONP, open redirects); nonce/hash-based CSP
- Security headers — X-Frame-Options, X-Content-Type-Options, Referrer-Policy
- Browser storage — localStorage, sessionStorage, IndexedDB — XSS targets
OWASP A01 Broken Access Control
- Users accessing data or functions they should not have permission to access
- Missing authorization checks before data access
- Horizontal privilege escalation — user A accessing user B's resources by changing an ID
- IDOR (Insecure Direct Object Reference) — `/api/orders/12345` without ownership check
- Path traversal — `../../../etc/passwd` in file access functions
- Forced browsing — accessing `/admin` without role check
- JWT manipulation — changing `alg` to `none` or modifying `role` claim
- Review checklist — every data access ownership check, every state-changing op authz, file path traversal sanitization
OWASP A02 Cryptographic Failures
- Cryptographic failures — weak crypto, hardcoded secrets, insecure transmission
- Sensitive data transmitted without encryption — HTTP instead of HTTPS
- Weak algorithms — MD5/SHA-1 for passwords; RC4; DES
- Hardcoded secrets — API keys, passwords, private keys in source code
- Insecure random — Math.random() for security tokens; should use crypto.randomBytes()
- Improper key management — keys in environment variables but committed to version control
- Code patterns: `MD5(password)`, `Math.random()` for session tokens, API keys in code (`apiKey = "AKIA..."`), HTTP endpoints for sensitive operations
OWASP A03 Injection — Deep
- Injection — untrusted data interpreted as code/commands by an interpreter
- SQL injection — string concatenation in queries; parameterized queries / prepared statements as the correct pattern
- ORM injection — `raw()` methods, string interpolation in ActiveRecord
- Second-order injection — stored input reused unsafely later
- Blind SQLi — boolean-based, time-based
- Stacked queries — multiple statements via semicolon
- Command injection — patterns where user input concatenates into shell-invoking calls; safe via parameterized exec without shell=True and allowlist input validation
- LDAP injection — unsanitized user input in LDAP filters: `(&(user=` + username + `)(pass=` + password + `))`
- XPath injection — unsanitized input in XPath queries
- Template injection (SSTI) — `{{user_input}}` in Jinja2/Twig/Freemarker without sandboxing; escalation to RCE via `{{7*7}}` → `{{config}}` → code execution
- NoSQL injection — MongoDB `{$where: userInput}`, operator injection via JSON body
- Header injection — CRLF injection in HTTP response headers
OWASP A04 Insecure Design
- Insecure design — flaws not caught by automated tools; require understanding application intent
- Price manipulation — sending negative quantities or modified prices
- Workflow bypass — skipping required steps in multi-step processes
- Race conditions — concurrent requests exploiting TOCTOU (Time-of-Check Time-of-Use)
- Mass assignment — binding user-supplied JSON to model attributes including privileged ones
- Threat modeling as the primary mitigation — design review before implementation
OWASP A05 Security Misconfiguration
- Security misconfiguration — defaults, verbose errors, debug enabled, missing headers
- Default credentials — admin/admin, default API keys
- Verbose error messages — stack traces exposing internal paths, versions, framework details
- Unnecessary HTTP methods enabled — TRACE, PUT, DELETE
- Directory listing enabled
- Outdated framework versions
- Debug mode enabled in production — Flask debug=True, Django DEBUG=True
- CORS wildcard with credentials
- Missing security headers
- Cloud storage public access — S3 bucket public read, Azure Blob anonymous access
OWASP A06 Vulnerable and Outdated Components
- Vulnerable and outdated components — known CVEs in deps, transitive vulnerabilities
- Dependencies with known CVEs
- NPM packages with transitive vulnerabilities
- Unpinned versions — `^1.0.0` allows unexpected updates
- SCA (Software Composition Analysis) as the primary control
- License compliance — GPL contamination risks
- Supply chain attacks — dependency confusion, typosquatting
OWASP A07 Identification and Authentication Failures
- Authentication failures — weak password policies, missing MFA, insecure resets, session fixation, credential stuffing
- Weak password policies — no length requirement, no complexity
- Missing MFA for privileged operations
- Insecure password reset — predictable tokens, no expiry, no one-time use
- Session fixation — session ID not regenerated after login
- Session timeout — sessions that never expire
- Credential stuffing susceptibility — no rate limiting, no lockout
- JWT issues — alg:none, alg confusion HS/RS, missing exp claim, sensitive data in payload, signing secret in source
OWASP A08 Software and Data Integrity Failures
- Software and data integrity failures — deserialization, CI/CD compromise, supply chain
- Java ObjectInputStream without type restrictions — gadget chains (Apache Commons Collections)
- Python pickle.loads() on untrusted data
- PHP `unserialize()` on user input
- Node.js node-serialize
- CI/CD pipeline integrity — unsigned artifacts, compromised build servers
- SolarWinds-style supply chain — build pipeline compromise
- Auto-update without signature verification
OWASP A09 Security Logging and Monitoring Failures
- Logging and monitoring failures — missing events, sensitive data in logs, log injection, no alerts
- Missing logging for authentication events, privilege changes, access denials
- Logging sensitive data — passwords, credit card numbers, SSNs in logs
- Log injection — user input written to logs without sanitization; CRLF injection
- Insufficient log retention
- Missing alerts on suspicious patterns
OWASP A10 Server-Side Request Forgery (SSRF)
- SSRF — application fetches URL supplied by user; attacker directs server to internal resources
- SSRF targets — AWS IMDSv1 metadata (`169.254.169.254`), internal APIs, Redis, Elasticsearch
- Code patterns — `requests.get(url)` user-supplied url, ImageMagick URL fetching, PDF generators fetching remote URLs
- Bypass techniques — DNS rebinding, IP representation variations (0x7f000001), redirects
- Prevention — allowlist of permitted external domains; block internal IP ranges; IMDSv2
Beyond OWASP Top 10
- XML External Entity (XXE) — XML parser loading external entities from user-controlled content; `<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>`; prevention disable external entity processing
- SSRF in depth — bypasses, cloud metadata exploitation
- Business Logic — race conditions, workflow bypass, price manipulation
- OAuth 2.0 / OIDC vulnerabilities — open redirect in redirect_uri, state CSRF bypass, token leakage via Referer, authorization code interception
- GraphQL security — introspection exposure, batching attacks, injection
- WebSocket security — missing origin validation, injection through WebSocket messages
OWASP ASVS (Application Security Verification Standard)
- ASVS Level 1 — automated testing baseline; covers the most critical controls
- ASVS Level 2 — standard for most applications; manual testing required
- ASVS Level 3 — critical systems (banking, healthcare, government); full assessment
- Using ASVS as a code review checklist and design requirement document
- Mapping ASVS requirements to developer tickets and security stories
Resources
- OWASP Testing Guide (free)
- PortSwigger Web Security Academy (free, the best web security learning resource)
- DVWA, WebGoat, OWASP Juice Shop (all free practice targets)
- "The Web Application Hacker's Handbook" (book)
Stage 02
Security Fundamentals
AppSec engineers operate in a security context. Network security, authentication protocols, cryptography, and threat concepts inform design recommendations.
Core Concepts
- CIA Triad; defense in depth; least privilege; secure by default
- Authentication protocols — OAuth 2.0, OIDC, SAML 2.0, JWT in depth
- Cryptography — symmetric/asymmetric, hashing, signing, TLS, PKI
- Network security — firewalls, WAF, API gateways, TLS termination
- Cloud security — IAM, security groups, secrets management, cloud-native services
- MITRE ATT&CK — application layer techniques; web shell (T1505.003), exploitation (T1190)
- Supply chain security — dependency confusion, typosquatting, build pipeline compromise
- Bug classes — memory safety (buffer overflow, UAF), logic flaws, injection, cryptographic failures
Certification
- CompTIA Security+
Resources
- Professor Messer Security+ (free YouTube)
- OWASP Cheat Sheet Series (free)
Stage 03
Threat Modeling
Threat modeling is the most senior and differentiating AppSec skill. It identifies security requirements before code is written, moving the cost of fixing vulnerabilities from production to design.
Why Threat Modeling Matters
- Cheapest time to fix a vulnerability: in design, before implementation; most expensive: after production deployment or breach
- Threat modeling forces explicit security decisions at architecture stage
- Output: ranked list of threats with mitigations, driving security requirements
STRIDE Methodology
- S — Spoofing: identity faking; mitigations strong auth, non-predictable session IDs, signed tokens
- T — Tampering: data modification in transit/at rest; mitigations server-side validation, integrity checks, signatures
- R — Repudiation: denying actions; mitigations audit logging with user identity, non-repudiable signatures
- I — Information Disclosure: exposing data; mitigations generic error messages, structured logging, access control
- D — Denial of Service: making service unavailable; mitigations rate limiting, auth before expensive ops, resource limits
- E — Elevation of Privilege: gaining unauthorized access; mitigations server-side role enforcement, deny by default
Data Flow Diagrams (DFDs)
- DFD elements — processes (circles), data stores (parallel lines), external entities (rectangles), data flows (arrows), trust boundaries (dashed)
- Drawing a DFD — identify modeling scope, external entities, processes, data stores, draw flows, identify trust boundaries (where data crosses security zones)
- Applying STRIDE at each trust boundary crossing
PASTA (Process for Attack Simulation and Threat Analysis)
- PASTA — seven-stage risk-centric methodology; more comprehensive than STRIDE; used for high-value features
- PASTA stages — define business objectives, technical scope, app decomposition (DFD), threat analysis, vulnerability analysis, attack modeling, risk and impact analysis
Attack Trees
- Attack trees — hierarchical decomposition of attacker goals; root = goal, child = methods, AND/OR nodes; useful for prioritizing mitigations against likely attack paths
Threat Modeling in Practice
- When to threat model — new features, significant architecture changes, new third-party integrations
- Participants — AppSec engineer, lead developer, architect, product manager
- Duration — 1–3 hours for a focused feature; can be iterative
- Output — threats documented in issue tracker with severity, mitigation, and acceptance decision
- Tools — Microsoft Threat Modeling Tool (free, generates STRIDE from DFD), OWASP Threat Dragon (open-source), Miro/Lucidchart
Resources
- "Threat Modeling: Designing for Security" by Adam Shostack (book)
- OWASP Threat Modeling Cheat Sheet (free)
- Microsoft SDL Threat Modeling (free documentation)
- Adam Shostack's blog (free)
Stage 04
Security Testing Tooling
AppSec engineers configure, tune, integrate, and interpret output from security testing tools. Tool operation without interpretation is useless. You must understand what the tool found and why.
SAST (Static Application Security Testing)
- What SAST does — analyzes source code without executing it; finds patterns matching known vulnerability classes
- False positive management is the primary operational challenge; tuning rules to reduce noise
- Semgrep — rule-based; custom rule writing in YAML (pattern, metavariable, message, severity, languages, fix); registry rules, CI integration, triage workflow
- Checkmarx — enterprise SAST; deep taint analysis; complex inter-procedural analysis
- Veracode — SaaS SAST; policy-based; integrates with SDLC; pipeline scan mode
- SonarQube — combines SAST + code quality; community edition free; quality gates blocking builds; security hotspots vs confirmed vulns
- GitHub Advanced Security / CodeQL — GitHub-native; QL query language for custom rules
- Fortify — enterprise; common in financial services and defense
- SAST best practices — run on every PR not just scheduled, break build only on critical, track FP rate, custom rules for tech stack
DAST (Dynamic Application Security Testing)
- What DAST does — tests the running application from outside; black-box; finds runtime issues
- Burp Suite Pro — primary manual web security testing tool; Proxy, Scanner, Intruder, Repeater, Collaborator, extensions (Active Scan++, J2EEScan, Autorize)
- OWASP ZAP — free, open-source; CI/CD-friendly; active scan, passive scan, ZAP API, Ajax Spider for SPAs
- Nuclei — template-based fast scanner; community templates for known CVEs and misconfigs
- Nikto — web server scanner; checks for misconfigurations and outdated software
- DAST in CI/CD — staging deploy → scan → gate; authenticated scans for deeper coverage; API scanning configs
SCA (Software Composition Analysis)
- What SCA does — identifies known vulnerable dependencies; license compliance
- Snyk — SaaS SCA; developer-friendly; auto-generated fix PRs; CLI snyk test, snyk monitor
- Dependabot — GitHub-native; automated security update PRs
- OWASP Dependency-Check — open-source; CVE matching against NVD
- Black Duck (enterprise; comprehensive license/security analysis); Mend (formerly WhiteSource, enterprise SCA)
- SCA best practices — block on critical/high CVEs in direct deps, review transitive deps, pin versions in lockfiles, generate SBOM (SPDX/CycloneDX)
Secrets Detection
- Tools — GitLeaks, truffleHog, GitHub Secret Scanning, Detect-Secrets
- Pre-commit hooks — catching secrets before they're committed
- Historical repo scanning — checking git history for committed secrets
- Secret rotation after detection — treating any committed secret as compromised
IaC Security
- IaC scanners — Checkov, tfsec, KICS, Terrascan
- IaC checks — open security groups, public S3 buckets, unencrypted storage, missing logging, overprivileged IAM
- Integrating IaC scans into Terraform and CloudFormation pipelines
Container Security
- Image scanning — Trivy, Snyk Container, Clair, Anchore
- Dockerfile best practices — non-root user, minimal base image, no secrets in layers
- Kubernetes security — RBAC, network policies, pod security standards, admission controllers
Resources
- PortSwigger Web Academy (free)
- OWASP ZAP documentation (free)
- Semgrep documentation (free)
- Snyk Learn (free)
Stage 05
Secure SDLC and DevSecOps Integration
AppSec engineers build the security program around the development workflow. Security that blocks developers gets bypassed. Security that helps developers gets adopted.
CI/CD Pipeline Security Integration
- Shift-left principle — catching security issues earlier in the pipeline is cheaper
- Pipeline gates — block on critical no-exception, warn on medium with ticket, inform on low
- Pipeline stages — pre-commit secrets, PR SAST scan, build SCA, container image scan, IaC scan, staging DAST, production runtime monitoring (RASP/WAF)
- GitHub Actions — `.github/workflows/security.yml`; codeql-action, snyk/actions, securego/gosec, owasp/zap-action
- GitLab CI — `.gitlab-ci.yml` security stages; GitLab Ultimate built-in SAST/DAST/SCA/secrets
API Security
- REST API security — Bearer/JWT/API keys/OAuth 2.0; rate limiting per IP/user/endpoint; schema input validation; output filtering; mass assignment allowlist; versioning
- GraphQL security — disable introspection in prod, query depth limit, query complexity limit, batching attack prevention, subscription auth on WebSocket upgrade
- OWASP API Security Top 10 — API-specific vulnerability categories
Secrets Management
- HashiCorp Vault — dynamic secrets, PKI, encryption as a service
- AWS Secrets Manager / Parameter Store — cloud-native secrets storage
- Azure Key Vault — Azure-native secret storage
- Principles — no secrets in code, no secrets in env vars (12-factor debate), rotation automation; secrets injected at runtime from vault
Security Champions Program
- Embedding security advocates within development teams; champion responsibilities, enablement, metrics (time to remediation, FP rate, engagement)
Developer Education
- Secure coding guidelines — language-specific reference documents
- Developer security training — OWASP WebGoat, Secure Code Warrior, HackEDU
- Brown bag sessions — 30-minute focused talks on specific vulnerability classes
- Security reviews as learning opportunities — explaining WHY, not just WHAT to fix
- Reducing security friction — good error messages from SAST, actionable findings
Certification
- CSSLP (Certified Secure Software Lifecycle Professional, (ISC)²) — most recognized AppSec lifecycle cert; required at many enterprises
Resources
- OWASP DevSecOps Guideline (free)
- "DevSecOps" by Jim Bird (book)
- Snyk Learn platform (free)
- GitHub Actions documentation (free)
Stage 06
API and Modern Architecture Security
Modern applications are APIs, microservices, and cloud-native. AppSec engineers must understand these architectures deeply.
Microservices Security
- Service-to-service authentication — mTLS, service mesh (Istio/Linkerd)
- Zero trust in microservices — every service authenticates every call; no implicit trust
- Service mesh security — Istio authorization policies; Envoy proxy
- Secret propagation — Kubernetes secrets, external secrets operator, vault agent injection
- Network policies — Kubernetes NetworkPolicy; restricting lateral movement
- Sidecar injection — security tooling deployed alongside application containers
Container and Kubernetes Security
- Pod security standards — Restricted, Baseline, Privileged
- RBAC — least privilege for service accounts; no cluster-admin for app service accounts
- Admission controllers — OPA/Gatekeeper, Kyverno — policy enforcement at deploy time
- Image signing — Cosign, Notary — verifying image provenance
- Runtime security — Falco, Sysdig — detecting anomalous container behavior
- Secrets in Kubernetes — external-secrets-operator vs Kubernetes secrets (not encrypted at rest by default)
Cloud Security Posture for AppSec
- AWS — IAM least privilege for applications; no EC2 instance profile with admin; Secrets Manager; S3 bucket policies
- Azure — Managed identities instead of service principals with passwords; Key Vault references
- GCP — Workload Identity Federation; Secret Manager
- Cloud-specific SSRF — IMDSv1 vs IMDSv2; blocking metadata endpoint from application
Resources
- OWASP Kubernetes Security Cheat Sheet (free)
- Kubernetes documentation (free)
- AWS Well-Architected Security Pillar (free)
Stage 07
Vulnerability Management and Bug Bounty
AppSec engineers own the vulnerability lifecycle, from discovery through remediation verification.
Vulnerability Triage
- CVSS — base, temporal, environmental scores; v3.1 and v4.0 attack vector / complexity / privileges / interaction / scope / impact
- Contextual severity adjustment — internal-only RCE may be lower priority than public auth bypass
- False positive identification — SAST findings that require manual validation
- SSVC (Stakeholder-Specific Vulnerability Categorization)
- EPSS (Exploit Prediction Scoring System) — probability of exploitation in 30 days
- KEV (CISA Known Exploited Vulnerabilities) catalog — actively exploited
Vulnerability Remediation Workflow
- Ticket creation with context — what it is, where it is, why it matters, how to fix it
- SLA definition — critical 24h, high 7d, medium 30d, low 90d
- Developer interaction — explaining vulnerabilities in developer terms; code-level guidance
- Remediation verification — retesting after fix; confirming the fix is correct (not just symptom-treating)
- Exception process — accepting risk with compensating controls and documented approval
Bug Bounty Program Management
- Program scope — what is in scope (domains, APIs, mobile apps); what is out of scope
- Reward tiers — based on severity and impact
- Triage workflow — validating, reproducing, responding to researcher submissions
- Disclosure coordination — managing public disclosure timelines
- Hacker-facing communication — clear, respectful, timely responses
- Platforms — HackerOne, Bugcrowd, Intigriti, self-hosted
Pen Test Coordination
- Scoping — agreeing on targets, timeframe, testing type (black/grey/white box)
- Brief document — network architecture, known issues, testing rules of engagement
- During testing — handling questions, managing impact on production
- Report review — validating findings, providing remediation guidance
- Verification testing — confirming fixes from pen test findings
Resources
- CVSS calculator (first.org, free)
- EPSS data (first.org, free)
- HackerOne Hacktivity (free, with real bug reports)
- CISA KEV (free)
Stage 08
Hands-On Practice & Portfolio
Practice Targets
- OWASP Juice Shop — intentionally vulnerable Node.js app; comprehensive OWASP coverage
- DVWA — PHP; classic injection vulnerabilities
- WebGoat — Java; guided learning with hints
- HackTheBox / TryHackMe — web challenges and machines
- PortSwigger Web Security Academy — best free structured web security learning; labs for every vuln class
- Bug bounty — HackerOne and Bugcrowd public programs; VDP
Build and Document
- Secure code review exercises — clone OSS, audit for OWASP Top 10, submit responsible disclosure
- Custom Semgrep rules — write for tech stack patterns; publish on GitHub; document FP rate
- CI/CD security pipeline — GitHub Actions integrating SAST + SCA + secrets + DAST; document config tradeoffs
- Threat model documentation — DFD + STRIDE + mitigations + trust boundaries + prioritized list
What to Document on LabList
- Vulnerability research write-ups — responsible disclosure findings with timeline
- Custom security tooling — Semgrep rules, automation scripts, scanning pipelines on GitHub
- CTF web challenges — PortSwigger Academy completion, HackTheBox web writeups
- Threat model examples — demonstrating design-stage security thinking
- Cert progression — Security+ → eWPT or GWAPT → CSSLP documented with context
FAQ
Common questions
How long does it take to become an AppSec Engineer?
2–3 years if you're coming from a developer background and put in 20–25 hours/week. 3–4 years realistic for the security-to-AppSec path because you have to build programming fluency from scratch. The developer-to-AppSec route is meaningfully faster — AppSec engineers review code in pull requests every day, and you have to read code faster than developers write it. Security analysts who can't read code are not AppSec engineers, regardless of years in the industry.
What certifications do AppSec employers actually require?
CSSLP is the most-listed AppSec lifecycle cert and validates secure development across the SDLC. eWPT or GWAPT validate offensive web testing depth. CISSP and CCSP holders earn $147K+ on average. Cert frequency in 2025–2026 postings: CSSLP, GWAPT, OSWE, OSCP, Security+ as baseline, then AWS Security Specialty or AZ-500 at cloud-heavy organizations. The cert that hurts you to skip is CSSLP for senior roles. Everything else is supportive.
Do I need a CS degree to break in?
No, but you absolutely need programming fluency in at least one of Python, Java, JavaScript, or Go — tested in every AppSec interview. Bootcamp grads with strong portfolio work do fine. Self-taught developers who built real applications and then specialized into security do better than CS grads with no shipping experience. The screen isn't 'do you have a degree' — it's 'can you read this codebase and identify the IDOR or SQL injection in 10 minutes.'
What separates a hired AppSec engineer from one who doesn't make it?
Custom Semgrep rules on GitHub. A complete threat model (DFD + STRIDE + mitigations) for a realistic application. Demonstrated developer fluency — can you read a pull request and identify three vulnerability classes in context? Generic OWASP knowledge without practical exploitation gets screened out. Tool literacy without interpretation gets screened out. The hiring signal is 'you'd add value on day one' — your portfolio answers that question or it doesn't.