Learn how to customize the OWASP Top 10 to fit your firm

A list of critical web application security vulnerabilities is a necessary risk management tool. Equally true is that each organization has a different set of vulnerabilities plaguing their applications. To complete a trifecta of fundamental truths, crowdsourced lists such as the OWASP Top 10 rarely reflect an individual organization’s priorities.

Given all that, many organizations continue to download the OWASP Top 10 and try to use it to guide their software security efforts. Since this likely won’t achieve the desired result, why not use it as inspiration to create your own evidence-based, customized list?

Why is a customized vulnerability list so important?

Identifying the vulnerabilities most prevalent in your organization’s applications provides real data. Data that encourages your development and security teams to actively improve their skills and processes. However, creating a satisfactory Top N list requires more than simply sorting one day’s or one application’s bug data.

Building a list from the results of code review, various security testing methods, and actual incidents experienced by your firm and/or industry allow you to craft a holistic vulnerability list. You’ll then be better prepared to drive change that reduces risk in your organization.

Customize your own comprehensive Top N list in 4 steps

Step 1: Gather vulnerability data

To understand what you’re up against, you’ll first need to gather web application vulnerability data for a given period. Go back as far as you can with the technologies you have. Six months of data should be a minimum benchmark. Obtaining such data is easier to gather if your firm tracks security bugs in a central repository.

If no repository currently exists, identify sources that contain vulnerability data. Collect reports associated with these sources. Next, extract the vulnerabilities into a spreadsheet or another data store.

Step 2: Normalize the vulnerability data

Normalizing the vulnerability data ensures that each vulnerability instance is only counted once per application. You don’t want one bug-filled application to skew your results.

Step 3: Create a vulnerability frequency table

Using the normalized vulnerability data, create a frequency table to list the number of times a given vulnerability was identified.

Step 4: Consider additional risk factors

Once you have vulnerability frequency data, add analysis for detectability, exploitability, and the impact. For each vulnerability in your list, also add a score for each risk factor.

Continue reading