Open source continues to transform how we architect software solutions in every industry. Black Duck’s 2017 Open Source Security and Risk Analysis of over 1000 commercial applications revealed that 96% of applications scanned utilised open source. While the rate of open source reuse has been steadily climbing over the decades, policies, procedures, and safeguards for the responsible use of open source has lagged.
This manifests by developers failing to use open source in compliance with the myriad of license types governing use of that code, and through their reuse of open source code without appreciation for, or the ability to track and remediate, known or later discovered security vulnerabilities in that code. Of the applications scanned in Black Duck’s 2017 survey, 67% contained known open source security vulnerabilities, with 52% of those rated as severe. On average the vulnerabilities identified had been publicly known for over four years.
Un-remediated known vulnerabilities can cause serious damage. The massive Equifax data breach that exposed the private data of 145.5 million people was due to exploitation of a known vulnerability (CVE-2017-5638) in Apache Struts, a free, open source framework for creating web applications. Apache Struts is widely used across the Fortune 100, powering front-end and back-end applications.
It is important to emphasise that open source is no less secure than proprietary/commercial code. Nearly all open source vulnerabilities are patched soon after the vulnerability is disclosed. But unlike commercial software – Microsoft software for example – critical open source security updates are not pushed to users as they become available. It’s up to open source users to know what open source they are using and to stay on top of the various patches, fixes and upgrades made to their open source packages.
Returning to the Equifax breach, it is clear that Equifax exercised wholly inadequate measures for tracking and managing the open source used in their critical applications. It should be expected that in situations where companies are trading in extremely sensitive and valuable personal data, that all adequate measures would be deployed to protect that data. However, Equifax appears to have failed to take basic steps to identify what open source they were using and where they were using it. This lack of visibility and awareness made it impossible for Equifax to identify where they were using Apache Struts and take the necessary steps to patch the publicly announced vulnerability in Apache Struts.
The key here is not only having the ability to track open source reuse and remediate known vulnerabilities, but also having the ability to do so extremely quickly. As mentioned above, Apache Struts is a very popular and widely used open source component. Hackers are aware of this and, when a vulnerability is publicly announced in a widely used application, a race ensues between the hackers and the user. Hackers want to exploit the vulnerability before the user can patch and remediate the vulnerability.
Since Equifax appears to have had no actionable inventory of what open source was deployed in their environment, where, at what revision level, etc., they had little chance of timely identification of where Apache Struts was being used and then deploying the necessary patch to fix the exploited vulnerability. In fact, reports indicate that there was a many month’s lag between when the vulnerability in Apache Struts was first publicised and when Equifax finally remediated the vulnerability. Again, given the nature and sensitivity of the information put at risk, one would expect processes in place to immediately identify and patch at-risk software components, including open source components. This management breakdown appears inexcusable.
What would have happened if the General Protection Data Regulation (GDPR) had been in effect at the time of the Equifax breach? We will focus on Article 32 of the GDPR. Below is the text in part. To read the complete regulation, click here.
Article 32: Security of processing
The controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including:
1. The pseudonymisation and encryption of personal data
2. The ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services
3. The ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident
4. A process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.
Taking number 4 above in particular, there are a few key steps you must take to ensure your business is prepared to support your GDPR initiatives and to maintain compliance.
Visibility is critical. You must have a complete inventory of the open source in use at your organisation, otherwise you are leaving your applications and your organisation at risk.
Inventory and audit software assets. Manually cataloguing the open source components comprising your applications often results in errors and omissions, and quickly becomes outdated in an agile development environment. Automatically identifying components by their unique file signatures and evaluating the vulnerabilities and risks attributable to third-parties that interact with sensitive data either through vendor relationships or APIs is the best way to mitigate risks.
Establish policies to support compliance. Institute controls and policies to manage risk before your applications and data become vulnerable to attack. Automated policy enforcement and policies integrated in development and deployment tools enable security and legal teams to support GDPR compliance by preventing vulnerable open source components from entering your applications. Structure policies at your organisation based on development phase, deployment model, vulnerability severity, component version and release date.
Monitor for vulnerabilities. Ongoing management of vulnerabilities is a significant aspect of GDPR compliance. On average over 30 new vulnerabilities were reported every day, a significant challenge for any legal or development team. Automatically detecting new open source vulnerabilities that impact your codebase, identifying impacted applications and components, and notifying development, operations, and security teams of any issues is key to preventing a massive breach like the one at Equifax.
The GDPR mandates that all companies processing and holding the personal data of European citizens must protect that information — regardless of where it is sent, processed or stored — and proof of protection must be verified. Once this regulation goes into effect, the penalties for non-compliance can be severe. Organisations can be fined up to 4 % of annual global revenue or up to €20 million (approximately 22.3 million USD) for breaching GDPR, whichever figure is higher. Would you be willing to bet whether appropriate security under GDPR will include open source vulnerability management?