Back to Details

application-security-testing

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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.
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.
这是“保障我的应用安全”类请求的入口场景，此时目标尚未明确为单个URL或代码仓库。核心任务是为每个资产选择合适的测试、执行测试并生成一份分级修复计划——而非对所有内容进行最大深度的测试。
安装步骤、LLM配置、所有CLI参数以及托管云部署方式均在penetration-testing-with-strix技能中。如果执行
strix --version
失败，请先查阅该技能文档。
仅测试用户拥有或获得授权的资产。首次执行测试前需确认授权，且优先选择预发布环境（staging）而非生产环境，因为Agent会发送真实的利用载荷，可能会修改数据。

1. Map the assets

1. 梳理资产

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.
扫描前需询问（或从代码仓库中读取）并记录以下问题的答案：
  • 源代码——单个代码仓库、单体仓库还是多个服务？使用哪些语言/框架？
  • 运行环境——是否有预发布部署？是否有公开生产站点？还是仅存在本地开发服务器？
  • API——是REST、GraphQL还是gRPC？是否有OpenAPI/GraphQL schema？
  • 身份验证——能否获取不同租户下的两个测试账号？大多数高影响漏洞测试需要用到这些账号。
  • 约束条件——非测试范围路径、是否可操作生产环境、预算和时间限制。
如果没有预发布环境且生产环境不可操作，请尽早告知用户。仅代码审查仍有价值，但无法验证针对运行中应用的可利用性。

2. Pick the right test per asset

2. 为每个资产选择合适的测试

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.
资产选用技能
代码仓库或工作目录find-security-vulnerabilities-in-code
运行中的Web应用或预发布站点web-app-penetration-testing
REST/GraphQL/gRPC APIapi-security-testing
映射至OWASP分类的评估owasp-top-10-testing
针对每个Pull Request的持续扫描ci-security-scanning-with-strix
无Docker、无LLM密钥，或需要审计方认可的报告managed-pentesting-with-strix
这些技能包含参数配置、凭证处理和结果解读的详细说明，此处不再重复。
首次评估的执行顺序：
  1. 代码审查：这是成本最低的测试，可梳理出授权模型。
  2. 使用凭证对预发布环境进行渗透测试，并将代码仓库作为第二个目标传入，以便Agent保留源代码上下文。
  3. 添加CI扫描，以便后续自动捕获回归漏洞，无需再次手动测试。
每次仅测试一个资产，在开始下一个测试前先阅读当前报告。代码审查的发现可让后续的在线测试更具针对性。

3. Consolidate into one plan

3. 整合为单一修复计划

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.
每次测试的结果会保存在
strix_runs/<run>/
目录中。将所有结果合并为一个列表，并按照已验证的影响程度而非扫描器给出的严重程度进行排序：
  1. 无需身份验证即可利用的已验证漏洞。
  2. 已验证的跨租户或权限提升漏洞。
  3. 需要身份验证账号才能利用的已验证漏洞。
  4. 未验证的观察结果（配置、依赖项和加固建议）——需明确标记，绝不能将其作为已确认的漏洞呈现。
去重：同一根本原因通常会在代码审查和在线渗透测试中同时出现。

4. Be honest about coverage

4. 如实说明测试覆盖范围

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.
需明确说明未测试的内容——无预发布环境的资产、黑盒测试无法覆盖的类别（日志与告警、供应链完整性、不安全设计），以及任何因预算或次数限制未完成的测试。需核对每次测试的
run.json
状态和成本与
--max-budget
的差异。截断扫描得到的空结果并不代表无安全问题。
之后可使用fix-security-vulnerabilities-with-strix进行修复验证，该技能会针对每个修复重新运行Strix，以确认漏洞已无法被利用。