---
title: "Yellow Teaming: buzzword eller vendepunkt? | Guardian360"
description: "Guardian360 har stille og roligt været et Yellow Team i årevis: bygherrerne bag Red og Blue. AI ændrede lige regnestykket for bygherrer, og det er grunden til, at vi vil have Lighthouse til at gå fra at række partnere et kort til at guide ruten."
url: https://guardian360.net/da/blog/yellow-teaming-buzzword-or-breaking-point/
locale: en
source: guardian360.net
---
[← Alle indlæg](https://guardian360.net/da/blog/)

Holdning

# Yellow Teaming: buzzword eller vendepunkt?

Af Jan Martijn Broekhof · 15. juli 2026

Jeg havde aldrig hørt udtrykket “Yellow Team”, før jeg læste et nyligt Dark Reading-stykke om AI og sikkerhed. Ved slutningen af andet afsnit indså jeg noget en smule ubehageligt: Guardian360 har stille og roligt været et i årevis, og ingen, heller ikke jeg, gad nogensinde kalde det det.

I lang tid betød det ikke så meget. At bygge de værktøjer, som Red- og Blue-teams bruger, blev set som commodity-arbejde: nødvendigt, uglamourøst, sjældent emnet for et konferenceoplæg. Angriberne fik dramaet. Forsvarerne fik æren for at holde stillingen. De mennesker, der byggede platformene under dem begge, fik en linje i budgettet. AI er ved at ændre det regnestykke, og det er værd at forstå hvorfor, og hvad det betyder for, hvordan Guardian360 arbejder med sine partnere.

## Hvad er Red-, Blue- og Yellow-teams egentlig, og hvor passer DevSecOps ind?

Farvevokabularet i cybersikkerhed er ældre, end de fleste antager. Red Team refererer til de mennesker, der simulerer angreb: penetrationstestere, etiske hackere, dem der får betaling for at bryde ind, før nogen med værre hensigter gør det. Blue Team refererer til forsvarerne: de analytikere og ingeniører, der opdager, reagerer på og genopretter efter disse angreb. Yellow Team sidder under dem begge. Det er den gruppe, der designer, bygger og vedligeholder de systemer, applikationer og værktøjer, som Red og Blue faktisk opererer på og med.

Denne skelnen blev første gang foreslået på Black Hat i 2017, da et farvehjul blev introduceret for at kortlægge de forskellige funktioner inde i sikkerhedsarbejde ud over den velkendte rød-mod-blå-ramme, som sikkerhedsforskere hos Retest Security siden har dokumenteret i deres egen historie om framework’et. Yellow blev defineret som bygherrerne: arkitekter, udviklere og ingeniører, der er ansvarlige for sikre systemer fra bunden, snarere end de mennesker, der angriber eller forsvarer dem bagefter.

DevSecOps er ikke en separat farve på det hjul. Det er den praksis, Yellow-teams bruger til at gøre deres arbejde: at folde sikkerhed ind i selve udviklingspipelinen, så sårbarheder bliver fanget ved skabelsespunktet snarere end opdaget senere af Red eller ryddet op senere af Blue. DevSecOps er metoden. Yellow Team er den gruppe mennesker, der anvender den.

## Bare DevSecOps med et nyt lag maling?

En rimelig skeptiker ville standse mig her. Hvis Yellow Team simpelthen er de mennesker, der laver DevSecOps, hvad har så egentlig ændret sig? Organisationer har haft secure-development-ingeniører i et årti. At kalde dem “gule” gør ikke arbejdet nyt.

Den skepsis fortjener et ærligt svar, og det ærlige svar er: alene ville etiketten faktisk være gammel vin på nye flasker. Det, der gør dette øjeblik anderledes, er ikke navnet, det er omfanget af det, Yellow-teams nu bliver bedt om at bygge til. Frontier-AI-modeller som Claude Mythos og GPT-5.5 kan finde og kæde softwaresårbarheder sammen hurtigere end næsten ethvert menneskeligt team, og organisationer er kun lige begyndt at finde ud af, hvordan de peger den kapacitet i en nyttig retning snarere end en kaotisk. Den udpegning viser sig at være Yellow Team-arbejde, og det ligner overhovedet ikke at skrive tjeklister til sikker kodegennemgang.

## Hvorfor AI lige ændrede regnestykket for bygherrer

Ifølge Dark Readings rapportering bruger ingeniører hos virksomheder som Cisco, Microsoft, Cloudflare og Netskope nu deres tid på at bygge “harnesses”: softwarekonstruktioner, der definerer præcis, hvad en AI-model har lov til at gøre, hvilke tilladelser den har, og hvilke guardrails den skal respektere, mens den jager sårbarheder. En harness lyder begrænsende, men det er det modsatte. Uden en bliver Red-teams overvældet af falske positiver og fund, der er strippet for forretningskontekst; med en bliver den samme AI-model reelt nyttig til både angrebssimulering og forsvar.

Netskopes CISO James Robinson beskriver præcis dette mønster: modellen markerede et internt endpoint som ikke-autentificeret, teknisk sandt, men overså, at endpoint’et aldrig var tilgængeligt fra nettet i første omgang. At komme fra rå AI-output til noget, en menneskelig analytiker ville stole på, krævede en dedikeret ingeniørindsats, ikke en prompt.

Følgevirkningen er, at Blue og Yellow bliver trukket tættere sammen, end de nogensinde har været. Som Zscalers Levi Bolourie udtrykker det, risikerer blue-teams, der ikke bruger AI til analyse, at blive overvældet af den rene mængde af signaler, som AI-assisteret red teaming nu producerer, og de to discipliner bliver nødt til at integrere langt tættere som følge heraf. Yellow-teams er ikke længere en støttefunktion, der står stille bag Red og Blue. De er grunden til, at nogen af teamene overhovedet kan følge med.

## Fra et system of record til et system of action

Der er et andet skift, der løber under alt dette, og det gælder langt ud over sikkerhed. I to årtier har det meste virksomhedssoftware været, hvad folk nu kalder et “system of record”: et sted, der gemmer, hvad der er sket. Dit CRM registrerer, at en kunde ringede. Din scanningsplatform registrerer, at en sårbarhed findes. Nyttigt, nødvendigt og fuldstændig passivt.

Et “system of action” gør noget andet. I stedet for kun at gemme, hvad der skete, bruger det den information til at beslutte, hvad der bør ske næste gang, og i stigende grad til at gøre det. Grammarlys egen forskning i arbejdspladsproduktivitet fandt, at 77 procent af fagfolk føler sig overvældet af den rene mængde information, de skal behandle, og 83 procent siger, at de mangler værktøjerne til faktisk at handle på det, de ved. Det gab mellem at have data og at gøre noget nyttigt med dem er præcis det, et system of action er ment at lukke.

Jeg kan lide at tænke på det som forskellen mellem et traditionelt fyrtårn og et, der kunne styre sin egen stråle. Et traditionelt fyrtårn er et rent system of record: det markerer en fast, kendt position, og det er op til skibets kaptajn at læse lyset, bedømme afstanden og vælge kursen. Det tilpasser sig ikke skibet foran det. Forestil dig nu et fyrtårn, der kunne spore et fartøj, der nærmer sig, og aktivt omdirigere sin stråle for at advare netop det skib, i netop det øjeblik, om den fare, der er tættest på det. Kaptajnen sejler stadig skibet. Men fyrtårnet er holdt op med at være en statisk markør og begyndt at være en aktiv deltager i at holde det skib sikkert.

## Vi plejede at række partnere et kort. Nu vil vi guide ruten.

En kort note om positionering, før jeg går videre: Guardian360 er en uafhængig softwareleverandør. Vi udvikler Lighthouse: løbende scanning, compliance-anbefalinger, aktivopgørelse, forretnings- og teknisk risikoscoring. Vi driver ikke et Security Operations Centre, vi udfører ikke manuel penetrationstest eller hændelsesreaktion, og vi sælger ikke direkte til kunder. Det arbejde ligger hos vores partnere, og det har det altid gjort.

I årevis var det, vi rakte partnere, reelt et kort. Lighthouse viste, hvor risikoen var, hvad der krævede opmærksomhed, og nogenlunde hvor presserende det var. At finde den bedste rute fra den information til et fast kundemiljø blev overladt helt til partneren. Det var den rette model, da kortet selv var den svære del at bygge. Det er en mere kompliceret model nu, hvor AI kan hjælpe med at generere ikke bare kortet, men et reelt nyttigt næste skridt.

I de kommende måneder vil vi have Lighthouse til at bevæge sig længere fra kort mod navigation: ikke bare vise partnere, hvor risikoen sidder, men foreslå den bedste rute til at håndtere den, igen og igen, efterhånden som omstændighederne ændrer sig. Det er, hvad det faktisk betyder for os i praksis at bygge et system of action.

Dette er værd at være ærlig om, fordi det rejser et åbenlyst spørgsmål for hver partner, der læser dette: hvis platformen begynder at foreslå ruten, hvad er der så tilbage til føreren? Vores svar er, at partneren forbliver i kontrol over bilen. Vi bygger ikke værktøjer for at skære partnere ud af arbejdet; vi bygger dem for at tage de dele af arbejdet, der ikke kræver en menneskelig vurdering, af deres hænder, så de vurderinger, der faktisk kræver et menneske, får mere af deres opmærksomhed, ikke mindre. Partnere bliver reelt morgendagens Blue Team: dem, der beslutter, handler og tager ansvar for resultatet, understøttet af et Yellow Team, der endelig bliver bedt om at gøre mere end at holde lyset tændt.

## Så hvilket team har du stille og roligt været?

Guardian360 var et Yellow Team længe før udtrykket eksisterede, og jeg formoder, at et godt antal organisationer, der læser dette, kan sige det samme om i det mindste én del af deres egen drift. Spørgsmålet, der er værd at dvæle ved, er ikke, om Yellow Teaming er en reel kategori eller bare en rebranding. Det er, hvilket af dine teams der har lavet dette arbejde i baggrunden i årevis, unavngivet og underkrediteret, og om du er klar til at række dem de værktøjer, og den opmærksomhed, som dette øjeblik faktisk kræver.

## Kilder

- Nate Nelson, “‘Yellow Teams’ Are Defining the Future of AI Security”, Dark Reading, 13. juli 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/)