> ## Documentation Index
> Fetch the complete documentation index at: https://docs.noscope.com/llms.txt
> Use this file to discover all available pages before exploring further.

# White-box testing

> Give the agent your source code so it can review the code before it tests the live application.

In a normal (black-box) pentest, the agent only sees what any user or attacker can see: pages, API responses, and error messages. In a white-box pentest, you also give the agent your source code. The agent reads the code first, then tests the live application with that knowledge.

White-box testing is optional. You turn it on for an application by attaching source code in the Target & scope step. If no source code is attached, the scan runs as a normal black-box pentest.

## Why use it

* The agent finds issues that are hard to see from the outside, such as a missing permission check on a rarely used endpoint, or a query that does not filter by tenant.
* The agent knows which endpoints, roles, and data matter most before it sends the first request.
* Each finding points to the file and line in your code, so your developers know where to fix it.

## How a white-box scan works

**1. The agent gets the code**

When the scan starts, the agent copies the GitHub repositories you selected, or extracts the zip files you uploaded. See [Connect source code](https://docs.noscope.com/white-box-testing/connect-source-code.md).

**2. The agent builds a threat model**

The agent reads the code, documentation, and configuration files and writes a threat model. It describes how your application is built, where the trust boundaries are, what an attacker would want, and which rules the code must enforce. See [Threat model](https://docs.noscope.com/white-box-testing/threat-model.md).

**3. The agent tests hypotheses**

The agent lists possible weaknesses as hypotheses, for example "this endpoint may return another tenant's invoices". It removes duplicates, puts the most likely ones first, and checks each one in the source code. See [Hypotheses](https://docs.noscope.com/white-box-testing/hypotheses.md).

**4. Confirmed issues become findings**

When the agent confirms a hypothesis in the code, it creates a finding with a CVSS score, a description, the affected code location, and a fix. These findings appear in the Findings tab with all other findings.

**5. The agent tests the live application**

The live pentest then starts. The agent gets the threat model and the list of confirmed source findings. It tries to reproduce and chain them against your running application, and it looks for new issues as usual.

## Source review and live testing

A finding from source review means the agent confirmed the issue by reading the code. It does not always mean the agent ran an exploit against your live application. The live pentest that follows tries to reproduce these issues. If it succeeds, the finding has proof from both the code and the running application.

## What happens to your code

* The agent only reads the repositories you select, or the zip files you upload.
* Source code is used only for the scan that needs it. It is not kept after the scan and it is never used to train models.
* NoScope only uses GitHub access to read code. It does not push commits or open pull requests.
* Uploaded zip files are used for the next scan only. They are deleted when that scan ends.

## Where to see the results

On the application page, two tabs show the results of the source review for each scan:

* **Threat model**: the threat model the agent wrote.
* **Hypotheses**: every hypothesis the agent tested, with its result.

> [!NOTE]
>
> The Threat model and Hypotheses tabs are not turned on for every organization yet. If you do not see them, contact us and we will turn them on for you.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.