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 identifier 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.
Across the EU, provision by provision
NIS2 Article 21 and its Implementing Regulation (EU) 2024/2690, with DORA for the financial sector.
| Provision | What it requires | What the audit delivers |
|---|---|---|
| §6.10Reg. (EU) 2024/2690 | Obtain information about technical vulnerabilities, evaluate the exposure to them, and manage them. | The report is the documented record of the vulnerabilities found, each with its exposure and severity. |
| §6.5Reg. (EU) 2024/2690 | Security tests to a documented methodology, recording type, scope, time and results, with the criticality and mitigating action for each finding. | A declared methodology, a coverage table, and a severity and recommended fix per finding: that record, ready to file. |
| §6.2Reg. (EU) 2024/2690 | Rules for secure development, applied in-house and when development is outsourced, across every phase up to testing. | An independent test of whether those rules held, read in the code itself. |
| Art. 21(2)(d) and (3)NIS2 | Supply chain security, weighing each supplier's cybersecurity practices and secure development procedures. | An audit of the code the supplier delivers is the evidence behind that assessment. |
| Art. 21(2)(f)NIS2 | Policies and procedures to assess the effectiveness of the cybersecurity measures. | An external audit is that assessment, made on the code rather than on paper. |
| Art. 25(1)DORA | A resilience testing programme that includes source code reviews where feasible. | A source code review, in a form the testing programme can file. |
| §12.2Reg. (EU) 2024/2690 | Asset handling through to disposal, including the irretrievable deletion and destruction of information. | On the appliance, a secure disposal certificate at the end of the work, signed by both parties. |
Implementing Regulation (EU) 2024/2690 binds digital infrastructure, ICT service and digital providers directly, and for every other sector it is the most detailed reading of Article 21.
Alongside NIS2
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.
National transpositions of NIS2
Where a member state publishes its own catalogue of measures, each finding also carries that code. In Portugal that is the RJC, Decreto-Lei n.º 125/2025, in force since 3 April 2026, with Regulamento n.º 756/2026 of the CNCS, whose Annex IV sets the minimum measures per entity group.
In Portugal, public bodies and other in-scope entities register with the CNCS on its MyCiber platform, and the minimum measures apply from 22 June 2028, 24 months after Regulamento n.º 756/2026. An audit against Annex III, or Annex IV for public bodies, tells you where you stand 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
Anatomy of a finding
Every entry in the report answers the same questions: what it is, where it is, what it implies, and how to fix it.
src/auth/session.py, lines 118 to 142, and the sign-out request in the web layer.
High, in CVSS v4.0, with the full vector on the record and the score computed from it.
Signing out deletes the cookie in the browser, but the server keeps accepting the identifier until it times out.
Invalidate the session on the server at the moment of the request, not only in the browser. Depending on the scope contracted.
An identifier copied before sign-out still gives access to the account, even after the user believes they have left.
The session management requirement of OWASP ASVS 5.0, and the NIS2 measure it touches, in the national rules that apply to you.
Illustrative example.
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 remediation effort estimate is for whoever decides on contracting, and states its assumptions and what falls outside the scope.
Run it yourself: the audit as software
The same lenses, verification workflow, and report engine, packaged as an application.
Goshawk is this audit turned into a product. Create an audit over your repositories, pick the compliance profile, and run the automated scan on demand, with its limitation stated in writing on the report itself, or order the full tier, where our senior reviewers drive the verification and the report carries an SLA. A self-service scan never presents itself as equivalent to a reviewed audit; that honesty is the product's first feature.
Which audit
Four ways to have your code audited, and when each one fits.
| Option | What it reviews | Who verifies | What you receive | Pick it when |
|---|---|---|---|---|
| Security Auditthis page | The applications you name, against OWASP ASVS 5.0, Level 2 by default. | Our reviewers, with a blind second review that tries to refute every finding. | Three documents: for the administration, the full technical report, and the remediation effort estimate. | A regulator, an auditor or a board has to accept the result, and people have to answer for it. |
| Goshawkautomated scan | Your repositories, on demand, as often as you like. | The application alone: the same lenses and the refutation step, no human review. | A report that states in writing what an unreviewed scan can and cannot claim. | You want the systematic sweep in hours, between audits or on every release. |
| Goshawkfull audit | Your repositories. | Our senior reviewers drive the verification queue and reconcile disputed findings. | The reviewed report, with an SLA in days. | You want the audit's rigour on your own schedule, through the application. |
| Ibexcode pillar | The Git repositories on the network Ibex sits in, as an immutable snapshot, offline. | The appliance, on your hardware; the source never leaves it. | SARIF findings, tied to the host the code runs on. | The code cannot leave the building and Ibex already watches that network. |
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. It runs on the Ibex appliance, the same containment discipline behind Marmot, applied to the audit itself.
We will also tell you what the closed perimeter costs you in audit capability, 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.
Three ways to run it
The same lenses, the same verification and the same report, wherever the audit runs. What changes is where your code sits and which models read it.
Air-gapped appliance
A sealed box on its own hardware, inside your perimeter. Every model runs on the appliance, and the only thing that leaves is the report, on your media. For code that may not leave the building.
Cloud instance
An instance of your own, run by us, one per client and never shared. Nothing to install and no hardware on site, with every stage of the audit on frontier models. For teams that want the audit on demand.
Hybrid
A cloud instance where the lenses read the whole codebase on a model we host, and only verification and the write-up go to a frontier model, which sees each claim and the lines it cites rather than the repository.
The appliance never runs in hybrid, and no setting makes it. Its whole argument is that the code stays on the box, and an argument a setting can undo is only a setting.
How the on-site work runs
In air-gapped mode, the appliance arrives, works inside your premises, and leaves without taking anything with it.
- A new data drive, installed with your security team present.
- Encrypted with a passphrase your team writes.
- Code copied from the repository, or from removable media mounted read-only.
- The version identifier, or a hash of the content, recorded in front of your team.
- An autonomous audit, operated only from the local screen and keyboard.
- Nothing of the work is written to the system drive.
- A hash-chained audit log, on the data drive.
- Sent to your SIEM, where there is a network and you ask for it.
- The report handed over on your media, with its hash on the delivery record.
- The data drive, the encryption key and the audit log stay with you.
- The system drive securely wiped in front of your team, with a NIST SP 800-88 Rev. 2 certificate signed by both parties.
- The appliance leaves with that drive blank, or with no drive at all if you prefer to keep it once wiped.
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
The software behind the audit
Goshawk runs the audit itself. Ibex and Marmot are the platforms for the estates where nothing may touch the internet at all.
Goshawk
Only what survives refutation ships
Security audits of your repositories as an application: automated scanning with its limits stated in writing, and a full tier with senior human verification.
Learn More about Goshawk
Ibex
Security for the networks the cloud can't reach
Air-gapped attack surface management: network, code, AI and databases assessed from one sealed appliance inside your perimeter, with findings tied to the host they run on.
Learn More about Ibex
Marmot
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 about Marmot