Guardian360
Starta gratis provperiodBli partner
← Alla inlägg

Opinion

Yellow Teaming: modeord eller vändpunkt?

Av Jan Martijn Broekhof ·

Jag hade aldrig hört termen “Yellow Team” förrän jag läste ett färskt inlägg i Dark Reading om AI och säkerhet. I slutet av det andra stycket insåg jag något en aning obekvämt: Guardian360 har i tysthet varit ett i åratal, och ingen, jag själv inräknad, hade någonsin brytt sig om att kalla det så.

Under lång tid spelade det inte så stor roll. Att bygga de verktyg som Red- och Blue-team använder sågs som standardarbete: nödvändigt, oglamoröst, sällan föremål för ett konferensföredrag. Angriparna fick dramatiken. Försvararna fick äran för att hålla ställningarna. De som byggde plattformarna under båda fick en post i budgeten. AI håller på att ändra den kalkylen, och det är värt att förstå varför, och vad det betyder för hur Guardian360 arbetar med sina partner.

Vad är egentligen Red-, Blue- och Yellow-team, och var passar DevSecOps in?

Färgvokabulären inom cybersäkerhet är äldre än de flesta antar. Red Team syftar på de människor som simulerar angrepp: penetrationstestare, etiska hackare, de som får betalt för att bryta sig in innan någon med sämre avsikter gör det. Blue Team syftar på försvararna: analytikerna och ingenjörerna som upptäcker, besvarar och återhämtar sig från dessa angrepp. Yellow Team sitter under båda. Det är gruppen som utformar, bygger och underhåller de system, applikationer och verktyg som Red och Blue faktiskt arbetar på och med.

Denna distinktion föreslogs först på Black Hat 2017, när ett färghjul introducerades för att kartlägga de olika funktionerna inom säkerhetsarbete bortom den välbekanta uppdelningen röd mot blå, något säkerhetsforskare hos Retest Security sedan har dokumenterat i sin egen historik över ramverket. Yellow definierades som byggarna: arkitekter, utvecklare och ingenjörer med ansvar för säkra system från grunden, snarare än de som angriper eller försvarar dem i efterhand.

DevSecOps är inte en egen färg på det hjulet. Det är den praktik Yellow-team använder för att göra sitt jobb: att väva in säkerhet i själva utvecklingskedjan, så att sårbarheter fångas vid skapandet snarare än upptäcks senare av Red eller städas upp senare av Blue. DevSecOps är metoden. Yellow Team är gruppen människor som tillämpar den.

Bara DevSecOps med ny fasad?

En rimlig skeptiker skulle stoppa mig här. Om Yellow Team helt enkelt är de människor som gör DevSecOps, vad har egentligen förändrats? Organisationer har haft ingenjörer för säker utveckling i ett decennium. Att kalla dem “gula” gör inte arbetet nytt.

Den skepsisen förtjänar ett ärligt svar, och det ärliga svaret är: i sig självt vore etiketten mycket riktigt gammalt vin i nya läglar. Det som gör detta ögonblick annorlunda är inte namnet, det är omfattningen av vad Yellow-team nu ombeds bygga för. Frontier-AI-modeller som Claude Mythos och GPT-5.5 kan hitta och kedja samman mjukvarusårbarheter snabbare än nästan något mänskligt team, och organisationer börjar först nu lista ut hur de ska rikta den förmågan i en användbar riktning snarare än en kaotisk. Den riktningen visar sig vara Yellow Team-arbete, och det ser inte alls ut som att skriva checklistor för säker kodgranskning.

Varför AI just ändrade kalkylen för byggare

Enligt Dark Readings rapportering ägnar ingenjörer på företag som Cisco, Microsoft, Cloudflare och Netskope nu sin tid åt att bygga “harnesses”: mjukvarukonstruktioner som exakt definierar vad en AI-modell får göra, vilka behörigheter den har och vilka skyddsräcken den måste respektera medan den jagar sårbarheter. En harness låter begränsande, men det är tvärtom. Utan en drunknar Red-team i falska positiva och fynd utan affärssammanhang; med en blir samma AI-modell genuint användbar för både angreppssimulering och försvar.

Netskopes CISO James Robinson beskriver precis detta mönster: modellen flaggade en intern endpoint som oautentiserad, tekniskt sant, men missade att den endpointen aldrig var nåbar från webben i första hand. Att ta sig från rå AI-output till något en mänsklig analytiker skulle lita på krävde en dedikerad ingenjörsinsats, inte en prompt.

Följdeffekten är att Blue och Yellow dras närmare varandra än de någonsin har varit. Som Zscalers Levi Bolourie uttrycker det: blue-team som inte använder AI för analys riskerar att drunkna i den enorma volym signaler som AI-assisterad red teaming nu producerar, och de två disciplinerna kommer som en följd att behöva integreras mycket tätare. Yellow-team är inte längre en stödfunktion som står tyst bakom Red och Blue. De är själva anledningen till att endera teamet överhuvudtaget kan hänga med.

Från ett system för dokumentation till ett system för handling

Det finns ett andra skifte som löper under allt detta, och det gäller långt bortom säkerhet. I två decennier har det mesta av företagsmjukvaran varit vad man i dag kallar ett “system of record”: en plats som lagrar vad som har hänt. Ditt CRM registrerar att en kund ringde. Din skanningsplattform registrerar att en sårbarhet finns. Användbart, nödvändigt och helt passivt.

Ett “system of action” gör något annat. I stället för att bara lagra vad som hände använder det den informationen för att avgöra vad som bör hända härnäst, och i allt högre grad, för att göra det. Grammarlys egen forskning om produktivitet på arbetsplatsen fann att 77 procent av yrkesverksamma känner sig överväldigade av den enorma mängd information de måste bearbeta, och 83 procent säger att de saknar verktygen för att faktiskt agera på det de vet. Det gapet mellan att ha data och att göra något användbart med den är precis vad ett system of action är tänkt att stänga.

Jag tänker gärna på det som skillnaden mellan en traditionell fyr och en som kunde styra sin egen stråle. En traditionell fyr är ett rent system of record: den markerar en fast, känd position, och det är upp till fartygets kapten att läsa ljuset, bedöma avståndet och välja kursen. Den anpassar sig inte efter fartyget framför sig. Föreställ dig nu en fyr som kunde spåra ett annalkande fartyg och aktivt omdirigera sin stråle för att varna just det fartyget, i just det ögonblicket, för den fara som är närmast det. Kaptenen seglar fortfarande fartyget. Men fyren har slutat vara en statisk markör och börjat vara en aktiv deltagare i att hålla det fartyget säkert.

Vi brukade ge partner en karta. Nu vill vi vägleda rutten.

En kort notering om positionering innan jag går vidare: Guardian360 är en oberoende mjukvaruleverantör. Vi utvecklar Lighthouse-plattformen: kontinuerlig skanning, efterlevnadsrekommendationer, tillgångsinventering, affärsmässig och teknisk riskvärdering. Vi driver inte något Security Operations Centre, vi utför inte manuell penetrationstestning eller incidenthantering, och vi säljer inte direkt till kunder. Det arbetet ligger hos våra partner, och det har det alltid gjort.

I åratal var det vi gav partner i praktiken en karta. Lighthouse visade var risken fanns, vad som behövde uppmärksamhet och ungefär hur brådskande det var. Att hitta den bästa rutten från den informationen till en given kundmiljö lämnades helt åt partnern. Det var rätt modell när själva kartan var den svåra delen att bygga. Det är en mer komplicerad modell nu när AI kan hjälpa till att generera inte bara kartan, utan ett genuint användbart nästa steg.

Under de kommande månaderna vill vi att Lighthouse ska röra sig längre från karta mot navigering: att inte bara visa partner var risken sitter, utan föreslå den bästa rutten för att hantera den, gång på gång, allteftersom omständigheterna förändras. Det är vad det faktiskt betyder för oss i praktiken att bygga ett system of action.

Det är värt att vara ärlig om, eftersom det väcker en uppenbar fråga för varje partner som läser detta: om plattformen börjar föreslå rutten, vad återstår då för föraren? Vårt svar är att partnern behåller kontrollen över bilen. Vi bygger inte verktyg för att skära ut partner ur arbetet; vi bygger dem för att ta de delar av arbetet som inte kräver ett mänskligt omdöme ifrån dem, så att de omdömesbeslut som verkligen kräver en människa får mer av deras uppmärksamhet, inte mindre. Partner håller i själva verket på att bli morgondagens Blue Team: de som beslutar, agerar och tar ansvar för utfallet, med stöd av ett Yellow Team som äntligen ombeds göra mer än att hålla lamporna tända.

Så, vilket team har du i tysthet varit?

Guardian360 var ett Yellow Team långt innan termen fanns, och jag misstänker att ett gott antal organisationer som läser detta kan säga detsamma om åtminstone en del av sin egen verksamhet. Frågan värd att stanna vid är inte om Yellow Teaming är en verklig kategori eller bara ett nytt varumärke. Den är vilket av dina team som har utfört detta arbete i bakgrunden i åratal, onämnt och underskattat, och om du är redo att ge dem verktygen, och uppmärksamheten, som detta ögonblick faktiskt kräver.

Källor