Acunetix has published a walkthrough showing how its dynamic scanner can be wired straight into a GitHub repository so that every pull request triggers a full web vulnerability scan before code is merged. The setup spins up a staging container from the changed code, runs a scan against it through Acunetix's API, and fails the pipeline if any vulnerability is found. The staging container is then torn down.
Decision checklist: Before you deploy this integration
- [ ] **Set your fail threshold.** The sample script exits non-zero on any single vulnerability. For most pipelines, a severity threshold (fail on High/Critical only) keeps security from blocking routine development.
- [ ] **Match your staging to production.** A stripped-down container will miss auth flaws, session issues, and business-logic bugs. Seed test user credentials if you need coverage beyond input handling.
- [ ] **Monitor licence usage.** Each PR consumes a target slot until cleanup runs. If your licence has a cap, ignored cleanups can push you over the limit silently.
- [ ] **Layer with SAST/SCA.** DAST catches runtime issues but cannot reach dependency vulnerabilities or code-level flaws. Budget time to add separate coverage.
How the integration works
The workflow uses three pieces: a sample web app, a GitHub repository, and a Bash script that drives Acunetix over its REST API.
The script first builds a Docker container from the project's Dockerfile and waits for an HTTP 200 response, confirming the app is up. It then calls Acunetix to create a scan target, trigger a scan, and poll for completion. When the scan finishes, the script checks the vulnerability count. If at least one vulnerability is found, the pipeline exits with an error code and the pull request cannot merge. A cleanup function then deletes both the scan and target records via the API.
Why it matters
This pattern turns DAST from a periodic audit into a continuous gate. Development teams get immediate feedback on security regressions without scheduling a separate scan window.
The trade-off is severity granularity.** Blocking merges on any finding sounds safe, but low-confidence or informational alerts will stall development and push teams to route around the gate entirely. A tiered rule—fail on High/Critical, warn on Medium—keeps both security and velocity intact.
Environment parity determines what you actually catch.** Scanning a minimal PHP container reveals input-handling issues and missing headers. It will not surface auth bypasses, session hijacking, or access-control flaws that depend on a real backend. If your app relies on those layers, seed your staging container with test credentials.
Cleanup is a licence concern, not just housekeeping.** Each PR leaves a target record in Acunetix until the cleanup function runs. On high-velocity teams, uncollected targets can accumulate quickly and affect performance or push a metered licence over its cap.
What to watch next
- Adjust the script to parse scan results by severity rather than by raw count
- Add authenticated scanning by injecting a test session token into the staging container
- Track target count against your licence ceiling, especially on busy branches
- Pair this with SAST for code-level flaws and SCA for dependency vulnerabilities
Key takeaways
- Acunetix's GitHub integration makes DAST a merge gate instead of a manual step
- The script handles API calls, polling, and cleanup, but uses a flat fail-on-any-vulnerability rule
- Treat the result as one signal; auth-aware and component-level scans need separate coverage
Frequently asked questions
Does the integration require GitHub Actions specifically?
No. The Bash script and Docker steps run on any CI runner that can call the Acunetix API and reach Docker.
What happens to old scans and targets after a pipeline run?
The cleanup function deletes the scan and target records via the Acunetix REST API, so each pull request should leave no lingering artifacts.
Can I make the pipeline fail only on high-severity findings?
The sample fails on any single vulnerability. Modify the script to parse scan results by severity and exit non-zero only above your chosen threshold.
Is a Docker-based staging environment enough for accurate DAST?
It covers input-handling and configuration flaws. For authenticated or business-logic issues, use a more production-like environment with seeded users and sessions.