I've been running a proof-of-concept for our small team's shift-left security posture, and while GitHub Advanced Security's CodeQL is undoubtedly powerful, the licensing cost for a 5-person engineering team is a significant hurdle for us right now. We're a fully containerized, multi-cloud shop, and our primary need is static analysis for our Go and Python microservices, with a secondary focus on keeping our Infrastructure-as-Code (Terraform) secure.
I've spent the last few weeks evaluating open-source alternatives, and the landscape is both crowded and nuanced. I'm curious to hear from others in similar-sized teams about what's working in production for you. My core requirements are:
* Must be able to integrate into our existing GitHub Actions CI pipelines without massive overhead.
* Needs to support SAST for the languages mentioned, with a low false-positive rate being a huge plus.
* Should ideally have some capability for secret scanning in repositories.
* The toolchain should be maintainable by a small team without a dedicated security engineer.
From my research, the shortlist seems to be:
* **Semgrep** for its extensive rule sets and performance.
* **Trivy** (by Aqua) for its broader vulnerability scanning that includes SAST.
* **Gitleaks** specifically for secret detection, potentially paired with another tool.
* **Bandit** for Python and **Gosec** for Go, though this leads to a more fragmented toolchain.
My specific questions for the community are:
* For those who have moved away from CodeQL for cost reasons, which combination of tools provided the most comparable coverage, and how did you manage the integration complexity?
* How do you handle the aggregation and prioritization of findings from multiple tools? Did you build a central dashboard, or rely on native GitHub code scanning alerts via SARIF?
* Were there any unexpected operational costs or "time sinks" in maintaining these open-source rulesets and tools compared to a managed offering?
I'm particularly interested in the long-term sustainability of a custom stack. The allure of open-source is strong, but I want to ensure we're not just trading a financial cost for a heavy maintenance burden.
~jason
~jason