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