Black Shard

We read your code the way an attacker will.

Line-level security review from engineers who ship production code, delivered Australia-wide, with a concrete fix for every finding and a re-review once it lands.

Most security review stops at the scanner. A scanner matches patterns; it has no idea what your application is supposed to do, so it misses the flaws that matter most: the authorisation check that trusts a client-supplied ID, the session that survives a password reset, the credential committed to the repository months ago and never rotated. Those flaws live in the code, and the only way to find them is to read it.

Black Shard is an Australian software engineering and cybersecurity firm with its head office in Brisbane. We build and run production software, and we review client code the same way we review our own: line by line, against the ways it will actually be attacked, with a concrete fix attached to every finding and a re-review once your team has applied them. Delivered Australia-wide.

What a secure code review involves

We read the source. Not a sample, not the diff of the last sprint: the authentication flow, the authorisation checks on every route that touches data, the query layer, the secrets handling, the dependency tree, and the configuration that wires it all together. The review concentrates on the classes of flaw that produce real incidents: injection in all its forms, broken authentication and session handling, authorisation gaps and tenancy boundaries in multi-tenant systems, secrets in code or configuration, and vulnerable or abandoned dependencies.

Every finding is validated by hand before it reaches the report. We do not forward raw scanner output, and we do not pad the findings list with theoretical issues no attacker would bother with. What you receive is written in plain English with severity, impact and reproduction steps, and each finding carries its fix, with the steps to apply it. When your team has shipped the fixes, we re-review them.

  • Line-level review covering injection, authentication and authorisation, secrets handling, and dependency risk
  • Every finding validated by hand before it reaches the report
  • Plain-English write-ups with severity, impact and reproduction steps
  • A concrete fix for each finding, with the steps to apply it
  • A re-review of the fixes once they land

How is this different from a scanner or a penetration test?

Static analysis tools are useful hygiene, and we have no argument with them as a category. But a scanner matches patterns against code it does not understand. It cannot know that an endpoint returning another customer's records is a catastrophe rather than a feature, because that judgement requires knowing what the software is for. Broken authorisation and business-logic abuse, the flaws behind some of the most damaging incidents, are close to invisible to automated tooling and sit in plain sight for a person reading the code with intent.

A penetration test attacks the running system from the outside, the way an adversary would, and proves what is reachable and exploitable within the engagement window. It is the right tool for that question. A code review answers a different one: what is wrong at the source, including flaws that sit behind feature flags, in code paths a black-box test never reaches, or in the deploy pipeline itself. The two are complementary. A pentest tells you the door is open; the review tells you why, where the same hinge was reused, and how to fix it once.

We run both practices under one roof. Where a review finding warrants proof of exploitability against a live system, it hands straight into our offensive testing work, which attacks applications, networks, and people against the OWASP and ASD playbooks.

Can a security review start before the code exists?

Yes, and the earliest review is the cheapest one. Threat modelling at design stage maps where a system can be attacked before anyone has built it: what an adversary would want, which trust boundaries they would cross to get it, and which parts of the design make that easy. A tenancy model that leans on developer discipline instead of the database, an integration holding more privilege than its job requires, a queue that trusts its producers: these are design flaws, and no amount of careful coding downstream repairs them.

A design-stage engagement delivers a threat model of the system or feature, an attack-surface and trust-boundary analysis, and specific design changes to close the gaps before they become load-bearing. It is how we build our own products: threat modelling before a line is written, least-privilege architecture, and security review gates through delivery. Our approach page describes how that discipline runs through every engagement.

When should you commission a secure code review?

Before launch. Once real users and real data arrive, every fix costs more: change windows, migration risk, disclosure decisions. A review in the weeks before go-live is the last point where findings are just engineering work.

After an incident. The incident tells you where an attacker got in once. A review answers the harder question: where else does the same class of flaw live, and what did the attacker have the opportunity to reach. Fixing the single exploited bug and stopping there is how organisations get breached twice.

During due diligence. If you are acquiring or investing in a software business, the codebase is the asset. A review tells you what liability ships with it: the secrets in the commit history, the abandoned dependencies, the authorisation model held together by convention. The same applies in reverse. A seller who commissions a review ahead of a process controls the narrative on what is found.

Who reads your code

Engineers who ship production code, not scanner operators. Black Shard builds and operates software in regulated Australian industries: clinical software for private-hospital specialists, running on Azure with tenant data isolated by PostgreSQL row-level security; the compliance and operations portal that GRM LAW, a Brisbane law firm, runs on, with an append-only audit ledger enforced on every state change; and the operations platform Stone Leaf Capital, an Australian capital-markets firm, engaged us to build, structured around its AFSL perimeter. We know what a missing authorisation check costs because we carry that risk in our own production systems.

We work against the OWASP and ASD playbooks, and we hold SMB1001:2026 Gold, verifiable on the public CyberCert registry. During an engagement we take least-privilege access to your code: read access to the repositories in scope and nothing more. Our trust page sets out exactly what we hold, what we self-assess against, and what we deliberately do not claim.

What does a secure code review cost?

We scope and quote each engagement individually. No figure on this page would be honest, because the drivers vary too much between codebases: the size and shape of the code, the number of services and repositories in scope, the languages and frameworks in play, and whether design-stage threat modelling is part of the brief. Name those in your first email and the quote comes back specific, 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.

Every engagement includes

  • A director on the work

    A director reads the brief, scopes the engagement, and stays accountable for the result.

  • Fixed scope, quoted first

    Scope, timeframe, and price are agreed before work starts.

  • Findings validated by hand

    Every finding is checked by a human, written in plain English, and paired with a concrete fix. Raw scanner output is never forwarded.

  • A re-review to prove it

    Once your team ships the fixes, we read them and confirm each one is closed.

  • Least-privilege access

    We take only the access the work requires, and client data sits in Australian regions.

  • A report that is yours

    Written for your engineers and your board, and kept confidential.

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, so we set the timeframe when we scope the engagement rather than promising a number here. A focused review of a single service is a much shorter exercise than a whole-platform review. You will know the schedule before any work starts.
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 least-privilege read access to the repositories in scope and nothing beyond that. If a finding warrants proof against a running system, we scope that separately as offensive testing.
What stacks do you review?
The ones we ship ourselves: 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 plainly whether we are the right reviewers.
Is this just a static analysis scan with a report attached?
No. Tooling can inform where we look, but every finding in the report was read, understood and validated by a person before it was written up, and a finding with no fix attached does not go in the report.
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 one closes the hole it was written for without opening a new one.
What does the report look like?
Plain English, with every finding ranked by severity and written up with impact and reproduction steps, and a concrete fix attached with the steps to apply it. It is a document your engineers can work from directly, not raw tool output.
Are you only in Brisbane?
We are a national firm, with the head office in Brisbane and the work delivered Australia-wide. Code review suits remote delivery well: the artefact under review is the repository, and the findings arrive in plain English with reproduction steps your engineers can act on wherever they sit.

Related reading

The full practice: Secure development & code review.

Ship code that stands up to attack.

Australia-wide, from our Brisbane head office. Someone will contact you as soon as possible.

Open a briefinfo@blackshard.com.au