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)}

differx

2026-04-24 09:37:01

Eraclito contro Parmenide
(e la #poesia contemporanea)

24 aprile, oggi “Exit poetry” è in libreria

marcogiovenale.wordpress.com/2…

CHI DESIDERA COMMENTARE, POLEMIZZARE, ANNOTARE, PUÒ FARLO LIBERAMENTE QUI IN CALCE, nei commenti a questo post Mastodon.

24 aprile, “exit poetry”

esce oggi l’antologia di 25 autori “exit poetry”, per le edizioni la nave di teseo, a cura di aldo nove, gilda policastro e lello voce. a circa un mese di distanza dall’anto…

^{marco giovenale}

(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.

Enrico Bucci

2026-04-24 04:20:41

PER QUANTO ANCORA?

La pronuncia dell'autoritá sanitaria spagnola illustra ancora una volta perché la miscela di pseudoscienza e placebo é pericolosa.

Quanto dovremo attendere per sentire parole simili dalle istituzioni italiane?

ilfoglio.it/scienza/2026/04/24…

Quando il placebo si trasforma in rischio clinico

Non esiste prova scientifica pubblicata che avalli l’omeopatia come strumento terapeutico efficace, dice il rapporto dell'Agenzia spagnola dei medicinali e dei prodotti sanitari.

^{Enrico Bucci (Il Foglio)}

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.