The processes enabling an organization to release updates more frequently also enables faster recovery when things go wrong — and with fewer mistakes reaching production in the first place.

But this defies cybersecurity folk wisdom, in which speed is scary and more frequent changes set organizations up for security failure. Why is there this disconnect between cybersecurity superstition and reality?

Worrying about developers inadvertently introducing changes that could lead to a data breach or other kind of security incident is understandable. If an organization increases their engineering velocity, will the metaphorical train careen off the rails?

Change can feel terrifying when the prospect of failure looms in an uncertain future, so restricting change and slowing down operations can feel like the right course of action.

Unfortunately, the common traditional solution involving manual or heavy security reviews as the final hurdle before release actually increases the likelihood that security issues will fall through the cracks. Lengthy security reviews directly reduce release frequency, which can incentivize larger releases with lots of changes bundled together.

More changes mean more complexity, which begets more vulnerabilities and other security issues being overlooked during review. Ultimately, the larger the release, the harder it is to ensure its rollout is smooth, stable and secure — the opposite of the intended aim.

The reality is that obstructing speed in the name of security backfires in practice. Empirical results consistently show speed and stability are friends rather than foes, despite what traditional textbook cybersecurity suggests. Failure is inevitable, so slowing down activity in the hopes of blocking security incidents from happening is not only ineffective but is also actively damaging to business operations. Cybersecurity without speed is a lose-lose proposition.

To support resilience to attacks, organizations must support speed. Resilient systems are those which can recover from incidents quickly and efficiently adapt to changing environments. But speed is also essential to help human defenders become as nimble as attackers and adopt more strategic, dynamic approaches to cybersecurity.

Low-risk changes

If a company or its security team's ultimate desire is for lower-risk changes, then the answer is more frequent and smaller releases that are less complex to understand and assess.

In fact, this desire overlaps with the aims of continuous delivery: releasing changes to end users that are higher quality, safer, and more reliable. This is accomplished by releasing small chunks of work quickly in as automated a fashion as possible, not by waiting for an external group's approval pending a laborious, lengthy review process.

The empirical evidence supports the correlation of speed and safety. The data show organizations that are fastest at delivering software also exhibit better security practices. Slower, heavier processes for managing changes are not correlated with lower change failure rates, so the sacrifice of speed does not actually curtail failure.

The elite software delivery performers spend only 5% of their time remediating security issues, but low performers — those with slower operational tempos and more hurdles to releasing changes — spend 10% of their time on remediation.

The fastest DevOps organizations conduct security reviews and implement changes in mere days; in contrast, the slower, more cautious organizations take weeks to conduct security reviews and even more time to implement changes.

This backfiring effect of heavy change processes meant to improve quality and stability is widely understood in the context of change approval boards (CAB), which are now commonly seen as an anti-pattern. It is only a matter of time before the equivalent in cybersecurity — heavyweight security reviews and processes — is similarly seen as an anti-pattern.

A fast, reliable release process for regular changes means organizations can deploy emergency changes, including urgent security fixes, quickly and without worrying it will cause performance problems that degrade the user experience. Deploying a commit into production within an hour can be viewed either as a recipe for introducing buggy updates too quickly, or as an opportunity for security updates, fixes, and changes to be delivered more quickly than previously possible.

This is why one of the two key DevOps metrics for speed, lead time for changes, is about more than just pushing features to production as rapidly as possible. Lead time also encompasses keeping up with compliance and regulatory changes, patching infrastructure, and dealing with vulnerabilities, all of which benefit enormously from speed.

Patch with confidence

All the tools and processes enabling the ability to release confidently also enable the ability to patch confidently. Organizations of all sizes and types worry about their ability to implement patches before attackers exploit known vulnerabilities and speed can support better patching strategies.

Automated CI/CD pipelines mean patches can be tested and pushed to production in hours rather than the days, weeks, or even months that it traditionally takes.

Runtime security benefits from speed and automation, too. Automated reprovisioning of infrastructure means compromised workloads can be killed and redeployed as soon as an attack is detected, without impacting the end user experience.

This does not mean security review is not important; it means it can't deny the reality of speed as an important factor to support resilience.

Early input into design and reviews of proposed business logic can set projects up for success. In contrast, deflating momentum as a release approaches in the name of security will only serve to frustrate stakeholders.

Peer review during development plus automated and continuous testing, integration, and monitoring provides better visibility into potential security issues while granting developers more time and flexibility to address necessary fixes instead of forcing them to scramble right before a release.

Security teams can either slow themselves and developers down, or optimize their security strategy to support velocity as safely as possible. Developers are creative and are prone to doing whatever they want anyway.

Denying reality will result in a cybersecurity program that works in theory rather than in practice, but embracing speed as an enabler of resilience can help organizations achieve their security goals without sacrificing business outcomes.