Security champions overview

What is a security champion?

A security champion is a developer that formally represents an engineering team. They are someone who will engage directly with the security team, and is responsible for bridging the dev-security gap. Their duties can include, but are not restricted to, educating the engineering team in secure development, adding and improving security checks in the developer workflow, questioning where engineering team decisions are not including security, giving the security team visibility into the practices and state of the development team they are in, and much more.

What is a security champions program?

A security champions programs bridge the gap between security and development teams. Both of these teams want to deliver secure applications at the speed that the business demands, but traditionally, security practices are added into the SDLC without scaling knowledge and practices through development teams. This creates security gates, automated or manual, that cause developer rework, frustration, and a slower overall product delivery.

In practice, we need the in-depth expertise from the security team to be paired with the development organization’s breadth and practices to allow them to continue to deliver software rapidly and securely. Security champions are the perfect way to fill this need, acting as an effective mechanism for communication, knowledge sharing, and collaboration between the two teams. 

Security champions are developers with an interest in security and a home in development. They are the interface between two teams that have traditionally been siloed. Let’s take a look at some of the benefits any organization can gain from these programs.

Top benefits of starting a security champions program

Different teams will have different motivations and benefits they will want to gain from a security champions program. As mentioned earlier, a shared goal between development and security teams is to reduce issues and overall risk of the applications they’re responsible for. The development teams can use this as a platform for education and advice, while the security team enjoy the visibility, amplification, and scaling this platform provides.

Here are the top four most common reasons the teams gave for why they wanted a security champions program:

1. To have a focal point in the development team for training and educating the wider team. The goal of making development teams more self-sufficient and autonomous can only be achieved with knowledge and understanding. With security, it’s important that secure development techniques are recognized and understood throughout the development teams. Having engineers teach engineers is a much more successful approach to growing that knowledge and education.

2. Scale the security team non-linearly within the organization.It’s common that for every 100 engineers, there will be 10 operations-like roles and a single security person to support them all. The only way to scale secure development is through the engineering organization by having the security team empower and support developers.

3. Improve oneself to be a better, more well-rounded developer (possibly for career growth).For many developers that are naturally security curious, they may just want to learn more and level up their security knowledge and practices. For some this might lead into a possible career in the security space.

4. Increase security influence earlier in the cycle to build security in rather than bolt it on.A common cause of pain for developers is when security practices are left till the end of a feature release or development cycle. When security practices are added at the end of a development cycle, it’s more frustrating and time consuming, rather than well-thought through. Security should be considered at each phase, including design.

To help you build your own application security champions program, we will use real world experiences from many different organizations of various sizes, maturities, and verticals to share their best practices that you may want to follow and some pitfalls you’ll want to avoid when designing, creating, and running your own.

Security champions programs are developer-focused

When thinking about the needs of your teams, be sure to keep in mind that while programs like this are typically run and supported by the security team, the goals, pain points, and needs of the developer should be put first. If you do not prioritize the needs of your development teams, you will not achieve organic developer adoption and participation, which will limit the program’s effectiveness significantly.

Ask your developers what they want from the program, what they’re struggling with in their day to day job, and how you can add value to their roles to make their jobs easier and help them achieve their goals. Thinking about how you can support and empower developers and teams through the program will allow you to see the value from a member point of view, not just as a program owner or administrator.

It’s important to make a distinction between a security champions program and a security community. A security community is a place for security curious individuals to share, learn and improve their security knowledge. By contrast, a security champions program is an organizationally approved way to scale security practices and embed them into the dev organization

Security champions programs need executive sponsorship

When you’re getting started, a pitfall to avoid is rolling out and running a security champions program without executive support from both the security and engineering groups. This support empowers practitioners to spend their time on the program and its activities, knowing that it is important and recognized by the management teams.

The typical executive sponsors on the security side are in the role of CISO, Security VP, or Director of Product Security, while on the engineering side it’s CTO or SVP of Engineering. This tends to be based on the organizational structure of the companies. The key is that the program is agreed to by both parties and this is communicated down into teams, scrum masters, management, etc.

Per our discussions, the timing of when this sponsorship was agreed upon varied, but it was found to be most effective at the very beginning or after a small pilot with a few teams. It’s important to share the problems the program is trying to solve, as well as to clearly state the activities and responsibilities that will be required. This can include time commitments, if you choose to be explicit about how much time a champion should be spending on security.

With executive sponsorship, backed up by local management understanding, a champion will be happy to reduce their other deliverables to take on the security work because they know that they will not be penalized for shifting their responsibilities (in their performance review, for example).