适合国内用的虚拟币交易所
北京时间5月20日，代码托管平台GitHub通过其官方账号发布了一则声明，正式承认其内部仓库遭遇了未授权存取。目前，相关调查正在进行中。
公告中，GitHub试图安抚用户，强调“目前没有证据显示储存在GitHub内部仓库以外的客户信息受到影响”，并承诺会持续监控基础设施，一旦发现任何影响将及时通知客户。然而，对于将核心资产托付于此的开发者，尤其是加密货币项目团队来说，这声警报的份量，远不止于此。
Grafana、CISA、Sail Point：一个月内连环爆
这次事件并非孤例，而是近期一系列针对代码托管平台攻击的最新一环，其波及范围之广、目标之要害，令人咋舌。
就在几天前的5月16日，知名监控平台Grafana Labs公开确认，因GitHub Token外泄，其完整代码库被攻击者下载并遭勒索。Grafana的回应是拒绝付款。
更令人震惊的案例发生在5月14日。美国网络安全和基础设施安全局（CISA）的一个内部GitHub仓库“Private-CISA”被发现对外公开了整整六个月。其中包含844MB的明文密码、AWS令牌以及Entra ID SAML凭证。连国家级网络防御机构都因仓库设置疏失而“翻车”，外媒The Register的评论一针见血：部分文件名称“明显到令人难以置信”。
同月，身份安全公司Sail Point的GitHub仓库同样未能幸免。安全媒体Security Affairs指出，这显示攻击者的矛头已经直接指向了那些本应掌管大量凭证的网络安全厂商自身。
Coinbase、Bitwarden CLI是前车之鉴
对于加密货币行业而言，GitHub基础设施被渗透的后果，早已有血淋淋的案例摆在眼前。
2026年3月，Palo Alto Networks旗下Unit42团队披露了一起精准的供应链攻击。攻击者的首要目标就是Coinbase的开源项目agentkit。在Coinbase成功侦测并封锁后，攻击者迅速转移阵地，成功劫持了当时广泛使用的GitHub Action“tj-actions/changed-files”。这一招“围魏救赵”，最终波及了23,000个仓库，其中218个仓库的敏感密钥（secrets）实际发生了泄露。
紧接着在同年4月至5月，“second-action”等15个热门GitHub Action标签遭恶意篡改，指向包含恶意代码的提交。这起影响广泛的标签劫持事件，再次暴露了依赖链的脆弱性。
而最直接冲击普通加密用户的，莫过于Bitwarden CLI事件。攻击者通过被入侵的GitHub Action，在Bitwarden CLI的2026.4.0版本中植入了恶意的npm包。该程序会主动窃取用户电脑上的MetaMask、Phantom及Solana钱&包文件。这个攻击链清晰地演示了“CI/CD管道 → 软件包管理器 → 终端用户钱&包”的三段式收割路径，每一步都踩在行业痛点上。
真正的风险：是GitHub的签署金钥
GitHub的声明将焦点放在了“客户仓库安全”上，但安全社区的担忧早已指向了更深层、更致命的威胁。
试想，如果攻击者在GitHub内部系统中成功横向移动，他们真正觊觎的目标会是什么？很可能是软件签署密钥——有了它，攻击者可以伪造看似合法的软件更新；也可能是CI/CD系统的控制权——这允许他们在任意时间点向海量项目注入恶意代码；甚至是Dependabot或GitHub Actions的执行上下文——一旦被污染，所有依赖这些自动化工具的下游项目都将遭殃。
近期，工程圈内的知名评论者Gergely Orosz和开发者Mario Zechner都公开批评GitHub在稳定性和安全性上的下滑趋势。Zechner更是直言不讳：“GitHub不再是一个可靠平台，每天都有东西坏掉。”这种来自资深用户的信任流失，或许比单次安全事件更值得警惕。
加密项目现在能做什么
面对持续升温的GitHub供应链威胁，坐等调查结果绝非上策。安全专家普遍建议，加密货币及相关项目应立即审视并加固自身防线，以下是四项核心措施：
第一，锁定Actions到完整SHA。 在配置GitHub Actions时，务必使用完整的提交SHA哈希值来引用操作，而不是使用标签（tag）或分支（branch）名称。这是防止标签劫持攻击最有效的一步。
第二，隔离并最小化Secrets权限。 使用GitHub的Environment功能来隔离敏感凭证，并为每个环境配置最小必要权限。避免使用一个“万能”Token，确保单一凭证泄露不会导致全线崩溃。
第三，启用推送保护与高级安全功能。 开启GitHub的Push Protection功能，它能在代码推送阶段就拦截意外上传的凭证。同时，考虑启用GitHub Advanced Security（GHAS），提供更深入的代码扫描和秘密检测。
第四，物理分离签名密钥。 将用于开发测试的签名密钥与用于生产环境正式版本发布的密钥进行物理分离。即使CI/CD环境被攻破，攻击者也无法伪造正式版本的软件签名，为用户留下最后一道验证屏障。
目前，GitHub的调查仍在进行，承诺将通过既有渠道更新进展。但对于那些将整个开发、构建和部署管道都构建在GitHub生态之上的加密货币项目而言，这次内部入侵事件的最终影响范围，恐怕要等到GitHub完成全面的内部取证后才能尘埃落定。在此之前，主动防御远比被动等待更为明智。
