When there’s a safety issue with a car or a child’s toy, the items usually get recalled and a fix is implemented. Some tech industry leaders are wondering why the same approach isn’t working for software.

Log4j is a widely used open-source tool used to collect diagnostics data from applications written in Java. In late 2021, security researchers discovered that a critical flaw in Log4j could be used by hackers to breach vulnerable systems. The Apache Software Foundation quickly released a patch in December of that year, and additional fixes have been deployed since. Yet, vulnerable versions of the open-source tool continue to be downloaded around the world.

“As of last week, 29% of the consumption worldwide of Log4j versions are of the known vulnerable versions,” said Brian Fox (pictured), chief technology officer of Sonatype Inc. “We’re closing in on 18 months at this point. How is it that a third of organizations are still pulling down these known vulnerable things? That’s insane.”

Fox spoke with theCUBE industry analyst John Furrier at the RSA Conference, during an exclusive broadcast on theCUBE, SiliconANGLE Media’s livestreaming studio. They discussed the threat landscape and key steps to be taken in securing the software supply chain. (* Disclosure below.)

Component assessment

The Log4j vulnerability has called attention to an ongoing issue within the technology industry. The software supply chain is vulnerable to attack and numerous companies are struggling to gain the upper hand.

“As an industry we’re failing to follow best practices and deal with the fundamentals,” Fox said. “Mainstream customers right now still don’t have a handle on what’s going on in their supply chain.”

Fox is intimately familiar with the open-source software world. He is a governing board member of OpenSSF, a cross-industry organization that brings together key individuals to drive open-source security initiatives. He was also a part of the Apache Software Foundation for nearly 14 years.

Fox’s company leverages firewall technology to help customers avoid the download of harmful malware or software with critical vulnerabilities. According to the firm, Sonatype researchers have analyzed more than 120 million open-source components and its platform has automatically blocked 115,000 malicious elements from corrupting software development pipelines.

“It sits in the development environment and is able to assess the components coming in,” Fox said. “We know which ones have malicious (code), and we actually use machine learning and AI techniques to identify that. If one of our customers tries to pull it in, we can stop it.”

Unpacking containers

Use of potentially dangerous software components is not the only threat confronting developers. Containers, which are prominent in today’s enterprise IT environment, hold perils of their own. A security knowledge gap currently exists in the container space. One cloud-native industry study found that only 3% of respondents understood that a container by itself was not a security boundary, and only 24% planned to deploy the necessary tools for runtime protection.

“It’s the same problem, just on a bigger scale,” Fox said. “As you start building containers it’s harder to know what’s inside them. You’ve got a container built on a base image. Who built that? What did they install on it?”

Threats posed by software and containerized applications highlight a developer community that has increasingly become an attractive target for threat actors. Key developers in many organizations often have high-level privileges that, if acquired by cybercriminals, could expose entire systems to a major breach.

“The developer infrastructure has a lot of keys to the kingdom, it makes it a very sweet target,” Fox noted. “Developers are not motivated to do a terrible job, but in some cases, they are not provided with the information to make a better choice about one component versus another. They don’t have the visibility into that stack to know that the components they have might have a bunch of vulnerabilities.”

Listing dependencies

To help address developer blind spots and other potential weaknesses, the technology industry has coalesced around a solution known as a software bill of materials, or SBOM. This solution provides a record of the various components used to create a piece of software.

“Software bill of materials is the term for listing out the dependencies that are in your applications,” Fox said. “Ninety percent of it comes from somewhere else.”

The need for provenance has led Sonatype to deploy a tool for generating and scanning SBOMs called the BOM Doctor. After creating an SBOM, users can try on security fixes before committing to updates for optimizing the build. By making tools like BOM Doctor available, Sonatype hopes to help developers improve their knowledge of the dependencies being used.

“Because these decisions are being made often by developers, they don’t go through the procurement process, where procure is about risk reduction across all these different things,” Fox said. “These things are skipped so what happens is organizations more often than not don’t have good visibility into what these dependencies are.”

Here’s the complete video interview, part of SiliconANGLE’s and theCUBE’s coverage of the RSA Conference:

Check out these highlights in Fox’s segment:

2:42 – AI doesn’t really affect security of dependencies yet.

4:37 – Mainstream customers still don’t have a handle on their software supply chain.

5:50 – Software bill of material can play an important role.

7:30 – Containers are a risk too, just on a bigger scale.

10:19 – Sonatype leverages firewalls and industry knowledge to protect customers.

(* Disclosure: Sonatype Inc. sponsored this segment of theCUBE. Neither Sonatype nor other sponsors have editorial control over content on theCUBE or SiliconANGLE.)

Photo: SiliconANGLE