Are We Eating From the Dirty Fork?

Earlier this week, SourceClear researchers wrote a technical analysis showing how they used our Security Graph Language (SGL) to uncover 23 vulnerabilities in GlassFish Open Source Edition. And while I’m certainly proud of our ability to find vulnerabilities that no one else sees, there is a much bigger issue here affecting how we think about and manage open source.

Are We Eating From the Dirty Fork?

In a nutshell, like many open source projects, GlassFish previously forked into a commercial and an open source version. During our analysis we found that the open source version retained many vulnerabilities that had been fixed in the commercial version. The problem is that the GlassFish Open Source Edition continues to be the Java EE Reference Implementation. This means when developers go to pull open-source code for new projects, they are likely pulling from the dirtier fork...vulnerability-speaking.

The underlying issue is that while everyone likes to pull from open source, far fewer expend the effort to fix and maintain it. People fix their own code, but those fixes don’t necessarily make it back to the community. And while this is disappointing, it certainly shouldn’t be a surprise. With only so many hours in the day, we all naturally focus on our most pressing personal projects. It’s fundamental. It’s not something that is limited GlassFish - it’s the nature of open source. Apache Struts provides provides a common example, but the same pattern is true across other projects such as Apache Spark, Apache Ranger and Apache Hive.

Taking Back Control

Hoping that a stranger does the right thing is a pretty poor plan for security. In fact the polar opposite might be a better plan, but we’ll save that discussion for another day. If we know that we need open source, but also know that we can’t implicitly trust it, what do we do? Obviously, we have to take responsibility ourselves. But how do we analyze millions/billions of lines of code without losing the time-to-market advantages of using open source in the first place?

This is precisely where the Security Graph Language comes into play. SGL gets the analyst out of digging through infinite lines of code and writing specific signatures, and instead allows us to focus on the fundamental pattern that bugs and vulnerabilities share in common. Find the underlying pattern, and immediately see all the other places where the pattern repeats. This allows the community to work at a massive scale and find problems that would never be seen via traditional means. By providing real tools to find open source problems and share fixes, we can not only secure our own projects, but keep the open source fork clean as well.