Hey Ryan,
Appreciate the feedback and I agree with you on your approach. I’ve put together:
Based on some analysis I’ve put together over the weekend based on your MVP approach. The only thing I’d want to assert is whether vmconfig is used within the deployment clusters? Or is it only used during the purpose of testing?
Scanners
On security scanners, I think your absolutely right you’d want to manage the signal. Your current posture is fairly strong with using distroless/static:nonroot images by default, so far so is AppArmor shouldn’t be strictly unless you’d be considering to cover included third-party components.
Interestingly kube-bench which can audit Kubernetes production best practices is managed by the parent company Aqua Security · GitHub under the Apache 2.0 license. This is the same company providing Trivy CLI for static analysis. A combination of approaches would be good to play around with which is my intent.
My original idea with SARIF is to collect any of the CRITICAL / HIGH CVEs across all netsy.dev, nstance.dev and podplane to combine for a formal triage. What that would look like - IDK. Simpler things like dependabot would be a more appropriate first steps too. I’ll continue looking into what you recommend.
My appraoch
Personally I’d like to setup a scanner and kube-bench formally via Github CI which can be managed cheaply using terraform-aws-github-runner. It’s something I’ve setup for myself before as a low-cost way to manage Github Actions. I can share this once I’ve got this tidy within a personal Github Org scope.
I’ll need to start deploying to all cloud targets to verify any changes don’t break backwards compatibility. If you have any recommendations for how you have set this up for yourself in a way that’s easy, I’d be all ears. I typically use direnv + a`sercets-manager` for managing deployments to different clouds, but am without specific techniques to validate any breaking changes across your different targets other than hard up/down across each environment.
Cheers