Myths and Misperceptions of

Open Source Security

Agenda

• 3 big myths of open source • 6 misperceptions• Key takeaways

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

23

You Use Open Source, and It Has Vulnerabilities

6 Misperceptions

1.SECURITYTESTINGTOOLSCOVEROPENSOURCEVULNERABILITIES

“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?”

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

What’s Missing?

Automated Tools Are Good, Not Perfect

All possible security vulnerabilities

Identifiable with Static

Analysis

Identifiable with

Dynamic Analysis

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

“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

Secure Development Lifecycle (SDL)

Relativecosttoremediatebugs

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 developmentGoal = Find bugs earlier

“The National Vulnerability Database is

all we use because all software projects are

required to report vulnerabilities to NIST”

3. NVD COVERS ALL VULNERABILITIES

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

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

“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

Remediation Guidance

1. Any code refactoring adds time to a project2. For older vulnerabilities, the “fixed” versions (also old) may have

even more vulnerabilities.3. Changes to API’s may make upgrading more difficult

Alternatives

1. Replacea. With next versionb. With a newer version

2. Modify the codea. If the fix was simple, modify the source yourself

3. Ignore and accept the riska. Risk appetite differs between organizations and applications

4. Mitigate the riska. Institute compensating controls

a. Input validationb. WAF rulesc. IDS/IPS rules

“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

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

“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

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 vulnerabilitiesOpen 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

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

Questions?