You can’t get away from it. Thousands of open source components are being used in every industry, every day, to quickly build and deploy applications. For those not in the security industry, it’s hard to keep track of what is being done in this field to manage and monitor open source usage. This article is the first in a series where we will talk about open source in layman terms, identify how prevalent open source is in the modern development environment and how teams are approaching the management of such a multi-headed hydra.
While there are many books I have read during my career as a software engineer, there are a handful that have been influential in my thinking. Here are my top 2 books for software developers. If you’ve read them before, you might want to read them again through the experience lens of your development career.
Over a month has passed since HeartBleed was announced to the public, and while saturation into the mainstream media likely peaked shortly after that, it can often be interesting to revisit technical revelations like this one from a layperson’s perspective.
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.
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)
I love watching TED Talks. To me, they are 15 well-spent minutes watching experts around the world provide great insights into things I thought I knew well. Some I had never imagined or topics on which I want to gain a deeper perspective.
The recent FS-ISAC whitepaper, “Appropriate Software Security Control Types for Third Party Service and Product Providers”, reveals the majority of internal software applications created by financial services involve acquiring open source components and libraries to augment custom developed software. While open source code is freely available and reviewed by many independent developers, that review effort does not translate into all software components and libraries being free from risk.