Imagine the following scenario. A deadline is nearing, and a developer is hard at work on one of the last unimplemented features. Unfortunately, his code simply doesn’t do what it’s supposed to.
In a moment of frustration, he goes online looking for a solution to his problem and finds an open source library that does exactly what he needs. The developer integrates the open source component into his code, checks the result, and finds that it works perfectly. The problem is solved, and he goes home feeling satisfied.
This scenario is common, and shows the power of open source. This is why open source is accelerating software development. But the usual way of managing open source components has its pitfalls. Can you guess what problems the scenario above is likely to cause?
The unintended consequences
Let’s keep going with the story above. What’s going to happen next?
In a typical situation, the developer will see his work as done, and that piece of code won’t be touched for a while. Perhaps there is a spreadsheet somewhere among the team’s documents that tracks open-source subcomponents, but someone will need to update it. Eventually, the code will get shipped or deployed
And here’s where the potential for trouble lies. There are two huge concerns that haven’t been addressed properly.
#1 Security Vulnerabilities
Hundreds of CVEs related to open source components are reported every year. Adding a vulnerable library can become a giant liability down the line. To make this concrete, consider that 7.5% of commonly downloaded Java components have known security issues, and this doesn’t include zero-day vulnerabilities that will only become known later on.
In addition, hackers are tracking open source security vulnerabilities closely, since exploiting one vulnerability may lead to many victims. The conclusion is that you have to continuously keep on top of what open source components are in your software, and keep track on related security vulnerabilities to make sure they aren’t creating security threats in your code.
#2 License Compliance
Every open source library has an open source license. There are no good or bad licenses, but some licenses may not fit your company’s business model and could jeopardize your entire project. Open source licenses can place binding restrictions on how your software can be used and distributed. Some only require adding copyrights and notices, some may prevent you from claiming patent rights, while others require your code to be open sourced as well.
To complicate matters tremendously, you have to worry about much more than just the license of the component that you used. As Jeffrey Hammond of Forrester Research points out, open source libraries usually has its own dependencies, and pulling in one library leads to a cascade of new dependent components. For a large open source project, this can mean hundreds of additional dependencies, each with its own license and restrictions.
Can’t they just try harder?
So now that we all understand why tracking your open source usage is so critical, let’s discuss why your developers should not be the ones doing it.
The traditional way of dealing with the problems above has been to get developers to track their own usage; after all, they are the ones adding the libraries. Although the majority of us know that manual tracking by developers is far from perfect, the response is usually to make them try harder. In other words, open source components should be reported with more diligence, project managers should be kept informed and involved in decisions whether to include open source or not, and included libraries should be regularly checked for newer versions and security vulnerabilities. Here’s why this is a flawed approach.
Manual Will Always Be Manual
This approach requires tedious and error-prone work. As mentioned, a single open source component can have dozens of other open source dependencies. Can your developers track all dependencies? Checking for licensing conflicts and ongoing security issues among all those dependencies is a huge task, and omissions will inevitably slip through.
Demoralize Your Developers
This process demoralizes your team. It’s a waste of valuable developers’ time to update Excel sheets with this administrative data and to pore over changelists to discover important security flaws and their fixes. Developers are hard to recruit and keep, yet they are often stuck doing one of the most hated tasks, which is managing open source dependencies.
Not Trained For It
Have you ever provided open source training to your developers? Do they know how to search for licenses and which licenses should not be used according to your company’s legal policies?
Based on our experience, the majority of developers don’t even know that if a library doesn’t have an open source license, it can’t be used. The majority also doesn’t know how to search for security vulnerabilities and match between CVEs and the relevant open source libraries.
If after reading these reasons you believe that more project manager involvement is the right approach – you are missing the point. If project managers are in charge of managing and documenting open source components, they too will be faced with all issues listed above, either directly or by having to consult with developers. The end result will be different but equally as bad.
So what should you do?
Automation is always the key
The solution is similar to any other labor intensive manual work – AUTOMATION.
Mend provides exactly that. We automate the entire process of managing your open source throughout the entire software development lifecycle (SDLC).
From selecting the right projects to real-time alerts when a problematic component is added to your build, to comprehensive up-to-date reports at any given time throughout the process, post-release security monitoring and even automating your approval workflow.
We integrate with your build to become part of your CI process. Our agile approach to open source management allows you to stay on top of security and licensing issues, without relying on increased developer oversight. Our open source management platform provides policy enforcement, reporting, and support for all major programming languages.
Would you like to learn more and see how Mend can help you? Click here, and request a free trial right now.
