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

# How Strix works

> Learn how Strix reviews applications and helps teams understand findings, prioritize vulnerabilities, and track remediation.

export const ScarfPixel = () => <img referrerPolicy="no-referrer-when-downgrade" src="https://static.scarf.sh/a.png?x-pxid=831669b6-b4bd-42cb-8832-2122c03e1d5f" alt="" width="1" height="1" style={{
  position: "absolute",
  width: 0,
  height: 0,
  opacity: 0,
  pointerEvents: "none"
}} />;

<ScarfPixel />

Strix uses AI to review applications for security issues.
Strix calls these reviews **pentests** and records findings as **vulnerabilities**.
Your team defines the scope, reviews the evidence, and decides how to address each finding.

This guide explains the review process for developers, security teams, and buyers.

## Define the scope

Scope identifies the applications, repositories, environments, and accounts included in a pentest.
Review only applications that you own or have permission to assess.
Record any exclusions and the context that the review needs.

The Strix API distinguishes two pentest types:

* **Blackbox** pentests review applications externally.
* **Whitebox** pentests include source code.

Strix requires domain ownership verification before a domain pentest.

The [knowledge base](/guides/knowledge) provides organization context, policies, and repository profiles.
This context helps Strix understand the application.

## Understand the findings

A finding describes a potential security issue in the reviewed application.
Finding details can include severity, affected code, evidence, assumptions, and remediation steps.
Use these details to understand the issue in the context of your application.

Some findings link to captured HTTP requests and responses.
Other findings have no captured HTTP evidence.
For example, a finding from source code review can have an empty evidence list.
Archived traffic can also expire or become unavailable.

## Triage the findings

Triage means deciding which findings need action and in what order.
Review the reported severity alongside the affected assets, access requirements, business impact, and available evidence.
Assign a responsible person to each finding that needs action.

Strix provides these vulnerability statuses:

| Status         | Meaning                                                                               |
| -------------- | ------------------------------------------------------------------------------------- |
| `open`         | The team has not started remediation.                                                 |
| `in_progress`  | The team is working on remediation.                                                   |
| `snoozed`      | The team has deferred the finding until its snooze deadline.                          |
| `fixed`        | The team has completed remediation.                                                   |
| `ignored`      | The team has accepted the risk.                                                       |
| `not_affected` | The team has reviewed the finding and determined that it does not apply to the asset. |

Record the reason for each decision in the finding notes.
A status change records a decision.
A status change does not, by itself, verify a fix.

## Review the remediation

Use the remediation steps as input to the engineering review.
Check that the proposed change addresses the underlying cause.
Review the change for effects on expected application behavior.
Record the change and the verification result before you mark the finding as fixed.

Strix supports finding notes and a history of status and other finding changes.
See [Vulnerabilities](/guides/vulnerabilities) for the available fields and status controls.

## Understand the limits

A pentest reflects its scope and the application state at the time of the review.
It does not establish that every part of an application is secure.
Unavailable accounts, missing context, and excluded assets can limit the review.
AI-generated findings and remediation steps need human review.

If an audit requires a specific deliverable, confirm the requirements with your auditor.
Report downloads require the Enterprise plan in the current [report documentation](/guides/scans#download-report).

## Next steps for buyers

Before you select a product or plan, define the decision that the review must support.
For example, your team might need to prioritize application fixes or provide evidence for an internal security review.

Use these questions to prepare an evaluation:

* Which assets and environments need a review?
* Who will review the findings and track remediation?
* What evidence must the security team receive?
* Which report formats or other deliverables does the buyer require?
* How will the team record remediation decisions and verify fixes?

See [current pricing](https://www.strix.ai/pricing) for plan information.
Confirm the scope, available deliverables, and access requirements before you commit to a plan.
For API concepts, return to the [introduction](/introduction) and [authentication guide](/authentication).