Open source is great for you. It saves resources, time and enables your developers to focus on the mission critical parts of your software. However, open source usage comes with a responsibility. Your team needs to keep an updated inventory list of all components, track licenses, check for updates and CVEs and more. If your team is like most commercial software teams, they do it manually through e-mails and spreadsheets.
The question is what are they missing?
1. You have more open source components in your software than you know.
Open source libraries use other open source libraries, and so on...
So if you have a list of 100 open source components in your code, there could be 500 open source components that you are using. It is impossible to manually list them all.
2. Developers add new open source components all the time.
Manual tracking means that your team has to report to you every time they add a new open source component.
They may forget. They may not be sure what exactly they added. And, per (1) above, they will have to discover and report on all the sub-components (there can be tens per a single open source instance they were intending to use).
3. When developers add open source components, you have to vet each of their choices from technical and legal perspectives. And you have to do it ASAP.
Otherwise, you may have to later ask a developer to remove a component after he has already integrated it into your software. The result may be a costly loss of effort and frustration.
If you are just about to release a new version and cannot find a good enough replacement, this can turn into a small crisis. The crisis may be bigger if a problematic component is discovered during an important due diligence process…
4. For each component (of the hundreds in your code), you have to constantly check online repositories for bug and vulnerability announcements.
Since the open source components you use are now part of your product, you must track their bugs and security vulnerabilities as if they were in your code.
You have to figure out which of the security vulnerabilities announcements affect open source components that you use, and, when necessary, quickly patch your software with the right fix.
5. Your CEO, sales team, partners, and customers all expect you to always know what’s in your code and how it can affect your product and their operations.
For example, existing customers may want to know how the recent announcement of a security vulnerability in an open source component affects your product. You may be required to provide a full list of open source components for a new financing round, or for the contract with a new large customer or partner. You should be able to provide all these instantly and with no effort.