Services / Source code review
Read the code, by hand.
We threat-model your application, run modern SAST across the stack, then triage every hit by hand, so what you get is real, exploitable findings with code references and fixes, never a raw tool dump.
The point
Real, exploitable findings. Not scanner noise.
A raw SAST report is a wall of maybes. We start from a threat model, confirm every finding in the code by hand, and hand your engineers issues they can fix, plus rules that catch the next one automatically.
Where we focus
The code that decides a breach.
We spend our hours where an attacker would, the trust boundaries, not the boilerplate. Hover to explore.
01 · Authentication
Paths to impersonation
Login, token issuance, and session handling, read line by line, the code paths that let an attacker become one of your users.
weak HS256 secret in source
02 · Authorization
Broken access control, in the source
Where a user can reach data or actions that aren't theirs. We trace every object lookup to the check that should, but doesn't, guard it.
03 · Input validation
Injection, traced to the sink
Every entry point followed to the query, command, or template that runs it, so a finding is a real, reachable sink, not a lint warning.
SQLi unsanitised, user-controlled
04 · Persistence layer
Where data leaks by default
Query construction, ORM pitfalls, and the serialisers that quietly expose more than they should.
05 · Build & deploy
The supply chain no one reads
Secrets in the pipeline, risky dependencies, and the CI config that ships them, the exposure that lives outside the app code.
secret hardcoded API token
Our approach
SAST is the floor, not the report.
Threat modeling first
We learn the app and its trust boundaries before reading a line.
SAST across the stack
Modern tooling to cover ground fast, tuned to your languages.
Manual triage on every hit
A human confirms each finding; no raw scanner noise ever ships.
Fits your SDLC
Findings arrive as PRs, tickets, and rules your team already uses.
What's hiding in your codebase?
Get a quote →Proof · State government
Eighty applications, by hand.
A portfolio assessment across 80+ web applications and Android APKs surfaced source-code disclosure and citizen-data exposure, each proven with reproducible evidence and a clear path to remediation.
“Eighty targets, read by hand, past the scanner baseline every time.”
- → Web apps and mobile APKs in scope
- → Source-code disclosure and PII exposure
- → Prioritised remediation for each finding
What you get
Evidence your team can act on.
Threat model doc
The trust boundaries and attack surface we mapped.
Findings report
Every issue with code references, impact, and fix.
JIRA-ready CSV
Findings your engineers can import and assign in minutes.
Custom Semgrep rules
Rules that catch your specific bug classes going forward.
SBOM bundle
A bill of materials and a known-vuln dependency view.
Engineering walk-through
A live session with your developers, not just a handoff.
Questions, answered
The usual questions.
Do we hand over our source?
Yes, under NDA, or we can work inside your environment if you'd rather not share the repo. Whatever we see stays confidential.
Which languages do you cover?
Python, JavaScript/TypeScript, Java, Ruby, PHP, C#/.NET, and Rust, among others. Tell us your stack and we'll confirm.
Is this just a Semgrep run?
No. SAST is the floor. Every hit is triaged by hand, and we author custom rules for your specific bug classes.
How do findings reach our team?
As a report, a JIRA-ready CSV, custom rules, an SBOM, and a live engineering walk-through, whatever fits your SDLC.
Source code review
Brief us on the codebase.
Tell us your stack and where it matters most. A senior operator replies within one business day.