Clear objectives and goals are key to success for any initiative, and AppSec is no exception. But many organizations struggle to establish application security goals, or focus on the wrong goals to the detriment of their program. Below we outline factors to consider when creating goals for your application security program.
Metrics
At a high level, the goals for your AppSec program should focus on a set of core software quality metrics:
- Fix rate: Your fix rate = fixed flaws divided by (fixed + open flaws).
- Flaw density, for instance flaws per MB of code: Flaw density —measured as the number of flaws divided by the size of the application —makes it easier to compare apples to apples across different teams or business units.
- Applications compliant with your policy.
Additional factors
The above are only the core metrics; you might have more based on your business goals, such as developer education benchmarks, or the number of applications that have been assessed or retired, or the level of scan activity.
In addition, when developing the goals and policy for your application security program, you should always consider the following factors:
Types of apps and types of vulnerabilities
Not all apps are created equal, nor are all vulnerabilities. Make your AppSec goals more targeted and effective by focusing on certain applications and vulnerabilities. For instance, an application that has IP, is public facing and has third-party components may require all medium to very critical flaws to be fixed. A one-page temporary marketing site may only require high/very high flaws to be fixed.
In addition, don’t give every vulnerability the same level of attention. Rank vulnerabilities so that you are focused first and foremost on those that are actually increasing your risk. For instance, it’s important to distinguish between flaws that represent a remote risk and those that represent more substantial, real-world risks. In some cases, the likelihood of a vulnerability being exploited may be low, but the potential damage might be great. In other instances, the chance of exploit might be high, but the damage may not be substantial.
For example, when collecting data for our most recent State of Software Security report, we found code quality flaws in twice as many applications as SQL injection vulnerabilities. However, that does not mean they pose twice as much risk as SQLi to the state of software security. Probably quite the opposite. As a class, SQLi tends to present flaws of a much higher severity and exploitability than code quality vulnerabilities.
Security know-how of your team
If security is being introduced for the first time or being enforced for the first time, start off with some achievable policy standards. Don’t make a team that has never had security built into their daily cycle try to meet PCI or all OWASP requirements; they will not pass, feel defeated, and give up before they start.
Start with a simple policy: no high or very high critical flaws. Then get more stringent over time as developers adopt security into their daily routine.
Industry you’re in
Your industry might dictate the regulations you are subject to, and the type of testing you need to conduct and goals you need to meet. For instance, retail will be subject to PCI, and finance might need to comply with the NY DFS cybersecurity regulations.
To see how others in your industry are tackling application security, what vulnerabilities they are seeing most often, and where they are seeing success or falling short, check out our most recent State of Software Security report, which includes data from our platform broken out by industry.
Learn more
Get more details on setting realistic and effective goals for your application security program in Everything You Need to Know About Application Security Policies.
