Services / Source code review
Find security flaws in your code.
A security code review that combines risk-led manual source code review with automated analysis, with verified findings and fixes your developers can act on.
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.
The code that decides a breach.
We spend our hours where an attacker would, the trust boundaries, not the boilerplate. Select a topic 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 it looks like
in practice.
An illustrative example of the class of issue this engagement is built to find, and what changes after it.
Illustrative example, not client data
BeforeWhat we found
# interpolated straight into SQL def report(group_by, start, end): q = f'SELECT sum(amount) FROM tx ' \ f'WHERE ts BETWEEN %s AND %s ' \ f'GROUP BY {group_by}' return db.execute(q, [start, end]) # params are bound, the column name is not # SAST scored this LOW: "parameterised query"
AfterAfter the fix
# column resolved from a fixed allowlist COLUMNS = {"day", "merchant", "region"} def report(group_by, start, end): if group_by not in COLUMNS: raise ValueError("bad grouping") ... # identifier can no longer come from a user
SQL injection the scanner scored as low. The values were parameterised, so the tool saw a safe query. Identifiers cannot be parameterised, and this one came from a query string. Reading it takes a person who knows that distinction.
What's hiding in your codebase?
Request a quoteAssessment walkthrough
Application portfolios and shared risk.
A coordinated web and mobile assessment examines authorization, source exposure, and security weaknesses shared across applications.
Read the walkthrough- Application scope
- Access controls
- Shared causes
Illustrative methodology. Client details remain confidential.
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.
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.
Brief us on the codebase.
Tell us your stack and where it matters most. A senior operator replies within one business day.