Skip to main content
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 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: 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 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.

​
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 for plan information. Confirm the scope, available deliverables, and access requirements before you commit to a plan. For API concepts, return to the introduction and authentication guide.