Automated scanners find the obvious. We find the exploitable defects they miss, authorisation gaps, injection paths and logic flaws that only surface under manual review, and hand your team a backlog they can actually work through, in order of real-world risk.
Secure code review is a manual, threat-model-led examination of source code for exploitable security defects, including broken authorisation, injection paths, unsafe data handling, trust-boundary mistakes and business-logic flaws that automated scanners often cannot judge in context. Codebase hardening is the follow-through: turning accepted findings into prioritised fixes, regression checks and safer patterns.
Secure code review is most useful just before a release that handles credentials, payments or personal information, or when you have inherited a system with no review history. The output is not a PDF full of untriaged scanner noise.
Languages, frameworks and build systems in scope are agreed in writing. We will not claim a stack we have not confirmed we can review to the depth you need.
What secure code review can answer
Attack paths
Where untrusted input can reach a sensitive operation and whether the path is genuinely exploitable.
Access control
Where identity, tenant, ownership or privilege decisions are missing, misplaced or inconsistent.
Business logic
Which workflow assumptions can be abused even when individual functions appear technically valid.
Remediation
What should change first, where the control belongs, and how engineers can verify the fix.
Manual review and automated SAST
Manual review is essential when
- Authorisation depends on identity, tenancy, ownership or workflow state
- An exploitable path crosses files, services or trust boundaries
- Business rules determine whether behaviour is legitimate or abusive
- Engineers need a contextual fix path rather than a generic rule identifier
Automated analysis remains useful for
- Broad coverage of recognisable insecure patterns
- Repeatable checks across commits and build pipelines
- Finding candidate locations for a reviewer to investigate
- Preventing a verified defect pattern from returning
The service combines manual review with static analysis tooling where it adds coverage. Scanner output is evidence to investigate, not a finished deliverable.
Current landscape
A useful code review follows the path from untrusted input to a sensitive decision, then gives an engineer enough evidence to close that path.
ASD’s 2024–25 threat year names third-party risk as one of four actions every Australian organisation should take. Latitude Financial’s 2023 incident, a stolen employee credential, then access to about 14 million records, including data retained from 2005, is a public illustration of what happens when least privilege, retention and code-level access control are not designed in. That is a secure-code problem as much as an identity problem.
Open-source supply-chain worms (Shai-Hulud on npm, Glassworm across VS Code and package registries) mean a “clean” repository can still ship a malicious dependency. (ISC)² calls this an expanding attack surface: different testing methods find different vulnerability types. Static application security testing without a human reviewer is not due care. Manual review is how you find authorisation gaps, injection and logic flaws scanners label as noise.
The Essential Eight still includes application control, user application hardening and patching applications, all of which fail if the application itself is written to bypass them. ASD is consulting on an Essentials series for enterprise IT, OT and cloud; until that guidance is published and the Eight is formally retired, the November 2023 Essential Eight remains the live, supported baseline. We will not pretend a code review is an Essential Eight assessment.
In (ISC)² terms this service is about integrity of the software asset, change management of the baseline, and authorization: defining which resources a user or service may touch. Official sources: Essential Eight; ISM terminology; (ISC)² CISSP student glossary.
When this fits
Sensitive release
You are preparing software that handles credentials, payments, personal information or privileged actions.
Inherited codebase
A critical system has no reliable review history and its trust assumptions are poorly understood.
Due diligence
A buyer, client, insurer, regulator or acquirer needs evidence of a scoped security review.
Scanner overload
Automated tooling produced a backlog with little context about exploitability or what to fix first.
Decisions and outcomes
Review is scoped to answer: where is this codebase actually exposed, how severe is each finding in this specific context, and what should be fixed first. Findings come with reproduction steps and a fix path, not just a severity label.
Scope
Typically included
- Threat modelling scoped to the reviewed component and its trust boundaries
- Manual code review supported by static analysis tooling, never tooling output alone, unreviewed
- Risk-ranked, reproducible findings with concrete remediation guidance
- A retest against fixed findings, on request
Not included unless agreed
- A full rewrite, ongoing development or general software consulting
- Infrastructure, cloud configuration or components outside the agreed codebase boundary
- A guarantee of zero remaining defects, review depth is bounded by the agreed scope and time
Deliverables
- A threat model summary for the reviewed component
- A findings report: severity, location, reproduction steps and remediation guidance
- A prioritised, engineering-ready backlog
- A verification/retest report once fixes are applied
Process
Authorise
Confirm ownership or authority over the codebase.
Scope
Agree languages, components and depth of review.
Review
Manual review supported by static analysis tooling.
Report and remediate
Deliver findings, then verify fixes on request.
Methods and standards
Review depth is matched to the languages, frameworks and build systems actually in scope. Threat modelling identifies assets and trust boundaries; manual source review follows data, identity and control decisions; static analysis supports coverage; and accepted findings include evidence, contextual impact and remediation guidance. Exact supported stacks are confirmed during scoping.
Security and evidence
No public evidence upload
This page never accepts malware, source code or evidence. Secure transfer is agreed only after authorisation and scoping, outside this website.
Limitations
What this engagement cannot promise
A secure code review demonstrates that the agreed components were examined to the agreed depth. It cannot prove the complete absence of defects inside or outside that scope, replace runtime penetration testing, or guarantee that later code changes will preserve the reviewed security properties.
Common questions
What parts of a codebase should be prioritised?
Start with authentication and authorisation, administrative functions, payments, file handling, secrets, external integrations and components processing personal or otherwise sensitive data. The final boundary depends on the decision you need the review to support.
Is this just an automated SAST scan?
No. Tooling is used for coverage. Every finding we report has been reviewed by a person in the context of your threat model. Scanner-only output is not a deliverable.
How is secure code review different from penetration testing?
Secure code review follows logic, data and authorisation decisions in available source code. Penetration testing exercises an authorised running target to determine whether an attack path is reachable. They answer different questions and can be complementary.
Will you fix the code for us?
Remediation stays with your engineering team unless a separate development engagement is agreed. We provide a backlog with a fix path, and we retest on request.
What should we prepare before a review?
A running local or staging build, access to the agreed repository, architecture notes, and a list of trust boundaries (authn/authz, payments, file handling, admin interfaces). The better the briefing, the less time is spent rediscovering how the system is supposed to work.
Case Studies
Current published case studies. Public-source illustrations are labelled clearly and are not presented as client engagements. View all case studies.
Six gift cards and a forged executive
A courier employee bought six $500 prepaid cards after mail that looked like it came from an executive. There was no malware. The missing control sat in the payment process.
More than $150,000 to a supplier who never changed banks
A construction firm paid an invoice twice after a supplier mailbox was taken over. No callback. No funds recovered.
The backup that encrypted itself
Ransomware at an auto parts store encrypted the live files and the backup disk still plugged into the same machine. Years of data went with the old system.
Related
Ready to talk about your situation?
Tell us the high-level scope. No malware, source code or evidence – just enough for us to route you safely.