技能介绍

为什么需要对抗性安全门禁

当你给 Agent 开放读取本地文件、运行脚本或发起网络请求的权限时，实质上是在部署一个能力极强但缺乏责任感的数字员工。传统安全扫描依赖单一启发式规则，模型同时承担“发现者”与“判定者”角色，容易导致自我锚定——把热点抽样当作完整审计，甚至在缺乏证据的情况下悄悄降低漏洞等级。本技能旨在解决这一痛点，通过分离扫描与判定逻辑，拒绝任何无据可依的结论。

五层攻击面与判定机制

本技能将审计流程拆分为扫描层与对抗性判定层。扫描层对照以下五个维度进行逐项排查：

隔离：验证部署是否进入 Docker 沙箱，并强制开启 --network none 或 --read-only 等硬限制。
网络：检查出站连接是否默认拒绝，以及是否配置了白名单与内部 DNS 解析器。
供应链：审查依赖安装是否设置了冷却期（如 pnpm minimumReleaseAge），并使用锁定版本。
MCP：确认外部服务是否进行了哈希比对，确保配置变更能触发阻断重审。
凭证：扫描硬编码密钥，验证是否使用了短期令牌或凭证代理。

扫描器仅输出原始信号，随后进入对抗性判定层：

证据收据：每条发现必须附带 evidence（文件、行号、片段），否则一律标记为 NEEDS_REVIEW。
防洗钱门：High 级漏洞禁止静默降级。若要降级，必须通过 --concur 参数显式确认，并提供完整的降级理由。
完整性门：扫描前先枚举所有配置文件（如 Dockerfile、.env）。若存在未覆盖的配置面，报告将直接标记为 report_blocking，禁止输出“安全”结论。

适用场景与注意事项

该技能适用于部署 Agent、接入 MCP 服务或自托管 AI 应用前的合规检查。请注意，它不替代人工代码审计，而是提供一套标准化的校验清单。运行前建议先通过质量门禁，再执行此安全检查。若报告出现 requires_concur 标记，意味着系统要求你必须介入人工确认，不要试图通过修改脚本参数来绕过安全限制。