Open source code is a valuable resource that can be used in your project to improve the quality of your work. However, there are a few things you should keep in mind when using open source code.
- Make sure you are aware of the risks associated with open source code. This includes understanding the potential vulnerabilities that could be exploited, and being familiar with the coding standards used in open source projects.
- Be aware of the potential for conflict between different groups of developers working on your project. If there is a disagreement over how to approach a particular task or feature, it could lead to problems down the road.
- Be careful about who you trust with your open source code. Do not put your trust in people who you do not know well, or who may have other motives for sharing your code with others.
Coding Before Open Source
Once upon a time software developers wrote everything from scratch. Then code libraries, toolkits, and other add-ons started to appear. You could get a leg up by using a toolkit to provide some functionality, such as a reporting module or an interface widget. You could pop these into your project as ready-made fully formed components and use them straight away. The alternative was to waste time, money, and development effort reinventing the wheel.
Of course, over time you’d build up your own library of routines and modules that had been written in-house. So when you were developing a new code routine or interface element, you had three options. Write it yourself, reuse some previously written in-house code, or buy in a library or toolkit.
The Rise of Open Source
The advent of open-source code changed all of that. Open-source software makes the source code to a project freely available for use by others, within the limits of a—usually benign—license. The growth and uptake of open source have both been staggering. The word proliferation doesn’t seem to cover it. There has been a phenomenal increase in open-source software, and not just in terms of the mind-boggling number of open-source projects and products that exist, but also in the use of open source within commercial products.
Open-source software hit critical mass a few years ago, and it has rocketed from a niche position on the sidelines to a fully embraced mainstream development resource. Because it was driven and developed by a community and not a traditional commercial enterprise, it was regarded as well, sort of amateur.
Now it feels like open source has grown up and matured. And it has. But the biggest change has been a wider appreciation of open source, an understanding of the benefits it brings, and recognition that including open source in your product isn’t anything of which to be ashamed.
Estimates suggest non-trivial software projects are writing about 20 percent of original code at most. The other 80 percent is open source. The major open-source repository hosting site, GitHub, hit over 100 million repositories in 2018. And there are many other hosted Git platforms, such as GitLab and BitBucket.
Open source is a software development phenomenon. But it’s not all roses in the development garden. There are issues that you need to be aware of, and manage.
The Security Issues
Using open-source components in large software projects reduces development costs, shortens the end-to-end development time, and—it has been argued—promotes innovation. Because it frees your development staff from the mundane, it allows them to focus on the unique and market-attractive aspects of your product.
There are some open-source products that have a commercial entity behind them. The organization releases their product under a dual-licensing scheme. A commercial version will have an official, professional, support channel, and may contain other benefits like proprietary extras that are bundled with the product. They also release a community-supported version that will benefit from the coding efforts of the commercial team as well as from the contributions from its own community. Significant community contributions will also make their way back into the commercial version.
However, the majority of open -source projects are completely community-driven. They may have the backing of commercial entities, but that backing is donations and sponsorship, not code contributions.
Regardless of their provenance, the open-source components that are chosen to be included in new development projects tend to be well-established and reputable projects in their own right. They have earned a high degree of trust. But that isn’t always the case. Sometimes the functionality you need is available, but it is contained in a new and somewhat unproven project. But you’ve got the source code, right? You can do a code review of it.
From a security viewpoint, open source is neither more, nor less secure than proprietary home-grown code. It’s all human-written code after all. Advocates of open source point to Eric S. Raymond’s law that he named in honor of Linus Torvalds, which states that “given enough eyeballs, all bugs are shallow.” With enough people reviewing the code and beta-testing it, issues should be identified, characterized, and fixed quickly.
That’s true as far as it goes. But security issues are not necessarily bugs. A vulnerability can be a circumstance that arises as a side effect of complex logic in a project of many source code modules amounting to millions of lines of code. The product does what it is supposed to, and so it is seen to be working as intended. And so it passes code review, product verification, field testing, and gets a clean bill of health.
Outside of blind luck and happenstance, that review, test, trial, and release loop won’t unearth security vulnerabilities.
Why Open Source Is Attractive to Hackers
Moreover, there are aspects of open source that are positively attractive to hackers and threat actors. They can see the source code, too. They can look for vulnerabilities with a different mind-set than the average community contributor who, although they may well be a competent developer, is unlikely to have any real security background.
Of course, contributors to open source come in all flavors with varied backgrounds. Some of them will undoubtedly have real-world security experience—but they’re going to be the minority. Threat actors are another beast altogether. And they’re not limited to finding vulnerabilities, they can inject them, too.
There have been many cases where a threat actor introduced a vulnerability via a patch they created and submitted to a project. It made its way through code review, into the code-base, and into the next release of the product.
Perhaps the ultimate example of this was a JavaScript component called event-stream. This open-source project was maintained by a single developer. The burden of stewardship of the project outgrew him. He was persuaded to hand it over to a new maintainer.
The new maintainer was a threat actor. They took over the project, ran it as normal for a short period, then added malicious code to it. Every copy of every other program that used that software component was quietly hijacking certain types of Bitcoin wallet for the threat actor.
What You Can Do to Reduce the Risk
As with many aspects of security, you manage this risk by applying controls. That requires governance—in other words, policies and procedures. Thankfully, there is software that can help.
Create an Open Source Register
You need to quantify the open source you are using. Create a register that lists the open-source components you use in your projects. List each open-source component, the version or versions you’ve used, the projects you’ve used them in, what the latest version is, and where it can be downloaded. In the design documentation for each of your projects, you should list the open-source components that are in use.
The devil is in the details. Don’t forget the dependencies and hierarchical nature of much of open source. Open-source projects often use other projects within themselves, nested like Russian dolls, or they require other open-source components to be installed on the target machine so that they can make use of them.
Drill down into these dependencies, and list them in your open-source register.
Run Automatic Audits
Vulnerabilities in open-source packages are a major issue for NPM, the package manager for JavaScript. To address this, they created an automatic audit tool that will scan for out-of-date packages with security updates.
This, of course, has its limitations, and it’s important to be conscious and not rely entirely on automatic tooling. It will only catch packages with known vulnerabilities and updates. If the package has a vulnerability, but hasn’t been updated to fix it, NPM audit will tell you nothing.
RELATED: Audit Your NPM Dependencies, They Account for 86% of Security Bugs
Create a Vulnerability Map
Your open-source register gives you a clear picture of the open source that you use. The next step is to map known vulnerabilities onto that register. Sometimes, these can be discovered by visiting the project’s home page and looking at the known issues list.
The National Vulnerability Database (NVD) will give you a much more granular picture. You can use their search page to look up products by name to find out which Common Vulnerabilities and Exposures affect that software component. The NVD is a great resource, even if its format does take a bit of unraveling until you get used to it.
Update Your Register and Vulnerability Map
Of course, this is something you need to keep on top of. New vulnerabilities are discovered all the time, so the security state of your product at launch is likely to slowly erode over time.
Recognizing this new need, there are commercial (Black Duck, WhiteSource) applications that will help with this. They can scan your projects and identify open-source code, and look-up vulnerabilities automatically. Some of these (FOSSA) offer a free tier.
Static analysis of your codebase—including the open-source components—should be a standard part of your development rigor, anyway. Tools like Coverity Scan can find defects in your code like buffer overflows that can lead to vulnerabilities. It will even advise on how they can be rectified.
Check the Open Source Licenses and Adhere to Them
Ensure you understand the licenses that are in force on the open source that you use. There are many different licenses, so check that you are complying with all of the requirements. Involve your licensing or compliance officer, if you have one.
Not complying with an open-source license can lead to litigation. Open-source projects are as quick to respond to breaches of licensing as commercial software houses.
Update Your Open-Source Components
As vulnerabilities are fixed by the communities of the open source you use, make sure you upgrade your versions so that you benefit from those fixes. Open source uses a “pull” model. They announce a new fix and then you have to go and download that new version. This is the opposite of much commercial software that has a “push” model where updates are transmitted to the registered users.
Monitor the project pages for new version announcements, and download and test the new builds.
The Cost of Open Source
Open-source software is free to obtain, but it comes with a management and governance overhead. The implications have to be understood and controlled in order to use it safely and with minimum risk.
