This thread is worth reading. Gary McGraw launches the discussion of the differences between bugs and flaws, then John Steven posts an exploration of the issue:
I nearly fell through one of my consultant's tables as I leaned on it this
morning. We explored: "Bug or flaw?".
A bolt's head had been sheered. The sheer had allowed the bolt to wiggle
loose and made the table top wobble.
IMPL. BUG: The bolt's head was weak-enough to sheer*
* Some readers will complain that the bolt manufacturer should have made the
bolt stronger. Don't get bogged down, we're building a table 'system' here,
and we can't control the bolt any more than we can control IBM's
implementation of Websphere. With respect to this table 'system', we have a
bug.
Was there a masked bug? Was the truss' metal cut but not buffed in a way
that caused an otherwise strong-enough bolt to score over time and
eventually sheer under normal load?
ARCH. FLAW: [Some aspect of the table's design] caused the bolt to sheer.
ARCH. FLAW: The table's design is not resilient to a sheered bolt.
As Crispin, Steve, and myself would likely agree... Good application of
techniques involved in common architectural and code-based analyses would
have likely found all of these problems. Remember, my thesis is that the
real difference is what we do w/ the vulns., not now they're identified.
In my experience, where overlap between bugs and flaws exist, mitigating the
flaw is almost always warranted.
As a table architect, I could have calculated the forces the table would
face (through misuse case def.) and realized that my requirements warranted
a stronger bolt. I can't control the strength of the bolt, but I could pick
a stronger one (Maybe Jboss resists an attack that Websphere doesn't).
Alternatively, I could have designed my system so that the bolt's relative
weakness wasn't exposed. Specifically, I could have introduced more support
trusses into the legs, used additional bolts, pegs, or [whatever] at the
same interface, or scrapped my table design, and started over in an attempt
to avoid that weakness.
This spawns much debate. I have some thoughts inline with the thread, but this sounds like a job for risk management to me.
Comments