The document discusses the significance of open source security, focusing on the Equifax breach which affected 145 million individuals due to a known vulnerability in the Apache Struts framework. It highlights the lessons learned from this breach and emphasizes the importance of transparency, detection of vulnerabilities, prioritization, and execution in maintaining secure software practices. Additionally, the document provides insights into the challenges faced by SmallComp during a merger and acquisition process, involving compliance with open source licenses.

1. Open Source Security:
How to Lay the Groundwork
for a Secure Culture
Guy Bar Gil, Product Manager

2. The Equifax Breach
2
Staying SecureSmallComp’s M&A
1 2 3

3. Introduction Slide
• Two dogs + one cat
• In my free time I enjoy:
• Sports
• Reading
• Traveling
3
Guy Bar Gil, Product Manager

4. 4
1The Equifax Breach

5. • Consumer credit reporting agency
• Equifax collects and aggregates information
• 800M+ individual consumers
• 88M+ businesses
• Publicly traded (NYSE), 9.5K+ employees, $3.14B in revenues
(2016)

6. Apache Struts
• Open-source framework, for
creating Java web applications.
• CVE-2017-5638 allows remote code
execution through the web
applications.

7. 7
The Equifax Breach – A Timeline
March 9th:
• CVE-2017-5638 was published.
• The Apache Software Foundation released a patch for the vulnerability.
• Equifax administrators were told to apply the patch to any affected systems.
March 10th: Hackers gained access to Equifax’s systems.
March 15th: Equifax's IT department ran a series of scans to identify unpatched systems.
May 13th: Hackers begin exfiltrating data.
July 29th: Equifax renews their expired public-key certificate
September 7th: Equifax publicized the breach

8. Incident Aftermath
145 million
People affected by the breach.
$3 billion
the amount Equifax spent upgrading its
security and resolving consumer claims

9. 9
Act Fast
Exploits are public for everyone
Continuously Monitor
300 new vulnerabilities published every month
Get the Basics Right
Millions spent on security gear but it was poorly implemented
#1
#2
#3
What Can We Learn?

10. 10
2
SmallComp’s M&A

11. SmallComp’s M&A
• SmallComp required to do an open-
source audit
• Each component comes with certain
terms
• Found a dependency licensed under
AGPL
11

12. $4M Dollars in Escrow
12
• Terms of the escrow:
• Remove any trace of AGPL from the
software.
• 80% of customers must deploy the
updated software to production.
• Two year timeframe.
• Development/deployment-related
costs taken from the escrow.

13. 13
Solving The Problem
Isn’t So Easy
Two main obstacles:
• Development + QA time is 1 year for 1 person
• SmallComp’s customers are hospitals, where
solutions are often manually deployed and
technicians are required to train staff

14. They Did It!
SmallComp was able to fulfill the terms of the escrow
after 1 year and 8 months!
14

15. 15
Set Clear Policies
for the whole company in regards to licensing
Communicate
the company’s policies to developers
Enforce
make sure your policies are being enforced
#1
#2
#3
How Do We Avoid This Situation?

16. 16
3Staying Secure

17. Step 1:
Create Transparency
• Transparency is the baseline to everything
• How can you detect and solve issues in your
open-source components if you have no idea
what they are?
• Understand exactly what you’re using:
• Direct Dependencies
• Transitive Dependencies
• Source files
17

18. 18
Lots of jars
?

19. 19
Lots of jars, but lots more java beans
?

20. Step 2:
Detect Potential Issues
• Match your components to the most
comprehensive DB possible:
• Published CVEs
• Vulnerabilities published in security advisories
• Vulnerabilities detected by research teams
• Thorough license detection
20

21. Step 3: Prioritize
How would you prioritize your vulnerabilities?
21

22. Step 3: Prioritize
• Prioritize by:
• Business risk
• Exploitability
• Severity
• Effectiveness
• Availability of fixes
22

23. 23
Vulnerabilities Prioritization

24. 24
After testing 2,000 Java
applications, WhiteSource
found that 85% of all
detected vulnerabilities
were deemed ineffective.

25. Step 4:
Execution
• Understand the best path to remediation
• Upgrade the component’s version?
• Change the component?
• Set up an external defense?
25

26. 26
Create
Transparency
Detect Issues Prioritize Execute
1 2 3 4

27. Let’s Talk About
Implementation!

28. Step 1 : Creating Transparency
Identify the processes in your software development lifecycle (SDLC)
28

29. Step 2: Detect
• Where you want to implement security checks
• Where you can automate
29

30. Development
30

31. Build
31

32. Deploy
32

33. Maintain
33
New vulnerabilities are constantly
being published

34. 34
Step 3: Prioritize
• Act on early -> Shifting left
• Avoid allowing vulnerable components
reach deployment
• How much does it cost?

35. 35
Detect Issues As Early As Possible

36. Step 4: Execution
Who’s responsibility is it?
• Security team:
• Setting policies
• Educating developers
• Development team:
• Execution
36

37. 37
Developers need robust tools,
that fit into their workflows

38. 38
Educate
About the basics of open-source security & compliance
Empower Teams
By providing them the right tools
Enable Success
By creating a shared mission
#1
#2
#3

39. Don’t Be That Guy
39
“

40. Q & A

41. Thank You!
41
For more info please contact us:
product@whitesourcesoftware.com