(This post is a taste of my presentation at the nCircle booth at RSA. Come by and see it if this is interesting).

Web application risk is a hot topic these days, but there's something missing from the discussion. Vendors seem to be focused on addressing web application risk in a vacuum. They limit their marketing and products to custom web applications and ignore two things: vendor supplied web applications and what I'll call the dependency risk of web applications.

When you choose to deploy a web application, you're deploying much more than just that web app. There is, of course, the web application itself.

Whether it's custom built or vendor supplied, the web application can be vulnerable to things like cross-site scripting, SQL injection or cross-site request forgery. Think about all the products you've deployed that are managed via a web interface. They're all potential sources of web application risk. But the risk doesn't stop there. That web application has to run on some kind of HTTP server.

The web server itself can be vulnerable to buffer overflows, directory traversal, cross-site scripting (again) and other conditions. But wait, there's more. That web server has to run on some platform, whether hardware or virtual, you've got an execution space that can also be vulnerable. There are a near infinite number of vulnerabilities that might exist on the OS or other applications running the web server itself.

Finally, there's likely a database somewhere on the back-end. It may have sensitive data or may be vulnerable itself or may run on yet another vulnerable platform.

The point here is that scanning just your customer-built web applications or scanning them with a completely separate tool just doesn't cover the whole problem. You can't make good risk mitigation decisions without a clear view of the entire risk context.