Secure SDLC, SAST, and DAST Tools

The Secure Software Development Lifecycle (SSDLC) integrates security activities into every phase of software development — from requirements through design, coding, testing, deployment, and maintenance. The traditional SDLC treats security as a final-stage gate, which is expensive and ineffective. The secure SDLC philosophy is to find and fix vulnerabilities as early as possible, because defects caught during design cost far less to fix than those found in production.

Shift left means moving security earlier (to the left on the development timeline) rather than bolt it on at the end. In practice, this means including security requirements in user stories, conducting threat modeling during design, performing code review and SAST during development, and running DAST before release. Teams that shift left discover vulnerabilities when they are cheapest to fix — during development, not in production.

Threat modeling systematically identifies and documents security threats during the design phase. The STRIDE model categorizes threats into: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric methodology that simulates attacker objectives. Threat models produce prioritized mitigations before a single line of code is written.

SAST (white-box testing) analyzes source code, bytecode, or binaries without executing the application, searching for coding patterns associated with known vulnerabilities. SAST tools can scan the entire codebase quickly and report issues like hardcoded credentials, SQL injection sinks, and unsafe deserialization. They run inside the IDE or CI pipeline and report findings with file and line numbers, making remediation straightforward.

A key limitation of SAST is its tendency to produce false positives — flagging code as vulnerable when it is actually safe. This alert fatigue causes developers to dismiss findings without investigating them. SAST tools also cannot detect runtime configuration issues, authentication flaws that depend on runtime behavior, or vulnerabilities in third-party API calls. SAST is most effective when combined with developer training so findings are triaged accurately.

DAST (black-box testing) tests a running application by sending attack payloads to its HTTP endpoints and analyzing responses for vulnerability indicators. DAST does not require access to source code — it tests the application as an attacker would. It excels at finding runtime issues like authentication bypass, XSS reflected in responses, and server misconfiguration. DAST tools include OWASP ZAP, Burp Suite, and Netsparker.

SAST and DAST are complementary rather than competing. SAST finds code-level issues early and integrates with the IDE, but has no visibility into runtime behavior. DAST finds runtime vulnerabilities and requires no source code, but cannot scan code paths that are not triggered by its automated probes. Using both together — SAST in the CI pipeline and DAST against a staging environment — maximizes vulnerability coverage across the SDLC.

IAST combines aspects of both SAST and DAST by instrumenting the application at runtime. An IAST agent runs inside the application (on the server), observing code execution as test traffic flows through. It can correlate tainted user input through code paths to sensitive sinks — finding vulnerabilities with lower false-positive rates than pure SAST. IAST is particularly effective in Java and .NET applications and integrates naturally into functional test runs.

Software Composition Analysis (SCA) identifies open-source libraries and third-party dependencies in an application and checks them against vulnerability databases (NVD, OSV). Because modern applications may pull in hundreds of dependencies — many transitively — SCA tools like OWASP Dependency-Check, Snyk, and Renovate are essential to catch known CVEs before attackers exploit them in your supply chain.

Integrating security tools into CI/CD pipelines ensures that no code reaches production without passing security gates. A typical DevSecOps pipeline runs: SAST on every commit, SCA on dependency changes, container image scanning before pushing to registry, IaC scanning for Terraform/CloudFormation, and DAST against a staging deployment. Failed security checks block the build, enforcing a security-by-default culture.

Automated tools cannot replace human code review focused on security logic. Peer review should verify: authentication and authorization checks are in the right places, error handling does not leak sensitive information, cryptographic functions use approved algorithms and parameters, and business logic cannot be bypassed. Security champions within development teams — developers with security training — bridge the gap between the security team and engineering.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: the secure SDLC integrates security across all development phases rather than bolting it on at the end, SAST analyzes code without execution while DAST tests running applications, and SCA identifies vulnerable open-source dependencies and CI/CD security gates enforce findings automatically. Next up we explore directory services with LDAP and Active Directory.