I can honestly say that although referred to by the media as Shellshocked, I am neither shocked nor awed. I can’t say that I am a fan of the latest glorification of bugs like Heartbleed and Shellshock in a fashion similar to tropical storms, but if it gets more people to pay attention to the exponential growth of our reliance on software I can’t say I am too worked up about it either. One thing that is unarguable is that this just happens to be the latest (and if you are reading this before you have patched stop right now, patch, and then come back to finish).
We led an invasion last week armed with a flying drone, glowing lightsabers, and the latest knowledge on open source security vulnerabilities. Our mission? Lead, share, educate, moderate, and have some fun. Our coordinates? This year’s AppSecUSA 2014 event in Denver, Colorado. If you were there, you couldn’t miss us. If you weren’t there, don’t fret…they caught the entire thing on video.
A skeleton key is capable of opening any lock regardless of make or type. Do you know anyone who has one? I do. Lots of them. At the HP Protect conference last week in Washington DC, the theme of their conference was “think like a bad guy”. They introduced us to known hackers, their approaches to infiltrating organizations, and the trends in their behaviors. They also introduced us to the people who hunted down the hackers and successfully captured them.
This week, I will be attending AppSec USA in Denver with the rest of our Sonatype crew. While it will be my first time attending the event, I am really excited to be leading a panel discussion at the event this Thursday. If you will be at the event, please come by the session or the Sonatype booth (G10) and say hello. So what’s the panel discussion about?
We are not the first industry to face this challenge. But many are convinced our problem is much smaller than it really is or that it does not exist. They simply ignore it. Or choose to do nothing about it. Meanwhile, the problem is multiplying like rabbits. The challenge lies within our software. Within the quality of its supply chain, within our collective ability to maintain its health, and within our ability to establish easy (yes, I said easy) paths to ban rampant, yet avoidable risks.
“It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness, it was the spring of hope, it was the winter of despair, we had everything before us, we had nothing before us…”, penned Charles Dickens in 1859’s A Tale of Two Cities.
I was going to start off listing a series of what I think are easy questions that I reckon everyone in technology should be able to answer even if they are not or have never been involved with writing software. I gave this some serious thought and decided (perhaps a little arbitrarily) that, actually, I’m really only interested in one single question for now and that is ‘should software be tested’?
I remember it clearly. Sitting down for breakfast, I opened the Sydney Morning Herald to see the latest headlines in Australia for the day. As I shuffled through the paper, I finally landed upon the Technology section and then noticed pages and pages of “help wanted” adds.
In part one of my blog, It’s Just the Way Software is Made, I discussed the realities of how software is made, the birth of agile development, and the advent of component-based software development. Today, we will drive down the software supply chain to understand where your software has really coming from. I’ll also discuss why it’s important for us to instill high quality standards and governance policies in our “parts” ecosystem.
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.