Skip to main content
June 4, 2013

Review Your Exceptions Early and Often


pride-and-prejudiceIt is a fact universally acknowledged that an organization in possession of a good policy must also be in possession of an exception process; the stricter the policy, the more efficient the exception process. While this piece of wisdom can be usually applied to any area, it is doubly true when it comes to application security policies and processes. These must contend not only with resource and budget constraints within the security teams, but also with the ever increasing need to accelerate time-to-market and deliver feature rich applications by development organizations.

There is nothing wrong with granting security exceptions. Here at Veracode, and especially within the services organization, we firmly believe in the importance of synergy between the application security team and the development organization. However, no such relationship can exist without an exception process. While we promote ownership of application security by developers, we do not entirely discount the claim that “Our developers are just too busy to worry about securing their applications.” That may be an overstatement, but often when a security policy competes with an organization’s bottom line, the bottom line will take precedence.

Even so, we mustn’t resign ourselves to applications riddled with security flaws! Here are a few guidelines to keep in mind for a functional and efficient exception process:

  • Do not let the exception become the rule: if you find yourself granting exceptions to the application security policy more often than not, then it is time to review the policy. It may be too strict to be effective, misunderstood, or incorrectly applied.
  • Application security exceptions should be time boxed when possible, for example: high severity flaws could have a grace period of thirty days while medium flaws could wait sixty. Pay down technical debt whenever and wherever you can.
  • Exceptions should be tracked rigorously and reviewed often: they represent accepted risk and should be tracked in the organization’s risk inventory. This will also enforce expiration of time boxed exceptions.

The goals of an application security policy and its accompanying exception process must always be to enable the business to be secure, efficient, and most importantly, to be a business. A good place to look for untracked exceptions is in your mitigation history on the Veracode platform. Search for comments like “will fix in the next release” or “do not have the resources to fix it now”. Contact Veracode support at support[at] if you need help finding your mitigation history.

Related Content

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.