Categories: Musings Security

Evolving the Security Review and Discussion Process

“The journey of a thousand miles begins with one step.” ~ Lao Tzu
“If you do what you’ve always done, you’ll get what you’ve always gotten.” ~ Anthony Robbins

We’ve been thinking about and working and retooling our security review process over the last few months with a set of goals in mind.

Review more items and review them early in the development process.
Pretty straight forward, find more features/bugs/ideas that need to be looked at. Schedule them and find stuff. The challenge here was getting much more plugged into the development process, especially for desktop Firefox which is where we started our focus. As things move along we are branching out into mobile, messaging, and other projects. We also want teams to come to us instead of us having to chase them.

Reviews need to be useful to all involved.
The core idea that security has to be add value, not just some time that people spend in a room talking about theory or speed bump on the ship lane. The outcome of meetings with security should be valuable and should focus on finding a path through, not stopping because we find a “problem”. When we had blockers we had to be clear about why it’s a blocker and what needs to be done. When it’s not a blocker it had to have a severity and the importance communicated clearly for future prioritization. And if the meeting was done early, it was done early. Time is a resource we cannot replace or replenish and it has to be used wisely. If we wanted to get the first goal this had to happen. And the format of the meeting had to be more firm.

Results of a review should be easy to find and available for review.
We want everyone interested in security and the security of our products to review our work, be critical in feedback and find ways to improve. That means publishing what we did, when we did it and what if any actions were to come from the meetings. We did just that, and you can find it here

Meetings need to be practicable, open, and publicized.
With the previous goals in mind the meeting format changed to something like this:

  •  Introduce Feature (5-10 minutes) [can be answered ahead of time to save meeting time]
  •  Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
    •  What solutions/approaches were considered other than the proposed solution?
    •  Why was this solution chosen?
    •  Any security threats already considered in the design and why?
  • Threat Brainstorming (30-40 minutes)
  • Conclusions / Action Items (10-20 minutes)

We also created a public calendar so that anyone who was interested could join in and share their knowledge; available as HTMLand .ICS. Every meeting also contains the information on how to dial-in and interact during the meetings.

Results So Far

So far this has had some good outcomes, we found and proactively fixed items in both CSS Animations and Server Sent DOM Events as examples. As well as having a large number of very productive conversations early in the development process with many teams that will yields results as we continue to work with them. By changing our focus to one of early intervention and positive paths we are also building a stronger culture of security focus across the Mozilla culture.

Other Related Changes

We also added some keywords to Bugzilla and some new items to the feature pages to help track our work, identify things that may need to be looked at and and allow others to nominate items for our review. Since I wrote about these on my personal blog I won’t repeat them here.

Looking Forward

We’ve made what I think are very useful changes that allow us to be more “fleet of foot” with the new rapid release process. We’ve done it in a uniquely Mozilla way while still leveraging from best practices from many in the industry. And it’s a great starting  point for even more positive change. We strive to give our users the most secure browsing experience, with a product they can trust and that puts privacy and security at the forefront.

As we evolve the process we encourage you to get involved by joining in our meetings, the wiki and discussions, as we do I will continue to write about what we are doing and share our journey with you.


One comment on “Evolving the Security Review and Discussion Process”

  1. Web Design India wrote on

    Hi Curtis,

    Thanks for sharing such wonderful information on how to make bug free system, what to be done and what has to be taken care of.