How to Avoid Technical Debt in Open Source Projects

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?

Begin Here
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.

3. Establish "health check" policies: Cross-referencing gives developers critical information about risks that are inherited by virtue of using these open source libraries so they can prioritize what to fix based on that information. A health check might be a policy that says, "We don't let anything go to production with inherited OS vulnerabilities that are high severity or above," or, "We are going to let anything go out that is using a version of the library that is over a year old." 

Eng says some organizations go as far as identifying the specific sanctioned versions of libraries they may use. If they detect developers are using some other than those, then they don't get to release.

Only So Many Hours in a Day
Engineering teams have only a certain amount of capacity. They can be working on new features, fixing bugs, or doing maintenance. At the highest level, Eng says, software development is features versus maintenance, which includes bug reports and getting libraries up to date.

"If you have to do all this patching, which may involve reprogramming and will definitely involve testing, you are taking that capacity away from building new features," he says.

What can help prevent that sort of technical debt build up is not letting libraries get so far out of date.

"Make it part of the maintenance process that when a new version comes out, you build that time into the engineering process to actually do the upgrade at that time so you stay reasonably current," Eng advises.

Related Content:

Image Source: deagreez via Adobe Stock