Setting a structure

It’s important to start off by clearly understanding the specific need that your teams have and the pain points your teams are going through before designing your security champions program. Every organization has a different culture that you should try to create a security champions program around. Avoid copy-pasting the exact same program someone else is successfully running, but rather, try to find gems of advice and best practices that you can apply that you feel would work with your teams and culture as well.

A security champions program consists of security champions, who are typically contributing developers on the engineering team with domain specific knowledge. A good security champion is often someone who is generally interested in security, but ultimately a developer. It’s clearest when you have one security champion per development team or group or teams — depending on your development team structure and how much interaction they have with developers in those teams — although sometimes programs allow multiple developers per team to join. This reduces the clarity around who one should reach out to if they need help, but also reduces the bottlenecks.

Volunteer champions

Ideally, a developer should become a security champion voluntarily, rather than have the role forced upon them. Many companies that want coverage across all their development teams will mandate that every team should have representation in the program, but it’s down to the team and developers to decide between them who should join.

You might want to suggest the types of developers you feel would fit well in the program based on the activities and authority they will need. In our discussions, some organizations required a senior developer, while others encouraged developers of any experience to be a part of the program. By relying solely on volunteers will more likely provide you with a program with people who genuinely want to be a part of the group, however, this may come at the expense of a lack of coverage across your organisation.  

Security representation

The security team will also have representation in the program as security coaches or mentors. A security coach would typically have a one-to-many relationship with a number of security champions, which will naturally match the parts of the organization that they are responsible for in the security team.

The role of a security champion isn’t necessarily to do the security work themselves. In many organizations, they are responsible for making sure that practices and procedures are followed but it could be that others in the team go ahead and do the work themselves. We’ll cover more about the security activities a little later.

Clearly defined activities

In every discussion we had with folks who ran these programs, the recurring theme of simplicity and clarity of activities came up time and time again. When deciding which activities to focus on, start with just one or two activities that you want your champions to focus on, and be explicit about what they or their team need to accomplish (program documentation is key). As the program grows, more can be added, but starting small and making it obvious what you want your champions to do is crucial.

Clearly defined roles and responsibilities

Equally important is providing clarity around the roles, what they mean and what people can expect from each other. Most programs didn’t restrict anyone from talking to anyone else, but encouraged discussion between champions between teams, a champion and their team, and a champion and their security coach. These are important relationships that need to be nurtured and built up with trust, reliability and expertise for them to function well.

Clearly defined cadence

How often your groups meet is up to you, but a monthly cadence for all champions to meet on call is common across organizations. Pre-COVID, an annual or 6-month in-person meetup was also done by some organizations, partly as a reward and to grow that belonging and membership and partly as a good way to share knowledge and experiences. These meetings do need structure and expectation, so do need to have ownership and a thought out plan over the months.

Program management

A recurring pitfall which led to a security program failing is the lack of program management. For large organisations with hundreds of security champions, this could be a dedicated person, but for smaller organizations someone should still own it. This role needs to look after the logistics of the program, including membership, responsibilities, accountability, rewards and recognition, as well as ensuring regular cadence meetings are well structured and inline with the program goals.

Rewards and recognition

Everyone is different when it comes to what they see as good rewards or recognition for being in a security champions program. Some may not want any, and really just want to level up their knowledge or have an interest in being a part of a champion group (knowledge is the best reward). Others see security as a potential career path and this is a good way of taking a small step into that world. The majority look to other perks, such as physical meetups, as discussed earlier, or tickets to security conferences like DefCon or Black Hat. Internal recognition such as mentions by your VP, which is seen by management teams, or an internal company conference can also act as a good advert for the program. Finally, t-shirts or hoodies are sometimes all people want to feel that belonging or association with the group. Check the pulse of your team to determine the best way to show your appreciation for their involvement.

Measurable goals

The most common education programs were a mix of internal and external training and sharings that also fed into a belt system. You may want to have KPIs/expectations that you have a certain number of people working in critical areas of application development in particular belts. For example if you have a business critical service that interacts heavily with sensitive data, you might want to ensure you have a brown/black as a champion in that team. Similarly, for those areas with very low risk, you would have less concern if you didn’t have more in depth levels of security training among those champions and teams. Belts are awarded based on certifications, completing training, hours of security work, advocating and sharing team projects and success and more.