Spcnet.it

2026-07-02 09:37:30

Agent AI e Malware Nascosto: come i Coding Agent vengono Ingannati da Repository GitHub Apparentemente Puliti

I moderni strumenti di coding assistito da AI stanno diventando parte integrante del flusso di lavoro di milioni di sviluppatori. Ma questa automazione introduce una nuova superficie di attacco che i ricercatori di sicurezza hanno appena dimostrato in modo preoccupante: un repository GitHub apparentemente pulito può indurre un agente AI a eseguire malware, senza che nessun codice malevolo sia visibile né agli scanner statici né agli occhi umani.

La ricerca di Mozilla 0DIN

I ricercatori della Mozilla Zero Day Investigative Network (0DIN), la piattaforma di sicurezza AI di Mozilla, hanno pubblicato un proof-of-concept che dimostra come un agente di coding autonomo possa essere indotto a installare una reverse shell sul sistema dello sviluppatore. Il test è stato condotto specificamente con Claude Code, ma la vulnerabilità concettuale riguarda qualsiasi agente AI che abbia accesso al filesystem e al terminale.

La parte più inquietante della ricerca è questa frase dei ricercatori: “No exploit code, no warning, no suspicious command anyone had to approve.” Nessun codice exploit, nessun avvertimento, nessun comando sospetto da approvare.

Come funziona l’attacco: tre componenti innocui

L’attacco si basa su tre elementi che, considerati singolarmente, non destano alcun sospetto:

1. Un repository GitHub pulito — Il repo contiene istruzioni di setup standard: installazione dipendenze (pip3 install -r requirements.txt) e inizializzazione del progetto (python3 -m axiom init). Nessun codice malevolo, nessun flag da scanner.
2. Un pacchetto Python progettato per fallire — Il package è volutamente configurato per rifiutare l’esecuzione finché non viene inizializzato. Genera un errore che istruisce l’utente (o l’agente) a eseguire python3 -m axiom init. L’agente AI, tentando di risolvere autonomamente l’errore di setup, lancia questo comando.
3. Un record DNS TXT controllato dall’attaccante — Il comando di inizializzazione chiama uno script shell che recupera un valore di configurazione da un record DNS TXT controllato dall’attaccante. Quel valore viene eseguito come comando.

Il risultato è una reverse shell con i privilegi del developer. L’agente AI ha eseguito tre livelli di indirection — un messaggio di errore fidato, uno script che ha recuperato un valore, e un record DNS che non ha mai esaminato — senza mai “vedere” il payload malevolo.

Perché è invisibile ai controlli tradizionali

Questa tecnica bypassa tutti i meccanismi di difesa convenzionali:

• Scanner statici: non trovano nulla perché il repository è genuinamente pulito
• Code review umana: anche un revisore attento non vedrebbe codice malevolo
• AI review: l’agente AI valuta solo il codice che vede, non il payload DNS
• Audit log limitati: l’agente potrebbe non registrare l’intera catena di esecuzione, incluse le risorse recuperate dinamicamente a runtime

Ciò che rende l’attacco efficace è il comportamento goal-oriented degli agenti AI: quando incontrano un errore, il loro obiettivo è risolverlo. E lo risolvono eseguendo esattamente ciò che viene suggerito — anche se quel suggerimento porta a recuperare ed eseguire un payload da un record DNS remoto.

Cosa ottiene l’attaccante

Se l’attacco va a segno, l’attaccante ottiene una shell interattiva con i privilegi dello sviluppatore. Questo significa accesso a:

• Variabili d’ambiente (incluse credenziali e API key)
• File di configurazione locali (chiavi SSH, certificati, config di cloud provider)
• Possibilità di stabilire persistenza sul sistema
• Accesso ai repository locali e ai segreti in essi contenuti

I ricercatori 0DIN avvertono che questa tecnica potrebbe essere distribuita facilmente attraverso fake job posting, tutorial, post su blog tecnici o messaggi diretti su piattaforme come Discord o LinkedIn.

Come mitigare il rischio

0DIN ha proposto alcune contromisure concrete per chi sviluppa o utilizza strumenti di coding AI agentico:

1. Execution chain disclosure: gli agenti AI dovrebbero mostrare esplicitamente l’intera catena di esecuzione dei comandi di setup, inclusi script e codice recuperato dinamicamente a runtime, prima di eseguirlo.
2. Sandboxing più rigido: gli agenti autonomi che interagiscono con repository esterni dovrebbero operare in ambienti isolati (container, VM, namespace separati) con privilegi minimi.
3. Permission scoping: limitare le azioni che un agente AI può compiere autonomamente — specialmente l’esecuzione di comandi shell — richiedendo conferma esplicita dell’utente per operazioni ad alto rischio.
4. Monitoraggio DNS in uscita: implementare logging e alerting su query DNS anomale durante le operazioni di build e setup.
5. Analisi comportamentale: non fidarsi solo degli scanner statici, ma adottare strumenti di analisi comportamentale che monitorino le azioni effettive a runtime.

Un segnale di allarme per il settore

Questa ricerca evidenzia un problema strutturale nell’adozione degli agenti AI nel ciclo di sviluppo: l’automazione che ci fa risparmiare tempo è la stessa che può diventare un vettore di attacco. Man mano che strumenti come Claude Code, GitHub Copilot Workspace e altri agenti simili vengono integrati nelle pipeline CI/CD e nei workflow quotidiani, la superficie di attacco si espande in modi che i modelli di minaccia tradizionali non contemplano.

La buona notizia è che, per ora, si tratta di un proof-of-concept. La cattiva è che chiunque abbia letto questa ricerca sa come replicarlo — e il costo per un attaccante è praticamente zero: basta pubblicare un repository GitHub e registrare un dominio per il record DNS TXT.

Per i team di sicurezza, questo è il momento di rivedere le policy di utilizzo degli agenti AI, in particolare per quanto riguarda le operazioni autonome su repository di terze parti.

---

Fonte originale: 4sysops.com — ricerca originale di Mozilla 0DIN via BleepingComputer

AI coding agents vulnerable to stealthy malware execution via GitHub – 4sysops

Security researchers have demonstrated a new attack method that tricks autonomous AI coding agents into executing malicious payloads from seemingly clean GitHub

^{IT News (4sysops)}

Spcnet.it

2026-06-30 13:08:29

.NET 8 e .NET 9: fine del supporto il 10 novembre 2026 — come migrare a .NET 10 LTS

La scadenza che riguarda milioni di applicazioni

Il 10 novembre 2026 è una data che ogni sviluppatore .NET dovrebbe segnare in calendario. In quel giorno, coincidente con il Patch Tuesday di novembre, sia .NET 8 che .NET 9 raggiungeranno la fine del supporto ufficiale Microsoft. Nessun aggiornamento di sicurezza, nessuna correzione di bug, nessun supporto tecnico. Le applicazioni continueranno a funzionare, ma rimarranno permanentemente esposte a qualsiasi vulnerabilità scoperta dopo quella data.

La cosa insolita di questa scadenza è che riguarda contemporaneamente due versioni: .NET 8 (LTS) e .NET 9 (STS). Normalmente un release LTS ha un ciclo di vita più lungo, ma in questo caso il calendario ha fatto sì che le loro finestre di supporto si chiudano lo stesso giorno. Chi è su .NET 9 sperando di guadagnare tempo rispetto a .NET 8 rimarrà deluso: la scadenza è identica.

Cosa succede dopo la fine del supporto

Le applicazioni basate su .NET 8 o .NET 9 continueranno a girare normalmente il giorno dopo la scadenza. Il problema non è l’esecuzione, è il rischio accumulato nel tempo:

• Nessuna patch di sicurezza per vulnerabilità future nel runtime o nelle librerie base.
• Visual Studio 2022 inizierà a segnalare i componenti .NET 8 e .NET 9 come “fuori supporto” in un aggiornamento futuro.
• Problemi di compliance per applicazioni in ambienti regolamentati (finanziario, sanitario, PA) che richiedono software aggiornato.
• Dipendenze di terze parti che smettono di supportare le versioni EOL, creando colli di bottiglia nelle pipeline di aggiornamento.

Il rischio non è immediato ma cresce nel tempo. Ogni mese trascorso su un runtime non supportato è un mese in cui una CVE critica potrebbe restare irrisolta.

Perché migrare direttamente a .NET 10 LTS

.NET 10 è il target di migrazione raccomandato. È la versione LTS corrente, rilasciata a novembre 2025 e supportata fino al novembre 2028: tre anni di aggiornamenti garantiti. Non ha senso fermarsi a .NET 9, che ha la stessa data di scadenza di .NET 8: sarebbe aggiungere lavoro di migrazione senza estendere la finestra di supporto.

.NET 10 porta miglioramenti significativi in diverse aree:

• Performance: ulteriori ottimizzazioni al JIT, riduzione delle allocazioni in Span e Memory, miglioramenti a LINQ e collezioni.
• ASP.NET Core: nuove API per minimal API, miglioramenti a Blazor, OpenAPI nativo senza dipendenze esterne.
• C# 14: field keyword per le proprietà auto, extension members, parametri params su ReadOnlySpan.
• Tooling: .NET Aspire 9 integrato, nuove funzionalità in dotnet publish per container nativi.

Come migrare: i passi pratici

1. Aggiornare il TargetFramework

Il primo passo è aggiornare il file di progetto .csproj. La modifica è minimale:

<!-- Prima -->
<TargetFramework>net8.0</TargetFramework>

<!-- Dopo -->
<TargetFramework>net10.0</TargetFramework>

Per progetti multi-target:

<TargetFrameworks>net10.0;net8.0</TargetFrameworks>

2. Aggiornare i pacchetti NuGet

Verificare che tutti i pacchetti Microsoft.* siano aggiornati alla versione compatibile con .NET 10. Usare dotnet outdated (strumento separato) o il Package Manager di Visual Studio per identificare i pacchetti da aggiornare.

dotnet list package --outdated

3. Usare il .NET Upgrade Assistant

Per progetti complessi o soluzioni con più progetti, Microsoft fornisce il .NET Upgrade Assistant, disponibile come tool CLI e come estensione Visual Studio:

dotnet tool install -g upgrade-assistant
upgrade-assistant upgrade MyProject.csproj

L’Upgrade Assistant analizza il progetto, identifica API deprecate, suggerisce sostituzioni e può applicare alcune modifiche automaticamente. Non risolve tutto, ma riduce significativamente il lavoro manuale.

4. Verificare le dipendenze di terze parti

Questo è spesso il collo di bottiglia più sottovalutato. Librerie NuGet che non hanno ancora rilasciato una versione compatibile con .NET 10 possono bloccare la migrazione. Controllare GitHub e NuGet Gallery per verificare lo stato di supporto di ogni dipendenza critica. Se un vendor non ha ancora aggiornato, contattarlo subito: con cinque mesi alla scadenza, i tempi di risposta si stringeranno progressivamente.

5. Testare prima del rollout

Per applicazioni con buona copertura di test, la migrazione da .NET 8 a .NET 10 è generalmente lineare. Breaking changes tra versioni LTS sono limitati e ben documentati nelle note di rilascio. Microsoft pubblica la lista completa su GitHub nel repository dotnet/core. Il time-to-complete dipende dalla complessità: da una a tre settimane per un singolo servizio con buon test coverage, quattro-otto settimane per piattaforme multi-servizio con audit delle dipendenze e rollout graduale.

Timeline consigliata

Con la scadenza al 10 novembre 2026, luglio e agosto sono il momento ideale per avviare la pianificazione. Aspettare settembre o ottobre significa sovrapporsi con i freeze di fine anno e ridurre drasticamente il margine di sicurezza per gestire problemi imprevisti.

Un approccio ragionevole:

• Luglio 2026: inventario delle applicazioni su .NET 8/9, audit delle dipendenze NuGet, verifica compatibilità vendor.
• Agosto 2026: migrazione dei progetti interni meno critici, test in ambiente staging.
• Settembre-Ottobre 2026: migrazione dei sistemi critici, test di regressione, formazione del team sulle novità .NET 10.
• Novembre 2026: deploy in produzione con ampio margine prima della scadenza.

Conclusione

La doppia scadenza di .NET 8 e .NET 9 il 10 novembre 2026 è un’opportunità per consolidare il proprio stack su .NET 10 LTS, garantendo tre anni di supporto garantito e beneficiando delle ottimizzazioni di performance dell’ultimo runtime. La migrazione è tecnicamente accessibile, ma richiede pianificazione anticipata, soprattutto per gestire le dipendenze di terze parti. Iniziare ora, prima che la finestra si restringa, è la mossa giusta.

Fonti: Microsoft aligns .NET 8 and .NET 9 end of support for November 2026 – 4sysops · Official .NET Support Policy – Microsoft

Microsoft aligns .NET 8 and .NET 9 end of support for November 2026 – 4sysops

Microsoft has announced that both .NET 8 and .NET 9 will reach their end of support on November 10, 2026. This alignment occurs because .NET 9 is a Standard Ter

^{IT News (4sysops)}

Spcnet.it

2026-06-30 13:05:43

Agent AI e malware nascosto: come i Coding Agent vengono ingannati da repository GitHub apparentemente puliti

I moderni strumenti di coding assistito da AI stanno diventando parte integrante del flusso di lavoro di milioni di sviluppatori. Ma questa automazione introduce una nuova superficie di attacco che i ricercatori di sicurezza hanno appena dimostrato in modo preoccupante: un repository GitHub apparentemente pulito può indurre un agente AI a eseguire malware, senza che nessun codice malevolo sia visibile né agli scanner statici né agli occhi umani.

La ricerca di Mozilla 0DIN

I ricercatori della Mozilla Zero Day Investigative Network (0DIN), la piattaforma di sicurezza AI di Mozilla, hanno pubblicato un proof-of-concept che dimostra come un agente di coding autonomo possa essere indotto a installare una reverse shell sul sistema dello sviluppatore. Il test è stato condotto specificamente con Claude Code, ma la vulnerabilità concettuale riguarda qualsiasi agente AI che abbia accesso al filesystem e al terminale.

La parte più inquietante della ricerca è questa frase dei ricercatori: “No exploit code, no warning, no suspicious command anyone had to approve.” Nessun codice exploit, nessun avvertimento, nessun comando sospetto da approvare.

Come funziona l’attacco: tre componenti innocui

L’attacco si basa su tre elementi che, considerati singolarmente, non destano alcun sospetto:

1. Un repository GitHub pulito — Il repo contiene istruzioni di setup standard: installazione dipendenze (pip3 install -r requirements.txt) e inizializzazione del progetto (python3 -m axiom init). Nessun codice malevolo, nessun flag da scanner.
2. Un pacchetto Python progettato per fallire — Il package è volutamente configurato per rifiutare l’esecuzione finché non viene inizializzato. Genera un errore che istruisce l’utente (o l’agente) a eseguire python3 -m axiom init. L’agente AI, tentando di risolvere autonomamente l’errore di setup, lancia questo comando.
3. Un record DNS TXT controllato dall’attaccante — Il comando di inizializzazione chiama uno script shell che recupera un valore di configurazione da un record DNS TXT controllato dall’attaccante. Quel valore viene eseguito come comando.

Il risultato è una reverse shell con i privilegi del developer. L’agente AI ha eseguito tre livelli di indirection — un messaggio di errore fidato, uno script che ha recuperato un valore, e un record DNS che non ha mai esaminato — senza mai “vedere” il payload malevolo.

Perché è invisibile ai controlli tradizionali

Questa tecnica bypassa tutti i meccanismi di difesa convenzionali:

• Scanner statici: non trovano nulla perché il repository è genuinamente pulito
• Code review umana: anche un revisore attento non vedrebbe codice malevolo
• AI review: l’agente AI valuta solo il codice che vede, non il payload DNS
• Audit log limitati: l’agente potrebbe non registrare l’intera catena di esecuzione, incluse le risorse recuperate dinamicamente a runtime

Ciò che rende l’attacco efficace è il comportamento goal-oriented degli agenti AI: quando incontrano un errore, il loro obiettivo è risolverlo. E lo risolvono eseguendo esattamente ciò che viene suggerito — anche se quel suggerimento porta a recuperare ed eseguire un payload da un record DNS remoto.

Cosa ottiene l’attaccante

Se l’attacco va a segno, l’attaccante ottiene una shell interattiva con i privilegi dello sviluppatore. Questo significa accesso a:

• Variabili d’ambiente (incluse credenziali e API key)
• File di configurazione locali (chiavi SSH, certificati, config di cloud provider)
• Possibilità di stabilire persistenza sul sistema
• Accesso ai repository locali e ai segreti in essi contenuti

I ricercatori 0DIN avvertono che questa tecnica potrebbe essere distribuita facilmente attraverso fake job posting, tutorial, post su blog tecnici o messaggi diretti su piattaforme come Discord o LinkedIn.

Come mitigare il rischio

0DIN ha proposto alcune contromisure concrete per chi sviluppa o utilizza strumenti di coding AI agentico:

1. Execution chain disclosure: gli agenti AI dovrebbero mostrare esplicitamente l’intera catena di esecuzione dei comandi di setup, inclusi script e codice recuperato dinamicamente a runtime, prima di eseguirlo.
2. Sandboxing più rigido: gli agenti autonomi che interagiscono con repository esterni dovrebbero operare in ambienti isolati (container, VM, namespace separati) con privilegi minimi.
3. Permission scoping: limitare le azioni che un agente AI può compiere autonomamente — specialmente l’esecuzione di comandi shell — richiedendo conferma esplicita dell’utente per operazioni ad alto rischio.
4. Monitoraggio DNS in uscita: implementare logging e alerting su query DNS anomale durante le operazioni di build e setup.
5. Analisi comportamentale: non fidarsi solo degli scanner statici, ma adottare strumenti di analisi comportamentale che monitorino le azioni effettive a runtime.

Un segnale di allarme per il settore

Questa ricerca evidenzia un problema strutturale nell’adozione degli agenti AI nel ciclo di sviluppo: l’automazione che ci fa risparmiare tempo è la stessa che può diventare un vettore di attacco. Man mano che strumenti come Claude Code, GitHub Copilot Workspace e altri agenti simili vengono integrati nelle pipeline CI/CD e nei workflow quotidiani, la superficie di attacco si espande in modi che i modelli di minaccia tradizionali non contemplano.

La buona notizia è che, per ora, si tratta di un proof-of-concept. La cattiva è che chiunque abbia letto questa ricerca sa come replicarlo — e il costo per un attaccante è praticamente zero: basta pubblicare un repository GitHub e registrare un dominio per il record DNS TXT.

Per i team di sicurezza, questo è il momento di rivedere le policy di utilizzo degli agenti AI, in particolare per quanto riguarda le operazioni autonome su repository di terze parti.

---

Fonte originale: 4sysops.com — ricerca originale di Mozilla 0DIN via BleepingComputer

AI coding agents vulnerable to stealthy malware execution via GitHub – 4sysops

Security researchers have demonstrated a new attack method that tricks autonomous AI coding agents into executing malicious payloads from seemingly clean GitHub

^{IT News (4sysops)}

Spcnet.it

2026-06-30 13:08:55

Podman su Linux: alternativa sicura e rootless a Docker

Cos’è Podman e perché considerarlo

Docker è stato per anni il punto di riferimento per la containerizzazione su Linux. Funziona, è ben documentato e ha un ecosistema enorme. Eppure, man mano che i requisiti di sicurezza sono aumentati e l’integrazione con systemd è diventata più importante, le sue limitazioni strutturali hanno iniziato a pesare. Podman nasce per affrontare esattamente questi problemi.

Podman (Pod Manager) è un container engine open source, daemonless: a differenza di Docker, non ha un demone centralizzato (dockerd) che gira in background con privilegi root. I container vengono avviati direttamente come processi figli dell’utente, il che significa che è possibile eseguirli in modalità rootless, senza mai richiedere sudo. Supporta gli stessi formati OCI di Docker (le immagini Docker funzionano senza modifiche), parla la stessa sintassi CLI e comprende nativamente il concetto di pod, gruppo di container che condividono rete e storage, esattamente come in Kubernetes.

Installazione su Linux

Podman è disponibile nei repository ufficiali di tutte le principali distribuzioni. Non servono PPA esterni o script di terze parti.

Debian / Ubuntu (20.10+) e Linux Mint:

sudo apt-get update
sudo apt-get install -y podman

Fedora / CentOS Stream / RHEL 8+:

sudo dnf install -y podman

openSUSE:

sudo zypper install podman

Arch / Manjaro:

sudo pacman -S podman

Dopo l’installazione, verificare con:

podman --version
podman info

Un rapido smoke test per assicurarsi che tutto funzioni:

podman run hello-world

Se si ottiene il messaggio di conferma, Podman è operativo.

Comandi di base: la compatibilità con Docker è quasi totale

La CLI di Podman rispecchia quella di Docker comando per comando. Chi conosce Docker si trova subito a proprio agio. Ecco i comandi più usati:

# Shell interattiva in un container Ubuntu
podman run -it ubuntu bash

# Container in background (Nginx su porta 8080)
podman run -d --name web -p 8080:80 nginx

# Elenco container in esecuzione
podman ps

# Elenco di tutte le immagini locali
podman images

# Stop e rimozione
podman stop web
podman rm web

Per chi vuole una transizione trasparente, è possibile creare un alias:

alias docker=podman

Oppure installare il pacchetto podman-docker, che fornisce uno shim che reindirizza automaticamente i comandi docker a Podman.

Le differenze che contano davvero

La maggior parte dei comandi funziona identica, ma ci sono differenze che emergono quando si lavora con volumi e SELinux. La più comune riguarda i bind mount in modalità rootless: i namespace utente e il mapping subuid/subgid possono causare problemi di ownership. Sui sistemi con SELinux attivo è necessario aggiungere il suffisso :Z ai volumi:

podman run -v /host/path:/container/path:Z myimage

La z minuscola condivide il volume tra più container; la Z maiuscola lo etichetta come privato per un singolo container. Altre differenze da tenere a mente:

• L’accesso GPU rootless per NVIDIA richiede nvidia-container-toolkit e la configurazione CDI.
• Docker Secrets e alcune configurazioni di rete non hanno un mapping diretto.
• I container rootless usano porte superiori a 1024 per default (limite del kernel per utenti non root).

Nessuna di queste differenze è un blocco, ma richiedono un test esplicito prima di assumere che la migrazione sia trasparente.

Integrazione con systemd: i Quadlet

Questo è forse il punto di forza più significativo di Podman per un amministratore di sistema. Invece di lasciare un demone attivo, è possibile affidare i container a systemd tramite i Quadlet: file dichiarativi con estensione .container che Podman trasforma automaticamente in unit systemd.

Per un servizio utente rootless, creare il file in ~/.config/containers/systemd/. Esempio minimale per Nginx:

[Container]
ContainerName=web
Image=docker.io/library/nginx:latest
PublishPort=8080:80

[Install]
WantedBy=default.target

Ricaricare systemd e avviare il servizio:

systemctl --user daemon-reload
systemctl --user start web

Aggiungendo l’etichetta AutoUpdate=registry, Podman scaricherà automaticamente le immagini aggiornate e riavvierà il servizio tramite timer, senza alcun tool esterno:

podman auto-update

Migrazione da Docker Compose

Chi ha ambienti basati su Docker Compose ha due strade. La prima è continuare a usare Compose puntando al socket di Podman, abilitandolo con:

systemctl --user enable --now podman.socket

I file docker-compose.yml esistenti funzionano senza modifiche. La seconda opzione è convertire i Compose in Quadlet usando podlet, uno strumento che legge un docker-compose.yml e genera i corrispondenti file Quadlet. La curva di apprendimento c’è, ma il risultato è un’integrazione più pulita con il sistema.

Quando Docker rimane la scelta migliore

Podman offre sicurezza migliore e un’integrazione più nativa con Linux. Ma Docker ha un ecosistema più maturo: Docker Swarm, strumenti CI/CD che assumono la presenza del comando docker, e team già standardizzati su determinati workflow. Se si parte da zero su un server Linux, Podman è la scelta più pulita. Se si ha già un’infrastruttura Docker consolidata, la migrazione va pianificata e testata con attenzione.

Podman è un’alternativa concreta e matura a Docker, non un esperimento di nicchia. L’assenza del demone root, l’integrazione nativa con systemd tramite Quadlet e la compatibilità quasi totale con la CLI Docker lo rendono una scelta solida per chiunque gestisca container su Linux. L’installazione richiede un singolo comando, i comandi quotidiani sono identici a Docker, e i vantaggi in termini di sicurezza arrivano senza configurazioni complesse. Vale la pena provarlo.

Fonte: Docker Alternative: Podman on Linux – LinuxBlog.io

Docker Alternative: Podman on Linux | LinuxBlog.io

This article is inspired by our LinuxCommunity.io forum discussion thread (thanks to users @tmick and @shybry747 for the feedback). Let's walk through

^{Hayden James (LinuxBlog.io)}