Stewing Over Software Ingredients

I love developing new software, and I also love security. But I also love cooking for my family. Both are full of reward, but occasionally come with challenges along the way.

Reason to Stew

Just the other day I was planning dinner for my family and thought it would be a great idea to bust out the Dutch oven I had to have, but rarely use, and make a nice stew. I ran to the grocery store to grab some fresh carrots, turnips, onions, a couple of Yukon Gold potatoes, and some fresh chicken (and a bottle of nice wine for the thirsty chef). I needed a quick start and an on-time finish. Or it would be another failed product delivery -- followed by a rapid desire by my family to outsource.

Once I unpacked all my ingredients, I went to work. I grabbed some fresh herbs from my garden, started to sear the chicken, added the onions, garlic, fresh herbs, and then deglazed with a little of the wine. I was about to pour in the chicken stock when my wife asked me, “did you check the expiration date on that?” Oh, no. Ugh. Sigh. It expired a year ago.

And of course, I had already been to the store. Dinner had to be done in a flash. But I now had new information. The expiration date. Did I want to tempt making my family sick with the old stock, or head back to the store for new stock? If dinner was not on the table soon, my project was surely going to be given to another team (in this case: P’Terry’s).

A Proper About-Face

I didn’t stew. I also didn’t really want to go to the store again. But, in the end that is exactly what I did. Paying attention to the information I had at hand would have saved me another trip to the store. But more importantly, using this vulnerable source of chicken stock could have put my family at risk.

In the future, when I get the itch to break out that Dutch oven again, I’ll be sure to check the expiration date of all my ingredients. Checking it is a simple practice of avoiding known risks (and will also save me from some unwanted Emergency Room bills).

The not so subtle hint here is that software components are the ingredients of software. Just like real food, they have an expiration date.

Some Things Don’t Age Well

Let me start with an example. Using an xml processing library with a “best if used by date” somewhere in 2005 might not be so good for your software. Using fresh ingredients helps ensure safer, tastier finished products. Known vulnerabilities are out there, and it is worth checking to see if the components you are using in development are still “fresh”. It also means, less rework for you (or trips to the store for me).

In our 2014 Open Source Development and Application Security Survey, 63% of the +3,300 participants said that no one was actively monitoring their open source components for changes in vulnerability data. That is, no one was in their kitchen asking “is that thing expired?”. The cooks did not have an easy way to check for the expiration date or for known vulnerabilities, even though the components were labeled (albeit in small print).

At the same time, 37% of organizations were showing good hygiene practices by actively monitoring for changes in vulnerability data. When the next Struts2, Bouncy Castle, or Heartbleed like bug is announced, they would be on the look out. The 37% are the best practice. And to be clear, they are not on a goose hunt looking for the unknown, these are the folks tracking the known, published risks that might impact the quality of their software.

As Brian Fox, our VP of Product Management, likes to say, “Components don’t age like a fine wine, they rot like milk”. If you are part of the 63% that are not tracking, the time is coming to do so. With applications recognized as the #1 source of attacks leading to breachs, the quality standards in our software kitchens need to improve. At lunch today or tomorrow, I’ll invite you to stew this one over with your colleagues.