But I am very much encouraged that the Rugged movement isn't just about developing software. It is envisioned to encompass the entire life of software, from design through operations and maintenance. Again, these are words we've heard before, but perhaps our collective frustrations with the status quo are sufficiently high that we can now actually put those words into action. Here's hoping.

More than has been true of S-SDLC, the Rugged movement aims to provide guidance to software developers, who would start by publicly stating what they do to make their software rugged. We see similar things in other realms, such as consumer product quality labels. Can it help make software more secure and rugged? The jury is out, but perhaps by publicly claiming certain aspects of an application's security, developers will take things more seriously. Again, here's hoping.

And some of the guidance would be actionable. Rugged envisions providing assistance to software developers on things like criteria for selecting a programming language for a project, advice on using that programming language securely and so on. Rugged also intends to help support development of new programming language technologies that are free of today's common defects. (Imagine a middleware language in which dynamic SQL queries are not even possible. Instead, all SQL queries would be parameterized, as with Java's PreparedStatement API.)

Still feeling some trepidation about the Rugged Software effort as I headed for this month's sessions, I was reassured by the attitude I noticed among the initial team gathered in Washington. I told them that I feel that software should be more "self-aware," so that it knows when it is under attack, can provide business contextual alerting to the security team, take active steps to evade the attack and thus protect the business data and processes it handles. This notion was consistently met with agreement and support.

In the end, the Rugged Software movement will be judged by the users and developers of software, of course. Whether it succeeds or fails will depend on whether CIOs and other business executives buy into it and start demanding more of their software -- whether that software is built in-house, is outsourced or sits in someone's . And it will need to break through to the developer community, which is justifiably leery of a group of self-appointed security experts trying to tell them what to do. Hopefully, the inclusion of people like Wilander will help there.