§ CAPABILITY

Application Security Audit

An assessment of where the system is exposed, ranked by what an attacker would actually reach. Findings written so they can be fixed rather than filed.

Who
Founder holds the engineering leadership seat; the delivery team executes underneath it.
Request a call How the work runs

What you're seeing

A customer asked for a recent security assessment and there is not one.
Usually means Enterprise procurement increasingly requires evidence of periodic testing. This is now a revenue dependency with a date on it rather than a security hygiene question.
An environment exists that nobody remembers standing up.
Usually means A forgotten staging or demo environment, usually with production-like data and weaker controls. It is a recurring finding and frequently the shortest path in.
Authorisation is checked in the controller and nowhere else.
Usually means Object-level authorisation is being enforced at one layer that not every path goes through. Broken object-level access is the most common serious finding in a B2B product, and it is invisible to scanners.
Secrets are in environment files that get shared when someone joins.
Usually means There is no secret management and no rotation, so the blast radius of any departure or any leaked repository is unbounded and unknown.

Ranked by what is reachable

A severity score describes a vulnerability in the abstract. It does not describe your system.

A critical-rated issue sitting behind authentication, a VPN and an internal network is genuinely less urgent than a medium-rated one on an unauthenticated endpoint that anyone can reach from a browser. Ranking by score produces a list that gets worked in the wrong order, which is worse than it sounds — teams work down the list, run out of appetite around item eight, and the reachable ones were at eleven.

So findings are ordered by what an attacker could actually do from where they can actually stand, and each one carries reproduction steps and a proposed fix. A finding a developer cannot reproduce is a finding that gets disputed rather than fixed.

Where the serious findings are

Two categories account for most of what is worth finding, and neither is what people expect.

Object-level authorisation. The check exists and is applied on four of five code paths, or it compares the wrong identifier, or it verifies that the user is authenticated without verifying that this particular record is theirs. This is the most common serious finding in a B2B product and no scanner detects it, because the code looks correct.

Forgotten surface. The staging environment stood up for a demo two years ago, with production-like data and weaker controls. The internal admin tool reachable from the public internet. The storage bucket that was public for one migration. Mapping the attack surface reliably finds something nobody remembered.

Fix, then retest

A findings register with no retest describes one day.

Fixes are made by the team that owns the code — that is correct, they understand it and they have to live with it — and then they get verified. Partial fixes are common: the reported instance is closed and the pattern survives elsewhere, or the check is added and applied on the path that was demonstrated. In a ticket tracker that is indistinguishable from a complete fix.

Where it sits

This capability sits under SOC 2 Readiness, where periodic assessment is a control an auditor will ask for evidence of, and under Technical Due Diligence, where security posture is one of the four things a deal team is buying an opinion on.

It runs alongside two neighbours. Code Security Review reads the code where this reads the system and its configuration — together they cover both what is written and what is deployed. And Vendor Risk Management applies the same questions outward, to the suppliers who can reach your data.

How the work runs

  1. Map the attack surface

    Everything reachable from outside — endpoints, storage, third-party integrations, forgotten environments. The forgotten ones are a recurring finding.

  2. Test authentication and authorisation

    Session handling, token lifetimes, privilege escalation and object-level access. Broken object-level authorisation is the most common serious finding in a B2B product.

  3. Review cloud configuration

    Identity policies, network boundaries, storage permissions, secret handling and logging coverage.

  4. Rank by reachability

    Findings ordered by what an attacker could actually do with them, with a fix and a verification step for each.

What arrives

  • A findings register ranked by reachable impact
  • Reproduction steps and a proposed fix per finding
  • A cloud configuration review with specific policy changes
  • A retest of the fixes, in scope

What it costs your team

Access provisioning, one architecture session, and an engineer available for questions during testing.

Next step

Tell us where this is breaking and we'll say what it takes to fix.

Request a call

How we decide

  • Findings are ranked by reachability, not by CVSS

    Costs Some high-scoring findings end up low on the list, which is uncomfortable to present to a board.

    A severity score describes a vulnerability in the abstract. What matters is what an attacker could actually do from where they can actually stand — a critical-rated issue behind two authentication layers and a VPN is less urgent than a medium-rated one on an unauthenticated endpoint. Ranking by abstract severity produces a list that is worked in the wrong order.

  • Source access is requested, and its absence is reported

    Costs It makes this different from a black-box test, and some clients expect the black-box version.

    Without source, whole categories of authorisation defect are unreachable — an outside tester cannot see that one of five code paths omits the tenancy filter. Where access is refused, saying which categories were out of scope is more useful than a report that reads as complete and is not.

  • Every finding carries a fix and a retest

    Costs It extends the engagement past the report, which is where most assessments stop.

    A findings list with no retest tells you what was true on one day. The fixes are made by whoever owns the code, which is correct, and then they need verifying — partial fixes are common and they are indistinguishable from complete ones in a ticket marked done.

Frequently Asked Questions

A structured assessment of where an application and its infrastructure are exposed, usually against a framework such as OWASP ASVS, covering authentication, authorisation, data handling, dependencies and cloud configuration. The output is a ranked set of findings with reproduction steps and fixes, not a score.
It overlaps and is not the same. A pentest simulates an attacker against a running system, is usually time-boxed, and is often bought for the certificate. This is an assessment with source access, which finds different things — particularly authorisation logic that an external tester has no way to see.
We prefer it, strongly. Without it you get an outside-in view that misses entire categories of authorisation defect. Where access cannot be granted we run what is possible and state in the report which categories were out of reach, rather than producing something that reads as complete.
It supports a SOC 2 or ISO 27001 programme by producing evidence of periodic assessment and remediation, which is what the control asks for. It is not the audit itself — that has to be an independent firm, and a provider offering both should be treated with caution.
Ranked, fixed by whoever owns the code, then retested. The retest is the part that is usually skipped and the part that matters: partial fixes are common, and in a ticket tracker a partial fix and a complete one look identical.

Sources

Page reviewed