Adjusting Security Testing to Software Development Lifecycle Models asks how the development model changes the security testing work: sequential models, Agile, and DevOps with DevSecOps and the shift-left argument. The second half covers security testing during operations and maintenance: confirmation testing and security regression testing after a change, and analysing results to establish the nature of a vulnerability and its potential technical impact.
This is the second of the two chapters with an analysis-level (K4) objective: you are expected to analyse how security testing activities are affected by a given lifecycle model, and that question is worth more than an ordinary one. The failure mode is answering with slogans — "Agile means test earlier", "DevSecOps means automate everything". What is being examined is the consequence: release cadence changes how much test time exists per change, pipeline automation changes which techniques are even feasible, and a long sequential phase changes when a finding can still be fixed cheaply.
Prepare by taking one model at a time and writing down what happens to test planning, environment availability, tooling and re-testing under it. Then compare the three side by side.
Confirmation testing vs security regression testing — proving that this fix works, versus proving that the fix broke no other security control.
Shift-left vs test-only-early — moving activities earlier does not delete the later ones; operations and maintenance still need testing.
DevSecOps vs DevOps with a security team — the point is security embedded in the pipeline and shared ownership, not an added gate.
Nature of a vulnerability vs its technical impact — what kind of flaw it is, and what it would let an attacker achieve, are separate analysis outputs.
Iterative delivery is not automatically safer — short iterations reduce the cost of a fix but also compress the time available to test each change.
Maintenance changes trigger security testing — a patch, a configuration change or a new dependency version is a reason to re-test, not just a deployment.
Model affects activities, not objectives — the lifecycle reshapes timing, depth and automation; it does not change what a security control must guarantee.
This chapter is covered most heavily (4 questions) in CT-STE — Mock Exam 1 (Zero Trust, Access Control & Threat Modelling), CT-STE — Mock Exam 2 (Attacker Profiling, DevOps Pipelines & Standards as Oracles), CT-STE — Mock Exam 3 (Reconnaissance Analysis, Standards & Regression)