Best noted by Royal Hansen : “Google Site Reliability Engineering(SRE) I was thrilled to find that focused on security and reliability was already underway when I arrived at Google, and am only too happy to contribute in a small way to the process. Ever since I began working in the tech industry, across organizations of varying sizes, I’ve seen people struggling with the question of how security should be organized: Should it be centralized or federated? Independent or embedded? Operational or consultative? Technical or governing? The list goes on....When the SRE model, and SRE-like versions of DevOps, became popular, I noticed that the problem space SRE tackles exhibits similar dynamics to security problems. Some organizations have combined these two disciplines into an approach called“DevSecOps.”Both SRE and security have strong dependencies on classic software engineering teams. Yet both differ from classic software engineering teams in fundamental ways:

•Site Reliability Engineers (SREs) and security engineers tend to break and fix, as well as build.

•Their work encompasses operations, in addition to development.

•SREs and security engineers are specialists, rather than classic software engineers.

•They are often viewed as roadblocks, rather than enablers.

•They are frequently siloed, rather than integrated in product teams. SRE created a role and responsibilities specific to a set of skills, which we can see as analogous to the role of security engineer. SRE also created an implementation model that connects teams, and this seems to be the next step that the security community needs to take. For many years, my colleagues and I have argued that security should be a first-class and embedded quality of software. I believe that embracing an SRE -inspired approach is a logical step in that direction”.