As presented at the Bay Area Cyber Security Meetup on January 25th, 2018. Open source development paradigms have become the norm for most software development. This is regardless of whether you're making the next great IoT device, a new container microservice, or desktop application. While open source components are often viewed as free, and definately help solve problems in a scalable way, using them in a secure manner requires an understanding of how open source development really works. In this sesssion, I covered how secure development practices with data center regulations can benefit from an understanding of open source development. Specifically, we looked at fork management, community engagement and patch management. We ended with an open source maturity model.

1. A Question of Trust –
Understanding Open Source
Security Risks –
A Container Story
By Tim Mackey – Black Duck Software
Bay Area Cyber Security Meetup – January 2018

2. #whoami – Tim Mackey
Current roles: Senior Technical Evangelist; Occasional coder
• Former XenServer Community Manager in Citrix Open Source Business Office
Cool things I’ve done
• Designed laser communication systems
• Early designer of retail self-checkout machines
• Embedded special relativity algorithms into industrial control system
Find me
• Twitter: @TimInTech ( https://twitter.com/TimInTech )
• SlideShare: slideshare.net/TimMackey
• LinkedIn: www.linkedin.com/in/mackeytim

3. Security Driven Development and Deployment
Developers are empowered with security information
Clear security driven release policies exist
Trusted components are used as dependencies
CI processes incorporate security testing
Binary artifacts are only created when release policies are met
Releasable binaries are digitally signed
Container images are built from trusted base images
Produced images are stored in trusted container registries
Containers are only deployed from trusted registries

4. Data Breaches are Serious Business
• Average cost of data breach: $7.35 Million
• Lost business: $4.03 Million
• Average time to identify and contain a breach: 206 days
Source: 2017 Cost of Data Breach Study – Ponemon Insitute

5. Question Everything and Continually Evaluate Trust
Where does your base image actually come from?
What is the health of that base image?
You’re updating it at build time, but from what cache?
You trust your build servers, but who controls them?
Is there any way a foreign container can start in your environment?
Who has rights to modify container images?
What happens if base image registry goes away?
What happens if base image tag goes away?
What happens if an update mirror goes down?
When a security disclosure happens what’s the process to determine impact?
How are images being updated and deployed in the face of new security disclosures?

6. CLOSED SOURCE COMMERCIAL CODE
• TRADITIONAL PROCUREMENT PROCESS
• ALERTING AND NOTIFICATION INFRASTRUCTURE
• SUPPORT AVAILABLE THROUGH EOL
• STAFFED WITH SECURITY RESEARCHERS
• REGULAR PATCH UPDATES
• DEDICATED SUPPORT TEAM WITH SLA
OPEN SOURCE CODE
• AD-HOC ADOPTION MODEL
• MONITOR NEWSFEEDS YOURSELF
• EOL MAY CREATE DEADEND
• “COMMUNITY”-BASED CODE ANALYSIS
• NO STANDARD PATCHING MECHANISM
• ULTIMATELY, YOU ARE RESPONSIBLE
Commercial Software Rules Don’t Apply

7. Media
Coverage
Embargo
Expires
Oct 21 2016
Git://id
Upstream
Patch
Vuln: CVE-2016-5195 –
AKA “Dirty Cow”
Oct 18 2016
Patches Available
Embargoed Vulnerability Awareness

8. Patches Available
Media
Coverage
Embargo
Expires
Oct 21 2016
Git://id
Upstream
Patch
Vuln: CVE-2016-5195 –
AKA “Dirty Cow”
Oct 18 2016
National
Vulnerability
Database
Vuln
Published
Nov 10 2016
Highest Security Risk
Timing is Opportunity

9. Security Analysis Isn't Only SAST/IAST/DAST
All possible security vulnerabilities
Vulnerability Analysis
- Identifies vulnerable dependencies
- 3000+ disclosures in 2015
- 4000+ disclosures in 2016
- 13,000+ disclosures through Nov 2017
- Most vulnerabilities found by researchers
Static, Interactive and Dynamic Analysis
- Discover common security patterns
- Challenged by nuanced bugs
- Focuses on your code; not upstream

10. Heartbleed: Why in 2017?
Don’t Give Attackers Opportunities
OpenSSH (CVE-2004-1653): AllowTCPForwarding creates open IoT
proxy
Apache Struts (CVE-2017-5638): Vulnerability response time
matters

11. 1649 Days 144 Days7 Days
The Tale of CVE-2017-5638 and Equifax
Code Bug
Introduced
August
2012
Struts 2.3
Released
November
2012
Struts 2.5
Released
May
2016
Patches
Available
March 6
2017
March 7
2017
Disclosure
Published
NVD
Details
March 14
2017
Hacks
Successful
May 13
2017
Hacks
Discovered
July 29
2017

12. Focus on Factors Impacting Risk
Use of vulnerable open source components
• What are my dependencies and where are they coming from?
• Is component a fork or dependency?
• How is component linked?
Impact of Point in Time Decisions
• Can you differentiate between “stable” and “dead”?
• Is there a significant change set in your future?
• API versioning
• Security response process for project
• Commit velocity and contributors

13. We Don’t Patch Containers – But Patches Matter

14. We’re all Researchers – Report What You Find
Distributed Weakness Filing
• Open Source specific CNA
• Designed for Open Source
projects without an existing CNA
Increasing vulnerability awareness
• Reinforce security collaboration
• Reduce islands of knowledge https://iwantacve.org
https://github.com/distributedweaknessfiling/

15. Open Source Development
Risk Maturity Model

16. LEVEL 1 – BLISSFUL IGNORANCE
No policies in place to manage open
source security and licensing risks.
Unknown versions and dependencies.
No documentation of intent.

17. LEVEL 2 – AWAKENING
Inconsistent manual processes to
identify and report on open source
usage. Conceptual awareness of
license requirements. Unaware of
security implications of open
source usage.

18. LEVEL 3 – UNDERSTANDING
Manual review processes, and basic
tooling. Primary focus on license
compliance. Accuracy is difficult to
maintain. Provides limited insight into
security vulnerabilities.
Tools: Spreadsheets, low cost tools,
sporadic security scans

19. LEVEL 4 – ENLIGHTENMENT
Automatic identification of open
source components and
versions. Direct mapping to
licenses and disclosed
vulnerabilities. Integration with
developer, issue management,
CI/CD and deployment tools.

20. Open Source Security Requires End-End Visibility
INVENTORY
Open Source
Components
MAP
To Known
Vulnerabilities
IDENTIFY
Open Source
Risks
MANAGE
Open Source
Governance
Policies
ALERT
For New
Vulnerabilities
Automation and workflow
Integration with DevOps tools and processes

21. Stay Out of the News for the Wrong Reasons