An audit you can hand to a regulator
We read your application the way an attacker would, line by line, and measure it against a normative framework we declare up front. Every finding is then handed to a second reviewer who cannot see how it was reached and whose instructions are to refute it. What survives goes in the report, scored, evidenced, and mapped to the regulatory obligations you actually have to answer for.
This is manual review of the source code, not a scanner run with a logo on the cover. Tooling locates candidates; the conclusion always comes from reading the file and following the call chain. A finding that was not confirmed by reading does not enter the report.
What we measure against
The framework is declared before the audit starts, and the version of every standard is reconfirmed at the outset and recorded in the report header. Standards move, and a report citing a withdrawn edition loses its authority.
OWASP ASVS 5.0.0
Verification standard. Level 2 by default, Level 3 for the modules that justify it. Every finding cites the requirement it fails.
OWASP Top 10:2025
Application risk categorisation, against the current edition rather than the one everybody still quotes.
OWASP API Security Top 10 2023
A dedicated pass with its own coverage map when the application exposes services.
OWASP Top 10 for LLM Applications 2025
A conditional lens, applied when the application integrates a model.
CWE and CWE Top 25 (2025)
Weakness identification. The Top 25 informs prioritisation; it does not replace it.
CVSS v4.0
Score and full vector per finding, derived deterministically rather than estimated.
EPSS and CISA KEV
Dependency prioritisation, where known exploitation beats a theoretical score.
CycloneDX 1.6 or SPDX 3.0.1
Software bill of materials, at or above the BSI TR-03183-2 version floor.
Mapped to the obligations you answer for
A technical finding rarely survives the trip to a board on its own. Each one is tied to the code of the compliance measure it touches, which turns the report from a technical argument into a compliance argument. That is the form in which it actually travels.
RJC, Decreto-Lei n.º 125/2025
The Portuguese cybersecurity legal regime, in force since 3 April 2026, transposing NIS2.
Regulamento n.º 756/2026 (CNCS)
Annex IV sets the minimum measures per entity group. Each finding carries the code of the measure it touches.
GDPR Articles 9 and 32
Special categories of data and security of processing, where the application handles them.
Cyber Resilience Act
Where a component comes from an external supplier, the report flags what the CRA will require of that supplier.
Portuguese public bodies and other in-scope entities self-identify on the CNCS MyCiber platform, and then have a two-year window to implement the minimum measures. An audit against Annex IV tells you where you stand in that window while there is still time to act on the answer.
Every finding is attacked before you see it
Each finding goes to a second reviewer who receives only the file, the lines cited, the claim and the exposure statement. They do not see how the first reviewer got there, and their instruction is to refute it. What is refuted is dropped; what survives with a different severity goes to reconciliation.
This exists because the author of a finding is the worst judge of their own line of code, and in a report that will be read by an external party, an invented call chain costs far more than the finding is worth. A refutation is held to the same standard: a reviewer who dismisses a finding because they could not find something has to show how they searched.
Two statements, not one
The audit says what is wrong, and it also says what was examined and found sound, with the search pattern on show. Without the second half, nobody can tell "this does not exist" apart from "nobody looked", and the next audit pays again for ground already covered.
The same discipline produces the ASVS coverage table, chapter by chapter from V1 to V17, stating for each what was verified, what passed, what failed, and what could not be checked and why. That table is what supports any claim that the audit was complete, and it is the first thing a re-audit consults.
How the audit is run
Manual source-code review, not a scanner run: tooling locates candidates, conclusions come from reading the file and following the call chain
Blind adversarial verification of every finding by a second reviewer instructed to refute it, so plausible-but-wrong findings never reach you
Two statements, not one: what is wrong, and what was examined and is sound, with the search pattern on show
An ASVS coverage table, chapter by chapter from V1 to V17, saying what was verified, what passed, what failed, and what could not be checked
Findings mapped to the compliance measures you are accountable for, which is the form the argument has to take to travel to a board
A credential rotation sheet with order, owner, dependencies, and a suggested window, so the report is work you can act on
Read-only throughout: nothing in your repository is modified, created, or deleted, and no builds are run
What you receive
Three documents, because three different people have to act on this and they cannot all read the same one.
The report for the administration is written from scratch and carries no credentials, no file paths, and no code. The technical report carries everything, including secrets in full, because the credential rotation sheet needs them and masking an already-exposed secret protects nothing while making the fix harder. It circulates under restriction. The effort and cost note is for whoever decides on contracting, and states its assumptions and what falls outside the scope.
When the code cannot leave the building
Where the sensitivity of the data justifies it, the audit runs entirely inside your perimeter, on hardware we bring or hardware you already own, with open-weight models and no route to any external service. Nothing about your code, your configuration, or your findings leaves the environment. This is the same containment discipline behind IBEX and Meerkat, applied to the audit itself.
We will also tell you what it costs you, because that matters more than the reassurance. The systematic reading holds up well on local models: pattern recognition across a large codebase is what they are good at. What degrades first is judgement, and judgement is where the value sits: calibrating severity against real exposure, refusing an attractive attack chain because the code does not support one link in it, recognising that a dependency's known vulnerabilities are not reachable in this application rather than adding them to the count. For work that will face a supplier in contradiction, we say so plainly and agree the split with you in advance rather than discovering it in the report.
Where this applies
Public bodies establishing their position against the minimum measures of the national cybersecurity regime
Regulated organisations that need an audit trail an external auditor or supervisor will accept
Due diligence on an application delivered by a supplier, before acceptance or renewal
Classified or otherwise sensitive estates where the audit has to run inside the perimeter
Products behind the closed-perimeter option
Where the audit has to run without touching the internet, these are the platforms that make it possible.
IBEX
Air-gapped AI Security & Attack Surface Platform
See everything, connect nothing: air-gapped AI security and attack-surface management for the classified, isolated, and operational networks the cloud can never reach.
Learn more
Meerkat
Sovereign AI with a Gate
On-premises AI with a per-request gate that decides what may reach a cloud model, and what never leaves the building.
Learn more