Security testing
Hands-on tests. Proof you can reproduce.
All security testingHow we workWhat happens after the first call.See the processBuild
We break software for a living. This is what we build.
All build servicesProof of workOur own apps, built the same way.See themSecurity review of the open-source code you depend on and the projects you run, from dependencies to release pipelines, plus help disclosing what you find.
We check the code you didn’t write, and the pipeline that ships the code you did.
Out of scope stays out. We ask first.
Known vulnerabilities, abandoned packages, risky install scripts and look-alike names.
Lockfiles, registries, pinning, and where a package could be swapped on the way to you.
CI workflows, secrets, token permissions, signing and provenance.
Parsers, authentication, crypto and anything that touches untrusted input.
Branch protection, maintainer access, deploy keys and tokens.
A security policy, a private reporting channel and an advisory workflow.
Everything you depend on, directly and through other packages.
Semgrep and CodeQL on the code, advisory databases on the dependencies.
CI workflows checked for untrusted input, broad tokens and unpinned actions.
Code that touches untrusted input, read line by line.
Bug in someone else’s project? We help you report it privately, coordinate the fix and request a CVE where it fits.
A prioritised plan, then a free retest.
How a finding reads
| Findings mapped to |
|
|---|---|
| Tools we use |
|
Yes. The code that matters most, the CI and release pipeline, and the repo settings. Then we help you set up private reporting.
We report privately to the maintainers, agree a deadline (often 90 days), help test the fix, and publish only once a fix ships or the deadline passes.
No. Your findings are yours. Nothing is published without your written agreement.
Read access to the repositories and CI in scope, a list of what you ship and how, and a maintainer who can answer questions.
Send the scope and your deadline, and we’ll set up a call.
