I've been reading a great paper by Daniel J. Bernstein, the creator of a qmail, and wow, what a pearl of wisdom. One of the most clarifying and straight to the point works on code security I have ever read. He (quite correctly) makes a parallel between the code security and the amount on exploitable bugs (EB), stating that it is the major problem on the code, regarding security. And then gives some answers to that problem, along with a couple of common distractions of the programmer while coding that helps those EB creep on our code base (CB). Let's review then, starting with the distractions, and I'll try to make some links with my favorite unambiguous tool of choice, Ruby.

1. Chasing attackers. The point here is give some thought to respond to tomorrow's attacks, and not being trapped by the anti-virus mentality of being only responsive to aggressors. Perhaps the dynamic nature of Ruby would help with that, but I think it is more a personal posture problem than anything else.
2. Minimizing privilege. Here, what is being said is that the old principle of least privilege is fundamentally wrong. How so? Well, it might (!) reduce the damage done by security holes, but never fixes these. Plus, IMO, it might even give users a false sense of security. Again, it is more of a way of a personal way of thinking (but what isn't? :P ).
3. Speed, speed, speed. Here I think rubists have some advantage. Since we work on a language that is 'slow', usually we tend to not place emphasis on premature optimization. I think this quote summarizes the thinking here:

   Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time; premature optimization is the root of all evil. —Knuth in [13, page 268]

Now, to the answers. These are also 3, and they are codependent connected to each other:

1. Eliminating bugs. I think everyone saw that one coming. But even so, Daniel's down to earth advices on it are a very worthwhile reading. I think I can summarize him on this section by saying (and that is a plus to rubists too), simplify stuff. Simplify interfaces, UI, parsing. Elegance is not a luxury, it is a way to obtain security. Following that logic we come to.
2. Eliminating code. Heck, here I'll quote his quote, and be done with it.

   To this very day, idiot software managers measure 'programmer productivity' in terms of 'lines of code produced,' whereas the notion of 'lines of code spent' is much more appropriate. —Dijkstra in [9, page EWD962–4]

   But as our systems grow, and our time and budgets remain the same or are diminished, and as programmers get more dumb, something has to give right? Wrong (don't know about the last part though).
3. Eliminating trusted code. That is somewhat more difficult I think, but it says that a program should do what it is meant to do, nothing more, and trust as few sources of data as possible. KISS and all that stuff.

I would love to hear any input on that. Until next time people.

The approach of Douglas Sellers about testing their AJAX heavy system really sounded to me as an excellent idea. I can imagine in the future this being adopted by more and more web systems, as they embrace javascript for building RIAs more and more.

Essentially they have built a DSL on top of selenium using ruby (yay), for testing the AJAX stuff on their page, aiming at easiness to write the tests, trading the complexity of writing the tests for the complexity of the DSL itself, trying even for the non technical people on the company to write their own tests.

Really recommended for a fresh and no nonsense view on testing.