Secure code review for Australian software teams.
Line-level review of source, configuration and dependencies, with a fix documented for each finding and a re-review once the fixes land.
- Repositories in scope, nothing further
- Read access
- Of the fixes, once they land
- Re-review
- CyberCert public registry
- SMB1001:2026 Gold
Black Shard conducts secure code review, also called security code review or a source code security audit. Tooling informs where to look, a finding is reported once a reviewer has read and confirmed it, and issues with no practical exploit path are left out.
What the review reads, and remote delivery
The review covers the authentication flow, the authorisation checks on routes that touch data, the query layer, secrets handling, the dependency tree and the deployment configuration. Findings are documented with severity, impact, reproduction steps and a fix, and a re-review of the fixes is included.
Black Shard is an Australian software engineering and cybersecurity firm working nationally and internationally. Code review is delivered remotely against the repositories in scope, with read access and nothing further.
What the review covers
The review reads the source in scope, with attention on the classes of flaw that produce incidents: injection, broken authentication and session handling, authorisation gaps and tenancy boundaries in multi-tenant systems, secrets in code or configuration, and vulnerable or abandoned dependencies.
- A defined scope and timeframe in writing before the review starts
- A findings report with severity, impact and reproduction steps for each issue
- A fix documented for each finding, with the steps to apply it
- A re-review of the fixes once they land
How findings are confirmed
Tooling informs where to look. A finding is reported once a reviewer has read and confirmed it, and issues with no practical exploit path are left out. Each finding is written with severity, impact and reproduction steps, and carries its fix with the steps to apply it.
When to commission a review
Before launch, while findings are engineering work and no change windows, migration risk or disclosure decisions attach to them.
After an incident, to establish where else the same class of flaw exists and what the attacker had the opportunity to reach.
During due diligence, when acquiring, investing in or selling a software business. The review reports what ships with the codebase: secrets in the commit history, abandoned dependencies, and an authorisation model held together by convention.
What a secure code review covers, by layer
A review reads the codebase in layers, because a flaw in one layer rarely turns up by scanning the whole system at once. Each layer is read against how it is actually used in the system in scope.
- Authentication and session handling: credential storage, token expiry, reset flows, and stale privilege on old sessions
- Authorisation and tenant isolation: a check on every data-touching route, and a tenant boundary in the query layer
- Input handling and injection: how untrusted input reaches queries, shells, templates and deserializers, and consistent parameterisation
- Secrets and configuration: committed credentials, checked-in environment files, unchanged scaffold defaults, and secret rotation
- Dependency and supply-chain risk: known vulnerabilities, unmaintained packages, and pinned versus latest-at-build resolution
- Logging and error handling: stack traces leaked to callers, and whether failed authorisation reaches a log anyone reads
Infrastructure as code
- Infrastructure as code: Terraform or Bicep read for over-wide network rules, public storage and broad role assignments
Each layer in detail
Authentication and session handling: credential storage, token generation and expiry, password reset flows, and whether a session issued before a privilege change still carries the old privilege afterwards.
Authorisation and tenant isolation: whether every data-touching route enforces an authorisation check, and in a multi-tenant system, whether the tenant boundary sits in the query layer or only in application logic a request can route around.
Input handling and injection: how untrusted input reaches a query, a shell command, a template engine or a deserializer, and whether parameterisation and escaping are applied consistently, or only where a reviewer happened to look first.
Secrets and configuration: credentials committed to source, environment files checked into a repository, scaffold defaults left unchanged, and whether a secret rotates or has sat static since it was issued.
Dependency and supply-chain risk: the dependency tree read for known vulnerabilities and unmaintained packages, and whether a build resolves a pinned version or whatever is latest at build time.
Logging and error handling: whether an error response leaks a stack trace or an internal path to the caller, and whether a failed authorisation check or a privilege change reaches a log anyone reads.
Infrastructure as code: the Terraform, Bicep or equivalent provisioning the environment, read for the same class of issue as the application itself: a network rule opened wider than needed, a storage account left publicly readable, a role assignment broader than its job.
How a review runs against a live codebase
The process is the same discipline used before code exists, applied to code already running. Read access is agreed at scoping and nothing further: no production credentials, no write access, no access to the deployment pipeline.
Threat model, severity and the follow-up pass
Before a line is read for a specific flaw, the reviewer models what the system does: its roles, its trust boundaries, and where privileged data or a privileged action sits, so a stray finding becomes a prioritised one. Every finding carries the file and the line. Severity reflects what an attacker could do with it in this codebase. A scanner's default score does not set it, so the same vulnerability class can carry different severities depending on what sits in front of it. A follow-up pass, once fixes land, confirms each one closes the issue it was written for without opening another.
From scoping to re-review
Scoping starts with a free 30-minute call and the repositories, services and languages in question. The written scope, quote and timeframe follow, and the review starts once read access is in place. Findings are delivered as a report and walked through with the reviewer.
The re-review runs once your team has merged the fixes, against the findings in the original report.
Design-stage review
Review can start before code exists. A design-stage engagement delivers a threat model of the system or feature, an attack-surface and trust-boundary analysis, and specific design changes: a tenancy model enforced in the database, an integration holding only the privilege its job requires, a queue that authenticates its producers.
This is the process applied to Black Shard's own products: threat modelling before implementation, least-privilege architecture, and security review gates through delivery.
What each finding contains
Every finding follows one structure, so the engineer who owns the file can fix it without a meeting.
- Title and severity, rated for what an attacker could do with the flaw in this codebase
- Location: the repository, file and line, and the commit reviewed
- Description and impact: the flaw, the path an attacker would take to reach it, and what it exposes
- Evidence: the code involved and, where it helps, a request that would trigger it
- Fix: the change to make and the steps to apply it, with OWASP references where they apply
- Re-review status: closed, partially closed or open, recorded once the fix lands
Code review and penetration testing
A penetration test exercises the running system and reports what is reachable and exploitable within the engagement window. A code review reads the source and reports what is wrong at the origin, including code behind feature flags, paths a black-box test does not reach, and the deployment pipeline.
Where a review finding warrants proof against a live system, that is scoped separately as penetration testing. Both are delivered by Black Shard, and an external penetration test starts at $4,950 ex GST.
Logic flaws
Authorisation and business-logic flaws are found by reading the code with knowledge of what the software is for.
Systems we operate
Black Shard builds and operates software in regulated Australian industries. Aurii, clinical software for private-hospital specialists that Black Shard built and operates, runs on Azure with tenant data isolated by PostgreSQL row-level security.
GRM LAW, a Brisbane law firm, runs on an operations and compliance portal with an append-only audit ledger enforced on every state change. Stone Leaf Capital operates a staff portal Black Shard built, with a sealed compliance audit log structured around the firm's AFSL perimeter.
Black Shard works against OWASP and ASD guidance and holds SMB1001:2026 Gold, verifiable on the public CyberCert registry. During an engagement we take read access to the repositories in scope and nothing more.
Secure code review against the Essential Eight, SMB1001 and ISO 27001
None of the three names secure code review as a standalone requirement, and a review is not a substitute for any of them. Each still touches the ground a code review covers, and the evidence a review produces feeds directly into a gap analysis for any of the three.
Black Shard runs its own environment at Essential Eight Maturity Level 3, assessed September 2026.
The Essential Eight
The Essential Eight's patch applications strategy calls for vulnerability scanning against the applications an organisation runs, with vendor patches applied inside set windows once a vulnerability is assessed as critical. A code review reads the dependency tree directly: a package with a known vulnerability, or one with no maintainer left to publish a patch, is a finding before a runtime scanner would otherwise catch it. Its restrict administrative privileges strategy governs how privileged accounts are provisioned and separated; applied to a codebase, the same discipline covers the credential a service account holds in configuration and whether an integration runs with only the privilege one operation needs.
SMB1001
SMB1001 Gold does not list secure code review among its twenty-seven controls either, but its patching control and its discipline around vendors and third parties both rest on knowing what is in a codebase and whether it is current, which is what a dependency and supply-chain review produces as evidence. Black Shard holds SMB1001:2026 Gold, Level 3, issued by CyberCert, active to 17 June 2027 and listed on CyberCert's public registry.
ISO 27001
ISO 27001 Annex A carries a secure development control: an organisation sets rules for building software securely and has to show those rules held in the code that shipped. A code review is direct evidence of that. Black Shard's ISO 27001 readiness work is led by a director who holds the Exemplar Global Certified Lead Auditor credential for ISO/IEC 27001:2022, certificate C-560291, valid to 25 August 2027, an individually held credential.
What does a secure code review cost?
Each engagement is scoped and quoted individually. Cost is driven by the size and shape of the codebase, the number of services and repositories in scope, the languages and frameworks in use, and whether design-stage threat modelling is included.
Scope and engagement shapes
The quote comes back with a defined scope and timeframe before any work starts.
The engagement runs one of two ways: a standalone review with a re-review of the fixes included, or an embedded arrangement where review runs continuously across a build.
Questions, answered
How long does a secure code review take?
It depends on the size of the codebase and the number of services in scope, the languages and frameworks in use, and whether design-stage threat modelling is included alongside the code review. A review of a single service is a shorter exercise than a whole-platform review, and an embedded engagement running continuously across a build is scoped differently again. The timeframe is set at scoping and is in writing before work starts.
What is the difference between a secure code review and a penetration test?
A penetration test exercises the running system and reports what is reachable and exploitable within the engagement window. A code review reads the source directly and reports what is wrong at the origin, including code sitting behind a feature flag, a path a black-box test never reaches, and the deployment pipeline itself. Authorisation gaps and business-logic flaws are usually found by reading the code with knowledge of what it is for; exercising the running system from the outside rarely surfaces them. Where a code review finding warrants proof against a live system, that is scoped separately as a penetration test, and Black Shard delivers both.
Do you need access to our production environment?
No. A code review runs against the source, its configuration and its dependency manifests. We ask for read access to the repositories in scope and nothing beyond that. If a finding warrants proof against a running system, that is scoped separately as penetration testing.
What stacks do you review?
The ones we ship: web applications and APIs, native iOS and Android, and Azure infrastructure and deployment pipelines, across the languages those stacks are built in. If your stack sits outside that, name it in the brief and we will tell you whether we are the right reviewers.
Is this just a static analysis scan with a report attached?
No. Tooling informs where we look. Every finding in the report has been read and confirmed by a reviewer, and a finding without a fix attached is not reported.
Do you review code written with AI coding tools?
Yes. Code is read and judged by the same criteria regardless of how it was written: authentication and session handling, authorisation and tenant isolation, injection, secrets, dependency risk and the rest. Tooling informs where a reviewer looks, but no finding is reported until a reviewer has read and confirmed it, whether the line in question was typed by a person or generated by a tool. A high rate of change into a codebase, which AI-assisted development tends to produce, is itself a reason to keep the review in place.
What happens after we fix the findings?
A re-review is part of the engagement. Once your team has applied the fixes, we read them and confirm each closes the issue it was written for without introducing another.
What does the report look like?
Each finding is ranked by severity and written with impact, reproduction steps, and a fix with the steps to apply it. It is a document engineers can work from directly.
Do you review code for teams outside Australia?
Yes. Black Shard works nationally and internationally, and code review is delivered remotely. The artefact under review is the repository, and the findings carry reproduction steps your engineers can act on wherever they sit.
What is a security code review?
A security code review is a manual read of application source, configuration and dependencies for flaws an attacker could use: broken authentication, missing authorisation checks, injection, exposed secrets and vulnerable dependencies. Each confirmed finding is reported with its file and line, its impact and the fix.