With GDPR coming into play May 2018, companies doing business in the EU face the prospect of fines and damaged reputations if they cannot prevent vital corporate and customer data from falling into the wrong hands.
Things are moving fast. Digital disruptors are slamming through traditional industries with a relentless fervour. Companies that develop cutting-edge solutions are under constant pressure to release software faster and improve quality. These businesses have a keen understanding that those who build the best software, fastest will win.
Innovation and speed are critical, but they cannot come at the expense of risk management. Balancing speed with control has become a continuous challenge for developers and the growing DevOps community.
Regulatory ripples in the fabric of innovation
In Europe, the situation has been compounded by companies having to comply with new legislation — none more so than GDPR (General Data Protection Regulation). Coming into force in May 2018, GDPR will strengthen EU data protection legislation and subject firms to severe penalties, should they fail to comply. With the fines for a data breach standing at $20 million, or 4% of annual turnover (whichever is higher), the protection and security of data is now of paramount importance for businesses.
The severity of the potential fines was recently put into perspective when Equifax delayed the public disclosure of a massive application breach by a month. Under GDPR rules, businesses are required to notify the public within 72 hours or face severe penalties. Equifax’s decision to drag its heels and wait 40 days to disclose the breach would have led to a $60 million fine for withholding that information.
In addition to the regulations surrounding public notification, Article 25 of GDPR mandates that data protection be implemented ‘by design and by default.’ As a result, it is imperative that organisations ensure software applications are secure throughout their lifecycle, with data protection measures designed in from the very beginning.
The pulse of innovation
Article 25 has a direct impact on today’s application development practices. What most people outside of development do not realise is that software is no longer written from scratch. Instead, it is largely assembled from open source and third-party software components, which enable businesses to accelerate innovation, improve quality and maintain a competitive edge. Today, these components make up 80 – 90% of a modern application.
To deliver perspective that hits closer to home, Sonatype estimates that the average development organisation downloads over 200,000 open source and third-party components each year. While the vast majority of these components are good, some are not.
Building vulnerabilities in from the start
Research from Sonatype has revealed that 1 in 18 components contain known security vulnerabilities on the day they are downloaded. Furthermore, our analysis of 17,000 applications showed that the vast majority of vulnerable components are not vetted at quality and security control gates throughout the development lifecycle before they are deployed into production. This means known vulnerable components are electively being built in from the start and shipped to consumers.
Most organisations are not yet paying sufficient attention to the quality and security of the components their developers are consuming, but their adversaries are very aware. Over the past few years, hacker attack vectors have shifted away from the network to applications. Recent reports from Forrester Research show that application-based attacks are now the most successful exploit path.
To make matters worse, many organisations have no guidelines for component use. Sonatype’s 2017 DevSecOps Community survey revealed that only 57% of organisations have policies in place to govern quality and security of open source components being used by their developers. For the remaining 43%, quality and security control gates have not been employed. Companies which have been lax in their control of open source components will need to pick up their pace on the road to compliance under GDPR’s secure ‘by design and by default’ requirement.
Four considerations for compliance
To adhere to GDPR’s Article 25, secure practices need to be initiated from the beginning and throughout the development lifecycle. To improve compliance, consider these four things:
1. Source secure components from the outset. CIOs and CISOs cannot assume that open source components downloaded by developers from the internet are free of security vulnerabilities.
2. Create a software bill of materials to track component use over time. This way components age and security vulnerabilities can be discovered over time. Components greater than three years old have 3x the vulnerability density of later versions.
3. Shift security investments to where the attackers are focused. Web application firewalls, network and endpoint security tools, and even hardened operating systems are not enough to defend against attacks that are aimed at applications.
4. Automate tracking and control of components across the lifecycle. The volume of software component consumption by the average development organisation is too large to keep up with through manual reviews. If a component once thought to be safe is discovered to be vulnerable, expediting an update to a safer version will be time critical in order to thwart attacks.
With Article 25 stipulating that data protection should be a core business process, all companies operating within the EU will need to ensure new practices are put in place to ensure security is built in from the beginning.
Sourced by Derek Weeks, vice president of Sonatype