Module 40: Secure SDLC: Coding and Testing

CCSP Domain 4 — Cloud Application Security Section A 6–8 min read

The CCSP exam expects you to understand that secure coding is a developer responsibility and that automated testing tools cannot replace secure coding practices — they complement them.

Secure Coding Principles

The exam tests whether developers follow fundamental secure coding practices:

Input validation — validate all input on the server side, never trust client-side validation alone
Output encoding — encode data before rendering in HTML, SQL, or OS commands to prevent injection
Parameterized queries — use prepared statements for all database interactions
Error handling — catch exceptions gracefully without exposing internal details
Secure defaults — deny access by default, require explicit grants
Secrets management — never hardcode credentials; use vault services

The exam consistently tests input validation as the root defense against injection attacks. If a scenario describes any form of injection, check whether input validation was the missing control.

Security Testing in the SDLC

The exam expects you to differentiate testing methodologies and when to apply them:

SAST (Static Application Security Testing) — analyzes source code without executing it. Finds vulnerabilities early in development. High false positive rate
DAST (Dynamic Application Security Testing) — tests the running application by sending crafted requests. Finds runtime vulnerabilities. Cannot see source code
IAST (Interactive Application Security Testing) — combines SAST and DAST by instrumenting the application during testing
SCA (Software Composition Analysis) — identifies vulnerabilities in third-party libraries and dependencies
Penetration testing — manual testing by security professionals simulating real attacks

Exam pattern: SAST is for code review (shift left). DAST is for runtime testing. SCA is for dependency management. If the question asks about finding vulnerabilities in open-source libraries, the answer is SCA.

Code Review Practices

Manual code review complements automated tools:

Peer review catches logic flaws that automated tools miss
Security-focused code review applies a threat perspective to code changes
Automated tools find pattern-based vulnerabilities; humans find design flaws
Code review should be mandatory for security-sensitive components

The exam may ask whether automated tools can replace manual review. The answer is always no — they are complementary. Tools find common patterns; humans find business logic vulnerabilities.

CI/CD Pipeline Security

Modern cloud development uses CI/CD pipelines. The exam tests security integration:

SAST runs on every commit (pre-merge gate)
SCA checks for vulnerable dependencies before build
Container image scanning before registry push
DAST runs against staging environments
Secrets scanning prevents credential leaks in code
Infrastructure-as-Code scanning validates cloud configurations

If the exam asks WHERE in the pipeline to catch a hardcoded API key, the answer is secrets scanning in the pre-commit or pre-merge stage. If it asks WHERE to find a runtime SQL injection, the answer is DAST against a staging environment.