一、背景概述
2025年底至2026年5月，一个被称为TeamPCP的威胁组织在全球范围内发起了一场规模空前、手法精密的软件供应链攻击行动。该组织以云原生基础设施和开发者生态系统为核心攻击目标，通过系统性地渗透和污染全球广泛使用的开源安全工具、AI开发框架、企业级SDK和代码编辑器扩展，构建了一条从单点入侵到全域失守的完整攻击链路。截至2026年5月底，该攻击活动已确认涉及至少十余波攻击序列（Campaign Wave），污染超过600个npm和PyPI软件包，覆盖超过50万台设备和服务器，窃取超过50万条各类凭证，直接和间接经济损失超过10亿美元。
TeamPCP并非孤立的黑产团伙。该组织也被业内同步追踪命名为DeadCatx3、PCPcat、ShellForce，并与CipherForce、Vect勒索软件组织存在关联。其攻击动机呈现出经济利益与地缘政治目标并存的双重特征：既通过凭证窃取和勒索变现获取非法收益，也针对特定国家和地区部署破坏性擦除载荷。在长达半年的活跃期内，TeamPCP逐步将其攻击能力从最初的云原生容器入侵，演进为具备自我传播功能的蠕虫级供应链攻击平台，并最终于2026年5月将完整的攻击框架源代码公开发布至GitHub，引发全球范围内的复制模仿潮。
本次攻击活动的核心特征在于其对"信任关系"的系统性利用。TeamPCP没有选择直接攻击最终用户，而是集中于渗透开发者与企业默认信任的环节——漏洞扫描器、CI/CD流水线、AI网关、官方SDK、代码编辑器扩展等。通过在这些高权限、高信任度的组件中植入恶意代码，攻击者实现了对全球开发环境的大规模、无感知渗透，彻底击穿了现行DevSecOps安全体系的底层信任假设。全球多家顶级安全厂商——包括Elastic、Trend Micro、Forcepoint、SentinelLabs、Wiz、Sysdig、Snyk、Socket、Endor Labs、Datadog等——均发布了针对该组织的专题分析报告。
本次攻击的完整时间线横跨2025年12月至2026年5月，在GitHub平台内部代码库泄露、微软官方SDK被投毒、AI领域核心工具被植入后门等标志性事件中达到高潮，并向全球安全界提出了一道无解的命题：当安全工具本身不再可信、当官方发布渠道无法保障安全、当数字签名和构建证明可以被伪造——我们的软件开发与分发体系，究竟还能依赖什么？
二、攻击活动时间线与关键事件
TeamPCP的攻击行动经历了从云原生环境初始渗透、到供应链投毒大规模爆发、再到攻击框架开源化扩散的完整演进过程。根据全球多家安全厂商的追踪记录，可将其攻击活动划分为以下六个关键阶段：
2.1 第一阶段：云原生初始渗透（2025年12月—2026年2月）
TeamPCP的首次公开曝光始于2025年12月底，安全研究人员观察到一场针对云原生环境的"蠕虫驱动"大规模攻击活动。攻击者利用暴露的Docker API接口、Kubernetes集群、Ray仪表板和Redis服务器等云原生基础设施组件，系统性建立恶意网络，用于后续的网络犯罪活动。这一阶段的攻击特征以凭证窃取和持久化后门植入为主，攻击者通过批量扫描互联网暴露的云服务端口获取初始访问权限。
2026年2月，TeamPCP进一步演化其攻击手段，开始利用窃取的云凭据进行横向移动，并在被攻陷的环境中部署名为CanisterWorm的后门程序。Elastic Security在这一时期发布了针对TeamPCP容器攻击场景的专题检测工程分析，详细记录了攻击者从初始漏洞利用、容器逃逸到集群横向移动的完整攻击链路。
2.2 第二阶段：Trivy供应链投毒及连锁反应（2026年3月）
2026年3月18日至19日，TeamPCP发动了其攻击生涯中最具影响力的单次行动——对全球顶级开源漏洞扫描器Trivy的全链路供应链投毒。Trivy由Aqua Security公司维护，在GitHub上拥有超过3.3万Star，Docker Hub累计下载量超1亿次，是全球DevSecOps体系中的核心安全组件。
攻击者通过前期窃取的Aqua Security相关仓库的高权限维护凭证，对Trivy的GitHub Actions组件（trivy-action、setup-trivy）发起强制推送攻击，批量篡改仓库中76个版本标签中的75个，仅0.35.0版本侥幸未受影响。同步地，攻击者向Docker Hub推送了无官方发布记录的v0.69.5、v0.69.6恶意镜像，并向GitHub Releases、GHCR和ECR等所有分发渠道同步投毒。由于攻击者在恶意代码中完整保留了Trivy的正常扫描功能，仅在扫描逻辑执行前静默植入凭证窃取程序，绝大多数用户在使用过程中完全无法察觉异常。
此次攻击的直接波及范围创下近年纪录：GitHub生态中超10万个开源项目调用了受污染的Trivy Actions；Docker Hub恶意镜像累计拉取量超百万次。更为严重的是，攻击者从失陷的CI/CD流水线中窃取了数十万条高价值凭证，为后续更大规模的供应链攻击储备了充足的"弹药"。此事件被追踪为CVE-2026-33634（CVSS评分9.4）。
从3月19日起，TeamPCP利用从Trivy事件中窃取的凭证，接连发起针对多个知名开源项目的精准打击：3月23日至24日，利用窃取的GitHub PAT令牌入侵Checkmarx公司KICS静态分析工具的GitHub Actions工作流和OpenVSX扩展市场，同时攻击AI网关LiteLLM的PyPI包（1.82.7和1.82.8版本），在40分钟内窃取超过50万条凭证；3月27日，入侵PyPI包Telnyx（v4.87.1/v4.87.2），累计影响超74.2万次下载。在上述攻击中，TeamPCP均采用Python的.pth文件机制或npm的postinstall钩子实现安装时即自动执行恶意代码。
2.3 第三阶段：CanisterWorm蠕虫扩散与勒索变现尝试（2026年3月下旬—4月中旬）
CanisterWorm是TeamPCP开发的具备自我传播能力的供应链蠕虫，标志着该组织的攻击能力从"手动定向投毒"升级为"自动化生态级扩散"。该蠕虫的核心逻辑极为精妙：利用从Trivy等事件中窃取的npm发布凭证，自动登录受害者账号，遍历该账号下所有开源包，逐一推送植入同源恶意代码的patch版本。新的恶意包被下载后会继续窃取新的凭证，形成指数级扩散链条。
CanisterWorm最独特的技术特征是其对ICP（Internet Computer）区块链的创造性滥用。攻击者将C2逻辑编写成智能合约（Canister）部署在ICP区块链上，恶意代码通过与智能合约交互获取指令和上传数据。由于区块链的去中心化特性，该C2基础设施无法通过传统的域名封禁或IP封锁方式关停，极大提升了防御方的溯源与反制难度。这是全球首次公开记录的利用ICP区块链进行恶意命令控制的案例。
在2026年3月下旬，TeamPCP在CanisterWorm的载荷中新增了针对伊朗的定向数据擦除功能（被称为"kamikaze.sh"）。该破坏性载荷通过双重检测机制——系统时区是否为Asia/Tehran以及默认语言是否为波斯语——精确识别伊朗环境。对匹配的Kubernetes集群，部署名为host-provisioner-iran的特权DaemonSet，挂载主机根文件系统后删除所有顶层目录并强制重启；对非Kubernetes的伊朗系统，直接执行rm -rf /命令。对非伊朗系统则仅保持静默后门，不做破坏。
2026年4月15日，与TeamPCP关联的Vect勒索软件组织开始在暗网发布受害者数据，受害者数量达25个，标志着TeamPCP将窃取的凭证正式转化为勒索变现渠道。然而，截至5月底，Vect和CipherForce的受害者网站均保持长期静默，多家安全厂商推测其勒索变现渠道已受损。
2.4 第四阶段：多波次精准打击与杀伤链精炼（2026年4月22日—5月11日）
2026年4月下旬至5月上旬，TeamPCP连续发动了至少七波经Trend Micro确认的供应链攻击，这一阶段的攻击呈现出三个显著特征：一是从单一渠道投毒升级为多通道同步污染；二是攻击目标从开源工具向企业级商业SDK和AI基础设施扩展；三是攻击框架从定制化工具向标准化、模块化平台演进。
4月22日，TeamPCP同时对Checkmarx KICS的三个分发渠道发动攻击：修改Docker Hub上的六个官方镜像标签（alpine、debian、latest、v2.1.20、v2.1.20-debian以及伪造的v2.1.21），向OpenVSX推送恶意VS Code扩展（cx-dev-assist和ast-results），修改GitHub Actions工作流以序列化全部仓库密钥。三个渠道的载荷均下载Bun运行时并执行约10MB的JavaScript凭证窃取程序mcpAddon.js，窃取目标涵盖GitHub PAT、npm Token、AWS/Azure/GCP云凭证、SSH私钥、AI和MCP配置文件以及Shell历史记录。24小时内，攻击者即利用窃取的npm令牌发布了恶意Bitwarden CLI版本（v2026.4.0），约334次下载发生在93分钟的暴露窗口内。
4月24日，TeamPCP通过一次极为简洁的GitHub Actions脚本注入攻击攻陷了elementary-data项目（PyPI月下载量超110万次）。攻击者仅在一个Pull Request的评论区中发布了一条curl管道到bash的命令，利用workflow中未经过滤的${{ github.event.comment.body }}表达式直接在CI Runner上执行了任意命令。利用Runner持有的GITHUB_TOKEN，攻击者伪造了带标签的发布提交并触发了项目自身的合法发布流水线——最终生成并签名了一个包含恶意.pth文件的"官方"版本，通过了PyPI所有标准校验。
4月30日，TeamPCP入侵PyTorch Lightning的PyPI账号，发布恶意版本2.6.2和2.6.3。恶意代码在import lightning时自动激活，18分钟后即被Socket安全团队检测并下架，但期间已有数万次下载。同期的攻击目标还包括Axios、SAP官方npm SDK、Intercom官方包和Xinference PyPI包等，实现了从前端生态到企业级软件的全覆盖。
2.5 第五阶段：Mini Shai-Hulud蠕虫爆发与攻击框架开源化（2026年5月11日—5月24日）
2026年5月11日，TeamPCP发动了其最具破坏性的单次攻击——Mini Shai-Hulud蠕虫攻击。当日攻击者劫持了TanStack官方发布流水线，在短短六分钟内通过OIDC令牌滥用机制向npm推送了42个@tanstack命名空间下包的84个恶意版本，其中包括每周下载量超过千万级的@tanstack/react-router。这一波攻击创造了供应链攻击史上两项"首次"：首次携带有有效SLSA Build Level 3构建签名的恶意npm包，以及首次在单个小时内实现如此高密度的恶意版本发布。
Mini Shai-Hulud具备完全自动化的自我复制能力，其传播机制打破了传统供应链攻击的边界：每个被感染的开发者不仅自身凭证被窃取，其维护的所有npm包也将在无人干预的情况下被自动植入同源恶意代码。蠕虫载荷在npm install期间即执行（通过preinstall钩子），窃取超过20类凭证——GitHub和npm Token、AWS密钥、GCP和Azure令牌、SSH密钥、Kubernetes服务账户、HashiCorp Vault密钥、Stripe API密钥以及1Password和Bitwarden本地密码库。持久化机制通过在~/.claude/settings.json和.vscode/tasks.json中植入钩子，使恶意代码在IDE和AI编码助手启动时重新激活。
5月12日，TeamPCP将Mini Shai-Hulud的完整框架源代码公开发布至GitHub，仓库README中明确标注"Love - TeamPCP"和"Change keys and C2 as needed"。这是一次蓄意的攻击能力扩散行为。Datadog Security Labs的分析显示，这是一个模块化的TypeScript/Bun工具包，涵盖凭证收割、供应链投毒和加密外传的完整功能。在源码发布的数小时内，至少出现了三个独立的复制分支，其中一个甚至增加了FreeBSD支持。截至5月19日，已有47个可独立运行的变种被全球安全厂商确认，影响范围从前端npm生态迅速蔓延至PyPI、Packagist、RubyGems等多个开源包管理平台。
2.6 第六阶段：GitHub内部入侵与微软SDK投毒（2026年5月18日—5月24日）
2026年5月18日，TeamPCP通过一条精心设计的多级攻击链入侵了GitHub内部系统。攻击者利用5月11日TanStack事件中通过OIDC滥用（追踪为CVE-2026-45321）窃取的凭证，向Visual Studio Marketplace推送了恶意Nx Console VS Code扩展（v18.95.0，发布者nrwl.angular-console，带有verified-publisher徽章，约220万安装量）。该恶意扩展在市场上存活了约18分钟，但由于VS Code的自动更新机制，GitHub一名员工的开发端点在此期间完成了自动升级。攻击者通过该端点窃取了开发者密钥，随后横向移动进入GitHub内部CI/CD系统，最终外传了约3,800个GitHub内部代码仓库。GitHub CISO Alexis Wales于5月21日公开确认此事，并指出OpenAI、Grafana Labs和Mistral AI为下游受害者。
5月19日，攻击进一步升级：TeamPCP向PyPI发布了微软官方durabletask Python SDK（Azure Durable Functions客户端，月下载量约41.7万次）的恶意版本1.4.1至1.4.3，恶意代码在约35分钟的窗口内存活。该载荷的第二阶段被独立报告描述为携带Linux磁盘擦除器，同时具备凭证窃取和云环境内自传播功能（通过AWS SSM在EC2内部传播、通过kubectl exec在Kubernetes内部传播）。同日，TeamPCP通过攻陷的维护者账号"atool"，向@antv npm生态发布了639个恶意包版本（涵盖323个独立包），包括每周下载量约110万的echarts-for-react和约420万的size-sensor。其中42个恶意包在npm UI中展示了伪造的Sigstore验证徽章。
5月22日，Shai-Hulud框架源码在GitHub公开发布并被多个独立攻击者复制使用，引发了全球范围内对TeamPCP攻击手法的大规模模仿。5月24日的ISC SANS日记中，安全研究员Kenneth Hartman以"单周内三次叠加升级"为标题总结了这一阶段：GitHub内部入侵、微软官方SDK被投毒、@antv npm生态遭史上最大单波污染，三项事件在72小时内密集发生。
三、攻击技战术深度分析
TeamPCP的攻击技术体系呈现出高度专业化、模块化和持续演进的显著特征。其技战术（TTPs）经过至少五轮迭代优化，已从最初的手动容器入侵发展为具备自我传播能力的自动化供应链攻击平台。综合全球多家安全厂商的技术分析，可将该组织的核心攻击技法归纳为以下七个方面：
3.1 初始访问：多层次凭证窃取与信任关系渗透
TeamPCP不依赖零日漏洞进行初始突破，而是系统性地利用现代软件开发体系中的信任关系和权限缺口获取初始访问权。其主要入口向量包括：通过钓鱼邮件和社会工程学攻击窃取开源项目维护者的账号凭证和API令牌；扫描互联网暴露的Docker API（端口2375）、Kubernetes集群、Ray仪表板和Redis服务器等未授权访问的云原生服务；利用前期攻击中窃取的GitHub PAT和npm Token进行凭证复用（Credential Stuffing）；以及通过GitHub Actions工作流中的Pull Request评论注入漏洞在CI Runner上执行任意命令。
在elementary-data事件中，攻击者仅通过一条Pull Request评论就获得了CI Runner的完整控制权，无需窃取任何维护者凭证即可利用项目自身的签名基础设施发布恶意版本。在微软durabletask事件中，攻击者则直接通过窃取的PyPI发布令牌向官方仓库推送恶意版本，表明其已经成功渗透了项目维护者的凭证体系。
3.2 执行机制：三运行时多态引导与隐式代码执行
TeamPCP开发了一套覆盖JavaScript/Bun、Python和Bash三种运行时的多态载荷引导体系，确保恶意代码能在最广泛的CI/CD和开发环境中实现自动执行。在npm生态中，攻击者通过package.json的preinstall或postinstall脚本在包安装时即触发恶意代码执行，利用Bun运行时的高性能特性在正常安装时间窗口内完成全量凭证扫描。在Python生态中，攻击者通过.pth文件（如litellm_init.pth、elementary.pth）注入恶意代码——任何以"import"开头的.pth文件行将在Python解释器启动时自动执行，无需用户显式导入被污染的包，影响范围覆盖该主机上所有Python进程。
Sha1-Hulud（即Shai-Hulud的公开版本）的源代码分析揭示了三个完全独立的引导路径：Bun/JavaScript主路径、Python备选路径和Bash三级路径。每次攻击活动中，攻击者都会轮换载荷文件名和执行钩子，通过操作层面的多态性规避基于哈希和文件名的静态检测规则。
3.3 凭证窃取：从环境变量到进程内存的全维度收割
凭证窃取是TeamPCP所有攻击活动的基础目标，其窃密载荷的覆盖范围远超常规信息窃取木马。在文件系统层面，载荷扫描超过100个预定义路径，涵盖~/.ssh/私钥、~/.kube/config集群凭证、~/.docker/config.json容器仓库凭证、~/.npmrc和.pypirc包注册表令牌、~/.aws/credentials和~/.azure/云凭证文件、~/.git-credentials Git认证信息、Shell历史记录（.bash_history、.zsh_history）以及AI编码助手配置文件（~/.claude.json、~/.claude/mcp.json、~/.claude/settings.json）。
在环境变量层面，载荷遍历所有进程环境变量，批量匹配包含KEY、TOKEN、SECRET、PASSWORD、CREDENTIALS等关键词的敏感值。在云API层面，载荷通过完整的AWS SigV4凭证解析链（环境变量→INI配置文件→IRSA OIDC→ECS容器元数据→EC2 IMDS）实现自动化的云环境适配，并通过AWS SSM和Secrets Manager API在跨区域维度上进行全量密钥枚举。在进程内存层面，最危险的技术是Runner Secret Dump——载荷通过sudo python3 -c执行AES-256-GCM加密的Python脚本，读取GitHub Actions Runner Worker和Listener进程内存，提取所有被注入的Secret，包括被GitHub标记为masked的敏感值。
所有窃取的数据经AES-256-GCM（随机会话密钥）加密后，会话密钥再通过攻击者的RSA-OAEP公钥加密，最后以Base64编码外传。在KICS事件中还引入了通过创建公开GitHub仓库（以沙丘系列小说中的词汇命名）作为辅助死信箱的传输机制。
3.4 命令与控制：ICP区块链C2与多层基础设施轮换
TeamPCP在C2架构设计中展现了极高的对抗性思维。其最具创新性的技术是利用ICP区块链的智能合约（Canister）作为C2服务器——将C2逻辑编写为部署在去中心化网络上的不可删除的智能合约，恶意代码通过与智能合约的标准API交互获取命令并上传数据，通信流量在外观上与正常的区块链交易无异。CanisterWorm使用的ICP Canister地址为tdtqy-oyaaa-aaaae-af2dq-cai.raw.icp0.io。
在传统HTTP C2方面，TeamPCP通过Cloudflare隧道域名进行载荷分发和C2通信轮换，增加了网络层拦截难度。Bitwarden CLI恶意版本还引入了C2域名恢复机制：如果主C2不可达，载荷会通过GitHub Commit Search API搜索特定的commit marker字符串，自动检索RSA签名的备用外传域名，实现基础设施热切换。此外，TeamPCP在整个攻击活动中使用了大量一致的特征标记，包括：X-Rise-To-The-Trinny: agree和X-Filename: tpcp.tar.gz等品牌化HTTP头、tpcp.tar.gz统一归档文件名、以沙丘词汇命名的GitHub仓库、commit message标志"LongLiveTheResistanceAgainstMachines"、以及复用的Session Messenger标识符作为XOR加密密钥种子。
3.5 持久化机制：IDE与AI编码助手注入
TeamPCP设计了一套覆盖开发者工作环境全生命周期的持久化体系，远超传统恶意软件对操作系统启动项的依赖。在IDE层面，攻击者在.vscode/tasks.json中植入恶意任务定义，使VS Code在特定触发条件下自动执行恶意代码。在AI编码助手层面，攻击者在~/.claude/settings.json中注入配置，使Anthropic Claude编码助手在启动时激活恶意载荷。在Python层面，通过site-packages中的.pth文件实现在每次Python解释器启动时重新激活。在系统服务层面，恶意代码安装名为internal-monitor或pgmonitor的systemd服务，以及在Windows Startup文件夹中植入启动项，确保跨操作系统的持久化。
LiteLLM v1.82.8版本中引入的Sysmon.py持久化模块实现了一个基于轮询的远程代码执行后门：首次启动时休眠300秒，随后每50分钟（3000秒）检查hxxps[://]checkmarx[.]zone/raw，如果响应中包含以"http"开头的URL，则下载文件至/tmp/pglog并作为后台进程执行。
3.6 横向移动与蠕虫传播：从单点到生态级的攻击扩散
TeamPCP设计了多层次的横向移动和自传播机制。在npm/PyPI生态层面，CanisterWorm和Mini Shai-Hulud蠕虫利用窃取的包注册表令牌，自动扫描受害者可发布的所有包，逐包推送植入恶意代码的新版本，实现无人干预的自动化扩散。在云环境层面，载荷通过AWS SSM在EC2实例之间、通过kubectl exec在Kubernetes Pod之间进行横向移动。在SSH层面，最新版擦除器载荷（第三版）解析SSH认证日志识别曾连接的机器，窃取私钥后尝试重新连接并传播载荷。在Docker层面，载荷扫描本地子网2375端口暴露的Docker API，向未授权的Docker守护进程部署恶意容器。
Mini Shai-Hulud的"受害者变传播者"机制是这一体系的核心创新：每个被感染的开发者和CI/CD流水线都成为蠕虫的传播节点。攻击者还利用GitHub Actions的OIDC令牌机制（id-token: write权限配合pull_request_target触发器），在合法的CI/CD流程内生成附带有效Sigstore签名的恶意包，使其通过npm audit签名校验，传统SCA工具完全无法检测。
3.7 防御规避：签名伪造、全兼容投毒与多态混淆
TeamPCP在防御规避领域的投入不亚于其攻击能力。在签名伪造方面，Mini Shai-Hulud通过劫持的OIDC令牌生成了通过SLSA Build Level 3认证的有效Sigstore构建签名，42个@antv恶意包在npm UI中展示了伪造的Sigstore验证徽章，从两方面同时对软件供应链的签名信任体系发起冲击。
在投毒隐蔽性方面，TeamPCP始终坚持"全兼容"投毒原则——恶意代码完整保留被污染工具的正常功能（如Trivy继续正常扫描、LiteLLM继续正常代理API），使用户体验完全不受影响，从行为层面消除可疑信号。在代码混淆方面，载荷通过AES-256-GCM加密所有敏感字符串常量，加之操作层面的多态性（文件名、钩子类型、外传路径的持续轮换），使基于静态特征的安全检测大面积失效。
在环境检测方面，载荷通过多重反调试和反沙箱机制（GetTickCount时间检测、CheckRemoteDebuggerPresent调试器检测、进程列表枚举排查Wireshark/Process Monitor等分析工具）识别安全分析环境，一旦确认即主动终止执行。攻击者还在LiteLLM和Xinference等载荷中嵌入复用的Session Messenger标识符作为XOR加密密钥种子，该标识符同时作为操作者联系方式，成为跨攻击波次的关键关联标记。
四、事件影响评估
TeamPCP发起的这起持续性供应链攻击行动，其影响已远超单次安全事件的范畴，对整个全球软件开发与安全体系产生了深层次的冲击：
4.1 直接影响：超大规模失陷与凭证泄露
从量化维度来看，本次攻击行动的直接影响堪称近年来供应链安全领域的极端事件。超过600个npm和PyPI软件包被植入恶意代码，50万台以上设备和服务器受到影响，超过50万条各类凭证被窃取，涵盖GitHub Token、云平台AccessKey、npm/PyPI发布令牌、SSH私钥、Kubernetes集群凭证、密码管理器数据库等核心安全资产。GitHub内部约3,800个私有代码仓库源码被外传，欧盟委员会超过90GB的敏感数据被窃取。直接和间接经济损失初步估计超过10亿美元。受影响企业和机构涵盖GitHub、微软、OpenAI、Mistral AI、Grafana Labs、SAP、Intercom、Bitwarden、Checkmarx、Aqua Security、Cisco等全球知名组织。
4.2 信任体系崩塌：安全工具不再保证安全
TeamPCP的攻击在本质上是针对现代软件开发信任体系的精准打击。长久以来，开发者社区对"安全工具自带安全性"的假设根深蒂固——漏洞扫描器、静态分析工具、密码管理器等被视为安全防线最可信赖的组成部分，被赋予了最高的系统权限。Trivy和KICS事件的讽刺在于：安全工具本身变成了最大的攻击载体，攻击者通过投毒安全工具获得了对企业CI/CD流水线的"万能钥匙"级访问权限。正如安全界广为流传的评论所言："你用Trivy来扫描漏洞、防范供应链攻击，而Trivy本身就是最大的供应链攻击载体。"这种信任悖论从根本上动摇了DevSecOps的理论前提。
4.3 数字签名体系遭受双重攻击
Mini Shai-Hulud攻击在软件供应链安全领域引发了一场关于签名信任的危机。该攻击同时从两个方向击穿了现有的数字签名验证体系：一方面，通过劫持合法的发布流水线产生附带有效SLSA签名和Sigstore构建证明的恶意包；另一方面，在npm UI中展示伪造的Sigstore验证徽章误导开发者。这组攻击证明了：发布者账户的合法性与单次发布事件的安全性是完全不同的两个维度，而现有的验证体系将两者混为一谈。elementary-data事件进一步揭示了深度问题——即使是项目自身CI基础设施签名发布的包，也可以是恶意的。
4.4 攻击能力扩散：从APT级能力到"开源攻击平台"
TeamPCP于2026年5月12日将Shai-Hulud框架完整源代码公开发布至GitHub，标志着其攻击策略从"保持技术优势"转向"蓄意扩散攻击能力"。截止5月19日，全球已出现47个可独立运行的变种，至少3个复制分支在代码发布后数小时内即开始活跃部署。这一行为将原本属于高级威胁组织专属能力的供应链蠕虫攻击技术，转化为任何具有基础编程能力的攻击者都可以获取并部署的标准化工具。对于防御方而言，这意味着基于TeamPCP特定框架构件的检测规则将面临大规模误报——无法区分TeamPCP本体的攻击与模仿者的攻击，归因难度呈指数级增加。
五、总结与展望
TeamPCP组织在2025年底至2026年5月间发起的这场持续性全球软件供应链攻击行动，是有史以来规模最大、链条最长、创新密度最高的供应链安全事件之一。它从根本上改写了行业对供应链安全威胁模型的认知，揭示出现行DevSecOps体系在信任架构层面的结构性缺陷。
该组织的攻击行动呈现出四个核心特征：其一，"上游突破、下游感染"的策略实现了以最小攻击成本换取最大化影响范围；其二，"全兼容、无感知"的投毒设计让传统安全检测手段大面积失效；其三，从手动投毒到蠕虫自动传播、从单点攻击到生态级扩散的能力跃迁，展现了惊人的攻击策略迭代速度；其四，攻击框架的开源化发布，标志着一个新的威胁时代到来——高级供应链攻击能力已经完成从专属到普惠的蜕变。
面对TeamPCP所揭示的行业痛点，安全界必须从三个维度展开系统性变革。在信任架构层面，必须全面转向零信任原则——不再默认信任任何组件、任何发布者、任何签名，对所有引入的第三方代码和工件执行哈希校验、数字签名验证和行为基线评估。在工具链安全层面，必须对CI/CD流水线和安全工具本身实施与生产环境同等严格的安全管控——禁止force-push覆盖已发布标签，实现版本不可变性，对安全工具的行为进行实时监控与异常审计。在平台责任层面，GitHub、npm、PyPI、Docker Hub等平台必须将供应链安全能力内置为基础功能——默认开启分支保护和标签保护，默认要求制品签名校验，默认拦截敏感环境变量批量读取和未知外部域名访问等恶意行为。
正如Trend Micro在其分析报告中所指出的："TeamPCP并不依赖传统漏洞进行攻击。它滥用了开发者、CI/CD流水线和包注册表之间的信任关系——而这些关系正是现代软件供应链得以正常运行的基础。"在信任被系统性地武器化之后，重建信任将是整个行业未来数年面临的核心命题。
参考来源：
1. ISC SANS Diary: TeamPCP Supply Chain Campaign Activity Through 2026-05-24 (Kenneth Hartman, 2026-05-25)
2. ISC SANS Diary: TeamPCP Supply Chain Campaign Activity Through 2026-05-17 (Kenneth Hartman, 2026-05-18)
3. Trend Micro: Analyzing TeamPCP Supply Chain Attacks - Checkmarx KICS and elementary-data (May 13, 2026)
4. Forcepoint: How TeamPCP Turned LiteLLM into a Credential Harvesting Tool (Prashant Kumar, 2026-05-18)
5. PolySwarm: Inside TeamPCP Supply Chain Offensive (The Hivemind)
6. Phoenix Security: Sha1-Hulud / Shai-Hulud Full Technical Dissection (2026-05-13)
7. Elastic Security: TeamPCP Container Attack Scenario (Ruben Groenewoud, 2026-03-20)
8. FreeBuf: TeamPCP组织部署针对伊朗的Kubernetes擦除器，破坏性CanisterWorm攻击升级 (2026-03-26)
声明：本文来自白泽安全实验室，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
