了解最新技术文章
过去三年见证了恶意供应链攻击的持续演变。随着不良行为者继续微调利用易受攻击的库的方法,避免将不必要的漏洞引入应用程序比以往任何时候都更加重要。但一个不幸的事实是,所有行业的组织仍然以旧方式看待软件供应链安全。
旧方法有点像这样:
一个漏洞一直隐藏而不被注意。最好的情况是安全研究人员发现它。最坏的情况是黑客找到它并开始利用它。
“以旧方式”看待网络安全的问题在于,当今的网络犯罪分子不仅仅是在寻找漏洞。他们是创造它们的人。
这些是当前最流行的一些方法:
依赖混淆
这是最常见的恶意供应链攻击类型。它依赖于欺骗内部包名称并将它们发布到具有异常高版本号的开源注册表。
域名仿冒
攻击者选择一个流行的组件,稍微拼错名称,然后依赖开发人员错误地添加该组件的易受攻击版本。
这种技术还有一种称为品牌劫持的变体,其中一个已知的品牌名称被足够仔细地欺骗,以诱使开发人员意外地集成这些包而不是合法组件。
恶意代码注入
这种攻击依赖于对手获得对库源代码的访问权限。它可以通过妥协——比如SolarWinds攻击——或者假装是一个仁慈的开源提交者。获得访问权限后,会引入伪装成无害代码更改的恶意更改。此有效负载分发给库用户,他们的构建系统随后将恶意代码引入到他们的应用程序中。这些攻击可能会产生很大的影响,但由于它们具有高度针对性,因此频率较低。
请务必注意,忽视这些攻击的组织并非有意为之。
阻碍安全、高效编码的问题包括:
认证和监管审计引入了阻碍团队前进的障碍,并可能导致效率较低的“勾选框”安全方法。
确保软件供应链安全所需的维护任务通常很复杂,并可能导致意想不到的问题和技术债务。
资源有限、团队超负荷和严格的期限在公共和私营部门中持续存在。
没有理想的安全措施并不意味着组织有意偷工减料。但这并没有改变他们没有优先考虑最佳实践的事实。
组织可以通过几种方式向左移动并在开发过程中更早地移动他们的安全问题。
SBOM提供构成应用程序的所有直接和传递依赖项的完整列表。它显示了您正在引入的库及其依赖项,以及对这些依赖项的洞察,例如漏洞、许可证问题和其他风险组件。
此时,很少需要 SBOM。但是,美国国家电信和信息管理局已经为要求 SBOM 奠定了基础。
对于专有软件,除非有 SBOM 与之配合,否则很难深入了解应用程序中的内容。SBOM 提供的更高透明度对于提高软件供应链安全性至关重要。
开始实施 SBOM 并不难。Sonatype 的Nexus Vulnerability Scanner是一款免费工具,可自动生成一个 SBOM,该 SBOM 对应用程序中的所有组件进行分类,并突出显示它发现的任何安全问题。
将软件开发想象成一个实体工厂,在整个生产过程中都有安全检查和质量控制程序。没有人会在未确保符合质量标准的情况下让实体产品进入其生产周期的末尾。为什么软件开发会有什么不同?
每月下载 12 亿易受攻击的依赖项。这本身就是一个令人震惊的数字,但更令人震惊的是,超过 95% 的所有已知易受攻击的组件都有可用的固定版本(根据 Maven Central 1 年的下载量来衡量)。大多数时候,没有人必须下载易受攻击的版本。
了解您的依赖关系和漏洞始于对以下各项进行定期扫描:
开发人员正在编写的代码。
从开源社区提取的代码。
容器、图像和 JAR 文件等 工件。
有趣的事实:开源项目的平均依赖树有 5.7 层深。对于企业项目,这个数字可能更深。
sonatype.com/hs-fs/hubfs/image2-Feb-06-2023-08-38-18-5860-PM.png?width=624&height=505&name=image2-Feb-06-2023-08-38-18-5860-PM.png" alt="给定组件中所有依赖项的列表。" width="624" height="505" loading="lazy" srcset="https://blog.sonatype.com/hs-fs/hubfs/image2-Feb-06-2023-08-38-18-5860-PM.png?width=312&height=253&name=image2-Feb-06-2023-08-38-18-5860-PM.png 312w, https://blog.sonatype.com/hs-fs/hubfs/image2-Feb-06-2023-08-38-18-5860-PM.png?width=624&height=505&name=image2-Feb-06-2023-08-38-18-5860-PM.png 624w, https://blog.sonatype.com/hs-fs/hubfs/image2-Feb-06-2023-08-38-18-5860-PM.png?width=936&height=758&name=image2-Feb-06-2023-08-38-18-5860-PM.png 936w, https://blog.sonatype.com/hs-fs/hubfs/image2-Feb-06-2023-08-38-18-5860-PM.png?width=1248&height=1010&name=image2-Feb-06-2023-08-38-18-5860-PM.png 1248w, https://blog.sonatype.com/hs-fs/hubfs/image2-Feb-06-2023-08-38-18-5860-PM.png?width=1560&height=1263&name=image2-Feb-06-2023-08-38-18-5860-PM.png 1560w, https://blog.sonatype.com/hs-fs/hubfs/image2-Feb-06-2023-08-38-18-5860-PM.png?width=1872&height=1515&name=image2-Feb-06-2023-08-38-18-5860-PM.png 1872w" sizes="(max-width: 624px) 100vw, 624px" style="height: auto; width: 624px; margin-left: auto; margin-right: auto; display: block;"/>依赖树可能是什么样子的示例。
深度依赖树使安全风险更容易溜走。确保工具可以扫描完整的依赖关系树至关重要。
判断应用程序何时需要可用更新以保持安全并不总是那么容易。许多工具都来自National Vulnerability Database,但通常无法准确说明哪些版本受到影响。例如,当只有 2.5 到 3.2 版本受到影响时,它可能会识别 3.2 版本之前的所有内容。在这种情况下,使用 2.5 之前版本的团队可能会花时间进行不必要的更新,而应用程序从一开始就不会受到攻击。
更准确的数据有助于避免不必要的版本更新工作。在 Sonatype,我们有一个大型数据安全团队对所有这些公共咨询进行深入研究。
他们查看代码并发现:
引入代码的提交。
修复它的提交。
与它们关联的发行版本。
这种额外的努力可以提供更准确的数据,准确说明受漏洞影响的对象。
理想情况下,每个组织都将遵循依赖管理最佳实践。但严酷的现实是,很多软件只是在发布前才检查漏洞。甚至更糟,直到之后。
自动化可以大大减少安全团队寻找漏洞的时间。Sonatype 的Nexus 防火墙在团队成员进行手动审查时自动隔离可疑组件。用户可以高枕无忧,因为他们的软件供应链更加安全。
更具体地说,防火墙:
阻止恶意和可疑的包,直到它们被确认是安全的。
自动将已清除的组件发布回开发管道,在清除组件后无需手动操作。
防止已知漏洞自动下载到组织的存储库中。
所有这些工具都是 Sonatype 的免费产品,可以更轻松地捕获和消除漏洞。
Sonatype 安全评级
Sonatype 安全评级以 1-10 的等级对项目进行评分,1 表示最有可能包含漏洞,10 表示最安全。
BOM Doctor
BOM Doctor 扫描现有 SBOM 的漏洞,生成完整的依赖关系树,并提出补救建议。
Sonatype Lift
Lift 分析代码并报告开发人员工作流程中的关键安全性、性能和可靠性错误。