SRE or Site Reliability Engineering can be defined in many ways, but according to Sal Kimmich, Developer Relations at Sonatype, it is what happens when developers start to do what was traditionally known as operations, focusing on aspects such as bringing together systems to ensure reliability. However, this does not necessarily mean 100% reliability and this is carving the way for SREs as they move forward in understanding how to best deal with expected failures and navigate vulnerabilities.

In this episode of TFiR Let’s Talk, Swapnil Bhartiya sits down with Kimmich to discuss the role of SRE and how widely it is being embraced by organizations. She goes into depth about the need for SRE best practices and some of the security challenges in open source projects.

Key highlights from this video interview are:

• SRE can be defined as when developers focus on what used to be known as operations, which is primarily ensuring technical reliability. However, we have come to realize that that does not necessarily mean 100% reliability and from that, the role of SRE is being driven towards how we can best navigate these challenges. Kimmich explains how SRE can be defined and what it entails.
• The DevOps movement has changed the developers’ workloads and responsibilities. SREs are brought in to help solve problems such as dealing with outages and optimizing the system itself. Kimmich goes into detail about the cultural shift by combining DevOps with SRE and how it removes some of the cognitive load of DevOps engineers.
• The SRE movement came about around ten years ago from Google so is still relatively new. 70% of actively employed SREs have been employed in that role for three years or less. While that suggests companies are starting to embrace SRE it depends on the size and maturity of the technical team. Kimmich discusses to what extent they are seeing a cultural shift and how SRE could work from a security perspective with open source.
• Kimmich shares insights into how companies can embrace the SRE culture to ensure security is not compromised such as contributing back any patches when consuming open source. She goes on to discuss the importance of pre-incident reports and how they can help ensure tools are in place for when an incident occurs.
• There is a narrative that security comes as an afterthought but Kimmich tells us that most open source projects have only one to three maintainers. She believes that there does need to be better awareness for maintainers on how to address cybersecurity concerns. She goes on to explain how bringing SREs into the DevOps team can help navigate this challenge.
• While security tools can be useful in addressing security challenges, it also needs to be firmly ingrained in the process. Kimmich discusses why there is a need for mandatory basic standards of security practice in open source to ensure that the packages being pulled are relatively likely to be free of vulnerabilities due to best practices being shared.
• Kimmich explains the work she is doing with the CNCF such as the Bug Bash. She takes a deep dive into the Bug Bash and how it is helping remove vulnerabilities whilst educating people and why best practices need to be put in place to enable developers to better handle real-time security events.
• Although there are several products offering automation, Sonatype aims to improve the intelligence by capturing the vulnerabilities allowing any language you have sitting inside your system to be represented. Kimmich explains what sets Sonatype apart from other products, going into detail about their product Lift and how it is helping to solve the open source security problem.

Connect with Sal Kimmich (LinkedIn, Twitter)
Learn more about Sonatype (Twitter)

The summary of the show is written by Emily Nicholls.