软件供应链安全曾经让人觉得是一个存在于别处的问题。
仓库和构建系统是首要关注点。包注册表、持续集成与持续交付流水线、发布自动化、云平台以及制品存储也成为了关注的焦点。这些仍然很重要，需要保护，但攻击面已经转移到了开发者日常工作的地方。
开发者笔记本电脑不再只是代码编写的地方。它是供应链的一部分。
安全影响很容易被低估。现代工作站涉及源代码、包管理器、云账户、注册表令牌、安全 shell 密钥、服务账户、构建脚本、人工智能编码助手、终端、本地缓存和环境文件。在那里，凭证被创建、复制、测试、记录，而且太常被遗忘。
攻击者明白这一点。他们不仅在寻找易受攻击的生产服务或被污染的构建步骤。他们在寻找能让一个系统信任另一个系统的访问材料。
我们必须更新防御模型。安全不能等到代码到达远程仓库或流水线。到那时，凭证可能已经在 Git 历史、模型提示、本地日志、构建制品或包安装脚本的范围内了。
控制点必须前移到软件创建过程的更早阶段。
共同线索是凭证窃取
GitGuardian 最近的违规研究报告 指出软件供应链攻击中有一个明确的模式：攻击者越来越多地针对嵌入在开发者工作流中的凭证。
2026 年 4 月，我们分析了影响 npm、PyPI 和 Docker Hub 在 48 小时内的三个供应链活动。生态系统和攻击技术各不相同，但目标是一致的。每个活动都专注于从开发者环境或持续集成与交付流水线中窃取有用的凭证。
一个被入侵的 npm 包使用 postinstall 钩子窃取 npm 发布令牌，然后利用该访问权限发布受害者可达范围内包的感染版本。一个 PyPI 活动收割安全 shell 密钥、云凭证、环境变量和加密钱包。在这些活动中，攻击者的目标显然是收集有效访问权限并用它来抵达下一个系统。
这就是让这个问题如此具有破坏性的原因。
开发者是有吸引力的目标
开发者可能拥有对源代码控制、云账户、包注册表、制品存储、预发布环境、事件工具和内部应用程序编程接口的访问权限。构建运行器可能持有部署凭证、包发布令牌以及对生产邻近基础设施的访问。一个暴露的令牌可以成为跨越交付过程多个层的桥梁。
这就是为什么凭证暴露不同于许多其他漏洞。攻击者并不总是需要利用软件缺陷、维持持久性或修改生产代码。有时，经过身份验证的访问就够了。有时，在开发者机器上的短暂立足点可以发现具有更广泛范围的凭证。
The GitGuardian 2026 年秘密扩散状态报告 让情况的规模变得清晰。我们在 2025 年的公共 GitHub 提交中发现了超过 2860 万个新秘密，同比增长 34%。内部仓库包含硬编码凭证的可能性大约是公共仓库的六倍。大约 28% 的事件完全起源于仓库之外，在 Slack、Jira 和 Confluence 等协作系统中。
仓库不再是边界。如果一个秘密可以以明文形式在机器上找到，它很可能也会以明文形式传播到其他地方，并被任何找到它的人使用。
工作站现在包含了太多上下文，无法忽视
开发者笔记本电脑之所以有吸引力，是因为它们包含上下文。
它们持有源代码树、dotfiles、shell 历史记录、本地环境文件、集成开发环境设置、包管理器配置、构建制品、终端输出、人工智能代理日志和临时调试笔记。其中许多文件在正常审查期间不可见。许多永远不会离开机器。有些位于开发者很少检查的目录中。
这使得本地暴露难以通过仅仓库控制来管理。
凭证可能出现在 .env 文件中，被打印到终端历史记录中，进入测试配置，出现在构建输出中，或在故障排除期间被复制到人工智能提示中。这些都不需要恶意提交。它们都不一定会触发集中式扫描。然而每个时刻都可能造成真正的访问风险。
作为行业，我们需要扫描在 Git 之外收集凭证的地方。项目工作区、dotfiles、构建输出和代理文件夹都可能存储复制的令牌、配置块、故障排除输出和缓存上下文。攻击者收割这些本地数据，因为它可以直接导向有效访问。
Shai-Hulud 数据为这一担忧提供了分量。在 6943 台被入侵的机器上，它发现了 33185 个唯一凭证，其中至少 3760 个在首次检查时仍然有效。这不是一个理论上的工作站问题。这是一个实际的攻击者工作流。
入侵机器。搜索上下文。提取访问权限。继续前进。
工作站已经成为安全边界，因为太多工具假设本地环境是受信任的。包管理器运行安装脚本。扩展读取项目文件。终端暴露环境变量。本地自动化触及真实系统。人工智能代理可以读取文件、运行命令和总结输出。
这些操作中的每一个都可能有用，但每一个也可能成为意外暴露或恶意指令的途径。
人工智能辅助开发为同样的问题增加了更新的层。人工智能编码工具现在更接近开发者的文件、终端、编辑器和环境变量。提示可能包含凭证。工具可能调用并读取敏感文件。生成的命令可能将访问材料打印到日志或模型上下文中。代理可以将无害的步骤组合成有风险的操作。
暴露面不再只是人工输入加上代码审查。它现在包括人类、本地工具、自动化代理和外部服务之间的交互。正如我们在报告中发现的，更多人在使用编码助手，而其中许多让代理共同创作提交的人每次提交泄露的秘密数量是其他人的两倍。
安全控制必须在实际发生工作流的地方满足它。
更早的检查点减少损害
传统的供应链控制仍然重要。团队仍然需要源代码控制保护、依赖扫描、安全持续集成与交付、制品完整性、发布控制和生产部署护栏。
但这些控制通常在风险时刻已经发生后触发。
开发者可能已创建了带有凭证的本地文件。人工智能助手可能已收到敏感上下文。包安装脚本可能已读取环境变量。令牌可能在到达远程仓库之前已进入本地 Git 历史。
在凭证到达共享仓库后轮换凭证可能成为完整的事件响应工作。有人必须识别所有权、吊销凭证、颁发替换凭证、检查使用情况、测试依赖应用程序、审查访问权限、在可能的情况下清理历史记录并记录事件。这项工作是必要的，但代价高昂。
在开发者仍在编辑文件时捕获同样的问题更简单。删除它。用安全引用替换它。继续前进。
最强大的模型将凭证检测视为持续的开发者端控制，而不是偶尔的清理任务。工具必须坐在开发者已经工作的地方：在编辑器中、在 Git 钩子中、在终端中以及在人工智能编码工作流内部。
保护您开发者的秘密
ggshield 是 GitGuardian 用于扫描开发者工作流的命令行界面。您可以在本地或持续集成环境中运行 ggshield，它在整个软件开发生命周期中提供防护，并检测数百种类型的硬编码凭证。
本地扫描在代码移动到共享基础设施之前捕获问题。持续集成扫描在代码离开笔记本电脑后捕获问题。预接收钩子可以防止秘密被推送到共享仓库或系统。在这些检查点使用相同的工具让团队获得一致性，而不强制开发者进入单独的安全流程。
Git 钩子增加另一层保护
使用 gghsield pre-commit 钩子 意味着在 Git 创建提交之前运行扫描。团队可以通过 pre-commit 框架配置它，为特定仓库本地安装，或在全球范围内为开发者工作站上的当前和未来仓库安装。
全局选项很重要。不是每个泄露都发生在主代码库中。临时仓库、测试文件夹、辅助项目、克隆的示例和一次性实验都会产生暴露。仓库逐个的推广会留下空白。全局钩子为开发者机器提供更广泛的默认保护。
预推送钩子 捕获更晚的时刻。它在代码离开机器前往远程仓库之前运行。GitGuardian 文档记录了本地、基于框架和全局安装模式用于此控制。pre-commit 和 pre-push 钩子一起创建两个有用的门控：一个在本地历史变得持久化之前，一个在代码到达共享基础设施之前。
保存时查找秘密
GitGuardian 的 VS Code 扩展 使用捆绑的 ggshield 命令行界面在开发者编写或修改代码时扫描代码。保存文件时自动运行扫描。发现结果通过代码注解、状态栏警告和问题面板直接即时显示在编辑器内。此扩展也适用于 Cursor、Antigravity 和 Windsurf。
GitGuardian VS Code 扩展运行中
安全控制在其太晚、太嘈杂或离错误太远时会失效。良好的本地控制提供上下文中的反馈。它解释发生了什么。它帮助开发者在问题成为工单、构建失败或事件之前修复它。
人工智能工具需要在交接点设置护栏
人工智能编码工具值得特别关注，因为它们改变了泄露可能发生的位置。
人工智能工作流可能在代码作为文件存在之前就暴露敏感材料。开发者可能在调试时将凭证粘贴到提示中。代理可能读取本地配置文件。工具调用可能执行打印环境变量的命令。该命令的输出然后可能进入模型上下文或本地日志。
这是一条与传统源代码泄露不同的路径。
GitGuardian 的人工智能编码工具集成通过将控制放置在 Cursor、Claude Code 和带有 GitHub Copilot 的 VS Code 等工具的钩子系统内部来解决这个问题。该集成扫描三个阶段：提示提交、工具使用前和工具使用后。
GitGuardian AI 钩子运行中
提示提交扫描在内容到达模型之前检查内容，并在找到凭证时阻止提示。工具使用前扫描在执行前检查命令、文件读取和模型上下文协议调用，阻止有风险的操作在运行前执行。工具使用后扫描在执行后检查输出，并在凭证出现时发送桌面通知。
这种结构适合代理工具的操作方式。
有风险的时刻可能是提示。可能是文件读取。可能是 shell 命令。可能是开发者没有手动检查的工具输出。仅仓库控制看到这条流的太少。在人工智能工作流内部的钩子可以在交接点阻止暴露。
编辑器在开发者编写时捕获问题。人工智能钩子在提示、工具调用或输出将其移动到有风险的地方之前捕获敏感材料。Git 钩子在凭证进入提交历史或离开笔记本电脑之前捕获它们。持续集成和服务器端控制在代码到达共享系统后提供备份。
分层预防而不强制单独的工作流
开发者环境现在是连接的、自动化的，并且越来越多地由能够对本地上下文进行操作的工具辅助。安全必须考虑到这一现实。等待远程扫描对于凭证暴露来说太晚了。
更好的模型很简单：在更早的地方发现凭证，在它们出现的地方更近的地方阻止它们，并减少开发者的笔记本电脑成为进入软件供应链的最简单路径的可能性。
GitGuardian 的 ggshield、IDE 扩展、人工智能钩子和 Git 钩子都指向该模型。它们将检测带入开发者已经使用的地方，而不是要求开发者离开工作流去获取安全。它们减少错误和反馈之间的时间。它们让团队在本地开发、人工智能辅助编码、Git 工作流和自动化中拥有一致的检测引擎。
供应链现在包括工作站。
按这种方式对待它。