Why Manually Tracking Open Source Components Is Futile
Table of Contents
Open source is everywhere. Everyone is using it. Open source code is found in almost every proprietary software offering on the market and is estimated to make up on average 60%-80% of all software codebases in 2020.
Why the proliferation? Open source libraries help developers write code faster to meet the increasingly shorter release cycles under DevOps pipelines. Instead of writing new code, developers leverage existing open source libraries to quickly gain needed functionality. The code written in house is primarily to add a company’s unique functionality and to stitch together open source components.
With near universal adoption by developers, open source code is here to stay. So why are some organizations still manually tracking their open source use?
Why you need to track open source components
Your developers save time using open source components, however, open source usage is not without risk. You need a full picture of your codebase to understand the following:
- Inventory. Full visibility into your open source components is necessary to efficiently manage them and ensure compliance with your organization’s policies.
- Licenses. Not all open source licenses are compatible. Different licenses’ permissions, requirements, and conditions can conflict with each other. The only way to ensure your organization is meeting all your open source licensing compliance requirements is by identifying and tracking all your open source licenses.
- Vulnerabilities. The application layer is the most attacked in the enterprise stack. If you’re not tracking your open source components, you’re not going to be able to remediate known vulnerabilities because you won’t know they’re in your software.
- Patches and version updates. Open source libraries are constantly updated, whether to improve functionality or to fix a bug. If you’re not tracking your open source components, you’re not managing their patches or version updates.
The problem with manually tracking open source components
Several obstacles stand in the way of successfully tracking open source components manually. First, manually tracking open source use requires your developers to keep track of every component, and humans are not perfect beings. Second, the sheer volume of open source components in the average codebase makes manual tracking highly impractical if not outright impossible. Finally, enforcing policies about open source licenses or vulnerabilities across your organization during development isn’t feasible if you’re manually tracking open source components.
Manually tracking open source and the human factor
Developers are human, and they don’t always get everything right. That’s particularly true on fast-moving projects, which is every project these days.
Let’s look at an example of how things go wrong. Your development team is working late hours. At 10pm, a developer is trying to fix a defect but she just can’t get it to work. That developer finds open source code that fixes the problem and gives her all the required functionality. The code is downloaded, tested, and works, so the developer compiles. Now it’s almost midnight and your developer is ready to go home. Do you want to depend on the developer remembering the next morning and documenting that she pulled that library down and it’s now part of your software solution?
The reality is things slip through the cracks when you rely on manual tracking. You also don’t want your developers to spend precious time combing through the code at the end of the project identifying all the components they pulled in or ripped out. It’s much easier — and significantly more reliable — if you automate this process.
Manually tracking open source doesn’t scale
Open source libraries make up most of your codebase. For each of the hundreds of components in your code, you have to check online repositories for bug and vulnerability announcements. You also have to check that the component’s license is compatible with your organization’s policies and that all the open source license requirements are being met. The amount of research required to ensure open source components are safe, up to date, and compatible will obstruct development.
Now consider how many dependencies each open source library has and how many dependencies those dependencies have. Forget about managing just your open source components for a moment while you consider how you are going to manage all those dependencies.
You likely have more open source components in your software than you realize, so much that it would be nearly impossible to track it all manually. The sheer number of man hours required to pull this off is not practical, and the possibility of missing a component or introducing an error is high. It doesn’t take much for open source usage to become too unwieldy and too risky to track manually.
Manually tracking open source and enforcing policies
When developers add open source components, each of their choices has to be vetted from both technical and legal perspectives. If you don’t vet components immediately, you risk slowing down development later down the line. Unfortunately, if you’re tracking your open source use manually, the approval process is likely done manually too, which again, is an unnecessarily slow process.
Not vetting choices as they are made has its own risks. You may have to ask a developer to remove a non-compliant component after it has already integrated it into your software. The result may be a costly investment of time and effort and increased developer frustration.
This also brings up the question of who is responsible for enforcing policies in your organization. If you still insist on manually tracking your open source use, do you really want your project managers to spend their time hunting down developers for this data just before shipping?
There is also the matter of third-party vendors. Say you don’t do all your own custom development. What if you use a third-party vendor to do custom development, say for a mobile app? If they’re tracking their open source use manually, are you going to trust they know everything they put into the code they’re delivering to you?
Let’s take another scenario. What if your company buys another company? Are you willing to take the chance that those developers were as diligent? That those project managers were as exacting as what you expect your own developers to be? Wouldn’t you feel better if they were using an advanced automated tool to track their open source usage to ensure license compliance and to manage vulnerabilities and patches?
Automation: The better way to track open source
Your CEO, sales team, partners, and customers all expect you to know exactly what’s in your code and how it could affect your product. Does a recently announced open source vulnerability impact your software? Do you need to produce a full list of open source components for the contract with a new large customer or partner? You should be able to answer these questions instantly and with no effort.
If you’re still managing your open source components manually, you’re unlikely to be able to answer these questions quickly or accurately. There’s a better way to do it.
Software composition analysis (SCA) is an automated tool that gives you visibility and control over your open source components. SCA integrates with any build tool, running in the background as part of your continuous integration environment, to identify your existing open source components and dependencies. It notifies you of all licenses and vulnerabilities. Then, most importantly, it does this day in and day out as your team works, so issues are identified as they arise…instead of on your scheduled release date. An automated solution makes managing open source effortless and protects your organization too.
