Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Scaling DevSecOps: Take a page from the Security Champions Playbook

Alexander Antukh Head of Product Security, Opera Software

Security. Champions. Playbook. If you've never heard this combination of terms, your confusion is understandable. Who are the champions? What value can they bring? Do you need one? How do you build a team of champions in your organization?

Where champions can help

Imagine that you are responsible for establishing mature security processes across an organization. Multiple teams are working on various products and services, using different technologies. Some teams might take an agile approach, some use good old Kanban, some rely on ad hoc security activities, and still others believe security is good enough already.

At this point, you start to read documentation, learn about release calendars, propose certain central knowledge and best practices and … in just a couple of weeks you're completely drowned. You're having problems all around and trying to stick to the strategy while being almost fully engaged with tactical firefighting.

Sound familiar?

It is obvious you won't be able to win this battle alone. You may get reinforcements from the central security team, depending on the allocated budget, but it still won't be enough if we’re talking about 10 or more different teams and a lack of security culture. That's exactly the sort of situation where the champions can come to the rescue!

According to the Open Web Application Security Project (OWASP), security champions are "active members of a team that may help to make decisions about when to engage" the security team. They act as a core element of security assurance process within the product or service and are the single point of contact within the team.

So how do you build an effective team of security champions? Here are six steps to follow.


1. Identify teams

The first step in starting your own security champions program is to map all the existing teams you will be working with. Since we're aiming to achieve better coverage and spread of security, it's extremely important to write all this down and keep the document in a publicly known and accessible place.

A good start would be rounds of one-on-one interviews with product owners and engineering leads. Typical questions you want to ask include: How many teams per product? What technologies will be used? What about documentation? Tools? Which security-related activities are currently undertaken? What will the release cycles be like? What communication channels will be used? How will product issues be reported?

2. Define the role

The main objective of this step is to come up with tangible goals and to prepare clear role descriptions for future security champions. While measuring the current state of security is partially done during the previous step, detailed descriptions of building a global app sec strategy are beyond this playbook. Please refer to existing frameworks such as OpenSAMM, which provides a simple and straightforward way to achieve this.

With your app sec program and global goals defined, it's crucial to match specific activities with security champions and map them onto these goals. Depending on the current state of security in your organization, activities could include some or all of the following:

  • Conduct and/or verify security reviews in the team.
  • Guard and promote best practices.
  • Raise issues for risks in existing and new code.
  • Build threat models for the new features.
  • Conduct and/or verify automated scans.
  • Investigate bug bounty reports.
  • Participate in R&D activities.

More expected activities are listed in the outcomes from the security champions session at the OWASP Summit 2017. Activities can evolve over time.

[ Get up to speed fast on secure DevOps at TB Learn ]

3. Nominate champions

Okay, so the roles are defined, and now it's time to nominate the champions! In order to smoothly pass through this step, you should first get approvals from managers on all levels—from top management to product owners to direct team managers.

Even though this is the classic top-down approach, it's an extremely important part. Buy-in at all levels counters the worst argument you can hear: "I have no time for security." Make a presentation of defined roles, benefits for the team, and approximate time that champions would spend on security tasks; 20% should be enough at the beginning.

Once the approvals are obtained, the next step is to identify potential champions. Sit down together with team managers, select the candidates, and conduct mini-interviews with each of them. Remember, it's not appointing, but nominating! Describe the role, expectations, and strategy, and discuss the benefits they'll get from becoming a champion:

  • Self-development and the ability to look at things differently.
  • Increased value on the market.
  • Improved product quality.
  • The opportunity to attend security conferences.
  • Being an important part of the security meta-team.
  • Having fun :-).

In the worst-case scenario, ask team managers for help finding a champion, although hopefully you'll get the champion to step up right after the first presentation. Then make the official nomination; add him or her to the meta security team's contact page, making sure the title "security champion" appears. Introduce the novice to others, and think of some sort of "insignia" like a coffee mug.

4. Set up communication channels

Champions cannot operate on their own, and the process works best when champions really feel the (meta) team spirit. So the next step is to set up communications channels. Depending on the corporate culture, the channels could include any of the following:

  • Private Slack / IRC channels.
  • Keybase teams.
  • Skype group chats.
  • Yammer groups.
  • Mailing lists.

The more the better, really—just make sure there is an easy way to share important information and get feedback. Additionally, set up periodic sync-ups to see how things are going and to adjust short-term goals together. At the beginning, biweekly meetings should be fine.

5. Build a solid knowledge base

While it can be a tedious task to create everything from scratch, there are a number of open-source projects that can make your life much easier. OWASP projects including the Security Knowledge Framework, the Application Security Verification Standard, and the Mobile Application Security Verification Standard are excellent starting points. Other sources are industry best practices (such as CERT secure coding standards); all of these can also become your basis for the first several internal workshops.

6. Maintain interest

To have a continuous and successful security champions ecosystem, it's crucial to constantly support them and provide them with learning materials. Here are some suggestions for how to maintain champions' interest and help them evolve as security professionals:

  • Workshops and trainings.
  • Regular newsletters of the most interesting developments.
  • Security champions corner.
  • Local OWASP meetings.

Security culture counts

If you followed all the steps, you should have a working security champions program. It might be possible to get the same results by skipping some of the steps above or reordering them, depending on what's required at your company.

The best thing about the champions ecosystem besides scalability is the side benefits your organization will be getting, mostly the development of a security culture. With time, the security champions will start to propose their own initiatives, participate in R&D, and conduct product-specific workshops, engaging more and more people and making security everyone's business, as it should be.

The original playbook is available at GitHub; the playbook is now part of OWASP.

Secure DevOps: What's in it for dev, sec and ops? TB Learn's new track gets you up to speed fast on DevSecOps.


Keep learning

Read more articles about: SecurityInformation Security