Short and concise stories, for software engineers.

Join 1,202 other busy engineers

Stay current with a weekly email of bite sized software engineering stories.
jamie@example.com
Subscribe

We should be more prepared when the next Log4Shell arrives

We should be more prepared when the next Log4Shell arrives
Photo by Brett Jordan / Unsplash

Remember the Equifax breach that happened 4 years ago, caused by an Apache Struts vulnerability (CVE-2017-5638)? I argue that it's quite similar to the new log4j vulnerability, and moreover - it will happen again, in a different project. It's imminent.

XKCD #2347: Dependency
XKCD #2347: Dependency

Is open source broken?

I don't think so. A similar vulnerability could have easily happened within companies' internal products, where people do get paid to build stuff. I trust that the log4j maintainers have properly reviewed the code that led to the vulnerability (even if I can't even imagine a scenario where JNDI in logs is a feature).

With that being said, the open source universe is excessively growing, and there will always be bugs and vulnerabilities (that's why Snyk and its competitors exist), even if we invest more in PR reviews / more contributors. What's special in these two vulnerabilities is the blast radius: and that's where I believe we should be shifting our focus.

My humble opinion and thoughts

I think that we, as part of the open source community, should start thinking about how we treat these massively popular packages. The following are just raw thoughts I wanted to put on paper:

  1. Set up events such as Hacktoberfest to find vulnerabilities in popular packages: if we encourage the community to invest time in researching vulnerabilities specifically, the findings would prevent future attacks.
  2. Make it more noticeable that a package is extremely popular, other than GitHub stars. For example, display how many big companies are using it in the package managers UI. That way, companies that use it will be more alert to the dangers of not auditing it properly
  3. Start educating companies that use these popular packages to invest time or money in research processes, and even limit their usage if they want to use these packages without investing in it
  4. Invest more in educating engineers to keep their software up to date (log4j vulnerability was fixed on December 4th)

Many security companies are operating in this sphere, but I believe we can make a change as a community - because if we don't, the next Log4shell will catch us with our pants down, once again.