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.
Another informative and well-presented RebelLabs survey has hit the streets. Their 2014 Java Tools and Technologies Landscape report was just released and hats off to them for ‘their better than ever response rate’ and their good will for charity donations from each completed survey response. This year’s survey covers more than a dozen different tool/technology segments within the Java industry.
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.
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…
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.
What can the financial services industry learn from the U.S. Department of Homeland Security? In this third segment of my blog series on open source component security as it relates to the recently updated Financial Services Information Sharing and Analysis Center (FS-ISAC) guidelines, I explore the need for speed: humans vs. machines.
In short, open source security can’t be an after thought. Security isn’t only the responsibility of ‘security professionals’ but instead a shared responsibility for all parties involved in developing or managing an organization’s software supply chain. Better put in the FS-ISAC guidelines…