La mayoría de los equipos de ingeniería mantienen dos conversaciones distintas sobre el mismo código fuente. Una se centra en la seguridad: ¿existe riesgo de inyección SQL, código Secreto codificado, dependencia vulnerable? La otra se centra en la mantenibilidad: ¿es esta función demasiado compleja, este código está duplicado tres veces, hay código muerto que nadie se atreve a eliminar?
Estas conversaciones suelen tener lugar en diferentes herramientas, gestionadas por diferentes equipos y con diferentes horarios. Un escáner de seguridad señala lo que es explotable. Una herramienta de calidad independiente, a menudo comprada y gestionada por separado, señala lo que es costoso de mantener. Dos licencias, dos dashboards, dos analizadores sintácticos que recorren el mismo árbol de sintaxis abstracta para responder a dos preguntas diferentes.
Esa división tiene un costo. Los defectos de confiabilidad (el tipo que causa fallas en tiempo de ejecución, no brechas) no reciben la misma disciplina de clasificación que los hallazgos de seguridad, porque se encuentran fuera del ámbito del equipo de seguridad. dashboardY cuando un equipo ya cuenta con un motor de análisis estático que analiza cada archivo con fines de seguridad, implementar un segundo motor, independiente del anterior, solo para verificar la calidad del código, es un trabajo redundante sin ningún beneficio compartido.
Por qué importa la calidad del código (y en qué se diferencia de Code Security)
Calidad del código y code security Responda dos preguntas diferentes. Code security La pregunta es: ¿se puede explotar este código? La calidad del código pregunta: ¿se puede mantener este código? Una función puede ser perfectamente segura y aun así ser un enredo de quinientas líneas que nadie quiere tocar, y un módulo bien organizado y fácil de leer puede incluir una vulnerabilidad crítica de inyección. Ninguna disciplina sustituye a la otra.
El coste de ignorar la calidad del código no se manifiesta como una infracción inmediata. Se hace evidente más lentamente: un nuevo empleado tarda dos semanas en lugar de dos días en realizar un cambio seguro, una funcionalidad rutinaria requiere tres sprints porque nadie puede predecir qué problemas podría causar un bloque duplicado en otro lugar, un ingeniero de guardia pierde una hora buscando un error en código obsoleto que debería haberse eliminado hace un año. Nada de esto activa una alerta de seguridad. Todo se refleja en la velocidad de desarrollo, y para cuando se hace visible en una retrospectiva del sprint, ya es costoso solucionarlo.
Ese es el motivo por el que se debe tratar la calidad con el mismo rigor que la seguridad: no porque un código defectuoso sea una amenaza, sino porque dejar que se acumule deuda de mantenimiento sin supervisión es la forma en que una base de código se convierte en el lugar donde mueren las funcionalidades.
La mejor manera: Un motor, dos catálogos de reglas
El escáner de calidad de código de Xygeni analiza el código fuente en busca de defectos de mantenibilidad y fiabilidad: malos olores en el código, violaciones de complejidad, código muerto y duplicación; patrones que no provocan una brecha de seguridad, pero sí interrupciones del servicio, regresiones y ralentización de los equipos.
La elección de diseño distintiva es arquitectónica, no cosmética. Code Quality comparte su motor de análisis estático con xygenis SAST escáner: los mismos analizadores, la misma construcción de AST, el mismo descubrimiento de archivos. Lo que no comparte es el catálogo de reglas. Las reglas de calidad están limitadas a la calidad, no a la seguridad, y los hallazgos se muestran en una sección dedicada a la calidad de la plataforma Xygeni, mantenida separada de SAST y el resto de las tablas de riesgos de seguridad.
El resultado: los equipos obtienen una visión de mantenibilidad y una visión de seguridad a partir del mismo análisis subyacente, sin fusionar dos preocupaciones diferentes en una sola ruidosa. dashboard.
Dos maneras de obtener una señal de calidad en su Pipeline
No todas las características de "calidad del código" funcionan de la misma manera internamente. Muchas CI/CD-Las herramientas de calidad nativas son capas de agregación: ellos no analizan tu código ellos mismos; importan los resultados de cualquier linter que ya estés ejecutando (un linter de JavaScript, un linter de Python, un detector de duplicados), cada uno reformateado en un esquema JSON compartido, cada uno conectado como su propio pipeline paso. Eso es flexible, pero significa que tu señal de calidad solo será tan consistente como la cantidad de herramientas, formatos y mantenedores separados que hayas combinado, uno por lenguaje.
El escáner de calidad de código de Xygeni toma otro camino: un motor nativo, que ya se ejecuta para la seguridad, extendido con un catálogo de reglas de calidad. No hay que instalar un linter por lenguaje, ni reformatear el formato del informe, ni mantener un trabajo separado por herramienta. Obtienes un comando, un modelo de gravedad consistente y un dashboard sección, porque el análisis nunca se dividió entre herramientas desde un principio.
¿Cómo funciona?
La calidad del código se ejecuta como un comando CLI independiente:
calidad de xygeni -d [opciones] (xygeni code-quality funciona como un alias.)
Comparte su modelo de opciones con xygeni sast, por lo que cualquiera que ya esté utilizando el escáner de seguridad de Xygeni reconocerá la interfaz de inmediato:
Generación de un informe de calidad del código
Un escaneo produce un informe de calidad de código que puede enviar a la plataforma, exportar como JSON para artefactos de CI o entregar a un líder de equipo sin dárselo. dashboard acceso. Ambos son comandos de una sola línea:
# Escanea y sube directamente a la plataforma Xygeni
xygeni calidad -n MiProyecto –subir
# Exportar un informe de calidad de código como JSON, solo con hallazgos críticos.
calidad de xygeni -d –detectores críticos –formato json –salida quality.json
Una vez cargado, ese mismo informe de calidad del código es el que rellena la sección de Calidad del dashboard: filtrable, con detalles desplegables por hallazgo, líneas base y el mismo comportamiento de informes que los equipos ya utilizan para SAST.
Ejecutar la calidad junto con un escaneo de seguridad
Para los equipos que desean ambas señales de un solo pase, el SAST El escáner acepta un –incluir-calidad bandera:
xygeni sast -d –incluir-calidad
Gracias SAST y Calidad del código comparten la etapa de análisis sintáctico, lo que resulta más eficiente que ejecutar los dos escáneres consecutivamente. Produce dos informes separados, uno de seguridad y otro de calidad, y cada uno se guarda en su propia carpeta. dashboard Sección. El indicador cambia la forma en que se ejecuta el escaneo, no la forma en que se organizan los resultados.
Escaneo sin conexión
Para entornos aislados o ejecutores de CI sin acceso a la plataforma Xygeni, los análisis de calidad pueden ejecutarse localmente y cargarse posteriormente:
calidad de xygeni -d -n MiProyecto
# …más tarde, desde un host con conectividad:
xygeni report-upload -n MyProject -r depsdoctor-quality.json
Los resultados se incluyen en la sección de Calidad exactamente igual que si se tratara de un análisis en tiempo real: mismo triaje, misma política, mismo comportamiento de referencia.
Por qué es importante separar la calidad de la seguridad
Sería fácil incluir los olores de código en la misma lista de gravedad que una vulnerabilidad explotable. Xygeni deliberadamente no lo hace. Una función duplicada y una inyección SQL no son el mismo tipo de riesgo, y tratarlas de la misma manera entrena a los equipos para reaccionar de forma exagerada al ruido de mantenibilidad o reaccionar de forma insuficiente a los hallazgos de seguridad reales. Mantener los catálogos de reglas, los informes y la dashboard El hecho de que las vistas sean independientes, pero que se comparta el motor subyacente, significa que cada equipo recibe la información que le interesa sin tener que pagar por una segunda herramienta de análisis estático.
Pruébalo: La calidad del código está disponible hoy a través de la CLI de Xygeni. Equipos que ya están ejecutando xygeni sast puede agregar –incluir-calidad a sus existentes pipeline en una línea, sin nueva herramienta para incorporar, sin segunda dashboard verificar.
Preguntas Frecuentes
¿Qué es la calidad del código Xygeni?
Xygeni Code Quality es un escáner de análisis estático que detecta defectos de mantenibilidad y confiabilidad, incluyendo olores de código, violaciones de complejidad, código muerto y duplicación. Se ejecuta como su propio comando (Calidad de xygeni) y los reporta a una sección de Calidad dedicada de la plataforma Xygeni, separada de los hallazgos de seguridad.
¿La calidad del código es lo mismo que...? SAST?
No. Calidad del código y SAST Comparten el mismo motor de análisis subyacente, pero utilizan catálogos de reglas independientes y generan informes independientes. SAST La evaluación de calidad del código busca vulnerabilidades de seguridad; la evaluación de calidad del código busca defectos de mantenibilidad y confiabilidad.
¿Puedo realizar un análisis de calidad y un análisis de seguridad al mismo tiempo?
Sí. Corriendo xygeni sast -d –incluir-calidad ejecuta ambos conjuntos de reglas en una sola pasada, lo que es más eficiente que ejecutar los dos escáneres por separado, ya que comparten la etapa de análisis sintáctico. Los resultados aún generan dos informes separados y aparecen en dos archivos separados. dashboard .
¿Necesito una licencia aparte para Code Quality?
Para cargar y visualizar resultados de calidad, se requiere el permiso de Calidad de código, el mismo que se necesita para ejecutar el análisis.
¿Puede funcionar Code Quality sin acceso a internet?
Sí. Los escaneos pueden ejecutarse localmente sin el -subir bandera, y el informe resultante se puede cargar más tarde desde un host conectado usando Carga de informe de xygeni.
