The evolution of modern software engineering has transitioned from simple code compilation to the complex orchestration of DevSecOps. In this landscape, the security of an application cannot be treated as a final, isolated stage of the development lifecycle. Instead, it must be integrated into the very fabric of the Continuous Integration and Continuous Deployment (CI/CD) process. While static analysis tools can inspect code for patterns indicative of vulnerabilities, they often fail to account for the dynamic complexities of a running environment. This is where Dynamic Application Security Testing (DAST) becomes critical. OWASP ZAP (Zed Attack Proxy), an open-source, powerful security tool, serves as a cornerstone for identifying vulnerabilities in web applications and APIs by interacting with them as an attacker would. Integrating OWASP ZAP into a GitLab CI/CD pipeline transforms a standard deployment pipeline into a robust, automated security gateway, ensuring that deployment only occurs when the running application meets defined security thresholds.

The Strategic Imperative of DevSecOps and Application Security Programs

Application security is no longer a niche concern for specialized security teams; it has ascended to a global priority. Regulatory frameworks and legislations, such as the NIST Secure Software Development Framework (SSDF) and Memorandum M-22-18 in the United States, alongside the Cyber Resilience Act (CRA) in the European Union, mandate high common levels of cybersecurity for software products. These legal drivers reflect the reality that attack sophistication and the absolute number of cyberattacks are increasing exponentially.

To combat these threats, organizations implement Application Security (AppSec) programs. While various frameworks exist, such as the Microsoft SDLC or the Binary Software Composition Analysis (BSIMM), the OWASP Software Assurance Maturity Model (SAMM) is widely regarded as the most accessible starting point for organizations aiming to build a structured security posture. A successful AppSec program is not merely a collection of tools; it is a holistic machine composed of six fundamental cornerstones:

• People: The human element responsible for implementing and maintaining security practices.
• Process: The structured workflows that integrate security into every stage of development.
• Knowledge: The expertise and understanding of the threat landscape and defensive techniques.
• Tools: The technical assets, such as OWASP ZAP, used to automate security checks.
• Training: The continuous education of developers and security engineers.
• Risk: The systematic evaluation of potential threats and their impact on the organization.

In a mature DevSecOps workflow, tooling is the final piece of the puzzle. It is a common error to attempt to reverse-engineer a process based solely on available tools. Instead, professionals focus on defining the process first and then selecting tools that fit seamlessly into that established workflow. Integrating OWASP ZAP into GitLab CI/CD is a specific application of this principle, specifically focusing on the "secure deploy" phase of the lifecycle.

Technical Architecture of OWASP ZAP Scanning in GitLab

OWASP ZAP functions as a DAST tool, meaning it probes the application while it is active and running. This capability allows it to identify vulnerabilities that static image scans or code analysis might miss, such as misconfigured authentication mechanisms, insecure endpoints, or unintended sensitive data leaks. The integration within GitLab involves creating a dedicated job within the .gitlab-ci.yml configuration that utilizes a ZAP-enabled Docker container.

The implementation typically follows a structured pipeline stage. For instance, a zap_scan stage is defined to execute the security testing after the application has been deployed to a test or staging environment. The following table outlines the typical components of a ZAP scan job within a GitLab runner environment.

The Baseline Scan Workflow

The baseline scan is a lightweight version of a full scan, designed to be run quickly in a CI/CD pipeline. It performs a passive scan of the target URL, looking for common vulnerabilities without being overly aggressive. A typical job configuration utilizes the zap-baseline.py script, targeting a specific $APP_URL.

To ensure the scan does not fail the entire pipeline unless specifically desired, the allow_failure: true parameter can be utilized. This allows developers to see the security results without blocking the deployment, which is useful during the initial integration phases of a new security tool.

yaml zap_scan: stage: zap_scan image: zaproxy/zap-stable script: - echo "Checking if the target is reachable..." - # Health check logic goes here - mkdir -p /zap/wrk - ln -s "$CI_PROJECT_DIR" /zap/wrk - echo "Starting ZAP baseline scan..." - zap-baseline.py -t "$APP_URL" -r zap-report.html -I - cp /zap/wrk/zap-report.html "$CI_PROJECT_DIR/" || true artifacts: paths: - zap-report.html expire_in: 7 days allow_failure: true

Automating Deployment and Environment Readiness

Before a security scan can occur, the target application must be successfully deployed and accessible. In a professional DevOps workflow, manual server logins are replaced by automated deployment jobs. Using GitLab CI/CD, the pipeline can connect to remote servers via SSH to trigger the deployment of a newly built Docker image.

Security is maintained during this process by using SSH keys rather than hard-coded passwords. These keys should be stored securely as GitLab CI/CD variables, such as SSH_PRIVATE_KEY. A deployment job might utilize the google/cloud-sdk:latest image to interact with Google Cloud Platform (GCP) if the infrastructure is hosted there.

The Deployment Process via SSH and Cloud Integration

The deployment stage involves several critical steps to ensure the environment is authenticated and the Docker image is pushed to the correct registry.

1. Installation of dependencies: Tools like docker.io, openssh-client, and curl are installed on the runner.
2. GCP Authentication: The runner authenticates using a service account key stored in a GitLab variable, often decoded from base64 to ensure integrity.
3. Docker Configuration: The runner is configured to authenticate with a specific Docker registry, such as asia-southeast1-docker.pkg.dev.
4. SSH Agent Setup: The ssh-agent is initialized, and the SSH_PRIVATE_KEY is loaded to allow secure communication with the remote host.

yaml deploy_to_production: stage: deploy image: google/cloud-sdk:latest before_script: - echo "Install Docker" - apt-get update && apt-get install -y docker.io curl ca-certificates tar gzip openssh-client - echo "Setting up Google Cloud authentication..." - echo "$GCP_SA_KEY" | base64 -d > $CI_PROJECT_DIR/gcp-key.json - gcloud auth activate-service-account --key-file=$CI_PROJECT_DIR/gcp-key.json - gcloud config set project escian - gcloud auth configure-docker asia-southeast1-docker.pkg.dev --quiet - eval $(ssh-agent -s) - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -

Ensuring Target Availability with Health Checks

A common failure point in automated pipelines is attempting to run a security scan before the application is fully initialized and listening for requests. To prevent "Target not reachable" errors, a shell script must be implemented to poll the application's health endpoint.

A robust health check script uses a loop to ping the target. If the target does not respond within a predefined number of attempts (e.g., 10 attempts with a 5-second sleep between each), the script exits with an error, preventing the ZAP scan from running against a non-existent target.

```bash
for i in $(seq 1 10); do
if curl -s --head "$APP_URL" | grep "200 OK" > /dev/null; then
echo "Target is reachable."
exit 0
fi
echo "Waiting for target... attempt $i"
sleep 5
done

if [ $i -eq 10 ]; then
echo "Target not reachable after 50 seconds."
exit 1
fi
```

Advanced ZAP Configuration and Automation Plans

For more complex applications, a simple baseline scan is insufficient. Professional teams utilize ZAP Automation Plans, which allow for highly granular control over the scanning process, including authentication, spidering, and active scanning.

The ZAP Automation Plan Structure

An automation plan (often defined in YAML) allows the user to define the scope, the authentication method, and the specific tests to be run. This is particularly useful for applications requiring authenticated scanning to reach protected endpoints.

The following table breaks down the components of a sophisticated ZAP Automation Plan.

Customizing Scans with sed and Environment Variables

To make the automation plan dynamic within a GitLab pipeline, environment variables are used to inject sensitive information or target URLs into the configuration files. This is achieved using the sed command to replace placeholders in the ZAP configuration files with actual values.

bash sed -i "s/TARGET/$ESCAPED_TARGET/g" zap/zap_baseline.yaml sed -i "s/STRESS_TEST_PASSWORD/$STRESS_TEST_PASSWORD/g" zap/zap-auth.zst sed -i "s/STRESS_TEST_USERNAME/$STRESS_TEST_USERNAME/g" zap/zap-auth.zst /zap/zap.sh -configfile $CI_PROJECT_DIR/zap/zap_config.conf -cmd -autorun $CI_PROJECT_DIR/zap/zap_baseline.yaml

Implementing Threshold-Based Failure

A critical feature of DevSecOps is the ability to "break the build" if security vulnerabilities exceed a certain risk level. This can be achieved by parsing the ZAP output. After the scan completes, a script can grep the results to check for "High" or "Medium" risk alerts. If such alerts are found, the script can exit with a non-zero code, causing the GitLab job to fail and alerting the engineering team.

bash returnCode=0 anyAlertsAboveLow=$(grep -E "^\| (High|Medium) \|" $CI_PROJECT_DIR/$ZAP_ALERT_REPORT.md | grep -oE '[0-9]+' | awk '$1>0') if [ ! -z "$anyAlertsAboveLow" ]; then echo "Vulnerabilities found exceeding the threshold!" returnCode=1 fi exit $returnCode

Addressing Pipeline Performance and Complexity

One of the primary challenges when integrating deep security scans is the impact on pipeline duration. Comprehensive scans, particularly those involving Selenium-based acceptance tests or heavy active scanning, can significantly increase the time developers wait for feedback.

Managing Scan Duration and Resource Intensity

In some environments, running hundreds of tests alongside ZAP scans can lead to execution times exceeding 40 minutes. To mitigate this, several strategies can be employed:

• Passive vs. Active Scanning: Use passive scans for every commit and reserve heavy active scans for scheduled nightly builds.
• Avoiding Aggressive Scans: Configure the scan to be "gentle" toward the test system to prevent resource exhaustion on the GitLab runner.
• Using the ZAP API: For specific workflows, one can use curl to communicate with the ZAP API to manage jobs, such as ending a delay job to expedite the process.

```bash

Example command to tell ZAP to stop a delay job and continue scanning

curl http://zap/JSON/automation/action/endDelayJob
```

• Report Management: Utilize the ZAP File Transfer API or direct file manipulation to fetch reports and store them as GitLab artifacts, ensuring that even if a job fails, the security data is preserved for analysis.

Conclusion: Building a Resilient Security Pipeline

The integration of OWASP ZAP into GitLab CI/CD represents a shift from reactive security to proactive, automated defense. By embedding DAST capabilities directly into the deployment workflow, organizations can identify and remediate vulnerabilities before they are exposed to the public internet. This requires a multi-layered approach: ensuring the target environment is correctly deployed via secure SSH channels, implementing robust health checks to verify application readiness, and utilizing sophisticated automation plans to perform deep-dive scans.

The complexity of these implementations—ranging from using sed for dynamic configuration to implementing logic that fails the pipeline based on risk levels—is the price of a high-assurance software lifecycle. While the impact on pipeline latency is a real concern, the use of optimized scanning profiles and strategic scheduling can balance the need for speed with the necessity of security. Ultimately, the goal is to move toward a state where security is not a bottleneck, but a fundamental, automated component of the continuous delivery engine, ensuring that every deployment is as secure as it is efficient.

Sources

1. Building, securing, and deploying a Go app with GitLab CI/CD
2. How to integrate ZAP in GitLab
3. ZAPROXY Users Google Group