It’s been about 11 months since the first time I ever spoke with Joshua Corman. He had this idea for a Rugged Software movement and wanted some feedback. After he filled me in on the concept, I told him I thought it was a good idea, and told him I was in. A few weeks later the Rugged Manifesto was published. There were a flurry of blog posts, and a bunch of email discussions, which ended February this year. Since then, I have heard … crickets. New stuff on RuggedSoftware.org? No. OWASP? Nada. Twitter? Presentations? Chat groups? Pretty much not a damned thing.

So what’s up, guys? Where is the movement? What problems have been solved? Don’t ask what is missing from software security; ask what’s missing from Rugged!

Josh, David, and Jeff … I am calling you out!

When the Agile Manifesto was originally published, there were a lot of frustrated software engineers who had specific problems, gripes, and issues that they wanted to address. They did not necessarily have the right answers, nor did they know what tools and techniques would work (either for themselves or for others), but they identified specific problems to address (lack of planning, fear, outside influencers, periodic validation, people’s inability to estimate, etc.), and had a bunch of stuff in their bag of tricks (peer programming, task cards, stories, test driven development, etc.).

The Rugged Software movement has some of the same ingredients: a bunch of frustrated security professionals want code to be secure. And many very public security failures illustrate the need. And we have the same piss-poor failure analysis and finger-pointing that looks very familiar as well. But I don’t think we have adequately identified the problems that contribute to insecure code, and we definitely don’t have a bag of tricks ready to go.

If you look closely at Agile techniques, most are actually process changes, without much to do with actual code. The processes were designed to address issues of complexity and lack of metrics, and to minimize negative human interaction. Do we have a similar set of guidance for Rugged? Nope.

What’s missing? At this stage, at least three things:

  1. Clear, concise, no-BS descriptions of the problems that lead to insecure code.
  2. Some simple techniques, tricks, and ideas to help people get around these problems.
  3. Some people to help get this rolling.

I am not trying to shove all this onto the backs of the three gents who started this movement. They need help. I want to help. And I know that there are many security pros and coders who will help as well. And I really don’t want to see another year of inactivity on this (sorry) ‘non-movement’. Ultimately I think Rugged is the right idea. But just like 11 months ago, there is a concept without direction. We don’t need a complete roadmap – early extreme programming sure wasn’t complete – but we do need to start moving the effort forward with some basics ways to solve problems.

I push. You push back. Or not. Your call.

Share: