Compliance & Risks
Manage Open Source Code Security Risks
Open source code is in the vast majority of commercial softwares today. Learn best practises to mitigate the unique risks that accompany its use.
Save to Folio
The adoption of open source code has increased exponentially over the past decade, with a large percentage of commercial software now containing it. Developers are constantly sharing common features and code functionality across the internet and globe. The speed and demand placed upon application teams is high – business used to run via application releases a handful of times per year, and now is done a handful of times per week or day. This rapid acceleration pushed the world to move from “waterfall” and “iterative” project methodologies to “agile” to meet the rapidly growing demand.
Open source code comes from a myriad of sources. Code reuse, 3rd party libraries and developer downloads tend to dominate the landscape. Also, realise your consultant working on the project you are paying them $250/hour for is using the same code they did on the other client project they did last year, as reuse of code from one project to another is common (after all, if it work for Client X’s project, and Client Y is doing something similar, let’s re-use the code and save money):
Take Capital One Bank as an example of this. In the 2010’s they followed the waterfall methodology. The organisation lives in the heavily regulated financial industry and is currently using Open Source as a part of their day-to-day work – even having built large components of their platform off it. In 2012 they were not open-source friendly with a “say no to open source” company mindset. Eventually, they realised they were using:
- Java (open source)
- Linux (open source)
- Apache (open source)
- Eclipse (open source)
They realised quickly they were building their environment off of open source. Through a migration from commercial source code management to subversion and their own architecture, they were able to launch their production applications (built in house) with open source code as part of the foundation. With specific processes put in place to mitigate the risks associated with open source code use, such as legal review, they were able to successfully execute without breaches or “secret” code releases.
Value of open source to Capital One: “Using Open Source software gives us numerous advantages from a business perspective. Open Source gives us the ability to re-use what already exists and works well, with full flexibility to customise and/or contribute back what we need for our business. It also means that we are inherently building with technology that a broader community is investing in, dramatically reducing the likelihood that we are relying on end of life tech as well as making us more permeable to the larger talent ecosystem” – John Schmidt, Product Manager Capital One
Open source isn’t completely free:
A common misconception of open source code is that it is “free”. Like a free puppy, its great to get, but then you still have to care for it and feed it. To benefit from open source code use, you need to get the right people, and tech involved to mitigate for the unique risks associated with it.
Legal Open Source Risk:
- Licences: Authors of software have rights to their code.
- Permissive (giving credit) vs. Copy left (distribute and show source code + share code being touched)
- Using code is as-is (no recourse to the author)
- Request changes or pull requests
- Trade secret disclosure (IP infringement)
- Devaluation of patent portfolio
- M&A Impact
- Reputational risk
In fact, many large companies such as Capital One and Facebook have Open Source legal counsel on staff. They hold the position of “law and technology counsel” and advise on the above legal issues. For example, during a Merger & Acquisition they will advise on any open source issues during due diligence and then after the acquisition, work in partnership with the integration team.
Open Source Security Risks:
- Vulnerabilities – average of 64 vulns per code base. 1500+ days before a fix. Development processes are your first line of defence.
- You build it you own it
- Software of unknown origin
- Continuous monitoring of config and environment
To mitigate the risks, usage of Open Source repository scanning technologies is mandatory. A service which is able to find manifest files (identify and analyse), understand the direct and indirect dependencies (and flag them for known vulnerabilities) is a must. Having integration into your code repository also helps identify your risks tied to your projects. Then building the issue findings into your ticketing system (or creating pull requests) for remediation, at the developer level, is the next step to ensure the code has ownership and is cared for during its lifecycle. Maintenance and auditing (remediation) of this will be required because every time the same pull request happens, as scan and updated patch request must occur there too.
Building a culture amongst your organisation to have ownership of code, the maintenance of it, and pride in the application from release to release will take time. It is paramount to making Open Source more secure though, as the ownership and pride will help keep it secure. Implementing the technology cheques on top will assist in keeping the teams involved and more secure, as will doing this continuously.
4 best practises to mitigate open source code vulnerabilities:
- Identify: Maintain open source inventory
- Analyse: Track open source vulns and licences
- Remediate: Fix and patch, upgrade
- Audit: Continuous monitoring
To help prevent the costly mistakes that open source vulnerabilities and licence risks can cause, SecOps teams can implement a solution like Trend Micro Open Source Security by Snyk. This helps secure open source inventories throughout the application development with increased visibility for earlier identification and continuous monitoring to minimise exposure over time.