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

胡帅 等: 产业研发视角下的开源软件供应链攻击问题研究                                                     2773


                    “人” (研发参与者) 维度从个体行为与组织互动的视角, 阐释了研发流程范式可能面临的安全威胁, 其挑战贯
                 穿从个体开发者      (安全知识、意识) 到团队协作         (沟通、信任), 直至系统层面        (工具链复杂性、治理模式) 的递进
                 结构  (详见表  2). 实践中, 开发人员普遍存在系统性安全知识匮乏               (STHD-01), 对常见漏洞、依赖管理及版本控制
                 风险的认知不足尤为突出. 此缺陷显著削弱了其识别软件供应链攻击                       (如恶意依赖注入) 的能力, 具体表现为无法
                 准确评估第三方依赖的安全性, 增加了引入恶意包或利用已知漏洞组件的风险. 若组织层面安全文化薄弱, 将安全
                 视为次要目标     (STHD-02), 则导致安全被边缘化、资源投入不足, 根本性弱化整体防护体系. 部分团队中, 开发人
                 员对集成安全流程存在抵触情绪            (STHD-03), 视其为发布进度的阻碍, 这在高压项目中尤为突出. 高压情境易诱使
                 开发人员有意忽略安全检查或仓促引入未经充分验证的代码/依赖, 从而直接引入安全缺陷                              (STHD-04), 为恶意代
                 码注入或篡改合法组件创造了机会. 未能与开发工作流无缝集成的安全测试                         (STHD-05) 易破坏开发连续性, 加剧
                 抵触心理. 安全与开发团队间的沟通障碍及信任缺失                 (STHD-06) 则进一步制约协作效率并阻碍安全措施的有效实
                 施. 大型研发环境中, 人员众多与工具链复杂化加剧了身份识别与访问控制挑战                         (STHD-07). 权限管理不善极易导
                 致开发账户或构建环境凭证泄露、滥用, 或被用于非法上传/篡改组件, 成为攻击者渗透供应链的关键跳板. 系统
                 复杂性亦增加了开发人员的认知负担              (STHD-08), 其不断扩展的安全边界常超出既有知识体系与工具支持能力,
                 导致问题恶化. 自动化安全工具          (尤其是集成于     CI/CD  流水线中的工具) 的误报问题        (STHD-09) 会削弱开发人员
                 信任, 干扰开发节奏, 降低工具实用效能. 此外, 研发流程              (尤其是强调快速响应与迭代的敏捷开发模式) 与传统集
                 中审批式安全治理机制之间的冲突被人为利用                 (STHD-10), 这一矛盾可能被蓄意利用, 从而引发测试逃逸等风险.
                 例如, 卡内基梅隆大学软件工程研究所            (Software Engineering Institute of Carnegie Mellon University, SEI) 发布的产
                 业案例研究    [59] 指出, 敏捷开发过程中常预设测试覆盖率阈值, 例如             80% (中国  GB/T 25000.51-2025  标准中要求企
                 业类型的项目, 核心模块覆盖率不得低于             90%, 普通模块覆盖率不低于       80%). 在实际交付项目中, 外包方为满足甲
                 方的合格率要求, 可能策略性地将易于通过的测试纳入达标范围, 而将复杂模块滞留于未覆盖的                               20%  中, 以此方
                 法来通过测试要求. 随着待办清单的持续积累, 相关安全问题可能被长期搁置甚至埋没, 最终为项目交付遗留技术
                 债与安全隐患. 若甲方能够借助          CI/CD  自动化工具尽早介入, 实时查看测试规划与具体内容, 则可在相当程度上
                 缓解此类风险. 该问题是在产业实践中以流程合规保障软件研发安全的隐性共识制约下所衍生的典型安全治理困
                 境, 具有重要的研究意义与实践代表性.
                    “事” (研发管理) 维度聚焦于软件研发流程中的安全治理挑战, 涵盖流程设计、测试整合、资源配置及组织协
                 同等关键环节, 其挑战呈现从基础流程规范              (定义、需求、规划) 到执行与协作机制            (协调、资源、测试实施), 直
                 至系统集成与治理       (自动化、环境、评估时机) 的递进结构            (详见表   2). 实践中, 缺乏明确的安全流程定义与标准
                 (PRCS-01) 导致角色间理解错位与执行混乱, 削弱了对恶意依赖识别等软件供应链攻击关键防护的协同基础. 安
                 全活动与文档审查流程脱节          (PRCS-02) 在快速迭代中易引发审计与溯源风险, 阻碍了供应链篡改事件的及时根因
                 分析. 安全需求来源混杂且管理标准不一             (PRCS-03) 显著增加统一治理难度, 致使依赖验证等           SCA  控制策略难以
                 有效落地. 研发流程规划常与可接受风险容忍度失衡                 (PRCS-04), 可能默许引入高风险依赖, 间接扩大           SCA  攻击
                 面. 研发方法的灵活性与安全控制需求间的固有冲突                 (PRCS-05)(如敏捷变更性与安全规范性) 进一步加剧管理矛
                 盾. 团队规模扩大或引入外部供应商时, 安全协调与责任界定困难                    (PRCS-06) 尤为凸显. 资源投入    (时间、经费) 不
                 足  (PRCS-07), 尤其在小型团队, 根本性制约安全实践, 致其常被优先级挤压. 快速交付节奏易诱发测试缺失与技
                 术债累积   (PRCS-08), 显著推高后期修复成本, 并因缺乏持续依赖扫描而增加未检出供应链漏洞的风险. 安全测试
                 的整合复杂性     (PRCS-09)(尤其在  DevOps 多变环境下) 阻碍其流程化执行. 安全措施碎片化              (PRCS-10) 导致缺乏
                 端到端管理. 流程自动化若不完备仍依赖人工干预                (PRCS-11), 易引入新风险. 自动化部署流程与安全审查机制未
                 有效结合   (PRCS-12) 极易导致未经审查代码上线, 直接放大恶意代码注入或篡改组件在供应链中传播的风险. 系
                 统过度一体化与资源共享         (PRCS-13) 虽提升效率, 却加剧权限模糊场景下的数据泄露威胁, 为攻击者横向移动提
                 供便利. 最后, 安全评估过度集中于开发后期            (PRCS-14) 具有显著滞后性, 大幅增加修复成本.
                    “物” (研发技术) 维度聚焦于产业软件研发的交付物、技术基础设施与工具链所面临的安全挑战, 其挑战源于
                 技术工具与快速演进的研发范式            (如自动化、分布式、云原生) 的适配性缺口, 并体现在依赖管理、攻击面控制、
   83   84   85   86   87   88   89   90   91   92   93