Why is it next to impossible to provide proper incentives for developers to adopt software security? With all the different methods available, the technologies maturing, and top-down support in some instances ...why are organizations still struggling with software security?

This blog is a guest-post by Olivier Jacques who read my "The Secrets of Incorporating Security into Functional Testing" post and offered up one solution to this very issue, using HP assets and technology.  It's an attempt to provide a real-world solution to a big challenge many of us are facing - give it a read!

This point keeps coming up over and over again in security circles, and in products teams like mine here in Alpharetta, GA... where dynamic software security testing is the big hotness.  So what's the secret to getting functional testers to adopt 'security testing'?  Read on... I have a few ideas.

I just left Dublin, Ireland and OWASP AppSec Ireland '12 ...and have this little summary for those interested.  It was a great conference, short as it was, which filled me with hope for the future and gave me a renewed sense of optimism that maybe, just maybe, security can finally stop being an after-thought.

Episode 21 of Down the Rabbithole is now live!

This time I got the pleasure of sitting down and continuing a Twitter conversation with Nick Galbreath, James Wickett, and Olivier Saudan - to talk about what it means to 'deploy faster' in a fast-paced world of technology.

We're talking DevOps, continuous deployment strategies, Application Security and a sane way to do it all while getting the 'big risk picture' that doesn't only include security and hackers...

Each of these guests has a background in Information Security, each bringing their own tint of enterprise development, deployment, operations and security ... and it sparked a fantastic conversation that I think everyone can learn from.  I invite you to give this episode a try, and shoot back some feedback!

Direct link: Listen to the Down the Rabbithole podcast, Episode 21 NOW

Does it make you nuts when you see a mobile application that's supposed to be a game that demands access to your address book, the ability to make/receive SMS messages and other really big permissions?  You're not along, but I bet you still click "I accept" ... don't you?

Can software glitches like the one that almost ruined Knight Capital and caused a sizeable debacle on Wall Street be avoided, if we know the root cause?  I think so, but the key lies in the "knowledge gap" between various units within the software development lifecycle ... Here's my take.

As software development organizations make changes to their release cycles, build out their teams and strategies how do we answer whether these changes are impacting the organization in a positive or negative manner?  You can't just guess, you need real hard evidence ... so let's look at one proposed new KPI called the EDD.

Remember when slow and steady won the race?  Those days are over, if you're in enterprise IT, or more specifically software delivery.  Today slow and steady gets you a pink slip and the goals is speed... so what about security?

Another day, another hack.  This time it was a pastebin with evidence of SQL Injection against a production system with what appears to be a non-production (stage) database... what do you suppose the odds are of that system having real production sensitive data?

Every organization I know has gotten popped in one way or another.  Software security assurance programs have had a difficult time getting out of neutral for a number of reasons, but mainly because they still haven't figure out what to do about the developers.  There are so many options, so many ways to go ...

Is the thought of deploying software multiple times per day making your security-focused brain freak out?  What if I told you that there are security-minded people out there that think deployment at these insane paces is a good idea, and more importantly - good for overall software security?  Intrigued?

At the heart of DevOps is the notion that you should be able to diagnose and repair issues with your applications in production.  Yes, this includes security issues which are being identified by attackers which you didn't previously know about, and that haven't yet turned into an incident (that you know of).  This post is a quick reaction to Nick Galbreath's presentation on "Data Driven Security" and I think the talk and this post are worth your read.

Every once in a while I'm lucky enough to be asked to come speak as an outsider at a customer event.  Yesterday I was honored to speak at a large customer's developer-centric conference, where I spoke on the topic of DevOps and security to developers ...and they taught me a thing or two.  I think we all have something to learn from my experience.

Today I'd like to pose a very simple question that's been troubling me for a while now - Why do efforts to build and maintain software security programs keep falling off the priority table in the budgeting cycles at even the "big enough to know better" sized organizations?  It's a question I've been wrestling with for some time now and a few conversations with some very intelligent colleagues from companies you would definitely know at InfoSec World and other venues over the past 3 months have got me perplexed.  Perhaps the answer to this question comes down to corporate culture, enterprise priorities, or maybe it's something else entirely.  Without pointing fingers, this post is dedicated to those who continue to struggle with software security long after we all think everyone should "get it" by now...