摘要：GitHub 已经从简单的版本控制发展成为现代软件开发的支柱。虽然组织认真地扫描来自 npm 或 PyPI的打包依赖项，但他们往往忽略了一个更普遍的危险：GitHub 托管的代码在整个软件开发生命周期中渗透系统的多种方式。这些隐藏的风险向量会造成老练攻击者主动

通过解决这些被忽视的风险向量，组织可以继续利用 GitHub 的创新，同时防止针对互连软件的复杂供应链攻击。

GitHub 已经从简单的版本控制发展成为现代软件开发的支柱。虽然组织认真地扫描来自 npm 或 PyPI的打包依赖项，但他们往往忽略了一个更普遍的危险：GitHub 托管的代码在整个软件开发生命周期中渗透系统的多种方式。这些隐藏的风险向量会造成老练攻击者主动利用的盲点，正如 tj-actions GitHub Action 和 XZ Utils 泄露等事件所证明的那样。

GitHub 引用的攻击面不断扩大

从最初的编码到生产部署，我们在 OX Security 进行的研究发现，开发团队在软件开发周期的不同阶段引用 GitHub 内容——每个阶段都代表着恶意代码的潜在入口点：

1. 依赖管理：直接 GitHub 引用

风险向量：npm、pip、Maven 和 Go 模块等包管理器都支持直接从 GitHub 存储库而不是官方注册表中提取依赖项。

攻击面：使用可变引用（如“main”等分支）而不是固定提交可能会导致不确定的构建。如果原始所有者更改或放弃存储库，存储库劫持会带来额外的风险。

相关新闻：黑客窃取 4M+ TransUnion 客户的数据

实际影响：我们的分析发现大约 110,000 个package-lock.json文件、超过 65,000 个 requirements.txt/pyproject.toml 文件以及超过 54,000 个直接引用 GitHub 的 JitPack 配置，从而形成了一个巨大的攻击面，恶意代码可以在其中以应用程序权限执行。

2. 容器构建：在镜像创建过程中注入代码

风险向量：Dockerfile 经常使用 git clone 或带有 GitHub URL 的 ADD/COPY 在映像构建过程中获取源代码、构建工具或设置脚本。

攻击面：源文档确定了大约 234,000 个 Dockerfile 和 78,000 个引用 GitHub 的 docker-compose 文件，如果远程存储库发生变化，层缓存可能会重复使用过时或受损的代码。

实际影响：在构建过程中克隆的看似无辜的实用程序可能包含隐藏函数，以便在容器内执行时泄露环境变量，除了基本 TLS 之外，完整性验证最少。

3. Kubernetes 部署：Helm 图表和清单

风险向量：Kubernetes 清单中的 Helm 图表或初始化容器在部署期间从 GitHub 获取配置和脚本。

攻击面：未经验证的图表或通过钩子动态获取可以部署具有集群权限的恶意资源。GitHub 会自动拉取并使用托管的 .tgz，而无需验证存储库的源代码。

相关新闻：1,000+ 开发人员将秘密暴露给人工智能驱动的窃取者

实际影响：如源文档所示，部署引用恶意 GitHub URL 的 Helm 图表可能会导致环境变量在部署时被泄露。

4. 配置管理：基础设施自动化

风险向量：Ansible（3,000 个requirements.yml文件）、SaltStack（1,000 个配置）、Logstash 和 Grafana（每个 5,000 个安装）等工具直接从 GitHub 提取配置或组件。

攻击面：未经验证的角色、状态、模式或仪表板以跨基础结构的管理权限执行。

实际影响：受损的配置可能会重定向日志、导致 ReDoS 攻击或执行恶意命令。Grafana 仪表板可能包含 XSS 有效负载或通过受损的数据源配置泄漏凭据。

5. CI/CD 自动化：GitHub Actions 和工作流程

风险向量：GitHub Actions 利用第三方作或在工作流执行中执行直接 git 克隆作。

攻击面：分析发现大约 561,000 个工作流引用外部 GitHub Actions，大约 167,000 个工作流使用显式 git 克隆，通常有权访问存储库机密和部署凭据。

相关新闻：人类人工智能用于自动化数据勒索活动

实际影响：该文档引用了 GitHub Actions 的真实事件，其中受损的作可能会窃取GITHUB_TOKEN、篡改项目或部署后门代码。使用带有可变标记 （@main） 的作而不是提交哈希会产生重大风险。

6. 代码组织：Git 子模块和子树

风险向量：Git 子模块和子树在项目中嵌入外部存储库，从而创建复杂的依赖树。

攻击面：分析发现大约 14,000 个子模块添加命令和 2,000 个子树添加命令引用 GitHub，如果引用的存储库受到损害或劫持，就会产生风险。

实际影响：存储库接管可能会在后续的“git submodule update --init”或“git subtree pull”命令期间引入恶意代码，特别是对于固定到缺少关键安全更新的旧提交的子模块。

7. 基础设施配置：Terraform 和 IaC 模块

风险向量：直接来自 GitHub 的基础设施即代码模块可自动进行云资源配置。

攻击面：该文档识别了大约 114,000 个 Terraform 文件和 13,000 个 terragrunt.hcl 文件，这些文件引用了 GitHub 模块，通常使用可变引用 （？ref=main）。

实际影响：遭到入侵的模块可能会在攻击者控制下预置资源、打开安全漏洞（公共 S3 存储桶、广泛的防火墙规则）、在 VM 中嵌入恶意启动脚本或泄露状态文件机密。

8. 构建和应用程序插件：扩展核心工具

风险向量：构建 Gradle 等工具和 Redis 等应用程序，直接从 GitHub 加载插件，将功能扩展到核心功能之外。

攻击面：与官方插件市场相比，分析在 GitHub 上发现了大约 24,000 个 Gradle 引用和 1,000 个 Redis 插件，审查最少。

实际影响：如文档所示，通过可传递的 GitHub 托管的 Gradle 插件合并看似无害的 PR 添加功能可能会导致构建过程中环境变量外泄。

9. 开发人员工作流程：预提交和安装钩子

风险向量：Git 钩子和包管理器生命周期脚本在开发工作流的早期自动运行。

攻击面：该文档确定了大约 7,000 个来自 GitHub 的 .git/hook 文件和 65,000 个带有安装前/安装后脚本的 npm 包，以最少的用户交互执行。

实际影响：恶意 npm 安装脚本可以窃取凭据或安装恶意软件，正如文档中提到的 ESLint 入侵等现实世界的攻击中所见。

10. 跨存储库触发器：Webhook 和集成

风险向量：Repository_dispatch事件允许一个存储库通过 API 调用触发另一个存储库中的工作流。

攻击面：分析发现大约有 56,000 个 .github/workflows 侦听repository_dispatch事件，表明已准备好应对可能被利用的外部触发器。

实际影响：如果没有 HMAC 签名验证，攻击者如果获得令牌，可能会伪造repository_dispatch事件，从而通过client_payload触发带有注入向量的意外工作流程。

利用 GitHub 的优势并保护我们自己

这些向量需要从传统的依赖扫描转向全面的供应链治理。为了最好地保护自己，组织必须清点其 SDLC 中的所有 GitHub 引用，标准化固定的不可变引用，实施完整性验证，并为常见的外部依赖项开发安全的内部替代方案。网络安全专业人员必须积极主动地提前为开发人员准备安全基础设施，这样他们就不会依赖未经验证的、有潜在风险的 GitHub 托管代码。

通过解决这些被忽视的风险向量，组织可以继续利用 GitHub 的创新，同时防范针对我们互连软件生态系统的复杂供应链攻击。

来源：八哥科技坊