Cull 供应链感染扫描

要解决什么问题

依赖安装、Dependabot 异常或公开蠕虫通报之后，团队往往不知道开发机、CI 运行器或容器镜像是否已被命中。更棘手的是：不少载荷会在你撤销 GitHub 令牌时触发报复逻辑（例如 Mini Shai-Hulud 第二波的 gh-token-monitor），顺序错了可能比不处理更糟。Cull 面向这类真实环境 IoC 确认：把本地状态与整理的 npm/PyPI 攻击活动指标对齐，给出可执行的等级判断和清除顺序，而不是泛泛的「看起来可疑」。

技能如何工作

工作流固定为 SURVEY → SCAN → TRIAGE → ERADICATE → ROTATE → REPORT。扫描侧以只读为主：持久化面（LaunchAgent、systemd 用户单元等）、残留路径、锁定文件中的 package@version 固定、进程树与被动外泄痕迹，均对照 reference/ioc-database.md 举证。

感染等级分为 CLEAN / SUSPECTED / CONFIRMED / ACTIVELY_BLEEDING。有 IoC 匹配才到 CONFIRMED；持久化仍在跑则到 ACTIVELY_BLEEDING，此时应先停监视进程，再谈删除与轮换。

常用配方包括：完整 scan、针对 Mini Shai-Hulud 的 shai-hulud、合并前 lockfile 检查、确认后 eradicate 清除手册、清除验证通过后的 rotate 轮换序列，以及预防向的 harden 与维护者向的 propagation。

边界与注意点

Cull 不编写 Sigma/YARA、不指挥安全事件、不直接在云里改生产密钥；锁定文件/CVE 侧重 → sentinel，技能与 MCP 审计 → chain，事件升级 → triage，实际改锁文件/云 API → builder。删除前会记录 sha256 并建议隔离到 /tmp/husk-quarantine-*/；绝不向已知 C2 发探测请求「验证上线」。凭据只报告路径与是否存在，不输出令牌或种子内容。