需要做整体应用安全测试但不确定用哪种测试时…

面向整个产品做应用安全评估：先盘点资产，再为每类资产选择合适的安全测试并执行，最后合并成一份按已验证影响排序的修复计划。

适用场景

解决思路

1. 先确认授权：只测试用户拥有或已获授权测试的资产，首次运行前确认授权，并优先使用 staging 而非生产环境，因为 agent 会发送真实漏洞利用载荷并可能修改数据。
2. 盘点资产并在扫描前写下答案：源码（单仓库、monorepo 还是多个服务？哪些语言/框架？）、运行环境（是否有 staging 部署、公开生产站点，还是只有本地开发服务器？）、API（REST、GraphQL、gRPC？是否有 OpenAPI/GraphQL schema？）、认证（能否拿到两个不同租户的测试账号？多数高危漏洞需要它们）、约束（范围外路径、是否允许触碰生产、预算与时间限制）。
3. 如果没有 staging 环境且生产环境禁止触碰，尽早说明：仅做代码审查仍有价值，但无法证明漏洞在真实应用中可被利用。
4. 按资产类型选择对应测试：仓库或工作区用 find-security-vulnerabilities-in-code；在线 Web 应用或 staging 站点用 web-app-penetration-testing；REST/GraphQL/gRPC API 用 api-security-testing；按 OWASP 分类的评估用 owasp-top-10-testing；每个 pull request 持续扫描用 ci-security-scanning-with-strix；没有 Docker、没有 LLM key，或需要审计师认可的报告时用 managed-pentesting-with-strix。
5. 首次评估按顺序执行：1) 先审查代码，这是成本最低的一轮，并能梳理出授权模型；2) 带凭证对 staging 做渗透测试，并把仓库作为第二个目标传入，让 agent 保留源码上下文；3) 加入 CI 扫描，使后续回归无需再次手动评估即可被发现。
6. 一次只运行一个资产，读完每份报告再开始下一个；代码审查的发现会让后续实时测试更精准。
7. 将各次运行在 strix_runs/<run>/ 下产生的发现合并为单一列表，并按已验证影响而非扫描器严重级别排序：1) 无需认证即可到达的已验证漏洞利用；2) 已验证的跨租户或权限提升问题；3) 需要认证账号的已验证问题；4) 未证实的观察项（配置、依赖与加固建议）——标注为未证实，绝不作为已确认漏洞呈现。
8. 去重：同一根因常常同时出现在代码审查和实时渗透测试中。
9. 如实说明覆盖范围：明确列出未测试的内容——没有 staging 环境的资产、黑盒运行无法触及的类别（日志与告警、供应链完整性、不安全设计），以及任何在完成前触及预算或轮次上限的运行；对每次运行检查 run.json 的状态与成本是否超出 --max-budget；被截断的扫描返回空结果不等于安全。
10. 随后用 fix-security-vulnerabilities-with-strix 进行修复，它会针对每个修复重新运行 Strix 以证明漏洞利用不再有效。
11. 若 strix --version 失败，先阅读 penetration-testing-with-strix 技能（安装、LLM 配置、所有 CLI 参数与托管云路径）；无 Docker 且无 LLM key 时，同一二进制可驱动托管平台：先 strix cloud login，再 strix cloud scans start ...（详见 managed-pentesting-with-strix）。

适用边界 · 注意事项

• 用户尚未确认对目标资产拥有所有权或测试授权时不要运行。
• 没有 staging 环境且生产环境禁止触碰时，不要声称能证明漏洞可利用，只能做代码审查。
• 不要对所有资产一次性全量、最大深度地运行所有测试，应一次一个资产并逐份阅读报告。