Security review for software and architecture.

Black Shard reviews source code and system architecture for vulnerabilities that automated tooling cannot reliably identify on its own.

Talk to us about a code review

Code reviews cover areas such as authentication, authorisation, injection, secrets handling, dependency risk and business-logic flaws. Threat modelling examines the system at design level: trust boundaries, data flows, privileged components and likely attack paths. The output is written for the engineering team responsible for fixing the issue, with specific remediation and a subsequent review where included in scope.

Secure code review

Review of source code for authentication, authorisation, injection, secrets handling, dependency and business-logic flaws.

What you get

Findings with the affected code, the flaw and the specific remediation
Remediation written for the engineers responsible for the fix
A subsequent review of the fixes where included in scope

Security architecture & threat modelling

Design-level review of trust boundaries, data flows, privileged components and likely attack paths.

What you get

A threat model of the system or feature
Attack-surface and trust-boundary analysis
Design changes to address the findings before build

How it is shaped

A standalone review with a subsequent review of the fixes, or an embedded engagement across a build.

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. An engineer confirms every finding before it reaches you. We do not forward raw tool 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. We hold SMB1001:2026 Gold, issued by CyberCert.
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 with reproduction steps and a 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 tool 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; it is 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 worth stealing. 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, and no 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 and we come back with a scoped proposal.
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.

The rest of the firm.

Tell us what you need reviewed.

Brisbane head office. Work delivered across Australia.

Open a briefinfo@blackshard.com.au