AppSec Process & Architecture
At the senior level, security is not a list of attacks but a process and an architecture: how to build controls into the development lifecycle, how to find threats in advance by design, how to assess and prioritize what is found, and how to design a system resilient to the compromise of individual parts. Here you think not in "vulnerabilities" but in stages, impact, and trust boundaries.
The traps at this level are about substituting a process with a point measure: "security is one pentest before release", "any SQLi is critical out of context", "TLS covers everything", "DBMS encryption protects data from admins". Each fails the systems question. The breakdown is by layers: from a secure SDLC to protecting data under segregation of duties.
Topic map
- Secure SDLC — shifting left and which control (
SAST,SCA,DAST, fuzzing, pentest) at which stage. - Threat modeling — a systematic enumeration of vectors, mapping each to a server-side control.
- Secure file upload — ranking vectors by impact and defending the upload flow.
- Vulnerability triage — assessing severity by real impact, not by vulnerability class.
- Production intake questions — what to establish with the team before shipping a system to production.
- Segregation of duties — protecting data from the DB admins themselves at the application layer.
Common traps
| Mistake | Consequence |
|---|---|
| Reducing security to one pentest before release | Defects reach production; cheap early checks are skipped |
Confusing the SAST (code) and DAST (running app) stages | The control is placed where it sees nothing |
| Ranking vectors by ease of attempt, not by impact | A trifle at the top, RCE via upload left "for later" |
| Setting severity by vulnerability class out of context | Every SQLi is "critical", severity detached from real impact |
| Relying on DBMS encryption against DB admins | The engine decrypts on read — the admin sees the data |
| Treating a login as sufficient authorization to an object | IDOR — access to someone else's account with a valid session |
Interview relevance
This is a high-priority topic for senior roles: it tests systems thinking, not knowledge of individual attacks. A candidate who maps a control to a stage, rates a bug by impact, and designs defense against a privileged insider looks like an engineer you can trust with the architecture.
Typical checks:
- Where in the
SDLCSAST,SCA,DAST, fuzzing and pentest apply, and why there. - How to systematically enumerate vectors (threat modeling) and map each to a server-side control.
- How to assess a finding's severity by impact, accounting for least privilege.
- What to ask before shipping a system to production and how to protect data from DB admins.
Common wrong answer: "slap on a WAF and TLS, and order a pentest before release — that's enough". In fact security is built in at every stage, impact sets severity, and perimeter measures do not replace server-side authorization, segregation of duties, and early code review.