Cobalt Methodologies

An overview of Cobalt methodologies.

Cobalt pentesters follow specific methodologies for different test and asset types.

By default, our pentesters test for industry standard vulnerabilities from:

For more information, refer to the detailed pages associated with your asset.

The methodology is usually fixed, based on the Test Type or the Asset Type you defined earlier. If you choose a combined asset type, such as Web + API, you can limit the test to either of the individual methodologies:

Choice of Methodologies

Testing Approaches

Understanding the level of testing access provided to the team is critical to defining the scope and depth of testing. We offer three standard approaches:

Black-box Testing

In a black-box engagement, testers are given no internal knowledge of the application or infrastructure. They simulate an external attacker with no privileged access, relying entirely on publicly available information and exposed functionality. This approach tests how the application performs under real-world attack conditions but may not uncover deeper or logic-based flaws due to limited visibility. Testing will cease immediately and the Customer will be contacted if the pentester gains access to the application or network.

Grey-box Testing

In a grey-box engagement, testers are provided with partial knowledge, such as valid user credentials, limited API documentation, or an overview of the application’s architecture. This approach balances realism with efficiency, allowing deeper testing of authenticated functionality, access control, and business logic flaws while retaining an external attack perspective.

White-box Testing

In a white-box engagement, testers are given full access to internal documentation, architecture diagrams, source code, configuration details, and test accounts with various roles. This method enables comprehensive coverage and is ideal for identifying deep-seated vulnerabilities, insecure configurations, and architectural weaknesses.

Out of Scope Testing

When you engage Cobalt for a pentest, it’s important to understand what’s usually outside the boundaries of the test. This clarity helps manage expectations and ensures the test focuses on the most relevant areas of your digital security. Here are a few key areas that generally fall out of scope:

Denial-of-Service (DoS/DDoS) Testing

Direct Denial-of-Service (DoS) or Distributed Denial-of-Service (DDoS) testing is not included in a standard Cobalt pentest.

Why it’s excluded:

  • DoS attacks are designed to crash or overwhelm services. Performing these tests could lead to significant downtime for your critical business operations.
  • Uncontrolled DoS testing can be indistinguishable from a malicious attack, and it might inadvertently affect other organizations that share infrastructure with you.
  • Assessing DoS/DDoS resilience usually requires specific performance and load testing. This is often done in controlled staging environments, not as part of a general security pentest.

Third-Party Applications and Libraries

Cobalt pentests primarily concentrate on the custom code and configurations implemented. Cobalt does not delve into the inherent security of third-party applications and libraries.

For example, if you use a third-party service like Okta or Auth0 for authentication:

  • Cobalt will test the connection and integration between your application and the authentication service. This includes looking for vulnerabilities in how your application communicates with Okta/Auth0, how it handles tokens, or if there are any misconfigurations that could expose your users.
  • Cobalt will not test the security of Okta’s or Auth0’s own authentication system. The security of their underlying platform, their servers, and their internal code is the responsibility of those vendors.

Why they’re excluded:

  • The security of third-party products is primarily the vendor’s responsibility. Organizations should rely on vendor security attestations, audit reports, and their own due diligence when choosing these solutions.
  • Cobalt pentesters typically don’t have the legal authorization or the necessary technical access to conduct in-depth testing on a third-party vendor’s infrastructure.
  • If third-party components are included in the scope, Cobalt testers will focus on how they are integrated and configured within your environment, rather than attempting to uncover vulnerabilities within the third-party product itself.
Last modified June 17, 2025