Security Testing Guide: SAST, DAST, Penetration Testing, and OWASP Top 10

Security testing is the process of identifying vulnerabilities, threats, and risks in software to prevent unauthorized access, data breaches, and system compromises. Unlike functional testing that verifies what software does, security testing verifies what software prevents.

Security breaches cost organizations an average of $4.88 million per incident (IBM Cost of a Data Breach Report 2024). Yet security testing remains an afterthought in many development pipelines — discovered vulnerabilities are 30x more expensive to fix after production deployment than during development.

This guide covers every type of security testing, the OWASP Top 10, penetration testing methodology, the SAST vs DAST decision, popular tools, and how to integrate security testing into your CI/CD pipeline.

What Is Security Testing?

Security testing evaluates software systems to identify security weaknesses that could be exploited by attackers. It covers the CIA triad:

• Confidentiality: Sensitive data is not disclosed to unauthorized parties
• Integrity: Data is not modified by unauthorized parties
• Availability: Systems remain available to authorized users (resilience against DoS)

Security testing differs from other testing types in a critical way: functional testers try to prove the system works as designed. Security testers try to prove the system can be broken — they think like attackers.

Why Security Testing Matters

• Regulatory compliance: GDPR, HIPAA, PCI-DSS, SOX require demonstrable security controls
• Cost: Fixing vulnerabilities in production is 30-100x more expensive than in development
• Reputation: Security breaches permanently damage user trust and brand value
• Legal liability: Data breaches can result in significant fines and lawsuits
• Software supply chain risk: Third-party dependencies introduce vulnerabilities you did not write

Types of Security Testing

Static Application Security Testing (SAST)

Analyzes source code, bytecode, or binaries without executing the application. Finds vulnerabilities in code structure, dangerous function calls, hardcoded secrets, and insecure patterns.

Dynamic Application Security Testing (DAST)

Tests a running application by sending attack payloads and analyzing responses. Simulates an external attacker with no knowledge of the source code.

Interactive Application Security Testing (IAST)

Combines SAST and DAST by instrumenting the running application with agents that monitor internal behavior during testing. Provides deeper visibility than DAST alone.

Software Composition Analysis (SCA)

Identifies known vulnerabilities in third-party libraries and open-source dependencies. Critical given that modern applications are 80-90% third-party code.

Penetration Testing (Pen Testing)

Manual security assessment performed by skilled security professionals who simulate real-world attacks. More thorough than automated tools — human creativity finds vulnerabilities that scanners miss.

Vulnerability Assessment

Systematic identification and cataloging of security weaknesses. Less invasive than penetration testing — identifies vulnerabilities without exploiting them.

Security Auditing

Systematic review of security controls, policies, configurations, and code against a security standard or compliance framework.

Fuzz Testing (Fuzzing)

Feeds invalid, unexpected, or random input to applications to find crashes, memory corruption, and input validation failures. Particularly effective for APIs and parsers.

Threat Modeling

Proactive security design process that identifies potential threats, attack vectors, and countermeasures during the design phase. The cheapest form of security — preventing vulnerabilities before they are coded.

SAST: Static Application Security Testing

SAST tools scan source code, configuration files, and infrastructure-as-code for security vulnerabilities without running the application.

What SAST Finds

• SQL injection vulnerabilities — string concatenation in database queries
• Cross-Site Scripting (XSS) — unescaped user input in HTML output
• Hardcoded credentials — API keys, passwords in source code
• Insecure cryptography — use of weak algorithms (MD5, SHA1, DES)
• Path traversal — unsanitized file paths constructed from user input
• Command injection — user input passed to shell commands
• Insecure deserialization — deserializing untrusted data
• Secrets in code — tokens, certificates, passwords committed to version control

How SAST Works

1. Parse source code into an Abstract Syntax Tree (AST) or data flow graph
2. Apply rules that identify dangerous patterns (e.g., exec() with user input)
3. Taint analysis — track untrusted data (user input) from source to sink (database query, HTML output)
4. Report findings with file, line number, severity, and remediation guidance

SAST Limitations

• False positives: SAST tools often flag issues that are not actually exploitable in context. High false positive rates lead teams to ignore findings.
• Cannot find runtime issues: Logic flaws, authentication problems, and business logic vulnerabilities require dynamic analysis
• Language-specific: Each tool supports specific languages and frameworks
• Context-blind: Cannot understand business logic or complex data flows that span services

SAST Tools

• Semgrep — fast, open-source, highly customizable rules; excellent for CI/CD integration
• SonarQube — comprehensive static analysis with security rules and quality gates
• Checkmarx — enterprise SAST with strong Java and .NET support
• Veracode — cloud-based SAST with compliance reporting
• Snyk Code — developer-friendly SAST integrated with IDE and CI/CD

SAST Integration Example (GitHub Actions)

name: SAST Scan
on: [push, pull_request]
jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/javascript
            p/secrets

DAST: Dynamic Application Security Testing

DAST tests a running application by interacting with it as an attacker would — sending requests with malicious payloads and analyzing responses.

What DAST Finds

• SQL injection — submitting SQL payloads through forms and parameters
• XSS — injecting script tags through input fields and URL parameters
• Authentication flaws — weak passwords, session fixation, missing logout
• Authorization flaws — accessing resources belonging to other users (IDOR)
• Security misconfigurations — exposed debug endpoints, verbose error messages
• Sensitive data exposure — PII in responses, unencrypted transmission
• Missing security headers — HSTS, CSP, X-Frame-Options

How DAST Works

1. Crawl/Spider the application to discover all endpoints and forms
2. Active scanning — submit attack payloads to each discovered input
3. Analyze responses for error patterns, unexpected behavior, or reflected payloads
4. Report vulnerabilities with request/response evidence and severity ratings

DAST Limitations

• Requires a running environment — cannot run in CI on pull requests without a staging environment
• Cannot access source code — misses vulnerabilities only visible in code
• Slower than SAST — active scanning can take hours for large applications
• May cause side effects — attack payloads can corrupt test data or trigger alerts

DAST Tools

• OWASP ZAP (Zed Attack Proxy) — free, open-source, excellent for CI/CD integration
• Burp Suite Professional — industry-standard tool for manual and automated DAST
• Nikto — open-source web server scanner for known vulnerabilities and misconfigs
• Acunetix — commercial DAST with strong JavaScript crawling and reporting
• HCL AppScan — enterprise DAST with compliance mapping

DAST with OWASP ZAP in CI/CD

name: DAST Scan
on: [push]
jobs:
  zap-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Start application
        run: docker compose up -d

      - name: ZAP Baseline Scan
        uses: zaproxy/action-baseline@v0.11.0
        with:
          target: 'http://localhost:3000'
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a'

SAST vs DAST

The Correct Answer: Use Both

SAST and DAST are complementary. SAST finds issues early in development before they reach staging. DAST validates security of the deployed application and finds configuration and runtime issues that SAST misses.

A mature security program uses:

• SAST: On every commit and pull request (fast feedback loop)
• DAST: On every deployment to staging (deeper validation)
• IAST: In integration test suites (real behavior monitoring)
• SCA: Continuously monitoring dependency vulnerabilities

Penetration Testing Methodology

Penetration testing is a structured, manual security assessment where ethical hackers attempt to breach a target system using the same techniques real attackers use. Unlike automated scanners, pen testers apply creativity and chained attacks that tools cannot replicate.

Types of Penetration Tests

Black Box: Tester has no prior knowledge of the target. Simulates an external attacker. Most realistic but most time-consuming.

White Box: Tester has full access to source code, architecture diagrams, and internal documentation. Most thorough coverage; used for deep code audits.

Grey Box: Tester has partial knowledge (e.g., user-level access credentials). Balances realism with efficiency. Most common for web application pen tests.

The Pen Testing Phases

Phase 1: Pre-Engagement and Scoping

• Define the scope: which systems, IP ranges, and applications are in scope
• Define the rules of engagement: timing, notification procedures, excluded attack types
• Obtain written authorization — pen testing without permission is illegal
• Define success criteria and deliverable format

Phase 2: Reconnaissance (Information Gathering)

Passive reconnaissance — gathering information without directly interacting with the target:

• WHOIS lookups, DNS enumeration
• Google dorking (specialized search queries)
• LinkedIn and social media for employee details
• Certificate transparency logs for subdomains
• Shodan/Censys for exposed services

Active reconnaissance — directly probing the target:

• Port scanning with Nmap
• Service version detection
• OS fingerprinting
• Web application crawling

# Nmap scan for service discovery
nmap -sV -sC -p- --open target.example.com

<span class="hljs-comment"># Subdomain enumeration
subfinder -d example.com <span class="hljs-pipe">| httpx -title -status-code

Phase 3: Scanning and Vulnerability Analysis

• Automated scanning with DAST tools (ZAP, Nikto)
• Manual review of application functionality
• Identifying authentication mechanisms and access controls
• Mapping data flows and trust boundaries
• Reviewing API endpoints and parameters

Phase 4: Exploitation

Attempting to exploit identified vulnerabilities to verify they are genuinely exploitable (not just theoretical):

• SQL injection to extract data
• XSS payload execution in target browser
• Authentication bypass
• Privilege escalation
• Lateral movement within discovered network segments

Important: Exploitation is always done within the agreed scope and rules of engagement. Testers document every step for the report.

Phase 5: Post-Exploitation

Understanding the real-world impact of a successful compromise:

• What data would an attacker access?
• What systems could they reach from the compromised host?
• What business processes could they disrupt?

This phase informs vulnerability severity ratings and business risk assessments.

Phase 6: Reporting

The deliverable of a pen test is a detailed report covering:

• Executive summary: Business risk, overall risk rating, key findings
• Technical findings: Each vulnerability with description, evidence (screenshots, payloads), CVSS severity score, and remediation steps
• Remediation roadmap: Prioritized list of fixes with effort estimates
• Methodology: What was tested, tools used, limitations

Phase 7: Remediation and Retest

After the development team fixes identified vulnerabilities, the pen tester verifies each fix in a follow-up engagement (retest). Fixes are validated individually to confirm the vulnerability is genuinely resolved, not just obscured.

OWASP Top 10

The OWASP (Open Web Application Security Project) Top 10 is the definitive list of the most critical web application security risks. Updated periodically, it represents consensus from security experts globally.

A01: Broken Access Control

The most prevalent vulnerability. Occurs when users can access resources or perform actions beyond their authorization.

Examples:

• Accessing another user's account by changing an ID in the URL (/users/123 → /users/124)
• Elevating privileges by modifying role parameters
• Accessing admin pages without admin rights

Testing approach:

# Test IDOR (Insecure Direct Object Reference)
1. Log in as User A, note object IDs in responses
2. Log in as User B
3. Attempt to access User A's objects using their IDs
4. Verify that 403 Forbidden is returned, not User A's data

Prevention: Implement server-side access control checks on every request. Never rely on hiding IDs from the UI as security.

A02: Cryptographic Failures

Sensitive data exposed due to weak encryption, missing encryption, or cryptographic implementation errors.

Examples:

• Passwords stored with MD5 or SHA1 (easily crackable)
• Credit card numbers stored in plaintext
• HTTP used instead of HTTPS
• Weak TLS configuration (TLS 1.0, weak cipher suites)
• Insecure session tokens with low entropy

Testing approach:

• Check TLS configuration with SSL Labs (ssllabs.com/ssltest)
• Intercept traffic to verify HTTPS is enforced everywhere
• Check password storage: attempt account enumeration to identify hashing
• Review API responses for sensitive data in plaintext

A03: Injection

Untrusted data sent to an interpreter as part of a command or query. SQL injection is the most common, but injection also affects LDAP, NoSQL, OS commands, XML, and more.

SQL Injection Example:

-- Vulnerable code
SELECT * FROM users WHERE username = '" + userInput + "'

-- Attack payload
userInput = ' OR '1'='1
-- Results in: SELECT * FROM users WHERE username = '' OR '1'='1'
-- Returns all users

Testing approach:

1. Identify input fields and parameters
2. Submit: ' (single quote) — look for SQL error messages
3. Try: ' OR '1'='1'-- and ' OR 1=1--
4. Use sqlmap for automated SQL injection testing
5. Check for NoSQL injection in JSON parameters: {"$gt":""}

Prevention: Use parameterized queries / prepared statements. Never concatenate user input into queries.

A04: Insecure Design

Security flaws baked into the application architecture — issues that no amount of patching can fix without redesign. Inadequate threat modeling during design is the root cause.

Examples:

• Password reset flows that allow enumeration of valid email addresses
• "Security questions" that are easily guessable or researchable
• Business logic that allows ordering negative quantities for credit

A05: Security Misconfiguration

Incorrect security settings across the application stack — web servers, databases, cloud storage, frameworks.

Examples:

• Default credentials left unchanged (admin/admin)
• Directory listing enabled on web server
• Verbose error messages revealing stack traces
• Unnecessary features enabled (debug mode in production)
• S3 buckets set to public read
• Missing security headers

Testing approach:

# Check security headers
curl -I https://example.com <span class="hljs-pipe">| grep -i <span class="hljs-string">"strict-transport\|x-frame\|content-security\|x-content-type"

<span class="hljs-comment"># Check for exposed sensitive files
curl https://example.com/.env
curl https://example.com/.git/config
curl https://example.com/phpinfo.php

A06: Vulnerable and Outdated Components

Using components (libraries, frameworks, OS packages) with known vulnerabilities.

Testing approach:

# JavaScript dependencies
npm audit

<span class="hljs-comment"># Python dependencies
pip install safety && safety check

<span class="hljs-comment"># Container images
trivy image myapp:latest

<span class="hljs-comment"># Infrastructure
snyk <span class="hljs-built_in">test --all-projects

A07: Identification and Authentication Failures

Weaknesses in authentication and session management.

Examples:

• No brute force protection on login (allows unlimited password attempts)
• Weak or predictable session tokens
• Session not invalidated on logout
• Password stored in URL parameters
• No multi-factor authentication on sensitive operations

Testing approach:

1. Attempt brute force login — count how many attempts before lockout
2. Inspect session tokens for patterns or low entropy
3. Log out, then attempt to access authenticated pages using the old session
4. Test "remember me" token expiration and revocation

A08: Software and Data Integrity Failures

Code and infrastructure that does not protect against integrity violations — particularly in CI/CD pipelines and deserialization.

Examples:

• CI/CD pipelines that execute code from untrusted sources without verification
• Deserializing untrusted data without integrity checks
• Using unsigned packages/updates
• Software supply chain attacks (malicious npm packages)

A09: Security Logging and Monitoring Failures

Insufficient logging prevents detection, response, and forensic analysis of security incidents.

Testing approach:

• Attempt login failures and verify they are logged
• Verify logs include sufficient context (user, IP, timestamp, action)
• Test that alerts fire for suspicious activity (multiple failed logins)
• Verify that logs cannot be deleted by the application user

A10: Server-Side Request Forgery (SSRF)

The application fetches a remote resource based on user-supplied URL, allowing attackers to make the server send requests to internal services.

Examples:

• Image processing that fetches URLs: https://example.com/fetch?url=http://169.254.169.254/metadata
• PDF generation from URLs
• Webhooks that fetch and display content

Testing approach:

1. Find URL parameters that cause the server to fetch external resources
2. Try: http://localhost/admin, http://127.0.0.1:6379 (Redis)
3. Try cloud metadata: http://169.254.169.254/latest/meta-data/
4. Use Burp Collaborator to detect blind SSRF

Security Testing Tools

Vulnerability Scanners

SAST Tools

Dependency Scanning (SCA)

Penetration Testing

DevSecOps: Shifting Security Left

DevSecOps integrates security into every phase of the development pipeline rather than treating it as a final gate. The goal: find vulnerabilities when they are cheapest to fix.

Security Gates in CI/CD

Commit → SAST scan → PR Review → Merge → Deploy to Staging → DAST scan → Production
   ↑           ↑                              ↑
  IDE       < 5 min                        < 2 hours
 plugins    feedback                      nightly scan

Implementing Shift-Left Security

1. IDE Integration Developers get security feedback while writing code. Semgrep, Snyk, and SonarLint have IDE plugins that flag vulnerabilities in real time.

2. Pre-commit Hooks Block commits containing secrets or high-severity vulnerabilities:

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.4.0
    hooks:
      - <span class="hljs-built_in">id: detect-secrets
  - repo: https://github.com/returntocorp/semgrep
    rev: v1.45.0
    hooks:
      - <span class="hljs-built_in">id: semgrep

3. Pull Request Checks SAST and dependency scanning run on every PR. Failed checks block merging.

4. Staging Environment DAST Automated DAST scans run against staging on every deployment. Findings above threshold severity block promotion to production.

5. Production Monitoring Runtime application self-protection (RASP) and security information and event management (SIEM) for ongoing threat detection.

Security Testing Checklist

Authentication

• Brute force protection on login (lockout or CAPTCHA after N failures)
• Secure password reset flow (tokens expire, one-time use)
• Multi-factor authentication available for sensitive operations
• Session tokens have high entropy and appropriate expiration
• Sessions are invalidated on logout

Authorization

• All API endpoints check user permissions server-side
• Horizontal privilege escalation (IDOR) tests conducted
• Vertical privilege escalation tested (user → admin)
• Admin functions require admin role, not just hidden from UI

Input Validation

• SQL injection tested on all database-querying inputs
• XSS tested on all user-input-to-output paths
• Command injection tested on inputs that influence system calls
• File upload restricted by type, size, and content verification

Data Protection

• Sensitive data (passwords, PII, payment info) encrypted at rest
• HTTPS enforced on all pages (HSTS header present)
• No sensitive data in URLs, logs, or error messages
• TLS 1.2+ with strong cipher suites

Configuration

• Security headers present (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
• Debug mode disabled in production
• Default credentials changed on all systems
• Verbose error messages suppressed in production

Dependencies

• npm audit / pip audit run with no high/critical findings
• Dependencies updated to versions without known CVEs
• Container images scanned for vulnerabilities

FAQ

What is the difference between vulnerability assessment and penetration testing?

A vulnerability assessment identifies and catalogs security weaknesses without exploiting them. It answers: "What vulnerabilities exist?" Penetration testing goes further — it exploits vulnerabilities to determine their real-world impact and chains multiple vulnerabilities together to simulate actual attacks. It answers: "How far can an attacker get?" Vulnerability assessments are faster and cheaper; pen tests provide deeper assurance.

How often should penetration testing be performed?

Most security frameworks (PCI-DSS, SOC 2, ISO 27001) require annual penetration testing at minimum. In practice, a pen test should be performed annually, after significant application changes, after security incidents, before launching new products, and when handling sensitive data categories for the first time. Continuous automated scanning (SAST/DAST) fills the gaps between manual pen tests.

What is DAST vs IAST vs RASP?

DAST (Dynamic Application Security Testing) tests from outside the application by sending attack payloads. IAST (Interactive Application Security Testing) instruments the running application with an agent to monitor internal behavior during testing — it sees both the request and the internal code path it triggers. RASP (Runtime Application Self-Protection) operates in production, monitoring and blocking attacks in real time. DAST and IAST are testing tools; RASP is a production security control.

Can automated tools replace penetration testing?

No. Automated tools (SAST, DAST, SCA) are essential and should run continuously. But they find known vulnerability patterns — they cannot chain vulnerabilities together, understand business logic flaws, or apply attacker creativity. A skilled penetration tester finds vulnerabilities that automated tools consistently miss. The best programs use both: automation for continuous coverage and frequency, manual pen testing for depth and business logic.

What is OWASP and why does it matter?

OWASP (Open Web Application Security Project) is a non-profit foundation that produces free security resources including the OWASP Top 10, OWASP Testing Guide, OWASP WSTG (Web Security Testing Guide), and OWASP ZAP (free DAST tool). The OWASP Top 10 is the most widely referenced security standard for web applications — it is referenced in PCI-DSS, GDPR compliance frameworks, and most security certification programs. Testing against the OWASP Top 10 is a baseline requirement, not a complete security program.

What is the difference between SAST and code review?

Code review is typically a peer review process focused on correctness, maintainability, and design. Security code review specifically looks for security vulnerabilities in code. SAST automates security code review — it applies security rules systematically to every line of code, much faster than a human reviewer. SAST complements manual security code review rather than replacing it — SAST catches known patterns; human reviewers catch logic flaws and design issues.

What credentials or certifications are relevant for security testing?

Key certifications include: OSCP (Offensive Security Certified Professional) — highly regarded for penetration testing; CEH (Certified Ethical Hacker); GWAPT (GIAC Web Application Penetration Tester); CISSP (Certified Information Systems Security Professional) for security management; CISA for auditing. Bug bounty programs (HackerOne, Bugcrowd) also provide practical experience and reputation.