Security audit
What is right, what is not, and how it was proven.
A security audit is for two things: sleeping well and signing with a clear conscience. We review the code, the data, the infrastructure and the tenant isolation of a system that already exists, and deliver a report where every statement carries its evidence. No inflated findings to justify the invoice, and no "all good" that nobody can stand behind later.
Who it is for
- Systems that sign long operating contracts and must show a cybersecurity programme, not a patch.
- Multi-tenant platforms that keep several clients’ data in the same database and need to prove they cannot see each other.
- Teams about to bid or face a client review who want to arrive with the report done, not with promises.
- Systems with AI inside: which data leaves towards an external model, behind which locks, with which log.
What gets reviewed
- 01
Application and code
Injection, authentication and sessions, route-by-route authorisation, secret handling, dependencies and the admin surface. Line by line where it matters, not by sampling.
- 02
Data and tenant isolation
Row Level Security policies and what the policies do not cover: side channels through unique indexes, foreign keys, shared sequences, error messages and response times.
- 03
Infrastructure and deployment
TLS and headers, CORS, exposed ports, system users and privileges, backups with tested restores, logs and who can read them.
- 04
Traceability and compliance
Append-only logs, audit per transition, and how all of the above maps to what the contract, the tender or the applicable data protection law demands.
- 05
AI inside the system
What leaves towards external models and what does not, anonymisation before it leaves, locks to turn it on, and a record of what was actually sent.
- 06
Sustained operation
Patches, incident response, periodic testing: what a long contract demands as a programme and almost never exists when the audit arrives.
How it is done
- 01
Scope and access
We agree what is in and what is out, and receive read access to the repository, the real configuration and a test environment. Production is not touched.
- 02
Review with evidence
Code, configuration and controlled tests. Every finding is reproduced before it is written down; if a hypothesis could not be proven, the report says so plainly.
- 03
Report
Verdict, what is right with its evidence, findings by severity with location and reproduction, and what is missing as a programme. Presented and discussed, not emailed and forgotten.
- 04
Closure
A second pass over the fixes. What was fixed is marked as verified; what was decided not to fix is documented with its reason.
The deliverable
Security audit report
Real structure of the report · no client data: conclusions and locations
-
1. Verdict
One sentence a board understands: how solid the system is and what separates what exists from what the contract demands.
-
2. What is right, verified
A table per area with status and concrete evidence (file, migration, test). What is right is documented too: it is what avoids auditing it again.
-
3. Findings by severity
Critical, high, medium, low. Each with location, how to reproduce it, the real risk today, and whether it blocks deployment or not.
-
4. What is missing as a programme
Tested backups, hardening, incident response, periodic testing: what is not a patch but a practice, with who and how often.
-
5. Technical annex
Commands, queries and configurations used to verify, so the team itself can repeat it.
The research behind it
The judgement does not come from a checklist: it comes from hunting flaws in the base software our own clients run on. On PostgreSQL we maintain fuzzing and logic-testing infrastructure, and report what we find to the project.
- 674 M
- fuzzing executions
- over the type parsers of the PostgreSQL core, with AFL++ and ASan on eleven lanes
- 15 M
- cases against pgvector
- vector binary protocol with our own harness; zero crashes, which is the expected result for a healthy project
- 10+
- bugs reported
- to pgsql-bugs with reproductions; several confirmed by project committers
The finding that defines the service
Row Level Security hides another client’s rows in a SELECT, but a unique index is physical and global: a probing INSERT with another client’s email fails with "duplicate key" and confirms that the data exists. Exploitable with low privileges, no misconfiguration, no superuser. It is not a PostgreSQL flaw (it is in its documentation), but it is a flaw in almost every multi-tenant platform that uses RLS with global unique indexes. We found it attacking our own platform; it is the first thing we look for in a client’s.
For assisted analysis we use Claude within Anthropic’s Cyber Verification Program (vulnerability research and disclosure, security tool development), approved in September 2026. It is an access adjustment, not an endorsement: findings are held up by evidence, not by the model.
Questions
How long does it take and what does it cost?
Two to four weeks depending on the size of the system, with a fixed scope and price agreed before starting. If something outside the scope shows up during the review, we flag it and decide together.
Do you need access to production?
No. We work on the repository, the real configuration and a test environment. If production has to be looked at, it is read-only, agreed in writing and logged.
What happens with what you find?
The client is told first, with the time needed to fix. If the flaw lives in third-party software, it is reported to the project under responsible disclosure, as we do with PostgreSQL.
Does it work for a tender or a contract?
That is the typical case. The report is structured against the requirements of the tender or contract, with the location of every piece of evidence by document, section and page, so the evaluator can find it.
Do you audit systems you did not build?
Yes, and it is the usual case. All we ask for is access to the code and the configuration: an audit without code is a survey.
Contact
Got a process falling apart on you?
Tell us which operation you want to put in order. If we can help, we say so with a plan and a timeline; if it is not our thing, we say that too.
Write to us at contacto@betrivasystems.com · We reply within one business day.