SECURITY TESTING IN CI

Security checks on every PR,not once a year.

Switch on security in CI Setup and Verity scans both halves of your product: your running app at a staging or preview URL, and your source code. Pull requests get a fast passive scan and a static scan of the files they change; merges get a time-boxed active scan. Findings arrive severity-ranked, with the URL or file and line, and never silently pass.

What it checks

Running app

Missing security headers, cookie flags, information disclosure, cross-site scripting and other OWASP Top 10 risks.

Source code

Injection patterns, unsafe APIs, hard-coded secrets and risky CI configuration, pointing at the file and line.

Every change

Diff-only static scans on pull requests keep feedback fast; full scans run on merge.

Real evidence

A scan that fails or inspects nothing is reported as a failed scan — never as zero findings.

How it works

01
Turn it on
Enable security in CI Setup and give a staging or preview URL for the app scan.
02
Commit the workflow
Scans run in containers on your own runner — your code never leaves your CI.
03
Work top-down
Fix critical and high first; a finding that disappears on the next scan is resolved.

.github/workflows/verity.ymlEXAMPLE

- uses: qashift/verity-action@v1
  with:
    token: ${{ secrets.VERITY_INGEST_TOKEN }}
    tier: full
    engines: ui,security
    security-target-url: https://staging.example.com
    security-dast-depth: full   # passive "baseline" on PRs

Why teams choose Verity

Code stays in your CI

Static analysis runs on your runner; only findings are sent to Verity.

Advisory, not blocking

Findings are ranked issues alongside your test results, so security work is visible without breaking builds.

Time-boxed active scans

Full active scans have a configurable time limit, so merges never hang.

One place for every test type

UI, API, visual, AI-agent, load and security results share one run history and one verdict per release. Every plan includes all six.

Frequently asked questions

What is the difference between DAST and SAST?

Dynamic analysis (DAST) tests your running app from the outside, like an attacker would. Static analysis (SAST) reads your source code for vulnerable patterns. Verity runs both.

Is an active scan safe to run?

Run active scans only against environments you own, such as staging or a preview deployment. Pull requests use the passive baseline scan by default.

Do security findings fail the build?

No. They are reported as severity-ranked issues in Verity; your team decides what blocks a release.

AI API testingGenerate API tests with AI from your OpenAPI spec: request chains, auth and response checks as Playwright code, plus automatic contract checks across every operation.LLM & AI agent evalsTest your chatbot, RAG assistant or AI agent on every deploy.Load testing in CIGenerate a load test from your OpenAPI spec and run it in CI: a smoke check on every pull request and load, stress, spike, soak or breakpoint profiles on merge.

Try it on your own app.

Free plan, no credit card: 15 AI-written tests a month and unlimited runs in your CI.