What does the GDPR have to do with Open Source Software (OSS)?
Developers use OSS to speed time to development so that they can focus on writing code that gives them a competitive advantage. In fact, open source is so widely used, that according to recent research, about 80% of a software application is made up of open source components. While this is great for providing speed and efficiency, it can cause some issues because not all open source components are created equal. Some components have security vulnerabilities and sometimes developers choose a vulnerable version involuntarily. Without empowering development teams to choose the right, healthy open source component, vulnerabilities can be exploited and personal data can be stolen.
With the advent of GDPR, if that happens, organizations will be liable for huge fines.
The GDPR legislation forces organizations to protect dataArticle 25: Data protection by design and by default.
Privacy by design as a concept has existed for years now, but it is only just becoming part of a legal requirement with GDPR. At its core, data protection by design and default calls for the inclusion of data protection from the onset of the designing of systems, rather than an addition. More specifically - "The controller shall... implement appropriate technical and organizational measures... in an effective way... in order to meet the requirements of this Regulation and protect the rights of data subjects."
How can OSS make data unsecure?
Open source software can be manipulated based on known security vulnerabilities to gain unlawful access to data. One type of attack into open source software is Remote Code Execution (RCE). This means that arbitrary commands can be appended to the legitimate command and executed on the target system without validation. For example:
<genuine command/payload> + <appended hack command/payload>
The commands can be serialized so it can be very difficult to find the appended command. For example, if I was to append 'mysql && SHOW DATABASES;' I would be shown a list of the databases*. I could then begin mining for tables within the listed databases and then within the tables for, you've guessed it..... I would have unlawful access to DATA!
Equifax would be liable under GDPR
A recent example of this type of exploitation that hit the press in September 2017 was the data breach at Equifax. 143,000,000 million personal data records were extracted over several months without Equifax knowing. This breaks a lot existing legislation but had GDPR been in place, an estimated fine upward of €60M could have been imposed.
The saddest part of the Equifax breach is that is was entirely preventable with the right processes and tools in place. Equifax was not able to identify and isolate the vulnerable open source struts2 component in its application landscape (see CVE-2017-5638). If Equifax had known what open source components were in their software and systems via a software bill of materials, they could have reacted very quickly, patching the issue at the point of disclosure, avoiding the data breach and eventual loss of their CEO and CISO.* This example assumes MySQL was initialized as unsecure. However, obtaining the password for the MySQL user is relatively simple if the web container is running as a superuser.