Software developers who use open source libraries were stunned earlier this week at news that two utility packages in the GitHub and NPM libraries were generating strange code, allegedly created by the projects’ creator as a protest over not being paid to maintain his work.
One industry expert we interviewed called the action “mischievous”, while another called it “vindictive.”
No matter what the cause, application security and risk analyst Sandy Carielli of Forrester Research says the incident raises many questions about open-source application maintenance and security, as well as what developers and commercial users of open-source code owe each other.
It’s also, she added, a caution to developers to not install an update to an open-source project without testing it first.
“It’s important when you take these to look how the rest of the community is using them [open source packages]. Look for feedback from the community, look to see if anyone has had to revert [to an earlier version] as a result of issues, and make sure you are doing the appropriate testing before you just take and install it.”
Carielli admitted she was “surprised, perhaps a little bit horrified” to hear about the incident.
“Occasionally you see issues of malicious developers uploading malicious projects, or attempting to take advantage of dependency confusion by replacing a good project with a malicious project. But the idea of a developer of a long-trusted, well-known project suddenly injecting malicious code is not something I’ve heard about before.”
“There is always going to be that ‘Trust but verify’ element,” she said, “making sure you have the necessary controls in place to block malicious packages and analyze to make sure you’re using the correct version of a piece of open source. Those are important parts of managing enterprise software.”
If the allegation is true that this is a protest, the incident — again — raises questions about how developers of open source projects should be compensated, she said. But, Carielli added, it also raises the question of “what is ethical to do when you know a large community is relying on the project?”
One utility, known as ‘colors’ allows an application to print in colour, while the other, called ‘faker’, generates fake code for application testing.
But according to the Bleeping Computer news service, which first reported on the incident, the latest versions ‘colors’ forces applications using the utility run an American flag constantly on screen. According to Sonotype, the functional code for ‘faker’ has been purged.
The new versions are not believed to be a hack by a third party but the creation of the developer of the two packages who, it seems, has launched a protest.
Commentators came to that conclusion because of a note allegedly published in 2020 by the developer. He wrote, “Respectfully, I am no longer going to support Fortune 500s (and other smaller sized companies) with my free work. There isn’t much else to say … Take this as an opportunity to send me a six-figure yearly contract or fork the project and have someone else work on it.”
Libraries like Github, NPM, and Maven are where open source developers place projects they’ve created, such as utilities, so others can download and implant them in their own applications. Usually these projects are free. Security and feature updates are issued at the discretion of the developer.
If the protest theory is correct, the incident raises some similarities to the controversy last month when vulnerabilities were found in Apache’s log4j2 libraries, said Carielli.
“One of the things that came to the forefront of log4j — and I will say this is not the first time this has come up — is the fact that there are critical open source components that are used by a myriad of developers across the world and are relied upon, [but] are often maintained by one or two developers. They do all the work and they’re not getting support or financial backing or additional assistance from other developers to be able to take care of them all the time.”
There was “some amount of abuse and impatience hurled towards the developers” of log4j, she noted, although they were trying to update and fix their libraries as fast as possible. “That reaction raised the question of how we protect and support critical projects in the open-source community.”
The same question is raised about the developer of the ‘colors’/’faker’ libraries, she said.
By coincidence, the Apache Software Foundation released a position paper ahead of Thursday’s White House Software Security meeting that in part complained that companies that add open-source into their products rarely participate in their continued maintenance.
The issue of the need to compensate those who create open-source applications was deeply covered in a 2016 report for the Ford Foundation. “Without effective support for coders’ work on publicly available projects, not only will their labor go uncompensated, but the digital world risks security breaches, interruptions in service, and slowed innovation,” says a summation of the report.
The question of open-source sustainability was also raised in this 2019 blog by GitHub’s then open-source product manager. And a year ago, software developer James Turner took a look at the funding problem in this blog.
DevSecOps will be a significant discussion point in 2022 as organizations begin to understand the importance of baking security into applications much earlier in the development process, Justin Fier, director of cyber intelligence and analytics at Darktrace, told ITWorldCanada. “Risks presented by the dependence on open-source will put dev teams front and center – especially following Log4J. This problem calls for cyber defense technology to spot vulnerabilities as threat actors exploit them. Organizations need to be able to defend against any potential risks they introduce through third-party suppliers and platforms.“
Application developers worried about being stung by problems in open source code have a wide range of software composition analysis (SCA) tools that can examine software code for vulnerabilities, Carielli noted, including those from vendors such as White Source, Sonotype, GitLab, Fossa and JFrog,
Ron Bash, vice-president of technical research at aDolus Corp., a Victoria, B.C. maker of a solution that analyzes and scores software components, said the ‘color’/’faker’ developer appears — like some others –to be tired of working for free in their spare time on an open-source project.
“I’m not excusing this behaviour,” he added. “What I am saying is it’s certainly understandable and relatable across a wider audience of open source packages.”
As for developers worried now about open source code, Bash was unsympathetic. “Software developers generally don’t think security applies to them,” he said. “They are aware of it, but they think that’s the cybersecurity team, that’s the tester team’s [responsibility] … Software engineers also need to consciously accept risk … rather than blindly importing a library or copy and paste code and accept its dependencies. They need to be conscious of third-party components, need to review the code if possible, delay and review updates before being added” to their applications.
This isn’t the first time an open-source app developer’s temper has stung others, noted Mei Nagappan an assistant professor at the University of Waterloo’s Cheriton School of Computer Science.
In 2016, hundreds of applications suddenly stopped working, allegedly because a developer was asked to change the name of a JavaScript library they created and published on NPM. Apparently unhappy with the request, the developer unpublished the code modules. This is separate, Nagappan added, from the number of vulnerabilities in NPM packages found last year.
“While such problems do occur,” he said in an email, “they are at least in the open. The solution is quick. If you read more carefully, the companies could have forked [the ‘colors’ and ‘faker’ code] and used the fork instead.
“The people who have something to lose may need to invest in what they use, too,” he added.
As to whether this incident reduces confidence in open source code, Nagappan noted that commercial software has its share of problems too.
One example, he said, was the recent compromise of SolarWinds’ Orion update mechanism.
