技术咨询
代买器件
商务客服
研发客服73%的企业在Log4Shell、SolarWinds和 Kaseya出现漏洞后加强了供应链安全管理
虽然业界一直在讨论通过“安全左移”来帮助解决问题，实现安全能力的扩展和和应用程序的快速开发。但企业在将其付诸实践时面临着挑战。大多数云原生安全事件都是由不当配置引起的，这给安全团队带来了很大的压力，迫使他们寻找将安全性纳入开发流程的方法，以便在部署之前发现并修复编码问题。企业还需要聚焦于寻找与开发团队更好的协作方式，从而快速修复检测到的任何安全问题。
新思科技(Synopsys, Nasdaq: SNPS)发布最新供应链安全调研报告。该报告由新思科技软件质量与安全部门委托技术研究公司Enterprise Strategy Group(ESG)执行，面向350名应用开发、信息技术和网络安全决策者进行调研。该报告名为《一往无前：GitOps与安全左移 - 可扩展且以开发者为中心的供应链安全解决方案》(Walking the Line: GitOps and Shift Left Security: Scalable, Developer-centric Supply Chain Security Solutions)，其指出软件供应链风险不限于开源范围。
针对 Log4Shell、SolarWinds 和Kaseya 等软件供应链攻击，73%的受访者表示，他们已通过各种安全举措显著加大了对企业软件供应链的保护力度。这些举措包括采用强大的多因素身份验证技术 (33%)；投资应用安全测试措施(32%)； 以及改进资产发现流程以更新攻击面清单 (30%)。尽管做出了这些努力，但仍有 34%的企业指出，他们的应用在过去 12 个月内因开源软件(OSS)中的已知漏洞而被利用，其中28%的企业在开源软件中发现之前未知的漏洞（“零日”漏洞利用攻击）。
随着使用规模增加，开源软件在应用程序中的存在自然也会增加。当前，软件物料清单 (SBOM)是解决软件供应链风险管理燃眉之急的重要途经。开源软件使用量激增，而开源管理乏善可陈，这使得制作SBOM变得复杂。ESG公司研究也证实了这一点： 39%的受访者将SBOM标记为使用开源软件的挑战。
新思科技软件质量与安全部门总经理Jason Schmitt表示：“近年来，供应链安全漏洞、攻击的新闻频发。企业意识到这对他们的业务会产生潜在的负面影响。采取主动安全策略已经成为企业的当务之急。虽然管理开源风险是管理云原生应用中软件供应链风险的关键组成部分，但我们还必须认识到风险是超出了开源组件范围的。基础设施即代码、容器、API、代码存储库等，不胜枚举。企业必须考虑所有因素，以进行全面部署，确保软件供应链安全。”
虽然开源软件可能是最初的供应链安全关注点，但向云原生应用开发的转变让企业担心对供应链的其它环节会构成的风险。这不仅包括源代码，还包括云原生应用如何存储、打包和部署，以及它们如何通过应用程序编程接口 (API) 互联。近一半 (45%) 的受访者认为API以及数据存储库 (42%) 和应用容器镜像 (34%)是最容易受到攻击的载体。
几乎所有(99%)的受访者表示，他们的企业目前使用或计划在未来12个月内使用开源软件。尽管对这些开源项目的维护、安全性和可信性存在担忧，但最受关注的问题与在应用开发中使用开源的规模有关。 54%的企业将“拥有高比例的开源应用代码”列为他们的主要关注点。
新思科技网络安全研究中心首席安全策略师Tim Mackey表示：“凭借SBOM，软件运营商可以了解应用中包含哪些第三方软件生产商，无论是来自开源、商业还是签约的第三方。在设计补丁管理流程时，这些信息至关重要。因为没有这些信息，对任何应用中存在的软件风险的观察都不全面，无论其来源如何。有了这些信息，一旦 Log4Shell 出现下一个零日漏洞（这会发生），企业将能够快速有效地采取行动，抵御针对第三方软件组件的攻击。”
调查结果还表明，尽管越来越多构建云原生应用的企业采取以开发人员为中心的安全策略和安全“左移”（一个专注于使开发人员能够在开发生命周期早期进行安全测试的概念），但 97% 的企业在过去 12 个月内遭遇过涉及其云原生应用的安全事件。
更快的发布周期也给所有团队带来了安全挑战：应用开发(41%)和DevOps(45%)团队允许开发人员经常跳过已建立的安全流程；而且大多数应用开发人员(55%)允许安全团队缺乏对开发流程的可见性。 68%的受访者表示，他们高度重视采用以开发人员为中心的安全解决方案，并将部分安全责任转移给开发人员。目前负责应用安全测试的开发人员 (45%)多于安全团队 (40%)。开发人员使用内部开发或开源安全工具的可能性是专门的第三方供应商的两倍。
与此同时，开发人员在保护云原生应用的软件供应链方面发挥着更大的作用，但只有36%的安全团队完全接受由开发团队负责安全测试。诸如使开发团队负担过重的额外工具和责任、破坏创新和速度以及获得对安全工作的监督权等问题仍然是开发人员主导的应用安全工作的最大障碍。
相关文章
