VERITAS: web vulnerability assessment you can trust.
A multi-tenant platform where customers prove they own a web application, run an active security assessment, and receive findings backed by evidence, confidence levels and remediation guidance, shared with their team.
01The problem
Developers and security teams need a reliable record of what was tested on an application they own: which inputs were reached, which tests ran, which results are actually confirmed, and what should be fixed. A raw scanner alert isn't enough. It doesn't say whether the issue is real, and it doesn't help a developer act on it.
A scanner is also a dual-use tool. If it will attack any URL it's given, it can be pointed at systems the user has no right to test.
02The approach
I designed VERITAS around five principles, decided before any code was written:
- Ownership before testing. A target must publish a DNS TXT record (
veritas-verification=<token>) before any scan is accepted. - AI proposes. Evidence validates. Rules decide. Language models may suggest categories, payload variants and report prose, but confirming a finding is a deterministic decision in code.
- Tenant isolation. Organisation data is protected in the database itself, not only in application code.
- Everything important is audited. Platform changes go into a log that can't be edited or deleted.
- Degrade without inventing. If an AI model is unavailable, scans continue on the deterministic path.
Models cannot change finding counts, severity or evidence. They can only help explain what the evidence already shows.
03How a scan works
- The customer registers a target URL. The app normalises it and rejects embedded credentials and internal hosts.
- The customer publishes a DNS TXT token to prove ownership.
- A scan is queued through a signed internal request and picked up by a background worker.
- The engine crawls the target and can sign in first, using form login, cookies, bearer tokens or custom headers.
- It selects payloads from a corpus of over 346,000 payloads across 65 categories, mapped to the OWASP Top 10 2025, and sends bounded probes. The corpus refreshes itself daily from Veritas Payloads.
- Each response is compared with a baseline to decide whether a finding is confirmed. Severity is derived from CVSS.
- Findings are stored with endpoint, parameter, category, request and response metadata, and the reason for their confidence level.
- Technical and executive reports are generated, plus a remediation record for each confirmed finding.
Architecture
- Next.js app
- FastAPI enqueue
- Redis
- Celery workers
- Scan engine
- Postgres (RLS)
| Layer | Implementation |
|---|---|
| Frontend & BFF | Next.js 15 App Router behind Nginx with TLS |
| Database & auth | Supabase: Postgres with row-level security; email and OAuth sign-in via Google and GitHub |
| Scan pipeline | FastAPI enqueue API with Celery workers on Redis; internal requests HMAC-signed with an expiry |
| Scan engine | About 11,000 lines of Python with a pytest test suite |
| AI | Groq-hosted models for scan analysis assistance and the in-app product assistant |
| Deployment | Docker Compose |
04Challenges & decisions
Stop the scanner being aimed at someone else's system
DNS TXT ownership proof before any scan. The engine re-checks ownership and that the host resolves to a public address, and rejects IP literals, localhost and internal hostnames, so a scan can't be turned against internal infrastructure.
Use AI without letting it invent findings
Confirmation is a deterministic comparison against a baseline response. AI is limited to suggestions and prose, and the scan still completes when the model is unavailable.
Keep each organisation's findings private
Postgres row-level security and security-definer functions enforce tenant isolation in the database, so an application bug can't leak another tenant's data.
Run long scans without blocking the web app
Scans are queued to Celery workers on Redis. The web app talks to the scan API only through HMAC-signed requests that expire.
Make administrative actions accountable
Organisation changes are logged, and platform changes go into a hash-chained audit log that can't be edited or deleted. The Super Admin control centre runs on its own hostname behind MFA.
05What it does today
- Personal workspace for every account, with optional team organisations.
- Organisation roles (owner, admin, analyst, developer, viewer), email invitations and authenticator (MFA) requirements.
- Live scan session view.
- Technical, executive and advanced reports, downloadable as PDF, Markdown and JSON.
- Remediation ticket list, support tickets and an in-app product assistant.
- Plan catalogue with quotas enforced in the database; Stripe Checkout with promotion codes and invoices.
- Super Admin control centre with MFA, maintenance mode, operational telemetry and the tamper-evident audit chain.
06Outcome
VERITAS is live at scanwithveritas.tech. I designed and built it alone, from the scan engine and payload corpus to billing and the admin control centre. The payload corpus is also published as its own open, self-updating dataset, Veritas Payloads, live at payloads.saifuliqbal.dev.
Building it taught me application security from the inside: how inputs are reached, how findings are proven, and how results should be reported so developers can act on them.
I'm happy to walk through a live scan. Get in touch.