Code Audit Services

A code audit is a structured review of an existing codebase that reports what is actually true about its architecture, security and performance. SWARECO provides code audit and software audit services for companies who need that read from someone who did not write the code.

The usual trigger is a gap between what the software is supposed to do and what it does. Delivery has slowed and nobody can say why. A security question has been asked that nobody in-house can answer. Or a rewrite is being proposed, and the cost of it needs testing before it gets approved.

We start by asking what decision the audit is meant to inform, because an audit for a security sign-off and an audit for a rewrite decision look different. Scope follows from the question, not from a template.

Then read-only access to the repository and, where it helps, a running environment. Static analysis and dependency scanning cover the mechanical layer; engineers read the code that matters most for your question. We also review commit and incident history, because the places a system has already broken are the places to look first.

You get a written report: findings ranked by severity and by remediation cost, a short list of what to fix first, and a plain answer to the question you commissioned it for. A smaller codebase takes about a week.

SWARECO audits source code across Ruby on Rails, React, React Native, TypeScript, PostgreSQL, Sidekiq, Redis, Elasticsearch or OpenSearch, Docker, AWS and Heroku — the same stack we build and run for clients, which is why the remediation estimates in the report are ones we would have to stand behind ourselves.

What the tooling covers, and where it stops

Static analysis and dependency scanning run first because they are cheap and exhaustive: linters and security scanners against the whole source code tree, dependency audits for known vulnerabilities and unmaintained packages, and coverage measurement to find which paths the test suite never touches. That layer reliably finds a known vulnerability in a published package. It cannot tell you that an authorisation check is missing from an endpoint that should have one, or that two modules disagree about who owns a piece of state.

So the mechanical pass produces a shortlist and a senior engineer reads the code that matters. A tool-generated report forwarded without that step is not a code audit, and it is the main thing we are asked to replace.

How we judge code quality

Code quality is only meaningful against the cost of change, so we measure it that way rather than by style compliance. The questions are how much of the system a typical feature has to touch, how long the test suite takes and how much of the revenue-generating path it covers, how much duplicated logic exists in the places that change most often, and how far the codebase has drifted from the conventions of its own framework. Rails and React both have strong community best practices, and a codebase that ignores them is expensive to hire for even when it works — a new engineer cannot use what they already know.

Security and regulatory compliance

We check authentication and authorisation, how personal data is stored and logged, secrets management, and third-party dependency exposure. Where you have a specific regulatory compliance obligation, tell us which one before we scope: the audit can be pointed at the evidence a particular framework asks for, and that changes what we read and what the report has to prove.

What the report actually contains

Every finding carries a severity, a location in the source code, the consequence if it is left alone, and an estimate of the effort to fix it. Findings are then ordered so the first section is the short list worth acting on this quarter, because a flat catalogue of two hundred issues at equal weight is a document that gets read once and filed.

The report also states plainly what we did not find. An audit that only lists problems tells you nothing about the parts of the system that are sound, and those are usually the parts a rewrite proposal is quietly planning to throw away. Where a security question was the trigger, the report answers that question in its first paragraph rather than at the end of a tour of the codebase.

What it takes to uncover, and what happens next

A smaller codebase takes about a week. Larger systems, or audits scoped around a specific regulatory compliance question, take longer because the reading is deeper rather than because the tooling is slower. We agree the scope against the decision you need to make, so the risk of paying for a broad survey when a narrow question was the real requirement is removed up front.

Remediation is a separate conversation and a separate engagement. Where the right answer is that your existing team fixes the findings against the plan in the report, that is what the report recommends, and SWARECO writes it the same way whether or not we expect to do the work.