Code audit services that end in merged fixes
A code audit is an independent read of software you already own: security, architecture, infrastructure. The output is a prioritised issue register with evidence and an effort estimate against every finding. InApps delivers it in two weeks. Then the same engineers fix what they found.
Trusted by engineering teams across 15+ countries - from startups to Fortune 500.
Six things we hear on the first call
All six come from the same place. The code shipped faster than anyone could write down what it does.
Nobody can say what is actually in the codebase, or where it is exposed.
Vulnerabilities get found by users or by an auditor. Not by your team, and never cheaply.
Coverage is thin, so every deploy is a bet. A change in one place breaks something unrelated.
Technical debt nobody has quantified. You cannot estimate features or defend a roadmap without a number.
The engineers who wrote it have gone. The commit history is the documentation now.
An investor or an acquirer has asked for a technical review, and it is due in three weeks.
What a code audit is, and what it is not
Inherited a codebase nobody can vouch for?
An outside read, with evidence against every finding
A code audit is a point-in-time review of an existing codebase by engineers who did not write it. It covers security, architecture and code quality, and the infrastructure the code runs on. It ends in a register, not a conversation.
That is the line between an audit and a code review. A code review is continuous and lives inside your pull request flow. An audit is a single systematic pass over the whole system, run by an independent team, and it produces a document you can hand to a board, an investor or an insurer.
What we read
Everything that decides how the system behaves.
- Source on every active branch, plus the commit history
- Dependency manifests and lockfiles
- CI/CD pipeline definitions and build config
- Infrastructure as code and environment variables
- Database schema, migrations and slow query logs
- Existing tests and coverage reports
What we never touch
Named in the NDA, before access is granted.
- Production data. We work from schema, never from rows
- Customer PII, in any environment
- Your production systems. The audit is read-only
- Anything outside the scope you signed
- Credentials. You provision access and you revoke it
Four workstreams, one engagement
They run in parallel, not in sequence. That is what makes two weeks possible.
Security code audit
Dependency scan against live CVE data. Authentication and authorisation flow review. Secrets sitting in the repository: hardcoded credentials, exposed API keys. Input validation and injection risk. OWASP Top 10 coverage for anything web-facing.
Architecture and code quality
Structure and separation of concerns. Coupling, cohesion, and whether the pattern survives ten times the load. Antipatterns and technical debt, named and located rather than described. Dead code, duplication and complexity scored per module.
Infrastructure and deployment
CI/CD pipeline gaps. Environment configuration and secret handling. Database schema and query performance. Logging, monitoring and alerting coverage. This is the layer fast-shipped codebases skip entirely, and it is where the findings nobody expected tend to be.
Remediation execution
Fixes sequenced by risk tier and mapped onto your sprint cycles. Each fix reviewed before merge, by an engineer who is not the author. Handover documentation and an updated README when the tier closes.
Audit it yourself, hire a security firm, or call us
| Criterion | InApps | Internal review | Security firm |
|---|---|---|---|
| Codebase coverage | Security, architecture and infrastructure | Whatever there is time for | Security layer only |
| Architecture review | Included | Sometimes | Rarely in scope |
| Independent perspective | Yes | No. Same team that wrote it | Yes |
| Who executes the fixes | The same engineers who found them | Your team, if it has capacity | Not offered. Report only |
| Time to register | 12 to 14 days | Slips behind feature work | Four to six weeks |
| What you receive | Register, evidence, effort estimates, live walkthrough | A ticket list, usually | PDF and a debrief call |
| Cost shape | Fixed fee for the audit | Your senior engineers, off the roadmap | Day rate, security scope only |
From repository access to a register you can act on
Scope and access
One call. What is in scope, what is off limits, and what you already suspect.
Systematic audit
Three workstreams in parallel. Tooling finds the patterns, engineers find the rest.
Register and walkthrough
You get the document, then you get the engineers who wrote it for ninety minutes.
Remediation
Optional, and quoted after you have read the register. Most clients start at Critical.
What lands on day 14
Four things, all of them yours to keep and to forward. No portal, no licence, no expiry.
Issue register
Every finding with a severity, a file path, the evidence, a recommended fix and an effort estimate in hours. Sortable, so you can cut it by risk or by cost.
Executive summary
Two pages, written for a board or an investor rather than for engineers. This is the one that goes in the data room.
Remediation roadmap
The register sequenced into sprints. Risk first, effort second, and dependencies flagged so nothing is scheduled before the thing it depends on.
Live walkthrough
Ninety minutes with the engineers who did the work. Your team asks, they answer. Recorded if you want it for people who could not attend.
Technical due diligence, from either side of the deal
Technical due diligence is a code audit with a deadline and a different reader. The buyer wants the risk quantified before the wire clears. The seller wants no surprises in the data room.
Buy side
You are acquiring or investing. We read the target's codebase, put a number on what it costs to run and to fix, and flag anything that should move the valuation.
Sell side
You are raising or exiting. We find what the buyer's team would find, and you fix it first. Vendor due diligence, run before anyone else asks the question.
Post deal
The deal closed and now the integration plan needs a real estimate. The register is where that starts, and our engineers can execute against it.
Four named engineers, not one generalist
Security, architecture and infrastructure are three disciplines. We staff them as three people, and you get their names before the audit starts.
Security engineer
- Auth and authorisation flows
- Dependencies and CVE exposure
- Secrets, input validation, OWASP Top 10
Senior software engineer
- Architecture and separation of concerns
- Code quality and antipatterns
- Maintainability and complexity scoring
Platform engineer
- CI/CD and deployment
- Database, schema and query performance
- Environments and observability
Technical lead
- The register and the executive summary
- Remediation roadmap and sequencing
- The walkthrough call, and your escalation path
What moves the price of a code audit
We do not publish a rate card, because a 40,000-line Rails app and a 12-service Java estate are not the same job. Five things set the number. You will have it after one scoping call.
| Driver | What we ask | Why it moves the number |
|---|---|---|
| Codebase size | Lines of code, repositories, active branches | Reading time scales with surface area, not with feature count |
| Stack breadth | How many languages, frameworks and runtimes | Each one needs an engineer who has actually shipped in it |
| Depth of the security pass | Scanning only, or manual review and a dynamic pass | A dependency scan is hours. A manual auth review is days |
| Infrastructure in scope | Application only, or CI/CD, IaC and databases too | The infra layer is usually where the unexpected findings are |
| Remediation | Register only, or we execute the fixes | Two engagements, quoted separately, and the second is optional |
The audit is a fixed fee, agreed before access. Remediation is quoted after you have read the register, so you never buy fixes for problems you turn out not to have.
The tools we run, and why none of them files a finding
Static analysis finds patterns. It does not find a broken authorisation check, and it reports plenty that turns out to be nothing. Every automated result is read by an engineer before it reaches your register.
Static analysis and quality
SonarQube and ESLint on every engagement, plus Semgrep rules written against your stack rather than the defaults. PHPStan, Bandit or ruff where the language calls for it.
Dependencies and security
Snyk and Trivy against live CVE data. Dependabot history for what has been alerted and ignored. Burp Suite for anything web-facing, and GitGuardian for secrets already pushed.
Pipeline and runtime
Your CI is part of the audit, whether that is GitHub Actions, GitLab CI or Jenkins. Sentry, or whatever you use in its place, tells us what is already failing in production.
Ask the people who stayed
Every quote below is from a verified review. None of them were written by us.
“Clear expectations, rules that actually hold, delivered on time. And the people are genuinely easy to work with, not just professionally, but as humans.”
Worth the call, or worth a no
An audit is the wrong shape for plenty of good problems. Here is where it works and where we will point you somewhere else.
This works well if
- You inherited a codebase, or the people who wrote it have left.
- An investor, an acquirer or an enterprise customer has asked for a technical review.
- You are a startup about to put a bigger team on code nobody has read end to end.
- You want an independent code audit company, not the team that wrote it marking its own work.
- You want the fixes executed, not just listed.
This is not a fit if
- You want continuous review inside your pull request flow. That is staff augmentation or a dedicated team, not an audit, and we will say so.
- You need a penetration test against a running system. We read source, not live traffic. Different engagement, and usually a different vendor.
- You need SOC 2 or ISO 27001 certified. We can prepare the engineering evidence, but the certificate comes from an accredited auditor.
- The codebase is three months old and one person wrote it. Ask them. It will be quicker and it will be free.
Answered without the hedging
Not sure it is an audit you need?
Send the repository size and the stack. We will tell you whether an audit is the right shape for the problem, including when it is not.
Book a code audit callWhat is a code audit?
What do code audit services cost?
How long does a code audit take?
What is technical due diligence, and is it the same thing?
Do you need access to our production environment?
What is actually in the code audit report?
Can you fix what you find, or do we?
How is this different from a penetration test?
Send us the stack, not a brief
Repository size, languages, and what you already suspect is wrong. We come back with a scope and a fixed fee. If an audit is the wrong answer we will tell you that instead.