Spcnet.it

2026-04-21 13:28:35

Primary Constructor e Dependency Injection in C# 12: vantaggi, insidie e quando usarli

Con C# 12, Microsoft ha introdotto i primary constructors per tutte le classi e le struct — non solo per i record come in precedenza. Per chi lavora quotidianamente con ASP.NET Core e il pattern di dependency injection, questa feature merita attenzione: riduce il boilerplate in modo significativo, ma nasconde un'insidia che è bene conoscere prima di adottarla sistematicamente.

Il problema: il boilerplate del costruttore classico

Chi ha scritto servizi ASP.NET Core sa bene come appare il costruttore tradizionale con dependency injection:

public class OrderService
{
    private readonly IOrderRepository _orderRepository;
    private readonly ILogger<OrderService> _logger;
    private readonly IEventBus _eventBus;
    private readonly IValidator<Order> _validator;

    public OrderService(
        IOrderRepository orderRepository,
        ILogger<OrderService> logger,
        IEventBus eventBus,
        IValidator<Order> validator)
    {
        _orderRepository = orderRepository;
        _logger = logger;
        _eventBus = eventBus;
        _validator = validator;
    }
}

Per ogni dipendenza: una dichiarazione di campo, un parametro nel costruttore, un'assegnazione nel corpo. Con quattro dipendenze, sono già dodici righe di puro scaffolding. In un servizio con sei o sette dipendenze, il costruttore diventa il blocco di codice più lungo della classe — senza contenere logica.

La soluzione con primary constructors

Con i primary constructors di C# 12, lo stesso servizio si scrive così:

public class OrderService(
    IOrderRepository orderRepository,
    ILogger<OrderService> logger,
    IEventBus eventBus,
    IValidator<Order> validator)
{
    public async Task<Order?> GetOrderAsync(Guid id)
    {
        logger.LogInformation("Fetching order {OrderId}", id);
        return await orderRepository.GetByIdAsync(id);
    }

    public async Task PlaceOrderAsync(Order order)
    {
        await validator.ValidateAndThrowAsync(order);
        await orderRepository.SaveAsync(order);
        await eventBus.PublishAsync(new OrderPlacedEvent(order.Id));
    }
}

I parametri del primary constructor diventano direttamente disponibili in tutta la classe senza dichiarazioni esplicite di campo. Il risultato è codice più snello, con meno rumore visivo e il focus immediato sulla logica di business.

L'insidia della mutabilità: perché Milan Jovanović era inizialmente scettico

Il motivo di resistenza di molti sviluppatori esperti è legittimo: i parametri del primary constructor non sono campi readonly. Il compilatore non impedisce la riassegnazione accidentale:

public class OrderService(IOrderRepository orderRepository)
{
    public void SomeMethod()
    {
        orderRepository = null!;  // Compila senza warning
    }
}

Con i campi privati readonly tradizionali, questo codice causa un errore di compilazione. Con i primary constructors, il compilatore lo accetta silenziosamente. In un servizio DI dove le dipendenze non dovrebbero mai essere rimpiazzate a runtime, questo è un rischio concreto in team di grandi dimensioni.

Mitigazione: assegnazione esplicita a readonly field

Quando la garanzia di immutabilità è critica, si può assegnare esplicitamente il parametro a un campo readonly:

public class CriticalService(IRepository repository)
{
    private readonly IRepository _repository = repository;

    // Da qui in poi si usa _repository, mai repository direttamente
}

Questo reintroduce parte del boilerplate, ma mantiene la sintassi più compatta per la firma del costruttore e garantisce l'immutabilità a livello compilatore.

Quando usare i primary constructors

La valutazione pragmatica è che i primary constructors offrono il massimo vantaggio nelle classi di servizio DI tipiche di ASP.NET Core, dove i parametri vengono usati ma raramente riassegnati. In questi scenari, il rischio di mutabilità accidentale è basso e i benefici di leggibilità sono immediati.

Vale la pena usarli anche per entity e value object dove i parametri di costruzione diventano proprietà read-only:

public class Order(Guid customerId, Money total)
{
    public Guid Id { get; } = Guid.NewGuid();
    public Guid CustomerId { get; } = customerId;
    public Money Total { get; } = total;
    public DateTime CreatedAt { get; } = DateTime.UtcNow;
}

Quando evitarli

Tre scenari in cui i primary constructors non sono la scelta giusta:

• Logica di validazione nel costruttore: se il costruttore deve eseguire guard clause o validazioni prima dell'assegnazione, il corpo esplicito del costruttore tradizionale è necessario.
• Multiple signature di costruttore: i primary constructors supportano una sola firma. Con overload multipli (es. per serializzazione), la sintassi tradizionale è l'unica opzione.
• Cinque o più dipendenze: se una classe richiede molte dipendenze, il problema non è la sintassi del costruttore ma il design della classe. Il segnale che suggerisce un refactoring verso interfacce più coese o il pattern Facade.

Conclusione: adottarli con consapevolezza

I primary constructors di C# 12 non sono una rivoluzione, ma un'evoluzione pragmatica del linguaggio. Per la maggior parte delle classi di servizio in ASP.NET Core, il tradeoff è favorevole: meno boilerplate, codice più leggibile, rischio di mutabilità basso nel contesto DI. L'importante è conoscere il comportamento del compilatore e scegliere consapevolmente quando la garanzia di readonly è effettivamente necessaria.

Come sempre con le feature di C#, il consiglio è adottarle dove migliorano la leggibilità del codice reale, non per seguire una moda sintattica.

Fonte originale: Why I Switched to Primary Constructors for DI in C# di Milan Jovanović.

Why I Switched to Primary Constructors for DI in C#

I resisted primary constructors for a while. They felt like a shortcut that would cost me later. But after using them across several projects, I'm sold, with one important caveat.

^{www.milanjovanovic.tech}

(in)sicurezza digitale

2026-04-21 09:52:18

The Gentlemen e SystemBC: anatomia di un’operazione ransomware con botnet da 1.570 vittime aziendali

Si parla di:
Toggle

• Il profilo del gruppo: RaaS ad alta velocità
• La scoperta della botnet SystemBC
• La kill chain: da accesso iniziale a cifratura domain-wide in poche ore
• Evasione difensiva: preparazione metodica alla cifratura
• Schema crittografico ibrido: X25519 + XChaCha20
• Indicatori di compromissione (IoC)
• Raccomandazioni per i difensori

Un’indagine di Check Point Research ha portato alla luce l’infrastruttura operativa di The Gentlemen, uno dei gruppi ransomware-as-a-service (RaaS) a crescita più rapida del 2026. L’analisi forense di un singolo incidente ha disvelato una botnet SystemBC con oltre 1.570 host aziendali compromessi, un arsenale di post-exploitation maturo e un modello operativo che spiega la rapidità con cui il gruppo ha raggiunto 320 vittime rivendicate, 240 delle quali concentrate nei primi mesi di quest’anno.

Il profilo del gruppo: RaaS ad alta velocità

Emerso intorno alla metà del 2025, The Gentlemen si è rapidamente affermato come uno dei programmi RaaS più aggressivi nel panorama del cybercrime organizzato. Il modello economico è generoso per gli affiliati: 90% dei proventi ai partner, 10% agli operatori. Questo split ha attratto affiliati con elevate competenze tecnico-operative, capaci di orchestrare intrusioni complesse nelle reti enterprise. Il gruppo opera una piattaforma di doppia estorsione con leak site Tor e countdown di 7 giorni prima della pubblicazione dei dati esfiltrati. Le comunicazioni avvengono tramite Tox, Session e l’account X @TheGentlemen25. Tra le vittime documentate: Oltenia Energy Complex (Romania) e Adaptavist Group.

La scoperta della botnet SystemBC

L’elemento più allarmante emerso dall’analisi è la presenza di una botnet SystemBC con 1.570 host compromessi, prevalentemente in ambienti aziendali distribuiti tra Stati Uniti, Regno Unito, Germania, Australia e Romania. SystemBC è un malware proxy che stabilisce tunnel SOCKS5 all’interno della rete vittima, comunicando con il C2 tramite un protocollo custom cifrato RC4. La botnet non è di proprietà esclusiva di The Gentlemen: indica che gli affiliati si integrano in un ecosistema più ampio di tooling condiviso, amplificando l’impatto operativo ben oltre le vittime rivendicate pubblicamente. I settori più colpiti sono manifatturiero e tecnologico, con healthcare in crescita come terzo target.

La kill chain: da accesso iniziale a cifratura domain-wide in poche ore

Il processo di attacco documentato rivela una kill chain estremamente efficiente. Dopo l’accesso iniziale — vettore non ancora determinato nell’incidente analizzato — gli attaccanti procedono con la compromissione del Domain Controller tramite Mimikatz per credential harvesting, seguita dal deploy di Cobalt Strike via RPC per il controllo remoto. Una volta ottenuti i privilegi di Domain Admin, viene attivata la propagazione via Group Policy Objects (GPO) per una detonazione sincronizzata sull’intera rete.

Per il lateral movement, il gruppo implementa sei vettori simultanei: PsExec con credenziali esplicite, WMI tramite wmic /node: process call create, Scheduled Tasks remoti, Windows Services, PowerShell Remoting via WinRM e accesso alle SMB Admin Shares (ADMIN$ e C$\Temp). L’uso parallelo di tutti i vettori massimizza la velocità di propagazione e rende difficile il contenimento.

Evasione difensiva: preparazione metodica alla cifratura

Prima dell’avvio della cifratura, il ransomware esegue una sequenza di operazioni per neutralizzare le difese:

# Disabilita Windows Defender real-time
powershell -Command Set-MpPreference -DisableRealtimeMonitoring $true -Force

# Disabilita Windows Firewall
netsh advfirewall set allprofiles state off

# Elimina le Shadow Copy
vssadmin delete shadows /all /quiet

# Cancella i log di sistema
wevtutil cl System
wevtutil cl Application
wevtutil cl Security

Vengono inoltre rimossi file di prefetch, log RDP e file di supporto di Windows Defender. LSA viene configurato per l’accesso anonimo e SMB1 viene riabilitato per compatibilità. Un comportamento rivelatore: il ransomware ignora esplicitamente la directory “! Cynet Ransom Protection(DON’T DELETE)”, dimostrando una conoscenza specifica dei meccanismi di rilevamento dei vendor di sicurezza.

Schema crittografico ibrido: X25519 + XChaCha20

Il payload Windows è scritto in Go, quello ESXi/Linux in C. Lo schema crittografico è progettato per massimizzare la velocità. Per ogni file viene generata una chiave privata effimera random a 32 byte; l’algoritmo X25519 (Curve25519) effettua lo scambio ECDH e i primi 24 byte del segreto condiviso diventano il nonce per XChaCha20. File inferiori a 1 MB vengono completamente cifrati; file più grandi subiscono cifratura parziale (1%, 3% o 9% del contenuto) per ottimizzare la velocità. Il footer apposto ai file è del tipo: --eph--[base64_key]--marker--GENTLEMEN.

La variante ESXi gestisce le VM tramite vim-cmd vmsvc/power.off e esxcli vm process kill --type=force, con persistenza tramite /etc/rc.local.d/local.sh e crontab @reboot, mascherandosi come /bin/.vmware-authd.

Indicatori di compromissione (IoC)

# Cobalt Strike C2
91.107.247[.]163

# SystemBC C2
45.86.230[.]112

# SystemBC SHA-256
992c951f4af57ca7cd8396f5ed69c2199fd6fd4ae5e93726da3e198e78bec0a5

# Leak site Tor
tezwsse5czllksjb7cwp65rvnk4oobmzti2znn42i43bjdfd2prqqkad.onion

# Contatto operatori
@TheGentlemen25 (X/Twitter)

Raccomandazioni per i difensori

Le priorità difensive si concentrano su tre fronti. Credential protection: implementare Windows Credential Guard, monitorare l’esecuzione di Mimikatz e lsass dumps, imporre MFA su tutti gli account privilegiati e in particolare su quelli con accesso al Domain Controller. GPO e lateral movement: allertare su modifiche non autorizzate ai Group Policy Objects, monitorare la creazione di scheduled task con contesto SYSTEM su host remoti, disabilitare SMB1 dove non strettamente necessario e bloccare PsExec non autorizzato. Detection comportamentale: correlare l’esecuzione parallela di PsExec, WMI e PowerShell Remoting su più host in breve tempo; monitorare la disabilitazione di Windows Defender e la cancellazione massiva di log come precursori di un evento ransomware. Check Point ha rilasciato una YARA rule specifica che rileva campioni compilati in Go tramite le stringhe caratteristiche del gruppo.

The Gentlemen rappresenta l’evoluzione moderna del RaaS: affiliati specializzati, infrastruttura condivisa con altri threat actor, velocità operativa che comprime la finestra di rilevamento a poche ore. La scoperta di 1.570 host aziendali compromessi nella botnet correlata suggerisce che l’impatto reale del gruppo superi significativamente le 320 vittime rivendicate pubblicamente — e che l’ecosistema criminale che supporta le sue operazioni sia molto più vasto di quanto finora documentato.

The Gentlemen e SystemBC: anatomia di un’operazione ransomware con botnet da 1.570 vittime aziendali - (in)sicurezza digitale

Check Point Research ha documentato come il gruppo ransomware-as-a-service The Gentlemen impieghi la botnet SystemBC per orchestrare attacchi devastanti: 320 vittime rivendicate, 1.

^{Dario Fadda ((in)sicurezza digitale)}

Spcnet.it

2026-04-21 07:55:23

RAG in .NET con Semantic Kernel: le insidie che i tutorial non ti dicono

RAG — Retrieval-Augmented Generation — è diventato il pattern dominante per integrare conoscenza dominio-specifica nei modelli linguistici. Ma tra un tutorial “hello world” e un sistema RAG che funziona davvero in produzione c’è un abisso. Questo articolo esplora le insidie reali che i tutorial non affrontano, partendo da un’implementazione in .NET con Semantic Kernel.

Il pipeline RAG in cinque fasi

Prima di entrare nei dettagli critici, è utile avere una mappa mentale del pipeline completo. Un sistema RAG ben strutturato si articola in cinque fasi sequenziali:

1. Ingestion — caricamento dei documenti sorgente
2. Chunking — suddivisione in segmenti adatti all’embedding
3. Embedding — conversione dei chunk in vettori numerici
4. Storage — persistenza dei vettori in un vector store
5. Retrieval + Generation — ricerca dei chunk rilevanti e generazione della risposta

Ogni fase nasconde decisioni non banali. Vediamo quelle che fanno davvero la differenza.

Il chunking è la variabile più sottovalutata

La qualità del chunking influenza il retrieval più di qualsiasi altra scelta, incluso il modello di embedding. La maggior parte dei tutorial usa split naive basati su caratteri o token fissi, ignorando la struttura semantica del documento.

Con Semantic Kernel, la scelta corretta per documenti Markdown è TextChunker.SplitMarkdownParagraphs(), che rispetta i confini dei paragrafi:

var chunks = TextChunker.SplitMarkdownParagraphs(
    lines: markdownContent.Split('\n').ToList(),
    maxTokensPerParagraph: 512,
    overlapTokens: 50
);

Due parametri critici spesso ignorati:

• overlapTokens: senza sovrapposizione, le frasi che cadono al confine tra due chunk vengono perse. Una sovrapposizione del 10-15% (qui 50 token su 512) risolve il problema.
• Pre-processing HTML→Markdown: se i sorgenti sono pagine web, convertire in Markdown prima del chunking (con librerie come HtmlAgilityPack) elimina tag irrilevanti che degradano la qualità dell’embedding.

Un’altra best practice avanzata: separare i blocchi di codice dalla prosa e taggare ogni chunk con metadati (tipo di contenuto, sezione, sorgente) per poter filtrare durante il retrieval.

Le soglie di rilevanza non sono universali

I tutorial usano tipicamente soglie di similarità coseno tra 0.75 e 0.80. Questo valore è quasi sempre sbagliato per il tuo corpus specifico. La soglia ottimale dipende da: qualità dell’embedding model, distribuzione semantica del corpus, tipologia delle query.

L’approccio corretto:

1. Costruire manualmente un set di valutazione di 20-30 coppie query/risposta attesa
2. Partire da 0.70 e iterare misurando Context Recall
3. Non affidarsi mai ai default senza validazione corpus-specifica

Scegliere il vector store giusto

Semantic Kernel supporta diversi backend. La scelta sbagliata genera complessità inutile o performance inadeguate:

• VolatileMemoryStore — solo per demo, dati persi al restart
• SqliteMemoryStore — sviluppo locale e prime versioni production: zero infrastruttura, persistenza garantita
• Elasticsearch — stack esistenti con ricerca ibrida (full-text + vettoriale)
• Azure AI Search — produzione su Azure, gestione scalabilità automatica
• Qdrant / Pinecone — carichi vettoriali dedicati ad alta scala

Per molte applicazioni aziendali, SQLite è la scelta razionale fino a migliaia di documenti. Aggiungere infrastruttura vettoriale dedicata ha senso solo con volumi e requisiti di latenza che lo giustificano effettivamente.

Evitare il re-embedding a ogni avvio

Uno degli errori più costosi (in termini economici e di latenza) è re-embeddare l’intero corpus a ogni riavvio dell’applicazione. La soluzione è semplice: verificare l’esistenza della collection prima di procedere all’ingestion:

var collections = await sqliteStore.GetCollectionsAsync().ToListAsync();
if (!collections.Contains(CollectionName))
{
    await ragService.IngestDocumentsAsync(documents, CollectionName);
}

Con Azure AI Search o Qdrant, la logica è analoga ma si basa sulle API specifiche del provider.

Il prompt di grounding non è opzionale

La costruzione del prompt è la difesa principale contro le allucinazioni. C’è una differenza sostanziale tra queste due istruzioni:

• “Usa il contesto seguente per rispondere” — il modello può integrare con la sua conoscenza generale
• “Rispondi SOLO usando il contesto seguente. Se la risposta non è nel contesto, dillo esplicitamente.” — vincolo semantico forte

La parola “SOLO” cambia radicalmente il comportamento del modello. In produzione, il prompt di sistema deve essere esplicito e non ambiguo.

Semantic caching per ridurre latenza e costi

Un ottimizzazione ad alto impatto spesso ignorata: se una query è semanticamente simile a una già elaborata, si può restituire la risposta cached senza chiamare il vector store né il modello:

var cachedAnswer = await cacheService.FindSimilarAsync(query, threshold: 0.92f);
if (cachedAnswer != null)
{
    return cachedAnswer.Answer;
}

Con una soglia alta (0.90-0.95), il cache serve solo query davvero simili, evitando risposte errate. Per sistemi con pattern di query ripetitivi (FAQ, assistenti documentali), questo ottimizzazione può ridurre i costi LLM del 40-60%.

Osservabilità: cosa monitorare

Un sistema RAG senza osservabilità è un sistema cieco. I KPI da tracciare per ogni richiesta:

• TopChunkScore: se costantemente sotto 0.75, il retrieval fatica. Rivedere chunking o embedding model.
• ChunksRetrieved: se raggiunge sempre il limite massimo, espandere la finestra di ricerca.
• CacheHit: se sempre false con alta latenza, la soglia del cache è troppo restrittiva.
• Latency: separare la latenza di retrieval da quella LLM per identificare il bottleneck.

Valutazione continua e CI

Il rischio silenzioso del RAG è la regressione: una modifica al chunking o alla soglia migliora alcune query e ne peggiora altre. La soluzione è integrare un set di valutazione nel pipeline CI con xUnit:

• Context Recall: i chunk corretti vengono recuperati?
• Faithfulness: la risposta rimane ancorata al contesto?
• Answer Correctness: corrisponde alla risposta attesa?

Il set di test deve includere query facili, domande che richiedono sintesi multi-documento, e domande a cui il sistema non dovrebbe rispondere (out-of-scope) — queste ultime sono fondamentali per rilevare allucinazioni.

Conclusione

Costruire un sistema RAG che funziona nei demo è relativamente semplice con Semantic Kernel. Costruirne uno che funziona in produzione — con costi controllati, latenza accettabile, assenza di allucinazioni e monitoraggio efficace — richiede decisioni architetturali precise. Il chunking con overlap, le soglie calibrate sul corpus reale, il caching semantico e l’osservabilità non sono optional: sono la differenza tra un prototipo e un sistema affidabile.

Fonte originale: RAG in .NET: What the Tutorials Don’t Tell You di Jamie Maguire.

RAG in .NET: What the Tutorials Don’t Tell You. Chunking, Embedding, and Production Gotchas – Jamie Maguire

RAG in .NET: What the Tutorials Don’t Tell You. Chunking, Embedding, and Production Gotchas

^{jamie_maguire (Jamie Maguire)}

(in)sicurezza digitale

2026-04-20 17:21:30

Dal Roblox script al breach di Vercel: come un infostealer ha quasi compromesso la supply chain di Next.js

Un dipendente che scarica script per un gioco su un dispositivo personale. Un infostealer silenzioso che raccoglie credenziali aziendali. Un gruppo criminale che usa quell’accesso come testa di ponte per violare una delle piattaforme di deployment più utilizzate al mondo dagli sviluppatori. La storia del breach di Vercel del 19 aprile 2026 è un manuale perfetto sulle supply chain attack nell’era dell’AI-as-a-service.

L’epicentro: Context.ai e il dipendente con Roblox

Tutto inizia con un’infezione apparentemente irrilevante. A febbraio 2026, un dipendente di Context.ai — un servizio di AI analytics utilizzato da numerose aziende tech tra cui Vercel — scarica sul proprio dispositivo degli script per automatizzare il gioco Roblox. Gli script sono trojanizzati e distribuiscono Lumma Stealer, uno degli infostealer-as-a-service più prolifici del 2025-2026, venduto nei mercati underground per pochi dollari al mese con funzionalità di raccolta credenziali da browser, password manager, wallet di criptovalute e token di sessione.

L’impatto è immediato: Lumma esfiltra le credenziali salvate sul dispositivo, tra cui accessi amministrativi a Google Workspace, Supabase, Datadog, Authkit e — il jackpot — account Vercel con privilegi elevati. I ricercatori di Hudson Rock hanno documentato come questa singola infezione abbia fornito il punto d’accesso iniziale che ha reso possibile tutta la catena successiva.

Il pivot: da Context.ai a Vercel

La vulnerabilità reale non era tecnica ma architetturale: Context.ai aveva accesso all’ecosistema Vercel tramite un’applicazione OAuth di Google Workspace. Una volta compromesso l’account Google del dipendente, il threat actor ha potuto usare quel token OAuth per accedere all’account Vercel collegato — senza bisogno di conoscere la password Vercel, senza trigger di MFA (perché il token era già autenticato), senza lasciare tracce convenzionali di accesso non autorizzato.

Questo tipo di attacco — noto come OAuth token hijacking tramite compromissione di terze parti — è sempre più frequente nell’ecosistema SaaS moderno, dove le integrazioni tra servizi si moltiplicano e la superficie d’attacco cresce esponenzialmente. L’analisi di Hudson Rock evidenzia come la “60-second OAuth Client ID audit” — una revisione rapida delle applicazioni OAuth connesse agli account aziendali — avrebbe potuto identificare e revocare l’accesso compromesso prima che la situazione degenerasse.

ShinyHunters rivendica: $2 milioni per codice sorgente e token

Il 19 aprile 2026, un threat actor utilizzando il nome ShinyHunters pubblica su forum underground l’offerta di un pacchetto di dati esfiltrati da Vercel, con un prezzo richiesto di 2 milioni di dollari. Il pacchetto includerebbe codice sorgente proprietario, token NPM e GitHub con accesso ai repository, credenziali database, API key interne e un file con 580 record di dipendenti Vercel contenenti nomi, email aziendali e timestamp di attività.

È importante notare che il gruppo criminale ShinyHunters — responsabile di breaches storici tra cui Ticketmaster (2024), Snowflake (2024) e decine di altri — ha pubblicamente negato il coinvolgimento in questo specifico breach. Questo è un pattern ricorrente: l’uso del brand di gruppi noti da parte di attori minori o criminali opportunisti che acquistano dati rubati da infostealer operations per poi rivenderli attribuendoli a APT o gruppi di alto profilo.

Il rischio supply chain: Next.js e Turbopack

La preoccupazione più grave non era la fuga di credenziali dei dipendenti, ma il potenziale impatto sulla supply chain software. Vercel è il creatore e maintainer principale di Next.js — il framework React più scaricato al mondo con oltre 6 milioni di download settimanali su NPM — e di Turbopack, il successore di webpack. L’accesso a token NPM e repository GitHub avrebbe potuto consentire la modifica del codice sorgente di questi framework e la pubblicazione di versioni trojanizzate, con un impatto a cascata su milioni di applicazioni web globalmente.

Vercel ha risposto rapidamente: il CEO Guillermo Rauch ha confermato che l’analisi della supply chain condotta con Google Mandiant ha verificato che Next.js, Turbopack e tutti i progetti open source della piattaforma non sono stati modificati. I token compromessi sono stati revocati immediatamente e le credenziali esposte sono state rigenerate. Un numero limitato di clienti è stato contattato direttamente per la rotazione delle variabili d’ambiente.

Il vettore più sottovalutato: i dispositivi dei dipendenti di terze parti

Questo incident è un caso di studio emblematico per un problema strutturale della sicurezza moderna: le organizzazioni investono massicciamente nella protezione dei propri endpoint aziendali, ma la catena di accesso si estende inevitabilmente ai dispositivi dei dipendenti di vendor, partner e fornitori di servizi SaaS — dispositivi su cui non hanno visibilità né controllo. Un dipendente di Context.ai che scarica uno script Roblox su un dispositivo personale non usato per lavoro potrebbe comunque avere credenziali aziendali salvate nel browser, vanificando ogni investimento in EDR aziendale.

Il 2025-2026 ha visto Lumma Stealer protagonista di decine di breaches di alto profilo. La sua distribuzione via gaming scripts, crack software e SEO poisoning è particolarmente insidiosa perché colpisce utenti che non percepiscono il rischio — e i cui dispositivi spesso hanno accesso a ecosistemi aziendali critici proprio in virtù delle integrazioni OAuth che caratterizzano il SaaS moderno.

Indicatori e azioni raccomandate

# Vettore iniziale
Lumma Stealer distribuito tramite script Roblox "auto-farm" trojanizzati

# Credenziali compromesse sul dispositivo Context.ai
- Google Workspace (account dipendente)
- Supabase (database as a service)
- Datadog (monitoraggio/osservabilità)
- Authkit (authentication service)
- Vercel (piattaforma di deployment — accesso admin)

# Dati rivendicati da ShinyHunters
- Codice sorgente proprietario Vercel
- NPM authentication tokens
- GitHub tokens
- Credenziali database
- 580 record dipendenti (nome, email, timestamp attività)

# Prezzo richiesto: $2.000.000 USD (forum underground)

# Stato supply chain (confermato da Vercel + Mandiant)
Next.js: NON compromesso
Turbopack: NON compromesso
Open source projects Vercel: NON compromessi

# Azioni immediate raccomandate per chi usa Vercel
1. Ruotare TUTTE le variabili d'ambiente non marcate "sensitive"
2. Revocare e rigenerare NPM tokens e GitHub tokens connessi a Vercel
3. Revisione audit log per accessi anomali (aprile 2026)
4. Audit OAuth apps connesse agli account Google Workspace aziendali
5. Verificare integrazioni AI tools di terze parti e relativi permessi OAuth

Lezione per i CISO: la sicurezza si ferma all’ultimo anello debole

La catena Roblox script → Lumma Stealer → Context.ai employee → OAuth token → Vercel admin access → potenziale supply chain attack su milioni di app Next.js è una dimostrazione pratica di come la sicurezza di un’organizzazione dipenda dall’anello più debole dell’intera rete di trust. I CISO devono estendere i programmi di gestione del rischio ai vendor di servizi AI — una categoria in rapida espansione con accesso privilegiato agli ambienti produttivi — e implementare politiche di revisione periodica delle OAuth app connesse agli account aziendali. La “60-second OAuth audit” non è un’esagerazione: pochi minuti potrebbero aver evitato un breach da $2 milioni e un potenziale disastro di supply chain.

netzpolitik.org

2026-04-20 09:40:27

Das Digitalministerium hatte die Zivilgesellschaft dazu aufgerufen, sich beim Deutschland-Stack einzubringen. Doch deren Expertise war am Ende doch nicht gefragt - obwohl die Zivilgesellschaft Fragen einbringt, die sonst untergehen. Das zeigt der Workshop zu „KI in der Verwaltung“ des Bündnisses F5.

netzpolitik.org/2026/deutschla…

Deutschland-Stack und Zivilgesellschaft: Digitalministerium sendet widersprüchliche Signale

Das Digitalministerium hatte die Zivilgesellschaft aufgerufen, sich beim Deutschland-Stack einzubringen. Doch in beiden Konsultationsphasen wurde deren Expertise nicht gefragt. Dabei bringt die Zivilgesellschaft Fragen ein, die sonst untergehen.

^{Esther Menhard (netzpolitik.org)}

Spcnet.it

2026-04-20 11:58:16

Rust 1.95.0: cfg_select!, if-let guard nei match e nuove API per Vec e atomici

Il 16 aprile 2026 è uscita Rust 1.95.0, una release che porta novità significative al linguaggio e alla sua libreria standard. Questa versione si segnala in particolare per l’introduzione della macro cfg_select!, il supporto agli if-let guard nei blocchi match, e una serie di nuove API per la gestione della memoria e degli atomici.

Vediamo nel dettaglio cosa cambia e come queste novità influenzano il codice quotidiano dei Rustaceans.

cfg_select!: condizionali di compilazione senza dipendenze esterne

La macro cfg_select! introduce un modo più espressivo per scrivere codice condizionale basato sulla configurazione di compilazione. Si comporta come un match valutato a compile-time sulle condizioni cfg, rimpiazzando di fatto il crate esterno cfg-if che molti progetti Rust usano da anni.

Prima di Rust 1.95, per scrivere codice dipendente dalla piattaforma si usava tipicamente:

// Prima: con cfg-if (dipendenza esterna nel Cargo.toml)
cfg_if::cfg_if! {
    if #[cfg(target_os = "linux")] {
        fn get_system_info() -> String {
            linux_system_info()
        }
    } else if #[cfg(target_os = "macos")] {
        fn get_system_info() -> String {
            macos_system_info()
        }
    } else {
        fn get_system_info() -> String {
            String::from("unknown")
        }
    }
}

Con cfg_select!, la stessa logica si esprime ora senza aggiungere dipendenze al progetto:

// Ora: built-in nella libreria standard
fn get_system_info() -> String {
    cfg_select! {
        target_os = "linux" => { linux_system_info() }
        target_os = "macos" => { macos_system_info() }
        _ => { String::from("unknown") }
    }
}

La sintassi è più pulita e il fatto di essere nella libreria standard elimina la necessità di dichiarare cfg-if nel Cargo.toml. Particolarmente utile per chi sviluppa librerie cross-platform o crate che devono supportare più sistemi operativi e architetture CPU.

if-let guard nei match: pattern matching più espressivo

Rust 1.95 stabilizza gli if-let guard all’interno delle espressioni match, costruendo sulle let chain introdotte in Rust 1.88. Un guard in un match è la condizione if che può seguire un pattern. Finora, questa condizione doveva essere un’espressione booleana semplice. Ora si può usare if let per abbinare pattern aggiuntivi direttamente nella guardia:

fn process(value: Option<Result<i32, String>>) {
    match value {
        Some(x) if let Ok(y) = x => {
            println!("Valore ottenuto: {}", y);
        }
        Some(Err(ref e)) => {
            println!("Errore: {}", e);
        }
        None => {
            println!("Nessun valore");
        }
    }
}

Questo permette di scrivere logica di pattern matching più complessa senza ricorrere a blocchi match annidati. Un caso d’uso pratico è la validazione combinata di metodo HTTP e corpo della richiesta:

fn handle_request(req: &Request) -> Response {
    match req.method() {
        Method::POST if let Ok(body) = serde_json::from_str::<Payload>(req.body()) => {
            process_payload(body)
        }
        Method::POST => {
            Response::bad_request("Payload JSON non valido")
        }
        _ => {
            Response::method_not_allowed()
        }
    }
}

Nota importante sull’esaustività: il compilatore non tiene conto dei pattern negli if-let guard per il controllo di esaustività (exhaustiveness checking). Questo significa che il compilatore non avvertirà se un pattern nell’if-let guard è irraggiungibile. Occorre quindi prestare attenzione quando si usano questi costrutti in match che devono essere esaustivi per correttezza.

Nuove API per Vec, VecDeque e atomici

push_mut e push_back_mut: riferimenti mutabili post-inserimento

Una delle aggiunte più pratiche riguarda i metodi push_mut e varianti per Vec e VecDeque. Questi metodi inseriscono un elemento e restituiscono immediatamente un riferimento mutabile all’elemento appena inserito, eliminando il doppio accesso che prima era necessario:

// Prima: due operazioni separate
let mut v: Vec<String> = Vec::new();
v.push(String::new());
let last = v.last_mut().unwrap(); // secondo accesso necessario
last.push_str("hello");

// Ora con push_mut: un unico accesso, più efficiente
let mut v: Vec<String> = Vec::new();
let elem = v.push_mut(String::new());
elem.push_str("hello"); // riferimento diretto all'elemento appena inserito

Metodi analoghi (push_back_mut, push_front_mut) sono disponibili anche su VecDeque, utile per code e buffer circolari.

update e try_update sugli atomici

I tipi atomici (AtomicUsize, AtomicBool, AtomicI32, ecc.) guadagnano i metodi update e try_update per semplificare i pattern read-modify-write senza dover scrivere manualmente il loop CAS (Compare-And-Swap):

use std::sync::atomic::{AtomicUsize, Ordering};

let counter = AtomicUsize::new(0);

// Incrementa atomicamente, restituisce il vecchio valore
let old = counter.update(Ordering::SeqCst, |x| x + 1);
println!("Valore precedente: {}", old);

// try_update: permette di fallire condizionalmente
// (ritorna Err se la chiusura restituisce None)
let result = counter.try_update(Ordering::SeqCst, |x| {
    if x < 100 { Some(x + 1) } else { None }
});

match result {
    Ok(old_val) => println!("Aggiornato da {}", old_val),
    Err(_) => println!("Limite raggiunto, nessun aggiornamento"),
}

Questi metodi gestiscono internamente il retry loop in caso di contesa tra thread, rendendo il codice più leggibile e meno soggetto a errori.

Stabilizzazioni in const context

Rust 1.95 estende il supporto ai const context per alcune API già stabili, consentendo un uso più ampio della valutazione a compile-time:

• fmt::from_fn ora utilizzabile in contesti const
• Metodi di ControlFlow ora const-stabili
• Nuovi metodi unsafe per puntatori: as_ref_unchecked e as_mut_unchecked
• Layout::dangling_ptr per manipolazione avanzata della memoria in allocatori custom

Breaking change: JSON target spec non più supportata su stable

Rust 1.95 rimuove il supporto alle specifiche di target in formato JSON sul canale stable. Questa funzionalità era già effettivamente limitata al canale nightly (costruire core richiedeva già nightly), quindi l’impatto pratico è minimo per la maggior parte dei progetti. Chi usa target custom non standard dovrà assicurarsi di usare il canale nightly o di migrare a definizioni di target ufficialmente supportate.

Come aggiornare

Per aggiornare Rust all’ultima versione stabile, basta eseguire:

rustup update stable

Per verificare la versione installata:

rustc --version
# rustc 1.95.0 (xxxxxxxx 2026-04-16)

Conclusioni

Rust 1.95.0 è una release solida che porta miglioramenti trasversali all’ergonomia del linguaggio. cfg_select! riduce la dipendenza da crate esterni per il codice condizionale, gli if-let guard aumentano l’espressività del pattern matching, e le nuove API per Vec e atomici semplificano pattern comuni nella gestione dello stato condiviso in contesti concorrenti.

Nel complesso, questa release conferma la direzione del progetto Rust: migliorare l’ergonomia senza compromettere la sicurezza, incorporando nella libreria standard soluzioni che prima richiedevano crate esterni.

Fonte: Announcing Rust 1.95.0 — The Rust Programming Language Blog

Announcing Rust 1.95.0 | Rust Blog

Empowering everyone to build reliable and efficient software.

^{blog.rust-lang.org}