用途
该技能用于对软件项目执行严格的供应链安全卫生（Supply Chain & Security Hygiene），帮助开发者在部署前或任何依赖更新后审计依赖、检测风险、最小化攻击面。其核心原则是：每个依赖都是一扇不是你建造、由你不认识的人维护的门。技能引用了 litellm PyPI 供应链攻击事件作为背景，指出广泛使用的 LLM 库可能通过其传递依赖被攻破，而项目可能直到为时已晚才意识到 litellm 存在于自己的技术栈中。
主要能力
-
完整依赖审计：针对 requirements.txt / package.json / Gemfile / go.mod 中的每个直接依赖，分析维护者健康度（是否单一维护者、最后提交时间、GitHub stars）、传递依赖深度、安装时是否执行任意代码、导入时是否触发外部网络连接、版本锁定方式（精确版本还是范围），并给出 HIGH / MEDIUM / LOW 风险评级与优先修复动作。
-
安装前 5 分钟快速检查：在添加任何新包之前，检查 PyPI/npm 周下载量、GitHub 仓库的 stars、最后提交、未解决问题、传递依赖深度、setup.py / postinstall 是否在安装时运行代码、导入时的实际行为，并给出 SAFE / VERIFY_FURTHER / AVOID 的风险判定，以及更安全的替代方案或自行实现建议。
-
requirements 文件加固：将宽松的依赖文件转换为锁定且经过审计的版本，要求所有包固定到精确版本（== 而非 ~=），为每个包添加用途注释，标记可低成本移除的包，按 core / dev / testing 分组，并添加包含最后审计日期、依赖总数、审计命令的头部注释。
-
最小依赖哲学评估：在通过包添加功能前，评估是否可以用 Python 标准库在 50 行以内实现，或用一个可内联粘贴的简单函数实现；若可以则给出最小实现，若不可以则确认该包是正确选择并建议最安全的导入方式。
-
容器化与隔离模板：提供 Dockerfile 模板，包括固定精确基础镜像、创建非 root 用户、仅先复制 requirements 以利用层缓存、使用 --require-hashes 进行哈希校验安装、以非 root 用户运行，并展示带哈希的 requirements.txt 写法（通过 pip-compile --generate-hashes 生成）。
-
供应链事件响应清单：分为立即（1 小时内）识别受影响版本、检查是否在依赖文件与运行服务中、隔离可能暴露凭据的服务；短期（24 小时内）轮换凭据与令牌、审计可能被访问或外泄的数据、更新到安全版本或移除包、扫描其他包；长期添加自动化扫描（pip-audit、npm audit、Dependabot）、对关键项目实施哈希锁定、考虑彻底消除该依赖。
-
扫描命令参考：Python 使用 pip-audit、pip freeze | pip-audit --stdin、safety check；Node.js 使用 npm audit、npm audit fix；检查传递依赖使用 pip show、pip-tree；生成哈希 requirements 使用 pip-compile --generate-hashes。
使用方式
该技能属于“想法到上线”工作流的第 4 步（安全检查），上游为 karpathy-minimalism（瘦身后），下游为 karpathy-vibe-to-agentic（最终收尾）。完整链路为：idea-files → agentic-engineering → minimalism → supply-chain-hygiene → vibe-to-agentic。使用时通过 Prompt Contract 提供包名与版本，要求产出：传递依赖数量与树、维护者活动（最后提交、巴士因子）、已知 CVE 或安全公告、postinstall 钩子或导入时网络调用、更安全的最小替代方案（或“用 N 行自行实现”）、批准后的锁定安装命令，并给出 LOW/MEDIUM/HIGH 风险评分与 USE/AVOID/IMPLEMENT_YOURSELF 建议。
适用场景
适用于任何拉取外部依赖的软件项目，尤其是在部署前、依赖更新后、引入新包前，以及发现供应链被攻破时进行应急响应。
限制
资料未提供该技能的具体运行环境、支持的编程语言范围之外的细节、收费或价格信息、实际效果数据，也未提供官方文档或安装命令。验证清单要求所有依赖有 pinned version、已检查传递依赖数量、无 postinstall 钩子或已审查其内容、单一维护者的包已标记风险、对高风险依赖提供自实现替代方案、lockfile 已提交到仓库。