How an audit is done.

The steps

1. Specialist review passes

   Your code is reviewed in separate passes. Each ecosystem in scope gets its own specialist pass, and a general pass looks across the whole codebase. The passes are run by Anthropic’s Claude models, through Anthropic’s commercial API.

2. Independent reconciliation

   A separate reconciliation step reads the results of the passes, and merges them into a single set of findings.

3. Evidence for each reported finding

   Where a regression test can be written and run, it is. Where it cannot, the finding carries a code trace, a path through your code with file and line references.

4. Severity and report

   Findings are scored with CVSS 3.1 and assembled into the report with a suggested fix for each.

The three-run regression-test check

A regression test asserts the safe behavior that a fix restores. It is written in your project’s own test framework, so your developers can keep it. We do not take the model’s word that a test works; the test is run, three times, each in a fresh container with no network:

• Against your code: the test must fail on an assertion, not crash.
• With the suggested fix applied: the test must build and pass.
• Against your code again: the test must fail again, which rules out a test that passes or fails at random.

Only a test that satisfies all three is recorded as a passing regression test. A test may only add files; it may not modify your project files. The fix may not touch tests or build configuration.

Code traces, confirmed by a second reviewer

Some findings cannot be given a runnable test. For those the evidence is a code trace, and a second, independent reviewer checks the trace against the code before it is kept. No exploit is executed. A report states which kind of evidence each finding has.

Severity

Severity comes from CVSS 3.1. Each finding in the report carries its CVSS 3.1 score. Attack paths are described in prose for your developers; reviewers are instructed not to write ready-to-run exploit payloads.

Your code is treated as untrusted input

Instruction files and comments addressed to AI tools inside your repository (for example a CLAUDE.md or AGENTS.md) are not obeyed. Everything in the code under review is treated as data, and the review prompts say so. Review also never touches a live system; see Data handling.

Limitations

• Static source review at one commit. We review the code as it is at the commit you name. Later changes are not covered.
• No testing against live systems. Nothing is run against your deployed services, hosts or infrastructure, and the review has no internet access.
• AI-assisted, with automated verification gates. The review is performed by AI models; the checks described above decide what is reported. Do not read it as a manual penetration test.
• No audit can promise to find every security flaw. A clean section of a report means nothing was found there, not that nothing exists. Treat the report as one input to your security work.

Codebases outside the size and ecosystem range we can audit reliably are declined before any review starts, rather than reviewed poorly.

Ready to start?

Tell us the size and ecosystem of your code and we will reply with a confirmed quote.