Engineering teams have only a certain amount of capacity. Cutting down the volume of rework inherent in the open source business model begins with three best practices.
Technical Debt- While the first step in any open source project is to understand your bill of materials, many companies have yet to create “health checks” that identify the components that are in the software they are building and buying.
Here’s the issue: Software is complex. It gets developed by teams of engineers who use a variety of open source libraries for whatever functionality they need. Even though they download and incorporate them into the software, their use is not always reported or documented somewhere. Though it is possible to ask a developer for a list of what they are using at that point in time, without an automated way to collect information as it is implemented, it can get lost.
But if enterprises continue to adopt open source as a business model — according to a recent report from Veracode, 95% of IT organizations rely on open source software — they need to focus on strategies to alleviate the “technical debt” involved. In other words, how can they lessen or avoid the additional rework associated with an open source business model?
Organizations should start by identifying which open source and commercial libraries and which versions of those libraries they are using, said Chris Eng, chief research officer at Veracode.
“The problem is that multiple development teams are spread out across the organization, which can span across different business units and geographies. You have different processes governing how all of those things work,” Eng says.
Shy of a central place where the entire company can put this information, it is extremely difficult to keep track of all the different libraries and versions that are being used. However, in order to assess risk as it relates to a vulnerability that is discovered in a particular library, organizations need to know what they are using and where it is being used.
Eng provides three best practices he says organizations should start with if they are looking for strategies to alleviate their technical debt.
1. Get open source risk under control: This step is the prerequisite to all others because you can’t secure something if you don’t know it’s there. Getting risk under control means finding all the applications that you have and then developing the habit of collecting that information.
If only that were as easy as it sounds. For some organizations, the process of understanding what is being used and where could be a multiyear effort. Eng says organizations will want to get automated tools and processes in place so that whenever they do a new build, add a new feature, or push something out to production, information is gathered about the bill of materials and the known vulnerabilities in those different libraries.
2. Cross-reference known vulnerabilities: Let’s assume organizations get to the point where they know all the libraries they are using. They are keeping that up-to-date and always know what their developers are using. Then they can start cross-referencing the known vulnerabilities in that library.
Places like the national vulnerability database and different tools can provide organizations with views into that information and actually perform the cross-referencing, Eng says. Developers can look up an application they are developing and have it report all of the libraries that it’s using, along with all of the known vulnerabilities in that library and the different severities.