风险常来自间接依赖
现代应用大量使用开源包，一个直接依赖又会引入多层间接依赖。开发者只修改了一个版本号，锁文件里可能发生数十项变化，其中可能包含已知漏洞、不兼容许可证或来源异常的组件。等问题进入生产后再修复，成本通常更高。
依赖审查应进入拉取请求流程，对新增、删除和升级项生成差异，识别已知漏洞及许可证风险。对于达到设定严重等级的问题，可让 CI 检查失败并阻止合并。锁文件必须纳入版本控制，避免不同环境解析出不同依赖树。
建立持续治理机制
团队应维护软件物料清单，开启漏洞告警和自动升级，但自动生成的升级请求仍需测试。更新策略可按风险分级：安全补丁快速处理，主版本升级经过兼容性评估。长期无人维护、下载来源不明或安装脚本权限过高的组件，应谨慎引入。
构建环节还要保护 CI 凭据、固定工作流依赖版本、对制品生成校验或签名，并确保生产部署使用经过验证的同一制品。供应链安全不是一次扫描，而是从选包、评审、构建到发布的全过程控制。
参考资料：https://docs.github.com/en/code-security/concepts/supply-chain-security/dependency-review