During SDLC, when should security testing ideally begin?

A. After coding

B. During the design phase

C. After deployment

D. During user acceptance testing

Correct Answer: B

A. After Coding
Historically, many organizations waited until the "Testing" phase (after coding) to perform security scans.

The Drawback: This approach is reactive. If a fundamental architectural flaw is discovered at this stage—such as an insecure way of handling session tokens—developers may have to rewrite thousands of lines of code.

The Cost: Fixing a bug after coding is exponentially more expensive than fixing it during the planning stages. While tools like Static Analysis (SAST) start here, "testing" in the broader sense should have already begun.

B. During the Design Phase
In a "Secure SDLC" (S-SDLC), security testing begins as soon as the requirements are defined.

Threat Modeling: During the design phase, teams perform Threat Modeling (e.g., using STRIDE or PASTA). This is a form of "non-functional testing" where you test the logic and architecture of the system before a single line of code is written.

Why it's the Answer: Identifying a vulnerability in a whiteboard diagram is cheap and fast. By validating security requirements during design, you ensure that security is "baked in" rather than "bolted on."

C. After Deployment
Testing only after deployment is often referred to as "Penetrate and Patch."

The Risk: This is the most dangerous approach. At this stage, the software is already exposed to real-world attackers.

The Consequence: A vulnerability found here could result in a data breach, regulatory fines, and brand damage. Post-deployment testing (like Continuous Monitoring) is necessary, but it should never be the start of the process.

D. During User Acceptance Testing (UAT)
UAT is the final phase of testing before software goes live, where end-users verify that the system meets their functional needs.

The Conflict: While security should be verified during UAT (ensuring that a "regular user" cannot access "admin" functions), it is far too late to begin security testing.

The Bottleneck: Finding a major security hole during UAT usually results in a delayed release date, creating friction between the security team and the business stakeholders.

Key Takeaway: The "Shift Left" Principle
CISSP Concept: "Shifting Left" means moving security checks to the left side of the SDLC timeline (toward the beginning). The earlier you find a bug, the less it costs to fix. Security starts at the Requirements phase and becomes formal testing at the Design phase.