1. Securing Open Source Software: Advantages and Challenges
Mitch Stoltz
Head Security Engineer
Netscape Client Products Division

2. Open Questions Is Open Source software more secure?
What are the security advantages of the open source model?
What are the disadvantages?
How can those disadvantages be overcome?

3. The Promise of Open Source
“Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
Or, less formally, ‘Given enough eyeballs, all bugs are shallow.’ I dub this: ‘Linus's Law.’”
- Eric Raymond,
“The Cathedral and the Bazaar”

4. The Promise of Open Source
No organizational bottleneck in the original developer
Anyone can download and test
Less communication necessary
Development, testing/verification, and maintenance can be done by different organizations

5. The Promise of Open Source
Independent verification means not having to trust manufacturers’ claims
What is impossible to prove is that proprietary software is more secure than free, without the public and open inspection of the scientific community and users in general. This demonstration is impossible because the model of proprietary software itself prevents this analysis, so that any guarantee of security is based only on promises of good intentions (biased, by any reckoning) made by the producer itself, or its contractors Edgar David Villanueva Nunez, Congressman, Peru

6. The Promise of Open Source
Popularity among academics and students increases the pool of knowledgeable reviewers
Potential for very fast turnaround time for security fixes

7. Opposing Views
Inherently, the closed nature of proprietary software is its first line of defense regarding security issues…
Opening the code to potential attackers provides a free education…
-Kenneth Brown, Alexis de Tocqueville Institution
People unfamiliar with the open source model are accustomed to keeping their source secret. When their source does become public, it's almost always related to a security breach or the threat of a security breach.
-Michael Warfield, LinuxWorld

8. Opposing Views Open source gives a short-term advantage to attackers
Attackers can find and exploit flaws before most users can find out about the problem and apply a fix
Security breaches bring negative publicity to a company - there’s an incentive to conceal information about flaws

9. Misconceptions Too little control over what code goes into a project
“If anyone can contribute, how can we trust the result?”
The GPL does not require `patches to wander in', a big part of the freedom inherent in it is that the impacted agency has the power to fix a problem, on the spot, and share the fix at essentially no cost with other impacted agencies. Trying to do that with proprietary software is generally illegal Leon Brooks

10. Misconceptions Code that is kept secret is inherently safer
Kerchoffs’ Principle: The security of an algorithm should depend only on the key
Corollary: Minimize the number of secrets that must be kept to maintain security
Public algorithms are designed to be secure even though they are public; that's how they're made. So there's no risk in making them public Bruce Schneier, Crypto-Gram

11. Misconceptions But secrecy is not necessarily unsafe…
Minimize the number of secrets in your security system. To the extent that you can accomplish that, you increase the robustness of your security. To the extent you can't, you increase its fragility. Obscuring system details is a separate decision from making your system secure regardless of publication; it depends on the availability of a community that can evaluate those details and the relative communities of "good guys" and "bad guys" that can make use of those details to secure other systems. -Bruce Schneier, Crypto-Gram

12. Misconceptions Open source software is inherently safer
Source availability is no guarantee of effective review
Few open source contributors know how to look for security flaws in code
simply publishing the code does not automatically mean that people will examine it for security flaws. Security researchers are fickle and busy people. They do not have the time to examine every piece of source code that is published. So while opening up source code is a good thing, it is not a guarantee of security… -Bruce Schneier

13. Re-Framing the Question
“Is open source code more secure than proprietary code?”

14. Re-Framing the Question
“Is open source code more secure than proprietary code?”
This is the wrong question.

15. Re-Framing the Question
New Questions:
What are the requirements for building and deploying secure software?
What aspects of open source development make these requirements easier or harder?
What can we do to help the open source model deliver on its promise of security?

16. Challenges & Solutions
Challenge: Responsible Disclosure
Early disclosure can lead to increased attacks
but people have a right to know the risks of the software they use
Those advocating secrecy are right that full disclosure causes damage, in some cases more damage than good. They are also right that those who build attack tools should be held liable for their actions; the defense of "I just built the bomb; I didn't place it or set the fuse" rings hollow. But they are wrong to think they can enforce secrecy. Information naturally disseminates, and strategies that go against that are doomed Bruce Schneier

17. Challenges & Solutions
Challenge: Responsible Disclosure
Companies conceal vulnerabilities and are slow to provide fixes
but some “security researchers” disclose vulnerabilities for personal publicity
Someone who releases a harmful program through a press release has a different agenda than to help you Bruce Schneier
A large portion of security experts go home at night and write tools for the script kiddies Marcus Ranum

18. Challenges & Solutions
Solution: Limited Initial Disclosure (A Compromise)
Limit technical description of vulnerabilities to a group of experts and stakeholders until bug is fixed
Low barrier to entry in the group
Reporter, group members keep things honest
Full disclosure after fix is distributed

19. Challenges & Solutions
Challenge: Lack of Qualified Reviewers
Security problems are subtle and often missed even by expert programmers
Solution: Finding, Training, and Incentivizing Bug Hunters
Training Reviewers to spot problems
Netscape Bug Bounty Program

20. Challenges & Solutions
Challenge: Automating & Systematizing Security Review
repeated mistakes
no feedback to developers
Solution: Tight Feedback Loops
Integrate security scanners into build feedback
Review past problems and integrate findings into future security evaluations

21. Challenges & Solutions
Challenge: Developer Education
Solution: Identify Common Mistakes & Teach Best Practices
We need new, innovative forms of developer education

22. Key Sources “The Cathedral and the Bazaar,” Eric Raymond
“Crypto-Gram,” Bruce Schneier, Sep. 1999, Jan. 2000, Feb. 2000, Sep. 2000, May 2002
“Opening the Open Source Debate,” Kenneth Brown
available at
“Dispelling Myths about the GPL and Free Software,” John Viega and Bob Fleck
“Why Open Source? Look at the Numbers!” David Wheeler

23. Questions & Comments Welcome