RE: Writing Secure Code...

>> You can't fix it if you bought it closed source.

> I see, you are talking about _purchased_ software. Well sure, that's
an advantage... but really, how many people make use of it ? And maybe
it's appropriate for some people, but (obviously) the typical end-user
couldn't care at all about that aspect. (i.e. the typical user
corporations aim for...)

I in general do not want to pay the price of learning someone else's
code to that extent. My time is worth something, so if someone else's
software does not work the way I'd like, I generally either ask them to
fix it, use someone else's software, or if it is something I know a
little about, write my own. Only if I were really interested in the
project would I get involved enough to think about submitting fixes (and
obviously I personally would have to be working elsewhere).

Companies usually don't have the bandwidth, particularly with respect to
operational people, to keep real programmers on staff and give them time
to go fix things.
 
>> I wholeheartedly agree. Business decisions + software = shoddy 
>> implementation. OSS removes the business decisions and leaves the 
>> programmers to thrive in excellence.

>But you say "OSS" projects are "funded" by corporate customers. This -
money - introduces "business" decisions... (i.e how to spend the money,
and how to get more of it).

Right - which goes back to my original premise that security is a very
weak function of business model and who you let read your source. It is
a strong function of the processes, practices and education level of the
people creating the software.

Another point would be is that at the end of the day, nearly everything
is a result of a sort of business decision. A very interesting book
which has the premise that most of our decisions can actually be
modelled using economics is "Hidden Order: The Economics of Everyday
Life".

I think we should try and get back on topic - leave the OSS vs.
proprietary debate for elsewhere. I don't think it is really important
to security. What's a lot more interesting to me is how to effectively
create processes, practices, and information that leads to more secure
software, whereever you happen to be writing it.