Chris Wysopal: Open source is becoming a national security risk

In early December 2021, enterprise security teams around the world went on high alert because of a string of vulnerabilities in an open-source Java component, Log4j, that is used in millions of applications. The incident prompted warnings from CISA and other national CERTs and led to renewed discussion about security and the open-source software ecosystem and how developers consume and track their use of open-source components.

Chris Wysopal, founder and chief technology officer of application security company Veracode, sat down with CSO Senior Writer Lucian Constantin at a recent Security Summit to discuss just that.

A security industry veteran, with more than 20 years of experience in application security and vulnerability research, Wysopal has testified to the US Congress on the subjects of government security and how vulnerabilities are discovered in software.

What follows are edited excerpts of Wysopal’s conversation with Constantin. To learn more about the aftermath of the Log4j vulnerabilities and the future of open source security, watch the full video interview embedded below.

On the significance and impact of Log4j:

Log4j was definitely a different kind of vulnerability for development teams to deal with than their normal day-to-day, just because of how widespread it was and how urgent it was.

It just hit almost every organization, and within every organization, it hit multiple development teams—teams that were working on the latest and greatest thing for the company and teams that were in maybe maintenance mode that maybe changed the code like once a year.

Because [Veracode is] a SaaS provider, we can look across all of our customers. And we looked across the couple hundred thousand applications that we had scanned in the last year,  especially enterprise customers. And of those enterprise customers, 95% of those customers were using Java. So that just shows you how popular Java is; if there is another vulnerability like this in Java, it is going to be widespread. And 88% were using Log4j and 58% were using the vulnerable version. So, this hit most organizations. Overall, 17% of Java apps were vulnerable to Log4j, so just think of that. There are millions and millions of Java applications that have been built over the last 10, 20 years, and a full 17% of them were vulnerable. There was just a lot of scrambling going on across all these different companies and their engineering teams.

How SBOMs could help:

If you are an IT department [or development team] that is purchasing products from vendors, [you’ll have to] to patch vendor code. Of course, IT departments are used to patching vendor code. The challenge was this was very widespread—all at the same time. This was a situation where most companies had dozens or even a hundred vendors that were all vulnerable to this, and they had to track which vendors were vulnerable, did I have the update yet, did I update it? And try to do this in a timely way because this is probably going to get attacked in a short amount of time.

A lot of organizations had to do this by asking questions of their vendors. They would ask, “Well, I think this appliance uses Java, so let me go ask the vendor. I will send an email to my support person and ask them if they use Log4j and when the update is going to be available.”

A lot of this was done manually—through email—and teams would set up spreadsheets and say, “This one is vulnerable; we are waiting for the update here.”

This is where the software bill of materials—or an SBOM—could really help, if when you purchased that product, they sent you an SBOM or they sent you a link online to their SBOM and you could programmatically just query so that you are not manually asking questions and building a spreadsheet. That is how I think things are going to move to in the future because SBOMs are starting to build traction.

On signs of progress: 

[Open source] is becoming almost a national security risk. I was at the Aspen Cybersecurity Summit in September, and a big part of that was systemic risk and how open source is getting up there as one of those systemic risks for the United States. So that is the kind of importance it is getting to because the usage is just so widespread.

[The good news is] things have improved. There is a lot of awareness. I think the enterprises are aware that they should be picking the right packages, whether that is a project that is well maintained and has less vulnerabilities or they are always keeping it up to date and making sure they are using a less vulnerable version.

But I also think the open-source teams are responding quicker to these issues. So, there are a lot of different factors that are going into the improvement here. And we need it badly because we cannot have a Log4j episode on a monthly basis. That would just kill productivity for people using open source, which is everybody.

This article originally appeared in CIO.com’s Center Stage newsletter. Subscribe today!