mcpField
R
reviewing-dependency-changes

reviewing-dependency-changes

github.com/bitwarden测试与质量16270 次安装今天更新
代码仓库

关于 reviewing-dependency-changes

用于审查代码变更中依赖项的 Bitwarden 技能，帮助审查者检查新增依赖、版本升级、锁定文件及依赖移除。其规则涵盖安全审批、迁移讨论和残留引用。

主要功能

  1. 01检查新增依赖及审批信号
  2. 02识别主版本升级与降级
  3. 03核对清单文件和锁定文件
  4. 04审查自动化依赖更新
  5. 05检查移除依赖后的残留引用

适用场景

  1. 01审查 PR 中引入的新依赖
  2. 02评估依赖主版本升级是否需迁移说明
  3. 03发现清单与锁定文件不一致
  4. 04确认依赖移除后代码无残留引用

安装

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

$npx skills add https://github.com/bitwarden/ai-plugins --skill reviewing-dependency-changes

安装后在 Claude Code 中输入/reviewing-dependency-changes确认已加载。

详细介绍

审查依赖项变更

清单文件检测

如果差异中出现以下任一文件，请标记此技能：

  • package.json、package-lock.json
  • *.csproj、Directory.Packages.props、packages.lock.json
  • Cargo.toml、Cargo.lock
  • go.mod、go.sum
  • requirements.txt、pyproject.toml、poetry.lock
  • Gemfile、Gemfile.lock

领域 1：新增依赖项

当 PR 添加代码库中之前不存在的依赖项时，Bitwarden 的依赖项审查与批准流程要求在集成前由 AppSec 审查并批准。这适用于所有新增依赖项——生产、开发和测试依赖项。

提交者必须提供软件包名称/版本、生态系统、理由、范围、受影响的产品以及它所替代的内容。安全工程师会在 Jira 中创建 VULN 任务，并从安全性（已知 CVE、可利用性）、许可证兼容性（MIT/Apache-2.0 等宽松许可证可接受；GPL/AGPL 等著作权左派许可证会被标记）、维护状况（活跃维护者、近期发布、安全策略）、供应链风险（拼写仿冒、所有权变更、混淆的安装脚本）以及传递依赖等方面评估该依赖项，然后作出批准决定。

检查内容
  1. 这是一个全新依赖项（代码库中之前不存在）吗？
  2. PR 描述中是否包含批准信号，表明已遵循相关流程？
批准信号

表明已遵循依赖项批准流程的证据：

  • PR 描述引用了 VULN 任务（例如，VULN-1234）
  • PR 描述明确提到 AppSec 批准或依赖项审查流程
严重性

当发出引用依赖项审查与批准流程的问题时，始终将流程名称链接到 https://bitwarden.atlassian.net/wiki/spaces/APPSEC/pages/2774466657/Dependency+Review+and+Approval，以便发布的审查评论能引导审查者查看权威文档。

  • 未发现批准信号 → ⚠️ 重要：新增了依赖项 <package>。Bitwarden 要求在引入新依赖项之前获得 AppSec 批准。提交者应联系 AppSec 团队，启动依赖项审查与批准流程。
  • 是否已获得批准尚不明确 → ❓ 问题：新增依赖项 <package> 是否已获得 AppSec 批准？
不应标记的情况
  • 代码库中已存在的依赖项（版本更新不属于新增依赖项）
  • Renovate/Dependabot 添加的传递依赖项更新（这些属于第 5 阶段对现有已批准依赖项的监控）

领域 2：主版本升级

主版本升级（例如，v2 → v3）可能引入影响 Bitwarden 代码库的破坏性变更。

检查内容
  1. 这是一次 SemVer 主版本变更吗？
  2. PR 描述是否讨论了破坏性变更或迁移步骤？
严重性
  • 主版本升级但未讨论迁移 → ❓ 问题：<package> 从 vX 升级到 vY（主版本）。是否评估过破坏性变更？
  • 版本降级 → ⚠️ 重要：<package> 正从 vX 降级到 vY。这并不常见，可能会重新引入已解决的漏洞。

领域 3：锁文件规范性

锁文件可确保构建可复现。清单文件与锁文件之间不一致，会带来构建可靠性和安全方面的问题。

检查事项
场景发现
清单已更改，但锁定文件未更新⚠️ 重要：锁定文件未更新，无法反映清单变更
锁定文件已更改，但清单未变更❓ 问题：锁定文件已更改，但没有对应的清单变更——这是有意为之吗（例如，npm audit fix）？
锁定文件已删除⚠️ 重要：删除锁定文件会破坏可复现构建
不要标记的情况
  • 清单仅有小幅变更，但锁定文件差异很大——这是正常现象。添加单个依赖项或升级版本都可能导致锁定文件发生显著变化。
  • 同一 PR 中伴随明确清单变更的锁定文件单独变更。

范围 4：自动化依赖 PR

Renovate 和 Dependabot PR 属于 Bitwarden 第 5 阶段（监控）流程的一部分。这些针对现有已批准依赖项的自动更新需要采用不同的审查方式。

如何识别
  • PR 作者：renovate[bot]、dependabot[bot] 或类似的机器人账号
  • PR 标题模式：“Update ...”“Bump ...”“chore(deps): ...”
审查指南
场景操作
对现有依赖项进行次要或补丁更新无需提出审批流程相关问题。重点检查锁定文件规范和 CI 状态。
机器人提交的主要版本升级按范围 2 标记——无论来源如何，主要版本升级都需要人工审查。
机器人 PR 引入了全新的依赖项按范围 1 标记——无论来源如何，新依赖项都需要经过审批流程。

范围 5：移除依赖项

从清单中移除依赖项时，请确认已彻底移除。

检查事项
  1. 代码中是否仍有对已移除软件包的引用？
    • JavaScript/TypeScript：import ... from '<package>'、require('<package>')
    • C#/.NET：using <namespace>、其他 .csproj 文件中的引用
    • Rust：use <crate>::、extern crate <crate>
    • Python：import <package>、from <package> import
  2. 构建或基础设施文件中是否有相关引用？
    • Dockerfile、docker-compose.yml
    • CI 工作流文件（.github/workflows/*.yml）
    • 构建脚本、Makefile、任务运行器
严重程度
  • 仍有未使用的导入或引用 → ♻️ 技术债务：<package> 已从清单中移除，但代码中仍有引用。

评论

支持 Markdown