Bad application security habits don’t merely make enterprises less secure, although they certainly do that. They drain resources, make development take far longer, and threaten a lack of compliance. Combined, this makes the application development process far more expensive and orders of magnitude less efficient. It eats into the time of people well beyond the development and security teams, touching many units relying on the new software to work as the specs dictate.
Old security habits can delay critical application updates, undermine the brand’s reputation and slow down the roadmap. This potentially robs the enterprise of significant revenue opportunities. If the problem is not, however, caught before release, the situation is far worse, potentially causing serious problems with customers.
Why are modern applications so riddled with expensive security problems?
It makes much more sense to invest in early and continuous AppSec, than to risk breaches and the associated lost business income. But why do some security executives struggle with this principle and rely on old security practices?
1. Time to market pressures
Developers are typically under extreme time pressures from managers. The result can be unreasonable deadlines and when developers are rushed, security mistakes happen. Even worse, those unrealistic time demands may result in code-checking being shortened or even eliminated.
2. Misuse of unvalidated third party code
Code re-use, such as open-source components, is not on its own a bad practice. Indeed, it’s quite the opposite. For app creation, it’s lunacy for the coder to try and recreate every capability, given that so much has already been done. That said, it’s hard to precisely determine how much quality-control was done on publicly available components. Those holes can be unintentional holes that some programmer made years ago or, far worse, some intentional malware that a bad actor planted with the hope that it would spread wildly. In short, code re-use is necessary but it must be done cautiously.
3. Manual security activities
Historically, automatic security tools did not meet expectations, which resulted in reduced adoption. As a result, some security executives prefer to rely on manual security activities. Lack of security automation means that security validation is expensive, slow, and prone to errors.
Prevention reduces the cost of insecure code
The least expensive way to release secure software is to incorporate security at the earliest stages of the Software Development Lifecycle (SDLC). By moving your checks and balances into the earliest stages of application development, an enterprise can much more easily and cost-effectively reduce the security hole nightmare.
Another best practice to reduce the cost of insecure software is to implement continuous security testing, as opposed to gate-based (waterfall) tests that happen at a given point in time.
Lastly, infusing a general culture of security is proven to reduce the cost of security. We like to say that security is everyone’s responsibility.
Security automation is the best fix
The security automation approach balances security, code quality, and time-to-market. It slashes the cost of security because it catches problems before they go any further into the SDLC. The farther along a software problem goes undetected, the more expensive and the more disruptive it becomes.
Enterprises have quickly adapted to routine third-party pen testing, which is fine for certain application security issues that tools cannot detect automatically. But it is a not very efficient fix for the far more common problem of security bugs. Security automation is the most viable approach to catch those kinds of security problems. Address that and most of the most common security issues are fixed, including a quick time-to-market.
The key to effectively deploying a security automation suite is to find tools that integrate seamlessly with everything that the enterprise is already using, as opposed to imposing new tools that deliver more friction.