上个月我遇到了 本文 来自暗读。看起来很眼熟。没过多久我就意识到文章中讨论的 GitHub 跨工作流工件中毒漏洞与 GitHub 跨工作流有着惊人的相似之处 缓存中毒 我们于 2022 年 XNUMX 月报告的漏洞。
GitHub 工作流程——GitHub CI/CD 管道的关键组件
GitHub 工作流程用于定义应作为 CI/CD 管道一部分采取的特定操作。它们是可以由 GitHub 存储库中的特定事件触发的自动化流程。例如，此类事件包括将代码推送到存储库时、打开或关闭拉取请求时或发布新版本时。
工作流是使用 YAML 文件创建的，该文件指定触发工作流时应采取的操作。此类操作可以由开发人员编写，也可以从 GitHub 市场中获取，其中可以下载和使用 10,000 多个预制操作。
工作流由一个或多个作业组成，这些作业被定义为一系列步骤。步骤可以是各种操作，例如运行测试、部署代码或发布包。
GitHub 工作流程是一个功能强大的工具，可以帮助开发人员自动化和简化其工作流程，节省时间和精力，并提高软件开发过程的可靠性，但它们并非没有内置缺陷。
使用 GitHub 工作流程时可能会出现一些潜在的安全问题。以下是一些常见的：
- 越权存取：未正确配置或保护的工作流程可能会被未经授权的用户访问和触发。这可能允许他们执行任意代码或执行其他未经授权的操作。
- 秘密泄露：工作流程通常需要使用机密（例如 API 密钥或密码）来访问外部资源或执行某些操作。如果这些秘密没有得到适当的保护，它们可能会被泄露，从而导致安全漏洞。
- 不安全的依赖s：如果这些依赖项不安全，依赖外部库或依赖项的工作流程可能容易受到攻击。定期检查和更新依赖项以确保它们的安全非常重要。
- 缺乏输入验证和清理：未正确验证输入的工作流程可能会被利用来执行任意代码或执行其他未经授权的操作。
让我们仔细看看上面提到的文章中讨论的两个跨工作流程漏洞。
跨工作流工件中毒
GitHub 工作流工件是 CI/CD 管道中完成的工作的产物。通常，每个工作流程都会有自己的存储桶来存储此类工件，但有时工作流程需要访问其他工作流程创建的工件。 GitHub 不允许工作流程直接访问来自不同工作流程的存储/工件。为了解决这个问题，有一个 GitHub 批准的 API，允许根据基本过滤下载工件。问题在于，API 无法区分分叉存储库上传的工件和基础存储库上传的工件。这意味着上传由分叉存储库创建的可能有毒的工件是一个真实存在的危险。
为了修复此问题，GitHub 开始在下载工件时提供附加信息以及工件元数据。此信息旨在帮助作者确保他们下载的是正确的工件。目前，跨工作流工件的基本问题不被 GitHub 视为问题。要了解有关此问题的更多信息，请查看 刊文 上文提到的。
跨工作流缓存中毒
GitHub 允许缓存工件和包以加速 CI/CD 管道。无需为每个可能需要的工作流程一次又一次地下载所需的工件和包，而是可以将它们缓存并在不同的工作流程中使用。
由于缓存在工作流之间共享，因此只需在使用缓存的工作流中进行一次破坏并有权更改它，并且该缓存可能会因所有后续工作流使用而中毒。由于缓存仅在有新的工件或包可供下载时更新，这意味着单个中毒缓存可能会长时间处于活动状态，从而影响该管道中运行的软件构建的无数迭代。
GitHub 不认为缓存可能中毒的问题是个问题。缓存是一项有用的功能，其在工作流程之间共享的能力目前不被视为错误或彻底的安全问题。要了解有关此问题的更多信息，请查看 刊文 上文提到的。
其他鲜为人知的 GitHub 漏洞以及如何防御它们
GitHub 是世界上最受欢迎的源代码控制管理 (SCM) 系统之一。因此，它还广泛用于使用其 CI/CD 管道、操作和工作流程来构建和分发软件。
人们需要记住，GitHub 的创建是为了促进代码共享和联合开发。它最初是为开源开发者设计的，后来添加了企业和组织帐户功能。从本质上讲，安全性并不是系统的主要关注点。事实上你需要做一个 特别设置 在 GitHub 上启用帐户的安全功能意味着使用 Git 本身就更安全的想法只是一种幻想。
本月晚些时候，Scribe 将主持 查奇·佐恩斯坦Checkmarx 软件供应链主管在一次网络研讨会上讨论了 GitHub 中的一些此类潜在软件供应链陷阱。
如果您想了解有关此类鲜为人知的漏洞以及如何防御它们的更多信息，请收听此点播 研讨会。
此内容由领先的端到端软件供应链安全解决方案提供商 Scribe Security 为您提供 - 为整个软件供应链中的代码工件以及代码开发和交付流程提供最先进的安全性。 了解更多
相关文章
