This is the sixth post in SAFECode’s Month of Champions series on building and sustaining a successful Security Champions program.

Part One: Start 2019 Strong: Join SAFECode for Our Month of Champions
Part Two: Building Secure Software: It Takes a Champion
Part Three: Putting a Face to Software SCs
Part Four: How to Build an Effective Security Champions Program
Part Five: Warning: Six Signs Your Security Champions Program is in Trouble
Also check out our podcast discussion with the series authors on the importance of Security SCs here.


By Vishal Asthana, Security Compass (former) with Manuel Ifland, Siemens

“Yes – I understand the need for a Security Champions Program and have built a program strategy that has executive management support. Now what? Are there recommended approaches towards rolling things out? Any pitfalls to avoid?”

This post will cover how to roll out a Security Champions (SC) program in a sustainable way. As you can imagine, kicking off the program with a huge disruption to engineering’s workflow will not help repair security’s reputation as an obstacle. So, a thoughtful kick-off is key to successful program adoption.

First, consider using to some sort of change management framework (e.g. Kotter’s Eight Steps to Change, Kubler-Ross Five Stage Model, Prosci’s ADKAR Model) from the start to help guide implementation.

Second, we highly recommend starting an SC program with a Pilot phase. In other words, roll out the program with a distinct team of people within an organization without affecting the rest of the organization. Such a pilot would establish if the program works as planned and if so, strengthen the case for buy-in by management. Other important advantages of the pilot are to adapt the planned program to the actual working culture of the enterprise and to establish if scaling is possible or if things need to be tweaked to enable it. Usually, a smaller (yet important) development team should be selected for running the pilot program.

In addition to management support, getting buy-in from each of the pilot program team members is key to making an SC Program pilot successful. Compare it to quitting smoking. If someone does not actually want to quit smoking, registering them for a quit-smoking program does not really make sense. The same applies to the pilot – it is important that the piloting team is open to it and wants to get help in integrating security into their processes.

Rolling out a SC Program enterprise-wide says a lot about an organization’s seriousness about building a security culture. But the job doesn’t stop there! After an SC Program has been launched enterprise-wide, it is equally important to take measures to sustain it. For example, one of our series contributors once worked with a large financial institution that onboarded 160 SCs to their program a few years back. That is a great feat and big accomplishment. Unfortunately, they did not build an ecosystem to sustain their SC program, and eventually found that the designated SCs were not actively engaged within their teams and with the central security team. Therefore, even this promising program start led to little/no change to the overall security culture within the organization.

In order to prevent similar disappointment and sustain an SC Program, building a supporting ecosystem is key. In large enterprises, the central security team typically plays a crucial role in building this ecosystem. In smaller enterprises, the designated SCs might need to self-organize in order to accomplish the same objective. A list of commonly used tactics to achieve this objective are being listed below:

  • Build an SC Cohort: Start with having a common mailing list (or a communication tool the engineers like and are used to) for all designated SCs to share important announcements on the SC Program, AppSec in general, etc. This also tends to create a sense of belonging to a cause. In parallel, build and regularly update a central AppSec Wiki for to help ease knowledge-sharing. Organize a recurring meeting of SCs on a periodic basis, say monthly. Use such meetings to recognize specific efforts of SCs and reemphasize the SC charter, especially highlighting how SCs fit in the AppSec wheel.
  • Socializing Software Security across the development team: Regularly socialize the concept of Application Security at all levels in a development team, not just at an individual developer-level. This is achievable through brown bag lunch-and-learn sessions, scheduled open hours with AppSec Subject Matter Experts “SMEs”, open hour sessions to discuss “anything security,” and similar events. During such sessions, encourage the designated SC in a team to drive or lead the effort. This would help “build up” the SC’s image as the resident AppSec SME.
  • Make security fun, not just a heads-down activity: Gamification in the form of hackathons typically helps achieve this objective. Have the designated SC lead in organizing such exercises on a periodic basis.
  • Train-the-trainer mindset: The SCs’ role should gradually evolve from being pure tactical security guides to acting as coaches who train developers so that they can tackle things on their own, reaching out for additional clarification or unresolved topics when needed. In the absence of this gradual cultural shift, security will continue to be viewed as someone else’s job (in this case an SC) instead of collective accountability of every developer.

In summary, using established change management processes and launching the program with a pilot to identify and correct any problems early (and avoid serious disruption) will help an SC program start on a positive note. To sustain that success, SC programs need ongoing care and feeding to socialize security awareness, build a security-supportive culture, and evolve the program to keep up with changing business needs. So how do you know if it is working? Check back for the final post in our series, which will discuss SC program metrics.