Software security and reliability have been compared and contrasted for several years, with the primary point being that both have the goal of protecting customers and consumers. However, with the continued adoption and maturation of the devsecops and site reliability engineering (SRE) movements, there is an increasing overlap between the two. When carried out appropriately, this maximizes stakeholder value.
Anyone who has worked in cybersecurity for some time is familiar with the CIA triad, which stands for confidentiality, integrity and availability. Metrics related to availability are a critical part of the devops (and subsequently devsecops) movement. These come in the form of the Devops Research and Assessments (DORA). These metrics include meantime to recover (MTTR) and change failure rate (CFR). If proposed changes fail and impede availability, and it takes unacceptable lengths of time to recover, you’ve now compromised both security and reliability.
We’re seeing a push for organizations to adopt secure devops practices, with studies such as the State of devops Report showing that high performers don’t sacrifice speed for stability (availability). A growing number of organizations are adopting SRE principles, aiming to learn from outages and turn fragile systems into antifragile and reliable ones.
Short lead time for changes boosts security
Despite the obvious relationship between MTTR and CFR, another DORA metric also has a strong potential impact from the security perspective. This would be the lead time for changes metric. This metric is often associated with the time it takes to go from code committed to code successfully running in production. It is generally discussed in the context of quickly being able to deliver value to customers or end users.
