Quando a essere violato è uno dei principali vendor di sicurezza applicativa — uno strumento usato per rilevare vulnerabilità nel codice altrui — le implicazioni si estendono ben oltre l’azienda stessa. Il gruppo LAPSUS$ ha pubblicato sul dark web 95 gigabyte di dati riservati di Checkmarx, inclusi codice sorgente, chiavi API e credenziali di database. È l’ultimo capitolo di una campagna supply chain orchestrata da un attore noto come TeamPCP, che da settimane sta sistematicamente compromettendo l’ecosistema degli strumenti di sviluppo e sicurezza.
Cosa è stato esfiltrato
Il 25 aprile 2026, LAPSUS$ ha rivendicato pubblicamente l’attacco a Checkmarx, pubblicando un archivio di circa 95 GB che include codice sorgente dei repository GitHub privati dell’azienda (tra cui componenti di KICS, il motore open source per la scansione di configurazioni cloud e IaC), un database dei dipendenti con informazioni personali e credenziali interne, chiavi API per servizi di terze parti e integrazioni, e credenziali di database MongoDB e MySQL dell’ambiente di sviluppo.
Checkmarx ha confermato l’autenticità del dump in un advisory pubblicato il 26 aprile, precisando che i repository GitHub compromessi sono separati dall’ambiente di produzione per i clienti e che nessun dato cliente è stato esposto direttamente. Tuttavia, la presenza di chiavi API e credenziali nei file esfiltrati amplia significativamente la superficie di attacco potenziale.
Il vettore: la campagna supply chain TeamPCP
L’accesso ai sistemi di Checkmarx non è stato ottenuto tramite un attacco diretto, ma attraverso la compromissione della supply chain di sviluppo software. La data del breach originale è il 23 marzo 2026, quando TeamPCP ha iniettato codice malevolo in componenti dell’ecosistema Checkmarx disponibili pubblicamente. Le immagini Docker KICS ufficiali su Docker Hub sono state sostituite con versioni trojanizzate contenenti uno stealer di credenziali: gli sviluppatori che le utilizzavano nelle pipeline CI/CD scaricavano automaticamente il malware. Parallelamente, due estensioni VS Code correlate a Checkmarx pubblicate su marketplace sono state compromesse con funzionalità di esfiltrazione che operavano silenziosamente in background.
Il nome TeamPCP emerge anche in connessione con le 73 estensioni malicious su Open VSX scoperte a fine aprile, suggerendo una campagna coordinata e ad ampio raggio contro l’intero ecosistema degli strumenti DevSecOps. Il modello è chiaro: compromettere prima gli strumenti che gli sviluppatori di sicurezza usano quotidianamente, per poi risalire — tramite le credenziali rubate — ai sistemi più preziosi.
Chi è LAPSUS$
LAPSUS$ è un gruppo di cybercrime con una storia operativa peculiare: composto prevalentemente da giovani hacker (diversi dei quali minorenni all’epoca degli attacchi), il gruppo si è distinto tra il 2021 e il 2022 per una serie di operazioni ad alto profilo contro Nvidia, Samsung, Okta, Microsoft e Uber, utilizzando principalmente tecniche di social engineering e SIM swapping piuttosto che exploit tecnici sofisticati. Dopo una serie di arresti nel 2022-2023, il gruppo sembrava smantellato. La ricomparsa nel 2026, questa volta sfruttando l’infrastruttura supply chain di TeamPCP come vettore di accesso iniziale, dimostra una capacità di adattamento e riorganizzazione che rende LAPSUS$ una minaccia ancora attiva.
Timeline dell’incidente
- 23 marzo 2026: TeamPCP compromette le immagini Docker KICS e le estensioni VS Code; furto delle credenziali Checkmarx GitHub
- Fine marzo – inizio aprile 2026: esfiltrazione massiva dei 95 GB di repository privati
- 25 aprile 2026: LAPSUS$ pubblica il data dump sul dark web e rivendica l’attacco
- 26 aprile 2026: Checkmarx pubblica un advisory confermando la violazione e bloccando l’accesso al repository compromesso
- 29 aprile 2026: il dump viene diffuso pubblicamente in forum accessibili, aumentando il rischio di sfruttamento secondario delle chiavi API esposte
Implicazioni per gli utenti Checkmarx e i team DevSecOps
La violazione di Checkmarx solleva preoccupazioni su più livelli. In primo luogo, l’esposizione del codice sorgente dei motori di analisi potrebbe consentire ad attori malevoli di identificare potenziali vulnerabilità nelle logiche di scanning, aprendo la porta ad attacchi che bypassano o manipolano i risultati dell’analisi statica del codice. In secondo luogo, i team che hanno utilizzato immagini Docker KICS o le estensioni VS Code compromesse tra marzo e aprile 2026 devono considerarsi potenzialmente compromessi e procedere con un’indagine forensica.
Indicatori di Compromissione e azioni immediate
# Immagini Docker KICS compromesse (periodo a rischio: 23/03 - 26/04/2026)
checkmarx/kics:latest # verificare hash con: docker inspect --format='{{.Id}}' checkmarx/kics:latest
checkmarx/kics:v1.7.x # controllare con advisory ufficiale Checkmarx
# Credenziali da ruotare immediatamente se si è usato KICS Docker nel periodo a rischio:
# - Token GitHub con accesso ai repository
# - Chiavi API Checkmarx
# - Credenziali MongoDB/MySQL condivise con l'ambiente di sviluppo
# - Segreti nelle pipeline CI/CD (GitHub Actions, GitLab CI, Jenkins)
# Verifica estensioni VS Code compromesse:
# Controllare l'elenco completo nel security advisory ufficiale su checkmarx.com/blog/checkmarx-security-update-april-26/
# Log da analizzare per pull sospetti (pipeline CI/CD):
# grep -r "checkmarx/kics" .github/workflows/ .gitlab-ci.yml JenkinsfileConsigli per i difensori
L’attacco a Checkmarx è emblematico di una tendenza sempre più preoccupante: i tool di sicurezza stessi diventano vettori di attacco. È necessario verificare i log delle pipeline CI/CD tra il 23 marzo e il 26 aprile 2026 per identificare eventuali pull di immagini Checkmarx da Docker Hub. Qualsiasi segreto memorizzato nell’ambiente di sviluppo deve essere considerato compromesso e sostituito immediatamente. Le estensioni VS Code Checkmarx vanno rimosse e reinstallate da sorgenti verificate e firmate. Il monitoraggio del dark web nei prossimi mesi è raccomandato: i 95 GB esfiltrati contengono informazioni che potrebbero essere sfruttate per attacchi secondari a lungo termine.
Più in generale, questo incidente sottolinea l’urgenza di adottare il principio del least privilege nelle pipeline CI/CD: i processi automatizzati non dovrebbero avere accesso a credenziali di produzione. L’isolamento degli ambienti — sviluppo, staging, produzione — e la firma crittografica delle immagini container (tramite strumenti come Cosign e la policy enforcement con Kyverno o OPA) limitano significativamente il blast radius di compromissioni simili. Quando a essere attaccato è chi produce gli strumenti di difesa, l’unica risposta efficace è l’architettura zero-trust applicata anche all’infrastruttura DevSecOps.