Page 107 - 《软件学报》2026年第7期

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

IaC 已成为现代 DevOps 的核心实践, 但大量实证研究表明 IaC 工具链和脚本本身存在安全短板. War 等人 [180]
对超过 1 600 个 IaC 仓库的分析显示, 源代码、依赖项和清单文件普遍存在漏洞, 覆盖 OWASP Top 10 几乎全部
类别, 其中配置错误、访问控制失效及硬编码密钥尤为突出; 声明式配置文件 (如 YAML/JSON) 是攻击重点. 此
外, 许多缺陷源于跨角色操作的误用, 例如开发者修改网络配置或运维人员调整认证逻辑, 若安全测试工具 (如
Snyk、Horusec) 未系统性集成于 DevOps 流程中, 漏洞可能在多个版本间长期存在. Zeini 等人 [181] 指出, 当前组织
普遍缺乏系统性的 IaC 风险管理框架, 对配置失误、自动化脚本变更及权限滥用缺乏持续监控, 超过 60% 的云安
全事件可归因于手动修复行为, 凸显了 IaC 生命周期中“非计划性”操作的高风险.
为系统化应对 CD 阶段的威胁, 产业界和学术界提出全链路纵深防御方案. 在部署前阶段, 可利用静态分析工
具 (如 Checkov、Snyk IaC) 检测过度授权、未启用加密等配置风险, 并通过 OPA (open policy agent) 对 IaC 脚本
进行策略合规性验证; 在产物管理层面, 结合 Sigstore 提供的 Cosign 与 Rekor 对容器镜像及模块实现签名溯源; 在
运行时环境中, 通过 Kubernetes 准入控制机制 (如 ValidatingAdmissionWebhook 和 PodSecurity 标准) 对资源请求
进行动态审查, 防止未签名或异常配置的资源进入生产环境; 在凭据管理上, 引入集中式密钥管理平台 (如 AWS
Secrets Manager), 实现 API Token 和 SSH Key 的动态注入与最小授权 [182] . 此外, 部署完成后需关注配置漂移问题,
通过 Drift Detection 工具与持续审计手段监控容器弹性伸缩、手动干预等引起的实际状态偏离, 确保系统与 IaC
描述保持一致, 形成可追溯、可验证的安全部署闭环 [181] .
综上所述, DevSecOps 在持续交付与部署阶段强调多层次、防御纵深的安全策略, 通过流水线拆解与权限隔
离、IaC 脚本分析与配置合规性验证、产物签名溯源与运行时动态审查, 以及凭据管理和配置漂移监控, 形成全
生命周期、可追溯、可验证的安全闭环. 这种系统化防护不仅有效降低了部署阶段的攻击面与风险暴露, 还确保
了自动化、敏捷交付流程中安全目标的持续实现, 为产业环境中的软件供应链提供了坚实的安全保障.
5.2.2 产业闭源研发中的攻击面收敛
● 内源软件研发机制. 开源软件虽被广泛采用, 但在产业环境中其安全性与可靠性仍存在潜在风险 [183] . 为系
统性地应对这一挑战, 产业界不仅需建立严格的外部开源软件采纳评估机制, 还应构建内源软件研发机制 (inner
source software development, ISSD), 将开源软件转化为组织内部可控的研发资产 [184] . ISSD 通过建立内部研发社
区, 使不同团队和部门能够共享知识、复用软件组件并协同开发, 从而提升组织创新能力及软件供应链的整体安
全性.
在实施层面, 产业界可对关键开源软件进行内源化改造, 将其纳入内部研发体系, 通过二次开发与定制满足组
织特定安全需求, 同时增强对软件生命周期的掌控. 例如, 在对开源 Web 框架进行内源化改造时, 可嵌入自定义安
全模块, 以强化访问控制、输入验证和漏洞防护. 内源研发机制不仅提高了软件开发过程的可控性, 还强化了版本
管理、安全策略执行及风险缓解能力, 使组织能够依据自身安全标准和业务需求对软件进行灵活调整, 从而降低
因开源软件供应链风险引发的潜在安全隐患.
此外, 产业组织应建立安全情报仓库, 持续从内部代码仓库、漏洞报告及外部威胁情报中积累安全知识, 并通
过构建安全知识图谱辅助开发人员识别和管理开源组件带来的安全威胁 [185,186] . 这一机制增强了对内源化软件的
安全监控能力, 并为 DevSecOps 流程中各阶段提供数据支持和决策依据, 从而在内源软件研发与持续集成/持续部
署与持续交付过程中形成系统化、安全可控的防护闭环.
● 安全灰度撤销机制. 企业应当建立安全灰度发布机制. 在渠道方面, 建立可熔断的恢复发布渠道, 新版本先
在灰度环境推送, 通过行为基线比对 (syscall 序列、网络连接资源占用), 让攻击者的行为暴露, 最终决定是否推送
给全量客户. 此外建立构建以及部署阶段的组件签名验证机制, 一旦发现签名与官方的不一致, 即阻止流水线的运
行或者系统的部署. 避免下游用户大规模的成品感染.
综上所述, 内源软件研发机制与安全灰度撤销机制管控了开源软件进入企业的入口以及产业组织交付成品的
出口. 这不仅提升了软件开发过程的安全性和可控性, 还通过内部研发社区促进团队协作、知识共享与组件复用,
从而增强组织创新力和供应链韧性. 结合安全情报仓库和安全知识图谱, 产业组织能够在开发、集成和部署各阶