mcpField
A
application-security-testing

application-security-testing

github.com/usestrixSecurity72.6k13.2k installsUpdated 1d ago
Repository

About application-security-testing

An entry guide for planning application security assessments with Strix. It helps teams choose tests for each asset, combine findings by proven impact, and report coverage limits.

Key features

  1. 01Selects tests based on asset type
  2. 02Plans code, application, and API assessments
  3. 03Ranks combined findings by proven impact
  4. 04Documents untested areas and scan limits

Use cases

  1. 01Planning assessments across repositories and environments
  2. 02Scheduling code review followed by staging tests
  3. 03Consolidating scan results into a remediation plan

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/usestrix/strix --skill application-security-testing

After installing, type/application-security-testingin Claude Code to confirm it loaded.

Details

From the project README

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

AssetSkill to use
Repository or working treefind-security-vulnerabilities-in-code
Live web app or staging siteweb-app-penetration-testing
REST/GraphQL/gRPC APIapi-security-testing
Assessment mapped to OWASP categoriesowasp-top-10-testing
Every pull request, continuouslyci-security-scanning-with-strix
No Docker, no LLM key, or a report an auditor will acceptmanaged-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:

  1. Review the code. It is the cheapest run and it maps the authorization model.
  2. Pentest staging with credentials, and pass the repo as a second target so the agents keep source context.
  3. 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:

  1. Validated exploits reachable without authentication.
  2. Validated cross-tenant or privilege-escalation issues.
  3. Validated issues needing an authenticated account.
  4. 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.

Comments

Markdown supported