Some vulnerabilities leave no trace in the behaviour of a running system until the day they are exploited: a missing check in a rarely used branch, a weak random generator, a secret in the history of the repository. They are visible in the code.
We read the code the way an attacker would if it leaked. Static analysis tools mark the candidates, specialists trace the data from entry point to sink and decide what is real. The review covers the code you wrote, the dependencies you imported and the pipeline that builds them, including code produced with AI assistants.
01Scope
What we test
Authentication and authorisation logic, including framework configuration
Input handling: injection, deserialisation, file and path operations
Cryptography: algorithms, modes, key and random number handling
Secrets in code, configuration, infrastructure definitions and history
Third-party dependencies and their reachability from your code
Build and delivery pipeline: permissions, runners, artefact integrity
Error handling, logging of sensitive data, concurrency
Infrastructure as code: Terraform, Kubernetes manifests, Helm charts
02Approach
How the work is done
01
Threat-driven entry
We start from what matters: the functions that handle money, identity and secrets. The architecture is read first, the code second.
02
Automated analysis
Static analysis, dependency analysis and secret scanning produce candidates. Custom rules are written for the patterns specific to your code.
03
Manual tracing
Each candidate is traced from the entry point to the sink. False positives are discarded, real issues are confirmed in a running instance where possible.
04
Variant analysis
When a flaw is found, the whole code base is searched for its variants. One finding usually has relatives.
Access is granted to named specialists, the code is analysed in an isolated environment and is not copied outside it. Working copies are destroyed 30 days after the engagement is closed. The code is never submitted to public AI services.
We already run a static analyser. What does a manual review add?
An analyser reports patterns. It does not know which of them is reachable, and it does not see a missing authorisation check, because a missing line matches no pattern. The review answers both questions.
Can the review be limited to a part of the code?
Yes. A review of a single component, of the changes since a release or of one pull request is a normal scope.