-Original Message-
From: sc-l-boun...@securecoding.org on behalf of Benjamin Tomhave
Sent: Thu 19-Mar-09 19:28
To: Secure Code Mailing List
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security
Alchemist(informIT)
Why are we differentiating between software and security bugs
[mailto:list-s...@secureconsulting.net] Sent: Fri 20-Mar-09 11:04 To:
Goertzel, Karen [USA] Cc: Secure Code Mailing List Subject: Re:
[SC-L] BSIMM: Confessions of a Software Security Alchemist(informIT)
So, what you're saying is that security bugs are really design
flaws, assuming a perfect
; Secure Code Mailing List
SC-L@securecoding.org Sent: Thursday, March 19, 2009 2:50 AM
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security
Alchemist (informIT)
Hi Steve,
Sorry for falling off the thread last night. Waiting for the posts
to clear was not a great idea.
The top N
Goertzel, CISSP
Booz Allen Hamilton
703.698.7454
goertzel_ka...@bah.com
-Original Message-
From: sc-l-boun...@securecoding.org on behalf of Benjamin Tomhave
Sent: Thu 19-Mar-09 19:28
To: Secure Code Mailing List
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security
On Mar 18, 2009, at 23:14, Steven M. Christey wrote:
I believe this is reflected in public CVE data. Take a look at the
bugs
that are being reported for, say, Microsoft or major Linux vendors
or most
any product with a long history, and their current number 1's are
not the
same as
Steve,
You saw my talk at the OWASP assurance day. There was a brief diversion about
the number of business logic problems and design flaws (coarsely lumped
together in my chart). That 'weight' should indicate that-at least in the
subset of clients I deal with-flaws aren't getting
Hi Kevin,
Any discipline with the word science in its name probably isn't. I have a
dual PhD in two of those fields (computer science and cognitive science), so I
ought to know.
I mostly agree with your assessment of many industry coders and IT people (most
of whom do NOT have a background
Hi Steve,
Sorry for falling off the thread last night. Waiting for the posts to clear
was not a great idea.
The top N lists we observed among the 9 were BUG lists only. So that means
that in general at least half of the defects were not being identified on the
most wanted list using that
Hi Gary,
On Mar 19, 2009, at 16:27, Gary McGraw wrote:
Hi Stephan,
In my view, it would be even better to study the difference in
external bug emphasis (as driven by full disclosure and the CVE) and
internal bug emphasis (as driven by an organization's own top N list).
That is a
List SC-L@securecoding.org
Sent: Thursday, March 19, 2009 2:50 AM
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist
(informIT)
Hi Steve,
Sorry for falling off the thread last night. Waiting for the posts to
clear was not a great idea.
The top N lists we observed
dustin.sulli...@informit.com; Secure Code Mailing List
SC-L@securecoding.org
Sent: Wednesday, March 18, 2009 11:54 AM
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist
(informIT)
Hi Steve,
Many of the top N lists we encountered were developed through the
consistent use
...@cigital.com; Michael Cohen
mco...@cigital.com; Dustin Sullivan dustin.sulli...@informit.com;
Secure Code Mailing List SC-L@securecoding.org
Sent: Thursday, March 19, 2009 2:50 AM
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist
(informIT)
Hi Steve,
Sorry for falling off
SC-L@securecoding.org
Sent: Thursday, March 19, 2009 9:04 AM
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist
(informIT)
Actually no. See: http://www.cigital.com/papers/download/j15bsi.pdf
(John Steven, State of Application Assessment, IEEE SP)
I am not a tool guy, I
hi sc-l,
The BSIMM is a sizeable document, so digesting it all at once can be a
challenge. My monthly informIT column this month explains the BSIMM in a much
easier to digest, shorter form. The article is co-authored by Brian and Sammy.
BSIMM: Confessions of an Alchemist
Hi Steve,
Because it is about building a top N list FOR A PARTICULAR ORGANIZATION. You
and I have discussed this many times. The generic top 25 is unlikely to apply
to any particular organization. The notion of using that as a driver for
software purchasing is insane. On the other hand if
On Wed, 18 Mar 2009, Gary McGraw wrote:
Many of the top N lists we encountered were developed through the
consistent use of static analysis tools.
Interesting. Does this mean that their top N lists are less likely to
include design flaws? (though they would be covered under various other
Hi Steve,
Many of the top N lists we encountered were developed through the consistent
use of static analysis tools. After looking at millions of lines of code
(sometimes constantly), a ***real*** top N list of bugs emerges for an
organization. Eradicating number one is an obvious priority.
On Wed, 18 Mar 2009, Gary McGraw wrote:
Because it is about building a top N list FOR A PARTICULAR ORGANIZATION.
You and I have discussed this many times. The generic top 25 is
unlikely to apply to any particular organization. The notion of using
that as a driver for software purchasing is
On Wed, 18 Mar 2009, Gary McGraw wrote:
Both early phases of software security made use of any sort of argument
or 'evidence' to bolster the software security message, and that was
fine given the starting point. We had lots of examples, plenty of good
intuition, and the best of intentions.
19 matches
Mail list logo
