application security in the age of open source

Application Securityin the age ofOpen Source

© Black Duck Software 2016

7 of the top 10 Software Companies (44 of the top 100)

6 of the top 8Mobile Handset Vendors

6 of the top 10 Investment Banks

24Countries

240+Employees

1,600Customers

About Black Duck

27Founded

2002

But security investment is often not aligned with actual risks

Up to 90%Open Source

TODAY

50%Open Source

2010

20%Open Source

20051998

10%Open Source

Open source is the foundation of modern applications

DEVELOPER DOWNLOADS

OUTSOURCED DEVELOPMENT

THIRD PARTY LIBRARIES

CODE REUSE

APPROVED COMPONENTS

COMMERCIAL APPS

OPEN SOURCE CODE

It enters your code through many channels…

…and open source vulnerabilities can come with it.

Most applications contain untracked open source & vulnerabilities

0

500

1000

1500

2000

2500

3000

3500

2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015

nvd vulndb-exclusive

Over 30,000 open source vulnerabilities have been reported since 2000

© Black Duck Software 2016 8

CVE-2014-0160 (Heartbleed)OpenSSL

Community Health Systems4.5 million patient records compromised

CVE-2013-4810JBOSS

23,000 sites vulnerable200 known compromised sites

Many of these vulnerabilities have had huge impacts

When vulnerabilities are discovered,it’s a race between you and hackers

VulnIntroduced

NationalVulnerabilityDatabase

VulnDiscovered

YouFind It

YouFIX It

ExploitsPublished

HackersHack

Highest Security Risk


So…who’s responsible for keeping your open source software secure?

?

• Dedicated security researchers• Security advisory notifications• Automated patch deployment • Support teams and SLAs


With commercial software, the vendor has your back

• The “community” reports vulns• Monitor newsfeeds yourself• No standard patching mechanisms• Most open source is unsupported


With open source, you have to watch your own

How are most companies managing open source today?

SPORADIC VULN TRACKING• No single responsible entity• Labor intensive manual effort• Unmanageable (~11 new vulns/day)

SPREADSHEET INVENTORY• Requires consistent developer input• Difficult to maintain• Not a full/accurate list of actual usage

PERIODIC VULN SCANNING• Monthly/quarterly vulnerability assessments

(with Nessus, Nexpose, etc.)• Difficult to scale• Limited insight into open source vulns

MANUAL DISCOVERY• Cumbersome processes• Occurs at end of SDLC• High effort and low accuracy• No ongoing controls

#FAIL

OpenSSLIntroduced: 2011Discovered: 2014

Heartbleed

GNU C LibraryIntroduced: 2000Discovered: 2015

Ghost

QEMUIntroduced: 2004Discovered: 2015

Venom

BashIntroduced: 1989Discovered: 2014

Shellshock

OpenSSLIntroduced: 1990'sDiscovered: 2015

Freak

FREAK!

What do these vulnerabilities have in common?

All were found by security researchers – not SAST / DAST tools.

But most open source vulnerabilities are too complex and too deep in the code to be found by automated SAST/DAST tools.


Fact: SAST & DAST tools miss open source vulnerabilities

Automated SAST/DAST tools are good at finding vulnerabilities in the code written by your developers

To manage open source risks you need an end-to-end approach

INVENTORYOpen Source Componentsin Your Code

MAPComponents

to Known Vulnerabilities

IDENTIFYLicense &

Code Quality Risks

TRACKPolicy Violations & Remediation

Progress

ALERTWhen New

Vulnerabilities Affect Your Code

Automation and policy management

Integration with DevOps tools and processes


No one tool does it all

Static Application Security Testing

• Analyzes source code

• Finds unknown vulns

• SQL injection

• Cross-site scripting

• Buffer overflows, etc.

Good for custom code

Dynamic Application Security Testing

• Tests running apps

• Finds configuration, authentication, and other session defects

• Usually HTTP/API testing only

Good for finished apps

Open SourceVuln Management

• Scans for open source components

• Finds known vulns

• Monitors for new vulns

Best for OSS vulns

• Is there a list of open source in use?

• How do they create and maintain it?

• What open source policies exist?

• How do they enforce them?

• Do they track open source vulnerabilities?

• Are they prepared for the next Heartbleed?

Talk with your head ofapplication development

18© Black Duck Software 2016

Find all open source in your apps & containers

Map open source to known vulnerabilities

Identify open source license risks

Manage polices and remediation activities

Get alerts for newly reported vulnerabilities

Integrate with your agile development tools

Secure & Manage Open Source with Black Duck Hub

Know Your Code®

application security in the age of open source

Technology