¿Qué es el análisis estático?
¿Qué es el análisis estático?
El análisis estático es el análisis automatizado del código fuente sin ejecutar la aplicación.
Cuando el análisis se realiza durante la ejecución del programa, se conoce como análisis dinámico.
El análisis estático se utiliza a menudo para detectar:
- Vulnerabilidades de seguridad.
- Problemas de rendimiento.
- Incumplimiento de las normas.
- Uso de construcciones de programación desactualizadas.
¿Cómo funciona una herramienta de análisis estático?
El concepto básico común a todas las herramientas de análisis estático es buscar en el código fuente para identificar patrones de codificación específicos que tienen algún tipo de advertencia o información asociada a ellos.
Esto podría ser tan simple como «las clases de prueba de JUnit 5 no necesitan ser 'públicas'». O algo complejo de identificar, como «Se utiliza una entrada de cadena no confiable en una sentencia de ejecución de SQL».
Las herramientas de análisis estático varían en la forma en que implementan esta funcionalidad.
- tecnología de análisis de código fuente para crear un árbol de sintaxis abstracta (AST),
- coincidencia de expresiones regulares de texto,
- una combinación de las anteriores.
La coincidencia de expresiones regulares en el texto es muy flexible, es fácil escribir reglas para hacer coincidir, pero a menudo puede generar muchos falsos positivos y las reglas de coincidencia ignoran el contexto del código circundante.
La coincidencia AST trata el código fuente como código de programa, y no solo como archivos llenos de texto, esto permite una coincidencia contextual más específica y puede reducir la cantidad de falsos positivos reportados en relación con el código.
Análisis estático en integración continua
El análisis estático a menudo se realiza durante el proceso de integración continua (CI) para generar un informe de problemas de cumplimiento que se puede revisar para obtener una visión objetiva del código base a lo largo del tiempo.
Algunas personas usan el análisis estático como una medida objetiva de la calidad de su código al configurar la herramienta de análisis estático para medir solo partes específicas del código y solo informar sobre un subconjunto de reglas.
La objetividad la proporcionan las reglas utilizadas, ya que no varían en su evaluación del código a lo largo del tiempo. Es evidente que la combinación de las reglas utilizadas y su configuración es una decisión subjetiva y los diferentes equipos eligen usar reglas diferentes en momentos diferentes.
Realizar el análisis estático en CI es útil, pero puede retrasar la retroalimentación al programador. Los programadores no reciben comentarios cuando codifican, sino que los reciben más adelante, cuando el código se ejecuta a través de la herramienta de análisis estático. Otro efecto secundario de ejecutar el análisis estático en CI es que es más fácil ignorar los resultados.
Para ayudar a los equipos a prestar más atención a los resultados del análisis estático, normalmente es posible configurar una métrica de umbral en el proceso de creación para que la compilación falle si se supera la métrica, por ejemplo, si se activan varias reglas.
Análisis estático en el IDE
Para recibir comentarios más rápido, hay muchos complementos del IDE que ejecutan las reglas de análisis estático en el IDE a pedido o de forma periódica a medida que cambia el código.
Las violaciones de las reglas se pueden ver entonces en el IDE mientras el programador escribe código y, para que sea más difícil ignorarlas, las violaciones a menudo se pueden configurar para que se muestren como código subrayado en el editor.
Personalmente, creo que esta es una forma útil de mejorar mi codificación, especialmente cuando trabajo con una nueva biblioteca que está cubierta por la herramienta de análisis estático. Aunque puede ser «ruidoso» con falsos positivos o reglas que no te interesen. Pero esto se resuelve dando un paso adicional para configurar la herramienta de análisis estático para que ignore ciertas reglas.
Corregir código basado en reglas de análisis estático
Con la mayoría de las herramientas de análisis estático, la corrección de la regla queda en manos del programador, por lo que debe entender la causa de la infracción de la regla y cómo solucionarla.
Muy pocas herramientas de análisis estático también incluyen la capacidad de corregir las infracciones, ya que la solución suele depender del equipo, la tecnología utilizada y los estilos de codificación acordados.
Reglas predeterminadas
La falsa confianza en la calidad de las reglas puede surgir cuando las herramientas de análisis estático vienen con reglas predeterminadas. Es tentador creer que cubren todos los problemas que un programador puede encontrar y todas las circunstancias en las que debería aplicarse esa regla. En ocasiones, las circunstancias en las que debe aplicarse una regla pueden ser sutiles y pueden no ser fáciles de detectar.
La esperanza es que, al utilizar una herramienta de análisis estático e investigar las reglas y las infracciones con más detalle, los programadores desarrollen la habilidad necesaria para detectar y evitar el problema en el contexto de su dominio específico.
Cuando el dominio requiere reglas contextuales, es posible que las herramientas de análisis estático no tengan reglas que coincidan con su dominio o biblioteca y, además, las herramientas suelen ser difíciles de configurar y expandir.
Molestias
Ninguna de estas «molestias» es insuperable:
- falsos positivos
- falta de correcciones
- configuración para ignorar las reglas
- agregar reglas específicas del contexto
Pero a menudo se usan como excusas para evitar el uso de herramientas de análisis estático en primer lugar, lo cual es una pena porque el uso del análisis estático puede ser enormemente útil, como una forma de:
- destacar mejores enfoques para los desarrolladores junior
- obtenga comentarios rápidos sobre infracciones claras de codificación
- identificar problemas poco conocidos que el programador no haya encontrado antes
- reforzar que el programador ha adoptado un buen enfoque de codificación (cuando no se denuncie ninguna infracción)
Herramientas de análisis estático basadas en IDE
Como colaborador individual de un proyecto, me gusta usar herramientas de análisis estático que se ejecutan desde el IDE para recibir comentarios rápidos sobre mi código.
Esto complementa cualquier solicitud de incorporación de cambios, proceso de revisión e integración de CI que pueda tener un proyecto.
Intento identificar herramientas que me den una ventaja y mejoren mi flujo de trabajo individual.
Cuando las herramientas se ejecutan en el IDE, dado que tienden a compartir la misma GUI básica y el mismo enfoque de configuración, puede resultar tentador verlas indistintamente.
Las herramientas pueden tener funciones o conjuntos de reglas superpuestos, pero para obtener el máximo beneficio instalo varias herramientas para aprovechar sus puntos fuertes.
Las herramientas IDE de análisis estático que uso activamente al codificar se enumeran a continuación:
- las inspecciones IntelliJ incorporadas: patrones de codificación comunes
- SpotBugs: errores comunes
- SonarLint: patrones de uso comunes
- checkStyle: patrones de estilo comunes
- Sensei de Secure Code Warrior: creación de reglas personalizadas
Los uso todos porque funcionan bien juntos para aumentarse y complementarse entre sí.
Inspecciones de IntelliJ
Si usa IntelliJ, entonces ya está usando sus inspecciones.
Estas son reglas de análisis estático que están marcadas en el IDE. Algunas de ellas también tienen opciones QuickFix para reescribir el código y solucionar el problema.
Las reglas se pueden configurar de forma activada y desactivada, y para elegir el nivel de error utilizado para resaltarlo en el IDE.
Hay muchas buenas inspecciones de IntelliJ. Lo sé porque las leí mientras escribía esto. Utilizo las inspecciones de IntelliJ por defecto y no las he configurado, pero para sacar todo el provecho de las inspecciones, deberías leerlas, identificar las que sean relevantes para tu estilo de codificación y configurar el nivel de advertencia para que las veas en el código.
Lo mejor de las inspecciones de IntelliJ es que vienen gratis con el IDE y ayudan a desarrollar la memoria muscular de:
- observar las advertencias y los errores en la fuente mientras escribes el código
- pasar el ratón sobre el código marcado para conocer las infracciones de las reglas
- usar alt+enter para aplicar una solución rápida al problema
Detecta errores
El Detecta errores El complemento IntelliJ usa el análisis estático para intentar alertarlo sobre errores en su código.
SpotBugs se puede configurar desde las Preferencias de IntelliJ para escanear su código; las reglas reales utilizadas se encuentran en la pestaña Detector.
Suelo usar SpotBugs después de escribir y revisar mi código, y luego ejecuto el «Analizar los archivos del proyecto, incluidas las fuentes de prueba».
Esto me ayuda a identificar errores, código muerto y optimizaciones obvias. También me obliga a investigar algunas de las infracciones señaladas para poder decidir qué hacer.
SpotBugs encontrará problemas, pero no ofrece ninguna acción de corrección rápida para intentar resolverlos.
SpotBugs es fácil de configurar y me parece una segunda opinión objetiva útil para consultar en mi IDE.
Sónar Lint
El Sónar Lint complemento.
SonarLint se puede configurar desde las Preferencias de IntelliJ para seleccionar las reglas con las que se valida el código.
De forma predeterminada, SonarLint se ejecuta en tiempo real y muestra los problemas del código actual que está editando.
SonarLint no ofrece soluciones rápidas, pero la documentación asociada a los informes de infracción suele ser clara y está bien documentada.
En el pasado, SonarLint me resultó útil para alertarme sobre las nuevas funciones de Java que conocía en las versiones más recientes de Java.
Estilo de verificación
El Estilo de verificación El plugin ofrece una combinación de reglas de formato y calidad de código.
El plugin CheckStyle viene incluido con «Sun Check» y «Google Check».
Las definiciones de estos pueden ser fácilmente encontrado en línea.
CheckStyle agrega el mayor valor cuando un proyecto ha dedicado tiempo a crear su propio conjunto de reglas. Luego, el complemento IDE se puede configurar para usar ese conjunto de reglas y los programadores pueden realizar un escaneo antes de enviar el código a CI.
CheckStyle se usa con mucha frecuencia como un complemento que falla en la compilación para procesos de CI cuando el número de infracciones de CheckStyle supera un umbral.
Sensei
Sensei utiliza un análisis estático basado en un árbol de sintaxis abstracta (AST) para hacer coincidir el código y crear soluciones rápidas, lo que permite una identificación muy específica del código con problemas.
El AST permite que los QuickFixes asociados a una receta comprendan el código circundante, por ejemplo, al agregar una nueva clase al código, cualquier importación de esa clase solo se agregará al archivo fuente una vez, y no para cada reemplazo.
Sensei se creó para facilitar la creación de reglas de coincidencia personalizadas que pueden no existir o que serían difíciles de configurar en otras herramientas.
En lugar de modificar un archivo de configuración, toda la configuración se puede realizar en la GUI. Al crear nuevas recetas, la GUI facilita ver con qué código coincide la receta. Además, al definir los QuickFixes, el estado anterior y posterior del código se puede comparar inmediatamente. Esto facilita la creación de recetas muy contextuales, es decir, exclusivas para equipos o tecnologías, e incluso para programadores individuales.
Utilizo Sensei en combinación con otras herramientas de análisis estático, por ejemplo, la mayoría de las herramientas de análisis estático encuentran problemas, pero no los solucionan. Un caso de uso habitual de Sensei es replicar la búsqueda coincidente de la otra herramienta en Sensei y ampliarla con una solución rápida. Esto tiene la ventaja de que la corrección personalizada aplicada ya cumple con los estándares de codificación de tu proyecto.
Periódicamente me encuentro creando recetas de Sensei que ya existen en el conjunto de intenciones de IntelliJ porque el informe de intenciones no coincide del todo con el contexto que he creado o porque el QuickFix proporcionado por IntelliJ no coincide con el patrón de código que quiero usar.
Amplio las herramientas existentes, en lugar de intentar reemplazarlas por completo.
Sensei también puede resultar muy útil a la hora de identificar una variante contextual de una regla común, por ejemplo, si está utilizando una biblioteca SQL que no es compatible con la herramienta de análisis estático, pero las reglas SQL comunes del motor de análisis estático aún se aplican, puede crear variantes de esas reglas específicas para la biblioteca con Sensei.
Sensei no viene de fábrica con muchas recetas genéricas, como las herramientas de análisis estático mencionadas, sino que su punto fuerte radica en facilitar la creación de nuevas recetas, con correcciones rápidas configuradas para que coincidan con su estilo de codificación y casos de uso específicos.
NOTA: estamos trabajando en un repositorio público de recetas para cubrir los casos de uso genéricos, y lo puedes encontrar aquí.
Resumen
Suelo elegir herramientas que funcionen juntas, que sean configurables y fáciles de expandir para cumplir con mi contexto específico. He usado las herramientas de análisis estático en el IDE durante años para ayudarme a identificar problemas y obtener más información sobre los lenguajes de programación y las bibliotecas que uso.
Utilizo todas las herramientas mencionadas en combinación:
- IntelliJ Intentions ayuda a marcar problemas de código comunes de forma inmediata, a menudo con soluciones rápidas asociadas.
- SpotBugs encuentra errores sencillos que podría haber pasado por alto y me alerta sobre problemas de rendimiento.
- SonarLint identifica las funciones de Java que desconocía y me indica formas adicionales de modelar mi código.
- CheckStyle me ayuda a ajustarme a un estilo de codificación acordado que también se aplica durante la CI.
- Sensei me ayuda a crear soluciones rápidas para aumentar los escenarios comunes que encuentran las herramientas de análisis estático y crear recetas tecnológicas o de proyectos específicos que pueden resultar difíciles de configurar en otra herramienta.
---
Instale Sensei desde IntelliJ mediante «Preferencias\ Plugins» (Mac) o «Configuración\ Plugins» (Windows) y, a continuación, busque «código seguro de sensei».
Puedes encontrar un repositorio de códigos de ejemplo y recetas para casos de uso comunes en la cuenta de GitHub de Secure Code Warrior, en el proyecto `sensei-blog-examples`.
https://github.com/securecodewarrior/sensei-blog-examples
Obtenga información sobre el análisis estático y cómo puede ayudarlo a escribir mejor código con ejemplos de 5 enfoques y complementos basados en IDE.
Alan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostración
Alan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.
¿Qué es el análisis estático?
El análisis estático es el análisis automatizado del código fuente sin ejecutar la aplicación.
Cuando el análisis se realiza durante la ejecución del programa, se conoce como análisis dinámico.
El análisis estático se utiliza a menudo para detectar:
- Vulnerabilidades de seguridad.
- Problemas de rendimiento.
- Incumplimiento de las normas.
- Uso de construcciones de programación desactualizadas.
¿Cómo funciona una herramienta de análisis estático?
El concepto básico común a todas las herramientas de análisis estático es buscar en el código fuente para identificar patrones de codificación específicos que tienen algún tipo de advertencia o información asociada a ellos.
Esto podría ser tan simple como «las clases de prueba de JUnit 5 no necesitan ser 'públicas'». O algo complejo de identificar, como «Se utiliza una entrada de cadena no confiable en una sentencia de ejecución de SQL».
Las herramientas de análisis estático varían en la forma en que implementan esta funcionalidad.
- tecnología de análisis de código fuente para crear un árbol de sintaxis abstracta (AST),
- coincidencia de expresiones regulares de texto,
- una combinación de las anteriores.
La coincidencia de expresiones regulares en el texto es muy flexible, es fácil escribir reglas para hacer coincidir, pero a menudo puede generar muchos falsos positivos y las reglas de coincidencia ignoran el contexto del código circundante.
La coincidencia AST trata el código fuente como código de programa, y no solo como archivos llenos de texto, esto permite una coincidencia contextual más específica y puede reducir la cantidad de falsos positivos reportados en relación con el código.
Análisis estático en integración continua
El análisis estático a menudo se realiza durante el proceso de integración continua (CI) para generar un informe de problemas de cumplimiento que se puede revisar para obtener una visión objetiva del código base a lo largo del tiempo.
Algunas personas usan el análisis estático como una medida objetiva de la calidad de su código al configurar la herramienta de análisis estático para medir solo partes específicas del código y solo informar sobre un subconjunto de reglas.
La objetividad la proporcionan las reglas utilizadas, ya que no varían en su evaluación del código a lo largo del tiempo. Es evidente que la combinación de las reglas utilizadas y su configuración es una decisión subjetiva y los diferentes equipos eligen usar reglas diferentes en momentos diferentes.
Realizar el análisis estático en CI es útil, pero puede retrasar la retroalimentación al programador. Los programadores no reciben comentarios cuando codifican, sino que los reciben más adelante, cuando el código se ejecuta a través de la herramienta de análisis estático. Otro efecto secundario de ejecutar el análisis estático en CI es que es más fácil ignorar los resultados.
Para ayudar a los equipos a prestar más atención a los resultados del análisis estático, normalmente es posible configurar una métrica de umbral en el proceso de creación para que la compilación falle si se supera la métrica, por ejemplo, si se activan varias reglas.
Análisis estático en el IDE
Para recibir comentarios más rápido, hay muchos complementos del IDE que ejecutan las reglas de análisis estático en el IDE a pedido o de forma periódica a medida que cambia el código.
Las violaciones de las reglas se pueden ver entonces en el IDE mientras el programador escribe código y, para que sea más difícil ignorarlas, las violaciones a menudo se pueden configurar para que se muestren como código subrayado en el editor.
Personalmente, creo que esta es una forma útil de mejorar mi codificación, especialmente cuando trabajo con una nueva biblioteca que está cubierta por la herramienta de análisis estático. Aunque puede ser «ruidoso» con falsos positivos o reglas que no te interesen. Pero esto se resuelve dando un paso adicional para configurar la herramienta de análisis estático para que ignore ciertas reglas.
Corregir código basado en reglas de análisis estático
Con la mayoría de las herramientas de análisis estático, la corrección de la regla queda en manos del programador, por lo que debe entender la causa de la infracción de la regla y cómo solucionarla.
Muy pocas herramientas de análisis estático también incluyen la capacidad de corregir las infracciones, ya que la solución suele depender del equipo, la tecnología utilizada y los estilos de codificación acordados.
Reglas predeterminadas
La falsa confianza en la calidad de las reglas puede surgir cuando las herramientas de análisis estático vienen con reglas predeterminadas. Es tentador creer que cubren todos los problemas que un programador puede encontrar y todas las circunstancias en las que debería aplicarse esa regla. En ocasiones, las circunstancias en las que debe aplicarse una regla pueden ser sutiles y pueden no ser fáciles de detectar.
La esperanza es que, al utilizar una herramienta de análisis estático e investigar las reglas y las infracciones con más detalle, los programadores desarrollen la habilidad necesaria para detectar y evitar el problema en el contexto de su dominio específico.
Cuando el dominio requiere reglas contextuales, es posible que las herramientas de análisis estático no tengan reglas que coincidan con su dominio o biblioteca y, además, las herramientas suelen ser difíciles de configurar y expandir.
Molestias
Ninguna de estas «molestias» es insuperable:
- falsos positivos
- falta de correcciones
- configuración para ignorar las reglas
- agregar reglas específicas del contexto
Pero a menudo se usan como excusas para evitar el uso de herramientas de análisis estático en primer lugar, lo cual es una pena porque el uso del análisis estático puede ser enormemente útil, como una forma de:
- destacar mejores enfoques para los desarrolladores junior
- obtenga comentarios rápidos sobre infracciones claras de codificación
- identificar problemas poco conocidos que el programador no haya encontrado antes
- reforzar que el programador ha adoptado un buen enfoque de codificación (cuando no se denuncie ninguna infracción)
Herramientas de análisis estático basadas en IDE
Como colaborador individual de un proyecto, me gusta usar herramientas de análisis estático que se ejecutan desde el IDE para recibir comentarios rápidos sobre mi código.
Esto complementa cualquier solicitud de incorporación de cambios, proceso de revisión e integración de CI que pueda tener un proyecto.
Intento identificar herramientas que me den una ventaja y mejoren mi flujo de trabajo individual.
Cuando las herramientas se ejecutan en el IDE, dado que tienden a compartir la misma GUI básica y el mismo enfoque de configuración, puede resultar tentador verlas indistintamente.
Las herramientas pueden tener funciones o conjuntos de reglas superpuestos, pero para obtener el máximo beneficio instalo varias herramientas para aprovechar sus puntos fuertes.
Las herramientas IDE de análisis estático que uso activamente al codificar se enumeran a continuación:
- las inspecciones IntelliJ incorporadas: patrones de codificación comunes
- SpotBugs: errores comunes
- SonarLint: patrones de uso comunes
- checkStyle: patrones de estilo comunes
- Sensei de Secure Code Warrior: creación de reglas personalizadas
Los uso todos porque funcionan bien juntos para aumentarse y complementarse entre sí.
Inspecciones de IntelliJ
Si usa IntelliJ, entonces ya está usando sus inspecciones.
Estas son reglas de análisis estático que están marcadas en el IDE. Algunas de ellas también tienen opciones QuickFix para reescribir el código y solucionar el problema.
Las reglas se pueden configurar de forma activada y desactivada, y para elegir el nivel de error utilizado para resaltarlo en el IDE.
Hay muchas buenas inspecciones de IntelliJ. Lo sé porque las leí mientras escribía esto. Utilizo las inspecciones de IntelliJ por defecto y no las he configurado, pero para sacar todo el provecho de las inspecciones, deberías leerlas, identificar las que sean relevantes para tu estilo de codificación y configurar el nivel de advertencia para que las veas en el código.
Lo mejor de las inspecciones de IntelliJ es que vienen gratis con el IDE y ayudan a desarrollar la memoria muscular de:
- observar las advertencias y los errores en la fuente mientras escribes el código
- pasar el ratón sobre el código marcado para conocer las infracciones de las reglas
- usar alt+enter para aplicar una solución rápida al problema
Detecta errores
El Detecta errores El complemento IntelliJ usa el análisis estático para intentar alertarlo sobre errores en su código.
SpotBugs se puede configurar desde las Preferencias de IntelliJ para escanear su código; las reglas reales utilizadas se encuentran en la pestaña Detector.
Suelo usar SpotBugs después de escribir y revisar mi código, y luego ejecuto el «Analizar los archivos del proyecto, incluidas las fuentes de prueba».
Esto me ayuda a identificar errores, código muerto y optimizaciones obvias. También me obliga a investigar algunas de las infracciones señaladas para poder decidir qué hacer.
SpotBugs encontrará problemas, pero no ofrece ninguna acción de corrección rápida para intentar resolverlos.
SpotBugs es fácil de configurar y me parece una segunda opinión objetiva útil para consultar en mi IDE.
Sónar Lint
El Sónar Lint complemento.
SonarLint se puede configurar desde las Preferencias de IntelliJ para seleccionar las reglas con las que se valida el código.
De forma predeterminada, SonarLint se ejecuta en tiempo real y muestra los problemas del código actual que está editando.
SonarLint no ofrece soluciones rápidas, pero la documentación asociada a los informes de infracción suele ser clara y está bien documentada.
En el pasado, SonarLint me resultó útil para alertarme sobre las nuevas funciones de Java que conocía en las versiones más recientes de Java.
Estilo de verificación
El Estilo de verificación El plugin ofrece una combinación de reglas de formato y calidad de código.
El plugin CheckStyle viene incluido con «Sun Check» y «Google Check».
Las definiciones de estos pueden ser fácilmente encontrado en línea.
CheckStyle agrega el mayor valor cuando un proyecto ha dedicado tiempo a crear su propio conjunto de reglas. Luego, el complemento IDE se puede configurar para usar ese conjunto de reglas y los programadores pueden realizar un escaneo antes de enviar el código a CI.
CheckStyle se usa con mucha frecuencia como un complemento que falla en la compilación para procesos de CI cuando el número de infracciones de CheckStyle supera un umbral.
Sensei
Sensei utiliza un análisis estático basado en un árbol de sintaxis abstracta (AST) para hacer coincidir el código y crear soluciones rápidas, lo que permite una identificación muy específica del código con problemas.
El AST permite que los QuickFixes asociados a una receta comprendan el código circundante, por ejemplo, al agregar una nueva clase al código, cualquier importación de esa clase solo se agregará al archivo fuente una vez, y no para cada reemplazo.
Sensei se creó para facilitar la creación de reglas de coincidencia personalizadas que pueden no existir o que serían difíciles de configurar en otras herramientas.
En lugar de modificar un archivo de configuración, toda la configuración se puede realizar en la GUI. Al crear nuevas recetas, la GUI facilita ver con qué código coincide la receta. Además, al definir los QuickFixes, el estado anterior y posterior del código se puede comparar inmediatamente. Esto facilita la creación de recetas muy contextuales, es decir, exclusivas para equipos o tecnologías, e incluso para programadores individuales.
Utilizo Sensei en combinación con otras herramientas de análisis estático, por ejemplo, la mayoría de las herramientas de análisis estático encuentran problemas, pero no los solucionan. Un caso de uso habitual de Sensei es replicar la búsqueda coincidente de la otra herramienta en Sensei y ampliarla con una solución rápida. Esto tiene la ventaja de que la corrección personalizada aplicada ya cumple con los estándares de codificación de tu proyecto.
Periódicamente me encuentro creando recetas de Sensei que ya existen en el conjunto de intenciones de IntelliJ porque el informe de intenciones no coincide del todo con el contexto que he creado o porque el QuickFix proporcionado por IntelliJ no coincide con el patrón de código que quiero usar.
Amplio las herramientas existentes, en lugar de intentar reemplazarlas por completo.
Sensei también puede resultar muy útil a la hora de identificar una variante contextual de una regla común, por ejemplo, si está utilizando una biblioteca SQL que no es compatible con la herramienta de análisis estático, pero las reglas SQL comunes del motor de análisis estático aún se aplican, puede crear variantes de esas reglas específicas para la biblioteca con Sensei.
Sensei no viene de fábrica con muchas recetas genéricas, como las herramientas de análisis estático mencionadas, sino que su punto fuerte radica en facilitar la creación de nuevas recetas, con correcciones rápidas configuradas para que coincidan con su estilo de codificación y casos de uso específicos.
NOTA: estamos trabajando en un repositorio público de recetas para cubrir los casos de uso genéricos, y lo puedes encontrar aquí.
Resumen
Suelo elegir herramientas que funcionen juntas, que sean configurables y fáciles de expandir para cumplir con mi contexto específico. He usado las herramientas de análisis estático en el IDE durante años para ayudarme a identificar problemas y obtener más información sobre los lenguajes de programación y las bibliotecas que uso.
Utilizo todas las herramientas mencionadas en combinación:
- IntelliJ Intentions ayuda a marcar problemas de código comunes de forma inmediata, a menudo con soluciones rápidas asociadas.
- SpotBugs encuentra errores sencillos que podría haber pasado por alto y me alerta sobre problemas de rendimiento.
- SonarLint identifica las funciones de Java que desconocía y me indica formas adicionales de modelar mi código.
- CheckStyle me ayuda a ajustarme a un estilo de codificación acordado que también se aplica durante la CI.
- Sensei me ayuda a crear soluciones rápidas para aumentar los escenarios comunes que encuentran las herramientas de análisis estático y crear recetas tecnológicas o de proyectos específicos que pueden resultar difíciles de configurar en otra herramienta.
---
Instale Sensei desde IntelliJ mediante «Preferencias\ Plugins» (Mac) o «Configuración\ Plugins» (Windows) y, a continuación, busque «código seguro de sensei».
Puedes encontrar un repositorio de códigos de ejemplo y recetas para casos de uso comunes en la cuenta de GitHub de Secure Code Warrior, en el proyecto `sensei-blog-examples`.
https://github.com/securecodewarrior/sensei-blog-examples
¿Qué es el análisis estático?
El análisis estático es el análisis automatizado del código fuente sin ejecutar la aplicación.
Cuando el análisis se realiza durante la ejecución del programa, se conoce como análisis dinámico.
El análisis estático se utiliza a menudo para detectar:
- Vulnerabilidades de seguridad.
- Problemas de rendimiento.
- Incumplimiento de las normas.
- Uso de construcciones de programación desactualizadas.
¿Cómo funciona una herramienta de análisis estático?
El concepto básico común a todas las herramientas de análisis estático es buscar en el código fuente para identificar patrones de codificación específicos que tienen algún tipo de advertencia o información asociada a ellos.
Esto podría ser tan simple como «las clases de prueba de JUnit 5 no necesitan ser 'públicas'». O algo complejo de identificar, como «Se utiliza una entrada de cadena no confiable en una sentencia de ejecución de SQL».
Las herramientas de análisis estático varían en la forma en que implementan esta funcionalidad.
- tecnología de análisis de código fuente para crear un árbol de sintaxis abstracta (AST),
- coincidencia de expresiones regulares de texto,
- una combinación de las anteriores.
La coincidencia de expresiones regulares en el texto es muy flexible, es fácil escribir reglas para hacer coincidir, pero a menudo puede generar muchos falsos positivos y las reglas de coincidencia ignoran el contexto del código circundante.
La coincidencia AST trata el código fuente como código de programa, y no solo como archivos llenos de texto, esto permite una coincidencia contextual más específica y puede reducir la cantidad de falsos positivos reportados en relación con el código.
Análisis estático en integración continua
El análisis estático a menudo se realiza durante el proceso de integración continua (CI) para generar un informe de problemas de cumplimiento que se puede revisar para obtener una visión objetiva del código base a lo largo del tiempo.
Algunas personas usan el análisis estático como una medida objetiva de la calidad de su código al configurar la herramienta de análisis estático para medir solo partes específicas del código y solo informar sobre un subconjunto de reglas.
La objetividad la proporcionan las reglas utilizadas, ya que no varían en su evaluación del código a lo largo del tiempo. Es evidente que la combinación de las reglas utilizadas y su configuración es una decisión subjetiva y los diferentes equipos eligen usar reglas diferentes en momentos diferentes.
Realizar el análisis estático en CI es útil, pero puede retrasar la retroalimentación al programador. Los programadores no reciben comentarios cuando codifican, sino que los reciben más adelante, cuando el código se ejecuta a través de la herramienta de análisis estático. Otro efecto secundario de ejecutar el análisis estático en CI es que es más fácil ignorar los resultados.
Para ayudar a los equipos a prestar más atención a los resultados del análisis estático, normalmente es posible configurar una métrica de umbral en el proceso de creación para que la compilación falle si se supera la métrica, por ejemplo, si se activan varias reglas.
Análisis estático en el IDE
Para recibir comentarios más rápido, hay muchos complementos del IDE que ejecutan las reglas de análisis estático en el IDE a pedido o de forma periódica a medida que cambia el código.
Las violaciones de las reglas se pueden ver entonces en el IDE mientras el programador escribe código y, para que sea más difícil ignorarlas, las violaciones a menudo se pueden configurar para que se muestren como código subrayado en el editor.
Personalmente, creo que esta es una forma útil de mejorar mi codificación, especialmente cuando trabajo con una nueva biblioteca que está cubierta por la herramienta de análisis estático. Aunque puede ser «ruidoso» con falsos positivos o reglas que no te interesen. Pero esto se resuelve dando un paso adicional para configurar la herramienta de análisis estático para que ignore ciertas reglas.
Corregir código basado en reglas de análisis estático
Con la mayoría de las herramientas de análisis estático, la corrección de la regla queda en manos del programador, por lo que debe entender la causa de la infracción de la regla y cómo solucionarla.
Muy pocas herramientas de análisis estático también incluyen la capacidad de corregir las infracciones, ya que la solución suele depender del equipo, la tecnología utilizada y los estilos de codificación acordados.
Reglas predeterminadas
La falsa confianza en la calidad de las reglas puede surgir cuando las herramientas de análisis estático vienen con reglas predeterminadas. Es tentador creer que cubren todos los problemas que un programador puede encontrar y todas las circunstancias en las que debería aplicarse esa regla. En ocasiones, las circunstancias en las que debe aplicarse una regla pueden ser sutiles y pueden no ser fáciles de detectar.
La esperanza es que, al utilizar una herramienta de análisis estático e investigar las reglas y las infracciones con más detalle, los programadores desarrollen la habilidad necesaria para detectar y evitar el problema en el contexto de su dominio específico.
Cuando el dominio requiere reglas contextuales, es posible que las herramientas de análisis estático no tengan reglas que coincidan con su dominio o biblioteca y, además, las herramientas suelen ser difíciles de configurar y expandir.
Molestias
Ninguna de estas «molestias» es insuperable:
- falsos positivos
- falta de correcciones
- configuración para ignorar las reglas
- agregar reglas específicas del contexto
Pero a menudo se usan como excusas para evitar el uso de herramientas de análisis estático en primer lugar, lo cual es una pena porque el uso del análisis estático puede ser enormemente útil, como una forma de:
- destacar mejores enfoques para los desarrolladores junior
- obtenga comentarios rápidos sobre infracciones claras de codificación
- identificar problemas poco conocidos que el programador no haya encontrado antes
- reforzar que el programador ha adoptado un buen enfoque de codificación (cuando no se denuncie ninguna infracción)
Herramientas de análisis estático basadas en IDE
Como colaborador individual de un proyecto, me gusta usar herramientas de análisis estático que se ejecutan desde el IDE para recibir comentarios rápidos sobre mi código.
Esto complementa cualquier solicitud de incorporación de cambios, proceso de revisión e integración de CI que pueda tener un proyecto.
Intento identificar herramientas que me den una ventaja y mejoren mi flujo de trabajo individual.
Cuando las herramientas se ejecutan en el IDE, dado que tienden a compartir la misma GUI básica y el mismo enfoque de configuración, puede resultar tentador verlas indistintamente.
Las herramientas pueden tener funciones o conjuntos de reglas superpuestos, pero para obtener el máximo beneficio instalo varias herramientas para aprovechar sus puntos fuertes.
Las herramientas IDE de análisis estático que uso activamente al codificar se enumeran a continuación:
- las inspecciones IntelliJ incorporadas: patrones de codificación comunes
- SpotBugs: errores comunes
- SonarLint: patrones de uso comunes
- checkStyle: patrones de estilo comunes
- Sensei de Secure Code Warrior: creación de reglas personalizadas
Los uso todos porque funcionan bien juntos para aumentarse y complementarse entre sí.
Inspecciones de IntelliJ
Si usa IntelliJ, entonces ya está usando sus inspecciones.
Estas son reglas de análisis estático que están marcadas en el IDE. Algunas de ellas también tienen opciones QuickFix para reescribir el código y solucionar el problema.
Las reglas se pueden configurar de forma activada y desactivada, y para elegir el nivel de error utilizado para resaltarlo en el IDE.
Hay muchas buenas inspecciones de IntelliJ. Lo sé porque las leí mientras escribía esto. Utilizo las inspecciones de IntelliJ por defecto y no las he configurado, pero para sacar todo el provecho de las inspecciones, deberías leerlas, identificar las que sean relevantes para tu estilo de codificación y configurar el nivel de advertencia para que las veas en el código.
Lo mejor de las inspecciones de IntelliJ es que vienen gratis con el IDE y ayudan a desarrollar la memoria muscular de:
- observar las advertencias y los errores en la fuente mientras escribes el código
- pasar el ratón sobre el código marcado para conocer las infracciones de las reglas
- usar alt+enter para aplicar una solución rápida al problema
Detecta errores
El Detecta errores El complemento IntelliJ usa el análisis estático para intentar alertarlo sobre errores en su código.
SpotBugs se puede configurar desde las Preferencias de IntelliJ para escanear su código; las reglas reales utilizadas se encuentran en la pestaña Detector.
Suelo usar SpotBugs después de escribir y revisar mi código, y luego ejecuto el «Analizar los archivos del proyecto, incluidas las fuentes de prueba».
Esto me ayuda a identificar errores, código muerto y optimizaciones obvias. También me obliga a investigar algunas de las infracciones señaladas para poder decidir qué hacer.
SpotBugs encontrará problemas, pero no ofrece ninguna acción de corrección rápida para intentar resolverlos.
SpotBugs es fácil de configurar y me parece una segunda opinión objetiva útil para consultar en mi IDE.
Sónar Lint
El Sónar Lint complemento.
SonarLint se puede configurar desde las Preferencias de IntelliJ para seleccionar las reglas con las que se valida el código.
De forma predeterminada, SonarLint se ejecuta en tiempo real y muestra los problemas del código actual que está editando.
SonarLint no ofrece soluciones rápidas, pero la documentación asociada a los informes de infracción suele ser clara y está bien documentada.
En el pasado, SonarLint me resultó útil para alertarme sobre las nuevas funciones de Java que conocía en las versiones más recientes de Java.
Estilo de verificación
El Estilo de verificación El plugin ofrece una combinación de reglas de formato y calidad de código.
El plugin CheckStyle viene incluido con «Sun Check» y «Google Check».
Las definiciones de estos pueden ser fácilmente encontrado en línea.
CheckStyle agrega el mayor valor cuando un proyecto ha dedicado tiempo a crear su propio conjunto de reglas. Luego, el complemento IDE se puede configurar para usar ese conjunto de reglas y los programadores pueden realizar un escaneo antes de enviar el código a CI.
CheckStyle se usa con mucha frecuencia como un complemento que falla en la compilación para procesos de CI cuando el número de infracciones de CheckStyle supera un umbral.
Sensei
Sensei utiliza un análisis estático basado en un árbol de sintaxis abstracta (AST) para hacer coincidir el código y crear soluciones rápidas, lo que permite una identificación muy específica del código con problemas.
El AST permite que los QuickFixes asociados a una receta comprendan el código circundante, por ejemplo, al agregar una nueva clase al código, cualquier importación de esa clase solo se agregará al archivo fuente una vez, y no para cada reemplazo.
Sensei se creó para facilitar la creación de reglas de coincidencia personalizadas que pueden no existir o que serían difíciles de configurar en otras herramientas.
En lugar de modificar un archivo de configuración, toda la configuración se puede realizar en la GUI. Al crear nuevas recetas, la GUI facilita ver con qué código coincide la receta. Además, al definir los QuickFixes, el estado anterior y posterior del código se puede comparar inmediatamente. Esto facilita la creación de recetas muy contextuales, es decir, exclusivas para equipos o tecnologías, e incluso para programadores individuales.
Utilizo Sensei en combinación con otras herramientas de análisis estático, por ejemplo, la mayoría de las herramientas de análisis estático encuentran problemas, pero no los solucionan. Un caso de uso habitual de Sensei es replicar la búsqueda coincidente de la otra herramienta en Sensei y ampliarla con una solución rápida. Esto tiene la ventaja de que la corrección personalizada aplicada ya cumple con los estándares de codificación de tu proyecto.
Periódicamente me encuentro creando recetas de Sensei que ya existen en el conjunto de intenciones de IntelliJ porque el informe de intenciones no coincide del todo con el contexto que he creado o porque el QuickFix proporcionado por IntelliJ no coincide con el patrón de código que quiero usar.
Amplio las herramientas existentes, en lugar de intentar reemplazarlas por completo.
Sensei también puede resultar muy útil a la hora de identificar una variante contextual de una regla común, por ejemplo, si está utilizando una biblioteca SQL que no es compatible con la herramienta de análisis estático, pero las reglas SQL comunes del motor de análisis estático aún se aplican, puede crear variantes de esas reglas específicas para la biblioteca con Sensei.
Sensei no viene de fábrica con muchas recetas genéricas, como las herramientas de análisis estático mencionadas, sino que su punto fuerte radica en facilitar la creación de nuevas recetas, con correcciones rápidas configuradas para que coincidan con su estilo de codificación y casos de uso específicos.
NOTA: estamos trabajando en un repositorio público de recetas para cubrir los casos de uso genéricos, y lo puedes encontrar aquí.
Resumen
Suelo elegir herramientas que funcionen juntas, que sean configurables y fáciles de expandir para cumplir con mi contexto específico. He usado las herramientas de análisis estático en el IDE durante años para ayudarme a identificar problemas y obtener más información sobre los lenguajes de programación y las bibliotecas que uso.
Utilizo todas las herramientas mencionadas en combinación:
- IntelliJ Intentions ayuda a marcar problemas de código comunes de forma inmediata, a menudo con soluciones rápidas asociadas.
- SpotBugs encuentra errores sencillos que podría haber pasado por alto y me alerta sobre problemas de rendimiento.
- SonarLint identifica las funciones de Java que desconocía y me indica formas adicionales de modelar mi código.
- CheckStyle me ayuda a ajustarme a un estilo de codificación acordado que también se aplica durante la CI.
- Sensei me ayuda a crear soluciones rápidas para aumentar los escenarios comunes que encuentran las herramientas de análisis estático y crear recetas tecnológicas o de proyectos específicos que pueden resultar difíciles de configurar en otra herramienta.
---
Instale Sensei desde IntelliJ mediante «Preferencias\ Plugins» (Mac) o «Configuración\ Plugins» (Windows) y, a continuación, busque «código seguro de sensei».
Puedes encontrar un repositorio de códigos de ejemplo y recetas para casos de uso comunes en la cuenta de GitHub de Secure Code Warrior, en el proyecto `sensei-blog-examples`.
https://github.com/securecodewarrior/sensei-blog-examples
Haga clic en el enlace de abajo y descargue el PDF de este recurso.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Ver informeReserva una demostración
Alan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.
¿Qué es el análisis estático?
El análisis estático es el análisis automatizado del código fuente sin ejecutar la aplicación.
Cuando el análisis se realiza durante la ejecución del programa, se conoce como análisis dinámico.
El análisis estático se utiliza a menudo para detectar:
- Vulnerabilidades de seguridad.
- Problemas de rendimiento.
- Incumplimiento de las normas.
- Uso de construcciones de programación desactualizadas.
¿Cómo funciona una herramienta de análisis estático?
El concepto básico común a todas las herramientas de análisis estático es buscar en el código fuente para identificar patrones de codificación específicos que tienen algún tipo de advertencia o información asociada a ellos.
Esto podría ser tan simple como «las clases de prueba de JUnit 5 no necesitan ser 'públicas'». O algo complejo de identificar, como «Se utiliza una entrada de cadena no confiable en una sentencia de ejecución de SQL».
Las herramientas de análisis estático varían en la forma en que implementan esta funcionalidad.
- tecnología de análisis de código fuente para crear un árbol de sintaxis abstracta (AST),
- coincidencia de expresiones regulares de texto,
- una combinación de las anteriores.
La coincidencia de expresiones regulares en el texto es muy flexible, es fácil escribir reglas para hacer coincidir, pero a menudo puede generar muchos falsos positivos y las reglas de coincidencia ignoran el contexto del código circundante.
La coincidencia AST trata el código fuente como código de programa, y no solo como archivos llenos de texto, esto permite una coincidencia contextual más específica y puede reducir la cantidad de falsos positivos reportados en relación con el código.
Análisis estático en integración continua
El análisis estático a menudo se realiza durante el proceso de integración continua (CI) para generar un informe de problemas de cumplimiento que se puede revisar para obtener una visión objetiva del código base a lo largo del tiempo.
Algunas personas usan el análisis estático como una medida objetiva de la calidad de su código al configurar la herramienta de análisis estático para medir solo partes específicas del código y solo informar sobre un subconjunto de reglas.
La objetividad la proporcionan las reglas utilizadas, ya que no varían en su evaluación del código a lo largo del tiempo. Es evidente que la combinación de las reglas utilizadas y su configuración es una decisión subjetiva y los diferentes equipos eligen usar reglas diferentes en momentos diferentes.
Realizar el análisis estático en CI es útil, pero puede retrasar la retroalimentación al programador. Los programadores no reciben comentarios cuando codifican, sino que los reciben más adelante, cuando el código se ejecuta a través de la herramienta de análisis estático. Otro efecto secundario de ejecutar el análisis estático en CI es que es más fácil ignorar los resultados.
Para ayudar a los equipos a prestar más atención a los resultados del análisis estático, normalmente es posible configurar una métrica de umbral en el proceso de creación para que la compilación falle si se supera la métrica, por ejemplo, si se activan varias reglas.
Análisis estático en el IDE
Para recibir comentarios más rápido, hay muchos complementos del IDE que ejecutan las reglas de análisis estático en el IDE a pedido o de forma periódica a medida que cambia el código.
Las violaciones de las reglas se pueden ver entonces en el IDE mientras el programador escribe código y, para que sea más difícil ignorarlas, las violaciones a menudo se pueden configurar para que se muestren como código subrayado en el editor.
Personalmente, creo que esta es una forma útil de mejorar mi codificación, especialmente cuando trabajo con una nueva biblioteca que está cubierta por la herramienta de análisis estático. Aunque puede ser «ruidoso» con falsos positivos o reglas que no te interesen. Pero esto se resuelve dando un paso adicional para configurar la herramienta de análisis estático para que ignore ciertas reglas.
Corregir código basado en reglas de análisis estático
Con la mayoría de las herramientas de análisis estático, la corrección de la regla queda en manos del programador, por lo que debe entender la causa de la infracción de la regla y cómo solucionarla.
Muy pocas herramientas de análisis estático también incluyen la capacidad de corregir las infracciones, ya que la solución suele depender del equipo, la tecnología utilizada y los estilos de codificación acordados.
Reglas predeterminadas
La falsa confianza en la calidad de las reglas puede surgir cuando las herramientas de análisis estático vienen con reglas predeterminadas. Es tentador creer que cubren todos los problemas que un programador puede encontrar y todas las circunstancias en las que debería aplicarse esa regla. En ocasiones, las circunstancias en las que debe aplicarse una regla pueden ser sutiles y pueden no ser fáciles de detectar.
La esperanza es que, al utilizar una herramienta de análisis estático e investigar las reglas y las infracciones con más detalle, los programadores desarrollen la habilidad necesaria para detectar y evitar el problema en el contexto de su dominio específico.
Cuando el dominio requiere reglas contextuales, es posible que las herramientas de análisis estático no tengan reglas que coincidan con su dominio o biblioteca y, además, las herramientas suelen ser difíciles de configurar y expandir.
Molestias
Ninguna de estas «molestias» es insuperable:
- falsos positivos
- falta de correcciones
- configuración para ignorar las reglas
- agregar reglas específicas del contexto
Pero a menudo se usan como excusas para evitar el uso de herramientas de análisis estático en primer lugar, lo cual es una pena porque el uso del análisis estático puede ser enormemente útil, como una forma de:
- destacar mejores enfoques para los desarrolladores junior
- obtenga comentarios rápidos sobre infracciones claras de codificación
- identificar problemas poco conocidos que el programador no haya encontrado antes
- reforzar que el programador ha adoptado un buen enfoque de codificación (cuando no se denuncie ninguna infracción)
Herramientas de análisis estático basadas en IDE
Como colaborador individual de un proyecto, me gusta usar herramientas de análisis estático que se ejecutan desde el IDE para recibir comentarios rápidos sobre mi código.
Esto complementa cualquier solicitud de incorporación de cambios, proceso de revisión e integración de CI que pueda tener un proyecto.
Intento identificar herramientas que me den una ventaja y mejoren mi flujo de trabajo individual.
Cuando las herramientas se ejecutan en el IDE, dado que tienden a compartir la misma GUI básica y el mismo enfoque de configuración, puede resultar tentador verlas indistintamente.
Las herramientas pueden tener funciones o conjuntos de reglas superpuestos, pero para obtener el máximo beneficio instalo varias herramientas para aprovechar sus puntos fuertes.
Las herramientas IDE de análisis estático que uso activamente al codificar se enumeran a continuación:
- las inspecciones IntelliJ incorporadas: patrones de codificación comunes
- SpotBugs: errores comunes
- SonarLint: patrones de uso comunes
- checkStyle: patrones de estilo comunes
- Sensei de Secure Code Warrior: creación de reglas personalizadas
Los uso todos porque funcionan bien juntos para aumentarse y complementarse entre sí.
Inspecciones de IntelliJ
Si usa IntelliJ, entonces ya está usando sus inspecciones.
Estas son reglas de análisis estático que están marcadas en el IDE. Algunas de ellas también tienen opciones QuickFix para reescribir el código y solucionar el problema.
Las reglas se pueden configurar de forma activada y desactivada, y para elegir el nivel de error utilizado para resaltarlo en el IDE.
Hay muchas buenas inspecciones de IntelliJ. Lo sé porque las leí mientras escribía esto. Utilizo las inspecciones de IntelliJ por defecto y no las he configurado, pero para sacar todo el provecho de las inspecciones, deberías leerlas, identificar las que sean relevantes para tu estilo de codificación y configurar el nivel de advertencia para que las veas en el código.
Lo mejor de las inspecciones de IntelliJ es que vienen gratis con el IDE y ayudan a desarrollar la memoria muscular de:
- observar las advertencias y los errores en la fuente mientras escribes el código
- pasar el ratón sobre el código marcado para conocer las infracciones de las reglas
- usar alt+enter para aplicar una solución rápida al problema
Detecta errores
El Detecta errores El complemento IntelliJ usa el análisis estático para intentar alertarlo sobre errores en su código.
SpotBugs se puede configurar desde las Preferencias de IntelliJ para escanear su código; las reglas reales utilizadas se encuentran en la pestaña Detector.
Suelo usar SpotBugs después de escribir y revisar mi código, y luego ejecuto el «Analizar los archivos del proyecto, incluidas las fuentes de prueba».
Esto me ayuda a identificar errores, código muerto y optimizaciones obvias. También me obliga a investigar algunas de las infracciones señaladas para poder decidir qué hacer.
SpotBugs encontrará problemas, pero no ofrece ninguna acción de corrección rápida para intentar resolverlos.
SpotBugs es fácil de configurar y me parece una segunda opinión objetiva útil para consultar en mi IDE.
Sónar Lint
El Sónar Lint complemento.
SonarLint se puede configurar desde las Preferencias de IntelliJ para seleccionar las reglas con las que se valida el código.
De forma predeterminada, SonarLint se ejecuta en tiempo real y muestra los problemas del código actual que está editando.
SonarLint no ofrece soluciones rápidas, pero la documentación asociada a los informes de infracción suele ser clara y está bien documentada.
En el pasado, SonarLint me resultó útil para alertarme sobre las nuevas funciones de Java que conocía en las versiones más recientes de Java.
Estilo de verificación
El Estilo de verificación El plugin ofrece una combinación de reglas de formato y calidad de código.
El plugin CheckStyle viene incluido con «Sun Check» y «Google Check».
Las definiciones de estos pueden ser fácilmente encontrado en línea.
CheckStyle agrega el mayor valor cuando un proyecto ha dedicado tiempo a crear su propio conjunto de reglas. Luego, el complemento IDE se puede configurar para usar ese conjunto de reglas y los programadores pueden realizar un escaneo antes de enviar el código a CI.
CheckStyle se usa con mucha frecuencia como un complemento que falla en la compilación para procesos de CI cuando el número de infracciones de CheckStyle supera un umbral.
Sensei
Sensei utiliza un análisis estático basado en un árbol de sintaxis abstracta (AST) para hacer coincidir el código y crear soluciones rápidas, lo que permite una identificación muy específica del código con problemas.
El AST permite que los QuickFixes asociados a una receta comprendan el código circundante, por ejemplo, al agregar una nueva clase al código, cualquier importación de esa clase solo se agregará al archivo fuente una vez, y no para cada reemplazo.
Sensei se creó para facilitar la creación de reglas de coincidencia personalizadas que pueden no existir o que serían difíciles de configurar en otras herramientas.
En lugar de modificar un archivo de configuración, toda la configuración se puede realizar en la GUI. Al crear nuevas recetas, la GUI facilita ver con qué código coincide la receta. Además, al definir los QuickFixes, el estado anterior y posterior del código se puede comparar inmediatamente. Esto facilita la creación de recetas muy contextuales, es decir, exclusivas para equipos o tecnologías, e incluso para programadores individuales.
Utilizo Sensei en combinación con otras herramientas de análisis estático, por ejemplo, la mayoría de las herramientas de análisis estático encuentran problemas, pero no los solucionan. Un caso de uso habitual de Sensei es replicar la búsqueda coincidente de la otra herramienta en Sensei y ampliarla con una solución rápida. Esto tiene la ventaja de que la corrección personalizada aplicada ya cumple con los estándares de codificación de tu proyecto.
Periódicamente me encuentro creando recetas de Sensei que ya existen en el conjunto de intenciones de IntelliJ porque el informe de intenciones no coincide del todo con el contexto que he creado o porque el QuickFix proporcionado por IntelliJ no coincide con el patrón de código que quiero usar.
Amplio las herramientas existentes, en lugar de intentar reemplazarlas por completo.
Sensei también puede resultar muy útil a la hora de identificar una variante contextual de una regla común, por ejemplo, si está utilizando una biblioteca SQL que no es compatible con la herramienta de análisis estático, pero las reglas SQL comunes del motor de análisis estático aún se aplican, puede crear variantes de esas reglas específicas para la biblioteca con Sensei.
Sensei no viene de fábrica con muchas recetas genéricas, como las herramientas de análisis estático mencionadas, sino que su punto fuerte radica en facilitar la creación de nuevas recetas, con correcciones rápidas configuradas para que coincidan con su estilo de codificación y casos de uso específicos.
NOTA: estamos trabajando en un repositorio público de recetas para cubrir los casos de uso genéricos, y lo puedes encontrar aquí.
Resumen
Suelo elegir herramientas que funcionen juntas, que sean configurables y fáciles de expandir para cumplir con mi contexto específico. He usado las herramientas de análisis estático en el IDE durante años para ayudarme a identificar problemas y obtener más información sobre los lenguajes de programación y las bibliotecas que uso.
Utilizo todas las herramientas mencionadas en combinación:
- IntelliJ Intentions ayuda a marcar problemas de código comunes de forma inmediata, a menudo con soluciones rápidas asociadas.
- SpotBugs encuentra errores sencillos que podría haber pasado por alto y me alerta sobre problemas de rendimiento.
- SonarLint identifica las funciones de Java que desconocía y me indica formas adicionales de modelar mi código.
- CheckStyle me ayuda a ajustarme a un estilo de codificación acordado que también se aplica durante la CI.
- Sensei me ayuda a crear soluciones rápidas para aumentar los escenarios comunes que encuentran las herramientas de análisis estático y crear recetas tecnológicas o de proyectos específicos que pueden resultar difíciles de configurar en otra herramienta.
---
Instale Sensei desde IntelliJ mediante «Preferencias\ Plugins» (Mac) o «Configuración\ Plugins» (Windows) y, a continuación, busque «código seguro de sensei».
Puedes encontrar un repositorio de códigos de ejemplo y recetas para casos de uso comunes en la cuenta de GitHub de Secure Code Warrior, en el proyecto `sensei-blog-examples`.
https://github.com/securecodewarrior/sensei-blog-examples
Tabla de contenido
Alan Richardson has more than twenty years of professional IT experience, working as a developer and at every level of the testing hierarchy from Tester through to Head of Testing. Head of Developer Relations at Secure Code Warrior, he works directly with teams, to improve the development of quality secure code. Alan is the author of four books including “Dear Evil Tester”, and “Java For Testers”. Alan has also created online training courses to help people learn Technical Web Testing and Selenium WebDriver with Java. Alan posts his writing and training videos on SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, and CompendiumDev.co.uk.
Secure Code Warrior está aquí para que su organización le ayude a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Ya sea administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudar a su organización a reducir los riesgos asociados con el código inseguro.
Reserva una demostraciónDescargarRecursos para empezar
Temas y contenido de formación sobre código seguro
Nuestro contenido líder en la industria siempre está evolucionando para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Se ofrecen temas que abarcan desde la IA hasta la inyección de XQuery para distintos puestos, desde arquitectos e ingenieros hasta directores de productos y control de calidad. Obtenga un adelanto de lo que ofrece nuestro catálogo de contenido por tema y función.
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
Recursos para empezar
Cybermon está de vuelta: las misiones de IA de Beat the Boss ya están disponibles bajo demanda
Cybermon 2025 Beat the Boss ya está disponible durante todo el año en SCW. Implemente desafíos de seguridad avanzados de IA y LLM para fortalecer el desarrollo seguro de la IA a gran escala.
Explicación de la Ley de Ciberresiliencia: qué significa para el desarrollo de software seguro por diseño
Descubra qué exige la Ley de Ciberresiliencia (CRA) de la UE, a quién se aplica y cómo los equipos de ingeniería pueden prepararse con prácticas de diseño seguras, prevención de vulnerabilidades y desarrollo de capacidades para desarrolladores.
Habilitador 1: Criterios de éxito definidos y medibles
Enabler 1 da inicio a nuestra serie Enablers of Success, de 10 partes, mostrando cómo vincular la codificación segura con los resultados empresariales, como la reducción del riesgo y la velocidad para lograr la madurez del programa a largo plazo.
