This document discusses regulatory requirements for vulnerability assessments and the challenges of managing open source software vulnerabilities. It notes that regulatory requirements from standards like PCI-DSS require vulnerability monitoring and patching, but traditional vulnerability assessment tools do not provide visibility into custom code or track vulnerabilities over time in open source components. The document argues that organizations need software bills of materials and proactive vulnerability management programs that can map vulnerabilities to applications to effectively manage risks from open source.

1. © 2015 Black Duck Software, Inc. All Rights Reserved.
PCI & VULNERABILITY ASSESSMENTS
WHAT’S MISSING?

2. 2 CONFIDENTIAL
REGULATORY LANDSCAPE IS EXPANDING AND
OVERLAPPING
Increasing regulatory scrutiny
• Force of law and penalties
• Expanding and overlapping
Common Goals
• Focus on protecting
sensitive information
• Documented
responsibilities and
processes
• Require visibility to risks
(e.g. vulnerability
assessments)
GLBA
Sarbanes - Oxley

3. 3 CONFIDENTIAL
WHERE DO RISKS APPEAR?
PCI-DSS
Build and Maintain a Secure Network and Systems
• Requirement 1 – Configure firewalls and routers to protect against unauthorized access to cardholder data
• Requirement 2 – Don’t use vendor supplied default passwords and configurations
Protect Cardholder Data
• Requirement 3: Protect stored cardholder data, and don’t store what you don’t need
• Requirement 4: Use strong crypto and protocols
Maintain a Vulnerability Management Program
• Requirement 5: Use anti-virus
• Requirement 6: Develop and maintain secure systems and applications
Implement Strong Access Control Measures
• Requirement 7: Limit access on a need-to-know basis
• Requirement 8: Use and maintain identity management tools correctly
• Requirement 9: Physical security
Regularly Monitor and Test Networks
• Requirement 10: Log and audit all activity
• Requirement 11: Regularly test security systems and processes.
Maintain an Information Security Policy
• Requirement 12: Train your people

4. 4 CONFIDENTIAL
Source: The State of Risk-Based Security
Management, Research Study by Ponemon
Institute, 2013
INVESTMENT PRIORITY –
WHERE ARE YOUR “SECURITY RISKS” VS. YOUR “SPEND”
MANY CLIENTS DO NOT PRIORITIZE APPLICATION SECURITY IN THEIR ENVIRONMENTS
35%
30%
25%
20%
15%
10%
5%
APPLICATION
LAYER
DATA
LAYER
NETWORK
LAYER
HUMAN
LAYER
HOST
LAYER
PHYSICAL
LAYER
SECURITY RISK
SPENDING
SPENDING DOES
NOT EQUAL RISK
Source: The State of Risk-Based Security Management, Research Study by Ponemon Institute, 2013

5. 5 CONFIDENTIAL
MAINTAIN A VULNERABILITY MANAGEMENT PROGRAM
• Requires identification of
vulnerabilities in custom
code and all installed
software
• Requires independent risk
rating of vulnerabilities
• Requires monitoring for new
vulnerabilities, and applying
patches as available
6.2 Ensure that all system components and software are
protected from known vulnerabilities by installing applicable
vendor-supplied security patches. Install critical security
patches within one month of release.
<snip>
This requirement applies to applicable patches for all
installed software.
<snip>
Without the inclusion of security during the requirements
definition, design, analysis, and testing phases of software
development, security vulnerabilities can be inadvertently or
maliciously introduced into the production environment.
6.3.2 Review custom code prior to release to production or
customers in order to identify any potential coding
vulnerability…
6.1 Establish a process to identify security vulnerabilities, using
reputable outside sources for security vulnerability
information, and assign a risk ranking (for example, as “high,”
“medium,” or “low”) to newly discovered security vulnerabilities.
<snip>
This is not achieved by an ASV scan or internal vulnerability
scan, rather this requires a process to actively monitor industry
sources for vulnerability information.

6. 6 CONFIDENTIAL
REGULARLY MONITOR AND TEST NETWORKS
Vulnerability assessments
• Quarterly requirement
• Ad hoc internal
assessments
• “Continuous
monitoring” (daily
scans)
Vulnerability assessment
(VA) tools focus on
• Network security
• System configurations
• Operating systems
(including Linux)
• Commercial applications
(Office, Adobe, Oracle, etc.)
PCI-DSS 11.2
“Run internal and external network
vulnerability scans at least quarterly and
after any significant change in the network
(such as new system component
installations, changes in network topology,
firewall rule modifications, product
upgrades).”

7. 7 © 2015 Black Duck Software, Inc. All Rights Reserved.
WHAT’S MISSING?

8. 8 CONFIDENTIAL
WHAT’S MISSING?
1 – VA tools don’t know about your custom
applications
• No visibility to open source you use, or to
vulnerabilities in those components
2 – VA tools provide a point in time snapshot
• They must scan your entire system and applications for each new
update or vulnerability
• Do not maintain an inventory of your applications
• Each new issue must be searched for independently

9. 9 © 2015 Black Duck Software, Inc. All Rights Reserved.
VULNERABILITY MANAGEMENT
PROGRAMS IN THE AGE OF
OPEN SOURCE

10. 10 CONFIDENTIAL
OPEN SOURCE IS CHANGING THE WORLD
By 2016, Open Source
Software will be included
in mission-critical
applications within 99%
of Global 2000
enterprises.
0,0
0,5
1,0
1,5
2,0
2007 2009 2011 2013 2015
millions
Growth of open source
projects is accelerating.
Will face problems because
of no policy.
50%

11. 11 CONFIDENTIAL
OPEN SOURCE DEVELOPMENT CONTINUES TO GROW
Open Source is growing in use
• Needed functionality w/o acquisition
costs
• Faster time to market
• Lower development costs
• Support from broad communities
Black Duck On Demand results
• >98% of applications tested used open
source projects
• 95% of reviews find unknown open
source
• On average, clients were aware of < 50%
of the open source used
Custom
Code
Open
Source

12. 12 CONFIDENTIAL
HOW ARE VULNERABILITIES FOUND AND
DISCLOSED?
Over 6,000 new
vulnerabilities in open
source since 2014
Over 76,000 total
vulnerabilities in NVD,
only 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
0
200
400
600
800
1.000
1.200
2010-Apr
2010-Dec
2010-Jan
2010-Jun
2010-May
2010-Oct
2011-Apr
2011-Dec
2011-Jan
2011-Jun
2011-May
2011-Oct
2012-Apr
2012-Dec
2012-Jan
2012-Jun
2012-May
2012-Oct
2013-Apr
2013-Dec
2013-Jan
2013-Jun
2013-May
2013-Oct
2014-Apr
2014-Dec
2014-Jan
2014-Jun
2014-May
2014-Oct
2015-Apr
2015-Dec
2015-Jan
2015-Jun
2015-May
2015-Oct
2016-Apr
2016-Jan
NVD
Open Source Vulnerability Disclosures by Month
Heartbleed
Disclosure

13. 13 CONFIDENTIAL
WE HAVE LITTLE CONTROL OVER HOW OPEN
SOURCE ENTERS THE CODE BASE
Open Source
Community
Internally
Developed
Code
Outsourced
Code
Legacy
Code
Reused Code
Supply
Chain
Code
Third
Party
Code
Delivered Code
Open source code introduced
i a y ways…
…a d absorbed i to
final code.

14. 14 CONFIDENTIAL
OPEN SOURCE: EASY TARGETS
Used everywhere Easy access to code
Vulnerabilities are
publicized
Exploits readily available

15. 15 CONFIDENTIAL
WHO’S RESPONSIBLE FOR SECURITY?
Commercial Code Open Source Code
• Dedicated security researchers
• Alerting and notification infrastructure
• Regular patch updates
• Dedicated support team with SLA
• “community”-based code analysis
• Monitor newsfeeds yourself
• No standard patching mechanism
• Ultimately, you are responsible

16. 16 © 2015 Black Duck Software, Inc. All Rights Reserved.
PROACTIVE VULNERABILITY
MANAGEMENT

17. 17 CONFIDENTIAL
WHAT IF THE AUTOMOTIVE MARKET TREATED
RECALLS LIKE THE OPEN SOURCE MARKET?
Known and Quantified Known and Unquantified

18. 18 CONFIDENTIAL
A SOFTWARE BILL OF MATERIALS SOLVES THE
PROBLEM
• Components and serial numbers
• Unique to each vehicle VIN
• Complete analysis of open source components*
• Unique to each project or application
• Security, license, and operational risk surfaced

19. 19 CONFIDENTIAL
HOW ARE COMPANIES ADDRESSING THIS TODAY?
NOT WELL.
Manual tabulation
• Architectural Review Board
• End of SDLC
• High effort and low accuracy
• No controls
Spreadsheet-based inventory
• Dependent on developer best
effort or memory
• Difficult maintenance
• Not source of truth
Tracking vulnerabilities
• No single responsible entity
• Manual effort and labor intensive
• Unmanageable (11/day)
• Match applications, versions,
components, vulnerabilities
Vulnerability detection
• Run monthly/quarterly
vulnerability assessment
tools (e.g., Nessus, Nexpose)
against all applications to
identify exploitable instances

20. 20 CONFIDENTIAL
A SOLUTION TO SOLVING THIS PROBLEM WOULD
INCLUDE THESE COMPONENTS
Choose Open
Source
Inventory
Open Source
Map Existing
Vulnerabilities
Track New
Vulnerabilities
Maintain accurate list of
open source
components throughout
the SDL
Identify
vulnerabilities during
development Alert on new
vulnerabilities and
map to applications
Proactively choose
secure, supported
open source
GUIDE VERIFY/ENFORCE MONITOR

21. 21 CONFIDENTIAL
WHAT CAN YOU DO TOMORROW?
Speak with your head of application
development and find out:
• What policies exist?
• Is there a list of components?
• How are they creating the list?
• What controls do they have to ensure
nothing gets through?
• How are they tracking vulnerabilities
for all components over time?

22. 22 CONFIDENTIAL
BLACK DUCK PROVIDES VISIBILITY AND CONTROL

23. 23 CONFIDENTIAL
VULNERABILITY INFORMATION AND ALERTS

24. 24 CONFIDENTIAL
7 of the top 10 Software companies,
and 44 of the top 100
6 of the top 8 Mobile handset vendors
6 of the top 10 Investment Banks
24
Countries
230
Employees
1,600Customers
27 of the Fortune 100
ABOUT BLACK DUCK
Award for
Innovation
Four Years in the “Software
500” Largest Software
Companies
Six Years in a row
for Innovation
Gartner Group
“Cool Vendor”
“Top Place to Work,”
The Boston Globe
2014

25. The Intelligent Management of Open Source
14 Day Free Trial at
www.blackducksoftware.com/free-trial