问题——开源工具“被投毒”，镜像分发渠道成为放大器。 近期，安全研究人员在容器生态中发现异常：Docker Hub上与Trivy涉及的的镜像出现可疑版本标签，其中0.69.3被认为是最后一个已知的“清洁版本”。随后出现的0.69.4、0.69.5、0.69.6等版本被指包含与早期攻击阶段一致的妥协迹象，并已从镜像库删除。研究人员注意到，部分镜像标签被推送时并未同步出现对应的代码发布记录或版本标签，反常的发布节奏与内容差异，成为判断镜像可能被篡改的重要线索。事件再次提示，容器镜像仓库、自动化构建与发布链路一旦被攻击者利用，将对开发者环境形成“乘数效应”。 原因——凭据失守与自动化链路权限过大，促成“由点到面”的渗透。 从已公开的信息看，此轮风险的起点与Trivy供应链入侵相关。Trivy作为广泛使用的开源漏洞扫描工具，常被嵌入企业CI/CD流程中用于镜像与依赖项检测。攻击者被指通过被入侵的凭据，将凭据窃取程序植入木马化工具版本及相关自动化组件（包括部分GitHub Actions），从而在开发、构建、发布等关键环节获取更多令牌与密钥。 继续的取证分析显示，攻击者可能利用某服务/机器人账户的令牌获得跨组织的写入与管理权限。由于此类账户往往被用于自动化运维与持续集成，权限范围广、调用频繁，一旦令牌泄露，就可能成为攻击者横向移动的“通行证”。相关研究指出，攻击者疑似在短时间内以脚本化方式批量修改多个内部仓库设置并公开暴露，反映其具备较强的自动化攻击能力与组织级权限。 影响——从信息窃取到蠕虫扩散，再到“擦除器”针对性破坏，危害链条延伸。 本次事件的外溢效应值得高度警惕。研究人员称，攻击者利用窃取的数据进一步入侵多个下游组件与包生态，投放自传播蠕虫载荷，形成从“工具投毒—凭据窃取—扩散传播”的链式攻击。更值得关注的是，近期还出现具备破坏性的“擦除器”行为：相关载荷不仅尝试通过被盗密钥经SSH传播，还会在本地网络中扫描暴露的Docker API（如2375端口）并加以利用，体现出攻击者对云基础设施薄弱点的持续探测与武器化能力。 在对Kubernetes环境的攻击中，研究人员描述其通过在集群节点部署高权限组件来实施破坏，对特定地理或环境特征进行识别后采取差异化动作：部分节点被执行擦除并触发重启，非目标节点则可能被植入后门维持控制。对非Kubernetes主机，亦有报告称出现高危破坏命令。上述特征表明，攻击者的目标已从“窃取数据、获利变现”延伸至“破坏可用性、制造业务中断”，云原生环境一旦遭遇，将面临业务连续性与数据安全的双重冲击。 对策——从“版本锁定”到“最小权限”，把供应链风险关进制度与技术的笼子。 业内人士建议，组织应围绕CI/CD与容器供应链开展紧急排查与长期治理： 一是核查构建流水线中对Trivy及相关自动化组件的引用方式，避免继续使用存在争议或无法溯源的镜像与版本；对关键工具实行版本锁定与哈希校验，优先采用可验证来源的制品。 二是全面清点并轮换可能暴露的令牌、密钥与访问凭据，重点审计服务/机器人账户权限，落实最小权限原则，降低“一个令牌贯通多组织、多仓库”的系统性风险。 三是强化镜像与制品安全策略，在拉取、构建、部署各环节增加签名验证、来源准入与行为检测；对异常发布节奏、缺失发布记录等信号建立告警机制。 四是加固云原生基础设施暴露面，严控Docker API对外开放，关闭或隔离不必要的2375等高风险端口；对Kubernetes集群启用更严格的RBAC、准入控制与特权工作负载限制，减少特权DaemonSet等高危配置被滥用的空间。 五是完善应急预案与演练机制，针对“凭据泄露—横向移动—擦除破坏”场景建立快速止血流程，包括隔离节点、吊销令牌、回滚镜像、恢复备份与取证留存等。 前景——供应链安全正从“技术议题”走向“系统治理”，云原生时代更需共同防线。 当前软件供应链已深度嵌入研发与运维自动化流程，开源组件、镜像仓库与自动化插件共同构成现代生产体系的“基础设施”。此次事件显示，攻击者正在以更低成本撬动更大范围的生态影响，并把攻击能力从单点植入升级为跨平台、多阶段联动。未来一段时间，类似以令牌为入口、以自动化链路为通道、以云原生环境为目标的攻击或将更趋频繁。对企业而言，安全建设需要从“事后修补”转向“前置设计”，将可验证、可追溯、可审计作为供应链的基础要求。
供应链安全的核心是信任管理；当攻击目标转向开发工具和自动化流程时，任何细微变动都可能引发风险。企业不能仅依赖上线前的安全检查，而应将"来源可信、权限可控、行为可审、应急可回滚"融入全流程，通过制度化和工程化手段降低风险，确保数字化生产的安全稳定。