Where are open source software components in use?
It’s crucial to have complete visibility into your organization’s use of open source software and code. In the open source world, however, the problem is particularly tricky because organizations often rely on libraries that, in turn, rely on other libraries that rely on other libraries (and so on and so on). So, even though a developer could be pulling in only a few open source libraries directly, those libraries could easily pull in hundreds of other open source libraries with them — including all of their vulnerabilities. In addition, while one segment of a library may not be vulnerable, other subsets may be, and it’s critical to know that in order to understand how to proceed once you find out a library has a vulnerability.
What open source versions do we have in use?
It’s also necessary to understand the versions of the components in use. Are they the most recent? Are they older? It’s a mistake to assume that the groups within your organization automatically update to the most recent and secure versions of open source software. It’s also a mistake to assume they’re using the best tools to detect those vulnerabilities.
When do we check on the status of open source?
Still another concern is how often development teams and other groups are checking on patches and updates. The period between when a coding flaw or vulnerability is detected and when it’s fixed is crucial. Adding to the problem: The National Vulnerability Database is overrun with submissions, and it can take several months to sort through submissions and officially disclose a vulnerability.