“Organizations and engineering teams should be checking their software constantly”

JAXenter: Log4j turned the world upside down and affected businesses and individuals worldwide. Even now, several weeks after its discovery, it continues to spread. Are people still unknowingly downloading the vulnerable version?

Ax Sharma: Many organizations have done an admirable job of patching the problem, but unfortunately, it’s true that others are still downloading vulnerable versions of Log4j. We can see from our data that roughly 70% of the ecosystem moved to download versions 2.15 and higher.

The other 30% continues to download the versions known to be vulnerable, and this hasn’t changed notably in recent weeks. The reason why is that so many companies have not covered the basics. They don’t know what is actually in their applications and so instead of quickly targeting affected applications and making those upgrades, they have resorted to sending out thousands of internal emails, collecting results in spreadsheets, trying to recursively scan file systems etc. In short, they are still just trying to build their inventory before they start to react.

JAXenter: Do you believe that something as large and widespread as the log4j vulnerability will happen again soon? Should we be concerned?

Ax Sharma: We can certainly expect another far-reaching attack to happen in the near term. This past year we saw a 650% year-over-year increase in next-generation software supply chain attacks, according to Sonatype’s 2021 State of the Software Supply Chain Report. For context, that same statistic was 430% in the 2020 report.

These attacks are special because they target open source software repos “upstream,” and result in the severe, cascading vulnerabilities like those of Log4j and Solarwinds. “Active,” upstream attacks are distinguished from “passive” attacks because bad actors are no longer waiting for public vulnerability disclosures to hunt for potential targets.

As for something as large as Log4j, we’ll likely experience another vulnerability of this size again in our lifetime, if not more than once. The Equifax breach is another that’s on par with Log4j and that was only five years ago, which really emphasizes the importance of securing software supply chains now versus after another Log4j level incident.

SEE ALSO: How Data Gateways Simplify Developers’ Lives

JAXenter: Recently, a maintainer of colors.js and faker.js maliciously corrupted the open source repository. How many people did this affect and what was the impact?

Ax Sharma: The colors library sees over 20 million weekly downloads on npm, and is relied upon by nearly 19,000 projects. The faker library has over 2.8 million weekly downloads, with almost 2,500 dependent projects.

The code introduced intentionally by the maintainer resulted in users seeing an infinite loop of gibberish data printed, breaking the projects down entirely.

JAXenter: What was the motive for the colors.js and faker.js sabotage?

Ax Sharma: In November 2020, the maintainer responsible for colors and fakers, Marak Squires, expressed the intention to no longer support Fortune 500 companies with “free work” and that businesses should either fork the developer’s projects or compensate him.

This gets at the tension between open source developers who work as volunteers to maintain projects, and the large corporations that benefit from their unpaid labor. Reception of Squires’ protest was mixed and ultimately a new group of maintainers came in to reestablish the project.

JAXenter: Many open source developers supported the colors.js and faker.js attack, stating that their free work goes unappreciated by large companies. Do you think we are reaching a turning point for open source software? If so, what does its future look like?

Ax Sharma: If not a turning point, this is a crucial stage of the debate between open source ecosystems and the companies that use them without significantly contributing. Log4j is another recent flashpoint that prompted similar arguments. In January, the Apache Foundation called out downstream businesses that benefit without actively contributing.

JAXenter: What now? How often should we check our open source software for security issues and vulnerabilities?

Ax Sharma: Ideally, organizations and engineering teams should be checking their software constantly. Putting some inventory safeguards in place is a good first step. For example, enacting Software Bills of Material (or SBOMs) – full lists of “ingredients” contained in a given application – make identifying tainted or vulnerable components easier in the event of an emergency like Log4j. Plenty of work needs to be done by organizations to put these into practice. A recent Linux Foundation report revealed that 82% of those surveyed were familiar with the term SBOM, and 76% have at least some degree of SBOM “readiness.” However, just 47% were actively using SBOMs in 2021.

SEE ALSO: “A little automation can save a lot of time for the developers”

JAXenter: Besides downtime, what other consequences will businesses face if they cannot secure their software supply chain?

Ax Sharma: Data loss, exposing their customers to privacy breaches, losing control of their systems and being subject to ransom are all unfortunate prospects in the event of a software supply chain attack. Then of course, there’s the potential for legal action and subsequent loss of public confidence if a company is attacked. Bad actors are just as savvy as security experts, and are constantly looking for new ways to exploit the open source ecosystem.

The post “Organizations and engineering teams should be checking their software constantly” appeared first on JAXenter.