Security Testing In The SDLC: Making SAST, DAST, And Code Review Part Of Normal Delivery

🎯 CISSP Lens

Pick answers that align business risk, governance intent, and practical control execution.

Security testing in the SDLC means embedding checks for security quality into the same processes where functional quality is tested.

Instead of relying only on late stage penetration tests or external scans, you.

• Define security requirements up front.
• Review designs for security implications.
• Test code for insecure patterns while it is being written.
• Exercise applications dynamically before and after deployment.

SAST in plain terms

Static Application Security Testing (SAST) analyzes source code or compiled artifacts without executing the program.

• It looks for known insecure patterns, such as SQL injection, hard coded secrets, or unsafe cryptography.
• It can run in developer IDEs, build pipelines, or both.
• It is effective for catching certain classes of issues early, particularly input validation and data handling problems.

Strengths.

• Finds issues before code runs, which reduces fix costs.
• Provides direct links to offending lines of code, useful for developers.

Limitations.

• Can generate false positives if rules are too generic.
• May struggle with environment specific issues or runtime configuration.

DAST in plain terms

Dynamic Application Security Testing (DAST) analyzes a running application from the outside.

• It sends HTTP or other protocol requests to the application and inspects responses.
• It behaves similarly to an automated attacker, probing for injection, authentication flaws, and misconfigurations.

Strengths.

• Reflects how the application behaves at runtime.
• Can detect issues that depend on deployment context.

Limitations.

• Requires a deployed environment, often a test or staging system.
• May miss issues in code paths that are hard to reach automatically.

IAST and RASP briefly

Interactive Application Security Testing (IAST) combines aspects of SAST and DAST by instrumenting the application while it runs. Runtime Application Self Protection (RASP) adds protection logic inside the application to block certain attacks.

For CISSP, you need a high level understanding, not tool specific details.

Manual code review and threat modeling

Automated tools are powerful, but they do not replace human analysis.

• Manual secure code review allows experienced reviewers to find logic issues, complex authorization flaws, and business logic abuse cases that tools miss.
• Threat modeling at design time helps teams think through assets, threats, and mitigations before code is written.

These activities complement automated SAST and DAST.

📋 Domain cross-reference

📋 Domain cross-reference

Domain 6 cares about where and how you apply testing in the SDLC, and how it supports overall risk management.

Key ideas.

• Shift left when it makes sense. The exam favors answers that find and fix issues early in the lifecycle, provided they are realistic for the organization.
• Use multiple techniques. SAST, DAST, manual review, and threat modeling each cover different types of risk. Relying on one alone leaves gaps.
• Integrate with processes. Security tests that run automatically in CI pipelines or as part of definition of done are more sustainable than ad hoc scans.
• Support developers. Successful programs treat developers as partners by providing clear guidance, training, and manageable findings.

When choosing between options in exam questions.

• Pick SAST when the goal is to find insecure coding patterns before deployment.
• Pick DAST when the goal is to test a running application from an external perspective.
• Pick manual code review or threat modeling for complex or high risk features that require human judgment.

A product team at a SaaS company builds a customer portal. Security is involved only at the end, when an external penetration test finds several injection flaws and broken access controls. The release is delayed, customers are unhappy, and developers are frustrated by last minute changes.

The security architect proposes a new approach for the next phase.

• During requirements, the team adds security user stories and nonfunctional requirements, such as input validation, logging, and access control rules.
• In design reviews, the architect and lead engineer perform lightweight threat modeling to identify likely attack paths.
• Developers enable SAST in their IDEs and build pipeline, focusing on a small set of high value rules to start.
• A DAST scan is integrated into the pre production environment before each major release.
• The team conducts targeted manual code reviews for critical modules, such as authentication and payment flows.

Within two release cycles.

• The number of critical findings in external tests drops significantly.
• Developers report that most issues are caught by SAST and code review before reaching staging.
• The business sees fewer last minute surprises and more predictable delivery.

Common pitfalls when bringing security testing into the SDLC include.

⚠️ Watch for this mistake: Tool first thinking. Buying SAST or DAST tools without planning workflows, ownership, or developer training.

⚠️ Watch for this mistake: Turning on every rule. Enabling full rule sets from day one, overwhelming teams with false positives and noise.

⚠️ Watch for this mistake: No prioritization. Treating minor style issues with the same urgency as exploitable vulnerabilities.

⚠️ Watch for this mistake: Ignoring dependencies. Failing to scan third party libraries, frameworks, and open source components.

⚠️ Watch for this mistake: No release criteria. Lacking clear thresholds for when security defects block a release, leading to inconsistent decisions.

To integrate security testing into your SDLC.

• ✅ ✅ Map your current SDLC phases and identify where functional testing already occurs.
• ✅ ✅ Choose one or two high value applications as pilots for SAST and DAST integration.
• ✅ ✅ Start with a small, focused SAST rule set targeting your top risk issues, such as injection and authentication problems.
• ✅ ✅ Integrate SAST into the build pipeline with clear feedback to developers, and provide training on how to fix common findings.
• ✅ ✅ Add DAST scans to a stable test or staging environment, aligned with release candidates.
• ✅ ✅ Establish severity levels and define which levels will block releases, with a documented exception process.
• ✅ ✅ Plan manual code review and threat modeling for the highest risk components instead of trying to review everything.
• ✅ ✅ Track metrics such as number of critical findings per release and time to remediate to demonstrate improvement.

• 💡 💡 Effective Domain 6 practice includes security testing throughout the SDLC, not just at the end.
• 💡 💡 SAST, DAST, manual review, and threat modeling each solve different parts of the problem and should be combined thoughtfully.
• 💡 💡 Integration into developer workflows and CI pipelines is critical for sustained adoption.
• 💡 💡 Starting small, prioritizing high value rules, and supporting developers leads to better outcomes than heavy, tool driven rollouts.
• 💡 💡 For CISSP, favor answers that align security testing with development processes and risk, not isolated one off scans.