Bare Metal Cyber Insights

Security teams are usually outnumbered. There are more products, more features, and more platform changes than any central security group can realistically be part of. At the same time, engineering teams feel constant pressure to ship, and security can start to look like an outside force that only shows up late in the game to say no. This tension is familiar in many organizations and can make “one security team” feel permanently too small. This narration comes from my Tuesday “Insights” feature in Bare Metal Cyber Magazine, where we look at practical ways to change that picture.

One of the most effective patterns for stretching security’s reach without pretending you can hire endlessly is the idea of security champions in engineering teams. Instead of trying to place a security specialist in every standup and design review, you grow security-minded people inside product and platform squads and give them a clear, recognized role. The core security team still sets direction and handles complex analysis, but they are no longer the only ones keeping an eye on risk. Everyday engineers start to carry part of that responsibility in a structured way.

A security champion is, first and foremost, an engineer. They write code, work on infrastructure, or help run a platform just like their teammates. On top of that, they agree to take on a side responsibility: keeping security visible in planning, design, and delivery, and acting as a local bridge back to central security. This is not a product or a tool. It is a people and process pattern that inserts a security lens into the places where decisions are already being made.

In the broader environment, security champions sit where application development, platform engineering, and security governance meet. They are close enough to the code, pipelines, and configurations to understand how changes really happen. At the same time, they stay connected to the central security team so they can carry policies, standards, and preferred patterns back into daily work. You can imagine the security team as defining the map and the guardrails, while champions help translate those ideas into concrete choices on their own squads.

It also helps to be clear about what a security champion is not. They are not a way to push all security work onto engineers and walk away. They do not replace dedicated security experts, penetration testing, or formal reviews. They are not just a name added to a slide deck with no time, training, or recognition. When organizations treat the role that way, people burn out and the model quietly dies. A healthy approach gives champions support, clear expectations, and a real two-way channel with security leadership.

Day to day, the work of a security champion should feel woven into normal engineering routines. In sprint planning and refinement, they bring an extra lens, asking simple questions such as whether a story touches sensitive data or changes trust boundaries. When something feels higher risk, they know how to pull in the central security team. When it is more routine, they can point teammates to standard libraries, patterns, and controls the organization already trusts. Their goal is not to block progress, but to help teams see and address risk early instead of discovering it at the release gate.

Around that role, you build a few simple rhythms. Champions might join a recurring sync with central security and other champions to share what they are seeing, review a small set of metrics, and hear about new patterns or priorities. They often keep a lightweight list of security-related tasks in the team backlog, such as improving logging around sensitive actions, tightening an access control that keeps causing issues, or fixing recurring misconfigurations. None of this has to be heavy process, but it does need to be visible and supported.

A concrete example brings this to life. Imagine a product squad planning a new feature that touches payment data. During refinement, the security champion flags that this is a higher-risk area and pulls a simple threat modeling checklist the organization already uses. The team spends a few minutes talking through what could go wrong and agrees to adopt an existing encryption library, strengthen certain access rules, and add specific tests to the pipeline. The champion logs the feature for a focused review with central security and tracks those actions through the sprint. When release time arrives, the security conversation is calmer because the main concerns were handled early.

The value of security champions often shows up in small, everyday choices rather than big, dramatic moments. Teammates learn that when they are unsure about logging a new type of event or handling a new data flow, the champion is the first person to ask. Many questions can be resolved on the spot by pointing to existing standards instead of inventing something new. Over time, this reduces random, one-off security “solutions” and creates more consistency across services, which helps operations and security understand and support the environment.

Common situations where champions help include early review of stories or epics that change how data is handled, guiding the adoption of secure coding rules or secrets management tools, and coordinating a response when a new advisory affects their service. For the security team, it is far easier to work with a known contact in each squad than to chase down whoever happens to be on call. For engineers, it is easier to talk to a peer who understands their context than to engage with an unfamiliar central group for every small question.

For smaller or stretched organizations, the first step can be very modest. You might identify one or two squads that already have someone informally answering security questions and give that person a clearer role, a small slice of time, and a short orientation. You track just a couple of security improvements per sprint and a regular touchpoint with central security. As you gain confidence, you can build a more structured champions network with shared training, a simple charter, and visible executive support. In larger environments, that kind of network turns into a distributed extension of the security function.

When the model is working well, it creates leverage that a central team alone cannot achieve. Instead of a small number of specialists reviewing every feature, you have many engineers spotting issues earlier, nudging designs toward safer patterns, and catching small problems before they grow. The benefits are often subtle but important: fewer last-minute security surprises, fewer rushed fixes right before release, and a more constructive relationship between security and engineering. The central team gains room to focus on deeper analysis, threat modeling, and long-term improvements instead of being pulled into every minor decision.

There are trade-offs and costs. A champions program asks engineers to take on additional responsibilities, and that time has to come from somewhere. Managers need to recognize the work formally rather than expecting it to happen on top of full workloads. The program also needs structure, even if it is lightweight. Without a clear charter, simple expectations, and some coordination across teams, champions can end up isolated and inconsistent, with each squad defining its own idea of what security means. Budget for training and basic tools is often necessary so champions feel equipped rather than left to figure it out alone.

It is helpful to think of this as a deliberate exchange. You invest in people, coordination, and training up front so that later you see gains in quality, predictability, and speed. Security champions cannot fix broken leadership, unclear priorities, or missing processes. What they can do is amplify good patterns and help embed them in real delivery work. Organizations that get this right tend to track simple indicators over time, like how many teams have active champions, how often they meet with security, and how many issues are caught earlier in the lifecycle.

Because this is a people pattern, it also has predictable failure modes. One of the most common is the “voluntold” champion, where someone is quietly assigned the role but nothing else changes. They get no time, no training, and no backing from their manager. After a few months, they feel stretched and discouraged, and the rest of the team learns that security work is something people are given on top of everything else. Another failure mode is when central security offloads tasks to champions without providing guidance or support, turning them into unofficial extra hands rather than partners.

Shallow adoption is another risk. You might see chat channels and slide decks with the word “champion” on them, but daily work looks the same as before. Champions are not invited to early design conversations, their input does not influence decisions, and there is no regular cadence for them to share lessons with each other or with security. Over time, the title remains but the behavior fades, and the model becomes more of a label than a living practice.

Healthy signals are easier to recognize than you might expect. Security champions are present in key planning and design discussions, and their questions are respected. Teams can point to specific changes that came from champions’ input, such as clearer data flow diagrams, stronger secrets handling in pipelines, or better logging around sensitive actions. Central security knows who the champions are, meets with them regularly, and provides simple playbooks and updates rather than ad hoc requests. When a new risk appears, you hear more “we already accounted for that” and fewer “we had no idea this was coming” reactions.

At its heart, a security champions model is about making “one security team” bigger by growing security awareness and practical capability where work actually happens. Instead of trying to place an expert in every meeting, you cultivate trusted engineers who can translate security expectations into day-to-day choices and know when to pull in deeper expertise. The core team keeps its strategic role, and engineering gains a clearer, more approachable path to doing the right thing.

A useful next step is to look at your own product and platform teams and ask where a well-supported champion could have the most impact. You may already have people informally filling that role. Giving them recognition, a bit of time, and a stronger connection to central security can turn that informal behavior into a lasting pattern. Over time, these small moves can shift security from a distant gate at the end of delivery to a shared habit across engineering, which is exactly what a good security champions program is meant to deliver.