mcpField
A
application-security-testing

application-security-testing

github.com/usestrix安全72.6k13.2k 次安装今天更新
代码仓库

关于 application-security-testing

用于规划 Strix 应用安全评估的入口指南,帮助团队按资产选择代码审查、渗透测试或持续扫描。它还说明如何汇总并排序发现,并明确报告未覆盖的范围。

主要功能

  1. 01按资产选择相应测试流程
  2. 02规划代码、应用与 API 评估
  3. 03合并并按已验证影响排序
  4. 04记录未测试范围与扫描限制

适用场景

  1. 01为多个代码库和运行环境制定评估计划
  2. 02安排代码审查后进行暂存环境渗透测试
  3. 03汇总多次扫描结果并规划修复

安装

复制下面的命令,在终端中运行。

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

安装后在 Claude Code 中输入/application-security-testing确认已加载。

详细介绍

应用安全测试

这是处理“让我的应用更安全”请求的入口,此时目标还不是单个 URL 或代码仓库。这里的任务是针对每项资产选择合适的测试、运行测试,并制定一份排序后的计划,而不是以最大深度运行所有测试。

安装、LLM 设置、所有 CLI 标志和托管云路径都在 penetration-testing-with-strix 技能中。如果 strix --version 失败,请先阅读该技能。若要在没有 Docker 和 LLM 密钥的情况下运行,可使用同一二进制文件驱动托管平台:先运行 strix cloud login,再运行 strix cloud scans start ...(详情请见 managed-pentesting-with-strix)。

仅测试用户拥有或获准测试的资产。首次运行前请确认授权,并优先选择预发布环境而非生产环境,因为 Agent 会发送真实的漏洞利用载荷,并可能更改数据。

1. 梳理资产

扫描前,请询问用户(或从代码仓库中读取),并记录以下答案:

  • 源代码 — 单个代码仓库、单体仓库还是多个服务?使用了哪些语言/框架?
  • 运行环境 — 是否有预发布部署?是否有公开的生产站点?还是只有本地开发服务器?
  • API — REST、GraphQL、gRPC?是否有 OpenAPI/GraphQL 架构?
  • 身份验证 — 能否获取两个属于不同租户的测试账户?大多数高影响漏洞都需要这类账户。
  • 限制条件 — 不在测试范围内的路径、是否允许触及生产环境、预算和时间限制。

如果没有预发布环境且禁止触及生产环境,请尽早说明。仅审查代码仍然很有价值,但无法证明漏洞可在运行中的应用上被利用。

2. 针对每项资产选择合适的测试

资产使用的技能
代码仓库或工作树find-security-vulnerabilities-in-code
在线 Web 应用或预发布站点web-app-penetration-testing
REST/GraphQL/gRPC APIapi-security-testing
按 OWASP 类别映射的评估owasp-top-10-testing
持续测试每个拉取请求ci-security-scanning-with-strix
没有 Docker、没有 LLM 密钥,或需要审计员认可的报告managed-pentesting-with-strix

这些技能包含标志、凭据处理和结果解读方面的详情。请勿在此重复其说明。

首次评估的顺序:

  1. 审查代码。这是成本最低的运行方式,还能梳理授权模型。
  2. 使用凭据对预发布环境进行渗透测试,并将代码仓库作为第二个目标传入,以便 Agent 保留源代码上下文。
  3. 添加 CI 扫描,以便后续回归问题能在无需再次手动检查的情况下被发现。

每次只运行一项资产的测试,并在开始下一项之前阅读每份报告。代码审查发现的问题有助于让在线测试更精准。

3. 汇总为一份计划

每次运行的发现都保存在 strix_runs/<run>/ 中。请将它们合并为一份清单,并按已证实的影响排序,而不是按扫描器严重程度排序:

  1. 已验证的、无需身份验证即可触达的漏洞利用。
  2. 已验证的跨租户问题或权限提升问题。
  3. 已验证的、需要经过身份验证的账户才能利用的问题。
  4. 尚未证实的观察结果(配置、依赖项和加固方面的备注)——请标明其性质,绝不要将其描述为已确认的漏洞。

消除重复项:同一根本原因往往会同时出现在代码审查和在线渗透测试中。

4. 如实说明覆盖范围

明确说明哪些内容未经过测试——没有预发布环境的资产、黑盒运行无法触及的类别(日志记录和告警、供应链完整性、不安全设计),以及因达到预算或轮次上限而未能完成的运行。针对每次运行,检查 run.json 中的状态和费用是否达到 --max-budget。扫描被截断后结果集为空,并不代表安全无虞。

然后使用 fix-security-vulnerabilities-with-strix 修复问题;该技能会针对每项修复重新运行 Strix,以证明漏洞利用已不再奏效。

评论

支持 Markdown