用途
该技能用于管理软件的第三方依赖，覆盖选择、锁定、审计、更新与移除的完整生命周期。资料将其定位为“生产纪律”：第三方依赖既是现代软件最强大的部分，也是最危险的部分，并以 log4shell、left-pad（11 分钟内拖垮数千个构建）以及依赖混淆供应链攻击作为背景说明。
适用场景：
- 判断是否新增一个依赖
- 版本锁定策略（精确锁定 / 范围 / 仅锁文件）
- 搭建自动更新工作流（Renovate、Dependabot）
- 使用 npm audit、pip audit、Snyk、Socket.dev 做安全审计
- 许可证合规扫描（MIT/Apache/GPL 兼容性）
- 生成软件物料清单（SBOM）
- 解决 peer dependency 冲突与 npm overrides
- 响应安全公告与 CVE
- 检测拼写抢注与依赖混淆攻击
不适用场景：内部 monorepo 包管理（改用 monorepo-management）、向 npm/PyPI/crates.io 发布自己的包、依赖管理之外的包管理器配置（如 workspace 配置）、vendoring 与隔离环境（资料说明其存在但超出范围）。
主要能力
依赖引入决策
资料给出一套判定流程：替换代码少于 20 行则自行实现；20–200 行且实现正确无难点（纯逻辑）则自行实现，涉及边界情况、locale、时区则进入审计；超过 200 行则先审计。审计维度包括周下载量（< 1 万为高风险，1 万–10 万需持续关注，> 10 万再看维护状态）、最近提交时间（超过 2 年考虑 fork 或替代）、许可证兼容性（专有项目遇到 GPL 直接拒绝，MIT/Apache 2.0 可接受）、安全扫描（存在未修复 CVE 则拒绝）、传递依赖数量（新增超过 50 个需重新考虑）。
版本锁定策略
Semver 语义：^1.2.3 允许 minor 与 patch 更新；~1.2.3 只允许 patch；1.2.3 精确锁定；* 永不使用。建议：生产应用对直接依赖使用精确锁定，由锁文件管理传递依赖；对外发布的库使用波浪号；插入号仅用于开发工具；所有生产环境以锁文件为准（npm ci、pip install --frozen、cargo build）。资料强调，semver 是理想而非强制，minor 版本也常带破坏性变更；CI 若用 npm install 而非 npm ci 会静默升级。
更新工作流
可选手动（每月 npm outdated / pip list --outdated）或自动化：GitHub 仓库用 Dependabot（.github/dependabot.yml），跨平台用 Renovate（renovate.json，功能更强）。可选择按类型分组更新（如开发依赖 patch、生产依赖 minor），仅对开发依赖 + patch 开启自动合并并设置测试门禁，生产依赖与主版本更新需人工评审。
安全审计
建议按由快到深依次运行：npm audit（含 --audit-level、audit fix，--force 需先评审）；pip-audit（含 --fix）；Socket.dev（npx socket check，分析 CVE 之外的行为与拼写抢注）；Snyk（test / monitor）；SBOM 生成（cyclonedx-npm、cyclonedx-bom）。资料反对忽略安全公告：开发依赖可通过构建工具或实际进入生产包两种方式影响生产，可用 npm audit --production 与 npm ls <package> 追溯依赖链；真正仅开发用途的包可延后 moderate 级别公告，但 critical/high 即使位于开发依赖也应纳入 SLA，且“无风险”应记录为评估结论而非跳过。
供应链安全
拼写抢注常见形式包括 lodash → 1odash（数字 1 替代字母 l）、express → expres、react → React（大小写敏感的注册表）、@org/package → org-package（作用域混淆）。可用 npx socket check 检测，或用 npm view 核对作者、描述与仓库地址。依赖混淆指攻击者发布与私有 @org/package 同名的公开包且版本号更高，从而使包管理器拉取公开包；防护方式是在 .npmrc 配置作用域 registry（如 @your-org:registry=...），或用 overrides/resolutions 锁定来源。锁文件完整性方面：不要提交 node_modules，只提交锁文件；CI 使用 npm ci（锁文件与 package.json 不匹配即失败），绝不使用 npm install；Python 可用 pip-tools 的 pip-compile 与 pip-sync 实现确定性锁定。
许可证合规
给出兼容性矩阵：专有项目对 MIT 依赖 OK，Apache 2.0 依赖 OK（需署名），LGPL 依赖 OK（动态链接），GPL 依赖拒绝；MIT/Apache 项目对 GPL 情况复杂；GPL 项目则全部 OK。扫描工具：npx license-checker（--onlyAllow、--failOn）与 pip-licenses。
过度依赖的反模式
资料以 is-odd（周下载 5400 万，核心逻辑仅一行 n % 2 !== 0）为例，指出每个生产依赖都是 CVE 载体、供应链攻击面、semver 冲突源与认知负担。建议添加前自问核心功能是否少于 20 行；日期处理、字符串工具与数学运算自行编写，本地化、密码学、协议解析使用成熟库。检测方式包括 npx cost-of-modules 或查看非平凡领域中体积小于 10KB 的包。资料也提到 2024 年 polyfill.io CDN 被篡改事件说明该问题同样适用于 CDN 依赖。
overrides 与 peer dependencies
当直接依赖未更新而传递依赖存在漏洞时，可用 npm overrides（npm 8.3+）强制最低版本、精确版本或针对特定父包的作用域覆盖，yarn/pnpm 使用 resolutions。资料提醒 overrides 可能破坏确实依赖旧 API 的包，添加后必须运行测试。查看 peerDependencies 可用 npm info <package> peerDependencies；npm 7+ 会自动安装 peer 依赖，--legacy-peer-deps 是最后手段；遇到 peer 依赖警告不要静默，它可能意味着会在运行时产生隐蔽失败的版本不匹配，应通过锁定共同 peer 到兼容版本来解决。
使用方式与参考文件
资料给出 CLI 命令示例，包括 npm audit 系列、pip-audit、socket check、snyk test/monitor、cyclonedx 生成 SBOM、npm ci、pip-compile/pip-sync、license-checker、pip-licenses、npm view、npm info 等。另有两个参考文件：references/update-strategies.md（Renovate 与 Dependabot 配置细节、分组策略、自动合并策略与安全测试更新 PR）和 references/security-auditing.md（npm audit / Snyk / Socket.dev 深入、SBOM 生成、许可证扫描工具与 CI 集成模式）。
限制
资料明确列出超出范围的内容：内部 monorepo 包管理、发布自有包、依赖管理之外的包管理器配置、vendoring 与隔离环境。此外，具体价格、性能基准、平台兼容列表等事实资料暂未提供。