---
title: "Yellow Teaming: parola di moda o punto di rottura? | Guardian360"
description: "Guardian360 è stata silenziosamente uno Yellow Team per anni: i costruttori dietro il Red e il Blue. L'IA ha appena cambiato i conti per i costruttori, ed è il motivo per cui vogliamo che Lighthouse passi dal consegnare ai partner una mappa al guidare il percorso."
url: https://guardian360.net/it/blog/yellow-teaming-buzzword-or-breaking-point/
locale: en
source: guardian360.net
---
[← Tutti i post](https://guardian360.net/it/blog/)

Opinione

# Yellow Teaming: parola di moda o punto di rottura?

Di Jan Martijn Broekhof · 15 luglio 2026

Non avevo mai sentito il termine “Yellow Team” finché non ho letto un recente articolo di Dark Reading su IA e sicurezza. Alla fine del secondo paragrafo mi sono reso conto di qualcosa di leggermente scomodo: Guardian360 lo è stata silenziosamente per anni, e nessuno, me compreso, si è mai preso la briga di chiamarla così.

Per molto tempo non ha avuto grande importanza. Costruire gli strumenti usati dai team Red e Blue era visto come lavoro di commodity: necessario, poco glamour, raramente oggetto di un intervento a una conferenza. Gli attaccanti si prendevano il dramma. I difensori si prendevano il merito di tenere la linea. Le persone che costruivano le piattaforme sotto entrambi si prendevano una voce nel budget. L’IA sta cambiando questo calcolo, e vale la pena capire perché, e cosa significa per il modo in cui Guardian360 lavora con i suoi partner.

## Cosa sono esattamente i team Red, Blue e Yellow, e dove si colloca il DevSecOps?

Il vocabolario dei colori nella cybersecurity è più antico di quanto la maggior parte delle persone immagini. Red Team indica le persone che simulano gli attacchi: penetration tester, hacker etici, quelli pagati per entrare prima che lo faccia qualcuno con intenzioni peggiori. Blue Team indica i difensori: gli analisti e gli ingegneri che rilevano quegli attacchi, vi rispondono e ne recuperano. Lo Yellow Team sta sotto entrambi. È il gruppo che progetta, costruisce e mantiene i sistemi, le applicazioni e gli strumenti su cui e con cui Red e Blue operano effettivamente.

Questa distinzione è stata proposta per la prima volta al Black Hat nel 2017, quando è stata introdotta una ruota dei colori per mappare le diverse funzioni all’interno del lavoro di sicurezza oltre la familiare contrapposizione rosso contro blu, come i ricercatori di sicurezza di Retest Security hanno da allora documentato nella loro stessa storia del framework. Il giallo è stato definito come i costruttori: architetti, sviluppatori e ingegneri responsabili di sistemi sicuri fin dalle fondamenta, anziché le persone che li attaccano o li difendono a posteriori.

Il DevSecOps non è un colore separato su quella ruota. È la pratica che gli Yellow Team usano per svolgere il loro lavoro: integrare la sicurezza nella pipeline di sviluppo stessa, così che le vulnerabilità vengano intercettate nel momento della creazione anziché scoperte più tardi dal Red o ripulite più tardi dal Blue. Il DevSecOps è il metodo. Lo Yellow Team è il gruppo di persone che lo applica.

## Solo DevSecOps con una nuova mano di vernice?

Uno scettico onesto mi fermerebbe qui. Se lo Yellow Team è semplicemente le persone che fanno DevSecOps, cosa è cambiato davvero? Le organizzazioni hanno ingegneri di sviluppo sicuro da un decennio. Chiamarli “gialli” non rende il lavoro nuovo.

Quello scetticismo merita una risposta onesta, e la risposta onesta è: da sola, l’etichetta sarebbe davvero vino vecchio in una bottiglia nuova. Ciò che rende diverso questo momento non è il nome, è la scala di ciò che agli Yellow Team viene ora chiesto di costruire. Modelli di IA di frontiera come Claude Mythos e GPT-5.5 possono trovare e concatenare vulnerabilità software più velocemente di quasi qualsiasi team umano, e le organizzazioni stanno solo iniziando a capire come indirizzare quella capacità in una direzione utile anziché caotica. Quell’indirizzamento, si scopre, è lavoro da Yellow Team, e non assomiglia per niente a scrivere checklist di revisione del codice sicuro.

## Perché l’IA ha appena cambiato i conti per i costruttori

Secondo il resoconto di Dark Reading, gli ingegneri di aziende come Cisco, Microsoft, Cloudflare e Netskope stanno ora dedicando il loro tempo a costruire “harness”: costrutti software che definiscono esattamente cosa a un modello di IA è consentito fare, quali permessi ha e quali guardrail deve rispettare mentre va a caccia di vulnerabilità. Un harness sembra restrittivo, ma è il contrario. Senza, i team Red vengono sommersi da falsi positivi e risultati privi di contesto di business; con uno, lo stesso modello di IA diventa davvero utile sia per la simulazione degli attacchi sia per la difesa.

Il CISO di Netskope James Robinson descrive esattamente questo schema: il modello ha segnalato un endpoint interno come non autenticato, tecnicamente vero, ma non ha colto che l’endpoint non era comunque raggiungibile dal web. Passare dall’output grezzo dell’IA a qualcosa di cui un analista umano si fiderebbe ha richiesto uno sforzo ingegneristico dedicato, non un prompt.

L’effetto a catena è che Blue e Yellow vengono avvicinati più di quanto lo siano mai stati. Come dice Levi Bolourie di Zscaler, i blue team che non usano l’IA per l’analisi rischiano di essere sommersi dall’enorme volume di segnali che il red teaming assistito dall’IA produce ora, e di conseguenza le due discipline dovranno integrarsi molto più strettamente. Gli Yellow Team non sono più una funzione di supporto che sta silenziosamente dietro Red e Blue. Sono il motivo per cui entrambi i team riescono a stare al passo.

## Da un sistema di registrazione a un sistema di azione

C’è un secondo cambiamento che scorre sotto tutto questo, e si applica ben oltre la sicurezza. Per due decenni, la maggior parte del software aziendale è stata ciò che oggi si chiama un “sistema di registrazione” (system of record): un luogo che memorizza ciò che è accaduto. Il tuo CRM registra che un cliente ha chiamato. La tua piattaforma di scanning registra che esiste una vulnerabilità. Utile, necessario e del tutto passivo.

Un “sistema di azione” (system of action) fa qualcosa di diverso. Invece di limitarsi a memorizzare ciò che è accaduto, usa quelle informazioni per decidere cosa dovrebbe accadere dopo, e sempre più spesso, per farlo. La ricerca di Grammarly sulla produttività sul lavoro ha rilevato che il 77 per cento dei professionisti si sente sopraffatto dall’enorme volume di informazioni che deve elaborare, e l’83 per cento afferma di non avere gli strumenti per agire davvero su ciò che sa. Quel divario tra avere i dati e farne qualcosa di utile è esattamente ciò che un sistema di azione dovrebbe colmare.

Mi piace pensarlo come la differenza tra un faro tradizionale e uno capace di orientare il proprio fascio. Un faro tradizionale è un puro sistema di registrazione: segna una posizione fissa e nota, e sta al capitano della nave leggere la luce, valutare la distanza e scegliere la rotta. Non si adatta alla nave che ha davanti. Ora immagina un faro capace di tracciare un’imbarcazione in avvicinamento e di reindirizzare attivamente il proprio fascio per avvertire quella specifica nave, in quel preciso momento, del pericolo più vicino a lei. Il capitano governa ancora la nave. Ma il faro ha smesso di essere un segnale statico e ha iniziato a essere un partecipante attivo nel tenere al sicuro quella nave.

## Ai partner consegnavamo una mappa. Ora vogliamo guidare il percorso.

Una breve nota sul posizionamento prima di proseguire: Guardian360 è un fornitore di software indipendente. Sviluppiamo la piattaforma Lighthouse: scanning continuo, raccomandazioni di conformità, inventario degli asset, scoring del rischio di business e tecnico. Non gestiamo un Security Operations Centre, non eseguiamo penetration testing manuali o risposta agli incidenti, e non vendiamo direttamente ai clienti. Quel lavoro spetta ai nostri partner, ed è sempre stato così.

Per anni, ciò che consegnavamo ai partner era, di fatto, una mappa. Lighthouse mostrava dove fosse il rischio, cosa richiedesse attenzione e più o meno quanto fosse urgente. Trovare il miglior percorso da quelle informazioni a un ambiente cliente specifico era lasciato interamente al partner. Era il modello giusto quando la mappa stessa era la parte difficile da costruire. È un modello più complicato ora che l’IA può aiutare a generare non solo la mappa, ma un passo successivo davvero utile.

Nei prossimi mesi, vogliamo che Lighthouse si sposti ulteriormente dalla mappa verso la navigazione: non limitarsi a mostrare ai partner dove si trova il rischio, ma proporre il miglior percorso per affrontarlo, ancora e ancora, man mano che le circostanze cambiano. È questo che significa davvero, per noi, costruire un sistema di azione nella pratica.

Vale la pena essere onesti su questo, perché solleva una domanda ovvia per ogni partner che legge: se la piattaforma inizia a proporre il percorso, cosa resta al guidatore? La nostra risposta è che il partner resta al controllo dell’auto. Non stiamo costruendo strumenti per tagliare fuori i partner dal lavoro; li stiamo costruendo per togliere loro di mano le parti del lavoro che non richiedono un giudizio umano, così che le decisioni che invece richiedono un umano ricevano più attenzione, non meno. I partner stanno, di fatto, diventando il Blue Team di domani: quelli che decidono, agiscono e si assumono la responsabilità del risultato, supportati da uno Yellow Team a cui finalmente si chiede di fare più che tenere le luci accese.

## Allora, quale team sei stato silenziosamente?

Guardian360 è stata uno Yellow Team molto prima che il termine esistesse, e sospetto che un buon numero di organizzazioni che leggono questo possa dire lo stesso di almeno una parte della propria attività. La domanda su cui vale la pena soffermarsi non è se lo Yellow Teaming sia una categoria reale o solo un rebranding. È quale dei tuoi team abbia svolto questo lavoro in secondo piano per anni, senza nome e sottovalutato, e se sei pronto a consegnargli gli strumenti, e l’attenzione, che questo momento richiede davvero.

## Fonti

- Nate Nelson, “‘Yellow Teams’ Are Defining the Future of AI Security”, Dark Reading, 13 luglio 2026. [https://www.darkreading.com/cybersecurity-operations/yellow-teams-defining-future-ai-security](https://www.darkreading.com/cybersecurity-operations/yellow-teams-defining-future-ai-security)
- “The colourful world of Cybersecurity”, Retest Security. [https://retest.dk/the-colorful-world-of-cybersecurity/?lang=en](https://retest.dk/the-colorful-world-of-cybersecurity/?lang=en)
- “Yellow Team: Definition & Overview”, Inspirisys. [https://www.inspirisys.com/glossary/yellow-team](https://www.inspirisys.com/glossary/yellow-team)
- “From Systems of Record to Systems of Action: Preparing for Agentic AI”, Grammarly Blog. [https://www.grammarly.com/blog/ai/summer-trend-systems-of-action/](https://www.grammarly.com/blog/ai/summer-trend-systems-of-action/)