运营现代化转型将进一步提升软件供应链安全需求

F5生态系统 | 2022年5月12日


如今,软件供应链安全受到威胁已不足为奇。首先,log4j漏洞引发广泛关注,促使各方紧急采取措施,缓解这一普遍存在且棘手的软件供应链漏洞。

最近,Spring4Shell进入了我们的视野。这是又一个由框架引入的漏洞,给需要应对这一威胁的企业带来了混乱。

因此,看到GitHub推出新功能来加强软件供应链安全,多少令人感到欣慰。尤其是在读完Sonatype最新发布的《软件供应链现状》报告后,更是如此。报告中的统计数据足以让任何关注安全的技术人员警醒,无论其担任何种职务。值得注意的是:

  • 目前已有3,700万个OSS组件版本可用
  • 29%的热门项目包含至少一个已知安全漏洞
  • 针对开源供应商的网络攻击同比增长650%

这些发现尤其令人担忧,因为报告指出,“现代应用平均包含128个开源依赖项。”

大家都知道,我不太喜欢算数,但现在还是来算一算吧。

在《2022 年应用策略现状》中,我们发现了几项值得关注的统计数据:

  • 现代应用(容器原生应用和移动应用)平均占企业应用组合的33%
  • 各行业企业的应用组合平均包含约200个应用

因此,200的33%意味着,一般企业的应用组合中平均有66个现代应用。按照Sonatype统计的开源依赖项平均数量计算,一般企业可能需要承担保护8,448个不同开源依赖项的重任。当然,不同应用之间几乎肯定存在依赖项重叠。容器原生应用几乎总是共享同一个容器编排环境(Kubernetes目前在容器编排引擎(COE)中占据主导地位),因此,就具体依赖项而言,实际负担会更低;但一旦出现漏洞,每个依赖项实例仍需更新,这方面的负担并未减轻。

无需再做更多计算,我们不妨达成共识:鉴于应用组合的规模以及其中包含的开源依赖项,如今保护软件供应链是一项艰巨的任务。

GitHub的新功能可帮助解决这一问题,方法是“发现并阻止目前仅显示在拉取请求丰富差异视图中的漏洞”。换言之,该功能可集成到CI/CD流水线中,实时扫描已知漏洞。

不错。不过,这种能力并不罕见。多年来,DevSecOps一直在推动此类安全“左移”。无论使用何种工具,大多数CI/CD流水线都能对代码执行安全扫描。但并非所有流水线都集成了相应能力,能够扫描可能深藏在依赖项中,或由难以检测的逻辑错误所导致的已知漏洞。

当然,应尽可能在CI/CD流水线中融入安全措施,以便尽早消除日后可能带来麻烦的漏洞和错误。但这并不是我们进行这项演练的原因。

SRE、软件和供应链安全

我之所以特别指出现有软件供应链的问题,是因为随着各组织采用SRE方法推动运维现代化,这一问题只会愈发严重。究其根本,SRE实践依赖自动化,而自动化又依赖软件和脚本。相信您也知道,其中许多竟然是开源的。

事实上,DevOps使用的许多开源工具也会被SRE采用,这并不令人意外。简单来说,SRE相当于面向生产环境的DevOps。DevOps从业人员通常专注于软件构建和发布流水线,而SRE则专注于软件运维流水线。这不仅涉及应用,还包括应用安全和交付服务,以及各种平台和环境(如核心、云和边缘环境)。SRE人员的职责范围横跨整个IT技术栈,因此在保护软件供应链方面面临的任务要困难得多。

简而言之,所有组织都应关注软件供应链安全,因为它会影响从开发、构建、发布、部署到运行的整个应用生命周期。

对于希望顺利推进数字化转型的组织而言,这同样值得关注。各地企业即将迎来一场重大变革,而这场变革将影响组织的核心:企业架构。

大多数企业架构都建立于数十年前,其所依据的框架以资源固定且缺乏灵活性、数据中心是业务核心为前提。

这些前提如今已不再成立;即使仍然成立,业务本身也已发生变化。如今,业务日益数字化。为采用数据驱动流程的数字化业务建模时,原本用于描述采用人工驱动流程的实体业务的架构已无法充分满足需求。企业架构必须实现现代化,并在此过程中纳入新的领域,例如SRE运维。

事实也确实如此。我们今年的研究发现,37%的组织已采用SRE运维来推动应用和运维现代化,另有40%的组织计划在未来12个月内采用。这意味着需要工具和脚本、软件和数据,以及一整套技术栈来支持这一新的组织角色。

软件、脚本和技术栈也会带来供应链和安全问题。我们从DevOps中得到了一条不容忽视的经验:在推进运维现代化的过程中,SRE实践也会产生许多类似的技术债务,并面临类似的安全挑战。

好消息是,与DevOps和构建流程不同,SRE运维对组织而言将是一种全新的实践。建立新实践意味着确立新的运作方式,包括从一开始就将安全融入其中。


分享

关于作者

Lori Mac Vittie
Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师,在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构,还是探索可扩展系统的极限,她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前,她曾担任技术编辑,并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位,著述颇丰,出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏,并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章

相关博客文章

SOAS 2025:目标不一致,结果难出色
F5生态系统 | 2025/05/13

SOAS 2025:目标不一致,结果难出色

AI部署缺乏协调会导致效率低下。了解如何协调安全、自动化和部署策略,充分释放AI潜力。

AI应用的应用交付与安全:驾驭现代AI架构
F5生态系统 | 2024/08/22

AI应用的应用交付与安全:驾驭现代AI架构

了解生成式AI应用和API安全如何塑造现代应用交付与安全。

借助多云网络简化超级云
F5生态系统 | 2023/09/13

借助多云网络简化超级云

超级云不只是一个流行词。它代表着一种简化愿景,以多云网络为起点,支持跨云提供商的混合IT。

2023年应用策略现状:成本与复杂性是推动多云网络发展的首要因素
F5生态系统 | 2023/03/15

2023年应用策略现状:成本与复杂性是推动多云网络发展的首要因素

多云网络解决方案可在核心、云和边缘环境之间实现无缝、安全的互联,为解决当今混合IT面临的挑战提供支持,因而备受业界关注。

运营演进的必要性
F5生态系统 | 2022/01/11

运营演进的必要性

在数字化成为默认模式的世界中,运维仍然过度依赖人工方式,需要不断演进,才能支持自适应应用。这一演进要求整个IT体系进行重大变革,并具备由AI赋能的自适应能力,以保持可用性、优化性能并保障安全。

多云并非简单使用多个云:让跨云衔接更轻松
F5生态系统 | 2021/10/07

多云并非简单使用多个云:让跨云衔接更轻松

随着企业转向互联云战略,工作负载的管理和保护变得日益复杂。了解F5如何满足市场对多云网络新方法的需求。