Entre março e maio de 2026, um grupo de ameaça até então desconhecido, denominado TeamPCP, executou a campanha de supply chain attack mais abrangente alguma vez documentada contra ferramentas de segurança open source. Em apenas 12 dias, cinco projetos críticos foram comprometidos. Em abril, o CLI do Bitwarden distribuiu código malicioso por 93 minutos. Em maio, 630 versões infetadas atravessaram 317 pacotes npm em menos de 20 minutos. O alvo não eram utilizadores comuns: eram as próprias ferramentas que os profissionais de segurança usam para proteger sistemas.
O Que é o TeamPCP e Como Surgiu
O TeamPCP é o nome atribuído pelos investigadores da Phoenix Security ao grupo responsável pela vaga de ataques à cadeia de fornecimento de software open source iniciada a 19 de março de 2026. Pouco se sabe sobre a identidade dos seus membros ou sobre a sua localização geográfica. O que está documentado é a sua metodologia: comprometer contas com permissões elevadas em repositórios GitHub de ferramentas amplamente distribuídas e substituir versões legítimas por builds com um ladrão de credenciais de três etapas, internamente designado “TeamPCP Cloud Stealer”.
A investigação conduzida pela Phoenix Security e posteriormente confirmada pela Microsoft, Sophos e Ars Technica revelou que o vetor inicial foi um token de acesso pessoal (PAT) do GitHub que não tinha sido completamente rotacionado após um incidente anterior. Esta falha operacional, negligenciada por uma equipa de segurança de uma empresa de renome, deu ao atacante o ponto de entrada necessário para comprometer não um, mas vários projetos de forma encadeada.
Paul McCarty, investigador da Phoenix Security que divulgou publicamente o ataque a 23 de março de 2026, foi dos primeiros a ligar os pontos entre o compromisso inicial do Trivy e a cascata subsequente: “O atacante não estava à procura de um alvo isolado. Estava a mapear a rede de confiança entre ferramentas usadas em pipelines de CI/CD. Comprometer o Trivy era apenas o começo.”
O Ataque Inicial: Trivy Comprometida a 19 de Março de 2026
O Trivy é o scanner de vulnerabilidades open source mais utilizado em pipelines DevSecOps. Desenvolvido pela Aqua Security, é adotado por equipas de segurança em empresas de todos os tamanhos para identificar CVEs em imagens de containers, código-fonte e dependências. É precisamente por esta razão que se tornou um alvo prioritário.
A 19 de março de 2026, o TeamPCP obteve acesso à conta GitHub da Aqua Security através do PAT comprometido e procedeu a um ataque em múltiplas frentes. Foram comprometidos três componentes distintos do ecossistema Trivy: o binário central do scanner, a GitHub Action trivy-action e a GitHub Action setup-trivy. A estratégia de atingir simultaneamente o binário e as Actions garantiu que qualquer pipeline CI/CD que usasse o Trivy, independentemente de como o integrasse, acabaria por executar o código malicioso.
O payload inserido nos builds era um ladrão de credenciais sofisticado. A sua função: procurar e exfiltrar tokens de repositório GitHub, chaves SSH, tokens npm e outras credenciais armazenadas em ambientes de desenvolvimento. Os dados eram enviados para dois endereços de comando e controlo (C2): 94.154.172.43 e audit.checkmarx.cx, este último deliberadamente concebido para mimetizar domínios legítimos da Checkmarx.
A equipa de segurança da Microsoft, que publicou orientações de deteção e defesa a 24 de março, descreveu a sofisticação do ataque: “Os atacantes aproveitaram o acesso previamente não remediado para injetar malware de roubo de credenciais em lançamentos oficiais do Trivy. O ataque comprometeu simultaneamente o binário central do scanner, a GitHub Action trivy-action e a GitHub Action setup-trivy, armando ferramentas de segurança confiáveis contra as organizações que dependem delas.”
O relatório do RTX à Securities and Exchange Commission (SEC), apresentado a 19 de setembro, e os padrões identificados pelos investigadores da Phoenix Security convergem para a mesma conclusão: o TeamPCP não executou um ataque de força bruta, mas sim uma exploração metódica de confiança implícita. O atacante sabia exatamente que ferramentas estavam ligadas entre si e aproveitou essa topologia como vetor de propagação.
Cascata de Comprometimento: Checkmarx Atingida em 4 Dias
A Checkmarx é uma das maiores empresas de segurança de código no mundo, conhecida pelos seus scanners SAST (Static Application Security Testing) e pelas ferramentas KICS (Keeping Infrastructure as Code Secure). A ironia do que aconteceu a 23 de março de 2026 não passou despercebida à comunidade de segurança: uma empresa cujo produto principal é encontrar vulnerabilidades no código de terceiros tornou-se, ela própria, um vetor de ataque.
O acesso inicial à conta GitHub da Checkmarx foi conseguido através das credenciais roubadas durante o compromisso do Trivy, quatro dias antes. O TeamPCP não perdeu tempo. Foram comprometidos dois plugins no marketplace OpenVSX, dois workflows de GitHub Actions, bem como artefactos distribuídos externamente, incluindo extensões VS Code e um plugin Jenkins. No total, o atacante manipulou mais de 110 versões (tags) em quatro repositórios distintos da Aqua Security e da Checkmarx, usando a técnica de force-push para substituir commits legítimos por commits maliciosos.
A Checkmarx publicou um comunicado oficial no seu blog a 23 de março confirmando o incidente: “A 23 de março de 2026, a Checkmarx identificou que atacantes obtiveram acesso não autorizado aos repositórios GitHub da Checkmarx. Este acesso ocorreu a 19 de março de 2026 devido ao Supply Chain Attack do Trivy.”
Num período de 40 dias, a Checkmarx enfrentou pelo menos dois compromissos de supply chain distintos. A agravante: o grupo de ransomware Lapsu$ publicou simultaneamente dados privados da empresa na dark web, num ataque paralelo que não foi atribuído ao TeamPCP.
A análise da Phoenix Security documentou a topologia completa do compromisso: “Partindo de um único token de acesso pessoal incompletamente rotacionado, a campanha cascadeou por dois fornecedores de segurança de grande porte, quatro repositórios de GitHub Actions, dois pacotes de extensões e mais de 66 pacotes npm.”
Cinco Ferramentas em 12 Dias: O Março Negro do Open Source
O relatório da DreamFactory, publicado a 31 de março de 2026, documentou o alcance completo da campanha inicial: entre 19 e 31 de março, cinco projetos open source de grande relevo foram comprometidos em sucessão rápida. Além do Trivy e do Checkmarx, foram afetados o LiteLLM (proxy de IA para APIs de modelos de linguagem no PyPI), o Telnyx (biblioteca de comunicações) e o Axios, o cliente HTTP mais descarregado no registo npm.
O ataque ao Axios apresentou um perfil distinto dos restantes. A análise da DreamFactory concluiu que este ataque tem “características sofisticadas de grau APT” e não foi atribuído ao TeamPCP. A separação entre os dois padrões de ataque, ocorrendo quase em simultâneo, levanta questões sobre coordenação entre grupos distintos ou sobre o aproveitamento oportunista de um momento de vulnerabilidade sistémica no ecossistema open source.
A escala do compromisso total em março incluiu a manipulação de mais de 66 pacotes npm e a distribuição de malware através de múltiplos canais: Docker Hub, GitHub Container Registry (GHCR), Amazon ECR e o marketplace de extensões OpenVSX. Para as equipas de DevSecOps, o impacto foi particularmente perturbador porque os builds afetados eram distribuídos pelos próprios canais oficiais dos fornecedores, com as respetivas assinaturas e checksums aparentemente válidos.
Tabela: Cronologia dos Ataques TeamPCP em 2026
| Data | Ferramenta Comprometida | Canal de Distribuição | Duração Ativa | Dados Visados |
|---|---|---|---|---|
| 19 Mar 2026 | Trivy (Aqua Security): binário, trivy-action, setup-trivy | GitHub Releases e Actions | Vários dias | SSH keys, tokens GitHub, credenciais de repositório |
| 19-31 Mar 2026 | LiteLLM, Telnyx | PyPI, npm | Vários dias | Credenciais de API, tokens de acesso |
| 23 Mar 2026 | Checkmarx: AST Actions, plugins VS Code, Jenkins, OpenVSX | GitHub Actions, OpenVSX, Jenkins marketplace | Vários dias | Tokens GitHub, tokens npm, SSH keys |
| 31 Mar 2026 | Axios (atribuído a APT distinto) | npm registry | Não divulgado | Credenciais diversas |
| 22 Abr 2026 | Bitwarden CLI v2026.4.0 e Checkmarx KICS | npm, Docker Hub, OpenVSX, GitHub Actions | 93 minutos | Tokens GitHub e npm, SSH keys, configs de IA |
| 19 Mai 2026 | 317 pacotes npm (incl. Antv da Alibaba, TanStack) | npm registry e GitHub | 20 minutos | Credenciais variadas, acesso a sistemas de IA |
A Segunda Vaga: Bitwarden CLI Infetada por 93 Minutos
A 22 de abril de 2026, o TeamPCP regressou. Desta vez, os alvos foram o pacote npm do Bitwarden CLI (versão v2026.4.0) e o repositório Docker Hub do Checkmarx KICS, atingidos no mesmo dia. O intervalo de tempo durante o qual a versão maliciosa do Bitwarden CLI esteve disponível para descarregamento foi de apenas 93 minutos, entre as 17h57 e as 19h30 (hora do Leste dos EUA).
Noventa e três minutos são suficientes para infetar qualquer pipeline de CI/CD configurado para atualização automática de dependências. No universo DevOps, sistemas como o Dependabot ou o Renovate Bot atualizam pacotes automaticamente assim que novas versões são publicadas. Qualquer organização com estas ferramentas ativas e com o Bitwarden CLI como dependência ficou exposta durante essa janela sem qualquer ação por parte dos seus programadores.
Os investigadores da Sophos X-Ops, que publicaram a sua análise a 24 de abril, confirmaram a ligação entre os dois incidentes: “Um agente de ameaça comprometeu os canais de distribuição de dois fornecedores de ferramentas de desenvolvimento, aparentemente no mesmo dia. As versões maliciosas do Checkmarx KICS e do Bitwarden CLI foram publicadas em canais oficiais e apresentadas como versões legítimas. Ambas as cargas maliciosas tentaram recolher a mesma informação sensível e partilhavam o mesmo domínio de comando e controlo, o que aponta para um único agente de ameaça a conduzir uma campanha coordenada.”
As informações recolhidas pelo payload nesta segunda vaga incluíam tokens GitHub e npm, chaves SSH e, de forma reveladora, configurações de assistentes de IA. Este detalhe sinaliza que os atacantes estavam a mapear o acesso a ferramentas de inteligência artificial integradas em ambientes de desenvolvimento, um vetor com crescente valor estratégico à medida que mais empresas integram LLMs nos seus pipelines de produção.
Infraestrutura Partilhada: Como a Sophos Ligou os Pontos
A Assinatura do C2
A chave para ligar as diferentes ondas da campanha foi a infraestrutura de comando e controlo. A Sophos X-Ops identificou que os incidentes do Bitwarden CLI e do Checkmarx KICS utilizavam exatamente o mesmo domínio C2. A Microsoft Defender tinha previamente identificado os mesmos indicadores nas vagas de março: o IP 94.154.172.43 e o domínio audit.checkmarx.cx.
A escolha de audit.checkmarx.cx como domínio C2 é particularmente reveladora da metodologia do grupo. Ao usar um domínio que mimetiza a Checkmarx, o tráfego de exfiltração tornava-se mais difícil de distinguir de comunicações legítimas em análises superficiais de logs de rede. Uma técnica de domain spoofing aplicada ao C2, em vez de ao phishing convencional.
O Modelo de Ataque Encadeado
A análise forense das três vagas revelou um padrão consistente. Em vez de explorar vulnerabilidades de software (CVEs), o TeamPCP explorou relações de confiança entre ferramentas. A cadeia funcionou assim: comprometer o Trivy deu acesso às credenciais de quem utilizava o Trivy, incluindo a própria Checkmarx. Comprometer a Checkmarx deu acesso aos utilizadores das suas ferramentas, em centenas de empresas. Cada passo amplificava o raio de impacto do anterior, sem necessidade de explorar uma única CVE pública.
Esta abordagem representa uma evolução significativa face aos supply chain attacks convencionais. Ataques como o do XZ Utils (março de 2024) ou o do SolarWinds (2020) dependeram de acesso de longa duração ou de comprometimento do processo de build. O TeamPCP operou de forma mais rápida e com menor pegada operacional, aproveitando credenciais existentes e confiança já estabelecida.
A Campanha “Mini Shai-Hulud”: 630 Versões Maliciosas em 20 Minutos
A 19 de maio de 2026, as empresas StepSecurity e SafeDep emitiram alertas sobre uma nova vaga de ataques à cadeia de fornecimento open source, rapidamente apelidada de “Mini Shai-Hulud” pelos investigadores. Desta vez, a escala era diferente: um único atacante assumiu o controlo da conta de um programador e publicou 630 versões maliciosas distribuídas por 317 pacotes em aproximadamente 20 minutos.
Entre os pacotes comprometidos nesta vaga encontrava-se o Antv, uma biblioteca de visualização de dados mantida pela Alibaba. A presença de software da Alibaba na lista de vítimas sinalizou que a campanha não se limitava a alvos ocidentais: qualquer projeto popular com manutenção ativa por um único programador era um alvo potencial.
Nesta mesma vaga, os atacantes comprometeram a biblioteca open source TanStack, amplamente usada em aplicações React e TypeScript. A exploração do TanStack permitiu aceder aos computadores de pelo menos dois funcionários da OpenAI, tornando-se um dos primeiros incidentes de supply chain documentados com impacto confirmado numa das empresas de IA mais proeminentes do mundo. O TechCrunch, que publicou a análise da campanha a 7 de junho de 2026, descreveu a OpenAI como “apenas uma das várias vítimas” desta vaga.
A velocidade da campanha, 630 versões em 20 minutos, levantou questões sobre automação. A hipótese prevalecente entre investigadores é que o atacante desenvolveu ferramentas automatizadas para publicar atualizações maliciosas a uma cadência que tornava a deteção em tempo real praticamente impossível sem sistemas especializados de monitorização de registos npm.
Segundo o relatório da SafeDep, o objetivo da campanha Mini Shai-Hulud era o mesmo das vagas anteriores: “Roubar credenciais para vários serviços, incluindo gestores de passwords, como forma de roubar dados e continuar a propagar o malware.” A cadeia de comprometimento auto-perpetuante é a característica mais perturbadora de toda a campanha: as credenciais roubadas servem de matéria-prima para o próximo ataque.
Impacto Real: De Credenciais Roubadas a Funcionários da OpenAI
Quantificar o impacto total de uma campanha de supply chain é notoriamente difícil, porque as credenciais roubadas podem ser utilizadas semanas ou meses após a exfiltração inicial. O que está documentado é o seguinte: qualquer organização que, entre 19 de março e 19 de maio de 2026, tenha utilizado o Trivy, o Checkmarx AST, o Bitwarden CLI, o LiteLLM, o Telnyx, o Axios, o TanStack ou qualquer um dos 317 pacotes comprometidos em maio, pode ter tido credenciais exfiltradas sem alertas visíveis.
Os dados visados, nomeadamente tokens GitHub e npm, são especialmente perigosos. Um token GitHub com permissões de escrita sobre repositórios privados permite que um atacante introduza código malicioso noutros projetos, potencialmente perpetuando a cadeia de comprometimento indefinidamente. Tokens npm com permissões de publicação permitem repetir exatamente o que o TeamPCP fez: distribuir software malicioso como se fosse uma atualização legítima de confiança.
Nick Frichette, investigador de segurança na nuvem, sintetizou o problema numa análise publicada na Ars Technica: “O que torna estes ataques tão perturbadores é que as organizações fizeram tudo certo. Usaram ferramentas de segurança reconhecidas, integraram-nas nos seus pipelines e seguiram as melhores práticas. E ainda assim foram comprometidas. O problema não é o utilizador, é o modelo de confiança.”
Tabela Comparativa: Supply Chain Attacks Relevantes
| Incidente | Ano | Vetor | Ferramentas Afetadas | Impacto Documentado |
|---|---|---|---|---|
| TeamPCP (ondas múltiplas) | 2026 | PAT comprometido, relações de confiança CI/CD | Trivy, Checkmarx, Bitwarden CLI, 317+ pacotes | Credenciais de centenas de organizações; funcionários da OpenAI comprometidos |
| Mini Shai-Hulud | 2026 | Takeover de conta de programador | 317 pacotes (Antv/Alibaba, TanStack) | Acesso a sistemas de IA, propagação automática |
| XZ Utils (CVE-2024-3094) | 2024 | Engenharia social prolongada (2 anos) | xz/liblzma em distros Linux | Backdoor SSH não chegou a produção; detetado por engenheiro da Microsoft |
| 3CX Desktop App | 2023 | Compromisso de dependência upstream | 3CX (600.000+ empresas) | Atribuído ao grupo Lazarus (Coreia do Norte) |
| SolarWinds Orion | 2020 | Build pipeline comprometido | 18.000+ clientes, incluindo agências dos EUA | Espionagem de nível estadual; danos estimados em biliões de dólares |
Resposta Institucional: Microsoft, Sophos e a Comunidade DevSecOps
A resposta ao compromisso do Trivy e às vagas subsequentes foi relativamente rápida, mas evidenciou lacunas significativas na capacidade de deteção proativa. A Microsoft Defender publicou orientações detalhadas de deteção, investigação e defesa a 24 de março, cinco dias após o ataque inicial, identificando os indicadores de comprometimento (IoCs) específicos e fornecendo consultas KQL para identificar sistemas afetados. O documento incluía os endereços de C2 confirmados e os hashes dos binários maliciosos, ferramentas práticas que as equipas de segurança podiam aplicar imediatamente.
A Sophos X-Ops publicou a sua análise a 24 de abril, focando-se na segunda vaga e na ligação entre o incidente do Bitwarden CLI e o compromisso anterior da Checkmarx. A equipa Sophos identificou o padrão de C2 partilhado e emitiu indicadores de comprometimento atualizados para os seus clientes empresariais.
A Checkmarx publicou atualizações contínuas no seu blog, detalhando os artefactos afetados e os passos de remediação. A empresa recomendou a todos os utilizadores que auditassem os tokens e credenciais presentes nos seus ambientes de CI/CD e procedessem à rotação imediata de qualquer segredo potencialmente exposto. A Aqua Security removeu as versões comprometidas do Trivy e emitiu uma nova versão limpa.
A janela entre o compromisso inicial (19 de março) e a remoção completa dos artefactos maliciosos foi de vários dias. Em segurança, cada hora conta: sistemas de CI/CD que executam builds automaticamente durante a noite ou ao fim de semana podem ter sido infetados sem qualquer interação humana direta.
Análise de Mercado: Custo e Impacto na Confiança no Open Source
O impacto financeiro direto dos ataques TeamPCP ainda não foi publicamente quantificado pelas empresas afetadas. Contudo, o custo médio de um incidente de supply chain a nível global situa-se, segundo o DBIR 2026 da Verizon, acima de 4,2 milhões de dólares por incidente, incluindo custos de resposta, honorários legais, notificações de clientes e perda de receita durante o período de remediação.
Para a Checkmarx, a série de incidentes representa um desafio reputacional significativo. Uma empresa vendida como solução de segurança para código de terceiros tornar-se ela própria um vetor de ataque é o cenário mais adverso possível do ponto de vista comercial. A empresa respondeu com transparência, mas o incidente levantou questões sobre se os fornecedores de ferramentas de segurança estão sujeitos a um nível de escrutínio suficientemente elevado nas suas próprias práticas de segurança operacional.
Para o Bitwarden, os 93 minutos de contaminação do pacote CLI demonstram simultaneamente a capacidade de resposta rápida e a vulnerabilidade do modelo de distribuição via npm. O episódio reforça o argumento a favor de mecanismos de verificação criptográfica adicional para além das assinaturas de pacote padrão, como o Sigstore, cujo projeto foi precisamente concebido para resolver este tipo de vulnerabilidade.
O impacto mais duradouro pode ser na confiança sistémica no open source como modelo de desenvolvimento de software de segurança. Uma tendência emergente entre equipas de segurança maduras é a adoção de Software Bills of Materials (SBOMs) e de ferramentas de verificação de proveniência, precisamente para garantir que os artefactos instalados correspondem ao código que foi auditado e aprovado. A campanha TeamPCP fornece o argumento mais concreto de 2026 para acelerar esta transição.
O Que as Equipas DevSecOps Devem Fazer Agora
As recomendações imediatas para equipas que utilizaram qualquer uma das ferramentas comprometidas no período de março a maio de 2026 são claras. A prioridade é a auditoria e rotação de todos os segredos presentes em ambientes de CI/CD: tokens GitHub, tokens npm, chaves SSH e credenciais de serviços cloud. A Microsoft Defender publicou consultas KQL específicas para identificar comunicações com os C2 do TeamPCP nos logs de rede.
Em paralelo, as equipas devem fixar versões de dependências em vez de usar a tag latest ou versões sem pin, e implementar verificação de checksums para todos os artefactos de ferramentas de segurança. Para GitHub Actions especificamente, a prática recomendada é fazer referência a commits específicos por hash, e não por tag. O force-push de tags foi exatamente a técnica usada pelo TeamPCP para substituir versões legítimas por versões maliciosas.
A adoção de ferramentas de monitorização de registos npm, como o Socket Security ou o StepSecurity, que emitem alertas em tempo real quando pacotes populares são atualizados com comportamentos inesperados, representa uma camada de defesa adicional que teria reduzido significativamente a janela de exposição em todos os incidentes documentados em 2026.
Previsões: O Que Esperar nos Próximos 12 Meses
Com base nos padrões documentados em 2026, cinco tendências emergem como prováveis nos ataques à cadeia de fornecimento de software nos próximos 12 meses.
Primeira, a automatização dos ataques vai acelerar. A capacidade de publicar 630 versões maliciosas em 20 minutos demonstra o uso de automação em escala. As defesas baseadas em revisão manual serão cada vez mais inadequadas sem complemento por sistemas automatizados de monitorização de registos de pacotes.
Segunda, as ferramentas de IA integradas em pipelines de desenvolvimento tornar-se-ão alvos prioritários. O facto de o payload do TeamPCP ter visado especificamente configurações de assistentes de IA sugere que os atacantes reconhecem o valor crescente dessas credenciais para aceder a sistemas de outra forma isolados.
Terceira, espera-se uma maior adoção regulatória de SBOMs e de verificação de proveniência de artefactos. A diretiva NIS2, em vigor na Europa desde outubro de 2024, cria obrigações de segurança da cadeia de fornecimento para operadores de serviços essenciais. Incidentes como o do TeamPCP fornecerão argumentos concretos para a aplicação mais rigorosa dessas obrigações pelas autoridades de supervisão europeias.
Quarta, tokens de acesso pessoal não rotacionados continuarão a ser o vetor de entrada preferido. O caso Trivy demonstrou que um único PAT esquecido pode servir de ponto de partida para uma campanha com impacto global. A gestão de segredos passará a integrar os requisitos de compliance de segurança de forma mais explícita nas auditorias ISO 27001 e SOC 2.
Quinta, a consolidação de plataformas CI/CD em menos fornecedores pode paradoxalmente aumentar o risco sistémico. Se um número crescente de pipelines passar pelo mesmo conjunto de ferramentas, o comprometimento de um único fornecedor terá um raio de impacto ainda maior do que o documentado em 2026.
Perguntas Frequentes
O que é um supply chain attack em software?
Um supply chain attack em software consiste em comprometer uma ferramenta, biblioteca ou serviço utilizado no desenvolvimento ou distribuição de outro software, em vez de atacar diretamente o alvo final. O objetivo é aproveitar a confiança que os utilizadores depositam nas ferramentas comprometidas para distribuir código malicioso de forma invisível.
O Bitwarden ficou comprometido para utilizadores finais?
O compromisso afetou especificamente o pacote CLI npm do Bitwarden (v2026.4.0), utilizado por programadores e sistemas automatizados. A aplicação Bitwarden para utilizadores finais (extensão de browser, aplicação móvel ou aplicação de secretária) não foi afetada. Utilizadores que usam o Bitwarden exclusivamente para gestão de passwords pessoais não estiveram expostos.
Como saber se o meu sistema foi afetado pelo TeamPCP?
A Microsoft Defender publicou indicadores de comprometimento específicos, incluindo o IP 94.154.172.43 e o domínio audit.checkmarx.cx. Qualquer comunicação de saída para estes endereços nos logs de rede deve ser considerada suspeita. A análise da Sophos também identifica os padrões de comportamento associados ao payload do TeamPCP. A rotação preventiva de todos os segredos presentes em sistemas CI/CD que usaram as ferramentas afetadas é recomendada independentemente da presença confirmada de IoCs.
Quais as versões do Trivy que foram comprometidas?
As versões comprometidas incluíram o binário central do scanner, a GitHub Action trivy-action e a GitHub Action setup-trivy publicadas entre 19 e 23 de março de 2026. A Aqua Security publicou versões limpas e identificou as versões afetadas no seu aviso de segurança oficial no GitHub, incluindo os hashes de verificação dos binários legítimos.
O ataque ao Axios foi do mesmo grupo?
A análise da DreamFactory e da Phoenix Security concluiu que o ataque ao Axios apresenta um perfil distinto, com “características sofisticadas de grau APT”, e não foi atribuído ao TeamPCP. A possibilidade de dois grupos distintos terem operado em simultâneo durante o mesmo período de vulnerabilidade sistémica foi levantada pelos investigadores mas não foi formalmente confirmada até à data.
O que é o Sigstore e como previne este tipo de ataque?
O Sigstore é um projeto open source, apoiado pela Linux Foundation, que fornece ferramentas de assinatura criptográfica e verificação de proveniência para artefactos de software. Ao registar cada publicação num log de transparência imutável, o Sigstore permite que qualquer utilizador verifique se um artefacto foi publicado pelo maintainer legítimo a partir de um pipeline de build autorizado. Se o Bitwarden CLI usasse Sigstore para todas as publicações no npm, a versão maliciosa de abril teria sido detetada imediatamente por verificação de assinatura.
Qual o impacto do Cyber Resilience Act neste tipo de ataques?
O Cyber Resilience Act (CRA), com prazo de conformidade para 11 de setembro de 2026, impõe requisitos de segurança a fabricantes de produtos com elementos digitais vendidos na UE, incluindo gestão de vulnerabilidades, divulgação de incidentes em 24 horas e fornecimento de SBOMs. Fornecedores como a Aqua Security e a Checkmarx, que vendem ferramentas no mercado europeu, estarão sujeitos a estas obrigações. Ataques como o do TeamPCP entrarão no âmbito das notificações obrigatórias às autoridades competentes de cada Estado-Membro.
Cobertura Relacionada
Para contexto adicional sobre ameaças à cadeia de fornecimento de software e segurança de infraestrutura digital na Europa:
- CVE em Crise: EUVD da UE e 11 Meses de Risco
- DBIR 2026: 31% das Fugas por Vulnerabilidades
- Ransomware Sem Encriptação: 44% das Falhas
- Ciberataques em Portugal: 2.437/Semana, +32% UE
- Cyber Resilience Act: Coima €15M e Prazo 11 Set
- Segurança Online: Guia Completo
Fontes externas consultadas nesta análise: Microsoft Security Blog, guia de deteção e defesa contra o compromisso do Trivy; Checkmarx, atualizações sobre o incidente de segurança; Sophos X-Ops, análise dos ataques ao Checkmarx e Bitwarden; Ars Technica, análise do ataque direcionado a empresas de segurança; TechCrunch, os piores hacks e fugas de dados de 2026.
