Page 103 - 《软件学报》2026年第7期
P. 103

2788                                                       软件学报  2026  年第  37  卷第  7  期


                 链攻击行为的系统分析, 并结合本文筛选的学术文献及                  67  篇产业报告   (表  1  所示) 中的典型案例, 本文构建了开
                 源软件供应链攻击模型        (表  7  所示). 本文通过  3  轮深入的研讨与评审, 最终确定了        16  起具有代表性的开源软件供
                 应链攻击事件. 如表      7  所示, 攻击过程可划分为     3  个关键阶段: 开源共建威胁产生、产业闭源研发攻击演化传播和
                 成品使用攻击发作. 该模型不仅清晰地展现了攻击的时序演进路径, 还系统揭示了各阶段采用的细分技术手段及
                 其内在关联.
                    如表  7  所示, 在“开源共建阶段”, 攻击者主要通过社会工程             (A1)、伪装成流行项目      (A2)、代码混淆    (A3) 或直
                 接发布恶意项目      (A4) 等手段, 向开源仓库     (如  PyPI、npmjs) 注入恶意代码. 例如, “XZ-Util”事件中, 攻击者结合
                 A1  与  A2  手段, 逐步获取维护权限并植入后门; “yandex-travel/ui@1.1.0”则通过伪装合法包        (A2) 诱骗开发者引入.
                 此类行为污染了开源生态的原始素材, 为后续传播奠定基础.
                    进入“产业闭源研发”阶段,恶意代码借助依赖攻击                  (S1)、误拼写包名    (S2)、劫持官方资产      (S3, 包括开发者
                 账户、DNS、代码库、容器等) 或篡改研发流水线产物及利用 CI/CD 工具链漏洞                       (S4) 等方式,渗透至企业开发
                 环境与构建流程. 例如, “IconBurst”通过误拼写包名       (S2) 渗透下游应用依赖链; “OneinStack”则通过劫持官方资产         (S3)
                 实现传播. 这一阶段的关键在于利用产业界对开源组件的高度信任和自动化集成机制, 实现恶意代码的横向扩散
                 与深度嵌入.
                    最终, 在“成品使用”阶段, 恶意代码通过安装脚本              (I1)、子组件安装配置      (I2) 或 IDE 脚本  (I3) 等机制在用户
                 环境中激活, 并执行      SaaS  服务攻击  (E1)、数据泄露   (E2)、多阶段攻击     (E3)、隐秘 API 调用  (E4)、后门驻留    (E5)
                 或反向 Shell (E6) 等恶意行为. 例如, “fsevent”包通过安装脚本       (I1) 触发恶意行为, 并进一步实施数据泄露           (E2);
                 “Discord-Token-Generator”则通过 GitHub 传播, 实施多阶段攻击  (E3) 与反向  Shell (E6).
                    综上所述, 攻击者利用开源软件供应链“自我反噬”的安全缺陷, 已形成从源码污染到构建传播、再到终端执
                 行的完整链条. 3    个阶段中采用的细分技术在研发效能提升的“自我强化”下相互衔接、逐级放大, 正是利用了现代
                 产业研发中的以流程合规保障软件研发安全隐性共识, 隐匿的完成攻击. 例如, 在                        XZ 事件中, 攻击者针对的目标
                 是欠维护但具备广泛传播能力的 XZ 项目, 它被例如 Ubuntu、Debian              等多款企业级     Linux  系统所依赖, 攻击者在
                 长达  3  年的攻击、传播实施中采用了社工攻击、代码混淆、依赖攻击、多阶段等多种复杂的软件供应链攻击方
                 法, 最终被微软的研发人员所发现. 时至今日仍有大量被污染的                   XZ  相关镜像存在于     DockerHub  中, 这凸显了开源
                 软件虽然强化了产业软件的能力, 但同时攻击者可以沿着相同的路径, 对开源社区, 产业研发以及下游用户进行攻
                 击, 最终反噬软件供应链与产业研发生态. 未来需构建覆盖全链路的动态安全防护机制, 尤其加强对开源组件来源
                 验证、CI/CD  流程中组件变动的管控, 特别是针对系统的运行时行为监控来达到安全再平衡的目的.
                  5   基于产业研发视角的软件供应链安全再平衡

                    在研发效能的不断“强化”下, 非法的攻击者利用开放的社区成为合法的贡献者, 被污染的组件在产业软件依
                 赖下被包装成为产业组织信用背书的流行企业软件, 自动化流水线的使用让研发态的威胁快速传入了成品阶段,
                 这形成了一体两面无法解决的内生矛盾, 只要能成功利用暴露面众多的软件供应链体系, “自我反噬”的安全威胁
                 就在所难免. 在产业数字化进程频频受扰的当下, 软件供应链安全不再是一道可选项, 一体两面的内生矛盾是在研
                 发组织流程合规的产业隐性共识下所产生的, 因此应该直面问题, 在开源共建、产业研发与成品使用的链路中, 建
                 立主动暴露风险的安全机制. 邬江兴院士曾提出以拟态防御思维                     (https://www.edu.cn/info/media/yjfz/qyjs/201612/
                 t20161215_1476207.shtml) 应对网络空间中不可预知的安全威胁. 既然无法预判未知的未知, 无法完全阻止攻击,
                 那就让攻击的成本更大, 发现的时机更靠前. 通过化整为零、大模型智能化主动感知自动修复的方式伴随研发流
                 程, 降低安全发现成本, 让安全研发不再是被动的流程妥协, 实现攻防之间的再平衡.
                  5.1   在开源共建阶段进行协同治理与代码异常检测
                    为应对开源生态在供应链早期阶段所面临的安全威胁, 现有技术路径主要体现于两个层面: 一方面是开源项
                 目安全治理机制, 通过组织协作与制度建设提升整体生态的风险协同防控能力; 另一方面是开源代码分析与检测
   98   99   100   101   102   103   104   105   106   107   108