Site icon IT World Canada

Software spat raises open source questions

oops, mistake, error

Image from Shutterstock.com

If your company uses Node.js, you may have suffered a shock this past week. A critical software package in the open source code base that many Node.js applications rely on suddenly disappeared. The problem was quickly rectified, but it caused problems for many users – and belies a fundamental problem with open source software.

The problem arose when Azer Koçulu, the developer of the Kik software module, was approached by lawyers working for a company of the same name. They wanted him to unpublish his module because the name infringed on theirs, they said. Koçulu refused, so they approached a company called NPM Inc.

NPM manages a software library, also called NPM, which is a package manager for Javascript applications. It is also a key component in many applications running Node.js, which is a Javascript framework for building server-side applications. NPM decided to change ownership of the module, which angered Koçulu enough to pull the plug. He unpublished his modules. That was a problem, because there were 273 of them.

One of the packages, called left-pad, padded out lines with zeros. It was only 17 lines long, but was used by thousands of Node.js projects. It had been downloaded 2.4 million times in the last month alone.

After Koçulu unpublished it, many Node.js projects were knocked offline. There was no warning, and no immediate solution, leaving business users vulnerable.

Depending on code that isn’t yours

This issue was eventually fixed after NPM worked with another developer to republish an older version of the module, but it highlights a problem with open source software: it may depend on packages over which you have no control.

There are often multiple people contributing to an open source code base. Not only can they alter the functionality of their frameworks, or delete them altogether, but they can also introduce insecurities into the system. And multiple open source software products may be used in other products, creating a matrix of dependencies that’s difficult to track, especially if they are not properly documented.

It’s easy for a developer to look online for a package that already does what they’re looking for when developing a larger software application, and this happens frequently, warned Mike Pittenger, vice president of security strategy at Black Duck Software.

“We’ll find a random open source library on the web that suits our purposes, and pull that in. It’s now up to us to continue to monitor that web site for updates to it,” he said.

Black Duck scans source code and binary files to find open source components, so that it can report exactly what open source code a particular piece of software is using. That can often surprise the companies that own the software.

The problem with having dependencies on code that isn’t yours is that software frequently draws on tens or even hundreds of open source modules.

“Open source software comprises about 35 per cent of the applications that we see,” said Pittenger. “That represents somewhere between on average between 70 and 100 individual open source software components.”

The firm hands customers a report on the open source code used in their software which can then be used to check against the National Vulnerability Database to see if any security flaws crop up, and then adding them to its own knowledge base. Checks can be made on how up to date the software is, assessing how many commits have been made by its developers, and how recently.

Black Duck originally focused on identifying licensing issues arise from open source, but Pittenger argues that many firms just wanted to identify open source code so that they can get rid of it. It would be a shame to throw the baby out with the bathwater, though. There are many benefits associated with open source – if only we could prevent the kinds of ownership spat and subsequent mayhem that happened this week.

Exit mobile version