The Long Road Toward Building Secure Software at Enterprise Scale

Since the rise of eCommerce in the late 1990s, enterprises have sought ways to improve the security of their software. Urgency to improve application security came when there was a wave of exploits and automated attacks in the form of worms and exploits started to hit.

Unfortunately, since then, while software makers, software services providers, and enterprises began working to improve the security of the applications they build they haven’t reduced software related security flaws to the point where attacks against software have been muted.

Since those early days, enterprises have tried many ways to meet the challenge and improve the security of their applications and web services. These include manual peer reviews whereby developers analyze each other’s code to identify potential security flaws. These reviews often are mandated with an enterprise policy that requires application code review. However, few firms have ways to be sure that these reviews are actually getting done. And most certainly without the proper toolsets, there is no way to verify that they are done well.

Other organizations relied heavily on educating their developers on security application development practices. While education like this always helps — especially in a fast-moving field like software development — it’s certainly not comprehensive enough without proper assessments and quality enforcement.

In fact, these manual assessments and security policy efforts toward resilient application development always fell short. This is why enterprises that took software security seriously began testing their applications with automated security assessment toolsets before they shipped to production. These tools assess the actual application code for the mistakes that make software susceptible to attack. Yet, despite the many years of effort, enterprises still struggled with ways to best develop software that is more resilient and secure.

This is just as true for the tools used to assess software for security vulnerabilities as it is for the enterprises trying to implement effective processes and create the secure development practices they need.

For a long time, most software security checks took place at the end of the development processes. It was common for organizations to have small security teams in place that evaluated applications for their level of security at the end of the development cycle. Only then do they work with development teams to fix the flaws uncovered. Despite working as quickly as they can, this process is rife with challenges and development bottlenecks. Some of these setbacks can be quite costly.

 

Application security tools are being deployed in a number of common ways in enterprises today, and much of the choices depend on how development teams build their code, within rapid sprints and more agile development approaches or with longer conventional software development cycles.

Fixing application flaws late in the development process is not only costly from a technical perspective but it slows down developers and forces teams to go back and work on code that shipped weeks ago. These teams have moved on to other things, and both their minds and efforts are elsewhere.

When security-related defects are found this late, developers must step back and refocus on what they had been working on weeks ago. Sometimes, the original developers are no longer available to work on the fixes; they have moved on to other projects that they can’t be pulled from. This means new teams must be brought up to speed to fix the code. It also means more errors are likely to be introduced.

In addition, depending on when the security defects are identified, the fix may require a significant enough change that would evoke additional regression testing. So, it’s not just about fixing and testing the one module; it could cascade into a lot more activity. This translates to production slowdowns and more cost.

The rise of DevOps changed how software and infrastructure is delivered and managed in the enterprise, and it’s also changing application security. Lots of people call this change DevSecOps, others don’t like that moniker much. I’m fine with it, knowing that hopefully, one day, it’ll just be understood that best security practices for an organization are built within DevOps. DevSecOps is the melding of security practices within DevOps. That essentially means, when it comes to application security, that the practices that produce secure software are blending into DevOps practices.

These practices include code analysts, securing during development. Threat modeling apps, delivering small pieces of software that can be secured and rollbacked if necessary, and of course continuous security monitoring.

Time will tell how well DevSecOps manages to actually improve application security, but for now there’s good reason for long-term optimism.

Let’s hope it does. After all, business is so dependent on software today that whether it is an independent software vendor or enterprise, when applications break down and software development slows, business does, too. And, of course, software flaws open everyone to attackers who wish to disrupt operations or steal or destroy data.