This document discusses myths and misperceptions around open source security. It addresses 6 common misperceptions: 1) that security tools can find all open source vulnerabilities, 2) that scanning is best done at the end of development, 3) that the National Vulnerability Database covers all vulnerabilities, 4) that replacing vulnerable components is always the answer, 5) that the "many eyes" theory ensures open source security, and 6) that open source is less secure than commercial software. The document provides details to counter each misperception and emphasizes that all software can have vulnerabilities, and that visibility into what software is used is key to security.

1. Myths and
Misperceptions of
Open Source Security

2. Agenda
• 3 big myths of open source
• 6 misperceptions
• Key takeaways

3. 3 BIG MYTHS
I don’t use much open source,
so security isn’t an issue
I know all of the open source
I use and have it covered
I find and fix open source
vulnerabilities quickly
1
2
3

4. You Use Open Source, and It Has Vulnerabilities

5. 6 Misperceptions

6. 1. SECURITY TESTING TOOLS COVER
OPEN SOURCE VULNERABILITIES
“I’m using static and
dynamic analysis tools, and
including the open source as
source code. Won’t those
tools find vulnerabilities in
the open source?”

7. Static analysis
• Testing of source code or binaries for unknown
security vulnerabilities in custom code
• Advantages in buffer overflow, some types of
SQL injection
• Provides results in source code
Dynamic analysis
• Testing of compiled application in a staging
environment to detect unknown security
vulnerabilities in custom code
• Advantages in injection errors, XSS
• Provides results by URL, must be traced to source
Automated Tools Are Good, Not Perfect
All possible
security vulnerabilities
Identifiable
with Static
Analysis
Identifiable
with
Dynamic
Analysis

8. Automated testing tools find common
vulnerabilities in the code written by internal
developers
• They’re good, but not at all effective in finding open
source vulnerabilities
• Many types of bugs are undetectable except by trained
security researchers
Over 74,000 vulnerabilities have disclosed in NVD.
• 63 reference automated tools
• 50 of those are for vulnerabilities reported in the tools
• 13 are for vulnerabilities that could be identified by a
fuzzer
There Are No Silver Bullets
Vulnerabilities by Detection Method
Found by Researchers Found by Tools

9. “I don’t want to slow down
developers with testing for
security when the product is
incomplete. Until we know how
all of the components used we
won’t know if we have included
those with vulnerabilities.”
2. SCANNING IS BEST AT THE END OF THE SDLC

11. Secure Development Lifecycle (SDL)
Relative cost to remediate bugs
Reqs Design Code Test Release
$1
$150
$50
$20
$10$5
• OSS Security
Requirement and Risk
Assessment
• Application Criticality
Ranking
• OSS Selection
• OSS Review Board
OSS Controls
• Implement Open Source
Security Controls
• Non-compliant OSS
Identification &
Reporting
• Correlation with Bills of
Material
OSS Controls
• Timely OSS Vulnerability
Identification &
Reporting
• Bug Severity
• Remediation Advice
• Correlation with Bills of
Material
OSS Monitoring
• Timely OSS Vulnerability
Identification &
Reporting
• Bug Severity
• Remediation &
Mitigation Advice
Security Activities at each phase of development
Goal = Find bugs earlier

12. “The National
Vulnerability Database is
all we use because all
software projects are
required to report
vulnerabilities to NIST”
3. NVD COVERS ALL VULNERABILITIES

13. Vulnerabilities are Reported (or not) in Many Places
• VulnDB in 2015 includes ~1,000
vulnerabilities not reported in NVD
• Other Certified Numbering Authorities (CNA)
• Mailing lists and discussion threads
• Project home pages

14. The Threat Landscape Constantly Changes
Why aren’t these collected by NVD?
• Researchers providing information directly to project communities
• Responsible disclosure
• Frustration with NVD responsiveness
• Time lag between discovery and NVD reporting
0
1000
2000
3000
4000
2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015
Open Source Vulnerabilities Reported Per Year
nvd vulndb-exclusive

15. “Vulnerabilities are typically
disclosed “responsibly”, so
a fixed version is available.
Upgrading to the next
release takes care of any
vulnerabilities.”
4. REPLACING THE VULNERABLE COMPONENT IS
ALWAYS THE RIGHT ANSWER

16. Remediation Guidance
1. Any code refactoring adds time to a project
2. For older vulnerabilities, the “fixed” versions (also old) may have
even more vulnerabilities.
3. Changes to API’s may make upgrading more difficult

17. Alternatives
1. Replace
a. With next version
b. With a newer version
2. Modify the code
a. If the fix was simple, modify the source yourself
3. Ignore and accept the risk
a. Risk appetite differs between organizations and applications
4. Mitigate the risk
a. Institute compensating controls
a. Input validation
b. WAF rules
c. IDS/IPS rules

20. “The ‘Many Eyes Theory’ ensures
the security of open source
components and applications.
With open access to the source,
anybody can conduct code
reviews and stop vulnerabilities
from entering the code base.”
5. OPEN SOURCE IS MORE SECURE
THAN COMMERCIAL SOFTWARE

21. Many Eyes Theory
Many eyes theory requires “security eyes”
• Most developers are not trained in code review
Security involves more than secure coding
• Security focused SDLC
• Security requirements
• Threat modeling
• Use and misuse cases
• Static/dynamic analysis
• Code reviews

22. “Open source is always less
secure. The open source
project communities don’t
have the money to do
security testing or employ
security teams."
6. OPEN SOURCE IS MORE LESS
SECURE THAN COMMERCIAL SOFTWARE

23. 0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015
Vulnerabilities in Open Source v. Commercial Code
Open Source Commercial
All software is subject to
vulnerabilities
Open source is subject to more
scrutiny because:
• Source availability (it’s where
researchers practice)
• Characteristics that make it
attractive to attackers
• Many more researchers with
better skills than 10 years ago
However, the trend shows that
commercial code has more
vulnerabilities disclosed
Software has Vulnerabilities

24. Key Takeaways
Visibility is key
• You need to know what you’re using to protect yourself
Knowledge is power
• Upgrading to the “fixed” version isn’t always the right answer
All software is not created equal
• Understand the criticality of every application, and respond accordingly

25. Questions?