LAS VEGAS -- Mozilla doesn't want to just make a better browser; it wants to make the Web a safer place for everyone.

That's the message that Mozilla Chief Security Officer Window Snyder and Mozilla project co-founder Mike Shaver delivered here today to a Black Hat crowd.

The Mozilla staffers provided an overview of how the open source group secures its code and how it intends to secure it in the future.

"Because everything is out in the open, it's easier for people to participate than they could with a traditional vendor," Snyder told the audience. "With traditional vendors you can only participate once the product ships. With Mozilla you can participate all along the process."

Mozilla uses a variety of security approaches to secure the browser, Snyder explained. Among them is threat modeling, which is a methodology for analyzing software for weaknesses and allows you to identify areas of risk.

Then there is the component security review, which is an approach that considers that every feature has a security impact on overall product. Mozilla also does code review looking for things like input validation mechanisms, improper sting handling and memory allocation errors.

"Mozilla's code review system is something we've had in since the project started nearly 10 years ago," Shaver said. "It catches errors and it also increases the number of people that are familiar with the code."

Snyder noted that Mozilla is also engaging in automated penetration testing, as well.

"We find fuzzing to be a very practical approach for finding vulnerabilities," Snyder said. "Targets include FTP, HTTP server responses, JavaScript and others."

For a browser vendor the Web can be a dangerous place. Shaver said that the whole of the Web for Mozilla is code and content you can't trust.

Mozilla's staffers also took aim at how to validate how secure or insecure a particular browser may be. In particular Snyder said that simply counting bugs is not a good measure.

"It doesn't tell you about the quality of the bug, how fast you're finding them or how bug-dense a particular piece of code is," Snyder said. "The real story shouldn't be that a vendor has x number of vulnerabilities; it should be that x number of vulnerabilities have been fixed.

This article was first published on InternetNews.com. To read the full article, click here.