Would someone please explain this Rugged thing to me?

I'm steeped in a huge SSDL project here at work - looking to move security in our development processes to the next level.  Lots of heavy lifting doing evaluation, analysis and reorganizing.  I'll throw in a shameless plug for WhiteHat Security who's helping us a ton.

Now, one of the things that came up in my search to see how to improve things was the Rugged Software movement.   Early on in the process, I foolishly mentioned it to our CTO as something to look at.   Why did I saw this was this foolish? Well, because at the time, I had only a cursory understanding of Rugged.   He went off and dutifully checked into Rugged only to find the bare documents on the website.  Indeed, it was a movement, but apparently not much else.. at least at that stage of the game.  He came back to me confused and wondering why I had brought it up to him.  What was he supposed to do with this Rugged thing?  Oops, I had just wasted some credibility and an important ally's time.   A mistake I wasn't going to repeat.

Well, here we are months later, and I'm afraid I still have only a cursory understand of Rugged.  Apologies to Josh and the other creators of Rugged, but I just don't see anything there worth passing on yet.  Maybe it isn't aimed at our developers? I don't know.  It wasn't clear.  I'll be the first to admit I've not attended any conference talks on Rugged (I admit here, I don't make to many conferences) and I don't attend many webinars or online thingies (they're often hard to follow).  I have googliated a bit and haven't found much beyond a few news articles.  On the other hand, I have found tons of advice and guidance on practical secure development frameworks like BSIMM.

Overall, my big questions / confusions are:

1) How is Rugged different than any other "Best Practice"? 
Is there any evidence yet to show that it improves security?  Can I see it?   Can I share it with management?


2) Convincing the Developers to write more secure/stable software isn't my problem.
Talk to them, as I have, and most of them wouldn't mind writing more secure code.  Some of them even want to write more secure code.  And a certain chunk of them don't know how to write secure code.  I don't see how Rugged solves any of these problems very well.    The root of the problem comes from the fact that secure code still isn't spelled out in the requirements.  Developers can only do what the project manager demands, which is based on what the customer demands.   So if Rugged is aimed at convincing customers to ask for more rugged software, specifically and pointedly asking, then I'll admit it should be preached (but not to me, to my customers).


3) Software security problems are deep and complex.
A lot of security bugs are buried deep in old crufty code or libraries.  Even when all our developers are cracking on all cylinders of secure code dev, we're still excavating for fundamental faults and design flaws.  And when you land in those pits, you're dealing with Expensive Questions - redesign ($$$) or patch-and-move-on.   I need a movement that helps me make those decisions.


4) Rugged appears mysterious and embrionic.
I'm sure it will grow up to be influential and useful, but to be practical to me right now, I need something that's actionable that I can use with my Development team and management.    The story I mentioned in the opening about confusing my CTO cannot be repeated.   And beyond that, my executive team will ask for proof and metrics for any new development movements I propose.   I don't blame them.


So please, help me out here.  I am confused, what am I missing or misunderstanding?

UPDATE - People have stepped up to 'splain it to me (ha, my evil plan worked).  Read what I've learned here.