It's 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 who 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 driven developers to rely 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? Recently, we've heard a lot about open source security risks, with Heartbleed, OpenID and OAuth as notable cases. And it's true, while all gardens have bugs, so does all software (proprietary and open source). While in my garden, some bugs might be good for the plants, but generally bugs aren't good for software. Some bugs in our open source components allow 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 using these newer, more secure versions helps ensure 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 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
If you want to learn more about how to 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.
Derek serves as vice president and DevOps advocate at Sonatype and is the co-founder of All Day DevOps -- an online community of 65,000 IT professionals.
Explore All Posts by Derek WeeksTags
Try Nexus Repository Free Today
Sonatype Nexus Repository is the world’s most trusted artifact repository manager. Experience the difference and download Community Edition for free.