In part 1 and part 2 of the ‘[ ________ ] is the Best Policy’ series, we looked at how open source policies can quite often lead to the wrong type of behavior in an organization. As we saw, 41% of development professionals stated they are generally looking for the path of least resistance when it comes to compliance with policies — many of whom will put a non-trivial amount of effort into working such policies.
At the Black Hat 2014 Conference in Las Vegas, Mark Miller, Community Advocate for Nexus, and Executive Producer of the OWASP 24/7 Podcast Series, presented the third installment of the OWASP security news quizz, “Wait, Wait! Don’t Pwn Me!”. Play along and see how many news stories you can identify for the month of August […]
In Part 1, ‘[ ________ ] is the Best Policy, we looked at some of the common aspects of an open source policy and discussed how our recent survey discovered that 41% of people think that policies are not enforced. Now in Part 2, we will look at how effective policies are when considering security concerns.
Open source has been around for donkey’s years but until recently the persuasive argument of “many eyeballs” was the guiding policy when using open source. In comes the recent industry shock wave we all know as Heartbleed and now many of us are re-evaluating the cost of free software.
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.
While Repository Health Checks are valuable, we just released something even better: the CLM 1.11 Dashboard. First of all, it helps you answer the first two critical open source vulnerability questions: did we ever use that and where is it? And, you can find out the answers to those questions in about three seconds.
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.
Paul Roberts (@paulfroberts) at InfoWorld recently shared his perspective on “5 big security mistakes coders make”. First on his list was trusting third-party code that can’t be trusted. Paul shares: “If you program for a living, you rarely — if ever — build an app from scratch. It’s much more likely that you’re developing an application from a pastiche of proprietary code that you or your colleagues created, partnered with open source or commercial, third-party software or services that you rely on to perform critical functions.
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.
In our recent open source developer survey we asked, what are the TOP FOUR characteristics considered when selecting a component? And since components are the building blocks used when creating an application, selecting the right one is an important choice. Not surprisingly, the most important characteristic for the selection are the features and capabilities provided by the component. After all, if the component doesn’t fulfill your requirements then why use it?