Walking in the Open Source Component Garden

Its not everyday I can stop to enjoy my afternoon tea outside on my deck, overlooking my garden. But today I did and while admiring my beautiful blooming flowers, I started to draw some parallels between my garden and software development. Full disclosure, I wouldn't consider myself a true gardener. I buy plants that have already been cultivated to a mature stage on someone else's farm or in someone else's greenhouse. I admire those that still chose to plant seeds in their gardens but for most of us (at least me) I don't have the time or want the hassle of caring for the seeds until they turn into plants.

Which is where I think developers can relate. Today, the pressures to deliver software faster have developers relying on component based development practices and with good reason. Why create your own web framework, or logging mechanism, when you can turn to proven components and frameworks from open source projects? Today's developers can easily access hundreds of thousands of components, including the basics such as the SLF4J logging framework, or a major framework like Struts or Spring. You could code an entire application from scratch, but honestly who has the time or wants the hassle?

But what about bugs? We've sure heard a lot about open source security risks lately with Heartbleed, OpenID and OAuth as notable cases. And its true, while all gardens have bugs so does all software (proprietary and open source). While in the case of my garden, some bugs might be good for the plants but generally bugs aren't good for software. Some of the bugs in our open source components allow for our applications to be exploited. And with Verizon’s 2014 report showing applications as the number one attack vector, better understanding what components you're using and the security vulnerabilities or licensing risks associated is important to keeping your applications safe.

For many of us, the good news is that open source projects often release newer versions of their components that address newly found vulnerabilities. Bug-free alternatives are available. But making use of these newer more secure versions, replies on ensuring your organization has a process to help you identify these defects easily and early.

In his recent blog post, 4 Open Source Components You Need to Update Right Now, my colleague, Brian Fox, shed some light on poor component practices -- that is, folks who are still downloading extremely vulnerable components long after bug-free versions were made available. One such example of this behavior was with Struts:

“Struts versions prior to 2.3.15.1 are vulnerable to CVE-2013-2251, which allows code to be uploaded anonymously and then executed as the application server user. This can lead to complete system compromise if the application server user has escalated permissions or if other vulnerabilities are chained together to escalate permissions. Since the disclosure in July 2013, affected versions of Struts2 components were downloaded 179,050 times from more than 4000 organizations.”

Any professional gardener will tell you, that if you see, then ignore the bad bugs infesting your garden, then you’ll have to live with unhealthy or perhaps even dead plants. The same goes for software development. If you are voluntarily downloading buggy/vulnerable components your application “garden” will not be healthy...“buggy parts equal buggy software".

If you want to learn more about how you can address security as part of your component based development practices, I invite you to read our latest paper: 7 Security Gaps in the Neglected 90% of your Applications.