Standard best practices for software development ask you to follow a ton of testing standards. From unit tests to mock tests to security tests with tools like Sonarqube and Veracode from a security static analysis perspective. When Infrastructure-as-Code and configuration languages started coming out, those same standards weren’t followed, especially with Dockerfiles to build a container image and Kubernetes Manifests using automated solutions like Kustomize to deploy a containerized image.
Because of that, applications were being deployed without security in mind, and often times vulnerabilities were (and still are) found well after the application was deployed to production. This not only drove app teams crazy but security and compliance teams as well.
In this blog post, you’ll learn why what you do with container image scan results after you receive them is just as crucial as running the scan itself. You’ll then learn where KSOC comes into play with automatic remediation of Kubernetes Manifests.
The Pitfall Of Policy-as-Code Scanning
How many times have you been on a security call about a report or spoken to the compliance team about generating reports? It always looks something like:
Scan the environment —> Generate a report about the environment —> send the report via email/slack.
…. then what? Typically, it sits in someone’s inbox or in a slack channel, both of which get bombarded by the messages/emails, and eventually the report just “goes away” until the next monthly or quarterly security meeting. This is a major problem because the reality is that a lot of these reports and remediation techniques don’t end up getting fixed until something catastrophic happens and the leadership team starts to buckle down on the need for security. This isn’t anyone’s fault, it’s just the way it is because engineers and managers are busy. Reading a report that gets swept away by other emails or messages ends up going on the back burner.
The other reality is it all depends on what type of field and organization you’re in. For example, it’s well known that healthcare organizations move rapidly slow when it comes to anything other than compliance needs. If it’s something for SOC2, HIPPA, or Hi-Trust, the security teams move quickly. If it’s something that’s DevOps, Platform, or App Dev specific, the security teams will typically say something along the lines of “figure it out and let us know”, which puts a strain on the teams because maybe the DevOps team thinks that the security team should help because it’s their domain, but the security team thinks it’s the DevOps teams domain. This causes major barriers between teams and irritation for engineers, all while the business continues to stay vulnerable.
How can we fix this?
How Scanning Can Be Improved
As you learned in the previous section, a lot of scanning that’s done from a Policy-as-Code perspective with today’s tools tells you what the problem is, but they never tell you how you can fix the problem. Better yet, they never automatically fix the problem for you. With everything that’s needed out of Platform teams, DevOps teams, and app dev teams in today’s world, the last thing you want to do is generate a Policy-as-Code report and then have it sit there for months because you’re too busy putting out other engineering-related fires.
For example, let’s say you run a report for a Kubernetes Manifest that doesn’t have memory limits set. Depending on how many Manifests or Kustomize configurations you have in your repos, that can be a lot of manual effort and work. Instead, it would make sense if you could run Policy-as-Code, and then the fixes for the configuration code/YAML are automatically there for you in a Pull Request for the code in your repo. Then you know that the Pull Request is open and the fixes are there. All you have to do is view them and click “commit”.
You need a tool that’s going to automatically remediate the situation for you. There are so many products that decide they don’t want to go down this route because of a few reasons:
- Production environments are complex customer by customer
- The product can never truly “know” everything about an environment
- There are multiple layers and differences in best practices for remediation
However, KSOC is up for the challenge of figuring out how to fix this. Instead of being just another security scanning company, KSOCs mission is automatic remediation of security vulnerabilities in your Kubernetes environment. Regardless of if it’s cluster/Ops security or application/Dev security, KSOC wants to do it all. That way, you can focus on providing true value with the work that you’re doing instead of spending all of your time putting out fires.
Enter KSOC
Now that you understand the pitfalls of container image scanning and how it won’t ensure a Kubernetes environment is secure, it’s time to focus on the importance of what you do after a container image is scanned and how to take the automatic remediation steps with KSOC, which focuses on Kubernetes Manifests to further secure your environment after container image scanning.
You’re able to set rules based on best practice scans that are pulled from several resources, including the National Vulnerability Database (NVD), like a rule that scans to see if values inside of a Kubernetes Manifest using a configuration data automation tool like Kustomize is setting memory limits, which are crucial for quotas and resource limit best practices in Kubernetes.
Once you define your rules, you’re able to connect to a Git-based repository, like GitHub, and choose what repo’s to add to KSOC.
Once you've chosen a repo with your rules in it, in real-time KSOC will run every change in your Kubernetes environment against the rules, surface any findings, and automatically remediate misconfigurations with a pull request.
Learn more at www.ksoc.com.