The whole development lifecycle: architecture before anything is built, the pull requests that carry real risk, the release gate, and the tests that stay in your pipeline afterwards. Our depth is in Rust, C, C++ and Solidity.
Scanners find the bug classes that look the same in every codebase. The ones that cost you money are specific to your business: a check in the wrong order, an authorisation decision made where it cannot be enforced, an invariant everyone assumed held. Those need someone to agree what "wrong" means for your system and then read the code against it. We start by writing down what must never happen, and test for that.
The lifecycle runs left to right. Where we join it, and how much of it we cover, depends on what you are building and what is already in place.
Illustrative. Most engagements are narrower than the whole line, and which part matters is a decision we make with you.
One example: the OpenVPN 2.7 audit ran 16 weeks and found 18 issues, one critical.
The code spans enterprise applications, blockchain and smart contracts, firmware, and AI-backed features. The method is the same in each: agree the rules the system must not break, walk the design and the code against those rules, then try to break it and turn each break into a test you keep. The tests stay with you, so the same bug fails a build instead of returning after we leave.
Across four models and two production codebases, a small model running on a laptop produced a set of findings comparable in size to a frontier cloud model, in under 90 minutes per codebase, without any source file leaving the machine. Some things do still leave: the file tree, the database schema, the API routes, the dependency list, and the findings themselves, which can include line numbers and short code excerpts.
How
Controlled comparison of four models over two codebases (~150 and ~85 source files) with a fixed harness. Two further models acted as orchestrators rather than subjects, which is why the count is four and not six.
What it does not support
Counts are raw findings, not validated true positives, and one codebase is open source, so contamination is not ruled out.
Beyond Fable: can a local LLM replace cloud AI for security code reviews?A 16-week audit of the OpenVPN 2.7 release candidate found 18 issues, one of them a critical logic bug in a replay check. Version 2.7 shipped with the important fixes in, and the fuzzing harnesses stayed behind in the project’s own repository, so the same tests can be re-run without us. The work was funded by the Sovereign Tech Agency together with the Open Technology Fund, which is why we can name all of it.
How
A four-month review of a release candidate, sponsored by the Sovereign Tech Agency in cooperation with the Open Technology Fund. Publicly funded, so the scope, the findings and the harnesses are all public, which is why we can name it.
OpenVPN 2.7 security audit: 18 findings, one critical bug, and what made the differenceA pre-release audit of one feature or release, with a clear answer on whether to ship.
We review the pull requests that carry real risk, on an ongoing basis, in your workflow.
One of our code auditors works inside your team, fixing things instead of reporting them.
Available on any of the three
Model-assisted review at scale, with your source code staying in your environment.
You get
Verified findings, and the review harness so your team can re-run it.
Also available across the rest of the lifecycle: security architecture review before code exists, and working alongside the team that implements it. Threat modelling, where we run the workshop that produces the invariants rather than being handed them. Fuzzing and harness development, left in your repository so the same class of bug fails a build after we leave. CosmFuzz, our CosmWasm fuzzer, is public. Certification and release-gate tooling that runs in your own pipeline. Remediation support, working with the people who wrote the code until the fix holds.
First we agree what must never happen in your system, which is a short list specific to your business rather than a checklist. On the OpenVPN 2.7 review that framing took 16 weeks and returned 18 issues, one of them a critical logic bug in a replay check. Then we read the design and the code against those rules, by hand, on the paths where it matters, and try to break it. Every break becomes a test that stays in your repository. We use fuzzing and model-assisted review where they help, but a candidate is not a finding until one of our auditors has confirmed it is reachable and shown what it lets an attacker do.
Tell us what you are building and what you need looked at. You will get an answer from the people who would run the engagement, and if another firm is the better fit for what you are asking, we will name one.
Security Research Labs is a member of the Allurity family. Learn more(opens in a new tab)