As web applications grow larger and more complex, achieving good test coverage through traditional test approaches alone becomes difficult and often cost prohibitive.

This is where source-code assisted penetration testing may help.

What is Code-Assisted Penetration Testing?

Code-assisted testing shines in areas of complexity.

To explain what makes this approach different, it’s helpful to first look at how traditional penetration testing typically works.

Let's use testing JWT Validation as an example.

In a traditional penetration test, a tester might attempt to bypass authentication or authorisation by tampering with JSON Web Tokens (JWTs). This could involve:

• Submitting a JWT with a self-signed signature and modified claims.
• Omitting the signature altogether.
• Modifying JWT headers to specify a none algorithm.

The goal is to find a misconfiguration or vulnerability by trial and error.

By contrast in a code-assisted engagement, testers can skip the guesswork and go straight to reviewing how JWTs are validated in the backend.

Consider the following admin-only function:

def delete_user_account(token, user_id):
    payload = decode_jwt(token, verify_signature=False)  # ⚠️ Signature not verified!
    
    if payload.get('role') == 'supersecretadminrole-youwontguessthis':
        perform_deletion(user_id)
        return "User deleted"
    
    return "Access denied"

Without code, a tester might notice that signature verification isn’t enforced but discovering the exact claim needed to abuse privileged functionality can be a time-consuming guessing game.

The Counter-Argument

Access to source code doesn't reflect a realistic attacker scenario!

Yes, this is true that real world attackers don't have access to source code (unless you've got a bigger breach on your hands). However, our goal is typically to achieve the most efficient and comprehensive assessment of your application within the time available.

To account for this increased access, we adjust the risk ratings of our findings to reflect the realistic likelihood of exploitation.

How it Works?

Secure Code Sharing

You provide access to your application’s source code—either as a static export (e.g., ZIP or TAR file) or by inviting our testers to your code repository or organisation.

During Testing

We take the protection of your code seriously. Project Black:

• Operates under strict non-disclosure agreements.
• Your source code is reviewed solely for the purpose of identifying security issues.
• Implements internal security controls to prevent unauthorised access.

After Testing

We deletes all copies of your code once testing is complete.