Just 11% of open-source packages are still being maintained: report

The vast majority of open-source projects that have piled up over the years are no longer maintained, according to the 2023 edition of Sonatype’s software supply chain report.

Just 11%, or around 118,000, of nearly 1.2 million Go, Java, JavaScript, .NET, and Python projects were receiving active support in the latest version of the survey. What’s more, 18.6% of the Java and JavaScript projects, which Sonatype listed as maintained in the 2022 version of the survey, no longer have maintainers.

While 67% of the 621 engineering professionals surveyed said they were confident their applications did not rely on known vulnerable libraries, around 10% of respondents admitted their organizations had experienced some kind of breach related to open-source vulnerabilities in the last year. One in five were unsure if such a breach occurred. Sonatype also found that while one in eight open-source downloads carry known risks, around 96% of vulnerable downloads had a fixed version available.

That’s particularly alarming because it indicates developers aren’t able to keep track of good download sources amid a surge in malicious open-source packages, according to Sonatype Co-Founder and Chief Technology Officer Brian Fox. Sonatype reported discovering around 245,000 such payloads ready to download, or twice the total it found over the prior four years combined.

“The answer to why it is growing is because it’s effective right now,” Fox told IT Brew. “Not enough people recognize this is happening.”

Many attackers are hosting malicious packages with names and URLs similar to popular components, Fox said. He warned threat actors often don’t even bother to disguise the malware as a legitimate package and instead launch “smash and grab” attacks on developer machines by bundling downloads with pre- or post-install scripts.

This comparatively low-effort method, which targets the developers directly rather than the final product or customers, can pay off if no one notices the download was bundled with the malicious add-ons.

“Developers have learned to recognize that as an indicator they’ve been compromised, their build will fail, because the component didn’t actually have the code it needed to compile,” Fox told IT Brew. “And the unintended consequence of that is the developer goes and gets the right component at that time, and then they continue their job, and they check it in.”

While 28% of organizations take as little as a day to discover disclosed vulnerabilities in their packages, according to the report, 39% take between one and seven days, and 29% take over a week. Approximately 39% of organizations then take over a week, which Sonatype researchers noted “means that the majority of bad actors have days to launch a malicious attack on enterprise targets.”

As the vast majority of code in modern applications tends to be from open-source components, the security of the open-source ecosystem has massive potential downstream consequences. Just look at the fiasco around the Log4j vulnerability, which was found in 2021 but could lurk in the wild for a decade or longer.

A separate report from electric design automation firm Synopsys earlier this year found 84% of nearly 1,500 codebases it examined during merger and acquisition audits had at least one open-source vulnerability, while 48% had high-risk vulnerabilities (for example, containing known exploits or allowing remote code execution).

In April 2023, the Senate Committee on Homeland Security and Governmental Affairs passed the Securing Open Source Software Act, which would direct the Cybersecurity and Infrastructure Security Agency (CISA) to seek out and mitigate threats in open-source software used by the federal government. As of the end of October, the bill has not yet been voted on by the full Senate.

Fox said that while open-source software offers numerous benefits, including a simpler procurement chain, the report is more evidence many organizations aren’t keeping track of what components they’re using. He argued visibility tooling, such as that used to build software bills of materials, is only one half of the question—and developers need to adopt technology like repository firewalls.

“I don’t think anybody is actively choosing to use these vulnerable components,” Fox said. “It’s happening because they don’t have the awareness.”