Manage your software where it’s created. It is in your continuous integration environment where the various pieces of code become software. While some of the software is proprietary, much of it (probably over 50%) is open source components, as your development teams use open source components to boost their productivity and make better products.
You most likely have your proprietary software thoroughly tested, QAed and reviewed via static code analysis on a regular basis. But what about the open source components? Open source components may have a direct impact on the quality of your software or service.
Open source components may have a direct impact on the quality of your software or service. Security vulnerabilities in open source components are discovered from time to time, and while often fixed very quickly, you need to make sure that you know of them when they are discovered and can apply the right measures when necessary.Here are 3 measures you should take to control the risks that open source components may introduce to your software:
1 – Know what’s in your software.
Open source components are part of your software, so you need to know which ones are embedded in your software, at all times. What makes this task hard is that most open source components have dependencies (components they use) – in fact, we researched the 300K open source components (out of a database of millions) that are most commonly used by our customers, and discovered that on average, each has 7.1 dependencies. So if you have 50 open source components that you know of in your software, the actual number is probably much higher.
Knowing what you are using is an essential step on the path to full control of your software.
2 – Control what’s being added into your software.
Checking what open source components are added in real time allows you to check whether they conform to your open source license and risk policy and decide whether you want to use them before too much effort is put into developing your software around these components. You just don’t want to spend precious development resources on components that you cannot use because their license is too restrictive. There are usually plenty of alternatives with friendly licenses your development team can consider if they know that they should.
3 – Track security vulnerabilities and stale libraries.
Another reason to check open source components as they are added to your software is security vulnerabilities. As we mentioned above, since open source software is like any other software, it too may contain security vulnerabilities. The good news: open source components are tested, used and fixed by an entire community. Our research of over 6,000 projects proves that if open source components are properly managed and regularly patched, most projects (98% of them) would not include an unfixed security vulnerability.
Controlling what’s in the software and what’s being added to it, is the first step on the path to secure software. Being able to create a full detailed report in a click, having full visibility and transparency and making all these part of a foolproof process that does not rely on the development team are key to successful management of open source usage.
| About the author: Rami Sass (@whtsrc) is CEO and Founder of WhiteSource. WhiteSource|
helps engineering executives to effortlessly manage the use of open source components in their software.Open source components make up a significant part of commercial software but are often undermanaged. WhiteSource fully automates all open source management needs, reducing risks, and guaranteeing the continuity and integrity of open source component management.Editor’s Note: The opinions expressed in this article are solely those of the contributor, and do not necessarily reflect those of Checkmarx.