Developing secure software. Was: Re: [Dshield] DCOM morning after

Paul Fottler paulf at
Wed Aug 13 17:25:12 GMT 2003


I have to agree with Jon regarding this. While I was not employed as a programmer/developer, I was network support at a U.S. Navy base involved with development of weapon and tracking systems. In conversation with the developers, I learned of the high standards their programs met. The main resaon for this in my mind, and the minds of those developers, is simple: LIVES depended on this code. If there were bugs or errors, the people using it could, and probably would, die. Because of this, the management was willing to spend the money to make sure everything is done right; taking the time to both develop and test. Also, the people sitting at their computers writing the code or testing it every day had that thought in their minds. They wanted to make DAMN SURE their programs worked perfectly to protect LIVES.

Now, take a commercial software company as a comparison. My roommate is a QA tester, and a few of our friends are as well. They regale me with stories of the sloppy, cost/corner-cutting methods that both the overly-pressured programmers as well as  management use to "ship it by the deadline". This deadline is generally set by marketing department lackeys who decide ship-dates based on things like "we should have this product out two weeks before Christmas" or "this would be great as a back-to-school promo" or company financial-related things (end-of quarter sales), nothing having to do with actual project estimates. My roommate reported that in several cases, the testing team was directly told "you will ignore this bug, we will not be fixing it" on bugs that were terminal (i.e. CRASH the program or system). He was even disciplined for submitting one such bug to their tracking system after having been told at a meeting to ignore it. In commercial software, it's all about sell!
ing the product and getting the CASH.

Paul Fottler
Information Systems Lead
Salem Communications

> -----Original Message-----
> From: Jon R. Kibler [mailto:Jon.Kibler at]
> Sent: Wednesday, August 13, 2003 7:44 AM
> To: General DShield Discussion List
> Subject: Developing secure software. Was: Re: [Dshield] DCOM morning
> after
> Stephane Grobety wrote:
> > SV> Why can't Microsoft just make sure that they are stuffs 
> are correctly and
> > SV> securely written and coded?
> > 
> > That's a delusion. Software without bugs doesn't exists. The average
> > piece of software, when initially written, has about one 
> bug every 50
> > lines of source code when written by a good programmer. 
> With strong QA
> > and lots of testing, this number can be changed to one bug every 200
> > lines of code, on average. Oh, and that's not Microsoft's code, BTW,
> > it's everyone's.
> > 
> I beg to disagree. I have worked on several large DoD (U.S. 
> Department of Defense) projects during my 30-something years 
> in this business, and NONE of the mission or safety critical 
> projects that strictly followed DoD Software and Systems 
> Engineering Standards EVER had that many (1 per 200 LOC) bugs!
> In fact, one weapon systems project I worked on had several 
> million LOC, and at delivery to the customer, it had 6 known 
> bugs. All were fixed and no new software bugs were reported 
> during the first year of deployment.
> Developing far less buggy software than is commonly seen 
> today can be easily done. The technology to do so has been 
> available since the early 1970s. 
> It is informative to compare how most IT managers view costs 
> vs. how most DoD managers view costs. In IT, management tends 
> to look strictly at development costs. Whereas, DoD tends to 
> look strictly at the life-cycle cost of a system.
> Yes, software developed under strict DoD standards and 
> practices is expensive -- typically costing 2 to 5 times the 
> cost of a comparable size commercial system. However, the 
> entire product life-cycle cost of a DoD software system is 
> typically only 20% to 30% that of a commercial system. Why? 
> Support costs are far lower because you are not constantly 
> patching and rebreaking the software.
> Good, clean, secure software CAN be written. The only issue is cost.
> Sincerely,
> Jon R. Kibler
> A.S.E.T., Inc.
> Charleston, SC  USA
> _______________________________________________
> list mailing list
> list at
> To change your subscription options (or unsubscribe), see:

More information about the list mailing list