(in)sicurezza digitale

2026-05-15 09:04:54

ApocalypseZ: come gli hacker russi automatizzano il furto di account Signal su scala industriale

Si parla di:
Toggle

Il 14 maggio 2026 TechCrunch ha pubblicato una storia che ha del cinematografico: un ricercatore specializzato nell’investigare attacchi spyware diventa lui stesso bersaglio di hacker governativi russi, ma invece di soccombere trasforma l’attacco in un’indagine che porta alla scoperta di un’infrastruttura di spionaggio capace di prendere di mira oltre 13.500 persone. La storia di Donncha Ó Cearbhaill, responsabile del Security Lab di Amnesty International, è la dimostrazione pratica di come lo spionaggio digitale di Stato oggi lavori in modo industrializzato, automatizzato e scalabile.

Il messaggio che non inganna (ma quasi)

Tutto è iniziato con un messaggio sul suo account Signal: “Dear User, this is Signal Security Support ChatBot. We have noticed suspicious activity on your device, which could have led to data leak. We have also detected attempts to gain access to your private data in Signal. To prevent this, you have to pass verification procedure, entering the verification code to Signal Security Support Chatbot. DON’T TELL ANYONE THE CODE, NOT EVEN SIGNAL EMPLOYEES.”

Il messaggio è grossolano per un esperto di sicurezza — nessuna piattaforma legittima chiede mai codici di verifica via chat — ma per un utente ordinario è sufficientemente convincente. La minaccia di una violazione imminente, il tono urgente, la richiesta di non condividere il codice: tutti elementi classici di ingegneria sociale progettati per innescare una risposta emotiva prima che quella razionale possa intervenire.

Il meccanismo tecnico: device linking via codice OTP

L’obiettivo dell’attacco non è rubare la password (Signal non ha password tradizionali), ma sfruttare la funzionalità legittima di linked devices di Signal. Quando si collega un nuovo dispositivo a un account Signal esistente, l’app genera un QR code o un codice numerico. Se l’utente viene ingannato a condividere questo codice con gli attaccanti, questi possono aggiungere un dispositivo controllato da loro come “dispositivo secondario” dell’account — ottenendo così accesso a tutti i messaggi futuri e a quelli precedenti sincronizzati.

La tecnica non richiede zero-day, exploit sofisticati o accesso fisico al dispositivo: bastano ingegneria sociale e un utente che si fida abbastanza da inserire un codice. Ó Cearbhaill, riconoscendo immediatamente la natura del tentativo, ha deciso di non bloccare l’interazione ma di utilizzarla come punto d’ingresso per investigare la campagna.

ApocalypseZ: la piattaforma di attacco di Stato

La scoperta più significativa dell’indagine è lo strumento che gli attaccanti utilizzano: ApocalypseZ. Si tratta di una piattaforma di automazione degli attacchi che consente agli operatori di prendere di mira molte persone simultaneamente con supervisione umana minima. Il codebase e l’interfaccia operativa sono in russo, e lo strumento include funzionalità di traduzione automatica dei messaggi delle vittime in russo — elemento che allinea l’attribuzione ai servizi intelligence russi confermata da CISA, NCSC britannico e intelligence olandese.

La logica operativa di ApocalypseZ funziona come un “funnel” automatizzato: il sistema invia messaggi di phishing in bulk, traccia le risposte, e quando una vittima interagisce attivamente, allerta un operatore umano per gestire la fase di convincimento finale. Questo approccio semi-automatizzato consente di scalare la campagna a decine di migliaia di bersagli mantenendo l’efficacia del social engineering.

La “snowball hypothesis”: come si espande il targeting

Ó Cearbhaill ha identificato un pattern importante nel modo in cui gli attaccanti selezionano i propri bersagli. Egli chiama questo meccanismo la “snowball hypothesis”: quando gli hacker compromettono con successo un account Signal, ottengono accesso alla lista dei contatti e alle chat di gruppo di quella persona. Questo fornisce una lista pronta di nuovi potenziali bersagli — colleghi, giornalisti, attivisti, fonti — che vengono aggiunti automaticamente alla coda di attacco.

Il ricercatore ritiene di essere diventato un bersaglio perché era membro di una chat di gruppo con qualcuno che era già stato compromesso. Tra i target identificati figurano giornalisti con cui aveva lavorato e un collega diretto — confermando che il network di contatti delle vittime è il principale meccanismo di espansione della campagna.

Scala e attribuzione: 13.500 bersagli e CISA

Analizzando l’infrastruttura di ApocalypseZ, Ó Cearbhaill ha determinato di essere tra almeno 13.500 bersagli identificati — e lui stesso precisa che il numero reale è certamente molto più alto, poiché la campagna era ancora attiva al momento della pubblicazione del suo report. Tra le vittime confermate vi sarebbero anche politici di alto profilo tedeschi, come riportato da Der Spiegel.

L’attribuzione a hacker governativi russi è stata formalizzata da più agenzie: la CISA statunitense, il NCSC britannico e i servizi d’intelligence olandesi hanno tutti emesso avvisi pubblici su questa campagna. Il targeting include giornalisti, ricercatori di sicurezza, funzionari governativi, attivisti e personale delle ONG — il tipico profilo di interesse dei servizi d’intelligence russi (FSB/GRU/SVR).

Il contesto: una campagna di lunga durata contro le app di messaggistica sicura

Questo attacco non è isolato. Da inizio 2026, Signal ha emesso avvisi pubblici su campagne di phishing contro i propri utenti. L’intelligence olandese aveva già messo in guardia a marzo 2026 contro hacker russi che prendono di mira Signal e WhatsApp. Il pattern è chiaro: man mano che la crittografia end-to-end è diventata lo standard per le comunicazioni sensibili, i servizi d’intelligence hanno spostato i propri sforzi dall’intercettazione delle comunicazioni al compromissione degli endpoint — cioè del dispositivo o dell’account dell’utente.

Signal stesso, nella sua architettura, è resistente agli attacchi a livello di rete. Ma nessuna crittografia può proteggere da un utente che viene convinto a consegnare volontariamente l’accesso al proprio account.

Indicatori e vettori di attacco

# Campagna phishing Signal - APT russo (ApocalypseZ)
# Rilevata: inizio 2026 | Pubblicata: 14 maggio 2026

## Vettore di attacco
- Piattaforma: Signal (messaggistica diretta)
- Metodo: impersonificazione "Signal Security Support ChatBot"
- Obiettivo: ottenere codice OTP per device linking
- Automazione: strumento ApocalypseZ (codebase in russo)

## Tecnica (MITRE ATT&CK)
- T1566 - Phishing
- T1078 - Valid Accounts (device linking tramite codice OTP legittimo)
- T1119 - Automated Collection (scraping lista contatti post-compromissione)

## Targeting
- 13.500+ bersagli identificati (numero reale superiore)
- Profili: giornalisti, ricercatori sicurezza, funzionari gov, attivisti, ONG
- Nazioni: USA, UK, Germania, Paesi Bassi, altri paesi NATO/UE

## Attribuzione
- CISA (USA): hacker governativi russi
- NCSC (UK): campagna attribuita a spie russe
- AIVD (NL): servizi intelligence russi

## Indicatori comportamentali (social engineering)
- Messaggio urgente da "Signal Security Support"
- Richiesta codice OTP/verifica
- Istruzione "non condividere il codice"
- Pressione temporale per completare verifica

## Difesa specifica
- Abilitare Registration Lock in Signal (Impostazioni > Account > PIN)
- Non condividere MAI codici OTP ricevuti su Signal
- Verificare dispositivi collegati: Impostazioni > Dispositivi collegati

Due righe per i difensori

La difesa contro questo tipo di attacco è paradossalmente semplice rispetto alla sofisticazione dell’infrastruttura offensiva. Ó Cearbhaill raccomanda di attivare immediatamente la funzione Registration Lock di Signal (nelle impostazioni come PIN di blocco registrazione): questa feature impedisce che il proprio numero di telefono venga registrato su un nuovo dispositivo senza conoscere il PIN, vanificando il device linking non autorizzato anche se l’attaccante ottiene il codice OTP.

Più in generale, per le organizzazioni che gestiscono profili ad alto rischio — giornalisti investigativi, difensori dei diritti umani, ricercatori di sicurezza, funzionari governativi — è fondamentale adottare un approccio sistematico alla sicurezza delle comunicazioni: audit periodico dei dispositivi collegati a ogni account, formazione sul riconoscimento del social engineering su piattaforme di messaggistica, e protocolli di verifica out-of-band quando si ricevono richieste inusuali anche da fonti apparentemente note.

La storia di Ó Cearbhaill termina con una nota di sfida aperta: il ricercatore ha dichiarato di dubitare che gli attaccanti proveranno a colpirlo di nuovo, e di dare il benvenuto a futuri messaggi — specialmente se contenessero zero-day da condividere. Un invito ironico che sintetizza l’essenza del lavoro di chi studia lo spionaggio digitale: trasformare ogni attacco in conoscenza.

Spcnet.it

2026-05-14 15:55:44

SimpleChat: un template Blazor provider-agnostico per chat AI con .NET 10 Aspire

Chi sviluppa applicazioni AI in .NET lo sa bene: ogni volta che si integra un LLM in un progetto Blazor, si finisce a riscrivere lo stesso boilerplate per connettere OpenAI, Azure OpenAI, Anthropic o Google. SimpleChat è un template open-source che risolve esattamente questo problema — un’applicazione Blazor Server + .NET 10 Aspire che gestisce quattro provider AI in modo intercambiabile, esponendo un unico IChatClient all’intera applicazione.

Il progetto è disponibile su GitHub: github.com/ADefWebserver/SimpleChat

Perché esiste SimpleChat

Il problema che SimpleChat risolve è concreto: ogni provider AI ha il proprio contratto REST, le proprie intestazioni e le proprie particolarità. OpenAI usa una API key e un base URL. Azure OpenAI richiede un endpoint, un deployment name e una versione API. Anthropic ha il proprio formato di richiesta e rifiuta il parametro temperature sui modelli Claude 4 con ragionamento. Google AI (Gemini) ha ancora un’altra struttura REST sotto generativelanguage.googleapis.com.

SimpleChat risolve tutto questo costruendo su Microsoft.Extensions.AI e centralizzando la logica di creazione del client in una sola classe: ChatClientFactory. Tutto il codice upstream non deve mai sapere quale provider è attivo.

Architettura del progetto

La soluzione Aspire è composta da tre progetti:

• SimpleChat — l’app web Blazor Server
• SimpleChat.AppHost — l’orchestratore Aspire
• SimpleChat.ServiceDefaults — OpenTelemetry condiviso, health check e resilienza

I componenti principali dell’applicazione sono:

• AIConfigurationService — legge la sezione AI della configurazione e scrive le modifiche dell’utente su disco
• ChatClientFactory — l’unico posto dove l’app conosce la differenza tra i provider; restituisce un IChatClient
• ChatService — orchestratore stateless che fa streaming delle risposte dall’IChatClient attivo
• AIModelService — chiama l’endpoint /models di ogni provider, con una lista di fallback

Il modello di configurazione

Tutta la configurazione AI vive in una sezione AI di appsettings.json:

{
  "AI": {
    "ActiveProvider": "OpenAI",
    "Providers": {
      "OpenAI": {
        "Enabled": true,
        "ApiKey": "",
        "Endpoint": "https://api.openai.com/v1",
        "DefaultModel": "gpt-4o-mini",
        "Models": ["gpt-4o-mini", "gpt-4o", "gpt-5-mini", "o4-mini"]
      },
      "AzureOpenAI": {
        "Enabled": false,
        "ApiKey": "",
        "Endpoint": "",
        "DeploymentName": "",
        "ApiVersion": "2024-10-21"
      },
      "Anthropic": {
        "Enabled": false,
        "ApiKey": "",
        "Endpoint": "https://api.anthropic.com",
        "DefaultModel": "claude-sonnet-4-20250514"
      },
      "GoogleAI": {
        "Enabled": false,
        "ApiKey": "",
        "Endpoint": "https://generativelanguage.googleapis.com",
        "DefaultModel": "gemini-2.5-flash"
      }
    },
    "Defaults": {
      "Temperature": 0.7,
      "MaxOutputTokens": 1024,
      "SystemPrompt": "You are a helpful assistant."
    }
  }
}

Questa struttura è il contratto. Per scambiare il layer di storage (database, Key Vault, browser storage, file share), basta modificare solo AIConfigurationService — nient’altro nell’app cambia.

La ChatClientFactory: un solo posto per tutta la logica provider

La factory è il cuore del template. Dopo che questo metodo ritorna, tutto il codice downstream vede solo un IChatClient:

public (IChatClient Client, string Model) Create(string providerKey)
{
    var key = NormalizeProviderKey(providerKey);
    var settings = _config.GetProvider(key);

    if (!settings.Enabled)
        throw new InvalidOperationException($"Provider '{providerKey}' is disabled.");

    IChatClient inner;
    string model;

    switch (key)
    {
        case "OpenAI":
            model = settings.DefaultModel ?? "gpt-4o-mini";
            var openAI = new OpenAIClient(
                new ApiKeyCredential(settings.ApiKey!),
                new OpenAIClientOptions { Endpoint = ... });
            inner = openAI.GetChatClient(model).AsIChatClient();
            break;

        case "AzureOpenAI":
            model = settings.DeploymentName!;
            var azure = new AzureOpenAIClient(
                new Uri(settings.Endpoint!),
                new AzureKeyCredential(settings.ApiKey!));
            inner = azure.GetChatClient(model).AsIChatClient();
            break;

        case "Anthropic":
            model = settings.DefaultModel ?? "claude-sonnet-4-20250514";
            inner = new AnthropicChatClient(settings.ApiKey!, model, _httpClientFactory.CreateClient(...));
            break;

        case "GoogleAI":
            model = settings.DefaultModel ?? "gemini-2.5-flash";
            inner = new GoogleAIChatClient(settings.ApiKey!, model, _httpClientFactory.CreateClient(...));
            break;

        default:
            throw new InvalidOperationException($"Unknown provider '{providerKey}'.");
    }

    return (inner, model);
}

Per Anthropic e Google AI, SimpleChat include client personalizzati (AnthropicChatClient e GoogleAIChatClient) che adattano le rispettive REST API all’interfaccia IChatClient di Microsoft.Extensions.AI — necessari perché questi provider non hanno ancora un pacchetto MEAI ufficiale.

Streaming e configurazione runtime

ChatService.StreamAsync restituisce un IAsyncEnumerable<string> di chunk di token. L’interfaccia utente fa lo streaming degli aggiornamenti nella bolla dell’assistente man mano che arrivano, e supporta un pulsante Cancel che interrompe la chiamata in corso.

Una delle funzionalità più interessanti è il cambio di provider e modello a runtime senza riavviare l’app. Il dropdown viene popolato dall’endpoint /models live di ogni provider. Il trucco tecnico è in Program.cs:

builder.Configuration.AddJsonFile(userOverlay, optional: true, reloadOnChange: true);
// ...
builder.Services.AddOptions<AIOptions>()
    .Bind(builder.Configuration.GetSection(AIOptions.SectionName));

reloadOnChange: true fa sì che salvare il file faccia scattare IOptionsMonitor<AIOptions>.OnChange, al quale il ChatPanel è sottoscritto — così il dropdown del provider si aggiorna senza ricaricare la pagina.

Gestione sicura delle chiavi API

In Development, le modifiche alla pagina Settings vengono scritte su appsettings.Development.json. In Production vengono scritte su un file separato appsettings.User.json che viene sovrapposto ad appsettings.json all’avvio — così le chiavi reali non devono mai essere committate nel repository.

private string WritablePath => _env.IsDevelopment()
    ? Path.Combine(_env.ContentRootPath, "appsettings.Development.json")
    : Path.Combine(_env.ContentRootPath, "appsettings.User.json");

Come usarlo come template per i propri agenti AI

Il vero valore di SimpleChat non è l’applicazione in sé, ma il pattern riutilizzabile che porta con sé. Quando si inizia una nuova app, si può puntare un agente AI di coding verso questo repository con l’istruzione: “implementa la configurazione di SimpleChat, ma salva le impostazioni AI in un database (o in un file JSON, o in Azure Key Vault, o dove mi dici).” Tutta la logica di incollaggio specifica per provider è già fatta.

Il contratto è semplice: l’agente deve implementare solo AIConfigurationService per leggere e scrivere lo stesso grafo di oggetti AIOptions. Nient’altro nell’app deve cambiare.

Conclusione

SimpleChat è un punto di partenza concreto per chiunque voglia costruire applicazioni AI con Blazor e .NET 10 Aspire senza dover reinventare ogni volta la ruota dell’integrazione multi-provider. L’architettura è intenzionalmente piccola e comprensibile: un frontend Blazor Server, un servizio di configurazione, una factory che produce un IChatClient, e un orchestratore di streaming leggero sopra. Il codice è aperto e modificabile per adattarsi a qualsiasi layer di storage.

Per chi lavora regolarmente con LLM in progetti .NET, avere questo template a disposizione può fare risparmiare ore di lavoro ripetitivo ad ogni nuovo progetto.

Fonte originale: SimpleChat: A Provider-Agnostic AI Chat Starter for Blazor di Michael Washington — via Morning Dew #4664

Dew Drop – May 8, 2026 (#4664) – Morning Dew by Alvin Ashcraft

Dew Drop – May 8, 2026 (#4664)

^{Alvin A. (Morning Dew by Alvin Ashcraft)}

Spcnet.it

2026-05-14 15:54:25

LINQ in C#: guida completa alle operazioni di aggregazione (Count, Sum, MinBy, MaxBy, Aggregate)

Le operazioni di aggregazione sono tra le più frequenti in qualsiasi applicazione .NET che lavora con collezioni di dati. LINQ mette a disposizione un toolkit completo: dagli operatori di base come Count e Sum, alle più potenti MinBy/MaxBy introdotte in .NET 6, fino ad Aggregate, il fold generico che permette di sostituire loop complessi con pipeline dichiarative. In questo articolo approfondiamo ogni operatore con esempi pratici, evidenziamo le trappole di performance più comuni e mostriamo come costruire aggregazioni efficienti anche in scenari avanzati.

Il modello di dominio

Tutti gli esempi utilizzano tre record che rappresentano un sistema di ordini e vendite:

public record Order(int Id, string CustomerId, string Status, decimal Total, DateTimeOffset PlacedAt);
public record Product(int Id, string Name, string Category, decimal Price, int StockLevel);
public record SalesData(string Region, string ProductId, int UnitsSold, decimal Revenue, DateTimeOffset Period);


Count e LongCount

Count() restituisce il numero di elementi come int. La versione con predicato conta solo gli elementi che soddisfano la condizione:

IEnumerable<Order> orders = GetOrders();

int total        = orders.Count();
int pendingCount = orders.Count(o => o.Status == "Pending");
int paidCount    = orders.Count(o => o.Status == "Paid");

Console.WriteLine($"Totale: {total}, In attesa: {pendingCount}, Pagati: {paidCount}");


Per sequenze con più di int.MaxValue elementi (circa 2,1 miliardi), usare LongCount() che restituisce long. Nella pratica, questo scenario si presenta principalmente in contesti di log aggregation o telemetria su larga scala.

La trappola di performance: Count vs Any

Questo è uno degli errori di performance più diffusi con LINQ. Quando si vuole verificare l’esistenza di almeno un elemento, molti sviluppatori usano Count() > 0 invece di Any():

IEnumerable<Order> orders = GetOrders();

// ❌ Count() valuta l'intera sequenza — O(n)
if (orders.Count(o => o.Status == "Pending") > 0)
{
    Console.WriteLine("Ci sono ordini in attesa.");
}

// ✅ Any() si ferma al primo match — O(1) nel caso migliore
if (orders.Any(o => o.Status == "Pending"))
{
    Console.WriteLine("Ci sono ordini in attesa.");
}


Any(predicate) cortocircuita non appena trova il primo elemento corrispondente. Count(predicate) deve valutare ogni elemento per produrre un conteggio accurato, anche quando la risposta a “esiste almeno un elemento?” sarebbe nota immediatamente. La differenza di performance è particolarmente evidente con sorgenti lazy, query EF Core o sequenze molto lunghe.

Stesso principio per il test di sequenza vuota:

// ❌ Enumera tutta la sequenza
if (orders.Count() == 0) { }

// ✅ Si ferma al primo elemento
if (!orders.Any()) { }


La regola da memorizzare: usare Any() per verifiche di esistenza, Count() solo quando serve il numero esatto.

Sum e Average

Sum(selector) e Average(selector) accettano un selettore per proiettare ogni elemento a un valore numerico prima di aggregare:

IEnumerable<Order> orders = GetOrders();

decimal totalRevenue = orders.Sum(o => o.Total);
decimal averageOrder = orders.Average(o => o.Total);

Console.WriteLine($"Fatturato totale: €{totalRevenue:F2}");
Console.WriteLine($"Ordine medio: €{averageOrder:F2}");


Importante: Average() lancia InvalidOperationException su una sequenza vuota. È buona pratica proteggersi con un controllo preventivo:

decimal? safeAverage = orders.Any()
    ? orders.Average(o => o.Total)
    : null;


Un esempio più articolato che combina GroupBy con Sum e Average per ottenere statistiche per regione geografica:

IEnumerable<SalesData> sales = GetSalesData();

var revenueByRegion = sales
    .GroupBy(s => s.Region)
    .Select(g => new
    {
        Region       = g.Key,
        TotalRevenue = g.Sum(s => s.Revenue),
        AverageUnits = g.Average(s => s.UnitsSold)
    })
    .OrderByDescending(x => x.TotalRevenue);

foreach (var row in revenueByRegion)
{
    Console.WriteLine($"{row.Region}: €{row.TotalRevenue:F0}, media {row.AverageUnits:F1} unità");
}


Min e Max

Min(selector) e Max(selector) restituiscono il valore scalare minimo o massimo — non l’elemento che lo contiene:

IEnumerable<Product> products = GetProducts();

decimal cheapest      = products.Min(p => p.Price);
decimal mostExpensive = products.Max(p => p.Price);

Console.WriteLine($"Range prezzi: €{cheapest:F2} — €{mostExpensive:F2}");


Il limite: se serve il prodotto più economico (non solo il suo prezzo), prima di .NET 6 si era costretti a enumerare la sequenza due volte:

// Prima di .NET 6 — due passaggi, potenziale bug con prezzi duplicati
decimal minPrice     = products.Min(p => p.Price);
Product? cheapestOld = products.FirstOrDefault(p => p.Price == minPrice);


Questo approccio ha un bug sottile: se più prodotti condividono il prezzo minimo, FirstOrDefault sceglie il primo trovato nell’ordine di iterazione, che potrebbe non essere quello desiderato. Inoltre itera la sequenza due volte.

MinBy e MaxBy: l’elemento, non il valore (.NET 6+)

MinBy(keySelector) e MaxBy(keySelector) restituiscono l’elemento che ha il valore minimo o massimo della chiave, in un singolo passaggio sulla sequenza:

// .NET 6+ — singolo passaggio, restituisce l'elemento
Product? cheapest      = products.MinBy(p => p.Price);
Product? mostExpensive = products.MaxBy(p => p.Price);

Console.WriteLine($"Più economico: {cheapest?.Name} a €{cheapest?.Price:F2}");
Console.WriteLine($"Più costoso: {mostExpensive?.Name} a €{mostExpensive?.Price:F2}");


Quando più elementi condividono la stessa chiave minima/massima, MinBy/MaxBy restituiscono il primo incontrato, coerentemente con la semantica di OrderBy().First().

Esempio reale: trovare il periodo di vendita con fatturato più alto e la regione con performance peggiore:

// Periodo con il singolo record di fatturato più alto
SalesData? topPeriod = sales.MaxBy(s => s.Revenue);
Console.WriteLine($"Periodo migliore: {topPeriod?.Region} — €{topPeriod?.Revenue:F2}");

// Regione con fatturato totale più basso
var revenueSummary = sales
    .GroupBy(s => s.Region)
    .Select(g => (Region: g.Key, Total: g.Sum(s => s.Revenue)));

(string Region, decimal Total) worstRegion = revenueSummary.MinBy(r => r.Total);
Console.WriteLine($"Regione con fatturato minore: {worstRegion.Region} (€{worstRegion.Total:F2})");


Aggregate: fold personalizzato

Aggregate è l’operatore più generale: accetta un valore seed e una funzione accumulatrice, piegando ogni elemento nel risultato accumulato. È il fold funzionale di LINQ, e può fare tutto ciò che i metodi specializzati fanno — e molto di più:

IEnumerable<Order> orders = GetOrders();

// Concatena gli ID degli ordini come stringa CSV
string orderList = orders.Aggregate(
    string.Empty,
    (acc, order) => string.IsNullOrEmpty(acc)
        ? order.Id.ToString()
        : $"{acc},{order.Id}");

Console.WriteLine($"ID ordini: {orderList}");


Caso pratico: calcolo del fattore di sconto combinato (moltiplicativo):

decimal[] discounts = [0.10m, 0.05m, 0.15m]; // 10%, 5%, 15%

// Il fattore risultante dopo l'applicazione di tutti gli sconti in sequenza
decimal combinedFactor = discounts.Aggregate(
    1.0m,
    (factor, discount) => factor * (1 - discount));

Console.WriteLine($"Fattore combinato: {combinedFactor:P2}"); // es. 72,54%


Aggregate con result selector

La variante a tre argomenti aggiunge una proiezione finale applicata al risultato accumulato dopo aver processato tutti gli elementi. Questo permette di calcolare la media in un singolo passaggio senza dover iterare due volte:

IEnumerable<SalesData> sales = GetSalesData();

decimal averageRevenue = sales.Aggregate(
    seed: (Total: 0m, Count: 0),
    func: (acc, s) => (acc.Total + s.Revenue, acc.Count + 1),
    resultSelector: acc => acc.Count > 0 ? acc.Total / acc.Count : 0m);

Console.WriteLine($"Fatturato medio: €{averageRevenue:F2}");


Aggregazioni multiple in un singolo passaggio

Calcolare più aggregazioni sulla stessa sequenza in modo ingenuo significa iterarla più volte. Per sorgenti costose — query su database, chiamate di rete, lettura di file — questo ha un impatto reale. La soluzione è usare Aggregate con un accumulatore composito che raccoglie tutti i valori contemporaneamente:

public record AggregateSummary(int Count, decimal Sum, decimal Min, decimal Max);

IEnumerable<Order> orders = GetOrders();

AggregateSummary summary = orders.Aggregate(
    new AggregateSummary(0, 0m, decimal.MaxValue, decimal.MinValue),
    (acc, order) => new AggregateSummary(
        acc.Count + 1,
        acc.Sum   + order.Total,
        Math.Min(acc.Min, order.Total),
        Math.Max(acc.Max, order.Total)));

decimal average = summary.Count > 0 ? summary.Sum / summary.Count : 0m;

Console.WriteLine($"Count:   {summary.Count}");
Console.WriteLine($"Somma:   €{summary.Sum:F2}");
Console.WriteLine($"Minimo:  €{summary.Min:F2}");
Console.WriteLine($"Massimo: €{summary.Max:F2}");
Console.WriteLine($"Media:   €{average:F2}");


Un passaggio, quattro valori. Questo pattern è particolarmente utile nei query handler CQRS in cui il risultato richiede più statistiche e la sorgente dati è un database o un servizio esterno.

TryGetNonEnumeratedCount (.NET 6)

Prima di calcolare aggregazioni che richiedono il conteggio, conviene verificare se è disponibile senza enumerare la sequenza:

IEnumerable<Order> orders = GetOrders();

if (orders.TryGetNonEnumeratedCount(out int count))
{
    Console.WriteLine($"Conteggio rapido: {count}");
    // Disponibile senza iterare — usabile per pre-allocazione o logging
}
else
{
    // Fallback: deve enumerare
    count = orders.Count();
}


TryGetNonEnumeratedCount restituisce true per List<T>, array, HashSet<T> e altri tipi che implementano ICollection<T>. Restituisce false per pipeline lazy, risultati di GroupBy e qualsiasi IEnumerable che deve essere valutato per conoscere la propria lunghezza.

Novità .NET 9: CountBy e AggregateBy

.NET 9 ha introdotto due nuovi operatori di aggregazione per chiave che migliorano i pattern basati su GroupBy:

IEnumerable<Order> orders = GetOrders();

// CountBy: conta gli elementi per chiave — più conciso di GroupBy + Count
var countByStatus = orders.CountBy(o => o.Status);
foreach (var (status, count) in countByStatus)
{
    Console.WriteLine($"{status}: {count} ordini");
}

// AggregateBy: aggregazione personalizzata per chiave
var totalByCustomer = orders.AggregateBy(
    keySelector: o => o.CustomerId,
    seed: 0m,
    func: (total, order) => total + order.Total);

foreach (var (customerId, total) in totalByCustomer)
{
    Console.WriteLine($"Cliente {customerId}: €{total:F2}");
}


Per aggregazioni per chiave in .NET 9+, preferire CountBy e AggregateBy rispetto a GroupBy seguito da aggregazione: il codice è più leggibile e spesso più efficiente.

Guida rapida alla scelta dell’operatore

• Verificare se esiste almeno un elemento → Any(predicate)
• Contare elementi → Count() / Count(predicate)
• Somma di valori proiettati → Sum(selector)
• Media di valori proiettati → Average(selector)
• Valore scalare minimo/massimo → Min(selector) / Max(selector)
• Elemento con chiave minima (.NET 6+) → MinBy(keySelector)
• Elemento con chiave massima (.NET 6+) → MaxBy(keySelector)
• Conteggio per chiave (.NET 9+) → CountBy(keySelector)
• Aggregazione personalizzata per chiave (.NET 9+) → AggregateBy(keySelector, seed, func)
• Fold generico con seed → Aggregate(seed, func)
• Fold generico con proiezione finale → Aggregate(seed, func, resultSelector)

Conclusione

Le operazioni di aggregazione LINQ coprono l’intero spettro delle necessità di riduzione dei dati. Conoscere la differenza tra Any e Count, sapere quando usare MinBy/MaxBy invece di un doppio passaggio, e saper costruire fold multi-valore con Aggregate sono competenze che migliorano sia le performance che la leggibilità del codice. Con l’aggiunta di CountBy e AggregateBy in .NET 9, il toolkit di aggregazione LINQ è oggi più completo che mai: vale la pena tenerlo presente come alternativa ai foreach loop ogni volta che si lavora con trasformazioni di collezioni.

Fonte: LINQ Aggregation in C#: Count, Sum, Min, Max, Average, and Aggregate — Dev Leader

LINQ Aggregation in C#: Count, Sum, Min, Max, Average, and Aggregate

Master LINQ aggregation in C# with Count, Sum, MinBy, MaxBy, and custom Aggregate, plus why Count vs Any matters for real-world .NET performance.

^{Nick Cosentino (Dev Leader)}

(in)sicurezza digitale

2026-05-14 15:53:26

FamousSparrow nel Caucaso: tre ondate di spionaggio cinese colpiscono il gas azero che alimenta l’Europa

Quando il 25 dicembre 2025 un processo silenzioso ha tentato di scrivere una web shell in una directory pubblica di un server Microsoft Exchange di un’azienda petrolifera azera, nessuno sapeva ancora che quello era l’inizio di un’operazione di cyberspionaggio in tre ondate. Il gruppo cinese FamousSparrow ha dimostrato una persistenza metodica e una sofisticazione tecnica che va ben oltre la semplice opportunismo: ha continuato a rientrare nello stesso sistema, cambiando ogni volta backdoor, per quasi due mesi. La ricerca di Bitdefender pubblicata il 13 maggio 2026 ricostruisce l’intera catena.

Un bersaglio di valore strategico nel Caucaso meridionale

L’Azerbaigian non è mai stato un paese secondario per la sicurezza energetica europea, ma la sua importanza è cresciuta esponenzialmente negli ultimi anni. Con la scadenza nel 2024 del transito del gas russo attraverso l’Ucraina e le successive interruzioni dello Stretto di Hormuz nel 2026, Baku si è trasformata in uno snodo critico per l’approvvigionamento energetico del continente. Chi controlla l’informazione che circola all’interno di quelle aziende ha accesso a dati di valore incalcolabile: prezzi di vendita futuri, capacità estrattive, negoziati contrattuali, infrastrutture fisiche.

È esattamente in questo contesto che Bitdefender Labs ha individuato un’intrusione plurifase attribuita con fiducia da moderata ad alta al gruppo FamousSparrow, noto anche come UAT-9244 e storicamente sovrapponibile a cluster come Earth Estries e Salt Typhoon — tutte denominazioni che orbitano intorno all’ecosistema dello spionaggio informatico legato allo stato cinese. L’obiettivo era un’azienda petrolifera e del gas azerbaigiana non nominata. L’operazione è durata dalla fine di dicembre 2025 alla fine di febbraio 2026.

Tre ondate, stesso ingresso: la tattica della porta sempre aperta

L’aspetto più rilevante dal punto di vista operativo è la persistenza attraverso lo stesso vettore iniziale nonostante i tentativi di bonifica. Gli attaccanti hanno sfruttato la catena ProxyNotShell (CVE-2022-41082 / CVE-2022-41040) su un server Microsoft Exchange esposto, una vulnerabilità che risale al 2022 ma che molte organizzazioni non hanno ancora patchato correttamente.

Il processo w3wp.exe è stato osservato tentare di scrivere una web shell in una directory pubblica del server Exchange il 25 dicembre 2025, avviando la prima ondata. Invece di cambiare punto di accesso quando il team difensivo ha tentato la remediation, FamousSparrow ha semplicemente sostituito la backdoor, dimostrando che la vulnerabilità non era stata effettivamente chiusa:

• Ondata 1 — Dicembre 2025: Deploy di Deed RAT (aka Snappybee), successore di ShadowPad, strumento condiviso tra molteplici gruppi di spionaggio cinesi. Caricato tramite DLL sideloading sul binario legittimo di LogMeIn Hamachi.
• Ondata 2 — Fine gennaio / inizio febbraio 2026: Sostituzione con TernDoor, un backdoor recentemente documentato in attacchi alle telecomunicazioni sudamericane nel 2024, mai visto prima nel Caucaso.
• Ondata 3 — Fine febbraio 2026: Ritorno a una variante modificata di Deed RAT, probabilmente aggiornata per eludere le firme generate dopo le prime rilevazioni.

L’arsenale tecnico: DLL sideloading di nuova generazione

Ciò che distingue questa campagna da molte altre operazioni APT è l’evoluzione della tecnica di DLL sideloading utilizzata per caricare Deed RAT. Il metodo tradizionale si limita a rimpiazzare una libreria legittima; la variante di FamousSparrow va oltre, sovrascrivendo due specifiche funzioni esportate all’interno della DLL malevola. Questo crea un meccanismo a doppio trigger che subordina l’esecuzione del loader di Deed RAT al flusso di controllo naturale dell’applicazione host — in questo caso il client Hamachi di LogMeIn.

Il risultato pratico è duplice: il processo appare legittimo agli strumenti di monitoring basati su firma, e l’analisi statica del binario non rivela comportamenti anomali fino all’esecuzione del secondo trigger. Un design che porta il segno di un gruppo con elevate capacità di sviluppo custom.

Deed RAT è un impianto modulare a plug-in, successore architetturale di ShadowPad, storicamente associato a gruppi come APT41, Bronze Atlas e altri cluster dell’ecosistema China-nexus. Supporta esecuzione di comandi, manipolazione del filesystem, tunneling di rete e caricamento dinamico di moduli aggiuntivi. TernDoor è invece un backdoor relativamente nuovo, scoperto per la prima volta nel contesto delle telecomunicazioni sudamericane: la sua comparsa in Azerbaigian suggerisce una condivisione di tooling tra operazioni geograficamente distinte.

Chi è FamousSparrow: storia di un gruppo nell’ombra

FamousSparrow è stato documentato per la prima volta da ESET nel 2021, quando veniva osservato sfruttare ProxyLogon contro hotel, studi legali e organizzazioni governative in cinque continenti. Da allora, il gruppo ha mantenuto un profilo basso, operando con tooling condiviso e sovrapposizioni tattiche con altri cluster China-nexus. La sua attribuzione rimane complessa proprio a causa di questa natura di “contractor” dell’ecosistema: usa strumenti come Deed RAT che circolano tra più gruppi, rendendo difficile tracciare confini netti tra operazioni distinte.

Bitdefender nota sovrapposizioni tattiche con Earth Estries (il gruppo noto per aver colpito le telecomunicazioni globali nel 2022-2024) e con Salt Typhoon, il cluster che nel 2024 aveva compromesso le infrastrutture di intercettazione legale di diversi carrier americani. Questa rete di attribuzioni incrociate riflette quella che gli analisti definiscono la “shared malware economy” del cyberspionaggio cinese: un ecosistema in cui strumenti, infrastrutture e accessi vengono riutilizzati tra operazioni con mandanti potenzialmente diversi.

Due righe per i difensori

Il caso azerbaigiano offre lezioni concrete per i team di sicurezza operanti in settori ad alto valore strategico. La prima, forse la più scomoda, è che un tentativo di remediation che non chiude completamente la vulnerabilità iniziale può essere peggio del non fare nulla: dà al team difensivo una falsa sensazione di sicurezza mentre l’avversario osserva e si riadatta. L’attaccante ha dimostrato di monitorare le azioni difensive e di rispondervi con una nuova backdoor.

Alcune raccomandazioni pratiche: verificare che ProxyNotShell (CVE-2022-41082 e CVE-2022-41040) sia effettivamente patchato attraverso validazione post-patch, non solo applicazione dell’aggiornamento; monitorare l’esecuzione di processi Exchange come w3wp.exe per attività di scrittura su filesystem inusuali; implementare detection per DLL sideloading tramite binari firmati di terze parti come strumenti di remote access legittimi; e adottare una strategia di threat hunting proattiva basata sui TTP di FamousSparrow anche dopo la chiusura di un incidente confermato.

Indicatori di Compromissione (IoC)

# Campagna FamousSparrow - Azerbaigian Oil & Gas (Dic 2025 - Feb 2026)
# Fonte: Bitdefender Labs / The Hacker News (13 maggio 2026)
## File IoC identificati
# Ondata 2 - TernDoor loader
MD5: 762f787534a891eca8aa9b41330b4108
Percorso: C:\ProgramData\USOShared\USOShared.exe
## Vettore di accesso iniziale
Vulnerabilità: ProxyNotShell
CVE: CVE-2022-41082 (RCE) / CVE-2022-41040 (SSRF)
Processo sfruttato: w3wp.exe (IIS Worker Process su Exchange)
## Tecniche MITRE ATT&CK
T1190 - Exploit Public-Facing Application (Exchange ProxyNotShell)
T1505.003 - Web Shell
T1574.002 - DLL Side-Loading (LogMeIn Hamachi binary)
T1027 - Obfuscated Files or Information
T1071 - Application Layer Protocol (C2)
## Malware families
Deed RAT (aka Snappybee) - modulare, successore di ShadowPad
TernDoor - backdoor, prima rilevato in telecomunicazioni SA 2024
## Nota ai defender
# Verificare presenza di web shell residue su:
# %ExchangeInstallPath%\FrontEnd\HttpProxy\
# %ExchangeInstallPath%\ClientAccess\

(in)sicurezza digitale

2026-05-13 23:20:00

GitLab Act 2: il manifesto dell’AI agentica che promette il futuro e inquieta gli sviluppatori

Quando una piattaforma DevSecOps da miliardi di dollari decide di riscrivere la propria identità attorno agli agenti AI, non sta semplicemente annunciando una nuova roadmap di prodotto. Sta dichiarando che il modello stesso di sviluppo software che abbiamo conosciuto negli ultimi vent’anni è destinato a diventare obsoleto.

È questo il messaggio reale dietro GitLab Act 2, il lungo manifesto pubblicato da GitLab per spiegare la trasformazione interna dell’azienda nell’era dell’AI agentica. Un documento che, più che un post corporate, assomiglia a una dottrina industriale: il software costerà sempre meno produrlo, gli sviluppatori diventeranno supervisori di sistemi autonomi e le organizzazioni dovranno ripensare completamente struttura, processi e ruoli.

Il problema è che, dietro la retorica della “nuova era”, molti sviluppatori vedono qualcosa di molto diverso: una drastica razionalizzazione aziendale mascherata da inevitabile rivoluzione tecnologica.

La tesi di GitLab: il software sarà scritto dalle macchine

Nel manifesto, GitLab sostiene che l’AI generativa stia comprimendo il costo marginale della produzione software in modo paragonabile a quanto avvenuto nell’industria manifatturiera con l’automazione. La conseguenza, secondo l’azienda, non sarà una riduzione della domanda di software ma l’opposto: un’esplosione.

Se creare applicazioni diventa più economico, ogni azienda produrrà più software, più automazione, più integrazioni e più servizi interni. In questo scenario, il valore umano non sarà più nella scrittura manuale del codice ma nella definizione degli obiettivi, nella governance, nella sicurezza e nella supervisione degli agenti AI.

È una narrativa ormai dominante nella Silicon Valley: gli sviluppatori non spariranno, ma evolveranno in orchestratori di sistemi autonomi.

GitLab vuole posizionarsi esattamente al centro di questa transizione con la propria piattaforma “Duo Agent Platform”, immaginata come un layer operativo in cui agenti AI collaborano lungo l’intero ciclo DevSecOps: pianificazione, sviluppo, code review, security scanning, remediation, test e deployment.

Non più copiloti. Non più semplici assistenti. Ma entità autonome capaci di eseguire task complessi all’interno delle pipeline.

La ristrutturazione interna è il vero cuore del manifesto

La parte più interessante del documento non è però tecnologica. È organizzativa.

GitLab annuncia infatti una profonda trasformazione della propria struttura interna. L’azienda parla apertamente di riduzione dei livelli manageriali, team più piccoli e autonomi, maggiore automazione operativa e integrazione massiccia dell’AI nei processi decisionali.

I gruppi R&D verranno suddivisi in circa 60 unità snelle, progettate per muoversi più rapidamente e lavorare in parallelo insieme agli agenti AI. Nel manifesto si percepisce chiaramente un’influenza delle metodologie “founder mode” e delle moderne filosofie ultra-efficientiste adottate da molte aziende AI-first.

Tradotto dal linguaggio corporate: meno coordinamento umano, meno middle management e più automazione decisionale.

Ed è qui che la community ha iniziato a reagire in modo estremamente critico.

La critica principale: “state inseguendo l’hype”

Molti sviluppatori hanno interpretato Act 2 come il segnale definitivo che GitLab stia inseguendo il trend AI sacrificando progressivamente gli elementi che l’avevano resa popolare nella community engineering.

Nel forum ufficiale e su diverse discussioni tecniche, il malcontento è emerso rapidamente. Alcuni utenti accusano GitLab di aver trasformato la piattaforma in un contenitore di feature AI ancora immature mentre problemi storici di UX, performance e stabilità rimangono irrisolti.

Il timore più diffuso è che l’azienda stia vendendo una visione futuristica molto più avanzata della realtà tecnica attuale.

Ed effettivamente esiste un forte scollamento tra la narrativa dell’AI agentica e lo stato reale degli LLM moderni.

Per quanto impressionanti, gli agenti AI soffrono ancora problemi enormi in contesti enterprise:

• perdita di contesto su codebase estese;
• hallucinations in scenari complessi;
• incapacità di ragionamento affidabile multi-step;
• difficoltà nel comprendere architetture legacy;
• fragilità nelle decisioni di sicurezza;
• dipendenza da prompt engineering estremamente fragile.

Nel mondo DevSecOps questi limiti non sono marginali. Sono potenzialmente catastrofici.

Automatizzare una pipeline CI/CD è relativamente semplice. Delegare ad agenti AI remediation di vulnerabilità, code review o decisioni infrastrutturali in ambienti enterprise è un’altra storia.

Soprattutto quando si parla di sicurezza.

Il nodo cybersecurity: chi valida l’agente?

Dal punto di vista della cybersecurity, il manifesto di GitLab apre questioni enormi che nel documento vengono affrontate solo superficialmente.

Se gli agenti AI diventano parte attiva della supply chain software, diventano automaticamente anche una nuova superficie d’attacco.

Un agente che modifica codice, approva merge request o interagisce con pipeline CI/CD introduce rischi completamente nuovi:

• prompt injection nei workflow DevOps;
• poisoning dei contesti RAG;
• manipolazione degli agenti tramite issue o commenti malevoli;
• escalation di privilegi attraverso tool integration;
• generazione di codice vulnerabile apparentemente corretto;
• supply chain compromise mediata da AI.

La community security sta già osservando casi concreti di agenti AI manipolabili tramite input indiretti, specialmente quando connessi a repository, ticketing system o documentazione interna.

In pratica, il problema non è più soltanto “il codice è vulnerabile?”, ma anche:

“l’agente che ha preso la decisione era affidabile?”

È una differenza enorme.

GitLab sembra convinta che governance e supervisione umana saranno sufficienti a mitigare questi rischi. Ma molti esperti ritengono che l’industria stia sottovalutando drasticamente la complessità della sicurezza negli ecosistemi agentici.

Il sottotesto economico: fare di più con meno persone

C’è poi un altro elemento che ha generato parecchio nervosismo: il sospetto che “Act 2” sia soprattutto un piano di efficientamento.

Nel manifesto, GitLab evita accuratamente toni allarmistici sui posti di lavoro, ma il messaggio implicito è difficile da ignorare. Se gli agenti AI aumentano drasticamente la produttività, le aziende avranno bisogno di meno persone per svolgere gli stessi task.

Molti hanno letto il documento come la formalizzazione di una tendenza già evidente nel settore tech: usare l’AI come leva per comprimere organici, ridurre management intermedio e aumentare output per dipendente.

Ed è qui che la narrativa “visionaria” inizia a somigliare a qualcosa di molto più concreto: una ridefinizione radicale del rapporto tra capitale umano e automazione nel software engineering.

Un manifesto che racconta il futuro del settore

Al di là dell’hype e delle critiche, GitLab Act 2 resta un documento importante perché fotografa perfettamente il momento storico dell’industria software.

Per la prima volta una grande piattaforma DevSecOps non presenta l’AI come una feature aggiuntiva, ma come il fondamento operativo attorno a cui ridisegnare un’intera azienda.

La vera domanda non è se GitLab riuscirà o meno nella trasformazione.

La domanda è quante altre aziende seguiranno lo stesso modello nei prossimi 24 mesi.

Perché se Act 2 dovesse diventare il template organizzativo dell’era agentica, il cambiamento non riguarderà soltanto il modo in cui scriviamo codice.

Riguarderà il modo in cui verranno costruite le aziende tecnologiche stesse.

GitLab Act 2

A letter to our customers and our investors.

^{Bill Staples (about.gitlab.com)}

(in)sicurezza digitale

2026-05-13 16:06:32

Nitrogen ransomware colpisce Foxconn: 8TB di dati con segreti industriali di Apple, Nvidia e Intel

Il 12 maggio 2026 Foxconn ha confermato un cyberattacco ai danni delle sue fabbriche nordamericane, rivendicato dal gruppo ransomware Nitrogen. Gli aggressori affermano di aver sottratto 8 TB di dati — oltre 11 milioni di file — contenenti documentazione riservata, schemi tecnici e istruzioni di assemblaggio relative a progetti di Apple, Intel, Google, Nvidia e Dell. L’attacco ha bloccato la produzione per giorni in uno dei nodi più critici della supply chain tecnologica globale.

La timeline dell’attacco

Secondo le ricostruzioni, il 1° maggio 2026 i lavoratori del turno di notte dello stabilimento Foxconn di Mount Pleasant, Wisconsin, hanno interrotto la produzione a causa di un’interruzione di rete. Al mattino, i lavoratori del primo turno sono arrivati senza Wi-Fi e sono stati rimandati a casa entro le 11. La produzione è rimasta ferma fino al 4 maggio. Undici giorni dopo, il 11 maggio, il gruppo Nitrogen ha aggiunto Foxconn al proprio data leak site sul dark web, rivendicando il furto di 8 TB di dati e pubblicando campioni come prova.

Foxconn ha confermato l’incidente con una dichiarazione sobria: “Alcune fabbriche di Foxconn in Nord America hanno subito un cyberattacco. Il team di cybersecurity ha immediatamente attivato il meccanismo di risposta e implementato misure operative multiple per garantire la continuità di produzione e consegna. Le fabbriche interessate stanno riprendendo la normale produzione.” L’azienda si è rifiutata di confermare quali dati clienti fossero stati effettivamente esfiltrati.

Chi è Nitrogen: genealogia di un gruppo ransomware

Nitrogen è attivo dal 2023 ed è considerato uno dei numerosi discendenti del codice trapelato del builder Conti 2. Il gruppo è operativamente collegato a threat actor dell’Europa dell’Est e alcuni suoi operatori sarebbero associati al cartello BlackHat/ALPHV. Una caratteristica critica emersa a febbraio 2026 rende il gruppo particolarmente pericoloso per le sue stesse vittime: un bug di programmazione nel modulo di cifratura per VMware ESXi rende il decryptor incapace di recuperare i file cifrati. Secondo i ricercatori di Coveware, pagare il riscatto — in questo specifico scenario — è inutile, poiché nemmeno gli stessi operatori di Nitrogen riescono a decifrare i file. Foxconn avrà quasi certamente verificato questa criticità prima di prendere qualsiasi decisione sui negoziati.

Il bottino: schemi tecnici di Apple, Nvidia, Intel, Google e Dell

I campioni pubblicati da Nitrogen sul data leak site comprendono, secondo le ricostruzioni di più fonti, istruzioni di assemblaggio, diagrammi di data center e schemi hardware relativi a progetti di Apple, Intel, Google, Nvidia e Dell. La natura della documentazione è coerente con l’operatività dello stabilimento di Mount Pleasant, che Foxconn gestisce come Fii USA (Foxconn Industrial Internet) e che produce principalmente server, workstation e componenti per data center — non dispositivi consumer Apple, il che spiega perché Apple abbia dichiarato di non essere direttamente a rischio per quanto riguarda i propri prodotti al consumo.

La vera preoccupazione non è nella divulgazione di schemi per smartphone già in commercio, ma nella potenziale esposizione di roadmap future, specifiche ingegneristiche riservate di infrastrutture cloud e configurazioni di data center enterprise. Per aziende come Nvidia, i cui chip AI sono al centro di una corsa tecnologica globale con implicazioni geopolitiche, la divulgazione di topologie di sistemi e specifiche tecniche costituisce un rischio di intelligence industriale non trascurabile.

Foxconn nel mirino: una vittima seriale

Non si tratta del primo incidente ransomware per il colosso taiwanese. Nel 2022 un gruppo criminale aveva colpito una filiale messicana di Foxconn. Nel 2024 LockBit aveva attaccato Foxsemicon Integrated Technology, società del gruppo nel settore equipment per semiconduttori. La recidività di questi attacchi suggerisce che la superficie di attacco di Foxconn — distribuita tra decine di stabilimenti, migliaia di sistemi IT e una rete supply chain planetaria — sia strutturalmente difficile da proteggere nella sua totalità.

Implicazioni per la supply chain tecnologica

L’attacco a Foxconn rappresenta un caso emblematico di come le grandi aziende di contract manufacturing costituiscano un vettore di rischio sistemico per l’intera industria tecnologica. Un singolo incidente a un fornitore terzo può esporre simultaneamente la proprietà intellettuale di decine di brand globali — anche quando questi brand mantengono standard di sicurezza interni elevatissimi. La documentazione tecnica che fluisce verso i produttori include spesso specifiche pre-commerciali, che diventano bersagli appetibili per attori mossi da interessi sia economici (concorrenza sleale, contraffazione) che geopolitici (intelligence industriale statale).

Vale la pena notare che Nitrogen stessa ha un track record di affidabilità tecnica discutibile: la presenza del bug nel decryptor ESXi lascia aperta la domanda su quanto effettivamente il gruppo sia in grado di “consegnare” quanto promesso in sede di negoziazione. Per Foxconn, questo potrebbe significare che, nel caso in cui parte dei sistemi produttivi fosse stata cifrata con la variante ESXi, i dati potrebbero essere irrecuperabili indipendentemente da qualsiasi trattativa.

Due righe per i difensori: lezioni dall’incidente Foxconn

• Segmentazione di rete per gli ambienti OT/IT: negli stabilimenti manifatturieri, la convergenza tra reti IT e sistemi operativi (OT/ICS) amplifica l’impatto di un’intrusione. Una corretta segmentazione può contenere il blast radius e prevenire interruzioni produttive.
• Hardening degli hypervisor VMware ESXi: Nitrogen e molti altri gruppi ransomware prendono specificamente di mira ESXi. L’applicazione tempestiva delle patch, la disabilitazione di servizi non necessari (SLP, OpenSLP) e il monitoraggio delle API di hypervisor sono controlli prioritari.
• Protezione della documentazione tecnica con DRM o controlli di accesso granulari: schemi, BOM e specifiche ingegneristiche riservate dovrebbero essere soggetti a policy di accesso basate sul principio del minimo privilegio e tracciabilità degli accessi.
• Verifica dei fornitori critici: le aziende che condividono IP con contract manufacturer dovrebbero condurre audit periodici della postura di sicurezza dei propri fornitori e includere clausole di notifica di incidenti nei contratti.
• Valutare la recuperabilità prima del pagamento: in caso di attacco Nitrogen su ambienti ESXi, ricercatori indipendenti hanno confermato che il pagamento non garantisce il recupero. Prioritizzare i backup offline e testare regolarmente i piani di disaster recovery.

Fonti: The Register (12 maggio 2026); CyberNews; The CyberSec Guru

Foxconn Breach: Nitrogen Claims 8TB Theft from Wisconsin AI Plant | The CyberSec Guru

8TB breach hits Foxconn Wisconsin! Nitrogen ransomware group claims 11 million files stolen, including Apple & Google specs

^{The CyberSec Guru}

404 Media

2026-05-13 13:00:48

Software Developers Say AI Is Rotting Their Brains

Tech company executives are confident that AI will completely transform the economy and point to the changes they see in-house to prove that this change is coming fast. At Meta, Google, Microsoft, and others, leadership says that AI generates a growing share of the overall code, which makes it cheaper and faster to produce. The implication is that if this AI is good enough that tech companies are using it internally to improve efficiency and reduce headcount, it’s only a matter of time until every other industry is similarly transformed.

Developers who are told to use AI whether they like it or not, however, tell a different story. On Reddit, Hacker News and other places where people in software development talk to each other, more and more people are becoming disillusioned with the promise of code generated by large language models. Developers talk not just about how the AI output is often flawed, but that using AI to get the job done is often a more time consuming, harder, and more frustrating experience because they have to go through the output and fix its mistakes. More concerning, developers who use AI at work report that they feel like they are de-skilling themselves and losing their ability to do their jobs as well as they used to.

“We're being told to use [AI] agents for broad changes across our codebase. There's no way to evaluate whether that much code is well-written or secure—especially when hundreds of other programmers in the company are doing the same,” a UX designer at a midsized tech company told me. 404 Media granted all the developers we talked to for this story anonymity because they signed non-disclosure agreements or because they fear retribution from their employers. “We're building a rat's nest of tech debt that will be impossible to untangle when these models become prohibitively expensive (any minute now...).”

The actual quality of output doesn't matter as much as our willingness to participate.

Tech company executives love to brag about how much of the code at their company is AI-generated. In April, Google said that three quarters of new code at the company was generated by AI. Last year, Microsoft CEO Satya Nadella said up to 30 percent of the company’s code was generated by AI. Microsoft’s CTO Kevin Scott said he expects 95 percent of all code at the company to be AI-generated by 2030. Meta’s Mark Zuckerberg said last year he expects AI to write most of the code improving AI within 12-18 months. Anthropic says 90 percent of the code written by most if its team is AI generated. Tech companies have also been bragging about their “tokenmaxxing,” or how much money they’re spending on AI tools instead of human employees.

💡
Are you a developer at Google, Microsoft, or another tech being pressured to use AI? I would love to hear from you. Using a non-work device, you can message me securely on Signal at ‪(609) 678-3204‬. Otherwise, send me an email at emanuel@404media.co.

Predictably, the huge spike in productivity that these companies claim their own AI products have enabled hasn’t resulted in more or better products, shorter work weeks, or better consumer experiences. Mostly, AI implementation in tech companies has been used to justify multiple massive rounds of layoffs. To name just a few examples where tech companies said they reduced headcount because of AI use, more recently, Meta said it would cut 10 percent of its workforce (around 8,000 people), Microsoft said it would offer voluntary retirement to 7 percent of its American workforce (around 125,000 people). Snapchat said it would lay off 16 percent of its full-time staffers (about 1,000 people).

This post is for subscribers only

Become a member to get access to all content
Subscribe now

Software Developers Say AI Is Rotting Their Brains

“It's making me dumber for sure.”

^{Emanuel Maiberg (404 Media)}

(in)sicurezza digitale

2026-05-13 12:56:19

Mythos contro curl: quando l’AI “troppo pericolosa” incontra la realtà del codice

Si parla di:
Toggle

Per settimane il nome “Mythos” è stato costruito come un oggetto quasi mitologico. Anthropic lo ha presentato come un modello AI capace di trovare vulnerabilità zero-day a un livello tale da risultare “troppo pericoloso” per una release pubblica. Una narrativa perfetta per il ciclo mediatico dell’AI security nel 2026: modello segreto, capacità offensive avanzate, accesso ristretto, migliaia di vulnerabilità individuate. Il genere di storytelling che nel mondo cyber si propaga in poche ore tra LinkedIn, Twitter/X, keynote e blog enterprise.

Poi però Mythos è stato testato contro uno dei progetti open source più scrutinati del pianeta: curl. E lì il racconto ha iniziato a incrinarsi.

Un software scritto come si deve

A raccontarlo è stato direttamente Daniel Stenberg, storico maintainer di curl e figura ormai centrale nel dibattito sulla collisione tra AI e vulnerability research. Nel suo lungo post pubblicato sul blog personale, Stenberg descrive il risultato dell’analisi effettuata con Mythos sul repository di curl: cinque vulnerabilità segnalate come “confirmed security vulnerabilities”. Dopo il triage umano del team sicurezza di curl, il bilancio finale si è ridotto a una sola vulnerabilità reale, classificata a bassa severità, tre falsi positivi e un semplice bug non-security. (daniel.haxx.se)

Ed è qui che il tema diventa interessante, perché il punto non è tanto “Mythos non funziona”. Anzi. Stenberg stesso riconosce che il report contiene analisi tecniche solide e bug descritti bene, con un numero relativamente basso di falsi positivi rispetto alla media degli scanner AI attuali. Il problema è un altro: il gap enorme tra la narrativa costruita attorno al modello e i risultati concreti osservabili sul campo.

La frase più pesante dell’intero post è probabilmente questa:

“the big hype around this model so far was primarily marketing”

Un software largamente usato

Una dichiarazione che arriva non da un opinionista qualsiasi, ma da uno dei maintainer open source più esposti al fenomeno AI-assisted vulnerability hunting. Negli ultimi mesi Stenberg ha documentato pubblicamente l’esplosione di report generati da AI, il collasso qualitativo di molti bug bounty submission e il nuovo scenario che lui stesso definisce “high-quality chaos”.

Il contesto infatti è fondamentale. curl non è un target qualunque. È software vecchio di decenni, onnipresente, analizzato continuamente da ricercatori, aziende, fuzzing infrastructure, static analyzer, LLM e offensive security team. Il progetto ha già attraversato una vera ondata di AI-powered auditing nel 2025 e 2026, con centinaia di issue segnalate e decine di CVE pubblicate.

In altre parole: Mythos non stava entrando in un territorio inesplorato. Stava arrivando su un codice già passato attraverso un livello di scrutiny estremo.

Ed è qui che la promessa implicita di Anthropic sembra perdere consistenza. Se un modello viene presentato quasi come una svolta paradigmatica nella vulnerability discovery offensiva, ci si aspetta almeno un salto qualitativo evidente rispetto agli strumenti precedenti. Non necessariamente centinaia di 0-day critici, ma almeno pattern nuovi, classi di bug differenti, chaining più sofisticati o insight architetturali difficili da intercettare con gli attuali sistemi AI-assisted SAST.

Secondo Stenberg, questo salto non si è visto.

Anzi, il maintainer di curl arriva a sostenere che altri strumenti AI usati in precedenza avevano già prodotto quantità maggiori di bugfix. Mythos forse è “leggermente migliore”, scrive, ma non abbastanza da cambiare realmente il paradigma della code analysis.

Questa distinzione è cruciale perché separa due fenomeni che oggi vengono continuamente confusi nel marketing AI security.

Il primo fenomeno è reale: i moderni LLM stanno diventando estremamente efficaci nell’analisi del codice. Stenberg lo dice chiaramente. Gli strumenti AI contemporanei trovano vulnerabilità meglio dei tradizionali static analyzer. La differenza rispetto a cinque anni fa è concreta e misurabile.

Il secondo fenomeno invece è narrativo: trasformare questo miglioramento incrementale in una retorica quasi apocalittica, dove ogni nuovo modello viene descritto come un cyber-weapon rivoluzionario capace di destabilizzare l’intero ecosistema software.

Ed è proprio questa seconda parte che il caso Mythos sembra mettere in discussione.

L’hype dell’AI ormai incontrollabile

Perché il rischio, nel settore cybersecurity, è che l’hype finisca per sostituire il metodo. La comunicazione attorno a Mythos ha funzionato perfettamente: accesso ristretto, dichiarazioni sulla pericolosità del modello, riferimenti a migliaia di zero-day trovati internamente, programma limitato a poche organizzazioni strategiche. Tutti elementi che costruiscono scarsità, percezione di superiorità tecnologica e senso di urgenza.

Ma quando il modello viene finalmente osservato in un caso reale e pubblico, il risultato appare molto più ordinario: un buon AI-assisted code analyzer che trova un low severity issue in un progetto maturissimo e già massacrato da anni di auditing.

Non è poco. Ma non è nemmeno la rivoluzione promessa.

La parte forse più interessante dell’intera vicenda è che Stenberg non assume una posizione anti-AI. Al contrario. La sua analisi è molto più sofisticata della solita polarizzazione “AI sì / AI no”. Lui riconosce apertamente che gli LLM stanno cambiando il vulnerability research landscape. Il problema, semmai, è che il settore sta sovrastimando la distanza tra i nuovi modelli “frontier” e ciò che gli strumenti AI moderni già fanno oggi.

Ed è una riflessione che nel mondo offensive security merita attenzione.

Perché se Mythos — il modello presentato come troppo pericoloso per essere rilasciato — produce risultati sostanzialmente comparabili agli strumenti già esistenti, allora forse la vera trasformazione non è l’arrivo di un singolo modello “superiore”, ma la democratizzazione progressiva dell’AI-assisted vulnerability discovery.

Una differenza enorme.

Nel primo scenario, il vantaggio resta concentrato nelle mani di pochi laboratori frontier AI. Nel secondo, invece, la capacità offensiva si distribuisce rapidamente: più ricercatori, più scanner, più auditing, più rumore, più CVE, più triage umano necessario.

Ed è esattamente il futuro che Stenberg sembra vedere arrivare: non una singola AI onnipotente, ma un ecosistema saturo di agenti capaci di produrre contemporaneamente valore tecnico reale e quantità industriali di “security slop”.

Un mondo dove il problema non è più trovare vulnerabilità. È distinguere quelle importanti dal resto.

Day: May 11, 2026

curl, open source and networking

^{daniel.haxx.se}

Spcnet.it

2026-05-12 17:15:00

Azure Resource Manager MCP Server: gestire l’infrastruttura Azure con gli agenti AI

Azure Resource Manager: il piano di controllo di Azure

Azure Resource Manager (ARM) è il piano di controllo dell’intera piattaforma Azure. Ogni operazione che crea, aggiorna o elimina risorse Azure passa attraverso ARM, indipendentemente da dove provenga: portale Azure, CLI, PowerShell, REST API o SDK. È l’unico punto di ingresso autorevole per gestire l’infrastruttura cloud Microsoft.

Con l’esplosione degli agenti AI, si pone una domanda concreta: come possono questi agenti interagire con ARM in modo strutturato, sicuro e coerente? Microsoft ha risposto con l’Azure Resource Manager MCP Server, ora in anteprima pubblica: un server MCP remoto che fornisce agli agenti AI un accesso di prima classe alle operazioni di infrastruttura Azure attraverso il Model Context Protocol.

Cos’è l’Azure Resource Manager MCP Server

Il server MCP per ARM è progettato per essere il layer di accesso degli agenti AI all’infrastruttura Azure, esattamente come lo è per qualsiasi altro client ARM. Nella versione attuale espone due macro-funzionalità principali:

• Azure Resource Graph (ARG) query: generazione, validazione ed esecuzione di query ARG in linguaggio naturale contro tutti i tipi di risorse Azure
• ARM Template Deployment: avvio, monitoraggio e cancellazione di deployment ARM su scope di resource group esistenti

In pratica, l’agente AI non esegue direttamente SQL o chiamate REST: descrive ciò che vuole sapere o fare, e il server MCP traduce quella richiesta in operazioni ARM concrete e sicure.

I tool disponibili

Il server espone sei tool principali, ciascuno con un ruolo preciso:

• generate_query: genera una query ARG a partire da un prompt in linguaggio naturale. Esempio: “Mostrami tutte le VM in esecuzione nel subscription X” → query KQL valida
• validate_query: verifica che una query ARG sia corretta sintatticamente e sicura prima di eseguirla
• execute_query: esegue la query ARG contro l’ambiente Azure dell’utente e restituisce i risultati
• create_template_deployment: avvia il deployment di un ARM template verso un resource group target
• get_arm_template_deployment_status: monitora lo stato di avanzamento di un deployment ARM
• cancel_arm_template_deployment: annulla un deployment in corso (utile dopo fallimenti di validazione o policy)

Caso d’uso pratico: interrogare l’infrastruttura in linguaggio naturale

Immagina di voler sapere quante storage account nel tuo tenant non hanno il tag “owner” assegnato. Tradizionalmente dovresti conoscere il linguaggio KQL di Azure Resource Graph e costruire manualmente la query:

Resources
| where type == "microsoft.storage/storageaccounts"
| where isnull(tags["owner"]) or tags["owner"] == ""
| summarize count() by subscriptionId

Con l’ARM MCP Server attivo in GitHub Copilot Chat su VS Code, puoi semplicemente scrivere:

“Conta tutte le storage account senza il tag ‘owner’, raggruppate per subscription”

Il server generate_query crea la query KQL, validate_query la verifica, e execute_query la esegue restituendo i risultati all’agente che li presenta in formato leggibile.

Caso d’uso: deployment di infrastruttura guidato dall’AI

Il secondo use case riguarda il deployment di ARM template. Un agente può ricevere istruzioni come:

“Deploy un’app service con piano B1 nel resource group ‘prod-rg’ in West Europe, usa il template standard dalla nostra libreria”

Il tool create_template_deployment avvia il deployment specificando subscription ID, resource group, nome del deployment e la definizione del template ARM. Il tool get_arm_template_deployment_status permette all’agente di monitorarne l’avanzamento. Se qualcosa va storto, cancel_arm_template_deployment lo interrompe immediatamente.

Governance e sicurezza

Un aspetto critico: il server ARM MCP opera nel contesto dell’utente autenticato in VS Code. Tutte le chiamate vengono eseguite per conto di quell’utente e sono soggette agli stessi permessi e controlli di accesso definiti in Azure. Non ci sono privilegi elevati o bypass del modello di sicurezza Azure: se l’utente non ha i diritti per deployare in un certo resource group, l’agente non li avrà neanche.

Per organizzazioni che vogliono impedire completamente i deployment tramite ARM MCP Server, è possibile applicare una Azure Policy che blocchi esplicitamente le richieste al tool create_template_deployment identificando l’AppID del server MCP (22bfbae3-f4e7-485f-be43-8cee15065084) nel scope desiderato. Un template di policy di esempio è disponibile nel repository GitHub ufficiale.

Installazione e configurazione

Durante questa preview pubblica, il server ARM MCP è supportato su:

• GitHub Copilot Chat in VS Code
• GitHub Copilot CLI

Per installarlo:

1. Apri aka.ms/JoinARMMCP — VS Code si avvierà automaticamente
2. Quando richiesto in VS Code, clicca su Install sotto “Azure Resource Manager MCP server”
3. Effettua il login con le credenziali Azure
4. In VS Code, apri View > Chat e clicca sull’icona Configure Tools
5. Assicurati che “Azure Resource Manager MCP server” sia spuntato

I prerequisiti sono VS Code installato, un account Azure valido e un account GitHub Copilot.

Considerazioni per gli amministratori Azure

L’ARM MCP Server apre nuovi scenari per i team DevOps e gli amministratori Azure. Alcuni esempi concreti:

• Compliance automatizzata: agenti che controllano periodicamente le risorse e verificano l’applicazione di policy di tagging, naming convention o configurazioni di sicurezza
• Troubleshooting accelerato: interrogare in linguaggio naturale lo stato dell’infrastruttura durante un incident, senza dover ricordare sintassi KQL
• Infrastructure as Code assistita: generare e deployare ARM template partendo da descrizioni in linguaggio naturale, con validazione integrata prima dell’esecuzione

Il limite attuale — solo VS Code e GitHub Copilot CLI come client supportati — sarà probabilmente espanso nelle prossime versioni in base al feedback degli utenti. Microsoft ha aperto un canale dedicato su GitHub per raccogliere segnalazioni e richieste di funzionalità.

Conclusione

L’Azure Resource Manager MCP Server rappresenta un passo significativo nell’integrazione tra agenti AI e infrastruttura cloud. Non si tratta di uno strumento che bypassa la governance Azure, bensì di un layer che la rende accessibile agli agenti rispettandola appieno. Per team che già usano Azure e GitHub Copilot, il valore pratico è immediato: meno sintassi KQL da memorizzare, deployment più veloci da validare, e la possibilità di costruire agenti personalizzati per automazioni di compliance che oggi richiedono script dedicati.

Il server è ora in anteprima pubblica e può essere installato seguendo le istruzioni ufficiali su aka.ms/JoinARMMCP.

Fonti:
Introducing the Azure Resource Manager MCP Server! — Microsoft Tech Community (Steven Bucher, 8 maggio 2026)
Azure/Azure-Resource-Manager-MCP — GitHub

Introducing the Azure Resource Manager MCP Server! | Microsoft Community Hub

We're super excited to announce the public preview of the Azure Resource Manager MCP Server! This is a remote MCP server that provides tools to give AI...

^{stevenbucher (TECHCOMMUNITY.MICROSOFT.COM)}

Spcnet.it

2026-05-12 15:14:00

.NET Aspire 13.3: tutte le novità della release

.NET Aspire 13.3 è disponibile, e nonostante siano passate soltanto cinque settimane dalla versione 13.2, questa release porta con sé novità di rilievo: un nuovo skill per l’onboarding assistito da agente, risultati strutturati dai comandi delle risorse, log del browser direttamente nell’orchestratore, e — finalmente — supporto di prima classe a Kubernetes e AKS tramite Helm.

In questo articolo analizziamo le funzionalità più importanti di Aspire 13.3, con esempi pratici per i team che già usano Aspire in produzione o che vogliono iniziare.

Aspireify: onboarding assistito da agente

Una delle novità più interessanti di Aspire 13.3 è il nuovo skill Aspireify, pensato per semplificare l’integrazione di applicazioni esistenti in Aspire. Chi ha già seguito le sessioni AspiriFridays sa bene quanto possa essere laborioso il processo di “aspirificazione”: capire quali servizi sono presenti, quali porte usano, quali variabili d’ambiente sono dipendenze reali e come mappare i servizi Docker Compose verso le integrazioni Aspire native.

Il nuovo skill risolve esattamente questo problema. Quando aspire init crea lo scheletro dell’AppHost in un’applicazione esistente, Aspireify guida l’agente di coding attraverso un workflow strutturato per completare il lavoro:

• Ispeziona il repository e comprende come l’applicazione è già strutturata
• Mappa le configurazioni esistenti (es. DATABASE_URL) usando WithEnvironment() invece di riscrivere la configurazione
• Preserva le porte hardcoded quando necessario, chiedendo all’utente nei casi ambigui
• Se esiste già un Docker Compose, lo analizza prima di aggiungere nuove risorse

Il principio guida è chiaro: minimizzare le modifiche al codice esistente. L’agente si adatta all’applicazione, non viceversa.

Risultati strutturati dai comandi delle risorse

In Aspire 13.3, i comandi delle risorse possono restituire risultati strutturati al chiamante. Testo e JSON ora fluiscono attraverso il modello, gRPC, backchannel, UI del dashboard, CLI e strumenti MCP.

Questo significa che i comandi possono restituire risposte in markdown formattato — non solo “sì, è andato a buon fine”. Il dashboard integra tutto questo con un nuovo notification center nell’header, dove i risultati dell’esecuzione appaiono come notifiche con timestamp, rendering markdown e un’azione “View response” per l’output completo.

Tra le novità specifiche:

• I comandi HTTP possono restituire il corpo della risposta, esposto via CLI, dashboard e SDK poliglotti generati
• Il comando di rebuild delle risorse restituisce l’output del build come dati di testo strutturati, leggibili da strumenti e agenti senza dover fare scraping dei log
• Le integrazioni di terze parti possono aggiungere comandi che restituiscono risultati significativi invece di cambiare solo stato in background

Browser logs: Aspire vede anche il frontend

La nuova API WithBrowserLogs() collega una risorsa browser tracciata a qualsiasi risorsa con un endpoint. Aspire avvia Chromium usando una pipe CDP privata (invece di un endpoint TCP debug esposto), poi trasmette log della console, richieste di rete ed errori nel log stream della risorsa:

// C# AppHost
var frontend = builder.AddViteApp("frontend", "../frontend")
    .WithHttpEndpoint(port: 3000)
    .WithBrowserLogs();

// TypeScript AppHost
const frontend = await builder.addViteApp("frontend", "../frontend")
    .withHttpEndpoint({ port: 3000 })
    .withBrowserLogs();

La funzionalità è disponibile tramite il nuovo pacchetto prerelease Aspire.Hosting.Browsers. Un comando del dashboard permette di configurare scope, browser e modalità user data a runtime, mentre un comando screenshot salva PNG come artefatti locali durevoli.

Dal punto di vista degli agent workflow, questo è particolarmente potente: l’agente può eseguire l’app, ispezionare i log del browser, catturare cosa è cambiato, correggere il codice, riavviare la risorsa e continuare — senza che lo sviluppatore debba incollare screenshot nella chat.

TypeScript, Python e Java AppHost verso la GA

Aspire 13.2 aveva introdotto l’authoring TypeScript AppHost. In 13.3, il lavoro continua su tutte e tre le piattaforme:

• TypeScript, Python e Java AppHost espongono ora il set completo di extension method di Aspire.Hosting
• Le API sono state rese più idiomatiche per ogni linguaggio: metodi come addProject, withEnvironment e withReference sono consolidati per leggere naturalmente
• Python si aggiunge come nuovo generatore di codice AppHost
• Java AppHost ora supporta union, optional/nullability, callback e un nuovo template “Empty (Java AppHost)”
• Il nuovo diagnostico ASPIREEXPORT013 individua ID di capability duplicati a compile time

Kubernetes e AKS: finalmente supporto di prima classe

La novità più attesa della release è senza dubbio il supporto Kubernetes come deployment target di prima classe. Aspire aveva già un’ottima storia per Azure Container Apps e Docker Compose; ora Kubernetes entra nel club.

Il nuovo pacchetto Aspire.Hosting.Azure.Kubernetes aggiunge AddAzureKubernetesEnvironment(), con cui è possibile definire cluster AKS, node pool, tier SKU, cluster privati e Azure Container Insights direttamente dall’AppHost:

// C# AppHost
var aks = builder.AddAzureKubernetesEnvironment("prod-aks")
    .WithHelm();

builder.AddCSharpApp("api", "../api")
    .PublishTo(aks);

// TypeScript AppHost
const aks = await builder.addAzureKubernetesEnvironment("prod-aks")
    .withHelm();

await builder.addCsharpApp("api", "../api")
    .publishTo(aks);

aspire deploy usa Helm sotto il cofano, e il nome del namespace e della release sono configurabili con WithHelm(). Sono disponibili anche routing dichiarativo Ingress e Gateway API con AddIngress() e AddGateway(), inclusa configurazione di route, TLS, hostname e class. Per il teardown, aspire destroy esegue helm uninstall automaticamente — niente più script di pulizia manuali in un README.

Altre novità rilevanti

Aspire 13.3 include molte altre migliorie degne di nota:

• EF Core migration management: sei comandi (Update Database, Drop Database, Reset Database, Add Migration, Remove Migration, Get Database Status) accessibili da dashboard e CLI, con esecuzione automatica all’avvio dell’AppHost in sviluppo locale
• Azure networking: Azure Front Door, Network Security Perimeters, endpoint privati per Azure OpenAI e Foundry, ACR privato, e upgrade HTTPS automatici per App Service
• JavaScript publishing: tre nuovi modelli di pubblicazione — PublishAsStaticWebsite(), PublishAsNodeServer() e PublishAsNpmScript() — con integrazione dedicata AddNextJsApp()
• CLI: rilevamento automatico di Bun, Yarn e pnpm da lockfile; aspire dashboard standalone senza AppHost; aspire docs api per sfogliare la reference API dal terminale
• Estensione VS Code: CodeLens e gutter icon nei file AppHost, Simple Browser integrato per il dashboard, workspace auto-restore
• Docker Compose: supporto Podman tramite rilevamento automatico del runtime

Breaking changes da conoscere prima dell’aggiornamento

Prima di aggiornare, è importante verificare la sezione dei breaking changes ufficiale se si usano:

• Startup hook Kubernetes/Docker Compose/AKS
• Endpoint di gestione degli emulator
• Il server MCP del dashboard
• Il template starter Python
• Output name di Azure network

Come aggiornare

Se si usa già Aspire, l’aggiornamento è semplice:

aspire update --self

Per chi parte da zero:

aspire init

oppure visitare get.aspire.dev per installare la CLI.

Conclusione

Aspire 13.3 consolida la piattaforma su tutti i fronti: l’onboarding diventa più semplice grazie ad Aspireify, l’osservabilità raggiunge il browser con WithBrowserLogs(), il supporto multi-linguaggio avanza verso la GA, e Kubernetes entra ufficialmente come target di deployment. Per i team .NET che operano su Kubernetes o AKS, questa è probabilmente la release più attesa degli ultimi mesi.

Fonte: What’s New in Aspire 13.3 — Maddy Montaquila, Microsoft Aspire Blog (7 maggio 2026)

What's New in Aspire 13.3

Aspire 13.3 is here with the Aspireify skill, command results, browser logs, Kubernetes and AKS deployment, and more.

^{Maddy Montaquila (Aspire Blog)}

Spcnet.it

2026-05-12 14:33:48

MCP Server con Node.js: da un sistema di note su file a MySQL

Cos’è il Model Context Protocol e perché interessa ai developer Node.js

I modelli di linguaggio sono bravi a ragionare e conversare, ma da soli non possono eseguire operazioni reali sui tuoi sistemi. Possono suggerire query SQL o chiamate API, ma non possono farle girare concretamente. Il Model Context Protocol (MCP) risolve questo limite: fornisce ai modelli AI un modo strutturato per interagire con i tuoi strumenti, dai database ai file, fino alle API esterne. Invece di generare testo su ciò che dovrebbe accadere, il modello può invocare funzioni che lo fanno davvero accadere.

In pratica, questo apre la strada a strumenti come chatbot che creano e cercano voci nel database, assistenti AI che interrogano tool interni o attivano workflow, e agenti che leggono file, eseguono comandi e restituiscono risultati reali.

In questo tutorial imparerai a costruire il tuo primo MCP server da zero con Node.js e TypeScript: partiremo da un sistema di note basato su file per capire i concetti fondamentali, poi passeremo a un backend MySQL per mostrare come un LLM possa guidare operazioni deterministiche. Entro la fine avrai un server MCP funzionante pronto per essere collegato al client AI che preferisci.

Come funziona MCP

MCP segue un modello client-server: l’applicazione AI fa da client, il tuo codice gira come server. In una configurazione tipica, il client (Claude Desktop, Claude Code, Cursor, ecc.) si interpone tra l’utente e il tuo server, inoltrandogli le richieste e restituendogli i risultati. Il modello stesso non chiama mai direttamente il tuo server: quando l’utente manda un messaggio, il client condivide col modello la lista dei tool esposti dal tuo server. Il modello decide quale tool chiamare (e con quali argomenti), il client esegue la chiamata e rimanda il risultato al modello.

Utente → Client MCP → Modello AI → Tool selezionato → Server MCP → Risposta

Prerequisiti

Per seguire questo tutorial ti serviranno:

• Node.js 18+
• Familiarità di base con TypeScript
• Un client compatibile con MCP per il test (Claude Desktop, Claude Code, Cursor, ecc.)
• MySQL installato localmente (solo per la sezione avanzata con database)

Costruire il server MCP: sistema di note su file

Iniziamo creando un nuovo progetto Node.js. Questo sarà un sistema di note basato su file, utile per comprendere i concetti prima di introdurre un database.

mkdir mcp-notes && cd mcp-notes
npm init -y

Installa le dipendenze necessarie: l’SDK MCP per costruire il server, Zod per la validazione degli input e TypeScript per la type safety:

npm install @modelcontextprotocol/sdk zod
npm install -D typescript @types/node

Apri il package.json e aggiungi "type": "module" (l’SDK MCP usa i moduli ES) e gli script di build e start:

{
  "type": "module",
  "scripts": {
    "build": "tsc",
    "start": "node dist/index.js"
  }
}

Crea un file tsconfig.json nella root del progetto:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "Node16",
    "moduleResolution": "Node16",
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true
  },
  "include": ["src/**/*"]
}

Scrivere il server

Crea il file src/index.ts con il codice base del server:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import fs from "fs/promises";
import path from "path";
import { z } from "zod";

const NOTES_DIR = path.join(process.cwd(), "notes");
await fs.mkdir(NOTES_DIR, { recursive: true });

const server = new McpServer({
  name: "mcp-notes",
  version: "1.0.0",
});

// I tool verranno aggiunti qui

const transport = new StdioServerTransport();
await server.connect(transport);

Questo è un MCP server completo e funzionante: crea la directory delle note, inizializza il server e lo connette tramite stdio per comunicare con un client MCP.

Aggiungere i tool

Ogni tool definisce una singola azione che il modello può compiere. Include nome, descrizione, schema di input e una funzione handler. Aggiungiamo i tre tool fondamentali: creazione, lettura e lista delle note.

server.tool(
  "create_note",
  "Create a new note with a given title and content",
  {
    title: z.string().min(1).describe("The note title"),
    content: z.string().min(1).describe("The body of the note"),
  },
  async ({ title, content }) => {
    const filename = `${title.replace(/[^a-z0-9_-]/gi, "_")}.txt`;
    const filepath = path.join(NOTES_DIR, filename);
    try {
      await fs.access(filepath);
      return {
        content: [{ type: "text", text: `Error: note "${title}" already exists.` }],
        isError: true,
      };
    } catch {}
    await fs.writeFile(filepath, content, "utf-8");
    return { content: [{ type: "text", text: `Note "${title}" created.` }] };
  }
);

server.tool(
  "read_note",
  "Read the content of a note by its title",
  { title: z.string().min(1).describe("The title of the note to read") },
  async ({ title }) => {
    const filename = `${title.replace(/[^a-z0-9_-]/gi, "_")}.txt`;
    try {
      const content = await fs.readFile(path.join(NOTES_DIR, filename), "utf-8");
      return { content: [{ type: "text", text: content }] };
    } catch {
      return {
        content: [{ type: "text", text: `Error: note "${title}" not found.` }],
        isError: true,
      };
    }
  }
);

server.tool(
  "list_notes",
  "List all available notes",
  {},
  async () => {
    const files = await fs.readdir(NOTES_DIR);
    const notes = files.filter(f => f.endsWith(".txt")).map(f => f.replace(".txt", ""));
    if (notes.length === 0) return { content: [{ type: "text", text: "No notes found." }] };
    return { content: [{ type: "text", text: notes.join("\n") }] };
  }
);

Testare il server con Claude Desktop

Compila il progetto con npm run build. Poi apri il file di configurazione di Claude Desktop:

• macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Aggiungi il server sotto la chiave mcpServers:

{
  "mcpServers": {
    "mcp-notes": {
      "command": "node",
      "args": ["/percorso/del/progetto/mcp-notes/dist/index.js"],
      "cwd": "/percorso/del/progetto/mcp-notes"
    }
  }
}

Riavvia Claude Desktop e prova con prompt come: “Crea una nota chiamata standup con gli aggiornamenti di oggi” oppure “Elenca tutte le mie note”.

Passare a MySQL: dati strutturati per uso reale

Il sistema basato su file funziona bene per comprendere i fondamentali, ma ha limiti evidenti. Passare a MySQL mette in luce un pattern importante nel design MCP: il modello decide quale azione intraprendere, ma il tuo codice rimane responsabile di come quella azione viene eseguita. Quando il modello chiama search_notes, non genera né esegue SQL da solo: il tuo handler gestisce l’operazione in modo controllato, con query parametrizzate.

Installa il driver MySQL:

npm install mysql2

Crea il database e la tabella:

CREATE DATABASE mcp_notes;
USE mcp_notes;
CREATE TABLE notes (
  id INT AUTO_INCREMENT PRIMARY KEY,
  title VARCHAR(255) UNIQUE NOT NULL,
  content TEXT NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

La versione MySQL del tool create_note inserisce una riga invece di scrivere un file e gestisce i duplicati intercettando l’errore ER_DUP_ENTRY. La versione di search_notes permette ricerche full-text su titoli e contenuti — una funzionalità che con i file richiederebbe un codice molto più complesso.

server.tool(
  "search_notes",
  "Search notes by keyword across titles and content",
  { query: z.string().min(1).describe("Keyword or phrase to search for") },
  async ({ query }) => {
    const like = `%${query}%`;
    const [rows] = await pool.execute<mysql.RowDataPacket[]>(
      "SELECT title, created_at FROM notes WHERE title LIKE ? OR content LIKE ? ORDER BY created_at DESC",
      [like, like]
    );
    if (rows.length === 0) {
      return { content: [{ type: "text", text: `No notes found matching "${query}".` }] };
    }
    return { content: [{ type: "text", text: rows.map(r => `- ${r.title} (${r.created_at})`).join("\n") }] };
  }
);

Principi per progettare buoni tool MCP

Un tool MCP che funziona in fase di test può fallire in produzione se il modello fraintende quando o come usarlo. Alcune regole pratiche:

• Descrizioni esplicite: frasi come “Gestisce le note” sono troppo vaghe. Usa descrizioni che spiegano chiaramente cosa fa il tool e quando va usato.
• Singola responsabilità: ogni tool deve fare una sola cosa. Strumenti troppo “jolly” costringono il modello a indovinare l’intento.
• Errori azionabili: usa isError: true con messaggi che guidano il modello su come riprovare: "Note non trovata. Usa list_notes per vedere quelle disponibili."
• Boundary sicuri: mai interpolazione diretta dell’input utente in SQL o comandi shell. Usa sempre query parametrizzate.

Conclusione

Costruire un MCP server con Node.js e TypeScript è sorprendentemente accessibile grazie all’SDK ufficiale. Il pattern che hai imparato in questo tutorial — definire tool con schema Zod, gestire gli errori con isError e connettere il server via stdio — si scala facilmente a scenari più complessi: integrazione di API REST, automazione di workflow, connessione di agenti AI a sistemi legacy.

Il codice completo del tutorial è disponibile su GitHub.

Fonte: How to build your first MCP server with Node.js — LogRocket Blog (Elijah Asaolu, 5 maggio 2026)

How to build your first MCP server with Node.js - LogRocket Blog

Learn how to build an MCP server with Node.js, from a simple file-based setup to a MySQL-backed system for real-world AI tool integration.

^{Elijah Asaolu (LogRocket Blog)}