Black Shard reviews source code and system architecture for vulnerabilities that automated tooling cannot reliably identify on its own.
Code reviews cover 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 re-review when the engagement includes one.
Review of source code for authentication, authorisation, injection, secrets handling, dependency and business-logic flaws.
What you get
Design-level review of trust boundaries, data flows, privileged components and likely attack paths.
What you get
How it is shaped
A standalone review with a subsequent review of the fixes, or an embedded engagement across a build.
Third-party assurance on a platform Black Shard built is run by a separate reviewer with no part in the build.
Engineers who build and run production software. The people who ship Black Shard's own products read yours, and someone who has shipped an authentication flow knows the ways one fails. An engineer confirms every finding before it reaches you, and nothing goes into the report that an engineer has not confirmed and written up.
Read access to the repositories and environments in scope, with administrative privilege only where the work demands it. Data is encrypted in transit and at rest, few third parties touch it, and client data is hosted in Australian regions. A defined incident path covers our Privacy Act notification obligations. We hold SMB1001:2026 Gold, issued by CyberCert.
A findings report built to be acted on. A code review covers injection, authentication, secrets handling and dependency risk, with reproduction steps and a fix for every finding, ranked by impact. Threat modelling delivers the threat model, an attack-surface and trust-boundary analysis, and the design changes that close the gaps. Every lead from a tool is confirmed by an engineer.
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. It is part of the standalone engagement. Teams that prefer review inside the delivery cadence can run an embedded engagement instead.
At design stage, before the code exists. A threat model maps the surfaces a system exposes, the trust boundaries it crosses and the data worth stealing. Before the build, a fix is a design change; after, it can mean reworking production. We model whole systems and single features, such as a new payment flow or a third-party integration.
Yes. A code review needs repository access and time with your engineers, so your team's location changes nothing about the engagement. Threat modelling sessions run by video call or across a table in Brisbane.
We do not publish prices, because the work is scoped per engagement: a standalone review with a re-review of the fixes, or an embedded engagement across a build. A fixed-scope engagement has a clear target, timeframe and deliverable agreed before work starts. Send the brief for a scoped proposal.
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
