Why a Code Freeze Is a Cybercriminal’s Best Friend

Posted on by Tony Bradley

As we wind down 2015 and businesses prepare to shut down for the extended holiday break, many will also implement a code freeze. The code freeze is a normal operating procedure that occurs regularly as an application or software update nears release, or whenever there’s a crucial business milestone—like end of quarter or end of fiscal year. Unfortunately, a code freeze also means that vulnerabilities can’t be fixed and cybercriminals get an extended period of time to analyze and exploit flaws.

Many security professionals perceive change as the “enemy.” If the network infrastructure and all of the applications running on it would just stay the same then it would ostensibly be easier to keep tabs on everything and mitigate any vulnerabilities. The reality, though, is that if you slow things down so that there is only a monthly—or even quarterly—update window, you leave your network and data exposed to flaws and zero-day attacks for a much longer period of time.

It takes too long to fix most vulnerabilities as it is. Some estimates suggest that it takes more than 100 days on average to develop a patch after a vulnerability is identified. Implementing a code freeze allows the bad guys even more time to do nefarious things before a patch can be applied. That’s why the exact opposite approach—rapid development and more frequent updates—is a more secure approach.

The current trend—from Agile development to DevOps and continuous delivery—allows companies to identify and fix vulnerabilities in real-time. The rapid pace of change with DevOps and continuous delivery don’t result in reduced stability or security—at least not if it’s done right.

Continuous delivery means that organizations can deploy smaller, incremental changes ten times a day rather than waiting to deploy a behemoth monthly release. That decreases the window of opportunity for an attacker to exploit a known vulnerability, and it significantly simplifies the troubleshooting and resolution process if an update goes wrong. It is much easier to identify the cause of a system conflict after a small update that fixes one thing than it is to try and reverse-engineer a massive update to identify the problem.

Rapid development, continuous delivery, and automation are all things that seem to be anathema to security professionals. If you know vulnerabilities exist, though—and they do—then finding them sooner is a good thing. And if you’ve identified vulnerabilities—and you will—then developing and deploying fixes for them sooner rather than later makes you more secure.

Stop with the code freezes. Embrace DevOps and continuous delivery. 

Tony Bradley

Editor-in-Chief, TechSpective.net

data security

Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment. Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA Conference™, or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.

Share With Your Community

Related Blogs