application-security-testing
- Use it when:
- You want an application-security review across a whole product but don't yet know which test you need.
- It does:
- Maps each asset (code, web app, API, CI) to the right Strix skill, sequences the runs, and merges findings into one ranked plan.
- You get:
- A remediation plan ordered by proven impact, with honest coverage gaps noted.
- Unlike the single-target skills:
- This one decides what to run and in what order.
Skill 2 of 8 in the Strix bundle, after penetration-testing-with-strix and before find-security-vulnerabilities-in-code.
Only works inside its bundle: Routes each asset to the bundle's other Strix skills and sequences the runs; on its own it gives the mapping and a ranked plan but defers the actual testing and setup to them. Install Strix instead.
TL;DR
The entry point for a broad 'make my application secure' request where the target is not yet one URL or repo. It maps the product's assets, source, running environments, APIs, authentication and constraints, then picks the matching Strix skill per asset: code review, web-app pentest, API testing, OWASP assessment, CI scanning, or the managed cloud. It recommends a first-assessment sequence, review the code first since it is cheapest and maps the authorization model, then pentest staging with the repo as a second target, then add CI, running one asset at a time and reading each report before the next. It consolidates findings into a single list ranked by proven impact rather than scanner severity, deduplicates issues that surface in both code and live runs, and states plainly what was not tested. It defers the actual flags and result-reading to the per-asset skills and hands remediation to the fix skill.
Summarizes the skill at 0601550.
npx skills add https://github.com/usestrix/strix --skill application-security-testing skills.sh pageSource on GitHubAll skills from usestrix/strix
- Total Downloads
- 15,600 on skills.sh, Nov 9, 2026
- Repo stars
- 74,490 usestrix/strix
- First seen
- Aug 20, 2026 on skills.sh
Weekly values
| Week to | Installs |
|---|---|
| Sep 21 | 1,078 |
| Sep 28 | 1,050 |
| Oct 5 | 1,101 |
| Oct 12 | 1,162 |
| Oct 19 | 1,593 |
| Oct 26 | 1,611 |
| Nov 2 | 1,648 |
| Nov 9 | 1,459 |
| Category |
Compliance, guardrails, skill vetting and browser fingerprinting. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills. |
|---|---|
| Type |
An entry point that picks and loads other skills. Retired skills that only redirect count as routers. |
| Effect |
Adds no side effects of its own. It shapes how the agent thinks, writes or reviews. Guidelines and routers are always effect:none, even when the task they support edits code. |
| Needs |
A specific command-line tool or desktop app must be installed, such as gh, agent-browser, LibreOffice, Obsidian or a vendor CLI. An account, API key or paid plan with an outside service. |
| Publisher |
A verified publisher on skills.sh, or the company or maintainer behind the product the skill operates. |
| Topics | |
| Stack |
SKILL.md
From usestrix/strix at 0601550. Checked daily, last changed Nov 6, 2026.
Frontmatter
name: application-security-testing
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.
license: Apache-2.0
metadata:
author: usestrix
homepage: https://docs.strix.aiApplication 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
| Asset | Skill to use |
|---|---|
| Repository or working tree | find-security-vulnerabilities-in-code |
| Live web app or staging site | web-app-penetration-testing |
| REST/GraphQL/gRPC API | api-security-testing |
| Assessment mapped to OWASP categories | owasp-top-10-testing |
| Every pull request, continuously | ci-security-scanning-with-strix |
| No Docker, no LLM key, or a report an auditor will accept | managed-pentesting-with-strix |
Those skills carry the flags, credential handling, and result-reading details. Do not duplicate their instructions here.
Sequence for a first assessment:
- Review the code. It is the cheapest run and it maps the authorization model.
- Pentest staging with credentials, and pass the repo as a second target so the agents keep source context.
- Add CI scanning, so later regressions are caught without another manual pass.
Run one asset at a time and read each report before starting the next. Findings from the code review make the live run sharper.
3. Consolidate into one plan
Findings arrive per run in strix_runs/<run>/. Merge them into a single list and rank by proven impact, not by scanner severity:
- Validated exploits reachable without authentication.
- Validated cross-tenant or privilege-escalation issues.
- Validated issues needing an authenticated account.
- Unproven observations (configuration, dependency, and hardening notes) — flag as such, and never present them as confirmed vulnerabilities.
Deduplicate: the same root cause often surfaces in both the code review and the live pentest.
4. Be honest about coverage
State plainly what was not tested — assets with no staging environment, categories a black-box run cannot reach (logging and alerting, supply-chain integrity, insecure design), and any run that hit its budget or turn cap before finishing. Check run.json status and cost against --max-budget for each run. An empty result set from a truncated scan is not a clean bill of health.
Then remediate with fix-security-vulnerabilities-with-strix, which re-runs Strix against each fix to prove the exploit no longer works.