HOW WE WORK

An Assessment, Step by Step

1. 1

   Understand the application

   In a kickoff call, your developers explain the architecture, what the application is meant to do, and where they see risks themselves. We then import the code into a code property graph, using the open-source platform Joern, and map where attacker-controlled data enters, where it can cause harm, and which code enforces authentication, authorization, and the separation between users or tenants. This map decides where the effort goes.

2. 2

   Find root causes

   We review the code with the help of the graph and, where you permit it, AI. If you want, we write queries for your code base that, unlike generic scanner rules, take your frameworks, input validation, and coding conventions into account. Manual review concentrates on what tools cannot decide: whether authorization is complete, whether business logic can be abused, whether tenants are separated, and whether cryptography and sessions are handled correctly. For each confirmed vulnerability, we search your code for every other instance of the same flaw.

3. 3

   Validate and prioritize

   We report nothing we have not reproduced and whose impact we have not demonstrated. Each finding is rated with the Common Vulnerability Scoring System (CVSS v3.1), but a score alone does not tell your team what to fix first. We also assess what each finding means for your application: how realistic an attack is, what is at stake, and how much effort a fix takes. The report recommends an order, and says clearly which findings matter now and which can wait.

4. 4

   Report for developers

   Critical findings reach you as soon as they are confirmed. The report describes each root cause with all of its instances, references to files and functions, steps to reproduce, the rating and recommended priority, and, if you want, concrete changes to the code. Where findings point to a broader weakness, it says what to improve beyond the individual findings. In a feedback call, we walk your developers through the results, and for 30 days afterwards we answer their questions while they fix them. See an example, from finding to fix.

5. 5

   Fix it together

   Optional

   Our analysts work hands-on with your team on the fixes: proposing them as pull requests, reviewing your developers’ own fixes, running joint sessions on root causes, giving trainings where they help, or working within your team for an agreed period.

6. 6

   Retest and keep it fixed

   Optional

   We verify each fix both in the code and against the running system, and rerun the queries written for each pattern to confirm that no instance remains. On request, we hand these queries over, so that you can run them in your own build pipeline and catch a vulnerability that is reintroduced later. These queries can grow into custom static analysis for your whole code base.

What You Get