I am looking into setting up security scanners across podplane and related projects to identify any CRITICAL / HIGH security concerns to enforce your intentions of the project being “secure by default”.
The security scanners I have used in the past are https://trivy.dev/ and https://www.checkov.io/ - of independent value. These can be setup as github CI and local verifiers to validate configurations and dependencies across a range of technologies within the projects:
- Golang
- Docker, Helm
- Terraform / OpenTofu (IaC)
- Kubernetes
I am wondering if there is any preferences around security you would want Ryan? Just noting, these scanners can provide output to a json convention SARIF - Static Analysis Results Interchange Format. This provides security findings in a unified structure which can be used inconjunction with other security tools.
My current aim is to configure this across components. It would then support ideas of triage across the breadth of the podplane + dependent projects. I’m not a security expert, but I do consider a good start for identifying, and managing visibility against security threats.
Keen for feedback.
Hey Max, welcome to the forum, thank you for taking the time to post! And sorry for the delayed reply - it seems notifications don’t work how I’d expect, I need to look into that!
I think this is a great idea. Particularly once the MVP feature set is complete (I don’t think I have formalised this, but roughly: local, AWS, Google Cloud, and Proxmox should all work for all implemented CLI functions and relevant components).
So right now I’m prioritising closing that MVP feature gap myself, then will switch focus to bug squashing and doing a security audit, ideally ahead of a 1.0 release. Some things on my mind for improving the security posture: looking at distroless and minimus base images instead of stock base images for all components and templates, and reviewing vmconfig to ensure it aligns to Debian hardening best practices (maybe consider AppArmor too, for example). There’s also things like Kubernetes production best practices check lists and known configuration-based CVEs which need another review to ensure the latest Kubernetes component configuration continues to align to those.
My experience with security scanning tools is that signal-to-noise is critical - if the number of actionable items is lost in a sea of things which cannot be immediately actioned, it becomes difficult to prioritise them. So my main ask is that we find a way to bubble up the most important stuff that we can tackle first, rather than a boil-the-ocean approach. Obviously as the project progresses, as more contributors come onboard, we can dial this up!
So the question becomes, you have a bunch of output in JSON files like SARIF - what are we going to do with this? How do we convert this into a small number of prioritised issues? Assume each contributor tackles a small number each week. And ideally we can tune it such that it keeps a backlog roughly consistent in size - as total contributor velocity drops or increases, adjust accordingly. The number of CVEs is exploding with AI, so to make this impactful, prioritisation is the key. Of course, I’m willing to keep an open mind to any approach which improves the security posture!