An overview of Cobalt methodologies.


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

:::

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

* [Open Web Application Security Project (OWASP)](https://owasp.org/).
  * Includes different “Top 10” lists for web, API, mobile, AI/LLM, and cloud systems.
* [Open Source Security Testing Methodology Manual (OSSTMM)](https://www.isecom.org/OSSTMM.3.pdf) (PDF).
  * Used for internal and external networks.

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

* [Web](https://docs.cobalt.io/articles/web-methodologies-TD2J4n0Oem)
* [API](https://docs.cobalt.io/articles/api-methodologies-nWz8MVade9)
* [Mobile](https://docs.cobalt.io/en-us/articles/mobile-methodologies-M7k4hP5LUW)
* [Internal Network](https://docs.cobalt.io/en-us/articles/internal-network-methodologies-KlbJ4od9vE)
* [External Network](https://docs.cobalt.io/articles/external-network-methodologies-sxBJAt9n6X)
* Cloud Network
  * [Cloud Configuration Review](https://docs.cobalt.io/en-us/articles/cloud-configuration-review-methodologies-2LTnBpOmYY)
  * [Cloud Pentest Methodology](https://docs.cobalt.io/en-us/articles/cloud-pentest-methodology-h7iHtGPxZB)
* [Desktop](https://docs.cobalt.io/en-us/articles/desktop-methodologies-3qxnBKeNnE)
* [AI/LLM](https://docs.cobalt.io/articles/aillm-methodologies-fa4rMCouO3)

The methodology is usually fixed, based on the Test Type or the [Asset Type](https://docs.cobalt.io/en-us/articles/asset-types-OQp8vLaQ85) 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:

 ![](https://brainfish-storage-prod.s3-accelerate.amazonaws.com/uploads/e425698c-e7a2-4adf-805e-55be5078fafc/6dee8c6d-05cd-4563-a06c-7276fae376f9/image.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAUPPN5IL34BQ6HVND%2F20260414%2Fus-east-2%2Fs3%2Faws4_request&X-Amz-Date=20260414T145214Z&X-Amz-Expires=3000&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEMT%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMiJHMEUCIGeuQmozgCJtURNzdZG5dSIWxinBUh7Y0A8xo83l3JNoAiEA53ddJp6N0tuOAnIKKkTk1q7b43IvPziCbgC9Snm%2FW8Aq5gUIjf%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FARACGgwzMDgxMjU5NzUyODciDKJe6DezwYuJf4VArSq6BaSxMBbEu8%2B%2BmISIDHOQyqxchNGtcsO6g2cBH7%2BzRL%2Buj75Zk%2FTsZt3Y1WWMxtMcYkEgopnqSaWVj94fmPgOJI35EFo19hHeZOcfrEq9WPtF4tFjtIcXeT7U%2FhXWvFR7FqUhI7GP4%2Fe6U9PewSmC7baWCHb5WIeJC19FyO3BZW8uBKU7TOlTz9UE89kaIdCBj0DI6v%2BA3Y2X7ZfGjMQlf7myXVGDU%2BFE54a5SqAPbEHD2VA9FFwQNDu9J6XE%2BVSL2Aa92rjkPKQ%2FSeTqCyYfEq8Fh%2B3Q%2FcJdo8wpnJebUdmcAH77G5c56dfIrtX5SZFuwo57rofuNMsNrKVuG88eRVwCIwy5u8xVibifAEXQ4cH1PCvT4%2BsV0lrkwnvtIpWkjvtM0ncibWZNJ6jHE25reTuCnJxplgDD%2FK6bVJXDNPNhJtWyn1yya1Mkl%2F07OA%2Fbkl3JQvlZzyYUJDrZY1B5E3%2FX%2FSTZtQ0iZHXLAkkN1LzUx7GHbT8JCZX8VyZkAXuwN1MP9SzWMSNOwZeKBCAYG3y%2Fu2sSxt3kcDDczWprDczv%2BUoWLev7f%2BOug9ZQd%2FxLULalRF4HnhNSDyFOSAe5jo8WhkZS%2B73CvEQY7Rfpv2gHEwT1T3M4hMZRF28oUyVqKGf2voCURHnyeZ9d2wQI0GoMbQYgP7POsRvAftmOrEWUm5kPLHxa1XA5aUyLLQY%2BiMfneyqbe%2BAjdSuJVLxKH3infANLBPrmKvMJNj02Vgbznq8geeFaqIiLr9WTG8P8TZ0z182A7JBMXJFeJ25NvRhIB39NAMDl6FgN0uug1q4LSFYM2iAJleC%2BHjA6mMFBI55VzMDAF2fLVasbkGMbkaTCKPeBPaFFIc4SaQl4oeFWtOBrIPPcO4oKbFSuYruy4M51uSNVLeze38m7W0RPk2FBZISbBoC%2FoYYmMLLQ%2BM4GOpAB6FxyT5zcOuLx%2FQJ07I78plwlrXgJpwVRXxs9uCR84lxs05wJuWGJp1dXJq1bjN8HSgb3fu2ElTBnwr11A6Wvov7vHtfSoR4R1jjCHHszqReC8ZSyAGBff7pL%2BBBR%2BvyUGO%2BHBUDo4BbCa1iLDcxeIPySBGzU9j6ZXNIJw1DkypF%2BpoNTtI1xPY4GXxkx1%2Fig&X-Amz-Signature=8c19c77e5bcf4d650cf08df4f61d6c4302bdb08da02c8dcbf1ac38d69f9f68c2&X-Amz-SignedHeaders=host&response-content-disposition=attachment)

## 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.

## Cobalt Testing and Traffic Details

The following outlines the typical traffic profile generated during a Cobalt engagement.

### Source IPs

All network traffic associated with a Cobalt pentest originates from a controlled range of [IPs](https://docs.cobalt.io/en-us/articles/preparation-LDnW9MraOZ), ensuring that the traffic is easily identifiable. All testing traffic passes through Cobalt VPNs, which can be stopped as needed in an emergency.

### Expected Traffic Volume

Our testing is primarily focused on manual techniques, which produce a light traffic load; however, there are some automated phases that generate brief, higher spikes.

| Metric | Typical Activity | Peak Activity |
|----|:---|:---|
| Expected Peak Bandwidth | Manual techniques typically use an order of magnitude less than the peak. | May peak at 100 Mbps (0.1 Gbps) when running brief, intensive scans. |
| Expected Peak Queries Per Second (QPS) | The majority of testing is manual, which typically produces less than 10 QPS. | The test may have brief periods of 10–100 QPS. |




Cobalt Methodologies Overview

Web Methodologies

API Methodologies

External Network Methodologies

Internal Network Methodologies

Mobile Methodologies

Cloud Configuration Review Methodologies

Cloud Pentest Methodology

Desktop Methodologies

AI/LLM Methodologies

Digital Risk Assessment Methodology

Secure Code Review Methodologies

Methodologies

How to get started with Cobalt

Getting Started

Risk Advisories

Assets are what we pentest

Asset Types

Create an Asset

Assets

Pentests

Overview

Asset Details

Pentest Details

Scope & Test Period

Preparation

Create a Pentest

Pentest Process

Pentest States

Coverage Checklist

Pentest Expectations

Set Up an In-House Pentest

Complete an In-House Pentest (For Pentesters)

In House Pentests

Severity Levels

Finding States

Remediate Findings

Findings

Customize Your Report

Co-branded Reports

Contents of a Pentest Report

Reports

Engagements Overview

Digital Risk Assessment

Secure Code Review

Engagements

Insights

Planning

Attack Surface Monitoring (ASM)

Attack Surface

DAST Scanner Overview

Best Practices

Integrations

Partial Scans: Reduced Scope

Scans

Sequence recorder

Targets

Target Authentication

Extra Hosts

Blackout Period

DAST Scanner

Account Overview

Account Settings

Password Best Practices

Sign In to Cobalt

Troubleshoot Sign-in Issues

User Account

Collaboration Overview

Collaborate on Pentests

Groups

Manage Pentest Collaborators

Manage Notifications

User Roles and Permissions

Collaboration

Organization Overview

Manage Users

Your Cobalt Contract

How to Configure SAML 2.0 for Cobalt 

SAML Migration: Update Your Configuration

Configure SAML SSO

SCIM Provisioning Setup Guide

Configure Organization Settings

Organization

Cobalt Credits

Track Your Credits

Cobalt PtaaS Tiers

Credits

Cobalt Integrations Overview

Connect your applications

Create GitHub tickets for Findings

Send MS Teams notifications for Findings

Create Azure DevOps Work Item for Findings

Create Jira tickets for Findings

Send email notifications for Findings from Outlook

Create GitLab tickets for Findings

HTTP Connector

Import Assets from Google Sheets

Map Cobalt Pentest Finding Severity to Jira Issue Priority

Modify Jira Issue Summary to contain Pentest Title

How to Guides

Troubleshooting

Integration Builder

Jira Data Center Integration

Push Cobalt Findings to Jira

Switching to a New Jira Instance

Jira Cloud Integration

Troubleshoot Your Jira Integration

Synchronize Cobalt Severity Levels with Jira

Integrate Jira with Cobalt

Slack

Microsoft Teams

Webhooks

DefectDojo

Kenna Security

Vanta

Carried Over Findings

Create Test Finding

Cobalt API Overview

Partner Integrations

API Versions

Events

Errors

Subscription

Introduction

Authentication

EU Data Center

Organizations

Engagement Findings

DAST Targets

DAST Scans

DAST Scheduled Scans

DAST Findings

External Ticket References

Tokens

Pagination

Idempotency

Rate Limits

Create a Personal Cobalt API Token

Changelog

Get an Organization Token

Revoke Your Personal Cobalt API Tokens

Create or Modify an Asset

Import Findings to Google Sheets

Cobalt API

Glossary

March 2026

February 2026

January 2026

November 2025 

August 2025

July 2025

June 2025

May 2025

April 2025

March 2025

January 2025

December 2024

November 2024

October 2024

September 2024

August 2024

July 2024

June 2024

May 2024

April 2024

March 2024

January 2024

What's New

Guide

Cobalt Product Documentation

Cobalt Methodologies Overview

Share

Share

Cobalt Methodologies Overview

Share

Share