攻击者在公共仓库投放恶意包时，普遍遵循几个套路。一是名称模仿，使用与流行包极为相似的拼写，利用开发者的输入错误。二是功能伪装，包确实实现了声明的功能，但在安装或导入时执行额外代码。三是版本抢先，通过发布大量高版本号让自动更新机制选中自己。四是生命周期脚本，利用包管理器在安装阶段自动执行脚本的机制，在依赖安装时就完成信息窃取。
恶意包在行为上往往有明显特征：读取环境变量并向外发送；读取本地配置文件如凭证目录和云平台配置；执行网络请求到不常见的域名；在安装脚本中下载并执行远程内容；混淆代码或使用压缩编码隐藏真实逻辑。这些行为在正常库中极少同时出现。
第一，禁止安装阶段的脚本执行。主流包管理器都提供了关闭生命周期脚本的选项，在不需要的生态中可以全局关闭。
第二，使用锁文件并固定版本与完整性哈希，避免自动解析到新发布的恶意版本。
第三，通过私有代理拉取依赖，在代理层做已知恶意包拦截和异常行为审计。
第四，对新增依赖做人工或自动审查，特别是体积很小但依赖关系复杂的包。
第五，在隔离环境中执行首次安装，避免在持有生产凭证的开发机上直接安装未知依赖。
第一，立即隔离受影响的环境，避免在网络中继续使用其中的凭据。第二，确定恶意包被引入的版本范围和时间点，统计受影响的项目与构建记录。第三，轮换在该环境中使用过的所有凭据，包括代码仓库、制品库、云平台和部署密钥。第四，检查是否存在恶意代码的持久化行为，例如新增的定时任务、启动项或修改过的构建脚本。第五，清理本地与远端缓存，避免后续构建再次拉取到同一版本。第六，排查制品库中是否已有被篡改的构建产物，必要时重新构建并重新发布。
包投毒难以完全避免，但可以通过降低安装阶段的执行权限、缩短恶意代码的存活窗口来控制影响。关键是把依赖安装视为一个需要防护的执行环节。
售后客服
企业微信
