The Secure SDLC, Threat Modeling and DevSecOps
The governing economics of software security are simple: the earlier a defect is found, the cheaper it is to fix, and a flaw caught in design costs a fraction of the same flaw found in production. That is why security is built into every phase of the development lifecycle rather than tested in at the end. Requirements gathering includes security requirements, design includes threat modeling, coding follows secure standards, and testing verifies the security requirements alongside the functional ones. DevSecOps carries the same principle into rapid delivery by automating those checks into the pipeline so speed does not mean skipping them.
Exam tip. When a question asks where a security flaw is cheapest to address, the answer is always the earliest phase offered, usually requirements or design. Threat modeling belongs in design and not after deployment, and if a scenario has developers deploying their own code straight to production, the control being asked for is separation of duties in the release process.
Development Methodologies and Maturity Models
The exam expects you to recognize development methodologies by their defining characteristic and to understand what each one implies for security. Waterfall runs sequentially with formal gates, which makes it documentation-heavy and slow to accommodate change. Agile delivers in short iterations and adapts continuously, which means security has to be present in every sprint rather than at a single checkpoint. Spiral is explicitly risk-driven, evaluating risk at every loop. Alongside these sit maturity models, which do not describe how you build software but how consistently and repeatably your organization does it.
Exam tip. Spiral is the answer whenever risk analysis at each iteration is described. If the stem mentions requirements that will not change and heavy documentation, it is Waterfall, and if it mentions frequent small releases with evolving requirements, it is Agile. Remember that CMMI measures process maturity, so a level 5 organization can still ship an insecure product.
Common Application Vulnerabilities and Their Defenses
Most application vulnerabilities come from one of two failures: trusting input that came from outside, or failing to check on the server that the requester is entitled to what they are asking for. Injection flaws happen when user input is treated as instructions instead of data. Cross-site scripting happens when input is returned to a browser and executed. Overflow conditions happen when the amount of input is never bounded. Access control flaws happen when the check exists only in the interface and not behind it. Learn the defenses as a small set of habits, because the same handful of practices removes entire families of defect.
Exam tip. Any answer that relies on client-side validation as a security control is wrong, because the client is under the attacker's control. Prefer allowlisting over blocklisting whenever both appear as options, and for database access the expected answer is parameterized queries rather than escaping or filtering the input by hand.
Database Security: Inference, Aggregation and Transaction Integrity
Databases raise a problem the rest of application security does not: a user can be perfectly authorized for every individual item they touch and still end up knowing something they were never meant to know. Aggregation is collecting many permitted facts until the collection itself becomes sensitive, and inference is deducing a protected fact from permitted ones. Neither involves any unauthorized access, which is why access control alone does not solve them. Alongside that sits the integrity side of database security, where transactions must complete reliably and concurrent users must not corrupt each other's work.
Exam tip. The distinction is tested directly: if the user gathered many pieces until the pile was sensitive, that is aggregation, and if they reasoned their way to a fact they never saw, that is inference. Polyinstantiation is the specific answer to inference. Also note that transparent database encryption does nothing against a compromised authorized account, since queries still return plaintext.