Black Shard

Security review at the level attacks happen: the code.

Line-level code review, threat modelling, and security architecture from a team that ships production code.

Most security review stops at the scanner. Ours reads the code the way an engineer wrote it and an attacker will read it, and every finding comes back with a concrete fix.

Secure code review

A line-level review of your codebase for the risks that actually bite.

What you get

  • Review for injection, auth, secrets, and dependency risk
  • A concrete fix for every finding, with the steps to apply it
  • A re-review of the fixes

Security architecture & threat modelling

Design-stage review of where a system can be attacked, before you build it.

What you get

  • A threat model of the system or feature
  • Attack-surface and trust-boundary analysis
  • Design changes to close the gaps early

How it is shaped

A standalone review with a re-review of the fixes, or an embedded engagement 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-test to prove it

    Fixed-scope offensive work includes a re-test, so fixes are confirmed closed rather than assumed.

  • 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

Who performs the secure code review?
Engineers who build and run production software. Black Shard designs, ships, and operates its own products, and the people who ship that code are the people who read yours. That matters because a code review is only as good as its reader: someone who has never shipped an authentication flow will not spot the subtle way yours fails. Every finding is validated by hand before it reaches you. We do not forward raw scanner output, and nothing goes into your report that an engineer has not confirmed and written up.
How is our source code handled during an engagement?
Read access to the repositories and environments in scope, nothing more, with administrative privilege granted only where the work demands it. Data we hold is encrypted in transit and at rest, the set of third parties that touch it is kept deliberately small, and the services that host client data sit in Australian regions. If an incident ever touched your material, we have a defined path for identifying, containing, and communicating it, including the notification obligations the Privacy Act places on us. The full posture is on our trust page, alongside the one certification we hold, SMB1001:2026 Gold.
What do we get at the end?
A findings report written to be acted on. For a secure code review it covers injection, authentication, secrets handling, and dependency risk, and every finding arrives in plain English with reproduction steps and a concrete fix your team can apply directly, ranked by what the weakness would cost you. For threat modelling you get the threat model itself, an attack-surface and trust-boundary analysis, and the design changes that close the gaps. None of it is raw scanner output: where a tool surfaced a lead, an engineer confirmed it and wrote it up so your team can act without translation.
What does the re-review cover?
A secure code review includes a re-review of the fixes. Once your team applies the remediation, we read the changed code again and confirm each finding is closed, not just moved. The re-review is part of the standalone engagement, not a separate exercise. Teams that would rather not batch security into a single pass can run an embedded engagement instead, with review sitting inside the delivery cadence rather than at the end of it.
When should threat modelling happen?
At design stage, before the code exists. A threat model maps where the system can be attacked: the surfaces it exposes, the trust boundaries it crosses, the data an adversary would go after. Done before the build, the fix is a design change that costs a conversation. Done after, the same fix can mean reworking something already in production. We model whole systems and single features alike; a new payment flow or a third-party integration is a perfectly good unit of work.
Do you work with teams outside Brisbane?
Yes. Black Shard is a national firm and the work is delivered Australia-wide from our Brisbane head office. A code review needs repository access and time with your engineers, not a desk in your office, so your team's location changes nothing about the engagement. Threat modelling sessions run remotely as readily as they do across a table in Brisbane.
How much does a secure code review cost?
We do not publish prices, because the work is scoped per engagement. A secure code review runs as a standalone review with a re-review of the fixes, or as an embedded engagement across a build. A fixed-scope engagement comes with a clear target, timeframe, and deliverable, so you know exactly what you are buying before the work starts. Send the brief: someone will contact you as soon as possible.
What happens after the review is delivered?
The findings get fixed, and the engagement is built around that. Every finding ships with the steps to apply the fix, so your engineers are not left decoding an abstract recommendation. When the fixes land, the re-review confirms the holes are closed. Teams that want the discipline permanently move to an embedded engagement, where security review runs across the build.

Further reading

The rest of the firm.

Know what your code would give away.

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

Open a brief[email protected]