Are you new to Black Duck or open source security? Do you need a refresher? Understanding the fundamentals of open source security is critical to keeping your data and organization safe. During this session, we'll share best practices from the world's leading experts to help you establish a foundation for success.

1. Open Source Security for
Beginners - Best Practices

2. • Overview of open source risk
• Designing a Successful Risk Mitigation Strategy
• Planning for Vulnerability Remediation
• Wrap up
Agenda

3. What are possible security vulnerabilities in
this home?
• Physical and/or policy-based
What are security threats to this home?
• Are some threats more likely to occur than
others?
What would an attack look like?
• Have any neighbors been robbed?
How should one prioritize defenses?
• What is an acceptable level or risk?
Security Vocabulary

4. But security investment is often not aligned with actual risks

5. Virtually all Global 2000 companies use open source to run critical infrastructure. -
Gartner
Open Source Has Blown Past the Tipping Point
© Black Duck Software 2017 |
CONFIDENTIAL
Open Source Projects (Millions)
70%
of apps will run on
OSS databases by
2018
50%
of orgs face
problems because
of a lack of policy
2.5
0.1
0.2
0.5
1.5
1.0
2007 2009 2011 2013 2015 2017

6. Open Source in Commercial Software
22% of
applications
had
>50% open
source

7. 7

8. License Risk
• Open source license compliance
• Ensure project dependencies are understood
Operational risk
• How well supported is a component?
• Can you differentiate between “stable” and “dead”?
• Are there more recent versions?
Security Risk
• Exploitable vulnerabilities in components
• Old components with multiple vulnerabilities
Open Source Risk Elements

9. Open Source
Security

10. Open Source is Not Risk Free

11. Over 9,000 new
vulnerabilities in open
source since 2014
Over 80,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
Over 34,000 known open source vulnerabilities since 2000
0
500
1000
1500
2000
2500
3000
3500
4000
1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016
NVD Black Duck exclusive

12. HIPAA +
FTC Act +
FDA Regulations +
State laws +
Enforcement actions + . . . .
Open Source and Regulatory Requirements
}=
Reasonable
Security

13. What Would Constitute
“Reasonable Security”?

14. Practical Implications of Regulatory Standards
A) Risk analysis (Required).
Conduct an accurate and
thorough assessment of the
potential risks and
vulnerabilities to the
confidentiality, integrity, and
availability of electronic protected
health information held by the
covered entity.
Risk Assessment
• Identify vulnerabilities in all
covered software
• Review of custom code to
identify vulnerabilities
• Monitor for new
vulnerabilities

15. Practical Implications of Regulatory Standards
(B) Risk management
(Required). Implement
security measures sufficient
to reduce risks and
vulnerabilities to a
reasonable and
appropriate level to comply
with § 164.306(a).
Risk Management
• Have policies and controls in
place to address identified
risks in a timely manner

16. Signature-based
Scanning
File Information
Extraction
Build Process
Monitoring
Risk Assessment: Visibility to All Components is Key
A 3-Pronged Strategy
Chooses the best scan methods
for:
• Your Dev Tools
• Your Business Goals
• Your Risk Levels
With Impactful Benefits
• Automated
• Multi-factor identification
• Ensures accurate BOM
• Broad language support
• Identifies partial and modified
components
• Minimizes false positives /
negatives
• Streamlines disambiguation
Signature-based Scanning
Use contextual and file analysis:
• File / Directory meta-data
• File Content (SHA1 signatures)
Build Process Monitoring
Build process monitoring
• External ID-based
• Find Transitive Dependencies
• Understand Relationships and Use
• E.G. Maven, Gradle
File Info Extraction
Leverage additional component information
• Package Management Files
• Installation / SCM artifacts
• Manifest Files
• .Net Assemblies

17. Risk Assessment: Completeness of Risk Information
© Black Duck Software 2017 |
CONFIDENTIAL

18. Prioritizing & Fixing
Security
Vulnerabilities

19. Not all applications are equally
important
• Determine which are most
critical to accomplishing
business goals
• Determine “acceptable risk”
for others
Step 1 – Risk Rank Your Applications

20. How severe is the issue?
• CVSS Scores
• High, medium, low
How is it exploited?
• Local access or network
• Authentication required?
• Complex or simple?
Is an exploit publicly available?
Step 2 – Prioritize Your Vulnerabilities

21. What damage can an attacker do?
• Read data
• Modify data
• Denial of Service
• Execute unauthorized code or commands
• Gain privileges / assume identity
• Bypass protection mechanism
• Hide activities
Prioritize Your Vulnerabilities

22. Common Weakness Enumerators (CWE)

23. CWE Defines Technical Impact
23
Technical Impact of SQL Injection:
• Read application data
• Bypass protection mechanism
• Modify application data

24. Finite number of options
1. Patch
2. Rip and replace
3. Punt
4. Compensating Control
Step 4 – Risk Reduction

25. Is the vulnerability isolated?
Is a patch available?
Are you prepared to manage your own
branch of the code?
Patch

26. With what?
• Use resources like OpenHub
to make sure you aren’t
adding vulnerabilities
• Look at changes to determine
LoE
• Consider a substitute/similar
functioning component
Rip and Replace
Source: openhub.net

27. Risk is acceptable in terms of business
goals and risk appetite
• For most applications, removing all
vulnerabilities is not necessary
Are you using the vulnerable portion of
the code?
Punt

28. Can be a substitute for replacing/updating the code
Can be a stopgap to mitigate risk until you can remediate
Examples
• IPS/IDS rules
• WAF rules
• Centralized data cleansing/input validation
Step 4 – Use Compensating Controls

29. Establishing an OS
Security Monitoring
Strategy

30. Application Security Goal: Move “Left” in the SDLC
Analyze Design Implement Test Maintain
1x
6.5x
15x
100x
Source: IBM Systems Sciences Institute
Earlier Visibility to Vulnerabilities Pays Dividends

31. The Right Tool at the Right Time
SDLC Ecosystem
Analyze Design Implement Test Maintain
Security Intelligence (including data sources)
Open Source Selection Detection and Notification
IAST
Dynamic Analysis
Static Analysis
Manual Penetration Testing
Vulnerability
Assessment

32. • Build and automatically enforce OSS policies
• Identify OSS components early in the SDLC
• Automatically create and maintain bills of material
• Continuously monitor threat environment for new vulnerabilities
Open Source Best Practices
Reqs
• OSS Policies
• Application Criticality
Ranking
• OSS Risk Parameters
• License Risk
• Security Risk
• Operational Risk
Design
• OSS Selection
• Design Review
• License Risk
• Security Risk
• Operational Risk
Code
• OSS Detection
• Automatically detect
and alert on non-
conforming
components
• Correlation with Bills
of Material
Test
• OSS Enforcement
• Detect and alert on
non-conforming
components
• Correlation with Bills
of Material
Release
• OSS Monitoring
• Timely OSS
Vulnerability
Identification &
Reporting
• Bug Severity
• Remediation Advice

33. Continued adoption of open source
• Value far exceeds controllable risks
Increased regulatory oversight
• FDA, PCI, HIPAA, FTC Act 5
• GDPR
Increased focus on IT infrastructure
• Vulnerability scanners don’t cover all open source risks
What to Expect in 2018

34. • Determine which applications are most critical to your organization’s
business goals
• Create roadmap for ranking, prioritizing, and addressing vulnerabilities
based on their technical impact
• Design a OS risk monitoring strategy with your team
• Know the regulations that impact you + coordinate with internal
compliance teams
• Move left to improve vulnerability protection over time
• Communicate plan with teams and stakeholders
Key Takeaways

35. Questions?