作者：韩启明｜OC 政策与安全编辑

安全研究者 Orchid Files 再次指出，GitHub 上仍能通过普通代码搜索找到一批向用户提供木马压缩包的仓库。这些仓库常使用相似 README、下载标题和带版本号的 ZIP 链接，部分模式已持续约两年。

一句话结论：问题不是 GitHub 完全没有删除恶意仓库，而是平台按举报批量清理后，没有把已知模式稳定转化为持续检测和阻断能力。

研究者此前编写脚本找到约一万个可疑仓库。GitHub 在文章传播后删除了这批仓库，但研究者称，同一脚本随后发现的新仓库仍能继续存在。最新文章还展示了几种任何用户都能执行的搜索条件，例如限定 README 中的下载标题，再匹配指向压缩包的链接。

这些数字需要谨慎理解。搜索结果数量会波动，其中也可能夹杂正常项目；VirusTotal 对文件的判定也不能自动证明整个仓库都由同一攻击者控制。因此，“数千个”描述的是搜索暴露出的可疑规模，不是经过 GitHub 或独立机构逐一确认的最终恶意仓库数。

但模式本身已经足够说明平台缺口。攻击者复制合法项目名称和历史，利用星标、README 和 GitHub 域名建立可信外观，再把真正载荷放进 Release、raw 链接或外部压缩包。用户看到的是熟悉的开源页面，下载的却可能是信息窃取程序。

为什么不能简单写一条规则全部删除？因为“README 有下载按钮和 ZIP”也是大量正常软件的常见结构，过度封禁会误伤。真正有效的检测需要结合账户创建时间、仓库复制关系、下载文件哈希、星标异常、提交模式和外部情报。问题不在于平台不知道一个关键词，而在于是否愿意长期为这类低成本滥用配置审核和响应资源。

开发者不能把 GitHub 域名当作安全认证。安装前仍应核对组织身份、发布签名、包管理器来源和文件哈希，尤其不要运行从陌生 README 下载的加密 ZIP 或可执行文件。

关键事实

• 来源：Orchid Files、安全研究与 GitHub 平台资料
• 常见伪装：复制正常项目、相似 README、下载压缩包、虚假活跃度
• 已知处置：研究者称 GitHub 曾删除其报告的一批约一万个仓库
• 尚未确认：当前所有搜索结果的准确恶意比例和攻击者归属

OC 判断

GitHub 面对的是持续生成的滥用网络，不是一次性脏数据。删除公开列表只能压低当下数量；如果相同模板很快重新出现，说明检测、账户治理和下载风险提示仍没有形成闭环。

为什么重要

• 对开发者：仓库页面、提交历史和星标都可能被伪造，不能替代签名验证。
• 对企业：应限制从未知 Release 和 raw 链接直接执行二进制文件。
• 对平台：安全响应需要衡量复发率，而不只是一次删除了多少仓库。

参考来源

• Orchid Files：What is GitHub's security team doing?
• GitHub：Acceptable Use Policies
• GitHub Blog：Inside the Advisory Database