DAST in CI/CD

Vibe Prompt

"Help me build a complete DAST Pipeline in GitHub Actions: Deploy → ZAP Scan → Generate Report → Fail or Pass."

Complete Workflow

name: DAST Security Scan

on:
  deployment_status:

jobs:
  dast:
    if: github.event.deployment_status.environment == 'staging' && 
        github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - name: OWASP ZAP Scan
        uses: zaproxy/action-full-scan@v0.10.0
        with:
          target: ${{ github.event.deployment_status.environment_url }}
          rules_file_name: '.zap/rules.tsv'
          cmd_options: '-a'
          fail_action: true
      
      - name: Upload ZAP Report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: report.json
      
      - name: Security Check Failed
        if: failure()
        run: |
          echo "❌ Security scan detected vulnerabilities, please review the report"
          exit 1

Nuclei Quick Scan

- name: Nuclei Scan
  uses: projectdiscovery/nuclei-action@main
  with:
    target: ${{ github.event.deployment_status.environment_url }}
    severity: high,critical

Security Gates

| Scan Type | Pass Standard | |---------|---------| | SAST | No Critical/High vulnerabilities | | DAST | No High vulnerabilities | | SCA | No Critical vulnerabilities | | Container | No High vulnerabilities | | IaC | No Critical risks |

Deploy to Production Only After All Security Gates Pass

develop → Build → SAST → Test → Deploy Staging → DAST → SCA → Deploy Production
                                  └── Failure → Notify Developers to Fix

Key Points

✅ Supplement specific learning points according to this chapter's topic
✅ Add comparison tables, code examples, or flowcharts as recommended
✅ Ensure content is solid and valuable

Complete CI/CD Security Pipeline

name: Secure CI/CD Pipeline

on: [push, pull_request]

jobs:
  saast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: SonarQube Analysis
        uses: SonarSource/sonarcloud-github-action@master

  sca:
    runs-on: ubuntu-latest
    steps:
      - name: Snyk Security Scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

  container-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Build Docker Image
        run: docker build -t app:${{ github.sha }} .
      - name: Trivy Scan
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: app:${{ github.sha }}

  dast:
    needs: deploy-staging
    runs-on: ubuntu-latest
    steps:
      - name: ZAP Scan
        uses: zaproxy/action-full-scan@v0.10.0
        with:
          target: "https://staging.example.com"
          rules_file_name: "zap-rules.tsv"

| Scan Phase | Tool | Timing | Blocking Condition | |:--------:|:----:|:----:|---------| | SAST | SonarQube | Commit / PR | Quality Gate not passed | | SCA | Snyk / Dependabot | Commit / PR | Critical vulnerabilities not fixed | | Container | Trivy / Docker Scout | Build | High-risk CVEs | | DAST | ZAP | Post-deployment | High-risk vulnerabilities | | Secret | GitLeaks / TruffleHog | Commit | Password exposure |

Strategies for Executing DAST in CI/CD

DAST and SAST/SCA differ—DAST requires a running application instance to scan. This necessitates special design in CI/CD processes.

DAST Deployment Strategies

| Strategy | Method | Advantages | Disadvantages | |:----|:----|:----|:----| | Review App | Automatically deploy an isolated environment for each PR | High isolation | Requires cloud resources | | Staging Scheduled Scan | Schedule daily scans of the Staging environment | Simple, stable | Not scanned on every change | | Production Scan (Read-only) | Scan read-only endpoints in Production | Most realistic | High risk |

GitHub Actions + ZAP Practical Example

name: DAST Scan
on:
  deployment_status:
    types: [success]  # Trigger after successful deployment

jobs:
  dast:
    if: github.event.deployment_status.environment == 'staging'
    runs-on: ubuntu-latest
    steps:
      - name: ZAP Scan
        uses: zaproxy/action-full-scan@v0.10.0
        with:
          target: ${{ github.event.deployment_status.target_url }}
          fail_action: true  # Fail the Pipeline if high-risk vulnerabilities are found
      - name: Upload Report
        uses: actions/upload-artifact@v4
        with:
          name: zap-report
          path: report.html

Next Chapter Preview: Complete Security Pipeline

SAST, SCA, DAST—you've now learned all the security testing tools. The next chapter will integrate them into a single Pipeline, with clear gate controls at each stage.

Understanding DAST in CI/CD: What, Why, and How

What is DAST in CI/CD?

DAST (Dynamic Application Security Testing) in CI/CD refers to the automated execution of security scans against a running application during the continuous integration and continuous deployment process. Unlike static analysis tools that examine source code, DAST tools interact with the application as a real user would, probing for vulnerabilities such as SQL injection, cross-site scripting (XSS), broken authentication, and insecure direct object references. By integrating DAST into the CI/CD pipeline, organizations can proactively identify security flaws before they reach production, ensuring that each deployment meets predefined security standards.

Why is DAST in CI/CD Critical?

The business value of implementing DAST in CI/CD is substantial. Security vulnerabilities in production can lead to data breaches, regulatory fines, reputational damage, and financial losses. For example, a single SQL injection vulnerability could expose customer data, resulting in legal liabilities and loss of trust. By catching these issues early in the development lifecycle, teams reduce the cost of remediation—fixing a vulnerability during development is significantly cheaper than addressing it post-deployment. Additionally, automated DAST scans ensure consistent security checks across all deployments, eliminating human error and providing audit trails for compliance requirements such as GDPR, HIPAA, or PCI-DSS.

How to Implement DAST in CI/CD Using Vibe Coding

Implementing DAST in CI/CD involves several strategic steps. First, select a DAST tool such as OWASP ZAP, Burp Suite, or Nuclei. Next, design your pipeline to deploy the application to a staging environment after successful builds. Once the application is running, trigger the DAST scan using the chosen tool. Configure the scan to fail the pipeline if critical or high-severity vulnerabilities are detected. Finally, integrate reporting mechanisms to store scan results and notify relevant stakeholders when issues arise. This ensures that security is not an afterthought but an integral part of the development workflow.

Deep Dive into OWASP ZAP Integration

What is OWASP ZAP?

OWASP ZAP (Zed Attack Proxy) is an open-source web application security scanner maintained by the OWASP Foundation. It is designed to help developers and security professionals find vulnerabilities in web applications during the development and testing phases. ZAP provides both automated and manual testing capabilities, including a proxy for intercepting and modifying HTTP traffic, a scanner for identifying vulnerabilities, and a set of rules for detecting common security issues.

Why Use ZAP in CI/CD?

ZAP is particularly well-suited for CI/CD integration due to its automation-friendly design and extensive rule set. It can be run in daemon mode, allowing it to be controlled programmatically via APIs or command-line options. ZAP's active scan mode can simulate attacks against your application, while its passive scan mode can analyze traffic for vulnerabilities without actively probing. Additionally, ZAP supports custom rules and scripts, enabling teams to tailor scans to their specific application architectures and threat models.

How to Configure ZAP in GitHub Actions

To integrate ZAP into a GitHub Actions workflow, use the official zaproxy/action-full-scan action. This action handles the setup and execution of ZAP scans, including starting the ZAP daemon, configuring the target URL, and generating reports in various formats. The fail_action parameter ensures that the pipeline fails if vulnerabilities are detected, enforcing security gates. You can also specify custom rules files to focus scans on high-risk areas of your application.

- name: OWASP ZAP Scan
  uses: zaproxy/action-full-scan@v0.10.0
  with:
    target: ${{ github.event.deployment_status.environment_url }}
    rules_file_name: '.zap/rules.tsv'
    cmd_options: '-a'
    fail_action: true

Customizing ZAP Rules for Your Application

ZAP's rules file allows you to define which vulnerabilities to scan for and their severity levels. For example, you might prioritize SQL injection and XSS vulnerabilities while excluding certain passive scan rules that are not relevant to your application. Creating a custom rules file involves understanding ZAP's rule IDs and their associated risk levels. This customization ensures that scans are both thorough and efficient, avoiding false positives and focusing on the most critical security issues.

Nuclei: Fast and Flexible Vulnerability Scanner

What is Nuclei?

Nuclei is a fast, open-source vulnerability scanner developed by ProjectDiscovery. It uses templates to identify vulnerabilities, misconfigurations, and exposures in running systems. Nuclei is designed for speed and scalability, making it ideal for scanning large networks or frequent CI/CD integrations. It supports a wide range of protocols, including HTTP, HTTPS, DNS, and TCP, and can be extended with custom templates written in YAML.

Why Use Nuclei in CI/CD?

Nuclei's lightweight architecture and template-based approach make it an excellent choice for CI/CD pipelines. It can quickly scan for known vulnerabilities and misconfigurations without the overhead of full application scans. Nuclei is particularly useful for identifying exposed services, default credentials, and common misconfigurations that might not be caught by traditional DAST tools. Its ability to run multiple templates in parallel allows for comprehensive scanning in a short amount of time.

How to Integrate Nuclei in GitHub Actions

Using the projectdiscovery/nuclei-action in GitHub Actions allows you to trigger Nuclei scans directly from your pipeline. You can specify the target URL and severity levels to focus on high-risk vulnerabilities. This integration ensures that your application is scanned for known vulnerabilities immediately after deployment, providing an additional layer of security.

- name: Nuclei Scan
  uses: projectdiscovery/nuclei-action@main
  with:
    target: ${{ github.event.deployment_status.environment_url }}
    severity: high,critical

Creating Custom Nuclei Templates

Nuclei's power lies in its template system. You can create custom templates to detect vulnerabilities specific to your application's technology stack or architecture. Templates are written in YAML and define the request to send, the response to look for, and the severity of the finding. By developing custom templates, teams can address unique security concerns that generic scanners might miss.

Security Gates: The Foundation of Secure Deployments

What Are Security Gates?

Security gates are predefined criteria that must be met before a deployment can proceed to the next stage in the CI/CD pipeline. These gates act as quality checkpoints, ensuring that security standards are maintained throughout the development lifecycle. Each gate is associated with a specific type of security scan, such as SAST, DAST, SCA, or container scanning, and defines the acceptable risk levels for vulnerabilities.

Why Are Security Gates Important?

Security gates provide a systematic approach to managing risk in software deployments. By enforcing strict criteria at each stage, they prevent vulnerable code from reaching production. This proactive approach reduces the likelihood of security incidents and ensures compliance with industry standards. Moreover, security gates create accountability, as developers must address issues before proceeding, fostering a culture of security-first development.

How to Define and Enforce Security Gates

Defining security gates involves setting clear pass/fail criteria based on vulnerability severity. For example, a SAST gate might require no critical or high vulnerabilities, while a DAST gate might allow only medium-severity issues. These criteria are enforced through pipeline configuration, where scans are run and their results are evaluated against the defined thresholds. If the criteria are not met, the pipeline fails, and developers are notified to fix the issues before re-deploying.

Full CI/CD Security Pipeline Architecture

Overview of the Secure Pipeline

A comprehensive CI/CD security pipeline integrates multiple security testing tools at different stages of the development lifecycle. The pipeline begins with code commits and pull requests, where SAST and SCA tools analyze the code for vulnerabilities and dependency issues. After successful builds, container scanning ensures that Docker images are free from known vulnerabilities. Once deployed to staging, DAST tools scan the running application for runtime vulnerabilities. Only after passing all security gates can the application be deployed to production.

Pipeline Stages and Their Security Checks

Commit/PR Stage: SAST and SCA tools analyze code changes for vulnerabilities and insecure dependencies.
Build Stage: Container scanning tools like Trivy or Docker Scout check Docker images for vulnerabilities.
Staging Deployment: DAST tools like ZAP or Nuclei scan the running application for runtime vulnerabilities.
Production Deployment: Final security checks ensure that no critical issues remain before deploying to production.

Benefits of a Full Security Pipeline

Implementing a full security pipeline provides continuous security monitoring, reduces manual security reviews, and ensures that every deployment meets security standards. It also improves developer productivity by catching issues early, reducing the need for emergency fixes in production. Additionally, it supports compliance requirements by maintaining detailed audit trails of security checks and their results.

DAST Deployment Strategies in Depth

Review App Strategy

The Review App strategy involves automatically deploying a separate environment for each pull request. This approach provides complete isolation, allowing DAST scans to run without affecting other environments. It is particularly useful for large teams working on multiple features simultaneously. However, it requires significant cloud resources and infrastructure management, which can be costly and complex.

Staging Scheduled Scan Strategy

Scheduled scans of the Staging environment offer a simpler and more cost-effective solution. By running DAST scans at regular intervals (e.g., daily), teams can ensure that the Staging environment remains secure. This strategy is ideal for smaller teams or projects with less frequent updates. However, it may not catch vulnerabilities introduced by every code change, as scans are not triggered on every deployment.

Production Read-Only Scan Strategy

Scanning Production's read-only endpoints provides the most realistic assessment of an application's security. This strategy ensures that vulnerabilities are identified in the actual production environment. However, it carries higher risks, as scans might impact production performance or trigger unintended actions. It is generally recommended only for read-only endpoints and with careful configuration to avoid disruptions.

Best Practices for DAST in CI/CD

Automate Early and Often

Integrate DAST scans as early as possible in the CI/CD pipeline to catch vulnerabilities before they propagate. Running scans on every deployment to Staging ensures that issues are identified and addressed promptly.