# Application Security Testing

Runs AppSec tests across a product and ranks reachable issues into a fix plan.

- Repository: https://github.com/usestrix/strix (73218 stars)
- Category: Security
- License: Apache-2.0
- Last updated: 2026-10-30
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add usestrix/strix --skill application-security-testing -g -a claude-code -y`
Codex: `npx skills add usestrix/strix --skill application-security-testing -g -a codex -y`
Cursor: `npx skills add usestrix/strix --skill application-security-testing -g -a cursor -y`
Gemini CLI: `npx skills add usestrix/strix --skill application-security-testing -g -a gemini-cli -y`

## Description

Application security testing (AppSec) across a whole product with Strix, decide which asset needs which test (source code, running web app, API, CI pipeline), run it, and turn the results into a ranked remediation plan. Autonomous agents exploit and prove each issue instead of emitting static-analysis alerts, so the plan is ordered by what is actually reachable. Use when the user asks for an application security review or audit, an appsec assessment, vulnerability scanning across their stack, a security review before a launch or a customer security questionnaire, or does not yet know which kind of security test they need.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Application security testing

Entry point for "make my application secure" requests, where the target is not yet a single URL or repo. The job here is to pick the right test per asset, run it, and produce one ranked plan, not to run everything at maximum depth.

Install, LLM setup, all CLI flags, and the managed-cloud path live in the **penetration-testing-with-strix** skill. Read it first if `strix --version` fails. For a run with no Docker and no LLM key, the same binary drives the managed platform: `strix cloud login`, then `strix cloud scans start ...` (details in **managed-pentesting-with-strix**).

Only test assets the user owns or is authorized to test. Confirm authorization before the first run, and prefer staging over production, because the agents send real exploit payloads and can change data.

## 1. Map the assets

Ask (or read from the repo) and write the answers down before scanning:

- **Source**, one repo, a monorepo, several services? Which languages/frameworks?
- **Running environments**, is there a staging deployment? A public production site? A local dev server only?
- **APIs**, REST, GraphQL, gRPC? Is there an OpenAPI/GraphQL schema?
- **Authentication**, can you get two test accounts in different tenants? Most high-impact bugs need them.
- **Constraints**, out-of-scope paths, whether production may be touched, budget and wall-clock limits.

If there is no staging environment and production is off limits, say so early. A code-only review is still valuable, but it cannot prove exploitability against a live app.

## 2. Pick the right test per asset

The rest: https://github.com/usestrix/strix/blob/HEAD/skills/application-security-testing/SKILL.md