Skip to content
CODETRUSS
Audit a repo
Code audit softwareCodeTruss

Audit the codebase before you quote, launch, buy, or repair it

A useful code audit is not a scanner dump. It explains how the repository works, where technical debt and security risk are concentrated, what evidence supports each finding, and which fixes should become issues first. CodeTruss turns that first-pass audit into a report, architecture map, health signals, and a GitHub issue roadmap.

Start freeRead a sample audit

What is a code audit?

A code audit is a time-boxed review of a repository that looks beyond whether the app runs. It checks architecture, maintainability, dependency risk, security boundaries, test evidence, documentation, and delivery process so the next decision is based on codebase evidence instead of guesses.

When to run a code audit

Before a codebase takeover

A freelancer, agency, or new team needs evidence before quoting cleanup work or accepting maintenance risk.

Before a launch or fundraise

A founder needs to know whether architecture, auth, billing, dependencies, and operational paths are ready for more users.

Before buying or inheriting software

A buyer, CTO, or investor needs a readable view of what is in the repo, where risk lives, and what it may cost to repair.

After heavy AI-assisted coding

The team shipped faster than review capacity, so generated code needs a whole-repo pass for drift, duplication, missing tests, and security-sensitive mistakes.

What a serious audit should inspect

The goal is not to create the longest checklist. The goal is to connect findings to decisions: can we launch, quote this takeover, accept this vendor handoff, or trust the AI-generated work enough to keep building?

Audit signal

Architecture and dependency flow

Map routes, services, data access, jobs, package boundaries, import cycles, and hidden coupling before recommending refactors.

Audit signal

Security-sensitive paths

Review auth, tenant isolation, secrets, webhooks, billing state changes, file handling, input validation, and exposed admin paths. Two of these are deterministic passes rather than review prose: missing authorization and cross-tenant object references, both described below with what they do not cover.

Audit signal

Technical debt hotspots

Rank oversized files, duplication, dead code, TODO clusters, missing ownership, brittle modules, and changes that repeatedly break nearby code.

Audit signal

Dependencies and release risk

Check vulnerable packages, abandoned libraries, lockfile drift, CI coverage, release provenance, and package-manager security settings.

Audit signal

Tests and operational evidence

Look for meaningful test coverage, untested critical paths, migration safety, observability, rollback paths, and production readiness gaps.

Audit signal

Documentation and handoff quality

Verify setup docs, environment requirements, runbooks, data model notes, ownership boundaries, and what a new developer needs on day one.

Hosted pass · security scan only

Broken access control, checked deterministically

Most tools treat authorization as a thing a human reviews. Two classes of it are decided here by a route authorization graph rather than by prose or by a model. Both run in the hosted audit only — they are not part of the CLI, and they are off for every scan type except a security scan. No language model participates in either; there is no path by which a suggestion becomes a finding.

CWE-862 · A01:2021

Missing authorization

A mutating route whose transitive callee set changes persisted state, with no middleware, proxy, or guard that can refuse the request dominating the write. The claim is a universal negative, so it is only made when the callee walk resolved completely — zero unresolved edges, no depth cap, no cut cycle. Most entries in a real repository fail that gate, and each one that fails produces silence rather than a guess.

CWE-639 · A01:2021

Cross-tenant object references

A request-controlled identifier selects a row of a model your schema says belongs to a tenant, and nothing in the handler confines that selection to the caller’s tenant. Six scoping clauses each silence an operation — among them a tenancy field bound to a non-request value, a key that came from the principal, an unguessable capability column, and an authorizing use of the key that dominates the query.

What it does not cover

  • Prisma and Drizzle only. Knex, TypeORM, Mongoose, Convex, and raw SQL are invisible to the cross-tenant pass.
  • No schema means no finding, ever. Tenancy is read structurally from your schema, not guessed. A repository without a machine-readable one records the pass as SKIPPED rather than as a clean result, so the report cannot claim a class nothing checked.
  • Cross-tenant analysis is intra-entry. A query written in a helper the handler calls is not judged, so a codebase that keeps every query in a model layer yields almost no sites.
  • Lookups by natural key are not reported. The pass looks at primary and foreign keys. A genuine cross-tenant read keyed by an email or a slug is a known recall cost, stated rather than hidden.
  • Identity endpoints are excluded by convention. Login, registration, and recovery routes exist precisely because the caller has no session yet. The cost is that a genuinely broken handler filed under auth/ is not reported.

Measured with every candidate hand-adjudicated. On this repository, the cross-tenant pass reports 0 findings across 117 database operations examined with the callee-resolution gate lifted — 23 with it in place — and the missing-authorization pass reports 0 across 12 mutating entries that clear its soundness gate, each read by hand. On a public multi-tenant SaaS boilerplate it produced 5 findings, all on one route, all the same real defect: an authenticated but unscoped user route. Zero false positives across that repository’s other 51 database operations. That repository is deliberately not named here, because the defect was reported to its maintainer and is not yet public.

Useful audit deliverables

The report should help someone decide what to do next. If the audit stops at a score or a wall of findings, the team still has to do the hard part manually.

  • Executive summary written for the buyer, founder, or client owner
  • Architecture map that explains how the repository is shaped today
  • Health, debt, security, docs, and test signals with evidence
  • Severity-ranked findings with affected files and why they matter
  • Remediation roadmap with effort, acceptance criteria, and sequencing
  • GitHub issues or a client-ready report that moves the audit into execution

How CodeTruss runs the first-pass audit

01

Connect the selected repositories

Install the GitHub App only on the repos you want audited. CodeTruss starts from the repository snapshot, not a vague questionnaire.

02

Analyze the whole codebase

The audit walks structure, dependencies, docs, tests, complexity, secrets, known vulnerability signals, and project health patterns.

03

Review the evidence

Use the report to separate urgent risk from normal cleanup, then decide which findings deserve issues, roadmap slots, or fix PRs.

04

Turn accepted work into issues

Accepted findings become scoped GitHub issues with labels, acceptance criteria, and verification steps instead of an unread PDF.

Manual audit, SAST, or CodeTruss?

First-pass options — best fit and tradeoff
OptionBest forTradeoff
Manual code auditHigh-stakes diligence, deep security review, bespoke architecture decisions, and final expert judgment.Usually days to weeks, expensive, and hard to repeat frequently without a strong template.
Static analysis or SASTSpecific vulnerability classes, code smells, known dependency risk, and policy checks inside CI.Useful evidence, but it rarely explains business context, architecture drift, or remediation sequence by itself.
CodeTruss auditFast whole-repo understanding, client discovery, recurring health checks, AI-code validation, and issue-roadmap creation.Best used as the first-pass audit layer. Human review still owns high-risk decisions and final signoff.

Common code audit questions

What is a code audit?

A code audit is a structured review of a software repository to understand code quality, architecture, security risk, dependencies, tests, documentation, and what should be fixed first.

Is a code audit the same as code review?

No. Code review usually looks at a pull request or change set. A code audit looks at the whole repository and answers broader questions about ownership, maintainability, risk, and roadmap sequencing.

Can an automated code audit replace a senior engineer?

No. Automation is strongest as the repeatable first pass: it gathers evidence, finds patterns, and prepares the report. A senior engineer should still review high-risk findings and business-critical decisions.

What should a useful code audit deliver?

A useful audit delivers a readable summary, architecture context, severity-ranked findings, evidence links, remediation priorities, and an execution path such as GitHub issues or a cleanup roadmap.

Continue the audit workflow

Worked example: auditing an AI-built SaaS

An independent teardown of a pinned public repository, including the automated findings that manual review rejected.

Inherited codebase takeover playbook

A practical workflow for auditing an unfamiliar repository before quoting or accepting the work.

Codebase audit report template

The report structure freelancers, agencies, and startup teams can use after inspecting a repo.

GitHub issue roadmap template

Turn audit findings into issues, milestones, owners, and verification steps.

AI-generated code technical debt

How to review generated code for drift, duplication, missing tests, and security-sensitive mistakes.

Run a code audit on a real repository

Start with one repo. Use the report to decide what is urgent, what can wait, and what should become a GitHub issue or fix PR.

Start freeSee pricing