ci/cd中自动化依赖检查的核心是将哈希校验嵌入构建流程，强制pip install --require-hashes、npm ci、maven lock验证，并集成漏洞扫描阻断高风险构建，切断不可信源，监控异常依赖变更。
CI/CD 中的自动化依赖检查，核心不是“扫出漏洞就报警”，而是把验证动作嵌进构建流程里，让不安全的依赖根本走不到打包那步。
在构建前强制校验依赖完整性
只锁版本远远不够——攻击者可以上传同名恶意包到 PyPI 或 npm registry。必须校验每个包的哈希值。
- Python 项目用
pip-compile --generate-hashes生成带--hash=sha256:xxx的requirements.txt，CI 中执行pip install --require-hashes -r requirements.txt，任何哈希不匹配都会失败 - Node.js 项目启用
npm ci（而非npm install），它严格比对package-lock.json，跳过node_modules缓存和package.json解析 - Maven 项目配置
maven-dependency-plugin的dependency:lock目标，生成并提交dependency-lock.xml，CI 阶段启用-Dmaven.dependency.lockFile=dependency-lock.xml
集成漏洞扫描并阻断高风险构建
扫描工具要运行在代码拉取后、编译前，且结果必须影响流水线状态。
- GitHub Actions 示例：添加
pip-audit -r requirements.txt步骤，发现 CVE-2024-1234 等严重漏洞时自动失败 - Java 项目在 Maven 生命周期的
verify阶段集成 OWASP Dependency-Check：mvn org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7.0 - 避免仅“记录告警”：所有扫描任务需设置
failOnError: true或等效参数，确保中危以上漏洞无法绕过
切断不可信来源的依赖路径
默认信任官方源是最大误区。CI 环境必须显式限定依赖来源，并禁用动态覆盖行为。
- 禁止在 CI 脚本中执行
pip install .或npm install <git-url></git-url>这类绕过锁文件的操作 - Docker 构建中，
RUN pip install前必须加--index-url https://your-internal-pypi-proxy/simple/ --trusted-host your-internal-pypi-proxy - 删除
.npmrc或pip.conf中的registry=覆盖配置，统一由 CI 环境变量控制源地址
监控依赖变更并识别异常模式
自动化检查不仅要防已知风险，还要发现“不该出现的变化”。
- 对比每次 PR 的
package-lock.json或requirements.txt，检测是否新增了未评审的依赖（如突然引入requests-mock） - 记录依赖树深度与节点数，若某次构建依赖数量激增 300%，触发人工复核
- 对低下载量（npm 1 年）、无签名的包自动标记为“高风险”，禁止进入主干构建
