Security Architecture · Topic 3 of 12
Secure SDLC and Security Testing
Build security into each life cycle phase, from requirements and threat modeling to SAST, DAST, IAST, SCA, fuzzing and CI/CD pipeline gates.
- 4 min
- Security belongs in every SDLC phase, and earlier is cheaper.
- Threat modeling belongs in design, and security requirements belong at the start.
- SAST reads code, DAST tests the running app, IAST observes from inside the running app, SCA checks dependencies.
What it is
The systems development life cycle (SDLC) is the sequence of phases a system passes through: requirements, design, development, testing, deployment, operation and retirement. A secure SDLC adds security work to every phase instead of testing only at the end.
Finding a flaw at the design stage is far cheaper than finding it in production. This idea is called shifting left, and it is the main reason to integrate security early.
How it works
Security at each phase
| Phase | Security activity |
|---|---|
| Requirements | Capture security and privacy needs, compliance duties and abuse cases |
| Design | Threat modeling, secure architecture review, choose proven components |
| Development | Secure coding standards, peer review, secrets kept out of code |
| Testing | Static, dynamic and interactive analysis, fuzzing, penetration testing |
| Deployment | Hardened configuration, signed artifacts, separation of duties |
| Operation | Monitoring, patching, vulnerability management, incident response |
| Retirement | Data removal, access revocation and secure disposal |
Development models differ. Waterfall completes phases in order, so security gates fall at phase ends.
Agile repeats short cycles, so security tasks must fit into each sprint. The security activity is the same, but the timing differs.
Secure coding practices
The following practices prevent the most common weaknesses.
- Input validation: treat all input as untrusted and check type, length and format.
- Output encoding: encode data for its destination to stop cross site scripting (XSS).
- Parameterized queries: keep data separate from commands to prevent injection attacks such as Structured Query Language (SQL) injection.
- Authentication and session handling: use proven libraries instead of custom code.
- Error handling: show users a generic message and log detail privately.
- Least privilege: run code with only the permissions it needs.
- Secrets management: keep keys and passwords in a vault, not in source code.
Testing techniques
| Technique | Looks at | When | Typical strength |
|---|---|---|---|
| Static application security testing (SAST) | Source code or binaries without running them | Early, in the build | Finds flaws early, can give false positives |
| Dynamic application security testing (DAST) | A running application from outside | Test or staging | Finds runtime and configuration issues |
| Interactive application security testing (IAST) | A running application using instrumentation inside it | During testing | Precise results with code context |
| Software composition analysis (SCA) | Third party libraries and their known flaws | Build and ongoing | Finds vulnerable and license risky dependencies |
| Fuzzing | Random or malformed input sent to a program | Test | Finds crashes and unexpected handling |
| Penetration test | A skilled tester simulating an attacker | Before release and periodically | Finds chained and business logic flaws |
No single tool covers everything. SAST cannot see runtime configuration, and DAST cannot see code that is never reached by its requests.
CI/CD pipeline and DevSecOps
Continuous integration and continuous delivery or deployment (CI/CD) automates build, test and release. DevSecOps places automated security checks in this pipeline so that every change is scanned.
A gate blocks a release when a rule fails, such as a critical vulnerability or an exposed secret. Pipeline credentials are high value targets, so protect them with least privilege, short lived tokens and logging. Separate environments for development, test, staging and production keep unfinished code away from live data.
Baselines and verification
Build servers and deployed hosts start from a hardened baseline. Configuration is stored as code and reviewed like any code. Before release, verify that requirements were met by tracing each security requirement to a test result.
What to remember for the exam
- Security belongs in every SDLC phase, and earlier is cheaper.
- Threat modeling belongs in design, and security requirements belong at the start.
- SAST reads code, DAST tests the running app, IAST observes from inside the running app, SCA checks dependencies.
- Fuzzing sends malformed input to find crashes and parsing flaws.
- Parameterized queries stop SQL injection, and output encoding stops XSS.
- Secrets should not live in source code or repositories.
- Pipeline gates should block releases that fail security rules.
- Protect the CI/CD system itself, because it can push code to production.
When the question says the team found a flaw late and wants to find similar flaws earlier, choose the shift left answer, such as SAST in the build or a design time threat model.
Common mistakes
Relying on one test type. SAST and DAST find different problems and should be combined.
Treating a clean scan as proof of security. Automated tools miss business logic flaws and chained attacks.
Ignoring false positives. If the team stops trusting the tool, real findings get ignored, so tune rules and triage.
Testing in production only. Dynamic tests against live systems risk outages, so use staging with realistic but protected data.
Forgetting retirement. Old systems keep data and accounts that attackers can still use.
Hard coded credentials in a repository stay in version history after deletion, so rotate any exposed secret.
Check yourself
Work through these three questions.
Which test examines source code without running the application?
Static application security testing (SAST).
What does software composition analysis find?
Known vulnerabilities and license issues in third party libraries and components used by the application.
Why shift security left?
Fixing flaws at requirements and design stages costs much less than fixing them after release.
Topic 3 of 12 in Security Architecture
Test yourself on Security Architecture
The full CompTIA SecurityX CAS-005 question bank has 654 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by CompTIA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.