Before using open source in your offerings, you need to make sure that the software won’t break your — or your customers' — system security requirements.
To gain confidence in the security of Open Source software projects, consider the 3 A's of Open Source Security -- Assess, Adopt, and Act -- which are explained in this video:
Video will open in new tab or window.
In this article, I discuss some high-level risks associated with using open source software and provide assessment exercises to help you mitigate those risks.
How to reduce risk
Just because an open source project is popular doesn’t mean it meets your company’s security requirements. Other consumers of this package might not have the same security requirements as your business. The temptation exists to just download and use the package because you want it “the same as it is everywhere else.” However, open source software that is meant to be used by a single user or distribution often does not meet the quality of service and security requirements an enterprise would have. Keep in mind that, while open source code is open for anyone to see, each community has different ways of searching for and prioritizing security fixes or features.
Assess the security features of the open source software
Specific risks:
Open source software might not provide design and architecture documents that you can review to understand the security objectives and features.
Formal threat modeling is not always being performed.
Exercise 1: Assess the design
“What? How can I design something I didn’t build?” If you could update the source code, what security features would you add that are missing? Security characteristics of code, including ported code, are normally considered during the design phase. Architecting security into source code later is risky and high-cost.
Simply asking what you would change might help you identify gaps. If you are not in a position to update the code, could you make configuration or environmental changes that increase security or reduce risk? For example, if the open source package opens a port, you can prevent that with a system-level setting. Another question to consider: Is there additional testing you can perform to mitigate risk?
Exercise 2: Do an initial cost assessment early
When making a business case for using open source software, you should consider the cost of securing the package. Imagine after performing an assessment of security features you realize you need to supplement the open source package with a plug-in module that you either need to build or buy.
You should repeat most of the exercises in this article when you download newer levels of an open source package. This adds an operational cost.
Exercise 3: Take up threat modeling
Even though you did not write the code, you could create a threat model based on the documentation or code available to you. If this feels out of touch with reality, keep in mind that a threat model exercise provides you with a list of questions to help you assess the security of an application or system. It also helps you think about the threats relevant to your environment. If you can’t easily answer some of those questions, it indicates you don’t really know the security posture of the open source software you intend to use. Isn’t that, perhaps, a worse problem? See OWASP for more information on threat modeling.
Get to know your partner
So what happens when a security vulnerability in open source code is found, and what does the community do about it? Publishing the vulnerability in a GitHub issue or on a public Slack channel can publicize the vulnerability before a fix is ready. A bad actor could find and exploit this unfixed issue. Security-minded open source projects should have a separate channel or mechanism for reporting security vulnerabilities and have separate timelines for delivering security fixes. If a community does not provide a secure method to report vulnerabilities, that could indicate their overall lack of a security mindset that could pose a risk to your business.
Specific risks:
An open source software community’s publicizing of security vulnerabilities can put a consumer of that software at risk.
The community’s lack of separate processes for addressing security vulnerabilities could delay receiving fixes in a timely manner.
Exercise 4: Research the community’s security and service policies for reporting and fixing vulnerabilities
A project’s website should provide answers to the following questions:
What is their process for reporting vulnerabilities?
Do they have a process and separate timeline for security fixes?
How many back-level releases are supported for security fixes?
Do they perform security scans?
Note that omission of an answer is still an answer. For example, if you don’t see a separate timeline for security fixes, there might not be one. Even if an open source project has policies in place for reporting security vulnerabilities, are those vulnerabilities getting addressed? It’s one thing to find them and another to fix them.
Assess open source community participation and longevity
An inactive or abandoned community can delay the turnaround of security fixes and put your systems and business at risk. Exercises 5-9 help you address those risks.
Exercise 5: Understand the community’s actual timelines for fixes and new releases
A few questions you should be able to answer:
How frequently is the software maintained? If infrequently, determine what steps you are willing to take if you need a fix earlier than one can be supplied.
Are you willing to provide fixes by updating the source code?
Would you be able to isolate or disable the package in your own environment with minimal business impact?
Is the community picking up fixes from other dependent open source packages in a timely manner?
Investigate the historical timeline of security fixes to see if it matches the community’s documented schedule and process. Look at their release notes and change logs to get a sense of their practices and how well they meet their policies.
If you use open source software that is provided and serviced by a commercial vendor, it is important to understand their service policies and timelines. For example, if a vendor provides support for a specific platform and maintains their own branch, that could affect their fix timeline.
Exercise 6: Determine how frequently and quickly fixes should be delivered
While getting fixes too slowly can be a problem, receiving fixes too frequently can also raise the risk. Consider the projected volume of fixes against your internal security requirements. Is the community delivering fixes faster than you can handle them? If so, the project might not be at the level of maturity you require. If you plan to perform security scanning or testing against the open source package, frequent releases and security fixes might require more frequent security scanning.
Exercise 7: Assess participation from contributors
Is the software maintained by a handful of developers or by many contributors? If only one person is active, there is a great risk that the project will be abandoned. Who controls the updates? If anybody in the world can update the software without an approval process in place to accept updates, the risk for attacks increases.
Exercise 8: Assess the community’s acceptance of code contributions
If you are willing to contribute code back to the community, don’t assume an open source community will accept your updates. For example, platform-specific changes (such as those sometimes needed for IBM Z or Power platforms) are not always readily accepted due to lack of access to testing platforms or the community not wanting to support another architecture. In addition, a community might also disagree that an issue is a security vulnerability or that it’s severe enough to be addressed.
Exercise 9: Assess trends
If another opens source package exists that is like the one you are assessing and is gaining traction in the industry, consider which solution is best for the long term. While it’s impossible to predict the future, you want to choose projects that have a good chance of long-term maintenance. Shelved or abandoned software increases the risk of security vulnerabilities not being fixed.
Understand your dependencies
Using components with known vulnerabilities is currently ranked sixth on the OWASP Top Ten most critical web application security risks. Understanding dependencies used by an open source package can be a manual and error-prone effort. For example, with projects that use Maven, developers might incorrectly assume the POM file includes the entire list of open source dependencies. However, the POM file does not include transient dependencies. In addition, modern build tools can pull in dependencies without a developer realizing it.
License-checking tools often don’t identify licenses at a community scope. A license checker might detect an Apache license in the first package it finds, but not the 100 open source packages using that license.
Finally, depending on whether you are downloading the open source executables or the source code, that will impact the methods you can use to find these dependencies.
The risk:
Open source dependencies that are not accurately identified increase the risk that open source packages with known vulnerabilities might be inadvertently used.
Reduce risk by using tooling for automated discovery of dependencies. A class of tooling known as Software Composition Analysis (SCA) can help identify dependent packages. Software comprises components, and often these components are open source. SCA tooling analyzes the specific components being used and checks to see if those specific levels have known vulnerabilities in databases, such as the National Vulnerability Database (NVD). SCA complements static and dynamic code scanning tools and is also used for license identification and management.
Exercise 10: Regularly run SCA tooling on your system to help automatically detect dependencies and known vulnerabilities
SCA tools like OWASP Dependency-Check can help identify dependencies. Commercial products also exist. The development or deployment teams should still confirm the results. Subscribing to automatic notifications for security fixes (from vulnerability databases or other tooling/products) can provide an additional safety net.
Exercise 11: Perform historic searches for vulnerabilities prior to deployment
You can search vulnerability databases such as National Vulnerability Database for known vulnerabilities against your open source packages. Tip: When using the advanced search, if you don’t know the vendor name, start with the “product” (package) name. Corresponding vendor names are then displayed by NVD for the given products.
Exercise 12: Check your build
If you are rebuilding open source code on your system, investigate the build logic to understand if open source packages are downloaded from somewhere, and if so, from where. Consider configuring your build to use a local repository that you explicitly populate.
Whew! What a workout
While this isn’t an all-inclusive list of exercises that can reduce risk when using open source software, this starting point can help improve your overall security posture.
About cookies on this siteOur websites require some cookies to function properly (required). In addition, other cookies may be used with your consent to analyze site usage, improve the user experience and for advertising.For more information, please review your cookie preferences options. By visiting our website, you agree to our processing of information as described in IBM’sprivacy statement. To provide a smooth navigation, your cookie preferences will be shared across the IBM web domains listed here.