SECURITY ASSESSMENTS

Built by Developers, for Developers

Many of our analysts worked as software developers before moving into security. We know what it is like to receive a long list of findings and no help with them. So we explain each finding in your code, tell your team which findings matter and which can wait, and answer their questions while they fix them. See an example, from finding to fix.

Code, Not Just the Surface

Many penetration tests are black-box tests: they probe an application from the outside and see only what it reveals. Our assessments are white-box penetration tests. We also read the code, with the help of the code property graph and tooling tailored to your application, and confirm what we find against the running system. This way we find the root cause of each vulnerability and every place it occurs, and keep false positives out of our reports.

Some vulnerabilities are hard to find from the outside at all: an authorization check missing on one of hundreds of API endpoints, a shared helper that leaks data between tenants, a debug route that no page links to, or a weak use of cryptography. In the code, they are plain to see. Where source code is not available, we test the running system in a black-box penetration test.

If you want AI in your assessment, our analysts work with MAGE, the AI harness we built for security assessments. It takes on grunt work such as scanning and exploitation attempts, and reports no finding that has not been proven exploitable and reviewed by an analyst.

What We Assess

Most of our work is on applications. In web applications and APIs, we concentrate on what scanners cannot judge: whether authentication and authorization hold up, whether business logic can be abused, and whether the data of different users or tenants is properly separated, alongside classic flaws such as injection. In iOS and Android apps, we look at how they store data and how they communicate with their backend, and at the backend itself.

In applications built on large language models, we test whether prompt injection, including instructions hidden in documents, web pages, or tool output that the model reads, can make it leak data or take actions it should not. We check that the model can reach only the tools and data the current user is allowed to use, and that its output is handled safely before it reaches other systems. More on how we test AI applications.

In system code written in C and C++, such as libraries, services, and embedded software, we look for memory-safety flaws like buffer overflows, use-after-free, and integer overflows, and determine whether they can be exploited.

Where your applications depend on infrastructure, we assess it as well. In AWS, Azure, and GCP, we look for misconfigurations, over-privileged identity and access management (IAM) roles, and paths for lateral movement. In internal networks and Active Directory, an assumed-breach test shows how far an attacker can get from a first foothold.

Standards We Follow

Our approach decides how we find vulnerabilities. Established standards make sure that no relevant class of vulnerability is overlooked. We check web applications and APIs against the OWASP Web Security Testing Guide (WSTG) and Application Security Verification Standard (ASVS), which also cover the risks of the OWASP Top 10. Mobile applications are checked against the OWASP Mobile Application Security Verification Standard (MASVS), applications built on large language models against the OWASP Top 10 for LLM Applications, and cloud and infrastructure configurations against the CIS Benchmarks. Each finding is rated with the Common Vulnerability Scoring System (CVSS v3.1), so that you can compare our results with other assessments and feed them into your risk management.

Meeting Compliance Requirements

Many companies need a penetration test or security assessment to meet a compliance requirement, such as the Payment Card Industry Data Security Standard (PCI DSS), ISO/IEC 27001, or SOC 2, or the security requirements of their customers and insurers. Our assessments meet these needs. The report documents scope, method, and coverage, rates each finding, and, after a retest, states whether it has been fixed. Beyond the compliance requirement, your developers come away knowing how to fix what we found.

M&A and Investments

If you are about to acquire or invest in a software company, we review its code for vulnerabilities and check the company’s claims against it, so that you know what you are paying for before the price is agreed. More on software due diligence.

Track Record

Our team has found and responsibly disclosed vulnerabilities in software from Microsoft, Cisco, the Linux kernel, VLC, Squid, and Pidgin, and, under the Whirly Labs name, in Graylog and Thinkst’s OpenCanary. See our work.

How an Assessment Works

Every assessment starts with understanding your application and ends with your developers knowing what to fix first. See how we work, step by step, and what every assessment includes.

What Comes Next

After an assessment, you can book a retest and hands-on help with the fixes. In a half-day findings workshop, we walk your developers through the vulnerabilities we found and fix some of them together, and a developer training built on your findings can go deeper. The vulnerability patterns we found can also become custom static analysis that catches them in your pipeline. If you want us to stay involved as your software changes, our analysts can join you as an embedded security team.