Automate a Security Audit with ZAP

Run automated DAST scans on your live web app using OWASP ZAP and GitHub Actions.

Introduction

30 Second Summary

Every web app you put online becomes a target. Hackers use automated scanners to probe for weaknesses around the clock. The question is whether you find those weaknesses first.

In this project, you will run OWASP ZAP against your live web app to discover real vulnerabilities, triage the results like a security professional, and build a GitHub Actions pipeline that automatically scans for new issues on every push.

What You'll Build

Push code to your repo, then watch your pipeline kick off a full security scan and open a GitHub issue listing every vulnerability it found. No manual commands required.

By the end of this project, you'll have:

  • A DAST scan you can run against any live site, showing real vulnerability alerts in your terminal with risk levels and affected URLs.
  • A CI/CD workflow that triggers security scans on every push and automatically creates GitHub issues for findings, so your app is continuously monitored.
  • A rules configuration that filters out false positives and focuses the scanner on real risks, proving you can triage like a security engineer.
  • A professional security findings report documenting each vulnerability with severity, OWASP Top 10 category, evidence, and remediation guidance.
  • Secret Mission: Add a scheduled weekly scan that catches new vulnerabilities as your app changes over time.

Are there any prerequisites?

You should be familiar with Git, GitHub, and basic web security concepts. You also need Docker Desktop installed on your machine. Step 1 will confirm everything is ready to go.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

You're going to build an automated security audit pipeline that continuously scans your live VFL app for vulnerabilities. By the end, you'll have a GitHub repo that proves you can operate real security tooling in a CI/CD pipeline.

Set Up Docker and Run Your First ZAP Scan

Before you configure any rules or automate anything, you need to see what a security scanner actually finds when pointed at your live app. This raw, unfiltered view reveals how much noise a default scan produces.

In this step, you'll pull the OWASP ZAP Docker image and run a full DAST scan against your Valorant Fantasy League site. The sheer volume of alerts will motivate the triage and filtering work you'll do in later steps.

In this step, get ready to:
  • Pull the OWASP ZAP Docker image.
  • Run a full security scan against your live VFL app.
  • Review raw vulnerability alerts in your terminal.
Pull the OWASP ZAP Docker image
  • Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
  • Type Terminal (macOS) or PowerShell (Windows) and press Enter to open it.
  • Pull the ZAP stable Docker image by running this command:
docker pull ghcr.io/zaproxy/zaproxy:stable

You should see Docker downloading image layers one by one, each showing Pull complete as it finishes. Once done, the terminal prints a digest and a status line confirming the image was downloaded.

What is OWASP ZAP?

OWASP ZAP (Zed Attack Proxy) is a free, open-source security scanner that performs Dynamic Application Security Testing. It works by crawling your live web app and actively testing it for vulnerabilities like missing security headers, injection flaws, and misconfigurations.

Running it as a Docker container means you don't need to install Java or any dependencies on your machine. Docker handles all of that inside the container.

Seeing a connection error or timeout?

Make sure Docker Desktop is running. You can check by looking for the Docker whale icon in your system tray (Windows) or menu bar (macOS).

If you see a permissions error, try running your terminal as Administrator (Windows) or prefixing the command with sudo (macOS/Linux).

help me fix a Docker pull error for the ZAP image

Run a baseline scan against your VFL site

ZAP's full scan works in two phases. First, it spiders your app to discover all reachable pages. Then it runs active security tests against every endpoint it found.

Only scan apps you own

ZAP performs real attacks against the target URL. Only run it against applications you own or have explicit written permission to test. Your VFL site is yours, so you're good to go.

Before you run this scan, what do you expect? Do you think your live VFL site will have many security alerts or just a few?

  • Run a full ZAP scan against your VFL site by running this command:
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py -t https://www.valorantfantasyleague.net/ -m 2 -I

What do these flags mean?

  • -t https://www.valorantfantasyleague.net/ sets the target URL to scan.
  • -m 2 limits the spider phase to 2 minutes, keeping the scan fast during development.
  • -I tells ZAP not to return a failure exit code on warnings. Without this, Docker would exit with an error code before you even see your results.

This scan takes a few minutes

The spider runs for up to 2 minutes, then the active scan tests each discovered endpoint. Expect 3-5 minutes total. You'll see output scrolling as ZAP works through each test.

Scan not starting or Docker error?

If you see a message about the image not being found, confirm the pull from the previous substep completed successfully by running docker images and checking that ghcr.io/zaproxy/zaproxy appears in the list.

If the scan starts but immediately exits, make sure you included the -I flag at the end of the command.

help me troubleshoot a ZAP Docker scan that won't start

Review the scan results

Once the scan completes, ZAP prints a summary of everything it found. Each alert shows three pieces of information.

  • Look for lines that start with WARN-NEW or FAIL-NEW in the output. Each one represents a distinct vulnerability ZAP discovered.
  • Note the risk level next to each alert. ZAP classifies findings as High, Medium, Low, or Informational.
  • Scroll to the very bottom of the output. You'll see a final summary line showing how many WARN and FAIL alerts were found in total.

Why so many alerts?

A raw scan with no filtering produces a lot of noise. Many of these alerts are informational or low-risk findings that don't represent real threats to your app.

In the next step, you'll learn to separate signal from noise by triaging these findings and building a rules configuration that focuses on what actually matters.

You've just run a real security scan against a live production app. Next up, you'll triage these findings and build a rules file that filters out the noise so you can focus on genuine vulnerabilities.

Triage Findings and Create Your Rules Configuration

In Step 1, you ran a raw ZAP scan and watched alerts flood your terminal. You now know what OWASP ZAP finds against your live VFL app.

The problem is that raw scan output mixes real vulnerabilities with false positives and informational noise. Triaging findings and creating a rules file is how security professionals focus on what actually matters.

In this step, get ready to:
  • Create a GitHub repo and generate ZAP's default rules configuration file.
  • Triage alerts by marking false positives as IGNORE in your rules file.
  • Re-run the scan with your rules applied and confirm cleaner output.
Create your repo and generate the rules file

You need a place to store your security audit files. You also need ZAP to generate its default rules file so you have a starting point for triage.

  • Go to github.com and click New to create a new repository.
  • Name it vfl-security-audit, set it to Public, and click Create repository.
  • Clone your new repo to the Desktop by running these commands in your terminal:
cd ~/Desktop
git clone https://github.com/[[GITHUB_USERNAME="your-github-username"]]/vfl-security-audit.git
cd vfl-security-audit
  • Confirm you're inside the repo folder by running:
ls

You should see an empty directory (or just a README.md if you initialised with one).

  • Generate ZAP's default rules configuration file by running this scan with the -g flag:
docker run -v ${pwd}:/zap/wrk/:rw -t ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py -t https://www.valorantfantasyleague.net/ -m 2 -g rules.tsv -I

What does this command do?

This runs the same full scan you did in Step 1, but adds two important pieces:

  • -v ${pwd}:/zap/wrk/:rw mounts your current directory into the Docker container so ZAP can write files to your machine.
  • -g rules.tsv tells ZAP to generate a default config file with every rule set to WARN. This file becomes your starting point for triage.

ZAP will run the scan (you'll see familiar output scrolling through) and then write rules.tsv into your current directory.

  • Confirm the file was created by running:
ls

You should see rules.tsv listed in the output.

Don't see rules.tsv?

  • Make sure you ran the command from inside the vfl-security-audit folder. The -v ${pwd}:/zap/wrk/:rw flag mounts your current directory, so the file only appears where you ran the command.
  • If Docker returned a permission error, make sure Docker Desktop is running and try the command again.
  • help me troubleshoot why rules.tsv was not generated by ZAP in my Docker scan
Review and triage your alerts

The generated rules.tsv file lists every rule ZAP found during the scan, with each one defaulting to WARN. Your job is to decide which alerts are real risks and which are noise.

  • Open rules.tsv in any text editor (Notepad, VS Code, or your preferred editor).

Each line follows this tab-separated format:

10035	WARN	(Strict-Transport-Security Header Not Set)
10098	WARN	(Cross-Domain Misconfiguration)

What do the three actions mean?

  • WARN means ZAP reports this alert in the output but does not fail the scan. Keep this for alerts you want to track.
  • IGNORE means ZAP skips this alert entirely. Use this for false positives or alerts irrelevant to your app.
  • FAIL means ZAP exits with a failure code if this alert fires. Use this for critical vulnerabilities that should break a CI pipeline.
  • Look back at the alerts you saw in Step 1. Identify any alerts that are informational noise or false positives for your VFL app.
  • For each alert you identified as noise, change WARN to IGNORE in that line of rules.tsv.
  • Save the file.

How to decide what to IGNORE

If an alert is about a missing header that your hosting provider controls (not your code), it's a candidate for IGNORE. If an alert fires on a URL you know is intentionally public, it may also be noise. When in doubt, leave it as WARN. You can always change it later.

Re-run the scan with your rules applied

Now you'll run the scan again, but this time ZAP will use your rules.tsv to filter results. The -c flag tells ZAP to read your configuration.

  • Before you run the next command, think about what you expect. Will there be fewer alerts in the output this time, or the same number? Why?
  • Run the filtered scan by running this command:
docker run -v ${pwd}:/zap/wrk/:rw -t ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py -t https://www.valorantfantasyleague.net/ -m 2 -c rules.tsv -I

What changed from the previous command?

The -g rules.tsv flag (generate) has been replaced with -c rules.tsv (consume). Instead of writing a new default file, ZAP now reads your edited rules and applies them during the scan.

The scan output should now show fewer WARN lines. Any rules you set to IGNORE no longer appear in the results.

Still seeing the same number of alerts?

  • Open rules.tsv and confirm you used the word IGNORE (all caps) and that each field is separated by a tab character, not spaces.
  • Make sure you saved the file before re-running the scan.
  • help me figure out why my ZAP rules.tsv file is not filtering alerts when I use the -c flag

Your scan output is now focused on real findings. Next up, you'll turn these results into a professional HTML report you can share with stakeholders.

Generate a Professional HTML Report

Your rules.tsv file is now filtering out the noise so you only see relevant alerts. The next problem: terminal output disappears when you close the window.

Stakeholders, hiring managers, and teammates need formatted evidence they can review without running Docker commands. In this step, you will generate professional HTML and JSON reports, then document your findings in a shareable Markdown summary.

In this step, get ready to:
  • Generate HTML and JSON vulnerability reports from your ZAP scan.
  • Review the HTML report in your browser to understand its structure.
  • Create a professional FINDINGS.md summarising your top findings.
Run ZAP with report output flags

ZAP can write its findings directly to files when you pass the right flags. The -r flag outputs an HTML report and the -J flag outputs a JSON report.

  • Run the full scan with report output enabled by running this command:
docker run -v ${pwd}:/zap/wrk/:rw -t ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py -t https://www.valorantfantasyleague.net/ -m 2 -c rules.tsv -r report.html -J report.json -I

What does this command do?

This is the same scan command from Step 2, with two new flags added at the end.

  • -r report.html tells ZAP to write a formatted HTML report to your mounted volume.
  • -J report.json tells ZAP to write a machine-readable JSON report alongside it.
  • The -v ${pwd}:/zap/wrk/:rw mount means both files land in your current directory (your repo folder).

The scan will take a couple of minutes to complete. You will see the same terminal output as before, followed by the report generation.

  • Once the scan finishes, confirm both report files were created by running:
ls

You should see report.html, report.json, and rules.tsv listed in the output.

Don't see the report files?

  • Make sure you included the volume mount -v ${pwd}:/zap/wrk/:rw in your command. Without it, ZAP writes the reports inside the container and they disappear when it exits.
  • Confirm you are in your vfl-security-audit repo folder. Run pwd to check your current directory.
  • On older PowerShell versions, try ${PWD} (uppercase) if ${pwd} does not resolve.

Help me troubleshoot missing ZAP report files

Review the HTML report in your browser

The HTML report is the artifact you will share with stakeholders and include in your portfolio. It organises every finding into a structured, navigable format.

  • Open report.html in your browser by double-clicking it in File Explorer (Windows) or Finder (macOS).

You should see a formatted vulnerability report. Each alert entry shows the affected URL, the risk level (High, Medium, Low, or Informational), a CWE ID, and a description of the vulnerability.

What is a CWE ID?

CWE stands for Common Weakness Enumeration. It is a standardised numbering system for software vulnerabilities maintained by MITRE. When ZAP labels a finding with a CWE ID, it links the alert to a globally recognised vulnerability category that security professionals and hiring managers understand.

Bookmark findings for your summary

As you scroll through the report, note the finding titles and risk levels for any High or Medium alerts. You will document these in your FINDINGS.md in the next substep.

Create a professional findings summary

The HTML report is detailed but long. A FINDINGS.md file gives anyone visiting your repo a quick, readable summary of the most important vulnerabilities you discovered.

  • Create a new file called FINDINGS.md in the root of your vfl-security-audit repo.
  • Paste the following template into the file:
# Security Findings - VFL (Valorant Fantasy League)

Scan Date: 2026-08-12
Target: https://www.valorantfantasyleague.net/
Scanner: OWASP ZAP 2.17.0 (Docker stable)

## Summary

| Severity | Count |
|----------|-------|
| High     | TBD   |
| Medium   | TBD   |
| Low      | TBD   |
| Info     | TBD   |

## Findings

### [Finding Title]

- Severity: [High/Medium/Low]
- OWASP Top 10: [Category, e.g., A05:2021 Security Misconfiguration]
- CWE: [CWE-ID]
- Affected URL: [URL]
- Evidence: [Brief description of what ZAP found]
- Remediation: [Brief recommendation]

---

*Report generated by automated ZAP scan pipeline. See report.html for full details.*

What does each field mean?

  • Severity maps directly to the risk level ZAP assigned (High, Medium, Low).
  • OWASP Top 10 is the category from the OWASP Top 10 list (e.g., A05:2021 Security Misconfiguration). You match this based on the type of vulnerability.
  • CWE is the ID ZAP shows in the HTML report for each alert.
  • Evidence is a one-line description of what ZAP detected. Pull this from the alert detail in report.html.
  • Remediation is your brief recommendation for how to fix the issue.
  • Replace the placeholder [Finding Title] section with real findings from your HTML report. Copy one block per finding for your top 2-3 most significant alerts.
  • Update the Summary table counts to match what your scan found.
  • Save FINDINGS.md.

Focus on High and Medium severity

You do not need to document every Informational alert. A professional report highlights the findings that pose real risk. Two or three well-documented High/Medium findings are more impressive than a wall of Low/Info entries.

Before you move on, what do you expect to see if you open FINDINGS.md in your browser or a Markdown previewer?

  • Preview FINDINGS.md in your editor or on GitHub (after pushing) to confirm the table renders correctly and your finding entries are filled in.

You should see a clean summary table followed by your documented findings, each with severity, OWASP category, CWE, URL, evidence, and remediation filled in.

Table not rendering correctly?

  • Make sure there is a blank line before and after the table. Markdown requires empty lines around tables for proper rendering.
  • Check that the pipe characters | line up and that the separator row uses dashes and pipes (|----------|-------|).

Help me fix my FINDINGS.md Markdown formatting

✔️ Awesome, I've got everything!

Great. Double check you have saved FINDINGS.md and that report.html and report.json are both present in your repo folder.

ⓧ I'd like to double check the full code

Here is the complete FINDINGS.md template. Your version should follow this structure, with the placeholder sections replaced by your actual findings:

# Security Findings - VFL (Valorant Fantasy League)

Scan Date: 2026-08-12
Target: https://www.valorantfantasyleague.net/
Scanner: OWASP ZAP 2.17.0 (Docker stable)

## Summary

| Severity | Count |
|----------|-------|
| High     | TBD   |
| Medium   | TBD   |
| Low      | TBD   |
| Info     | TBD   |

## Findings

### [Finding Title]

- Severity: [High/Medium/Low]
- OWASP Top 10: [Category, e.g., A05:2021 Security Misconfiguration]
- CWE: [CWE-ID]
- Affected URL: [URL]
- Evidence: [Brief description of what ZAP found]
- Remediation: [Brief recommendation]

---

*Report generated by automated ZAP scan pipeline. See report.html for full details.*

You now have three report artifacts: a detailed HTML report for deep review, a JSON report for automation, and a concise Markdown summary for your repo. Next up, you will wire all of this into a GitHub Actions pipeline that runs automatically.

Automate with GitHub Actions

You have professional reports documenting your VFL app's vulnerabilities. The problem is that you had to run Docker commands manually every time you wanted a fresh scan.

A CI/CD pipeline means your app is continuously monitored without you remembering to run anything. In this step, you will create a GitHub Actions workflow that automatically scans your VFL site on every push and creates a GitHub issue with the results.

In this step, get ready to:
  • Create a GitHub Actions workflow file that triggers ZAP scans on push.
  • Add documentation and push all files to GitHub.
  • Verify the workflow runs and creates an issue automatically.
Create the GitHub Actions workflow file

GitHub Actions workflows live in a special directory inside your repo. The workflow file defines when to run, what permissions it needs, and what steps to execute.

  • Create the required directory structure by running these commands:
mkdir -p .github/workflows
  • Confirm the directory was created by running:
ls .github/workflows

You should see an empty directory listed with no errors.

  • Create the workflow file by running:
New-Item .github/workflows/zap-scan.yml
  • Open zap-scan.yml in your text editor and paste the following content:
name: ZAP Security Scan

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  issues: write

jobs:
  zap_scan:
    runs-on: ubuntu-latest
    name: OWASP ZAP Full Scan
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: ZAP Scan
        uses: zaproxy/action-full-scan@v0.13.0
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          docker_name: 'ghcr.io/zaproxy/zaproxy:stable'
          target: 'https://www.valorantfantasyleague.net/'
          rules_file_name: 'rules.tsv'
          cmd_options: '-a'

What does this workflow do?

  • on: push triggers the scan every time you push to the main branch.
  • workflow_dispatch lets you trigger the scan manually from the Actions tab whenever you want.
  • permissions: issues: write grants the workflow permission to create GitHub issues with scan results.
  • The Checkout step pulls your repo code (including rules.tsv) into the runner.
  • The ZAP Scan step uses the official ZAP action (v0.13.0) to run a full scan against your VFL URL with your rules configuration applied.
  • cmd_options: '-a' includes alpha scan rules for broader vulnerability coverage.
  • Save zap-scan.yml.

File not saving in the right place?

Make sure the file is at .github/workflows/zap-scan.yml exactly. GitHub Actions only picks up workflows from the .github/workflows/ directory. If you accidentally created a github folder without the leading dot, rename it to .github.

help me fix my workflow file path

✔️ Awesome, I've got everything!

Great. Double check you saved the file in the correct location.

ⓧ I'd like to double check the full code

name: ZAP Security Scan

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  issues: write

jobs:
  zap_scan:
    runs-on: ubuntu-latest
    name: OWASP ZAP Full Scan
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: ZAP Scan
        uses: zaproxy/action-full-scan@v0.13.0
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          docker_name: 'ghcr.io/zaproxy/zaproxy:stable'
          target: 'https://www.valorantfantasyleague.net/'
          rules_file_name: 'rules.tsv'
          cmd_options: '-a'
Add a README and push everything to GitHub

A good README turns your repo from a folder of config files into a professional portfolio piece. It tells anyone visiting your repo what this project does and how to use it.

  • Create a README.md file in the root of your repo and paste the following content:
# VFL Security Audit

Automated security scanning pipeline for [Valorant Fantasy League](https://www.valorantfantasyleague.net/) using OWASP ZAP.

## What This Does

This repo runs Dynamic Application Security Testing (DAST) against the live VFL web application using OWASP ZAP. It:

- Spiders the application to discover all reachable pages
- Runs active security tests against discovered endpoints
- Reports findings mapped to OWASP Top 10 and CWE classifications
- Automatically creates GitHub issues when vulnerabilities are found

## Pipeline

The GitHub Actions workflow triggers on:
- Every push to `main`
- Manual dispatch (Actions tab > Run workflow)

## Reports

- `report.html` - Full HTML vulnerability report
- `report.json` - Machine-readable JSON report
- `FINDINGS.md` - Human-readable summary of key findings

## Configuration

- `rules.tsv` - ZAP rules configuration (WARN/IGNORE/FAIL per alert rule)
  • Below the Configuration section, add the rest of the README content:
## Running Locally

```bash
docker pull ghcr.io/zaproxy/zaproxy:stable

docker run -v ${pwd}:/zap/wrk/:rw -t ghcr.io/zaproxy/zaproxy:stable zap-full-scan.py \
  -t https://www.valorantfantasyleague.net/ -m 2 -c rules.tsv -r report.html -J report.json -I
```

## Tech Stack

- OWASP ZAP 2.17.0 (DAST scanner)
- GitHub Actions (CI/CD automation)
- Docker (containerised scanning)

## Security+ Alignment

This project reinforces CompTIA Security+ SY0-701 exam domains:
- Security Operations (28%) - Vulnerability management, alerting/monitoring
- Threats, Vulnerabilities, and Mitigations (22%) - Application vulnerabilities, mitigation techniques
- Security Architecture (18%) - Secure application design review

What does the README cover?

The README documents your pipeline triggers, report files, local run instructions, and how the project maps to CompTIA Security+ exam domains. Anyone visiting your repo immediately understands what it does and how to use it.

  • Save README.md.
  • Commit and push all files to GitHub by running these commands:
git add .
git commit -m "Add ZAP security scan workflow and documentation"
git push origin main

What does this push include?

This commit sends your workflow file, rules configuration, security reports, findings summary, and README all to GitHub at once. The push to main will immediately trigger your new workflow.

Push rejected or authentication error?

If you see a permission or authentication error, make sure you are signed into Git with an account that has push access to the repo. You may need to configure a personal access token or use GitHub CLI to authenticate.

help me fix my git push authentication

Watch the workflow run and verify the issue

Your push just triggered the workflow. Now you will confirm that GitHub Actions picked it up, ran ZAP against your VFL site, and created an issue with the results.

  • Open your vfl-security-audit repository on GitHub in your browser.
  • Click the Actions tab at the top of the repository page.
  • You should see a workflow run in progress or recently completed, named ZAP Security Scan.
  • Click into the workflow run to watch the live logs. The scan takes a few minutes to spider and test your VFL site.

How long does the scan take?

The full scan typically takes 3 to 10 minutes depending on how many pages ZAP discovers. You can watch the logs update in real time as ZAP spiders the site and runs active tests.

Before you check the result, predict: what artifact do you expect the ZAP action to create in your repo once the scan finishes?

  • Once the workflow run shows a green checkmark, click the Issues tab in your repository.

You should see a new issue titled ZAP Full Scan Report automatically created by the workflow. This issue contains the full scan results including alert names, risk levels, and affected URLs.

No issue appeared after the workflow completed?

  • Check if the workflow run failed by clicking into it in the Actions tab. A red X means something went wrong during execution.
  • Verify your repo is public. The ZAP action needs issues: write permission, which requires the permissions block in your YAML.
  • Make sure rules.tsv was committed and pushed. The action references this file by name and will fail if it cannot find it.

help me debug my GitHub Actions workflow failure

Your security audit pipeline is now fully automated. Every push to main triggers a fresh scan, and you can also run it on demand from the Actions tab. Next up, the Secret Mission takes this further with scheduled weekly scans.

Secret mission

Add a Scheduled Weekly Scan

Vulnerabilities are not a one-time problem. Your VFL app changes over time, and new issues can appear with every deployment. Can you configure your pipeline to automatically scan every week and catch regressions without lifting a finger?

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs on GitHub Actions free minutes (unlimited for public repos) and a locally cached Docker image, so there are no ongoing costs.

Resources you used:

  • A GitHub repository (vfl-security-audit) with a ZAP scanning workflow that runs on push, schedule, and manual dispatch.
  • The ghcr.io/zaproxy/zaproxy:stable Docker image cached on your local machine.
  • Local project files including rules.tsv, FINDINGS.md, report.html, and report.json.

Keep everything running

No action needed. Choose this if you want your VFL app to continue being scanned automatically.

  • Your GitHub Actions workflow will continue running on every push to main and every Monday at 9 AM UTC.
  • For public repos, GitHub Actions minutes are unlimited. There is no cost.
  • The local Docker image uses disk space only. It does not run unless you execute a scan command.

Pause - I'll come back to this later

Disable scheduled scans to stop the workflow from running weekly while keeping all your files intact.

  • Go to your repo's Actions tab on GitHub.
  • Click on the ZAP Security Scan workflow in the left sidebar.
  • Click the ... menu and select Disable workflow.
  • This stops the scheduled scans and push-triggered scans. You can re-enable it anytime from the same menu.

Delete - I don't want to use this again

Remove all project resources completely.

  • Delete the GitHub repository by going to your repo's Settings tab, scrolling to the bottom under Danger Zone, and clicking Delete this repository.
  • Remove the local Docker image by running:
docker rmi ghcr.io/zaproxy/zaproxy:stable
  • Delete your local project folder. On macOS/Linux:
rm -rf ~/Desktop/vfl-security-audit

On Windows (PowerShell):

Remove-Item -Recurse -Force ~\Desktop\vfl-security-audit

Nice Work!

Nice Work!

You just built a complete automated security audit pipeline that continuously scans your live web app for vulnerabilities. That is a real DevSecOps workflow, not a lab exercise.

You've learned how to:

  • Run a full DAST security scan against a live production web app using OWASP ZAP, triaging results to separate real vulnerabilities from false positives with a rules configuration.
  • Generate professional HTML and JSON security reports documenting findings with evidence, severity ratings, and OWASP Top 10 classifications.
  • Build a GitHub Actions CI/CD pipeline that automatically scans for vulnerabilities on every push and creates GitHub issues for findings.
  • Secret Mission: Configured scheduled weekly scans to continuously monitor your app for new vulnerabilities without lifting a finger.

Ready to quiz yourself?