We audit your product’s security using the methods of a real attacker, with your written permission. Then we show you what we reached and how serious it is, and give recommendations for fixing each vulnerability.
A report your developers can act on and your management can read. Below is a made-up example.
billing.example.com
Web app and API, two user roles
One page in plain language for management. The technical detail for developers follows it.
How we reached it
What it means
Anyone with an account can see every customer’s names, addresses and amounts, and edit them.
Recommendation
Add an authorization check on the server: the invoice must belong to the signed-in account, on every read and write.
A fixed price follows a free scoping call. One retest of the fixes is included.
We agree on what is off limits before we start and we run no denial-of-service tests. Where we can, we test on a staging copy. If something looks unsafe during a test, we stop and call you.
No. We usually ask for a test account per role, which is closer to what a real customer or attacker has. With code access we go deeper in the same time.
A test alone won’t. PCI DSS asks for penetration tests outright, and SOC 2 or ISO 27001 auditors and large customers often expect one. Our report is evidence for them. We don’t certify anything.
Yes, as a check before release. If an auditor or client needs an independent test, we’ll say so and you should use another firm for that one.
Yes. We build software every day, so your team can take the report or we can do the fixes as separate work. Either way the retest is included.
A signed permission from whoever owns the system, the list of what to test, and test accounts. We only test systems you own or are allowed to have tested.