Bugs and flaws

[brian at fortifysoftware.com (Brian Chess)]

I spent Phase One of both my academic and professional careers
working on hardware fault models and design for testability.
In fact, the first static analysis tool I wrote was for hardware:
it analyzed Verilog looking for design mistakes that would make
it difficult or impossible to perform design verification or to
apply adequate manufacturing tests.  Some observations:

- The hardware guys are indeed ahead.  Chip designers budget for
test and verification from day one.  They also do a fair amount
of thinking about what's going to go wrong.  Somebody's going to
give you 5 volts instead of 3.3 volts.  What's going to happen?
The transistors are going to switch at a different rate when the
chip is cold.  What's going to happen?  A speck of dust is going
to fall on the wafer between the time the metal 2 layer goes down
and the time the metal 3 layer goes down.  What's going to happen?

- The difference between a manufacturing defect and a design
defect is not always immediately obvious.  Maybe two wires got
bridged because a piece of dust fell in exactly the right spot.
Maybe two wires got bridged because you made a mistake in your
process physics and you need 50 nm of tolerance instead of 0.5 nm.
You'd better figure it out before you go into full-swing
manufacturing, or big batches of defective chips could kill your
profit margins and drive your customers away at the same time.
For that reason, diagnosing the cause of failure is an important
topic.

Brian

-----Original Message-----
From: sc-l-bounces at securecoding.org [mailto:sc-l-bounces at securecoding.org]
On
Behalf Of Chris Wysopal
Sent: 02 February 2006 21:35
To: Gary McGraw
Cc: William Kruse; Wall, Kevin; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws



In the manufacturing world, which is far more mature than the software
development world, they use the terminology of "design defect" and
"manufacturing defect".  So this distinction is useful and has stood the
test of
time.

Flaw and defect are synonymous. We should just pick one. You could say that
the
term for manufacturing software is "implementation".

So why do we need to change the terms for the software world?  Wouldn't
"design
defect" and "implementation defect" be clearer and more in line with the
manufacturing quality discipline, which the software quality discipline
should
be working towards emulating. (When do we get to Six
Sigma?)

I just don't see the usefulness of calling a "design defect" a "flaw".
"Flaw" by
itself is overloaded.  And in the software world, "bug" can mean an
implementation or design problem, so "bug" alone is overloaded for
describing an
implementation defect.

At @stake the Application Center of Excellence used the terminology "design
flaw" and "implementation flaw".  It well understood by our customers.

As Crispin said in an earlier post on the subject, the line is sometimes
blurry.
I am sure this is the case in manufacturing too.  Architecture flaws can be
folded into the design flaw category for simplicity.

My vote is for a less overloaded and clearer terminology.

-Chris

P.S. My father managed a non-destructive test lab at a jet engine
manufacturer.
They had about the highest quality requirements in the world. So for many
hours
I was regaled with tales about the benefits of performing static analysis on
individual components early in the manufacturing cycle.

They would dip cast parts in a fluorescent liquid and look at them under
ultraviolet light to illuminate cracks caused during casting process. For
critical parts which would receive more stress, such as the fan blades, they
would x-ray each part to inspect for internal cracks. A more expensive
process
but warranted due to the increased risk of total system failure for a defect
in
those parts.

The static testing was obviously much cheaper and delivered better quality
than
just bolting the parts together and doing dynamic testing in a test cell.
It's
a wonder that it has taken the software security world so long to catch onto
the
benefits of static testing of implementation.  I think we can learn a lot
more
from the manufacturing world.

On Thu, 2 Feb 2006, Gary McGraw wrote:

> Hi all,
>
> When I introduced the "bugs" and "flaws" nomenclature into the
> literature, I did so in an article about the software security
> workshop I chaired in 2003 (see http://www.cigital.com/ssw/).  This
> was ultimately written up in an "On the Horizon" paper published by
> IEEE Security & Privacy.
>
> Nancy Mead and I queried the SWEBOK and looked around to see if the
> new usage caused collision.  It did not.  The reason I think it is
> important to distinguish the two ends of the rather slippery range
> (crispy is right about that) is that software security as a field is
> not paying enough attention to architecture.  By identifying flaws as
> a subcategory of defects (according the the SWEBOK), we can focus some
> attention on the problem.
>
> > > From the small glossary in "Software Security" (my new book out
> tomorrow):
>
> Bug-A bug is an implementation-level software problem. Bugs may exist
> in code but never be executed. Though the term bug is applied quite
> generally by many software practitioners, I reserve use of the term to
> encompass fairly
> simple implementation errors. Bugs are implementation-level problems
> that
> can be easily discovered and remedied. See Chapter 1.
>
> Flaw-A design-level or architectural software defect. High-level
> defects cause 50% of software security problems. See Chapter 1.
>
> In any case, I intend to still use these terms like this, and I would
> be very pleased if you would all join me.
>
> gem