Security
Catch security risk in the same quality workflow.
The tests you already have sign in as real roles and drive real flows. That is most of what an authorization check needs, so Vera does security work where the tests already live — and reports each kind of finding as exactly the kind of claim it is, because they are not interchangeable.
1 · Authorization — observed
Vera signs in as each role and attempts what that role must not be able to do. A cell marked denied counts as satisfied only when Vera saw the refusal. A broken selector, a timeout and a 500 all look like “correctly denied” to a naive check — Vera records those as inconclusive and they never turn green. This is the one layer where Vera made the thing happen and watched it happen.
2 · Scan signals — reported
An OWASP ZAP scan crawls the target and flags patterns. Everything it returns is a possible vulnerability and is labelled that way in the data, not just in the copy: ZAP matched a shape, it did not watch your app fail. Scans are capped in duration, page count and request rate, because an uncapped scan of a staging environment is a load test nobody asked for.
3 · Imported results — reported
Bring SARIF from whatever you already run. The tool’s own severity is passed through unchanged rather than remapped to a Vera opinion — re-scoring it would silently overrule a judgement made with context Vera does not have, while looking like agreement. Anything the tool suppressed stays suppressed, because importing it anyway undoes somebody’s triage.
4 · Vera’s own posture — not your app
Sealed secrets, SSRF guards, tenant scoping, an append-only ledger. These protect Vera. They test nothing whatsoever about your application. It is listed here as a fourth layer precisely so it cannot be read as a third-party assessment of your product — a vendor handing you its own compliance posture as your security report is the oldest trick on this page. The full list ↓
There is no security score. Any single number has to weigh a missing X-Frame-Options against an authorization bypass, and there is no honest weighting of those two. Vera counts findings per kind and stops there. Teams work out within a week that a blended grade is arbitrary, and what they learn from it is to discount the entire report.
This is not a penetration test, and Vera will not pretend otherwise. There is no exploitation, no chaining one finding into another, and no proof that a finding is reachable in your production environment. A scanner that flags a pattern and a person who breaks in are different things, and only one of them is happening here.
Scanning is permissioned per project and per host: somebody has to record that they are authorised to test that host before a scan will start, and that permission is stored, attributed and revocable. Vera will refuse a scan rather than take the target on trust.
Layer 4 — Vera’s own posture
How Vera protects what you give it.
Test platforms hold credentials, sessions and API keys, and Vera treats all of them as radioactive. Everything below is about Vera — it is not a finding about your application, and it is kept on its own so it can never be mistaken for one.
Ship with it
Wire it into the pipeline you already have.
Vera meets your stack where it is — GitHub, Slack, your CI, even your AI assistant.
- GitHub Action — run a project, suite, or single test against a preview deploy. Vercel and Netlify preview URLs are auto-detected.
- Honest gating — the PR fails only on real failures. Quarantined tests, passes-on-retry and passes-on-heal surface as warnings, so nobody learns to ignore red.
- Green is not one thing — a run that only went green because self-heal rewrote a selector is reported as
healed, never folded into the pass. Self-heal is an explicit repair action, not something an unattended CI run does to your selectors behind your back. - GitHub App — import a repo as a project, let the AI discover config from source, and review autosync proposals when the app changes.
- REST API + tokens — scoped bearer tokens (shown once, stored hashed) to trigger and await runs from any CI system.
- MCP server — ask Claude to run a test or suite, inspect a failure, apply a repair, author a new test, or file an issue — straight from your editor.
- Import from anywhere — Cypress, Playwright, WebdriverIO, Java/Python Selenium via AI conversion, TestCafe, Postman, a browser HAR, or an OpenAPI spec — all become editable no-code steps.
- Export without lock-in — any test as runnable Playwright, WebdriverIO, Selenium (pytest), or TestCafe code; any run as JUnit XML.
- CI runner agent — the
vera-agent-ciaction drains queued runs on your own GitHub runners — including iOS simulators onmacos-*.
# Gate every PR on your real user flows - name: Run Vera E2E suite uses: vera/vera-run@v1 with: api-url: https://vera-agent.com api-token: ${{ secrets.VERA_TOKEN }} project: proj_checkout environment: preview preview-url: ${{ steps.deploy.outputs.url }} # opt in to a stricter gate: # fail-on-flaky: 'true' # fail-on-healed: 'true' # quarantined, passed-on-retry and healed => warnings, # the check only fails on real failures
Get started
Your next critical regression should be found by Vera — not by a customer.
Show Vera what your business depends on and start protecting it before the next release. Free plan, your own AI key, no credit card.