Security can often feel like a top-down initiative — install an antivirus, do this training so you know how to avoid being phished — that kind of thing. But good security starts from the bottom up, and organizations implementing service ownership need to push this down to the level of the developer/service owner.
Most developers don't know how to own the security of their services; they hand off an application or, as is often the case today, a container, which they hope Ops will handle and secure. As a result, Ops teams feel overwhelmed by the sheer number of services being deployed that they’re suddenly responsible for. An Ops or "platform" team of any sufficient size can be the sole entity in the organization responsible for the problem, and that’s just too much for them to manage alone.
The average developer spends their lives worrying whether the service they're delivering is conforming to the API standards the organization has set, or is giving the user the outcome they desire. The developer wants to ship the features they're required to ship, and they want to make sure the service is up and doesn't fall over under strain. They aren't concerned with security, because they're hoping someone else in the organization understands the problem better and knows how to address it.
So how do you make the issues visible at the developer level? True service ownership requires tooling that enables the developer to play their part in helping your organization maintain its security posture.
It’s important that you choose modern tooling that enables your developers to understand what they need to fix and how to go about fixing it. That includes tools that scan the code or can stop a deployment before it hits production because it has overly permissioned settings.
Thankfully, there are great tools in the open source community for doing things such as container scanning, checking for known CVEs. But the solution is limited by each step of the deployment process:
A platform team can implement open source solutions that will help your organization maintain its security posture — and expose the developer to those tools so that each service can be fully owned. This helps your developers not only ship the desired features and make sure the service runs reliably, but also maintains the necessary security posture.
When you're deploying to a uniform place — such as a Kubernetes-based infrastructure — you need to ensure that people are doing things according to best practices. Fairwinds Insights makes this easy by integrating into the CI/CD pipeline in a way that developers are already familiar with. They can see when their deployments contain security issues early on, well before they reach production. This visibility for developers is critical — without it, they can’t see how what they're doing fits into the big picture, and they don’t know whether they're doing it right.
In college, I had a job where it was my job to use a leaf blower to clean off a large part of the college campus. I remember my boss coming by once and telling me I was doing it all wrong and that he would have to do it again as a result. He didn't tell me what I was doing wrong or how to improve it — he simply told me it was wrong. I remember saying something to him that was akin to, "I want to do this job well, but you've given me no training and I have no idea what the result is that you want beyond 'a clean sidewalk.'" In other words, he gave me no path to success.
Don’t do that to your developers. Help them by providing visibility into your Kubernetes environment by providing a dashboard view of your clusters and enforcing compliance requirements automatically. This visibility and control helps your teams understand how what they’re doing fits into the larger picture (a clean sidewalk), so they understand how misconfigurations cause security and compliance risks. Insights helps developers learn how to assign ownership to the right person or team to resolve those issues. The goal isn’t for your CISO to manage security alone; managing security well requires dev, sec, and ops teams to make security a service owner responsibility — a change that requires tooling and cultural shifts in your organization, but will ultimately make your services more secure.