Guardian360
Start free trialBecome a partner
← All posts

Opinion

Yellow Teaming: Buzzword or Breaking Point?

By Jan Martijn Broekhof ·

I had never heard the term “Yellow Team” until I read a recent Dark Reading piece on AI and security. By the end of the second paragraph, I realised something slightly uncomfortable: Guardian360 has quietly been one for years, and nobody, including me, ever bothered to call it that.

For a long time, that did not matter much. Building the tools that Red and Blue teams use was seen as commodity work: necessary, unglamorous, rarely the subject of a conference talk. Attackers got the drama. Defenders got the credit for holding the line. The people who built the platforms underneath both of them got a line item in the budget. AI is changing that calculation, and it is worth understanding why, and what it means for how Guardian360 works with its partners.

What exactly are Red, Blue and Yellow Teams, and where does DevSecOps fit?

The colour vocabulary in cybersecurity is older than most people assume. Red Team refers to the people who simulate attacks: penetration testers, ethical hackers, the ones paid to break in before someone with worse intentions does. Blue Team refers to the defenders: the analysts and engineers who detect, respond to and recover from those attacks. Yellow Team sits underneath both. It is the group that designs, builds and maintains the systems, applications and tooling that Red and Blue actually operate on and with.

This distinction was first proposed at Black Hat in 2017, when a colour wheel was introduced to map the different functions inside security work beyond the familiar red-versus-blue framing, as security researchers at Retest Security have since documented in their own history of the framework. Yellow was defined as the builders: architects, developers and engineers responsible for secure systems from the ground up, rather than the people attacking or defending them after the fact.

DevSecOps is not a separate colour on that wheel. It is the practice Yellow Teams use to do their job: folding security into the development pipeline itself, so that vulnerabilities get caught at the point of creation rather than discovered later by Red or cleaned up later by Blue. DevSecOps is the method. Yellow Team is the group of people applying it.

Just DevSecOps with a new coat of paint?

A fair sceptic would stop me here. If Yellow Team is simply the people doing DevSecOps, what has actually changed? Organisations have had secure-development engineers for a decade. Calling them “yellow” does not make the work new.

That scepticism deserves an honest answer, and the honest answer is: on its own, the label would indeed be old wine in a new bottle. What makes this moment different is not the name, it is the scale of what Yellow Teams are now being asked to build for. Frontier AI models such as Claude Mythos and GPT-5.5 can find and chain software vulnerabilities faster than almost any human team, and organisations are only beginning to work out how to point that capability in a useful direction rather than a chaotic one. That pointing, it turns out, is Yellow Team work, and it looks nothing like writing secure code review checklists.

Why AI just changed the maths for builders

According to Dark Reading’s reporting, engineers at companies including Cisco, Microsoft, Cloudflare and Netskope are now spending their time building “harnesses”: software constructs that define exactly what an AI model is allowed to do, which permissions it has, and which guardrails it must respect while hunting for vulnerabilities. A harness sounds restrictive, but it is the opposite. Without one, Red teams get overwhelmed by false positives and findings stripped of business context; with one, the same AI model becomes genuinely useful for both attack simulation and defence.

Netskope’s CISO James Robinson describes exactly this pattern: the model flagged an internal endpoint as unauthenticated, technically true, but missed that the endpoint was never reachable from the web in the first place. Getting from raw AI output to something a human analyst would trust took a dedicated engineering effort, not a prompt.

The knock-on effect is that Blue and Yellow are being pulled closer together than they have ever been. As Zscaler’s Levi Bolourie puts it, blue teams that do not use AI for analysis risk being overwhelmed by the sheer volume of signals AI-assisted red teaming now produces, and the two disciplines will have to integrate far more tightly as a result. Yellow Teams are no longer a support function standing quietly behind Red and Blue. They are the reason either team can keep up at all.

From a system of record to a system of action

There is a second shift running underneath all of this, and it applies well beyond security. For two decades, most enterprise software has been what people now call a “system of record”: a place that stores what has happened. Your CRM records that a customer called. Your scanning platform records that a vulnerability exists. Useful, necessary, and entirely passive.

A “system of action” does something different. Instead of only storing what happened, it uses that information to decide what should happen next, and increasingly, to do it. Grammarly’s own research into workplace productivity found that 77 percent of professionals feel overwhelmed by the sheer volume of information they have to process, and 83 percent say they lack the tools to actually act on what they know. That gap between having data and doing something useful with it is exactly what a system of action is meant to close.

I like to think of it as the difference between a traditional lighthouse and one that could steer its own beam. A traditional lighthouse is a pure system of record: it marks a fixed, known position, and it is up to the ship’s captain to read the light, judge the distance and choose the course. It does not adjust for the ship in front of it. Now imagine a lighthouse that could track an approaching vessel and actively redirect its beam to warn that specific ship, at that specific moment, about the danger closest to it. The captain still sails the ship. But the lighthouse has stopped being a static marker and started being an active participant in keeping that ship safe.

We used to hand partners a map. Now we want to guide the route.

A short note on positioning before I go further: Guardian360 is an independent software vendor. We develop the Lighthouse platform: continuous scanning, compliance recommendations, asset inventory, business and technical risk scoring. We do not run a Security Operations Centre, we do not perform manual penetration testing or incident response, and we do not sell directly to customers. That work sits with our partners, and it always has.

For years, what we handed partners was, in effect, a map. Lighthouse showed where the risk was, what needed attention, and roughly how urgent it was. Finding the best route from that information to a fixed customer environment was left entirely to the partner. That was the right model when the map itself was the hard part to build. It is a more complicated model now that AI can help generate not just the map, but a genuinely useful next step.

Over the coming months, we want Lighthouse to move further from map towards navigation: not just showing partners where the risk sits, but proposing the best route to deal with it, again and again, as circumstances change. That is what building a system of action actually means for us in practice.

This is worth being honest about, because it raises an obvious question for every partner reading this: if the platform starts proposing the route, what is left for the driver? Our answer is that the partner stays in control of the car. We are not building tooling to cut partners out of the work; we are building it to take the parts of the work that do not need a human judgement call off their hands, so the judgement calls that do need a human get more of their attention, not less. Partners are, in effect, becoming the Blue Team of tomorrow: the ones who decide, act and take responsibility for the outcome, supported by a Yellow Team that is finally being asked to do more than keep the lights on.

So, which team have you quietly been?

Guardian360 was a Yellow Team long before the term existed, and I suspect a good number of organisations reading this can say the same about at least one part of their own operation. The question worth sitting with is not whether Yellow Teaming is a real category or just a rebrand. It is which of your teams has been doing this work in the background for years, unnamed and under-credited, and whether you are ready to hand them the tools, and the attention, that this moment actually requires.

Sources