How GitOps Benefits from Security-as-Code
Security-as-code is the practice of “building security into DevOps tools and workflows by mapping out how changes to code and infrastructure are made and finding places to add security checks, tests, and gates without introducing unnecessary costs or delays,” according to tech publisher O’Reilly. In this latest “pancakes and podcast” special episode — recorded during a pancake breakfast at KubeCon + CloudNativeCon in October — we discuss how security-as-code can benefit emerging GitOps practices.
The guests were Sean O’Dell, director of developer advocacy, Accurics, Sara Joshi, who was an associate software engineer for Accurics when this recording was made; Parminder Singh, chief information security officer (CISO), for hybrid-cloud digital-transformation services provider DigitalOnUs; Brendan O’Leary, staff developer evangelist, GitLab; Cindy Blake, senior security evangelist, GitLab; and Emily Omier, contributor, The New Stack and owner of marketing consulting provider Emily Omier Consulting.
Alex Williams, founder and publisher of TNS, hosted the podcast.
The emergence of security-as-code signifies how the days of security teams holding deployments up are waning. “Now we have security and app dev who are now in this kind of weird struggle — or I think historically had been — but bringing those two teams together and allowing flexibility, but not getting in the way of development is really to me where the GitOps and DevSecOps emerge. That’s kind of the big key for me,” Blake said.
Developers today are deploying applications in an often highly distributed microservices environment. Security-as-code serves to both automate security for CI/CD with GitOps while also ensuring security processes are taking interconnectivity into account.
“It’s sort of a realization that everything is so interconnected — and you can have security problems that can cause operational problems. If you think about code quality, one of your metrics for ‘this is good code’ doesn’t cause a security vulnerability,” Omier said. “So, I think a lot of these terms really come from acknowledging that you can’t look at individual pieces, when you’re thinking about how we are doing? What metrics should we be looking at? You really have to look at the whole.”
Security-as-code should also serve to support access control. Setting and enforcing policy about who can grant access to users, for example, should be integrated with security as code and GitOps processes.
Singh noted how in one customer case access control “had to be built into a pipeline where we allowed multiple people to actually get access.”
“So, that’s where the workflow would change substantially just to meet some of these requirements,” Singh said.
Joshi noted how security professionals or tools to help developers integrate into their GitOps workflows should be “automated in a way that is meaningful to them, and helps them write secure code without having to understand the full background of what security professionals do everyday,” Joshi said. “That’s what we try to do at Accurics: our product is integrated into git workflows so that developers don’t have to worry so much about what the fix is or you know, what has to be done in the background behind it.”