SC-L,
Saw this via Gunnar Peterson's blog (http://1raindrop.typepad.com/
1_raindrop/2007/05/common_attack_p.html)... Check out Mitre's first
draft of CAPEC, the Common Attack Pattern Enumeration and
Classification database (http://capec.mitre.org). It complements the
existing CVE
I think my thinking was a little different. I would also expect criteria that
shows how it integrates into the entire lifecycle. For example, scanning source
code that is already extracted is a little different than scanning a PVCS
repository. Likewise, taking a list of vulnerabilities and
[snip]
Good to see that folks are expanding the criteria in terms of
what it scans for, but criteria as to how it integrates is
also equally useful.
On the contrary I find the idea of evaluating tools by what they scan
for very disturbing. It shows a continuing belief that software
All,
My last two posts to Cigital's blog covered whether or not to build your
security standards specific to a technology-stack and code-centric or to be
more general about them:
http://www.cigital.com/justiceleague/2007/05/18/security-guidance-and-its-%e
2%80%9cspecificity-knob%e2%80%9d/
And
In my experience, a tiered approach is useful. The higher up you are in the
policy framework, the more general and time-enduring the content should be.
The farther you progress down the framework to a more detailed level, the
more perishable the content will be, out of necessity. The reason that
