[WEB SECURITY] WASC Threat Classification vs. OWASP ASVS

Boberski, Michael [USA] boberski_michael at bah.com
Thu Jul 16 09:18:40 EDT 2009

Hi guys. My name is Mike, I'm the project lead for ASVS.

For the larger audience, it's more than a "philosophy" - ASVS does NOT prescribe how one may wish to go about figuring out if an ASVS verification requirement is met. There is no text in the document that contains that type of information.

ASVS as Jeff explained groups verification requirements into levels that folks may then use as a yardstick (after verification against the requirements is performed) to measure the degree of trust one may wish to place in the targeted Web application.

ASVS may also be used by security control developers ("How should my security controls work?") and during procurement ("I want an ASVS Level x review of my Web app").

ASVS can be used in YOUR life-cycle wherever you'd originally planned or are already performing appsec scan/code review/pentest/architecture review. Do what you normally do, use ASVS to tweak your approach. That's the upshot.

I wrote a brief article recently to explain to an Agile Scrum-based development shop one possible way to go about adding code reviews using ASVS into their life-cycle, perhaps helpful:



Mike B.

From: Jeff Williams [mailto:planetlevel at gmail.com]
Sent: Wednesday, July 15, 2009 9:22 PM
To: websecurity at webappsec.org
Subject: RE: [WEB SECURITY] WASC Threat Classification vs. OWASP ASVS

Glad to see this discussion.  Sorry I'm late.

ASVS is not a process guide at all.  ASVS defines the set requirements for security controls that need to be verified in an appsec scan/code review/pentest/architecture review.  The process you use to do this verification is up to you.  To allow organizations to compare the coverage of different application security services in the market, ASVS has 4 levels: 1. automated, 2. manual, 3. architecture, and 4. internal.  Very few commercial applications are reviewed beyond level 2.

Philosophically, ASVS (and OWASP for that matter) doesn't really care whether you use a black-box or white-box technique to verify the requirements. I suggest you use the cheapest approach on a requirement-by-requirement basis depending on the particular application to be verified.  Any other approach will waste money by definition.

Organizing security reviews around security controls makes sense (to me anyway). It's just easier to understand the coverage. It's *possible* to organize these efforts around attacks and weaknesses, but there are so many of them that completeness becomes very difficult.  Is there a plan to cover the 700+ CWE in the TC?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20090716/fe61856f/attachment.html>

More information about the websecurity mailing list