The U.S. recently overtook France as the world’s largest wine market. And here at Sonatype, we can proudly say we’ve contributed to this achievement. By not only consuming our fair share of wine but by also being involved — outside of work — in crafting our own wines. Over the 4th of July holiday, I was able to enjoy some of the wine I’ve aged over the years. For the best wines, aging can create spectacular results years down the line. Unfortunately, the same cannot be said for code and components used in today’s applications. Where aging improves a fine wine, code ages more like milk.
Wow! What an amazing turnout we had for our 4th annual survey: 3,353 participants this year brings us to over 11,000 participants in the four years we’ve run this survey. I would like to extend a BIG THANK YOU to all who participated! The survey started with a bang and was quickly followed by a shock wave. Just a week after our 2014 survey kicked off this year, the tech world was thrown off by the announcement of the Open SSL bug dubbed Heartbleed.
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.
Over the past four years, Sonatype has surveyed open source development organizations and year after year, we find that developers have the best intentions. They strive to build good quality code, free of defects and flaws but when it comes to policies that enforce these standards, the manual review process is at odds with how developers really work. If you don’t believe me, here are just a few examples of how developers describe the challenge manual policies create.
If you had a heart attack, would you stop eating cheeseburgers? For most people, the answer is “No”. A recent survey of 1,000 survivors found that 60 percent of heart attack victims weren’t sticking to a healthy diet and about 30 percent still had high cholesterol and blood pressure. Hey, old habits (especially the tasty ones) die hard. Funny thing is, the same behavior for those who have suffered a heart attack is found in application security. If you have been breached, chances are you have not changed your security diet.
Now that Heartbleed has become the new measuring stick for vulnerability disclosures, I have had several people ask me, “Is this OpenId/Oauth thing the next Heartbleed?” The long answer, as Run DMC once said, is “It’s Tricky, Tricky, Tricky, Tricky”. The TL/DR (too long/didn’t read) answer is “No”.
Like a good holiday the Verizon 2014 Data Breach Investigation Report (DBIR) is something I look forward to every year. Now that I’ve had some office time to digest this, I figured no better time to share my thoughts. I am not going to cover all sections, but do want to highlight a few things that stuck out to me
As the HeartBleed bug wreaked havoc on the internet over the past few days, we at Sonatype began thinking about the lessons learned from this recent scare and how, collectively, we can develop a process for mitigating the next major exposure.
Once upon a time, there was a great battle between speed and security. Development wanted to go fast. But, security wanted to slow down and be safe. For years, they endured the pain of testing late in the lifecycle, sorting through reams of false positive reports, and dealing with the added cost of pushing bad software out the door. They knew there had to be a better way…
Code snippet scanning is a common question we get from prospects. We typically try to dig at why the prospect actually thinks they need snippet matching. We think this comes from mis-informed demand. To create conversation with the masses on this topic, I’ve shared my perspective so you have a complete picture of the risk and cost of code snippet scanning.