GDPR Compliance and Open Source

Data privacy and controls are a continuing trend that is occupying consumers and organisations alike. After years of preparation and debate, the General Data Protection Regulation (GDPR) was finally approved by the EU with enforcement starting as early as May 2018, at which time those organisations in non-compliance will face heavy fines. GDPR does not only affect companies operating within the EU — if you collect the data of European Citizens the new rules apply to you. As predicted, the EU confirmed its decision to go for hefty fines for non-compliance, with companies needing to pay up to 4% of their global revenues or €20 million, whichever is greater. A fine of this magnitude could put many firms out of business.

Under the new GDPR rules, the recent Equifax breach would need to be handled very differently. Perhaps Richard Smith, CEO of Equifax would not be starting retirement early if the notification to the public had happened within the first 72 hours of the breach, instead of the 40 days it actually took. Under GDPR Equifax would now need to prove that they “implement technical and organisational measures to ensure a level of security appropriate to risk” per Article 32. Furthermore the GDPR legislation places the burden on organisations to continuously adjust their security to the state of the art of their business domain.

As Equifax found out to its detriment, one of the areas most rapidly evolving inside organisations is the use of open source, where vast amounts of open source are pulled to achieve agility. However, developers generally lack the guidance and oversight to know if open source imposes compliance and security risks on their organisations let alone have time to keep up to date with the latest versions to remain vulnerability free.

Verizon research shows that “Most attacks exploit known vulnerabilities [in open source components] that have never been patched despite patches being available for months, or even years”. Heather Adkins (Google Information’s Security Manager) has also talked specifically about the importance of keeping dependencies patched and up-to-date “I think it’s the cost of doing business with open source software. The reality is that we have to stay on top of it. Even if you’re just two people in a garage, one of you need to be in charge of security, whether it’s part time as an IT person or as a lead software developer.”

It is therefore no surprise that this problem is highlighted in the OWASP Top 10 Application Security Risks for 2017 — ‘A9 – Using Known Vulnerable Components’, and organisations can no longer afford to not make this a top priority.

Some of the technical measures that an organisation could implement to ensure a level of security appropriate to their risk is to use automated security tools and better processes that will:

• Track known vulnerabilities across the different tech stacks

• Help developers find existing vulnerabilities, easily fix them and prevent new ones from being introduced

• Be integrated into the developer’s workflows and tools

• Focus on the developer UX, so developers adopt them en-masse, and allow security to grow at the scale of development teams rather than security teams

• Be simple to use, so they don’t require security expertise

And this is exactly where Snyk comes in, and why we have made the decision to make tools that are focused on the developers. Snyk does not just report vulnerabilities for developers to ignore, Snyk automates fixing them. Protecting the full app lifecycle, from early prevention on commit hooks, through compliance gates in CI/CD, to monitoring for vulnerabilities in deployed PaaS and Serverless apps.

Heather Adkins is right: keeping on top of your dependencies to make sure they’re up to date and secure is the cost of doing business. The cost of not doing it is much higher.