RE: Is this list still active?

>I'm certainly trying to create spin when writing "How about the notion
that we've basically given up on security." As coders we haven't. But in
society there are signs of acceptance that viruses, worms, cracking,
phising and ID theft are unavoidable side effects of the information
age. Perhaps as a society we are starting to give up. 

[DCL]
Or maybe we're just starting to learn the computing equivalent of "don't
take candy from strangers" and "look both ways before crossing the
street". I also think that we can reduce all of these problems, but
cannot eliminate it. For example, most pen testers consider social
engineering to be cheating because it nearly always works. It's like
crime in the rest of the world - it will happen, despite our efforts to
minimize it.

>We all know how to make secure code because we've got organisations
like OpenBSD and Wind River showing everyone how it's done. It's a
painstaking, monastic review process that takes top people. I know that
some organisations have equivalent inquisitional groups for when they
can't afford to have their code blow up in their clients face but in
everyday code development there's no such rigour.

[DCL]
I'm not familiar with Wind River, but the OpenBSD team has done a lot of
good work. However, if we depend on very small, relatively elite groups
of programmers to deliver all our software, we won't have much to run.
We have to find solutions that scale to larger groups and which are
workable for ordinary programmers. That's a real challenge, and one of
the more interesting aspects of this problem. I think it involves:

1) Secure design practices - clean specs, threat modeling, etc. Merely
sweeping for implementation mistakes won't find design problems.

2) Better developer knowledge - we need better code auditing tools - the
security equivalent of grep can't do much. Use of more secure APIs,
people getting taught this stuff early and often in school, etc.
Security notes on CRT and system API calls. Getting the security monks
to review your code is good, but teaching everyone to do what you can do
is better.

3) More solid testing practices - real security testing, not just
functionality testing.

>Yeah, I like to think of code review in these terms; inquisition,
monastic. 
Perhaps these guys should wear robes :) Our code serves important and
sometimes critical social function, we don't just owe it to our
shareholders to produce good code, we contribute to the infrastructure
of society.

[DCL]
That's a really funny thought - I needed a laugh today. I'm envisioning
the Monty Python Spanish Inquisition sketch, but with code review...