Which statement best describes the role of secure coding practices, such as input validation and output encoding, within the secure SDLC?
AThey are detective controls applied after deployment to identify vulnerabilities that reached production
BThey are corrective controls that automatically remediate exploited flaws in the running application
CThey are compensating controls used only when architectural security requirements cannot be met
DThey are preventive controls applied during implementation to stop classes of vulnerability from entering the codebasecheck_circle Correct
Classify secure coding practices as preventive controls applied during the implementation phase of the SDLC. Input validation, output encoding and similar secure coding techniques act before a vulnerability can exist, eliminating classes of defect such as injection and cross-site scripting as code is written. That makes them preventive controls tied to the implementation phase, distinct from detective, corrective or compensating controls applied later.
Why A is wrong: Detection after deployment describes monitoring or scanning, not secure coding. This confuses a preventive development practice with a later detective activity.
Why B is wrong: Automatic remediation at runtime is not what secure coding does. Secure coding prevents defects during development rather than correcting them after exploitation, so the category is wrong.
Why C is wrong: Compensating controls substitute for an unmet requirement. Secure coding is a baseline preventive practice expected throughout implementation, not a fallback, so this mischaracterises it.
Why D is correct: Secure coding practices are preventive measures used as developers write code, reducing whole classes of flaws such as injection at source. This correctly places them in the implementation phase.
Answers that look right on this material and are not. Each one is a distractor from a different question in the CCSP bank for this domain.
Static application security testing run against each pull request before it is approved
errorWhy it is wrong: Static analysis finds code weaknesses but does not by itself record or reverse changes to released components. It is a valuable secure-SDLC control aimed at a different problem.
Selecting a stronger symmetric cipher for encrypting payment data at rest
errorWhy it is wrong: Choosing a strong cipher matters for protecting card data and sounds security-focused, but it does nothing to stop a developer pasting a live access key into shared code.
Tampering, because the attacker is altering data that the service relies on to process the transaction
errorWhy it is wrong: Tampering covers unauthorised modification of data or code in transit or at rest. The described risk is about denying an action, not altering data, so this is the wrong category.