RE: Re: Application Insecurity --- Who is at Fault?

["Joel Kamentz" <Joel.Kamentz () sas com>]

Re: bridges and stuff.

I'm tempted to argue (though not with certainty) that it seems that the bridge analogy is flawed
in another way --
that of the environment.  While many programming languages have similarities and many things apply
to all programming,
there are many things which do not translate (or at least not readily).  Isn't this like trying to
engineer a bridge
with a brand new substance, or when the gravitational constant changes?  And even the physical
disciplines collide
with the unexpected -- corrosion, resonance, metal fatigue, etc.  To their credit, they appear far
better at
dispersing and applying the knowledge from past failures than the software world.

Let's use an example someone else already brought up -- cross site scripting.  How many people
feel that, before it
was ever known or had ever occurred the first time, good programming practices should have
prevented any such
vulnerability from ever happening?  I actually think that would have been possible for the
extremely skilled and
extremely paranoid.  However, we're asking people to protect against the unknown.

I don't have experience with the formal methods, but I can see that, supposing this were NASA,
etc., formal approaches
might lead to perfect protection.  However, all of that paranoia, formality or whatever takes a
lot of time, effort
and therefore huge economic impact.  I guess my personal opinion is that unit testing, etc. are
great shortcuts
(compared to perfect) which help reduce flaws, but with lesser expense.

All of this places me in the camp that thinks there isn't enough yet to standardize.  Perhaps a
new programming
environment (language, VM, automation of various sorts, direct neural interfaces) is required
before the art of
software is able to match the reliability and predictability of other fields?

Is software more subject to unintended consequences than physical engineering?

Joel