When it is treated as an afterthought, security can never work. When enterprises purchase and write thousands of applications without any formal app security mechanism, they are opening themselves up to breaches. What recent reports show is that there is a real disconnect between the spend on applications and the investment in protecting them.
Gartner is projecting that U.S. enterprises will drop $380 Billion/year on developing and buying applications by next year and the tiniest fraction of that will be spent on application security. That's like spending the $4.5 million dollars on a Lamborghini and then parking it outside with the doors unlocked. Yes, it is an amazing vehicle but you are leaving it vulnerable.
The problem is threefold. It is not usually that IT management doesn't understand/appreciate the need for app security. So what is the problem?
In other words, they assumed that the application infrastructure—the interconnected high-tech industry itself, if you will—was going to protect them.
Let's take these one at a time. Not making app security a sufficiently high priority. This speaks to security spend. Many IT and security teams are forced to take the “peanut butter” approach to cybersecurity. There are so many areas on which to focus, they end up not focusing at all. Instead they spend 10 percent of budget on network security, 10 percent on endpoint security, 10 percent on application security and so on. As a result, no one area is strong and all are weak. Since applications are the number one attack vector, is stands to reason that applications are the area that companies should be paying the most attention to in regards to security.
In addition, true security has a cost and it's not limited to money. An oft-cited reason for coders/developers to rush their apps into deployment is because of timing pressure from the line of business. Time to market is indeed essential, which means that departments must anticipate their needs and request apps early enough so that there's time for sufficient security efforts.
When an app development request is being prepared, business units must insist on seeing a projected timeline so that they can make sure that there is enough time allocated for research and post-production security testing. That additional time in the timeline is essential. It's hard to fully blame developers for security lapses when management is only giving them two weeks to deliver. However, companies working in CI/CD environments can’t add time to their cycles and need ways to assess applications for vulnerabilities that work right in the development process.
Most critically, you need to retain specialized app security talent. A third-party service is the most cost-effective route because you want teams who are familiar with the latest app security holes. As long as code-reuse shortcuts are commonly used, such experience is essential and the larger number of verticals they are helping, the better.
And although the adage does say that time is money, in this case, money is also money. That means that businesses need to have a specific line item in internal app development for security testing and research. Nothing is free or magical. Businesses can't spend nothing on app security, allocate no time for the developers to spend effort on app security and then be surprised when vulnerabilities emerge after the app has gone live.
The dynamic changes somewhat when dealing with apps purchased externally, whether it's off-the-shelf or custom code. Your agreements with ISVs must be unambiguous that your company expects clean and secure code and that initial responsibility for security falls on the ISV. Software vendors are under huge time-to-worker and cost pressures. Therefore, unless paying clients insist on documented security processes and sign off on the additional time/money such efforts require, it's hard to fault ISVs for not delivering.
Your company's security spend speaks directly to your priorities. Make sure that app security is one of them.