DevSecOps Zero to Hero: SAST, DAST, and SCA

Application security (AppSec) is the practice of embedding security controls, checks, and testing into the software development life cycle (SDLC). Without dedicated security testing, applications may pass functional and unit tests while containing critical vulnerabilities like hardcoded secrets, SQL injection vectors, or outdated dependencies that expose databases and infrastructure to bad actors.

1. Why Do We Need Application Security? (The Problem Space)

A standard, naive application development life cycle focuses primarily on feature delivery and basic operational correctness.

The Blind Spot in Traditional SDLC

• Absence of Security Gates: Developers may overlook security nuances (e.g., insecure SSL configurations, hardcoded database credentials) while rushing to meet feature deadlines.
• Human Error in Code Review: Peer code reviews often catch syntax and logic bugs, but easily miss subtle security flaws like SQL injection patterns or insecure deserialization.
• QA Limitations: While QA engineers perform functional, regression, performance, and basic penetration testing, their tooling is not designed to audit source code, inspect dependency vulnerability databases, or discover deep-seated architectural security flaws.

Note: Application Security (AppSec) bridges this gap by introducing automated scanning, dependency auditing, and runtime security testing into the development pipeline.

2. Core Mental Model: The Three Pillars of AppSec

To secure an application comprehensively, DevSecOps engineers deploy three complementary scanning methodologies. Each operates at a different stage of development and uses a distinct mechanism to uncover risks.

3. SAST (Static Application Security Testing)

Static Application Security Testing involves inspecting the application's source code, bytecode, or binary files without executing the program.

How SAST Works

• SAST tools parse code into Abstract Syntax Trees (ASTs) and run pattern-matching algorithms combined with heuristic rules.
• They identify insecure coding constructs, weak cryptographic functions, hardcoded API keys, and injection vulnerabilities before the code ever runs.

Popular SAST Use Cases & Vulnerability Patterns

1. Hardcoded Secrets: Credentials, API tokens, or private keys stored directly in code repositories.
2. SQL Injection (SQLi): Unsanitized user inputs concatenated directly into database queries.
3. Command Execution Risks: Executing system shell commands using unverified user inputs.
4. Insecure Deserialization: Unsafe handling of serialized object data from untrusted sources.
5. Weak Cryptography: Using deprecated hashing algorithms (e.g., MD5, SHA-1) or insecure random number generators (random.random()).

4. Practical Hands-On: Running SonarQube for SAST

In this demonstration, we deploy SonarQube Community Edition locally via Docker, configure a Python project, and execute a static code scan using the SonarScanner CLI.

Step 1: Spin Up SonarQube via Docker

Run a containerized instance of SonarQube mapping port 9000:

docker run -d \
  --name sonar-container \
  -p 9000:9000 \
  sonarqube:9.9-community

Note: Access SonarQube at http://localhost:9000 with default credentials admin / admin. You will be prompted to update your password on first login.

Step 2: Configure Project Properties (sonar-project.properties)

In the root directory of your target application (e.g., the Python web application folder), create a configuration file:

sonar.projectKey=vulnerable-python-app
sonar.projectName=Vulnerable Python Application
sonar.sources=.
sonar.language=py
sonar.host.url=http://localhost:9000
sonar.login=squ_your_generated_api_token_here

Step 3: Generate a User Token & Run SonarScanner

1. Navigate to User Profile -> My Account -> Security in the SonarQube UI and generate a new global analysis token.
2. Execute the scanner CLI from your project directory:

sonar-scanner \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.login=squ_your_generated_api_token_here

Interpreting SAST Findings

Upon successful analysis, the SonarQube dashboard reports code smells, bugs, and Security Hotspots. For example:

• CSRF Hotspot: Warns that state-changing HTTP methods (POST/DELETE) lacking anti-CSRF tokens may be vulnerable if cookie-based authentication is used. Developers review the context, determine if the risk applies, and mark it as Safe or issue a Jira remediation ticket.
• Weak Randomness: Flags the use of random.random() for generating cryptographic tokens, recommending secure alternatives like secrets module.

5. SCA (Software Composition Analysis)

Modern applications rely heavily on open-source libraries and frameworks. While developers declare a handful of direct dependencies, those packages pull in dozens of transitive (indirect) dependencies, creating a massive attack surface.

Why Manual Dependency Tracking Fails

If a Python application uses flask (version 1.2), and flask depends on 10 sub-libraries, each with their own dependencies, your total dependency graph quickly scales to hundreds or thousands of packages. Human review cannot manually track Common Vulnerabilities and Exposures (CVEs) across this entire tree.

SCA Mechanism

• SCA tools scan dependency manifest files (requirements.txt, package.json, go.mod, pom.xml).
• They map every direct and indirect package version against public vulnerability databases (such as the National Vulnerability Database - NVD).

6. Practical Hands-On: Auditing Dependencies with pip-audit

We use pip-audit to inspect Python project dependencies for known vulnerabilities.

Step 1: Create and Activate a Virtual Environment

python3 -m venv venv
source venv/bin/activate

Step 2: Install and Run pip-audit

Install the audit utility inside your virtual environment and scan the project's requirements.txt:

pip install pip-audit
pip-audit -r requirements.txt

Output Interpretation

pip-audit analyzes the dependency tree, flags outdated packages, and outputs exact CVE identifiers. Developers take these CVE numbers, research the patch notes on the NVD, and upgrade vulnerable packages to secure versions.

7. DAST (Dynamic Application Security Testing)

Dynamic Application Security Testing evaluates an application during runtime from the outside. Unlike SAST, DAST tools do not require access to the source code.

How DAST Works (Black-Box Testing)

• DAST tools treat the running application as a black box.
• They target the application's base URL and automatically crawl endpoints, submit forms, manipulate parameters, and bombard APIs with thousands of HTTP requests.
• They simulate how an external hacker probes a live website for misconfigurations, Cross-Site Scripting (XSS), CORS errors, and header omissions.

[DAST Tool (OWASP ZAP)]
         |
         | Sends thousands of crafted HTTP requests (GET/POST)
         v
[Running Target App (e.g., OWASP Juice Shop on Port 3000)]
         |
         | Returns responses & behavioral anomalies
         v
[DAST Tool parses responses & generates HTML Security Report]

8. Practical Hands-On: Running OWASP ZAP Against Juice Shop

OWASP Juice Shop is an intentionally vulnerable e-commerce web application designed for security testing and training.

Step 1: Deploy Vulnerable Target App (Juice Shop)

docker run -d \
  --name juice-shop \
  -p 3000:3000 \
  bkimminich/juice-shop

Step 2: Execute DAST Scan via CLI (Automation Framework)

Run OWASP ZAP in a containerized automated scan mode pointing to the local Juice Shop instance (host.docker.internal:3000), instructing it to output an HTML report:

docker run --rm \
  -v $(pwd):/zap/wrk/:rw \
  owasp/zap2docker-stable zap-baseline.py \
  -t http://host.docker.internal:3000 \
  -r zap-report.html

Step 3: Alternative UI-Based DAST Scan

To perform interactive scanning via the ZAP browser user interface:

docker run -u zap -p 8080:8080 -p 8090:8090 \
  owasp/zap2docker-stable zap.sh \
  -daemon -host 0.0.0.0 -port 8080 \
  -config api.disableKey=true

1. Open http://localhost:8080 in your browser.
2. Enter the target URL (http://host.docker.internal:3000) in the Automated Scan input field.
3. Click Attack to initiate active crawling and payload injection.

Analyzing the DAST HTML Report

The generated zap-report.html categorizes findings by risk level (High, Medium, Low, Informational):

• Cross-Domain Misconfiguration (CORS): Highlights improper Access-Control-Allow-Origin headers.
• Missing Content Security Policy (CSP): Flags unprotected script execution pathways.
• Vulnerable JavaScript Libraries: Identifies outdated npm modules (e.g., vulnerable express middleware versions) down to specific function names and source code line numbers.

9. Summary and Key Takeaways

• Application Security Integration: Securing the SDLC requires embedding automated testing tools alongside standard unit and functional tests.
• SAST (Static Analysis): Scans source code and configuration files without execution, catching hardcoded secrets, weak crypto, and SQL injection patterns early.
• SonarQube: A leading enterprise SAST platform that analyzes codebases, tracks security hotspots, and integrates with CI/CD pipelines.
• SCA (Software Composition Analysis): Audits direct and indirect third-party dependencies against public vulnerability databases (CVEs).
• pip-audit: A specialized Python utility used to scan project dependencies and transitive package trees for known security flaws.
• DAST (Dynamic Analysis): Tests running applications via black-box HTTP probing, simulating real-world hacker behavior at runtime.
• OWASP ZAP: A powerful, open-source DAST tool capable of crawling web applications and generating comprehensive vulnerability reports.
• Complimentary Defense: SAST, SCA, and DAST are not mutually exclusive; combining all three pillars provides complete coverage across code, dependencies, and runtime environments.