Before an acquisition
Buyers need to know about hidden rewrites, licence exposure and code only one person understands.
Code Audit
Code audit services for inherited codebases
Before you buy, fund or take over software, you need to know what is inside it. Agnotic Technologies audits codebases independently, with read-only access, and gives you ranked findings that support a decision rather than a long list of warnings.
Read-only accessSecurity and licencesBuild reproducibilityRanked findings
Trusted by global innovators
Code audit
What is a code audit?
A code audit is an independent review of a codebase before you inherit, buy, fund or rescue it. Agnotic Technologies reviews architecture, security, dependencies and open source licences, tests, build and deploy, data handling and documentation with read-only access, then ranks the findings so the report supports a decision.
A paid code review by an outside team is the same service. AI model audits are a separate offer, and we do not give legal opinions on licences; we flag licence risks for your counsel.
The report does not score your code against other companies. Each finding stands on its own, with evidence, impact and a fix.
When should you commission a code audit?
Before an investment
Investors want to know whether the product can scale on its current code or needs rework first.
When changing vendors
A new team needs a clear picture of what it is taking over before it commits to estimates.
To rescue a troubled project
Missed releases and rising bugs often trace back to a few root causes an audit can find.
Before scaling or a compliance audit
A check that the codebase can carry more users, or the controls an auditor will review.
Audit checklist
What does the audit check?
Seven areas, each with a method and a finding format, so reports from different audits can be read the same way.
| Area | What is checked | Tool or method | Finding format |
|---|---|---|---|
| Architecture | Module boundaries, coupling, data flow and fit with the product roadmap | Reading code and diagrams, interviews with the current team | A diagram of the current state with risk notes |
| Security | Injection, access control, secrets in code and authentication flows | Static analysis, secrets scanning and manual review of sensitive paths | One finding per issue, with file, line and fix |
| Dependencies and open source licences | Outdated and vulnerable packages, and the licence of each component | Software composition analysis and SPDX licence identifiers in an SBOM | A dependency list with versions, known vulnerabilities and licence flags |
| Tests | Coverage of critical paths, flaky tests and what is not tested | Running the suite, coverage reports, reading test code | Gaps listed against business-critical features |
| Build and deploy | Whether a clean machine can build and deploy the code | Rebuilding from the repository using only the written steps | A reproducibility result and the missing steps |
| Data handling | Where personal or sensitive data is stored, logged and sent | Data flow tracing, log and configuration review | A data map with exposure points |
| Documentation | Setup guides, runbooks and architecture notes | Following the docs as a new engineer would | What a new team needs that is missing |
Method
How does an audit run with read-only access?
Agree scope and access
An NDA, read-only repository access, no production data, and the questions the audit must answer.
Automated scans
Static analysis, dependency, secrets and licence scans across the whole codebase.
Manual review
Engineers read the paths that matter most: authentication, payments, data access and integrations.
Rebuild test
Build and deploy from scratch in an isolated environment, using only what is written down.
Interviews
Short sessions with the current team to confirm the intent behind unusual code.
Report and walkthrough
Ranked findings presented to decision makers and to engineers, with time for questions.
Automated or manual review
What do automated code review tools catch, and what needs a human reviewer?
Automated code review tools catch rule-based problems: formatting and lint rules, known insecure patterns, vulnerable dependencies and secrets in code. A human reviewer is needed for architecture and coupling, business logic errors, authorization gaps and unclear intent. Agnotic Technologies runs the tools across the whole codebase first, then spends reviewer time on what tools cannot judge.
| Finding type | Who finds it | Why |
|---|---|---|
| Formatting and lint rules | Automated tool | The rules are exact and apply the same way to every file |
| Known insecure patterns | Both | Static analysis flags the pattern; a person decides whether user input can really reach it |
| Vulnerable dependencies | Automated tool | Matching package versions against published advisories is a lookup |
| Secrets in code | Automated tool, with a person checking each hit | Scanners find keys in code and history; a person confirms which are live and must be rotated |
| Architecture and coupling | Human reviewer | Tools can count links between modules but cannot say whether a boundary fits the product |
| Business logic errors | Human reviewer | Code can be valid and still apply the wrong business rule |
| Authorization gaps | Human reviewer | A missing check is an absence, so the reviewer has to know which roles should reach each path |
| Unclear intent | Human reviewer | Names and structure that will confuse the next team are a reader's judgement |
AI review assistants add comments to pull requests. We treat those comments as suggestions: an engineer accepts or rejects each one, and no AI tool approves a change on its own.
Ranking
How are findings ranked?
Ranks describe what to do and when, not a grade for the team that wrote the code.
01
Fix before the decision
Example: Hard-coded production credentials, or a copyleft component that conflicts with how the product is distributed
Approach: Flagged to you as soon as it is confirmed, with the evidence, not held for the final report.
02
Fix before scaling
Example: No tests on billing logic, or a data model that cannot grow with tenants
Approach: Planned as the first work after the deal or handover.
03
Plan into the roadmap
Example: A framework that is old but still inside its support window
Approach: Scheduled with an upgrade path and the reason it can wait.
04
Note
Example: Inconsistent naming or missing comments
Approach: Listed so the next team knows; no action required.
Deliverables
What is in the code audit report?
- An executive summary answering the questions agreed at the start
- Ranked findings with evidence, impact and a recommended fix
- A dependency and licence inventory in a machine-readable format
- An architecture diagram of the system as it is today
- A fix or rewrite view per module, with the reasoning
- Rebuild notes so a new team can build and deploy the code
References
References behind the audit
NIST SP 800-218 PW.7OWASP Code Review GuideOWASP ASVSSPDX (ISO/IEC 5962:2021)OpenSSF ScorecardCWE
Facts and sources
Facts behind a code audit
The standards our method and report formats follow.
NIST SP 800-218 task PW.7.1 asks teams to decide between code review, where a person reads the code, and code analysis, where tools find issues, and PW.7.2 asks that every issue found is recorded and triaged in the team's issue tracker.
Source: NIST SP 800-218, SSDF Version 1.1The SPDX specification for software bills of materials, including licence information, is recognized as the international open standard ISO/IEC 5962:2021.
Source: SPDX: overviewThe SPDX License List is part of the SPDX Specification and lists commonly found licences and exceptions used in free, open and collaborative software, each with a standard identifier.
Source: SPDX License ListOpenSSF Scorecard runs automated checks on open source projects, such as unfixed vulnerabilities through the OSV service, whether the project is maintained and whether it declares a licence.
Source: OpenSSF Scorecard
Scope and cost
What drives the cost of a code audit?
We do not publish prices. These factors decide the size of the audit.
Codebase size and languages
More languages mean more tools and reviewers with the right experience.
Services and repositories
A single application, or many services with shared libraries.
Depth of security review
Automated scans only, or manual review of every sensitive path.
Licence review
How the product is distributed changes which licences matter.
Rebuild test
Whether build and deploy are checked from scratch.
Decision deadline
A fixed deal or board date that the report must meet.
Frequently Asked Questions
It depends on the size of the codebase, the number of languages and services and how deep the security review goes. We agree a report date tied to your decision deadline before the audit starts.
No. Read-only access to the repositories, CI logs and documentation is enough. If configuration matters, we review a redacted copy rather than live systems.
No. A code audit reads the source and its dependencies; a penetration test attacks a running system. They find different problems, and an acquisition often needs both.
That is your decision. Short interviews with the current team make findings more accurate, and in acquisitions we coordinate access through the seller.
No. A single score hides what matters. You get ranked findings, each with evidence and a fix, and a fix or rewrite view per module.
Yes, as a separate engagement, or your own team can use the report as its backlog. If you are changing vendors, our maintenance and support service covers the takeover.
AI tools may help scan a large codebase and summarize modules, but every finding in the report is confirmed by an engineer, with the file and line as evidence.