It might now seem like a distant memory, but it wasn’t too long ago that many enterprises viewed open source software in a negative light. Former Microsoft CEO Steve Ballmer famously called it a “cancer,” and developers relied far more heavily on proprietary code than open source when building products.
Today, of course, we live in a world where open source’s value is unquestioned. 90% of all cloud workloads use Linux (an open source operating system), and 82% of the smartphone market uses open source. Those numbers make clear that open source is used in every corner: personal computing, smartphones, embedded devices, the cloud, business services, and more.
If your organization has a DevOps function, then it’s extremely likely that you will have a significant amount of open source code in your internal systems, apps, commercial products, and in any place where your organization uses or produces software. There are many reasons why open source usage has grown so rapidly, including the fact that it’s often more secure than proprietary code, it accelerates software development, and above all else, it’s really cost-effective. Smart developers don’t reinvent the wheel. They instead use open source code that has already been built to perform a function, rather than writing it from scratch themselves.
But there are also a few roadblocks that can prevent organizations from taking full advantage of open source’s many benefits. Two of the biggest are license compliance issues and security vulnerabilities. Unless properly managed, compliance and security challenges can slow the software development lifecycle (SDLC) and prove quite costly. Let’s face it: No CEO wants a data breach on their watch, let alone a GDPR fine or reputational damage to their firm.
Here’s the good news, though. Companies can reap the benefits of open source while staying both compliant and secure. In this blog, we’ll explore five key strategies to tackle these common open source challenges and help your business get real value from open source software. You can also watch the on-demand version of our webinar on this subject by clicking the link below.
1. Check for Compliance and Security Threats Everywhere in the Software Development Lifecycle (SDLC)
Many businesses used to wait until the end of a release run before conducting a thorough audit of their open source components, sometimes up to three or six months. That’s generally no longer the case today. But if you’re still waiting for the end of a sprint or, even worse, the end of more than one sprint before doing license compliance checks, you may be forced to redo some or all of that work.
Instead of waiting, it’s best to build license compliance and vulnerability analysis directly into release cycles or iterations — the earlier the better. (This concept is also known in some circles as “shifting left.”) If you can get feedback directly within your development environment, you don’t even need to push that inappropriate license into your Continuous Integration and Continuous Deployment (CI/CD) solution, such as Jenkins, CircleCI, Travis, GitLab, BitBucket, or whatever system you’re using.
You want to be able to iterate your compliance and vulnerabilities in real time or as near to real time as you can. Think of doing compliance in every iteration — in other words, continuous compliance as part of continuous delivery. By building vulnerability and license compliance management into your software delivery cadence, you can significantly accelerate and de-risk development.
2. Consider Your Licenses Carefully
You may be drawn to a certain open source library. But before deciding to use it, keep in mind that it brings with it all kinds of dependent libraries. Many companies do not realize this and do not have practices in place to scan open source software for licenses and determine which licenses they should and should not use. This could be for a host of reasons. Businesses may not have open source license compliance policies, they may lack governance, and they may not understand the impact those licenses have.
Numerous open source licenses have been endorsed by the Open Source Foundation, but a lot of those licenses are actually pretty restrictive. You would think “free and open source” would mean you’d be able to use the software without restriction, but some licenses come with strict limitations.
For example, some licenses stipulate that the software is free for personal or educational use. But as soon as you’re generating revenue from the use of that library, you have to commercially license that particular component. Other licenses say that if you embed the software even indirectly into your app, you have to release your whole app source code back to the community, even proprietary business logic.
There have been situations where organizations have had to publish their intellectual property on the internet because they didn’t properly consider the ramifications of using open source with a strong copyleft license — or they unwittingly pulled in some dependency with a strong copyleft license.
This can have a major impact on both competition (imagine handing your valuable intellectual property over to your competitors because you weren’t aware that the open source code you used had that license obligation) and brand perception. Failure to spot those restrictive requirements could therefore severely impact your business.
3. Automate Compliance and Security
Of course, manually recording every single dependency and staying on top of every compliance obligation and potential security vulnerability is a massively time-consuming task. If you have something that’s 10 levels of abstraction away from what the developer thinks they have in their software, are they really going to the 10th level of abstraction for that commit? That’s impossible. All organizations face the constraints of time and money, and it’s impractical for developers to do this without help.
That’s why automation is so important. Software composition analysis tools, such as FOSSA, give businesses full visibility into all of the open source components in their builds, including deep dependencies (open source buried in other code) and security vulnerabilities. Some even have policy engines that can automatically deny, flag, or approve any license or dependency that can be used with your project. Using such a tool is the only way to scale effectively.
From a security perspective, it’s worth noting that two of the biggest and most public breaches in recent years occurred as a result of “bad actors” hacking open source code as THE route into their targets. (British Airways was hacked into via the “Modernizr” open source JavaScript and Equifax via open source “Apache Struts.") Having a solution that can automatically detect and surface likely security vulnerabilities, while also providing the specific remediation path, is crucial for many, often overloaded, security teams.
4. Be Proactive to Avoid Unsupported Libraries
At some point, your organization might find itself in a situation where the core maintainers (or the company backing) an open source project decide to stop supporting it. This may sound like a frightening possibility, but you have a few options to avoid a security or operational breakdown.
- You can invest your own time and resources and continue maintaining the open source project
- You can find a supplier to do it
- You can crowdsource development resources to reinstate support of the project
With that said, it’s best to be proactive. Open source projects contrast with some proprietary software in that they generally don’t have a known end of life. So, if you have a lot riding on a given open source project, it’s worth checking periodically to make sure it’s still vibrant. If there are fewer contributors, fewer commits, and a lower release cadence than there once was, try to identify an alternate option that’s functionally equivalent where you have the source code and a community to support you if something goes wrong.
5. Implement Continuous Monitoring for Security Vulnerabilities
Some programming languages and ecosystems are more afflicted by security vulnerabilities than others, but there’s risk across the board. And, in our fast-moving development world, what’s secure today might not be tomorrow. That’s why continuous monitoring for vulnerabilities in third-party code is so critical. Even if the version that you’re using is stationary, a bad actor may find another attack vector. You’ve not changed anything, but you still face a new vulnerability. Ultimately, it’s best to check for vulnerabilities on an ongoing basis, at least daily. (This is where a tool like FOSSA Vulnerability Management, which has continuous automatic monitoring, can be a big help.)
Make Open Source Work Harder for Your Organization
Watch our on-demand webinar, Maximizing the Value of Open Source, for additional information on how to use open source software more effectively in your organization, including:
- Service meshing and the future of open source
- The importance of a software bill of materials
- New attack vectors and how to prevent bad actors from exploiting them
About the Authors
Marko Bocevski is the CTO and founder of Keitaro, a specialist open source company that provides clients with best-in-class applications and services. Prior to Keitaro, he held various technology and IT services leadership roles in global organizations with a strong go-to-market and customer focus. With vast experience in open source software, cloud solutions, application lifecycle management, and service management, he has been leading Keitaro’s very successful growth since its start back in 2012.
Ryan Sheldrake is a technology evangelist and industry thought leader. Having worked in a multitude of roles in a career spanning 20+ years, from Operator to Principal Architect and across the financial, retail, and defense verticals, he brings a wealth of knowledge about IT design and delivery.
