It 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:
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]veracode.com if you need help finding your mitigation history.