Qodana 检查你的代码。谁来检查你的 DevOps 和平台工程栈？
内容提要
Qodana目前仅检查应用代码，但DevOps和平台工程栈缺乏统一质量检查。团队使用多个独立CLI工具（如Kube-score、Checkov等）分析基础设施，各有配置和集成，无共享质量门禁或IDE反馈，导致基础设施代码审查不足。文章提议将Qodana扩展至DevOps工件，提供统一界面、配置和跨域分析，建立基础设施代码的共享质量标准，并征求社区反馈。
延伸解读
现状：基础设施代码缺乏统一质量门禁
文章指出，DevOps和平台工程团队通常使用多个独立的CLI工具（如Kube-score、Checkov、Hadolint等）来检查基础设施代码。这些工具各有配置语法、严重性模型和CI集成方式，导致没有共享的质量门禁，也没有IDE反馈循环。结果，基础设施代码在合并时受到的审查远少于应用代码，安全配置错误和可靠性问题可能悄然进入生产环境。
提议：将Qodana扩展到DevOps工件
作者设想将Qodana扩展至DevOps工件，以统一界面和配置模型覆盖五个关键领域。通过qodana.yaml，社区可以构建适配器接入Pulumi、CDK或GitLab CI等工具。这样，团队可以在同一用户界面中查看基础设施代码的发现，使用相同的报告结构和严重性模型，并建立跨域分析能力，例如同时评估Terraform模块和其引用的Helm chart。
深层价值：建立共享质量标准
文章强调，更深层的价值不在于捕捉个别错误配置，而在于为基础设施代码建立共享质量标准，就像Qodana为应用代码所做的那样。这意味着开发者体验一致（IDE反馈、CI执行、质量门禁），配置模型统一（一个qodana.yaml覆盖应用和DevOps工件），并支持跨域分析。这有助于将安全左移扩展到整个技术栈，而不仅仅是应用层。
Q&A
Qodana 目前主要检查什么？
Qodana 目前主要检查应用代码，能够捕获未使用的变量、安全漏洞、代码风格违规和架构问题，并在代码进入生产环境前提供质量门禁和 IDE 内联反馈。
DevOps 和平台工程团队目前如何检查基础设施代码？
他们通常依赖一系列独立的 CLI 工具，例如 Kube-score 用于 Kubernetes 清单分析，Checkov 用于 Terraform 和 CloudFormation，Hadolint 用于 Dockerfile 检查，Ansible-lint 用于 Ansible 剧本，Tfsec/Tflint 用于 Terraform 安全，Trivy 用于容器镜像和 IaC 扫描，Conftest 用于策略即代码，Yamllint 用于 YAML 验证，Actionlint 用于 GitHub Actions 工作流检查。
当前 DevOps 工具链存在哪些问题？
每个工具都有自己的配置语法、严重性模型、CI 集成和维护方式，缺乏统一的质量门禁和 IDE 反馈循环，也无法进行跨域分析，导致基础设施代码在合并时受到的审查远少于应用代码，安全配置错误和可靠性问题可能悄悄进入生产环境。
Qodana 扩展到 DevOps 工件后，会带来哪些改进？
Qodana 扩展到 DevOps 工件后，将提供统一的界面、配置和跨域分析，使团队能够使用与应用程序代码相同的报告结构、严重性模型和质量门禁来检查基础设施代码，并支持社区构建的适配器（如 Pulumi、CDK、GitLab CI）通过 qodana.yaml 直接集成。
Qodana DevOps Linter 的深层价值是什么？
深层价值在于为基础设施代码建立共享的质量标准，就像 Qodana 为应用代码所做的那样，包括相同的开发者体验（IDE 反馈、CI 强制、质量门禁）、相同的配置模型（一个 qodana.yaml 覆盖应用和 DevOps 工件）、跨域分析（规则可跨越 Terraform 模块和其支持的 Helm chart），以及整个技术栈的左移策略。
文章作者希望社区提供什么反馈？
作者希望了解其他从业者是否也认识到同样的差距，以及这个想法是否匹配他们团队的痛点，并询问他们希望首先分析哪个领域或工具，邀请他们联系讨论。
