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 themExternal and internal infrastructure tests, plus AWS, Google Cloud and Azure configuration reviews, following PTES, NIST SP 800-115 and the CIS Benchmarks.
We start at the edge and keep going until we reach something that matters.
Out of scope stays out. We ask first.
Internet-facing hosts and services, VPNs and remote access.
Segmentation, directory services, management interfaces, paths between zones.
IAM roles, policies, access keys and trust between accounts.
Storage access, encryption, snapshots and backups.
Security groups, firewall rules, public endpoints and peering.
Would anyone notice an attacker, and would the logs show it?
Ranges, accounts, rules, testing hours, and a read-only role for the cloud review.
Nmap and passive sources map hosts, services and versions.
Prowler and ScoutSuite against CIS, then IAM and network rules by hand.
Every exposure confirmed inside the agreed rules, without disrupting your services.
How small issues chain, and what they add up to.
Prioritised fixes, a walkthrough and a free retest.
How a finding reads
| Findings mapped to |
|
|---|---|
| Tools we use |
|
We plan for it. No denial-of-service testing unless you ask, hours agreed in writing, and a contact who can pause us at any time.
A read-only audit role, such as AWS SecurityAudit with ViewOnlyAccess, or the viewer roles in Google Cloud and Azure. Never write access.
Yes. A VPN account, or a small test machine you place inside the network for the test.
AWS, Google Cloud and Azure don’t require approval for most testing of your own resources, but each publishes rules. We stay inside them.
Send the scope and your deadline, and we’ll set up a call.
