What is NOT a goal of Secure Software Development Life Cycle (SDLC)?

A. Code Quality
B. Cost Reduction
C. Secure Coding Practices
D. User Experience

Answer: D

Explanation:

A. Code Quality

In security, code quality and security are deeply linked.

•  The Relationship: High-quality code is typically more readable, maintainable, and predictable.  Poor quality code (spaghetti code) often hides logic flaws, buffer overflows, or race conditions. 

• The Tools: S-SDLC uses Static Application Security Testing (SAST) to scan source code for quality and security defects before the code is even compiled.  

B. Cost Reduction

It may seem counterintuitive that adding security steps reduces cost, but it is a fundamental tenet of the S-SDLC.

• The "Shift-Left" Principle: Finding a security vulnerability during the Requirements or Design phase is significantly cheaper than fixing it after the software has been deployed.

•  The Risk: A post-production fix requires emergency patching, regression testing, and potentially dealing with the massive legal and reputational costs of a data breach.  

C. Secure Coding Practices

This is the core "how-to" of the S-SDLC.

• The Goal: To ensure developers are trained to avoid common pitfalls like those found in the OWASP Top 10 (e.g., SQL Injection, Cross-Site Scripting).

•  The Implementation: This includes using "vetted" libraries, performing input validation, and practicing Least Privilege within the application's internal service accounts.  

D. User Experience (UX)

UX focuses on how a human interacts with the software—its ease of use, aesthetics, and efficiency.  

• Why it's the Answer: While UX is a primary goal of general software development, it is not a goal of the Secure SDLC. In fact, security and UX are often in "tension." For example, requiring a 16-character complex password with MFA (Security) makes the user experience slightly more difficult (UX).

• The Distinction: A secure app can have a terrible user interface, and a beautiful app can be full of security holes.