At the Synopsys Security Event - Israel, Tim Mackey, Senior Technical Evangelist at Black Duck by Synopsys presents on open source and containers. For more information, please visit our website at www.synopsys.com/software.

1. New AppSec Paradigms with
Open Source and Containers

2. Open Source Development
From project inception through consumption

3. PHASE 1 – Project Inception
Equivalent of “Stealth Mode”. Targeted
development with small team. Features and
function rules.

4. OSS License Impacts Security Information Flow
Permissive Licenses
• Can use, copy, modify and distribute the software
• Allows combination with open source or proprietary
software
• No obligation to distribute derivative works’ source
Copyleft (Reciprocal) Licenses
• Source code must be distributed with derivative work
using same license
• Much more complex than permissive licenses
Uncertain Licenses
• Licenses lack solid jurisdictional definition

5. LEVEL 2 – BIRTH
First meaningful external adoption.
May see contributions and forks of
the code. Excitement within the core
team.

6. CLAs and Forks – Knowing Your Contributors
Contribution License Agreements
• Defined by the project
• Covers rules for third party contributions
• Can be at odds with corporate IP
Forks
• Indicator of project health
• Creates ownership dependency
• Parallel development occurs

7. LEVEL 3 – ADOPTION
Now that we have users and
“customers”, we need to get process.
Security matters, so we need to track
things. Thankfully we have tools, but
cost matters.

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

9. Security Analysis Isn't Only SAST/IAST/DAST
All possible security vulnerabilities
Vulnerability and Compositional Analysis
- Creates full inventory of dependencies
- Maps dependencies to security information
- 3000+ disclosures in 2015
- 4000+ disclosures in 2016
- 14,000+ disclosures in 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. LEVEL 4 – MISSION CRITICAL
Are we ready for prime time? Our
users now trust us, and we need to
step up. Things just got real!

11. The Real World of Open
Source Consumption

12. 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
Proprietary Software Rules Aren’t Open Source

13. Managing Consumption
Risks

14. 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

15. OSS Patching Differs from Vendor Patches

16. Understand Realities of Patch Policies
Patch version worse
Patch version worse
Patch version worse

17. Some Real World Examples

18. 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

19. Heartbleed: Why in 2017?
Don’t Give Attackers Opportunities
OpenSSH (CVE-2004-1653): AllowTCPForwarding creates open IoT proxyApache Struts (CVE-2017-5638): Vulnerability response time mattersHeartbleed: Why in 2018?

20. Container Design Follows a Supply Chain Model
Engineers Design using internal and external components
Production Assembles components into a vehicle
Vehicle safety and assembly Tests ensure compliance
Vehicle Delivery occurs using trusted carriers to dealerships
Vehicle Deployment occurs at time of purchase
Repair occurs using validated components
Regulators define Governance and Compliance criteria
DevelopmentOperations

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

22. 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