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.
In part two of my blog ‘A Closer Look at Today’s Software Supply Chain’, I discussed why human-speed supply chain management can’t keep pace with today’s agile software development practices and why high quality software components are not simply a given. In this final segment, I will share a real world story on how thousands of organizations sourced one “bad part” named Bouncy Castle in 2013.
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
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 like automobile manufacturers, software “manufacturers” need to apply supply chain management principles for both efficiency and quality. They need to be prepared to conduct a rapid and comprehensive “recall” when a defect is found. And today’s modern development practices make this, well, challenging to say the least.
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.
Want to win a programmable LEGO robot? Share your voice in this year’s survey. The real intent of the Open Source Development Survey is to SPARK DISCUSSION. Remember, it’s not the stats that count…it’s the value of the discussions that follow that make this survey so important. So take 5 minutes and take the survey. (it takes less than 5 minutes, we promise)