Security testing is most useful when it happens automatically, on every build, rather than once before a big release. Adding DAST to your CI/CD pipeline catches new vulnerabilities while the change is still fresh in the developer's mind.

How it works

The pipeline deploys the build to a test environment, runs a DAST scan from the command line, and checks the result. If findings at or above a chosen severity appear, the pipeline fails, just like a failing unit test. Reports are saved as build artefacts.

Why it matters

• Vulnerabilities are caught days or weeks earlier, when fixes are cheapest.
• Security becomes part of the normal definition of done.
• Findings appear in the tools developers already use.

Best practices

• Start with a severity threshold of High or Critical, then tighten it.
• Use a config file kept in version control, so every run is repeatable.
• Keep secrets in environment variables, never in the config file.
• Publish SARIF so findings appear in your code-scanning dashboard.

How Vooki Pro helps

• vooki-pro-cli runs the same scans as the desktop app from a JSON config file.
• Export the config straight from the scan wizard, so the CLI scan matches the one you tested by hand.
• Set fail_on_severity and the run exits with code 2 when findings reach that level.
• Produces SARIF, HTML, PDF and JSON reports, and a .vpscan archive you can open in the desktop app for triage.

Frequently asked questions

Will DAST slow down my pipeline?

Scope and policy control the scan time. Many teams run a focused scan per build and a full scan nightly.

How do I fail a build on security findings?

Set a severity threshold; the scanner exits with a failure code when findings reach it.

Related: GraphQL security testing · Reducing false positives in DAST