KEMBAR78
Application Security in the Age of Open Source | PDF
Application Security
in the age of
Open Source
© Black Duck Software 2016
7 of the top 10
Software Companies
(44 of the top 100)
6 of the top 8
Mobile Handset Vendors
6 of the top 10
Investment Banks
24
Countries
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 Systems
4.5 million patient records compromised
CVE-2013-4810
JBOSS
23,000 sites vulnerable
200 known compromised sites
Many of these vulnerabilities have had huge impacts
When vulnerabilities are discovered,
it’s a race between you and hackers
Vuln
Introduced
National
Vulnerability
Database
Vuln
Discovered
You
Find It
You
FIX It
Exploits
Published
Hackers
Hack
Highest Security Risk
© Black Duck Software 2016 10
So…who’s responsible for
keeping your open source
software secure?
?
• Dedicated security researchers
• Security advisory notifications
• Automated patch deployment
• Support teams and SLAs
© Black Duck Software 2016 11
With commercial software, the vendor has your back
• The “community” reports vulns
• Monitor newsfeeds yourself
• No standard patching mechanisms
• Most open source is unsupported
© Black Duck Software 2016 12
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
OpenSSL
Introduced: 2011
Discovered: 2014
Heartbleed
GNU C Library
Introduced: 2000
Discovered: 2015
Ghost
QEMU
Introduced: 2004
Discovered: 2015
Venom
Bash
Introduced: 1989
Discovered: 2014
Shellshock
OpenSSL
Introduced: 1990's
Discovered: 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.
© Black Duck Software 2016 15
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
INVENTORY
Open Source
Components
in Your Code
MAP
Components
to Known
Vulnerabilities
IDENTIFY
License &
Code Quality
Risks
TRACK
Policy Violations
& Remediation
Progress
ALERT
When New
Vulnerabilities
Affect Your Code
Automation and policy management
Integration with DevOps tools and processes
© Black Duck Software 2016 17
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 Source
Vuln 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 of
application 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

  • 1.
    Application Security in theage of Open Source © Black Duck Software 2016
  • 2.
    7 of thetop 10 Software Companies (44 of the top 100) 6 of the top 8 Mobile Handset Vendors 6 of the top 10 Investment Banks 24 Countries 240+ Employees 1,600Customers About Black Duck 27Founded 2002
  • 3.
    But security investmentis often not aligned with actual risks
  • 4.
    Up to 90% OpenSource TODAY 50% Open Source 2010 20% Open Source 20051998 10% Open Source Open source is the foundation of modern applications
  • 5.
    DEVELOPER DOWNLOADS OUTSOURCED DEVELOPMENT THIRDPARTY 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.
  • 6.
    Most applications containuntracked open source & vulnerabilities
  • 7.
    0 500 1000 1500 2000 2500 3000 3500 2000 2001 20022003 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
  • 8.
    © Black DuckSoftware 2016 8 CVE-2014-0160 (Heartbleed) OpenSSL Community Health Systems 4.5 million patient records compromised CVE-2013-4810 JBOSS 23,000 sites vulnerable 200 known compromised sites Many of these vulnerabilities have had huge impacts
  • 9.
    When vulnerabilities arediscovered, it’s a race between you and hackers Vuln Introduced National Vulnerability Database Vuln Discovered You Find It You FIX It Exploits Published Hackers Hack Highest Security Risk
  • 10.
    © Black DuckSoftware 2016 10 So…who’s responsible for keeping your open source software secure? ?
  • 11.
    • Dedicated securityresearchers • Security advisory notifications • Automated patch deployment • Support teams and SLAs © Black Duck Software 2016 11 With commercial software, the vendor has your back
  • 12.
    • The “community”reports vulns • Monitor newsfeeds yourself • No standard patching mechanisms • Most open source is unsupported © Black Duck Software 2016 12 With open source, you have to watch your own
  • 13.
    How are mostcompanies 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
  • 14.
    OpenSSL Introduced: 2011 Discovered: 2014 Heartbleed GNUC Library Introduced: 2000 Discovered: 2015 Ghost QEMU Introduced: 2004 Discovered: 2015 Venom Bash Introduced: 1989 Discovered: 2014 Shellshock OpenSSL Introduced: 1990's Discovered: 2015 Freak FREAK! What do these vulnerabilities have in common? All were found by security researchers – not SAST / DAST tools.
  • 15.
    But most opensource vulnerabilities are too complex and too deep in the code to be found by automated SAST/DAST tools. © Black Duck Software 2016 15 Fact: SAST & DAST tools miss open source vulnerabilities Automated SAST/DAST tools are good at finding vulnerabilities in the code written by your developers
  • 16.
    To manage opensource risks you need an end-to-end approach INVENTORY Open Source Components in Your Code MAP Components to Known Vulnerabilities IDENTIFY License & Code Quality Risks TRACK Policy Violations & Remediation Progress ALERT When New Vulnerabilities Affect Your Code Automation and policy management Integration with DevOps tools and processes
  • 17.
    © Black DuckSoftware 2016 17 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 Source Vuln Management • Scans for open source components • Finds known vulns • Monitors for new vulns Best for OSS vulns
  • 18.
    • Is therea 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 of application development 18© Black Duck Software 2016
  • 19.
    Find all opensource 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
  • 20.