(in)sicurezza digitale

2026-04-24 18:17:28

GopherWhisper: il nuovo APT cinese che spia il governo mongolo nascondendo il C2 in Slack, Discord e Outlook

ESET Research ha scoperto GopherWhisper, un nuovo gruppo APT allineato alla Cina attivo dal novembre 2023, specializzato nello spionaggio di istituzioni governative in Mongolia. La particolarità operativa che distingue questo attore: utilizza Discord, Slack e le bozze di Microsoft Outlook come canali di command-and-control, rendendo il traffico malevolo praticamente indistinguibile dalle normali comunicazioni aziendali.

Scoperta e attribuzione: 12 sistemi governativi mongoli compromessi

La ricerca pubblicata da ESET il 23 aprile 2026 rivela che GopherWhisper ha compromesso almeno 12 sistemi appartenenti a un’istituzione governativa mongola, con attività iniziata nel novembre 2023. La telemetria raccolta ha permesso ai ricercatori di recuperare migliaia di messaggi degli operatori direttamente dai server Discord e Slack compromessi, grazie al recupero di token API inclusi nel codice dei backdoor.

L’attribuzione alla Cina si basa su più elementi convergenti: l’analisi dei timestamp dei messaggi Slack e Discord mostra che il grosso delle comunicazioni avviene tra le 8:00 e le 17:00, perfettamente allineato con il China Standard Time (UTC+8). I metadati di configurazione dell’utente Slack configurato dagli operatori riportano inoltre il fuso orario cinese. ESET stima che le vittime complessive siano potenzialmente decine, ma non ha informazioni sulla loro geolocalizzazione o settore.

L’arsenale: sette tool, quattro backdoor, un’infrastruttura C2 distribuita

GopherWhisper si distingue per la proliferazione di strumenti personalizzati — sette in totale, quattro dei quali sono backdoor distinte. Questa ridondanza suggerisce un’organizzazione con risorse sufficienti per sviluppare e mantenere un ecosistema malware parallelo, probabilmente con team distinti per componente.

LaxGopher — Backdoor Go via Slack

Backdoor scritta in Go che usa Slack come canale C2. Esegue comandi tramite cmd.exe, pubblica i risultati su un canale Slack configurato e può scaricare payload aggiuntivi. La comunicazione avviene attraverso le API ufficiali di Slack, rendendola quasi impossibile da rilevare a livello di firewall senza ispezione applicativa.

RatGopher — Backdoor Go via Discord

Backdoor analoga a LaxGopher ma che usa Discord come infrastruttura C2. Riceve messaggi da un server Discord privato, esegue comandi, pubblica i risultati sui canali configurati e gestisce upload/download da file[.]io. L’uso di due piattaforme separate (Slack e Discord) per backdoor distinte è probabilmente una strategia di ridondanza operativa.

BoxOfFriends — Backdoor via bozze Outlook

La backdoor più sofisticata dal punto di vista della tradecraft: gestisce il C2 attraverso bozze email di Microsoft 365 Outlook. Le istruzioni vengono scritte come bozze sul server di posta — mai inviate — e recuperate dal backdoor. Questa tecnica sfrutta il fatto che il traffico HTTPS verso i server Microsoft è quasi universalmente consentito e ignorato dagli strumenti di monitoraggio. È una variante della tecnica nota come “draft-based C2”, già osservata in alcuni APT mediorientali.

SSLORDoor — Backdoor C++ con raw socket

Backdoor scritta in C++ che comunica su porta 443 attraverso connessioni raw socket con OpenSSL BIO. A differenza dei backdoor Go che usano servizi cloud legittimi, SSLORDoor comunica direttamente con infrastruttura C2 controllata dall’attaccante. Supporta enumerazione di drive, operazioni su file e esecuzione di comandi via cmd.exe.

CompactGopher — Strumento di esfiltrazione

Tool Go-based di raccolta e esfiltrazione file, deployato da LaxGopher. Filtra i file di interesse per estensione, li comprime in ZIP, li cifra con AES-CFB-128 e li esfiltra su file[.]io. Le estensioni target sono documentali: .doc, .docx, .jpg, .xls, .xlsx, .txt, .pdf, .ppt, .pptx.

FriendDelivery e JabGopher

FriendDelivery è una DLL malevola che funge da loader e injector per BoxOfFriends. JabGopher è un injector generico del toolkit. Entrambi i componenti svolgono funzioni di supporto nell’ecosistema GopherWhisper, gestendo il deployment e l’iniezione dei backdoor principali.

Living off Trusted Services: la nuova frontiera dell’evasione APT

La scelta di Discord, Slack e Outlook come canali C2 non è casuale: rappresenta l’evoluzione della tecnica “Living off the Land” applicata ai servizi cloud. Invece di abusare di tool di sistema Windows legittimi, GopherWhisper abusa di servizi cloud enterprise affidabili il cui traffico è quasi impossibile da bloccare senza interrompere le operazioni aziendali normali.

L’approccio crea un problema fondamentale per i difensori: bloccare Discord o Slack a livello di firewall è tecnicamente fattibile, ma spesso politicamente impraticabile in organizzazioni che li usano quotidianamente. Rilevare il C2 richiede quindi un’analisi comportamentale del traffico verso questi servizi — pattern anomali di accesso, frequenza, orari e dimensioni dei payload.

Indicatori di compromissione

## GopherWhisper IoC (fonte: ESET Research, aprile 2026)
## IoC completi disponibili su: github.com/eset/malware-ioc

## Strumenti identificati
LaxGopher     - Go backdoor, C2: Slack API
RatGopher     - Go backdoor, C2: Discord API  
BoxOfFriends  - Go backdoor, C2: Microsoft Outlook drafts (M365)
SSLORDoor     - C++ backdoor, C2: raw socket port 443
CompactGopher - Go exfil tool, upload: file[.]io (AES-CFB-128)
FriendDelivery - DLL loader/injector per BoxOfFriends
JabGopher      - Injector generico

## Estensioni file target (CompactGopher)
.doc .docx .jpg .xls .xlsx .txt .pdf .ppt .pptx

## Caratteristiche di attribuzione
- Orari operativi: 08:00-17:00 CST (UTC+8)
- Locale configurato: China Standard Time
- Vittime confermate: istituzione governativa Mongolia (gen 2025)
- Attività iniziale: novembre 2023

Consigli per i difensori

GopherWhisper solleva sfide difensive specifiche legate all’abuso di servizi cloud legittimi:

• Monitoraggio del traffico verso servizi di messaggistica: Implementare analisi comportamentale del traffico verso Discord, Slack e Microsoft 365. Pattern anomali — accessi notturni, frequenza insolita, grandi upload su file.io — possono indicare attività C2.
• Controllo degli accessi alle API di servizi cloud: Gestire e monitorare i token API delle piattaforme aziendali. Un’applicazione non autorizzata che accede alle API Slack o Discord dall’interno della rete è un segnale di allarme.
• Ispezione delle bozze email: La tecnica “draft-based C2” via Outlook è particolarmente insidiosa poiché non genera traffico SMTP. Considerare soluzioni DLP (Data Loss Prevention) in grado di ispezionare le bozze nei sistemi di posta enterprise.
• EDR con visibilità sulle chiamate Go runtime: I backdoor Go presentano pattern di comportamento riconoscibili a livello di runtime. Assicurarsi che le soluzioni EDR abbiano firma e behavioral detection per payload Go-based.
• Blocco dei servizi di file-sharing anonimi: Limitare o monitorare il traffico verso file[.]io e servizi analoghi nelle reti governative e critiche. Questi servizi sono raramente necessari per operazioni aziendali legittime.

Il report completo di ESET Research è disponibile su WeLiveSecurity, con indicatori di compromissione pubblicati nel repository GitHub ufficiale di ESET.

Spcnet.it

2026-04-24 09:03:20

Azure Developer CLI: scrivere gli hook in Python, TypeScript e .NET

L’Azure Developer CLI (azd) è lo strumento open-source di Microsoft pensato per accompagnare lo sviluppatore dall’ambiente locale fino al deployment su Azure. Tra le sue funzionalità più apprezzate, il sistema degli hook permette di iniettare logica personalizzata nei punti chiave del ciclo di vita: prima del provisioning, dopo il deployment, e così via. Fino a poco tempo fa, però, questa logica doveva essere scritta esclusivamente in Bash o PowerShell, costringendo chi lavora in Python o TypeScript a un cambio di contesto non sempre gradito.

Con il rilascio più recente di azd, questo limite è stato rimosso: gli hook possono ora essere scritti in Python, JavaScript, TypeScript e .NET, oltre ai già supportati Bash e PowerShell. La selezione del linguaggio avviene automaticamente in base all’estensione del file, senza configurazione aggiuntiva.

Cosa sono gli hook in azd

Gli hook sono script eseguiti automaticamente da azd in corrispondenza di eventi specifici nel workflow:

• preprovision: prima che venga eseguito il provisioning dell’infrastruttura
• postprovision: dopo il provisioning
• predeploy / postdeploy: prima e dopo il deployment dell’applicazione

Si definiscono nel file azure.yaml con il blocco hooks:, specificando il percorso allo script da eseguire. azd si occupa autonomamente di rilevare il runtime appropriato, installare le dipendenze e lanciare lo script.

Come usare gli hook in Python

Per un hook Python, è sufficiente creare il file .py e, nella stessa directory o in una directory padre, un file requirements.txt o pyproject.toml. azd individuerà automaticamente il file di dipendenze, creerà un virtual environment e installerà i pacchetti necessari prima di eseguire lo script.

Struttura tipica:

hooks/
├── setup.py
└── requirements.txt

Configurazione in azure.yaml:

hooks:
  preprovision:
    run: ./hooks/setup.py

È possibile personalizzare il nome del virtual environment tramite il blocco config:

hooks:
  preprovision:
    run: ./hooks/setup.py
    config:
      virtualEnvName: .venv

Hook in JavaScript e TypeScript

Per gli hook JavaScript e TypeScript, azd cerca un file package.json nella stessa directory o in una directory padre. Esegue automaticamente npm install (o il package manager specificato nella configurazione) e lancia lo script.

Per TypeScript, la novità più interessante è che non serve un tsconfig.json né una fase di compilazione separata: azd utilizza npx tsx per eseguire il file TypeScript direttamente.

hooks/
├── seed.ts
└── package.json

hooks:
  postdeploy:
    run: ./hooks/seed.ts
    config:
      packageManager: pnpm   # npm | pnpm | yarn

Hook in .NET e C#

Per i progetti .NET sono supportate due modalità distinte:

• Project mode: se nella directory dello script (o in una padre) è presente un file .csproj, .fsproj o .vbproj, azd esegue automaticamente dotnet restore e dotnet build.
• Single-file mode: a partire da .NET 10, i file .cs standalone vengono eseguiti direttamente con dotnet run script.cs, senza necessità di un progetto.

hooks/
├── migrate.cs
└── migrate.csproj   # opzionale su .NET 10+

hooks:
  postprovision:
    run: ./hooks/migrate.cs
    config:
      configuration: Release   # Debug | Release
      framework: net10.0

Funzionalità avanzate

Override della directory di lavoro

Se la root del progetto e la posizione dello script differiscono, si può usare il campo dir per specificare la working directory:

hooks:
  preprovision:
    run: main.py
    dir: hooks/preprovision

Override esplicito del linguaggio

Se l’estensione è assente o ambigua, è possibile forzare il runtime con il campo kind:

hooks:
  preprovision:
    run: ./hooks/setup
    kind: python

Formato misto e override per piattaforma

Si possono combinare hook in linguaggi diversi e specificare script differenti per Windows e sistemi POSIX:

hooks:
  preprovision:
    run: ./hooks/setup.py
  predeploy:
    windows:
      run: ./hooks/build.ps1
    posix:
      run: ./hooks/build.sh
  postdeploy:
    run: ./hooks/seed.ts
  postprovision:
    run: ./hooks/migrate.cs

Come aggiornare azd

Per assicurarsi di avere questa funzionalità disponibile, è sufficiente aggiornare azd all’ultima versione:

azd update

Per una nuova installazione, è possibile seguire la guida ufficiale di installazione.

Conclusioni

Il supporto multi-linguaggio per gli hook di azd rappresenta un miglioramento concreto per i team che lavorano con stack tecnologici eterogenei. Non dover più mantenere script shell separati per la logica di deployment è un risparmio reale di complessità, soprattutto nei progetti .NET o Python dove gran parte della base di codice esistente può essere riutilizzata direttamente negli hook.

La gestione automatica delle dipendenze (virtual env per Python, npm install per JS/TS, dotnet restore per .NET) elimina ulteriore boilerplate, rendendo l’integrazione trasparente. Chi già usa azd nel proprio workflow troverà questa novità immediatamente utile; chi non lo ha ancora esplorato può partire dalla documentazione ufficiale e dalla galleria di template.

Fonte: Write azd hooks in Python, JavaScript, TypeScript, or .NET – Azure SDK Blog

Write azd hooks in Python, JavaScript, TypeScript, or .NET

Azure Developer CLI (azd) hooks now support Python, JavaScript, TypeScript, and .NET scripts alongside Bash and PowerShell, with automatic dependency installation and virtual environment management.

^{Kristen Womack (Azure SDK Blog)}

(in)sicurezza digitale

2026-04-24 09:05:59

fast16: il framework di cybersabotaggio pre-Stuxnet riemerso dai tool segreti NSA dei ShadowBrokers

Si parla di:
Toggle

SentinelLABS ha riportato alla luce un framework di cybersabotaggio completamente sconosciuto, denominato fast16, i cui componenti core risalgono al 2005: almeno cinque anni prima di Stuxnet. La scoperta rimette in discussione la cronologia del cyberwarfare a livello statale e solleva interrogativi inquietanti sull’affidabilità dei sistemi di calcolo ad alta precisione nelle infrastrutture critiche.

Un fantasma nei tool NSA: la connessione ShadowBrokers

La storia di fast16 inizia nel 2017, quando il gruppo ShadowBrokers pubblicò una serie di tool offensivi attribuiti alla NSA, tra cui un documento denominato “Territorial Dispute”. Quello schema elencava framework malware di cui la NSA era a conoscenza — o che aveva prodotto — e che i suoi operatori non avrebbero dovuto interferire. Tra le voci appariva un riferimento criptico a “fast16”, rimasto inspiegato per quasi un decennio.

È stato il ricercatore di SentinelLABS Juan Andrés Guerrero-Saade, insieme al collega Vitaly Kamluk, a riconnettere i puntini: dopo anni di oscurità, Guerrero-Saade ha identificato un campione reale del framework, scoprendo che non si trattava di un semplice rootkit, ma di un sistema sofisticato di cybersabotaggio con capacità di auto-propagazione all’interno di reti chiuse.

Architettura tecnica: Lua VM, kernel driver e alterazione floating-point

fast16 è composto da due componenti principali che collaborano in modo sinergico:

• fast16.sys — Un kernel driver con avvio a livello boot (boot-start), in grado di operare a basso livello nel sistema operativo prima che qualsiasi software di sicurezza si inizializzi. Il driver è responsabile del patching in-memory degli eseguibili target e dell’introduzione di sottili errori nei calcoli in virgola mobile (floating-point).
• svcmgmt.exe — Un “service carrier” riutilizzabile che incorpora una virtual machine Lua. Questa scelta architetturale è notevole: si tratta del primo utilizzo documentato di una Lua VM embedded in malware offensivo, datato 2005, anticipando tecniche poi riutilizzate in framework come Sandman APT decenni dopo. Il design rende il payload modulare e facilmente aggiornabile senza modificare il componente carrier.

Il meccanismo di sabotaggio è di raffinata sottigliezza: invece di bloccare o distruggere i sistemi target, fast16 introduce errori minimi ma sistematici nei calcoli ad alta precisione. L’obiettivo non è il crash, ma risultati scientifici falsati che possono essere impossibili da distinguere da errori di progettazione o calibrazione. Fast16 include inoltre meccanismi di propagazione worm-style per diffondersi trasversalmente all’interno di una facility, garantendo che lo stesso driver corrotto raggiunga tutte le workstation rilevanti.

I target: LS-DYNA, PKPM e il programma nucleare iraniano

Il framework è stato progettato per colpire specifiche categorie di software di simulazione ad alta precisione:

• LS-DYNA — Software di analisi agli elementi finiti (FEA) ampiamente usato per modellare dinamiche fisiche complesse, inclusi problemi legati alla ricerca nucleare e ai sistemi d’arma. Scienziati iraniani risultano averlo impiegato in contesti ricollegabili al programma nucleare nazionale.
• PKPM — Suite di ingegneria strutturale molto diffusa in Cina e nel mondo accademico, utilizzata per simulazioni nell’industria delle costruzioni e dell’ingegneria avanzata.
• MOHID (Modelo Hidrodinâmico) — Framework di modellazione idrodinamica per sistemi acquatici, rilevante in ambiti di ricerca scientifica applicata.

La presenza di LS-DYNA nella lista dei target è particolarmente significativa: il software è stato usato da ricercatori iraniani in attività compatibili con lo sviluppo di armamenti convenzionali e non convenzionali. Questo ha portato i ricercatori a ipotizzare che fast16 potrebbe essere stato impiegato come operazione offensiva contro il programma nucleare iraniano — non distruggendo centrifughe come Stuxnet, ma falsando i risultati delle simulazioni a monte della progettazione.

Stuxnet aveva un precursore: implicazioni geopolitiche e strategiche

Stuxnet, scoperto nel 2010 e datato operativamente intorno al 2007-2008, è stato a lungo considerato il capostipite del cyberwarfare industriale: il primo malware a causare danni fisici reali in impianti industriali attraverso il sabotaggio di sistemi SCADA Siemens. La scoperta di fast16 sposta l’asticella indietro di almeno cinque anni.

Questa linea temporale suggerisce che le capacità di cybersabotaggio offensivo a livello statale — in particolare quelle attribuite agli USA o ai loro alleati contro il programma nucleare iraniano — erano molto più mature e avanzate di quanto si ritenesse pubblicamente. fast16 non sostituisce Stuxnet nella narrativa, ma ne diventa il precursore logico: un primo tentativo di alterare i calcoli scientifici a monte, prima che si optasse per il sabotaggio diretto delle centrifughe.

Kamluk ha espresso preoccupazioni esplicite sulle implicazioni più ampie: se un framework capace di introdurre errori floating-point non rilevabili esisteva già nel 2005, quante altre operazioni analoghe potrebbero essere rimaste silenti in sistemi critici globali per anni o decenni?

Componenti principali e indicatori tecnici

## Componenti fast16 (SentinelLABS, aprile 2026)

Componente         | Tipo                      | Funzione
-------------------|---------------------------|----------------------------------
fast16.sys         | Kernel driver (boot-start)| Patching in-memory + errori FP
svcmgmt.exe        | Service carrier + Lua VM  | Loader modulare riutilizzabile
[payload Lua]      | Script Lua embedded       | Logica di sabotaggio e targeting

## Software target identificati
- LS-DYNA (FEA, fisica nucleare/balistica)
- PKPM (ingegneria strutturale)
- MOHID (idrodinamica)

## Connessione ShadowBrokers
- Documento: "Territorial Dispute" (2017 leak)
- Indicazione: tool marcato come "da non toccare" per operatori NSA
- Implicazione: fast16 era già monitorato dalla NSA prima del 2017

Consigli per i difensori

La scoperta di fast16 ha implicazioni pratiche per chi opera in ambienti ad alta criticità scientifica o industriale:

• Integrità dei risultati di calcolo: Implementare meccanismi di verifica crociata (cross-validation) per simulazioni ad alta precisione, specialmente in ambiti nucleari, aerospaziali e infrastrutturali. Un attaccante sofisticato non distruggerà i vostri sistemi — li renderà inaffidabili in modo silenzioso.
• Monitoraggio dei driver kernel: Rivedere le policy di controllo dei driver con avvio boot-start. Strumenti come Windows Driver Signature Enforcement e Secure Boot sono parzialmente efficaci, ma un attaccante con accesso fisico o supply chain può aggirarli.
• Audit di supply chain del software scientifico: Il software di simulazione specialistico è spesso distribuito attraverso canali meno controllati rispetto al software commerciale mainstream. Verificare l’integrità degli installer e monitorare comportamenti anomali a runtime.
• Threat hunting retrospettivo: Considerare l’eventualità che tecniche analoghe a fast16 siano già presenti in ambienti critici. La firma “Territorial Dispute” è pubblica dal 2017 — è il momento di verificare.

La ricerca di SentinelLABS su fast16 è disponibile nel blog ufficiale di SentinelOne Labs e rappresenta un contributo fondamentale alla comprensione storica e tecnica del cyberwarfare offensivo a livello statale.

(in)sicurezza digitale

2026-04-24 06:42:14

Contagious Interview diventa un worm: Void Dokkaebi trasforma 750 repository in vettori auto-propaganti contro gli sviluppatori

Si parla di:
Toggle

Le campagne di cyberspionaggio nordcoreane basate su finti colloqui di lavoro hanno una storia lunga: da almeno il 2023 il cluster noto come Contagious Interview, attribuito al gruppo Famous Chollima (tracciato da Trend Micro come Void Dokkaebi, da altri come DeceptiveDevelopment, Gwisin Gang o Wagemole), ha ripetutamente adescato sviluppatori occidentali promettendo posizioni in startup cripto e AI. L’ultima iterazione documentata da Trend Micro nell’aprile 2026 fa un passo qualitativo in avanti che cambia la natura della minaccia: la campagna ha smesso di essere un attacco mirato sviluppatore-per-sviluppatore ed è diventata una vera infezione worm-like della supply chain del software, con propagazione automatica attraverso l’ecosistema Git/VS Code.

Nel solo mese di marzo 2026, i ricercatori hanno identificato più di 750 repository infetti, oltre 500 configurazioni VS Code task weaponized e 101 istanze del tool di commit-tampering usato dal gruppo. Quando una vittima clona un repository compromesso e lo apre in VS Code, il malware si avvia automaticamente e — soprattutto — riesce a infettare a sua volta i repository che lo sviluppatore toccherà in seguito, innescando una cascata di contaminazione attraverso fork, contributi downstream e template condivisi.

Da Famous Chollima a Void Dokkaebi: la continuità operativa DPRK

Void Dokkaebi è una delle diverse sotto-unità che negli ultimi anni hanno reso la Corea del Nord uno degli avversari più attivi sul fronte del furto di criptovalute e del cyberspionaggio economico. Il nome «dokkaebi» richiama una figura del folklore coreano: uno spirito burlone capace di trasformarsi, metafora apt per un attore che continua a riciclare lo stesso modus operandi cambiando i nomi di fantasia, i finti marchi aziendali e le tecniche di consegna del payload. Il filone «Contagious Interview» è stato negli anni associato anche a famiglie di malware come BeaverTail (JavaScript infostealer), InvisibleFerret (Python backdoor), OtterCookie e, più recentemente, a varianti compilate in Go per espandere la compatibilità cross-platform.

Parallelamente, una seconda campagna DPRK — tracciata come HexagonalRodent — ha sottratto oltre 12 milioni di dollari a sviluppatori web attirati con finte offerte LinkedIn, usando la stessa infrastruttura di consegna basata su BeaverTail e InvisibleFerret. L’ipotesi operativa degli analisti è che i cluster condividano infrastruttura e codice base, con team distinti focalizzati rispettivamente su spionaggio tecnologico e monetizzazione diretta via cripto.

Il lure: da colloquio tecnico a code-review test

Il vettore iniziale resta coerente con la narrazione storica: un finto recruiter si rivolge alla vittima su LinkedIn, Upwork, Freelancer o piattaforme di recruiting specializzate in Web3/cripto. L’offerta è attraente — compensi alti, lavoro da remoto, meeting su Google Meet o Discord — e culmina in un «test tecnico» che chiede allo sviluppatore di clonare un repository e «risolvere un bug» o estendere una feature. È in questa fase che Void Dokkaebi ha inserito la novità sostanziale: il repository non si limita a contenere un payload JavaScript eseguito al npm install, ma distribuisce due vettori complementari progettati per coprire gli scenari operativi di qualsiasi sviluppatore moderno.

I due vettori: .vscode/tasks.json e JavaScript iniettato

Il primo vettore sfrutta un file .vscode/tasks.json ben costruito, con una task configurata per l’esecuzione automatica all’apertura della cartella (tramite proprietà runOptions folderOpen). Questo meccanismo è nativo di Visual Studio Code ed è controllato dal sistema di Workspace Trust: quando un utente apre un repository e lo segna come «trusted» — comportamento comune tra sviluppatori pressati — le task si eseguono senza ulteriori avvisi. Gli attaccanti hanno inoltre imparato a nascondere la cartella .vscode nelle viste più comuni, anche tramite commit-tampering che la omette dai diff presentati a UI-level.

Il secondo vettore è JavaScript direttamente iniettato nel codice del progetto. Si tratta di payload offuscato che si attiva alla build o all’esecuzione del progetto, indipendentemente dall’IDE in uso. La ridondanza è deliberata: se lo sviluppatore usa JetBrains, Neovim o Sublime invece di VS Code, il JavaScript di progetto scavalca il primo vettore. Se l’utente evita di eseguire il codice ma apre solo la cartella in VS Code, la task interviene. In entrambi i casi, l’esecuzione del malware è garantita.

Commit tampering: il tool che rende invisibili i file malevoli

Uno degli aspetti più ingegnosi dell’evoluzione 2026 è l’uso sistematico di un tool custom che Trend Micro ha ritrovato in 101 istanze operative. Il tool manipola i commit per nascondere i file malevoli (tipicamente la cartella .vscode) dalle viste di GitHub, GitLab e dai client grafici più usati, mentre i file restano fisicamente presenti nel tree al momento del clone. La tecnica sfrutta la differenza tra come i sistemi Git mostrano la history rispetto a come checkoutano lo stato: un reviewer umano che scorre i diff su GitHub può non vedere nulla di sospetto, ma uno sviluppatore che fa git clone si trova il payload sul disco.

La propagazione worm-like tra repository

Quando il payload viene eseguito, oltre alla fase di furto credenziali tipica di BeaverTail e InvisibleFerret (dump di browser-stored passwords, wallet cripto, file SSH, token cloud), il malware scansiona la workspace locale dello sviluppatore alla ricerca di repository Git aperti. Ove possibile, iniezione e commit-tampering vengono replicati nei repository upstream dello sviluppatore, trasformando la vittima in un untwitting maintainer di nuovi vettori. Ogni sviluppatore che contribuisce al repository infetto diventa il potenziale paziente zero della prossima ondata. È il tratto che giustifica la parola «contagious» nel nome del cluster: il contagio non è più una metafora narrativa, è l’architettura tecnica dell’operazione.

Staging C2 su blockchain pubbliche

Per ostacolare le operazioni di takedown, Void Dokkaebi ospita parte della logica C2 e della distribuzione dei payload su Tron, Aptos e Binance Smart Chain. Smart contract e transazioni pubbliche diventano canali di delivery praticamente incancellabili: le autorità possono sanzionare indirizzi o bloccare domini, ma non possono cancellare dati già scritti su una blockchain permanente. La stessa tecnica era stata osservata in campagne precedenti (tra cui EtherHiding del cluster UNC5342), e qui viene integrata nell’infrastruttura di staging per la fase di second-stage download.

Indicatori di Compromissione

== IP C2 Void Dokkaebi (aprile 2026) ==
136.0.9.8
198.105.127.210
23.27.202.27
154.91.0.196
23.27.20.143
85.239.62.36
83.168.68.219
166.88.4.2
23.27.120.142

== Famiglie malware associate ==
BeaverTail        (JavaScript infostealer)
InvisibleFerret   (Python backdoor)
OtterCookie       (loader recente, varianti Go)

== Artefatti sospetti nei repository ==
.vscode/tasks.json con runOptions = "folderOpen" e comandi curl/wget
Commit che modificano tree ma non diff visibili (commit tampering)
Cartelle hidden (.vscode, .run, .idea) con script non giustificati dal contenuto

== Infrastruttura di staging ==
Smart contract su Tron, Aptos, Binance Smart Chain usati come C2 resilienti

Implicazioni e consigli pratici per i difensori

La nuova postura di Void Dokkaebi mette in discussione alcune assunzioni base della difesa dello sviluppatore. Non basta più non eseguire codice sconosciuto: anche la sola apertura di un repository in VS Code può essere sufficiente a compromettere la workstation. In più, la scala raggiunta (750 repository infetti in un mese) rende plausibile che un team stia inconsapevolmente clonando contenuti malevoli durante normali attività di ricerca, valutazione tecnica o contributo open source.

• Workspace Trust disabilitato per default: impostare VS Code a chiedere esplicitamente il trust ad ogni apertura, con preferenza per l’apertura in modalità restricted.
• Ambienti effimeri per il codice non fidato: ogni repository proveniente da recruiter, colloqui o contatti esterni andrebbe clonato ed eseguito dentro VM isolate, devcontainer o dev sandbox (GitHub Codespaces, Gitpod) usa-e-getta senza credenziali cloud montate.
• Segregazione dei token: mai tenere gh auth token, credenziali AWS/Azure/GCP o wallet cripto sulla stessa workstation usata per esperimenti su codice esterno.
• Monitoraggio commit: verificare periodicamente i commit dei repository personali per la comparsa di cartelle .vscode, .run, .idea non previste; strumenti come git fsck e hook pre-commit possono intercettare task injection.
• Code-signing enforcement per script di build critici e pipeline di rilascio.
• Awareness sul pattern «colloquio tecnico»: ogni richiesta di clonare un repository durante una fase di colloquio è oggi un segnale di rischio elevato, a prescindere dalla credibilità apparente del recruiter.

Lo snodo strategico è che il lure di Void Dokkaebi punta esattamente alle vittime più fragili dell’ecosistema tech: freelance in cerca di nuove opportunità, sviluppatori Web3 con wallet personali carichi di token, ingegneri AI con accesso a modelli e infrastruttura cloud. Per la Corea del Nord, ogni workstation compromessa è tre obiettivi in uno: liquidità in cripto, accesso a supply chain software, e un trampolino per campagne di spionaggio più ampie. La svolta contagious di aprile trasforma ogni nuova vittima in un potenziale super-spreader — e rende l’operazione una delle minacce più silenziosamente pervasive del 2026 contro la community open source.

Spcnet.it

2026-04-23 15:01:47

Addio byte[]: allocazioni a costo zero in .NET Framework con ReadOnlySpan

Uno dei pattern di ottimizzazione più semplici e meno conosciuti nel mondo .NET è la sostituzione dei campi static readonly byte[] con proprietà static ReadOnlySpan<byte>. Andrew Lock, noto per le sue analisi approfondite su ASP.NET Core e il runtime, ha pubblicato un articolo che conferma un dettaglio fondamentale: questa tecnica funziona anche su .NET Framework, basta il pacchetto NuGet System.Memory. Zero allocazioni, zero costo di startup, nessuna pressione sul garbage collector.

Il problema: allocazioni “gratuite” che non lo sono

Consideriamo un pattern che troviamo in quasi tutte le librerie che manipolano dati binari: signature di file, magic number, header fissi, tabelle di lookup. Tipicamente si scrive:

public static class MyStaticData
{
    private static readonly byte[] ByteField = new byte[] { 1, 2, 3, 4 };
}

Sembra innocuo: un singolo array, allocato una volta sola al caricamento del tipo. Ma in un processo con migliaia di tipi simili — pensiamo a un parser di formati immagine, a una libreria di crittografia, a un framework web — queste allocazioni si sommano. Ogni array è un oggetto gestito: richiede header, richiede tracciamento GC, occupa spazio sulla Gen 2 (perché sopravvive per sempre) e aumenta i tempi di startup.

La soluzione: ReadOnlySpan<byte> come proprietà

La trasformazione è quasi meccanica:

public static class MyStaticData
{
    private static ReadOnlySpan<byte> ReadOnlySpanProp => new byte[] { 1, 2, 3, 4 };
}

Sintatticamente sembra che stiamo allocando un array ogni volta che accediamo alla proprietà. In realtà è esattamente il contrario: il compilatore C# riconosce questo pattern e incorpora i byte direttamente nei metadati dell’assembly, costruendo lo span con un puntatore a quei dati. Non viene mai eseguito newarr.

L’IL generato mostra chiaramente la magia:

IL_0000: ldsflda      int32 '<PrivateImplementationDetails>'::'...'
IL_0005: ldc.i4.4
IL_0006: newobj       instance void valuetype [System.Memory]System.ReadOnlySpan`1<unsigned int8>::.ctor(void*, int32)
IL_000b: ret

I dati vivono in una sezione di sola lettura dell’assembly; lo span viene costruito on-the-fly con pointer + length. È essenzialmente gratuito.

Letterali UTF-8: lo stesso trucco, più ergonomico

A partire da C# 11 (.NET 7), la stessa ottimizzazione si ottiene con i letterali UTF-8:

private static ReadOnlySpan<byte> Utf8Hello => "Hello world"u8;

Il suffisso u8 istruisce il compilatore a codificare la stringa direttamente in UTF-8 nell’assembly. Molto utile per header HTTP, prefissi di protocollo, marker di formato binari — tutti casi in cui storicamente si manteneva una byte[] statica generata da Encoding.UTF8.GetBytes.

I vincoli da rispettare

L’ottimizzazione non si applica in modo uniforme. Vale solo per i tipi a byte singolo:

• byte[]
• sbyte[]
• bool[]

Per gli altri tipi primitivi (int, long, double…) entra in gioco l’endianness: su .NET 7 e successivi c’è RuntimeHelpers.CreateSpan<T>() che la gestisce in modo trasparente, ma su .NET Framework il compilatore emette codice che cache l’array in un campo statico alla prima chiamata. Ancora efficiente, ma non zero-alloc.

Il secondo vincolo è che tutti i valori devono essere costanti a compile-time:

// Anti-pattern: alloca a ogni accesso
private static readonly byte One = 1;
private static ReadOnlySpan<byte> Bad => new byte[] { One, 2, 3, 4 };

Qui One è un campo, non una costante, quindi il compilatore deve costruire l’array a runtime. La differenza tra const byte e static readonly byte diventa improvvisamente importante.

Il terzo vincolo è usare ReadOnlySpan<T>, mai Span<T>:

// Sbagliato: alloca un array mutabile a ogni accesso
private static Span<byte> MutSpan => new byte[] { 1, 2, 3, 4 };

Uno Span<byte> potrebbe essere scritto, e modificare dati immutabili condivisi sarebbe catastrofico. Il compilatore quindi non applica l’ottimizzazione.

Il supporto su .NET Framework

Questa è la parte più interessante: il trucco funziona su .NET Framework 4.6.2+ semplicemente referenziando il pacchetto System.Memory:

<ItemGroup>
  <PackageReference Include="System.Memory" Version="4.6.3" />
</ItemGroup>

La ragione è che l’ottimizzazione è una feature del compilatore, non del runtime: serve solo che ReadOnlySpan<T> esista come tipo, e il pacchetto System.Memory lo fornisce. Chi mantiene librerie multi-target può quindi applicare questa ottimizzazione senza creare codice condizionale #if NET6_0_OR_GREATER.

Collection expressions: la rete di sicurezza

Su C# 12 e successivi le collection expressions offrono protezione a compile-time:

// Compila e non alloca
private static ReadOnlySpan<byte> Safe => [1, 2, 3, 4];

// Errore CS9203 — il compilatore rifiuta
private static Span<byte> Dangerous => [1, 2, 3, 4];

L’errore CS9203 è un salvavita: impedisce di assegnare una collection expression a un tipo Span<T> in contesti static, perché il risultato sarebbe condivisibile e mutabile. Su .NET Framework o su versioni di C# precedenti questa protezione non esiste, quindi serve attenzione in fase di code review.

Quando applicarla nel codice reale

Le candidate ideali sono costanti binarie che vivono in campi static readonly byte[]: magic number (PNG, ZIP, PDF), prefissi protocollari, tabelle di sostituzione, chiavi di test fisse, certificati embedded. Il refactoring è meccanico e non cambia l’API pubblica della classe se la visibility è private.

Attenzione invece ai metodi che accettano byte[]: non possiamo passare uno ReadOnlySpan<byte> a un’API che richiede un array. In questi casi la scelta è tra riscrivere il consumer per accettare ReadOnlySpan<byte> (preferibile) o mantenere l’array tradizionale. Molte API del BCL sono già state aggiornate negli ultimi anni: Stream.Write, HashAlgorithm.ComputeHash, Encoding.GetString accettano tutti ReadOnlySpan<byte> in overload moderni.

Conclusione

Cambiare static readonly byte[] in static ReadOnlySpan<byte> => è uno di quei refactoring che riducono allocazioni e startup con una modifica locale a costo zero. Funziona anche su .NET Framework, quindi vale la pena considerarla durante la manutenzione di codice legacy — un punto che spesso sfugge perché l’ecosistema associa Span<T> esclusivamente a .NET moderno.

Fonte: Removing byte[] allocations in .NET Framework using ReadOnlySpan<T> di Andrew Lock.

Removing byte[] allocations in .NET Framework using ReadOnlySpan

In this post I describe how to remove static byte[] allocations, even on .NET Framework, by using Span, look at the associated IL, and discuss the risks

^{Andrew Lock (Andrew Lock | .NET Escapades)}

(in)sicurezza digitale

2026-04-23 12:32:05

Checkmarx nel mirino di TeamPCP: l’immagine Docker ufficiale di KICS trojanizzata per esfiltrare i segreti dell’infrastruttura

Si parla di:
Toggle

Il 22 aprile 2026 Docker, Inc. ha rilevato attività sospette sul repository ufficiale checkmarx/kics e ha allertato i ricercatori di Socket. L’analisi ha confermato il peggiore degli scenari per un vendor di security scanner: le immagini Docker ufficiali dello strumento open source KICS (Keeping Infrastructure as Code Secure) erano state sostituite con versioni trojanizzate, progettate per generare, cifrare ed esfiltrare i report di scansione completi insieme a token cloud, credenziali GitHub e chiavi SSH di ogni pipeline CI/CD che le eseguiva. Poche ore dopo, l’account @pcpcats rivendicava l’operazione: «Thank you OSS distribution for another very successful day at PCP inc.»

Non è la prima volta che Checkmarx finisce nel mirino di TeamPCP. A marzo 2026 lo stesso gruppo aveva compromesso due workflow GitHub Actions di Checkmarx e plugin distribuiti tramite OpenVSX, colpendo nella stessa ondata anche Trivy e LiteLLM. L’attacco di aprile rappresenta però un salto qualitativo: non si limita più al codice sorgente o agli action, ma colpisce direttamente i binary artifact distribuiti ufficialmente dal vendor, trasformando uno strumento che gli ingegneri installano proprio per cercare vulnerabilità in un vettore di furto di segreti su scala globale.

Che cos’è KICS e perché è un bersaglio ideale

KICS è uno scanner open source per Infrastructure-as-Code mantenuto da Checkmarx, ampiamente integrato nelle pipeline CI/CD per rilevare misconfiguration in Terraform, CloudFormation, Ansible, Kubernetes manifests e Dockerfile. Per sua stessa natura, viene eseguito con accesso di lettura all’intero repository, ai file di configurazione, ai secret dell’ambiente di build e spesso alle credenziali cloud a breve durata emesse dal provider di CI. Compromettere KICS significa ottenere, per ogni installazione infetta, una vista privilegiata sui crown jewels della pipeline.

Il vettore Docker Hub: tag sovrascritti e un v2.1.21 fantasma

Gli attaccanti hanno sovrascritto tag esistenti del repository checkmarx/kics — tra cui alpine, latest, debian, v2.1.20 e v2.1.20-debian — e hanno introdotto un tag v2.1.21 che non corrisponde ad alcun rilascio ufficiale del progetto. Questa tecnica è particolarmente insidiosa: ogni sistema che effettua docker pull checkmarx/kics:latest o che aggiorna l’immagine di base nei workflow di CI scarica silenziosamente la versione compromessa, senza allarmi da parte dei tool di dipendency scanning che si fidano del nome del repository ufficiale.

Il binario ELF di KICS all’interno dell’immagine è stato modificato per mantenere la funzionalità legittima (la scansione si completa senza errori, non ci sono segnali visibili di compromissione nei log) e aggiungere in parallelo una routine di raccolta dati che genera un report di scansione non censurato, lo cifra e lo invia a un endpoint esterno. In pratica, i file di configurazione che contengono password, token e connection string — normalmente redatti dai report pubblici di KICS — vengono esportati in chiaro verso l’infrastruttura dell’attaccante.

L’estensione VS Code e il payload mcpAddon.js

La campagna non si ferma alle immagini Docker. Socket ha identificato malware anche nelle estensioni Checkmarx per Visual Studio Code pubblicate sul marketplace Microsoft e su OpenVSX. Le versioni compromesse sono checkmarx.cx-dev-assist@1.17.0 e @1.19.0, oltre a checkmarx.ast-results@2.63.0 e @2.66.0 (la 1.18.0 risulta pulita, con il malware temporaneamente rimosso nel ciclo di release).

Il meccanismo è chirurgico: gli attaccanti hanno iniettato un commit retrodatato (68ed490b) nel repository Checkmarx/ast-vscode-extension contenente un file di circa 10 MB in modules/mcpAddon.js. Il modulo viene stageed per l’esecuzione runtime tramite l’interprete Bun, una scelta che riduce la probabilità di rilevazione rispetto all’esecuzione tradizionale in Node.js e permette di eseguire codice JavaScript con minore scrutinio da parte degli EDR endpoint.

Cosa ruba realmente mcpAddon.js

Il payload è un infostealer di caratura operativa avanzata. Esegue comandi nativi sulla macchina della vittima per raccogliere un dossier completo di credenziali:

• Token di autenticazione GitHub tramite gh auth token
• Credenziali AWS dai file di configurazione standard
• Token Azure tramite az account get-access-token e azd auth token
• Configurazioni Google Cloud tramite gcloud config config-helper
• Token npm dai file .npmrc dell’utente
• Chiavi SSH e file di configurazione
• File di configurazione di Claude Code e di altri MCP client
• Variabili d’ambiente selezionate del processo

L’inclusione esplicita dei file di configurazione MCP è un segnale che TeamPCP sta mappando non solo le supply chain tradizionali, ma anche l’ecosistema emergente degli agenti AI — che a loro volta conservano token per molteplici servizi di terze parti.

Esfiltrazione via repository GitHub pubblici: l’ingegno del «vocabolario Dune»

L’aspetto più creativo dell’operazione riguarda l’esfiltrazione. Invece di esfiltrare direttamente verso un C2 facilmente bloccabile, il malware crea repository GitHub pubblici con nomi casuali costruiti dal pattern <word>-<word>-<3 digits>, attingendo a un vocabolario ispirato all’universo di Dune — «gesserit», «melange», «fedaykin», «ornithopter», «atreides», «sandworm». Ogni repository ospita tre file: envelope con il payload cifrato, key con la chiave di decifratura (a sua volta cifrata), e token con un identificativo che lega il furto alla vittima.

I messaggi di commit incorporano token aggiuntivi secondo il pattern «LongLiveTheResistanceAgainstMachines:<encoded>», uno slogan ricorrente nel folklore di TeamPCP. Questa architettura rende la rilevazione molto più complessa: il traffico di esfiltrazione è indistinguibile dal normale uso di GitHub da parte di sviluppatori.

Il workflow format-check.yml e l’abuso di toJSON(secrets)

Nell’operazione di marzo, TeamPCP aveva già dimostrato padronanza dei GitHub Actions: il workflow maligno .github/workflows/format-check.yml sfruttava l’espressione ${{ toJSON(secrets) }} per serializzare tutti i segreti del repository e dell’organizzazione in un artefatto JSON scaricabile per 90 giorni. È una tecnica di supply chain attack elegante e sottovalutata, perché non richiede di esfiltrare alcunché verso infrastruttura esterna: GitHub stesso ospita il bottino, che diventa scaricabile con le sole credenziali dell’attaccante.

Propagazione npm via token rubati

Una volta ottenuti i token npm delle vittime, il malware cerca automaticamente pacchetti scrivibili interrogando l’endpoint /-/org/<user>/package e, in fallback, effettua ricerche con https://registry.npmjs.org/-/v1/search?text=maintainer:<user>&size=250. La logica è quella classica dei self-replicating npm worm già osservati in campagne come Shai-Hulud: ogni sviluppatore colpito diventa un potenziale vettore per nuove pubblicazioni malevoli.

Indicatori di Compromissione

== Hash ==
mcpAddon.js
  SHA256  24680027afadea90c7c713821e214b15cb6c922e67ac01109fb1edb3ee4741d9
  SHA1    2b12cc5cc91ec483048abcbd6d523cdc9ebae3f3
  MD5     d47de3772f2d61a043e7047431ef4cf4

kics (ELF binary trojanizzato)
  SHA256  2a6a35f06118ff7d61bfd36a5788557b695095e7c9a609b4a01956883f146f50
  SHA1    250f3633529457477a9f8fd3db3472e94383606a
  MD5     e1023db24a29ab0229d99764e2c8deba

== Docker tag compromessi (checkmarx/kics) ==
alpine, latest, debian, v2.1.20, v2.1.20-debian, v2.1.21 (fake)

== Index manifest digest ==
sha256:2588a44890263a8185bd5d9fadb6bc9220b60245dbcbc4da35e1b62a6f8c230d  (alpine/v2.1.20/v2.1.21)
sha256:222e6bfed0f3bb1937bf5e719a2342871ccd683ff1c0cb967c8e31ea58beaf7b  (debian variants)
sha256:a0d9366f6f0166dcbf92fcdc98e1a03d2e6210e8d7e8573f74d50849130651a0  (latest)

== Estensioni VS Code / OpenVSX ==
checkmarx.cx-dev-assist  1.17.0, 1.19.0   (malevole)
checkmarx.ast-results    2.63.0, 2.66.0   (malevole)

== C2 ==
audit.checkmarx[.]cx/v1/telemetry
94[.]154[.]172[.]43

== Pattern repository di staging ==
<word>-<word>-<3 digits> (vocabolario Dune: gesserit, melange, fedaykin,
ornithopter, atreides, sandworm, ...) con file envelope/key/token

== Pattern commit message ==
LongLiveTheResistanceAgainstMachines:<encoded>

Implicazioni e raccomandazioni

Il caso Checkmarx/KICS è un promemoria brutale: gli strumenti di security scanner sono essi stessi componenti della supply chain, spesso eseguiti con privilegi elevati dentro le pipeline più sensibili dell’organizzazione. Per chi gestisce ambienti che integrano KICS o altri scanner Checkmarx:

• Verificare le versioni pullate di checkmarx/kics negli ultimi 30 giorni e confrontare i digest con quelli pubblicati ufficialmente dal vendor dopo la rimediation.
• Effettuare il pin delle immagini Docker a digest SHA invece che a tag mutabili come latest o alpine.
• Controllare i log GitHub per workflow artefacts di dimensione anomala, in particolare quelli generati da workflow che referenziano toJSON(secrets).
• Ruotare tutti i token GitHub, npm, AWS, Azure e GCP che potrebbero essere stati esposti a sviluppatori con cx-dev-assist o ast-results nelle versioni compromesse.
• Monitorare la creazione di repository GitHub pubblici corrispondenti al pattern Dune descritto sopra.
• Bloccare o allertare sulle connessioni verso audit.checkmarx.cx (dominio di lookalike non legittimo di Checkmarx).

Il doppio colpo di TeamPCP a Checkmarx in meno di due mesi suggerisce che il gruppo conserva un accesso persistente o ricorrente agli ambienti di build del vendor, o quantomeno che alcune delle credenziali rubate nella prima ondata non sono state completamente invalidate. La security community attende risposte più dettagliate dal vendor su come il tag Docker ufficiale sia stato sovrascritto e su quale catena di fiducia debba essere ricostruita per i clienti che hanno integrato KICS nelle proprie pipeline negli ultimi mesi.

Spcnet.it

2026-04-23 07:54:20

TypeScript 7.0 Beta: il nuovo compilatore in Go è circa 10 volte più veloce

Il team di TypeScript ha rilasciato la beta ufficiale di TypeScript 7.0, e non si tratta di un aggiornamento incrementale: il compilatore è stato riscritto in Go, con miglioramenti di performance che in molti scenari superano un fattore 10x. Dopo quasi un anno di anteprime tecniche sotto il nome TypeScript Native Preview, Microsoft porta la versione nativa del compilatore a un pubblico molto più ampio e la raccomanda per uso quotidiano, pur restando formalmente in beta.

Perché riscrivere il compilatore in Go

Il compilatore di TypeScript era storicamente scritto nello stesso linguaggio che compilava. Questa scelta, elegante dal punto di vista del bootstrapping, ha sempre comportato un costo: su codebase di grandi dimensioni il tsc può impiegare decine di secondi (o minuti) per il type-checking e il watch mode si appesantisce rapidamente all’aumentare dei file.

La riscrittura in Go non è un rewrite da zero: il team parla esplicitamente di un port metodico, mantenendo parità strutturale con la logica di type-checking di TypeScript 6.0. Questo approccio riduce il rischio di regressioni semantiche: la stessa base di casi di test, le stesse regole, ma con le velocità permesse da codice nativo e dal parallelismo reale a memoria condivisa.

Il risultato, secondo Microsoft, è che TypeScript 7.0 è circa 10 volte più veloce di TypeScript 6.0. Team come Bloomberg, Figma, Google, Slack e Vercel hanno riportato numeri comparabili durante la beta privata, con riduzioni drastiche dei tempi di build in CI.

Come provarlo oggi

L’installazione avviene come package separato per non rompere le pipeline esistenti. Basta un singolo comando:

npm install -D @typescript/native-preview@beta
npx tsgo --version
# Version 7.0.0-beta

Durante la fase beta, l’eseguibile si chiama tsgo al posto di tsc. Per Visual Studio Code è disponibile l’estensione “TypeScript Native Preview”, che affianca il language service classico permettendo di confrontare i tempi di risposta in tempo reale.

Parallelismo configurabile

Una delle novità più sottili, ma con maggiore impatto pratico, è il parallelismo integrato nel compilatore:

• --checkers N: numero di worker dedicati al type-checking (default 4). I worker mantengono viste indipendenti per evitare ricalcoli ridondanti, ma i risultati restano deterministici.
• --builders N: abilita la compilazione parallela di più progetti referenziati (project references). Ha un effetto moltiplicativo quando combinato con --checkers, ed è particolarmente efficace nei monorepo.
• --singleThreaded: forza l’esecuzione sequenziale per debugging o ambienti con memoria limitata (container CI con poca RAM, ad esempio).

Alzare --checkers aumenta la velocità ma anche il consumo di memoria: su agenti CI piccoli conviene fare qualche prova empirica prima di spingerlo oltre 8.

Breaking changes: la pulizia annunciata

TypeScript 7.0 è anche l’occasione per rimuovere anni di retrocompatibilità. Chi mantiene progetti legacy dovrà prestare attenzione, perché molte opzioni di configurazione sono semplicemente scomparse:

• target: es5 non è più supportato.
• downlevelIteration, moduleResolution: node/node10/classic, e i moduli amd, umd, systemjs, none sono stati rimossi.
• baseUrl è stato eliminato: usare paths relativo alla root del progetto.
• esModuleInterop, allowSyntheticDefaultImports e alwaysStrict non possono più essere disattivati.

Cambiano anche diversi default: strict: true, module: esnext, target pari all’ultima versione ECMAScript stabile prima di esnext, noUncheckedSideEffectImports: true, e soprattutto types: []. Quest’ultimo è il cambiamento che più spesso romperà le build: prima @types/* venivano inclusi automaticamente, ora vanno dichiarati esplicitamente:

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

Sul fronte del supporto a JavaScript con JSDoc, la pulizia è ancora più netta: i valori non possono più sostituire i tipi (usare typeof valore), la sintassi Closure-style function(string): void è rimossa, così come @enum e l’operatore postfisso !.

Convivenza con TypeScript 6.0

Per chi non può migrare subito tutte le pipeline, è possibile installare entrambe le versioni affiancate:

npm install -D typescript@npm:@typescript/typescript6

Così typescript continua a puntare a 6.0, mentre tsgo (o tsc7 dopo il rilascio finale) resta disponibile come entry point separato. È lo scenario consigliato per confrontare gradualmente i due compilatori su progetti reali prima di fare il cutover.

Roadmap e cosa aspettarsi

La beta è datata 21 aprile 2026; il rilascio stabile è previsto entro due mesi, con una release candidate alcune settimane prima. Nel frattempo arriveranno un --watch più efficiente, la parità di declaration file emit per JavaScript, miglioramenti all’editor (ricerca dei riferimenti ai file, comandi import/export più granulari) e una API programmatica stabile, attesa per TypeScript 7.1 o successiva.

Vale la pena migrare subito?

Per team che lavorano su codebase grandi e soffrono di type-check lenti, la risposta è “quasi sicuramente sì, almeno in parallelo”. Microsoft stessa dichiara il compilatore “altamente stabile e altamente compatibile” sulla base di test su codebase da milioni di righe. La strategia più prudente è: installare @typescript/native-preview come dev dependency aggiuntiva, introdurlo come job di CI opzionale accanto al tsc esistente, misurare i tempi reali e segnalare eventuali incompatibilità sul repository microsoft/typescript-go.

Le incompatibilità che emergeranno non saranno di natura logica ma di configurazione: soprattutto il nuovo default types: [] e la rimozione di baseUrl. Chi si è tenuto aggiornato con le versioni recenti dovrebbe cavarsela con poche modifiche al tsconfig.json.

Fonte: Announcing TypeScript 7.0 Beta di Daniel Rosenwasser sul blog ufficiale TypeScript (Microsoft DevBlogs).

Announcing TypeScript 7.0 Beta - TypeScript

Today we are absolutely thrilled to announce the release of TypeScript 7.0 Beta! If you haven’t been following TypeScript 7.0’s development, this release is significant in that it is built on a completely new foundation.

^{Daniel Rosenwasser (TypeScript)}

Spcnet.it

2026-04-22 15:21:43

12 tecniche per ottimizzare le query PostgreSQL su dataset di grandi dimensioni

Quando una tabella PostgreSQL cresce oltre il milione di righe, query che prima restituivano risultati in millisecondi iniziano ad impiegare secondi — o peggio. La buona notizia è che PostgreSQL offre strumenti potenti per affrontare questo problema. La cattiva notizia è che molti sviluppatori conoscono solo una parte di questi strumenti.

In questo articolo passiamo in rassegna le 12 tecniche più efficaci per ottimizzare le query su grandi dataset, con esempi SQL concreti per ciascuna.

1. Creare indici sulle colonne frequentemente filtrate

Il consiglio più noto, ma non per questo meno importante. Un indice trasforma una scansione sequenziale (O(n)) in una ricerca B-tree (O(log n)). La differenza su una tabella da un milione di righe può essere di due ordini di grandezza.

-- Prima: full sequential scan su ordini
SELECT * FROM orders WHERE customer_id = 42;

-- Creazione dell'indice
CREATE INDEX idx_orders_customer_id ON orders(customer_id);

-- Dopo: index scan, da 240ms a pochi ms

Usate EXPLAIN ANALYZE per verificare che l’indice venga effettivamente utilizzato.

2. Normalizzare il database in modo strategico

La normalizzazione riduce la ridondanza e migliora la coerenza dei dati, ma va applicata con giudizio. Una normalizzazione eccessiva crea decine di JOIN che possono diventare colli di bottiglia. La regola pratica: normalizzate i dati che cambiano spesso o che hanno alta cardinalità (liste di prodotti, clienti, categorie), denormalizzate i dati storici o di report dove la velocità di lettura è critica.

3. Evitare SELECT *

Selezionare tutte le colonne ha due costi nascosti: aumenta il volume di I/O e impedisce a PostgreSQL di soddisfare la query direttamente dall’indice (index-only scan). Specificate sempre le colonne necessarie:

-- Evitare
SELECT * FROM orders WHERE customer_id = 42;

-- Preferire
SELECT id, created_at, total_amount FROM orders WHERE customer_id = 42;

Quando le colonne selezionate fanno parte di un indice composito, PostgreSQL può restituire i dati senza accedere all’heap, eliminando un intero livello di I/O.

4. Ordinare i JOIN in modo efficiente

Il query planner moderno di PostgreSQL determina autonomamente l’ordine ottimale dei JOIN grazie al cost-based optimizer. Tuttavia, in scenari con molte tabelle o con join_collapse_limit ridotto, conviene strutturare i JOIN in modo che le tabelle più piccole (o più filtrate) vengano processate per prime, riducendo la cardinalità delle operazioni successive.

5. Usare LIMIT durante l’esplorazione dei dati

Apparentemente ovvio, ma spesso trascurato: se l’interfaccia utente mostra al massimo 50 risultati, non ha senso recuperarne un milione dal database.

SELECT id, name, email 
FROM customers 
ORDER BY created_at DESC 
LIMIT 50 OFFSET 0;

Attenzione al pagination problem: con OFFSET elevati, PostgreSQL scansiona comunque tutte le righe precedenti. Per paginazione su grandi dataset, preferite il keyset pagination (cursor-based).

6. Indici parziali per subset frequenti

Un indice parziale indicizza solo le righe che soddisfano una condizione, riducendo dimensioni e costo di manutenzione:

-- Indice solo sugli ordini completati (subset più frequentemente interrogato)
CREATE INDEX idx_completed_orders
ON orders(customer_id)
WHERE status = 'Completed';

-- La query deve includere la stessa condizione per usare l'indice
SELECT id, total_amount 
FROM orders 
WHERE customer_id = 42 AND status = 'Completed';

In un test pratico, questo indice ha dimezzato i tempi rispetto a un indice standard su tutte le righe.

7. Usare i tipi di dato più piccoli necessari

Ogni byte conta quando moltiplicato per milioni di righe. Preferite sempre il tipo più compatto che soddisfa il requisito:

• integer (4 byte) invece di bigint (8 byte) per chiavi primarie < 2 miliardi
• smallint (2 byte) per enumerazioni con pochi valori
• timestamp invece di timestamptz se il fuso orario è fisso
• varchar(n) con limite appropriato invece di text illimitato dove possibile

Tipi più piccoli significano pagine di dati più dense, quindi meno I/O per ogni query.

8. Non applicare funzioni sulle colonne indicizzate

Applicare una funzione a una colonna indicizzata invalida l’utilizzo dell’indice:

-- L'indice su name NON viene usato
SELECT * FROM customers WHERE LOWER(name) = 'mario rossi';

-- Soluzione: creare un indice funzionale
CREATE INDEX idx_customers_lower_name ON customers(LOWER(name));

-- Ora l'indice viene usato
SELECT * FROM customers WHERE LOWER(name) = 'mario rossi';

Lo stesso vale per funzioni su date come DATE(created_at): usate range di timestamp o create l’indice sulla funzione.

9. Partizionare le tabelle molto grandi

Il partizionamento divide una tabella logica in sotto-tabelle fisiche, permettendo a PostgreSQL di escludere partizioni irrilevanti (partition pruning) durante le query:

-- Tabella partizionata per anno
CREATE TABLE orders_partitioned (
    id         serial NOT NULL,
    customer_id integer,
    created_at  timestamp NOT NULL,
    CONSTRAINT pk_orders PRIMARY KEY (id, created_at)
) PARTITION BY RANGE (created_at);

-- Creazione delle partizioni annuali
CREATE TABLE orders_2024 PARTITION OF orders_partitioned
    FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');

CREATE TABLE orders_2025 PARTITION OF orders_partitioned
    FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');

Una query che filtra per anno legge solo la partizione corrispondente, ignorando completamente le altre.

10. Usare le transazioni per operazioni bulk

PostgreSQL esegue un commit (e quindi una scrittura sincrona su WAL) dopo ogni statement. Raggruppare più operazioni in un’unica transazione riduce drasticamente i costi di I/O:

-- Lento: un commit per ogni INSERT
INSERT INTO log_events VALUES (...);
INSERT INTO log_events VALUES (...);
-- ... x 10.000

-- Veloce: un solo commit per tutto il batch
BEGIN;
INSERT INTO log_events VALUES (...);
INSERT INTO log_events VALUES (...);
-- ... x 10.000
COMMIT;

In test pratici, l’approccio con transazione singola completa lo stesso lavoro in meno della metà del tempo rispetto agli inserimenti individuali.

11. Evitare transazioni long-running

Il modello MVCC (Multi-Version Concurrency Control) di PostgreSQL mantiene versioni multiple delle righe per garantire la consistenza delle letture. Le transazioni long-running bloccano il processo di VACUUM dal rimuovere le versioni obsolete, causando table bloat: tabelle che crescono fisicamente anche quando i dati logici non aumentano.

Spezzettate le operazioni pesanti in batch più piccoli e monitorate le transazioni attive con:

SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state
FROM pg_stat_activity
WHERE state != 'idle' AND query_start IS NOT NULL
ORDER BY duration DESC;

12. Gestire il bloat con VACUUM

Ogni UPDATE e DELETE lascia righe “morte” sul disco. VACUUM le recupera:

-- VACUUM standard: recupera spazio senza bloccare le letture
VACUUM orders;

-- VACUUM FULL: recupera tutto lo spazio ma blocca l'accesso alla tabella
-- Usare solo in finestre di manutenzione programmate
VACUUM FULL orders;

-- Verificare lo stato del bloat
SELECT relname, n_dead_tup, n_live_tup,
       round(n_dead_tup::numeric / NULLIF(n_live_tup + n_dead_tup, 0) * 100, 2) AS dead_pct
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

Per la maggior parte dei workload, autovacuum è sufficiente. Assicuratevi che sia abilitato e calibrate i threshold in base al volume di modifiche della vostra applicazione:

-- Verificare la configurazione autovacuum per una tabella specifica
SELECT reloptions FROM pg_class WHERE relname = 'orders';

Riepilogo operativo

Non tutte le tecniche si applicano a ogni scenario. Un approccio efficace inizia sempre dall’analisi con EXPLAIN (ANALYZE, BUFFERS) per identificare i reali colli di bottiglia, poi applica le ottimizzazioni in modo mirato. L’indice sbagliato o il partizionamento mal configurato possono peggiorare le prestazioni invece di migliorarle.

Il punto di partenza universale resta lo stesso: misurare prima, ottimizzare dopo.

---

Fonte: 12 practices for optimizing PostgreSQL queries for large datasets — elmah.io Blog

12 practices for optimizing PostgreSQL queries for large datasets

Boost PostgreSQL performance with 12 expert tips for large datasets from partitioning to partial indexes and avoiding bloat. Stay fast and scale.

^{Ali Hamza Ansari (elmah.io Blog - .NET Technical tutorials/guides and new features)}