Next week, we’re looking forward to bringing together the amazing speakers, attendees and sponsors of DevSecCon24 to discuss, debate and understand how a Security Champions programme can work. As Snyk’s Field CTO, I’ll be leading a panel with stellar DevSecOps leaders from Twilio, Atlassian and Pearson to delve into how to get started, the challenges and the fine-tuning. Here’s a taster of where the discussion might lead.
The concept of a Security Champions program is quickly gaining traction within DevOps and DevSecOps, as organisations look for new ways to bridge the gap between Development, Ops and Security, to ultimately create software that’s secure by design. But a Champions program isn’t something that can be rushed into if it is to achieve long-term success. There needs to be careful planning and strategic thinking. It’s crucial that security teams lay solid foundations, choose the right champions, define their role, as well as the role of the program, and roll it out organically and as slowly as it needs to be.
Laying solid foundations
The first step of building a Security Champions program is defining why you want one in the first place. Setting up a program isn’t about keeping up with other companies, or because you read an article saying you should; it’s about fixing specific security problems, unique to your organisation. Identify the security challenges within your own organisation and make fixing them the goal.
Many organisations approach a Champions program from the security perspective, but if you want to get your developers on board and engaged, then you need to show them how the program is valuable to them in terms of eliminating pain points. I find an effective question is asking the developer team ‘if they could change one thing in their role, what would it be?’ This cuts to the heart of their issues and gives you a solid foundation to start building out your Security Champions program.
However, it’s support as well as strategy that’s critical for a successful Security Champions program. Executive sponsorship is paramount: the majority of organisations I’ve spoken to that have launched programs without executive level support, ultimately saw them fail. No program is ever going to succeed in the long-term if the C-suite sees it as a waste of time.
Choosing your Security Champions
A great deal rests on the people you choose to be Security Champions: get it right and your developer and security teams can work seamlessly together; get it wrong and you’re introducing more confusion and frustration. Your Security Champions should be people who are naturally interested in security and are developers who actively contribute to their teams.
Typically, programs will have one Security Champion per engineering team, or group of teams, as this gives the security department visibility of the entire organisation and an in-depth understanding of the way risk is manifested within it. Security Champions will be partnered with a security mentor or coach from the security team and they will jointly work to resolve issues and increase the security maturity of engineering teams.
Opinion is divided on whether developers should volunteer to be Security Champions or whether this should be decided by management. But, from my experience, it’s best if the position is filled voluntarily, even if one champion per team is mandated. That way you find someone who’s genuinely passionate about security and won’t be resentful about their expanded role. It can be a great professional opportunity for them, too, and a chance to pursue new interests. Within Snyk itself, one of our engineers became a Security Champion and ultimately went on to join our security team.
The role of a champion
Let’s be clear – the role of a Security Champion is to act as a conduit between developer and security teams, not to be a security expert themselves. Though they should be security curious, they are not expected to magically fix all issues. Instead, their job is to provide visibility and to keep both sides focused on achieving security goals, within a time frame, and work out the practical steps needed to achieve this.
However, the specifics of a Security Champion’s role still needs to be clearly defined within your organisation. When a developer sees a Security Champion they need to be crystal clear on what the role is and what those individuals do.
Champions can be supported in their role with regular meetings with other champions and with the security team, allowing them to discuss any issues, assisting in their development and encouraging them within their role. Encouragement can – and should – also be provided in the form of recognition and rewards, which also help drive further Security Champion recruitment.
Rolling out the program
Although the overall goal is company-wide coverage, the rollout of a Security Champions program should start small. Get a program working smoothly and successfully with a few teams and then you can start to expand. Start with teams that are working on higher priority areas, who experience the highest risk, and teams that are mature in security practices and so have a solid foundation to build from.
The key to a successful rollout is to do it organically and slowly. But how do you know when to expand the program to more teams? The answer to this is, if the security team is in a position to support further teams and if the program is going successfully. But this leads to another question: what does success look like?
Measuring success is difficult, but it is possible – and security teams should be looking at both qualitative and quantitative data. How well is the program being adopted by engineering teams, and how well are the champions’ recommendations being implemented? Are champions active, filling out their scorecards and meeting the goals they set themselves?
Talk to developer teams and see if they can tell you about any changes to their processes – for example, from a certain date have they always done threat modelling, reduced backlog or added automated testing of a particular feature throughout their pipeline.
Numbers are of course useful too (you can see if the backlog of vulnerabilities is reducing or, if your organisation works with timesheets, you can check if a champion is spending the agreed amount of time on security tasks) but you should be careful of numbers without context. A team with a low number of vulnerabilities may not necessarily be more secure than one with a higher number – they may just be running fewer or less stringent security checks.
A Security Champions program is an important way organisations can grow in security maturity, reduce vulnerabilities and embed security into every level of their work. But it takes work and time. If an organisation wants to launch a program that lasts they need patience to achieve the organic, slow growth that underlies success.
For more information on the best practices and pitfalls of running Security Champions programs, register for free to attend DevSecCon24, taking place 23rd-24th June.
Editor’s note: This article is in association with Snyk.
(Photo by Nik Shuliahin on Unsplash)
