A security audit that separates what is confirmed from what is doubtful.

For companies and public bodies with software of their own or built by a supplier: a website, a portal, an API or an internal application. Also for anyone who has to show security assurances to a customer or a public body.

You do not know whether your application has holes. A supplier built it, or a team that is no longer there. The last audit was a PDF with hundreds of warnings from an automatic tool, in no order, and nobody knew where to start. And now a customer asks for proof that your software is secure.

We read the code and look at the application the way someone who wants to get in would. Each possible flaw is proposed by one agent and a different one tries to prove it false. What holds up reaches the report, with its evidence. We tell you what to fix first and the smallest change that closes it.

We agree the scope: which repositories and which applications. You give us read-only access to the code. We work without touching anything: we do not change the code or run it outside an isolated environment. You get the report with what is confirmed, what is still to be validated and the minimum fix for each finding. If you want, we fix it ourselves and check it again.

Confirmed findings by severity, findings still to be validated, candidates discarded during verification and, if there is a second round, findings already fixed.

The audit starts with automatic scanners: Semgrep for the code, OSV-Scanner for the dependencies, Trivy for images and configuration, and Gitleaks for credentials in the history. What they find are leads, not findings.

Then comes reconnaissance: what the application does, where data comes in and what it protects. The code is split into units and each one is reviewed by an isolated agent, which starts from those leads and also looks for what a scanner cannot see: permission and logic flaws.

Each candidate goes to an independent verifier agent whose job is to refute it. What it cannot refute is confirmed; what can be neither confirmed nor ruled out is delivered as still to be validated. Findings are stored in a fixed, validated format, and the report is built from it.

For Liferay we use our own guide, with the usual flaws in its modules, services and permissions. In our projects, static analysis also carries our own rules for Liferay and stops the integration if a new finding appears.