¿Qué es el análisis estático?
¿Qué es el análisis estático?
El análisis estático consiste en analizar automáticamente el código fuente sin ejecutar la aplicación.
Cuando el análisis se ejecuta durante la ejecución del programa, se denomina análisis dinámico.
El análisis estático se utiliza a menudo para detectar lo siguiente:
- Vulnerabilidad de seguridad.
- Problemas de rendimiento.
- Infracción de las normas.
- Uso de una estructura de programación obsoleta.
¿Cómo funciona la 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 e identificar patrones de codificación específicos a los que se asocian advertencias o información.
Esto puede ser algo tan simple como «las clases de prueba de JUnit 5 no tienen por qué ser públicas». O puede ser algo difícil de detectar, como «se está utilizando una cadena de caracteres no fiable en una sentencia SQL».
Las herramientas de análisis estático implementan esta función de manera diferente.
- Técnicas de análisis de código fuente para crear árboles sintácticos abstractos (AST)
- Coincidencia de expresiones regulares de texto,
- La combinación mencionada anteriormente.
La coincidencia de expresiones regulares en el texto es muy flexible y permite describir fácilmente las reglas de coincidencia, pero en muchos casos puede producirse un gran número de detecciones erróneas, ya que las reglas de coincidencia no reconocen el contexto del código circundante.
En la comprobación AST, el código fuente no se trata como un simple archivo de texto, sino como código de programa. Esto permite una comprobación más específica y adaptada a cada situación, lo que reduce el número de falsos positivos detectados en el código.
Análisis estático en la integración continua
En muchos casos, el análisis estático se ejecuta durante el proceso de integración continua (CI) y genera informes sobre problemas de cumplimiento. La revisión de estos informes permite obtener una visión objetiva de la base de código a lo largo del tiempo.
Algunas personas utilizan el análisis estático como medida objetiva de la calidad del código configurando las herramientas de análisis estático para que midan solo partes específicas del código y reporten solo un subconjunto de reglas.
La objetividad viene determinada por las reglas que se utilizan, ya que estas no cambian con el tiempo en la evaluación del código. Es evidente que la combinación de reglas utilizadas y su configuración son decisiones subjetivas, y que diferentes equipos eligen utilizar reglas diferentes en momentos diferentes.
Aunque resulta útil realizar análisis estáticos en CI, es posible que se retrase la retroalimentación a los programadores. Los programadores no reciben retroalimentación mientras escriben el código, sino cuando ejecutan el código posteriormente con la herramienta de análisis estático. Otro efecto secundario de realizar análisis estáticos en CI es que resulta más fácil ignorar los resultados.
Para que el equipo pueda centrarse más fácilmente en los resultados del análisis estático, normalmente se pueden configurar métricas de umbral en el proceso de compilación, de modo que la compilación falle si se superan dichas métricas. Por ejemplo, cuando se activan numerosas reglas.
Análisis estático en IDE
Para recibir comentarios más rápidamente, hay muchos complementos IDE disponibles que ejecutan reglas de análisis estático IDE bajo demanda o periódicamente cuando se modifica el código.
A menudo, para que los programadores puedan comprobar las infracciones de las reglas en el IDE mientras escriben código y para que sea más difícil ignorar las reglas, se pueden configurar las infracciones para que se muestren como código subrayado en el editor.
Personalmente, creo que es una forma útil de mejorar la codificación. Esto es especialmente cierto cuando se utilizan nuevas bibliotecas cubiertas por herramientas de análisis estático. Sin embargo, puede haber «mucho ruido» si hay reglas erróneas o que no son de interés. No obstante, este problema se puede resolver tomando medidas adicionales para configurar la herramienta de análisis estático de modo que ignore reglas específicas.
Modificación del código basada en reglas de análisis estático
En la mayoría de las herramientas de análisis estático, la corrección de las reglas se deja en manos de los programadores, por lo que estos deben comprender la causa de la infracción de las reglas y cómo corregirla.
Hay muy pocas herramientas de análisis estático que incluyan funciones para corregir infracciones. Esto se debe a que, en la mayoría de los casos, las correcciones se realizan de acuerdo con el equipo, la tecnología utilizada y el estilo de codificación acordado.
Regla por defecto
Si las herramientas de análisis estático incluyen reglas predeterminadas, es posible que se genere una confianza errónea en la calidad de las reglas. Es fácil creer que cubren todos los problemas con los que se puede encontrar un programador y todas las situaciones en las que se deben aplicar dichas reglas. Las situaciones en las que se deben aplicar las reglas pueden ser sutiles y difíciles de identificar.
Se espera que, mediante el uso de herramientas de análisis estático y la investigación más detallada de las reglas y las infracciones, los programadores adquieran la capacidad de detectar y evitar problemas en el contexto de un dominio específico.
Cuando se necesitan reglas de contexto para un dominio, es posible que la herramienta de análisis estático no tenga reglas que coincidan con el dominio o la biblioteca, y además, puede resultar difícil configurar y ampliar la herramienta.
molestia
Ninguna de estas «molestias» es insuperable.
- Falso positivo
- Falta de corrección
- Configuración que ignora las reglas
- Añadir reglas específicas del contexto
Sin embargo, a menudo se utiliza como excusa para evitar el uso de herramientas de análisis estático. Es una lástima, ya que el análisis estático puede resultar muy útil en los siguientes casos:
- Enfatizar un mejor enfoque hacia los desarrolladores jóvenes.
- Obtener rápidamente comentarios sobre infracciones claras de codificación.
- Identificar problemas poco claros que los programadores nunca han encontrado antes.
- Destacar que los programadores están adoptando excelentes técnicas de codificación (si no se han reportado infracciones).
Herramienta de análisis estático basada en IDE
Como colaborador individual del proyecto, me gusta utilizar herramientas de análisis estático que se ejecutan desde el IDE para poder recibir rápidamente comentarios sobre el código.
Esto complementa el proceso de revisión de solicitudes de extracción y la posible integración de CI del proyecto.
Intento encontrar herramientas que me den ventaja y mejoren mi flujo de trabajo individual.
Cuando se ejecuta la herramienta en el IDE, la interfaz gráfica de usuario básica y el enfoque de configuración tienden a ser los mismos, por lo que es posible que desee que se muestre de la misma manera.
Las herramientas pueden tener funciones y conjuntos de reglas que se duplican, pero hemos instalado varias herramientas para aprovechar al máximo sus ventajas.
Las herramientas IDE de análisis estático que utilizo activamente durante la codificación son las siguientes.
- Inspección integrada de IntelliJ: patrones de codificación comunes
- Errores comunes
- SonarLint: patrones de uso generales
- Estilo de verificación: patrón de estilo general
- Profesor de Secure Code Warrior: creación de reglas personalizadas
Los utilizo todos porque se complementan entre sí y funcionan bien juntos.
Inspección de IntelliJ
Si utiliza IntelliJ, ya está utilizando esa inspección.
Estas son reglas de análisis estático marcadas en el IDE. Algunas de ellas incluyen la opción QuickFix para reescribir el código y solucionar el problema.
Las reglas se pueden activar y desactivar, y también se puede seleccionar el nivel de error que se resaltará en el IDE.
IntelliJ tiene muchas inspecciones excelentes. Lo sé porque las he revisado mientras escribía esto. Utilizo las inspecciones de IntelliJ como valor predeterminado, pero aún no las he configurado. Para sacar el máximo partido a las inspecciones, es necesario revisarlas, identificar las que son relevantes para tu estilo de programación y configurar el nivel de advertencia para que te avisen cuando las detecten en el código.
Lo mejor de las inspecciones de IntelliJ es que vienen incluidas de forma gratuita en el IDE y ayudan a desarrollar la memoria muscular, como se describe a continuación.
- Al escribir código, se detectan advertencias y errores en el código fuente.
- Al colocar el cursor sobre el código marcado con una bandera, se puede ver la infracción de la regla.
- Utilice las teclas Alt+Intro para aplicar una solución rápida al problema.
Spot Bug
El complemento SpotBug para IntelliJ utiliza análisis estático para advertir sobre errores en el código.
SpotBugs se puede configurar para escanear código desde las preferencias de IntelliJ. Las reglas que se utilizan realmente se encuentran en la pestaña Detector.
Tiendo a usar SpotBugs después de escribir y revisar el código, y luego ejecuto «Análisis de archivos de proyecto que contienen fuentes de prueba».
Esto ayuda a identificar errores, código muerto y optimizaciones evidentes. También es necesario investigar algunas de las infracciones marcadas para determinar qué se debe hacer.
SpotBugs detecta problemas, pero no ofrece soluciones rápidas para resolverlos.
SpotBugs es fácil de configurar y creo que resulta útil como segunda opinión objetiva de referencia en el IDE.
Sonarint
El complemento Sonarint.
SonarLint se puede configurar desde las preferencias de IntelliJ y permite seleccionar las reglas que se aplicarán a la verificación del código.
Por defecto, SonarLint se ejecuta en tiempo real y muestra los problemas del código actual que se está editando.
SonarLint no ofrece soluciones rápidas, pero los documentos relacionados con los informes de infracciones suelen ser claros y estar bien documentados.
SonarLint ha sido muy útil, ya que me ha advertido sobre las nuevas funciones de Java que reconocía en las nuevas versiones de Java.
Estilo de verificación
El complemento Check Style de Z提供 una combinación de reglas de formato y calidad del código.
El complemento CheckStyle incluye «Sun Check» y «Google Check».
Estas definiciones se pueden encontrarfácilmente en línea.
CheckStyle ofrece el máximo valor cuando un proyecto dedica tiempo a crear su propio conjunto de reglas. De esta forma, se puede configurar el complemento IDE para que utilice ese conjunto de reglas y los programadores pueden ejecutar un análisis antes de enviar el código a CI.
CheckStyle se utiliza a menudo como complemento de fallo de compilación del proceso de CI cuando el número de infracciones de CheckStyle supera el umbral.
先生
Utilizamos análisis estático basado en árboles de sintaxis abstracta (AST) para comparar códigos y crear soluciones rápidas. Esto nos permite identificar el código problemático de forma muy específica.
Al utilizar AST, QuickFix puede comprender el código circundante relacionado con la receta. Por ejemplo, al añadir una nueva clase al código, la importación de esa clase solo se añade una vez al archivo fuente y no se añade cada vez que se sustituye.
Sensei fue creado para facilitar la creación de reglas de emparejamiento personalizadas que no existen en otras herramientas o que son difíciles de configurar.
En lugar de modificar el archivo de configuración, todas las configuraciones se pueden realizar en la interfaz gráfica de usuario (GUI). Al crear una nueva receta, la GUI permite comprobar fácilmente con qué código coincide la receta. Además, al definir QuickFix, se puede comparar rápidamente el estado del código antes y después. Esto facilita la creación de recetas muy específicas para cada contexto, como recetas específicas para equipos, tecnologías o incluso programadores individuales.
Utilizo Sensei junto con otras herramientas de análisis estático. Por ejemplo, la mayoría de las herramientas de análisis estático detectan problemas, pero no los corrigen. Un uso habitual de Sensei es replicar las coincidencias encontradas por otras herramientas en Sensei y ampliarlas con Quick Fix. Esto tiene la ventaja de que las correcciones personalizadas aplicadas ya cumplen con los estándares de codificación del proyecto.
Debido a que los informes de intenciones no coinciden completamente con el contexto creado o a que las soluciones rápidas que ofrece IntelliJ no coinciden con los patrones de código que se desean utilizar, se crean periódicamente recetas Sensei que ya existen en el conjunto de intenciones de IntelliJ.
No pretende sustituir por completo las herramientas existentes, sino complementarlas.
Sensei también resulta muy útil para identificar variantes contextuales de reglas comunes. Por ejemplo, si se utiliza 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 siguen siendo aplicables, se puede utilizar Sensei para crear variantes específicas de la biblioteca para esas reglas.
Sensei no proporciona recetas generales de inmediato, como las herramientas de análisis estático mencionadas anteriormente. Su punto fuerte es que permite crear fácilmente nuevas recetas utilizando QuickFix, que se configura según estilos de codificación y casos de uso específicos.
Nota: Actualmente, estamos creando un repositorio público de recetas para dar respuesta a los casos de uso más comunes. Puede encontrarlo aquí.
Resumen
Tiendo a elegir herramientas que funcionen en conjunto, sean configurables y se puedan ampliar fácilmente para adaptarse a contextos específicos. He utilizado durante muchos años herramientas de análisis estático de IDE para identificar problemas y profundizar en mi comprensión de los lenguajes de programación y las bibliotecas que utilizo.
Utilice todas las herramientas mencionadas anteriormente de forma combinada.
- IntelliJ Intentions ayuda a informar rápidamente de los problemas de código más comunes. En muchos casos, utiliza soluciones rápidas relacionadas.
- SpotBugs encuentra errores simples que podrían haberse pasado por alto y notifica los problemas de rendimiento.
- SonarLint identifica funciones de Java que yo no había detectado y me enseña otras formas de modelar el código.
- CheckStyle ayuda a cumplir con los estilos de codificación acordados que se aplican también durante la integración continua.
- Sensei ayuda a crear soluciones rápidas para reforzar los escenarios comunes que se observan en las herramientas de análisis estático y para crear recetas tecnológicas y proyectos específicos que son difíciles de configurar con otras herramientas.
---
Utilice «Preferencias\ Complementos» (Mac) o «Configuración\ Complementos» (Windows) para instalar Sensei desde IntelliJ y busque «código seguro de Sensei».
El repositorio de código de ejemplo y recetas para casos de uso generales se encuentra en el proyectosensei de la cuenta deSecure Code Warrior deSecure Code Warrior .
https://github.com/securecodewarrior/sensei-blog-examples
Más información sobre el profesor
Aprendamos cómo el análisis estático puede ayudar a escribir código, tomando como referencia cinco enfoques basados en IDE y ejemplos de complementos.
Alan Richardson lleva más de 20 años trabajando como desarrollador y ha acumulado experiencia en todos los niveles de la jerarquía de pruebas, desde probador hasta responsable de pruebas.Es responsableSecure Code Warrior y colabora directamente con el equipo para mejorar el desarrollo de código seguro y de alta calidad. Alan es autor de cuatro libros, entre los que se incluyen Dear Evil Tester y Java for Testers. Además, ha creado cursos de formación en línea que ayudan a aprender pruebas web técnicas y Selenium WebDriver con Java.Alan publica artículos y vídeos de formación en SeleniumSimplified.com, EvilTester.com, JavaForTesters.com y CompendiumDev.co.uk.
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Reservar una demostración
Alan Richardson lleva más de 20 años trabajando como desarrollador y ha acumulado experiencia en todos los niveles de la jerarquía de pruebas, desde probador hasta responsable de pruebas.Es responsableSecure Code Warrior y colabora directamente con el equipo para mejorar el desarrollo de código seguro y de alta calidad. Alan es autor de cuatro libros, entre los que se incluyen Dear Evil Tester y Java for Testers. Además, ha creado cursos de formación en línea que ayudan a aprender pruebas web técnicas y Selenium WebDriver con Java.Alan publica artículos y vídeos de formación en SeleniumSimplified.com, EvilTester.com, JavaForTesters.com y CompendiumDev.co.uk.
¿Qué es el análisis estático?
El análisis estático consiste en analizar automáticamente el código fuente sin ejecutar la aplicación.
Cuando el análisis se ejecuta durante la ejecución del programa, se denomina análisis dinámico.
El análisis estático se utiliza a menudo para detectar lo siguiente:
- Vulnerabilidad de seguridad.
- Problemas de rendimiento.
- Infracción de las normas.
- Uso de una estructura de programación obsoleta.
¿Cómo funciona la 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 e identificar patrones de codificación específicos a los que se asocian advertencias o información.
Esto puede ser algo tan simple como «las clases de prueba de JUnit 5 no tienen por qué ser públicas». O puede ser algo difícil de detectar, como «se está utilizando una cadena de caracteres no fiable en una sentencia SQL».
Las herramientas de análisis estático implementan esta función de manera diferente.
- Técnicas de análisis de código fuente para crear árboles sintácticos abstractos (AST)
- Coincidencia de expresiones regulares de texto,
- La combinación mencionada anteriormente.
La coincidencia de expresiones regulares en el texto es muy flexible y permite describir fácilmente las reglas de coincidencia, pero en muchos casos puede producirse un gran número de detecciones erróneas, ya que las reglas de coincidencia no reconocen el contexto del código circundante.
En la comprobación AST, el código fuente no se trata como un simple archivo de texto, sino como código de programa. Esto permite una comprobación más específica y adaptada a cada situación, lo que reduce el número de falsos positivos detectados en el código.
Análisis estático en la integración continua
En muchos casos, el análisis estático se ejecuta durante el proceso de integración continua (CI) y genera informes sobre problemas de cumplimiento. La revisión de estos informes permite obtener una visión objetiva de la base de código a lo largo del tiempo.
Algunas personas utilizan el análisis estático como medida objetiva de la calidad del código configurando las herramientas de análisis estático para que midan solo partes específicas del código y reporten solo un subconjunto de reglas.
La objetividad viene determinada por las reglas que se utilizan, ya que estas no cambian con el tiempo en la evaluación del código. Es evidente que la combinación de reglas utilizadas y su configuración son decisiones subjetivas, y que diferentes equipos eligen utilizar reglas diferentes en momentos diferentes.
Aunque resulta útil realizar análisis estáticos en CI, es posible que se retrase la retroalimentación a los programadores. Los programadores no reciben retroalimentación mientras escriben el código, sino cuando ejecutan el código posteriormente con la herramienta de análisis estático. Otro efecto secundario de realizar análisis estáticos en CI es que resulta más fácil ignorar los resultados.
Para que el equipo pueda centrarse más fácilmente en los resultados del análisis estático, normalmente se pueden configurar métricas de umbral en el proceso de compilación, de modo que la compilación falle si se superan dichas métricas. Por ejemplo, cuando se activan numerosas reglas.
Análisis estático en IDE
Para recibir comentarios más rápidamente, hay muchos complementos IDE disponibles que ejecutan reglas de análisis estático IDE bajo demanda o periódicamente cuando se modifica el código.
A menudo, para que los programadores puedan comprobar las infracciones de las reglas en el IDE mientras escriben código y para que sea más difícil ignorar las reglas, se pueden configurar las infracciones para que se muestren como código subrayado en el editor.
Personalmente, creo que es una forma útil de mejorar la codificación. Esto es especialmente cierto cuando se utilizan nuevas bibliotecas cubiertas por herramientas de análisis estático. Sin embargo, puede haber «mucho ruido» si hay reglas erróneas o que no son de interés. No obstante, este problema se puede resolver tomando medidas adicionales para configurar la herramienta de análisis estático de modo que ignore reglas específicas.
Modificación del código basada en reglas de análisis estático
En la mayoría de las herramientas de análisis estático, la corrección de las reglas se deja en manos de los programadores, por lo que estos deben comprender la causa de la infracción de las reglas y cómo corregirla.
Hay muy pocas herramientas de análisis estático que incluyan funciones para corregir infracciones. Esto se debe a que, en la mayoría de los casos, las correcciones se realizan de acuerdo con el equipo, la tecnología utilizada y el estilo de codificación acordado.
Regla por defecto
Si las herramientas de análisis estático incluyen reglas predeterminadas, es posible que se genere una confianza errónea en la calidad de las reglas. Es fácil creer que cubren todos los problemas con los que se puede encontrar un programador y todas las situaciones en las que se deben aplicar dichas reglas. Las situaciones en las que se deben aplicar las reglas pueden ser sutiles y difíciles de identificar.
Se espera que, mediante el uso de herramientas de análisis estático y la investigación más detallada de las reglas y las infracciones, los programadores adquieran la capacidad de detectar y evitar problemas en el contexto de un dominio específico.
Cuando se necesitan reglas de contexto para un dominio, es posible que la herramienta de análisis estático no tenga reglas que coincidan con el dominio o la biblioteca, y además, puede resultar difícil configurar y ampliar la herramienta.
molestia
Ninguna de estas «molestias» es insuperable.
- Falso positivo
- Falta de corrección
- Configuración que ignora las reglas
- Añadir reglas específicas del contexto
Sin embargo, a menudo se utiliza como excusa para evitar el uso de herramientas de análisis estático. Es una lástima, ya que el análisis estático puede resultar muy útil en los siguientes casos:
- Enfatizar un mejor enfoque hacia los desarrolladores jóvenes.
- Obtener rápidamente comentarios sobre infracciones claras de codificación.
- Identificar problemas poco claros que los programadores nunca han encontrado antes.
- Destacar que los programadores están adoptando excelentes técnicas de codificación (si no se han reportado infracciones).
Herramienta de análisis estático basada en IDE
Como colaborador individual del proyecto, me gusta utilizar herramientas de análisis estático que se ejecutan desde el IDE para poder recibir rápidamente comentarios sobre el código.
Esto complementa el proceso de revisión de solicitudes de extracción y la posible integración de CI del proyecto.
Intento encontrar herramientas que me den ventaja y mejoren mi flujo de trabajo individual.
Cuando se ejecuta la herramienta en el IDE, la interfaz gráfica de usuario básica y el enfoque de configuración tienden a ser los mismos, por lo que es posible que desee que se muestre de la misma manera.
Las herramientas pueden tener funciones y conjuntos de reglas que se duplican, pero hemos instalado varias herramientas para aprovechar al máximo sus ventajas.
Las herramientas IDE de análisis estático que utilizo activamente durante la codificación son las siguientes.
- Inspección integrada de IntelliJ: patrones de codificación comunes
- Errores comunes
- SonarLint: patrones de uso generales
- Estilo de verificación: patrón de estilo general
- Profesor de Secure Code Warrior: creación de reglas personalizadas
Los utilizo todos porque se complementan entre sí y funcionan bien juntos.
Inspección de IntelliJ
Si utiliza IntelliJ, ya está utilizando esa inspección.
Estas son reglas de análisis estático marcadas en el IDE. Algunas de ellas incluyen la opción QuickFix para reescribir el código y solucionar el problema.
Las reglas se pueden activar y desactivar, y también se puede seleccionar el nivel de error que se resaltará en el IDE.
IntelliJ tiene muchas inspecciones excelentes. Lo sé porque las he revisado mientras escribía esto. Utilizo las inspecciones de IntelliJ como valor predeterminado, pero aún no las he configurado. Para sacar el máximo partido a las inspecciones, es necesario revisarlas, identificar las que son relevantes para tu estilo de programación y configurar el nivel de advertencia para que te avisen cuando las detecten en el código.
Lo mejor de las inspecciones de IntelliJ es que vienen incluidas de forma gratuita en el IDE y ayudan a desarrollar la memoria muscular, como se describe a continuación.
- Al escribir código, se detectan advertencias y errores en el código fuente.
- Al colocar el cursor sobre el código marcado con una bandera, se puede ver la infracción de la regla.
- Utilice las teclas Alt+Intro para aplicar una solución rápida al problema.
Spot Bug
El complemento SpotBug para IntelliJ utiliza análisis estático para advertir sobre errores en el código.
SpotBugs se puede configurar para escanear código desde las preferencias de IntelliJ. Las reglas que se utilizan realmente se encuentran en la pestaña Detector.
Tiendo a usar SpotBugs después de escribir y revisar el código, y luego ejecuto «Análisis de archivos de proyecto que contienen fuentes de prueba».
Esto ayuda a identificar errores, código muerto y optimizaciones evidentes. También es necesario investigar algunas de las infracciones marcadas para determinar qué se debe hacer.
SpotBugs detecta problemas, pero no ofrece soluciones rápidas para resolverlos.
SpotBugs es fácil de configurar y creo que resulta útil como segunda opinión objetiva de referencia en el IDE.
Sonarint
El complemento Sonarint.
SonarLint se puede configurar desde las preferencias de IntelliJ y permite seleccionar las reglas que se aplicarán a la verificación del código.
Por defecto, SonarLint se ejecuta en tiempo real y muestra los problemas del código actual que se está editando.
SonarLint no ofrece soluciones rápidas, pero los documentos relacionados con los informes de infracciones suelen ser claros y estar bien documentados.
SonarLint ha sido muy útil, ya que me ha advertido sobre las nuevas funciones de Java que reconocía en las nuevas versiones de Java.
Estilo de verificación
El complemento Check Style de Z提供 una combinación de reglas de formato y calidad del código.
El complemento CheckStyle incluye «Sun Check» y «Google Check».
Estas definiciones se pueden encontrarfácilmente en línea.
CheckStyle ofrece el máximo valor cuando un proyecto dedica tiempo a crear su propio conjunto de reglas. De esta forma, se puede configurar el complemento IDE para que utilice ese conjunto de reglas y los programadores pueden ejecutar un análisis antes de enviar el código a CI.
CheckStyle se utiliza a menudo como complemento de fallo de compilación del proceso de CI cuando el número de infracciones de CheckStyle supera el umbral.
先生
Utilizamos análisis estático basado en árboles de sintaxis abstracta (AST) para comparar códigos y crear soluciones rápidas. Esto nos permite identificar el código problemático de forma muy específica.
Al utilizar AST, QuickFix puede comprender el código circundante relacionado con la receta. Por ejemplo, al añadir una nueva clase al código, la importación de esa clase solo se añade una vez al archivo fuente y no se añade cada vez que se sustituye.
Sensei fue creado para facilitar la creación de reglas de emparejamiento personalizadas que no existen en otras herramientas o que son difíciles de configurar.
En lugar de modificar el archivo de configuración, todas las configuraciones se pueden realizar en la interfaz gráfica de usuario (GUI). Al crear una nueva receta, la GUI permite comprobar fácilmente con qué código coincide la receta. Además, al definir QuickFix, se puede comparar rápidamente el estado del código antes y después. Esto facilita la creación de recetas muy específicas para cada contexto, como recetas específicas para equipos, tecnologías o incluso programadores individuales.
Utilizo Sensei junto con otras herramientas de análisis estático. Por ejemplo, la mayoría de las herramientas de análisis estático detectan problemas, pero no los corrigen. Un uso habitual de Sensei es replicar las coincidencias encontradas por otras herramientas en Sensei y ampliarlas con Quick Fix. Esto tiene la ventaja de que las correcciones personalizadas aplicadas ya cumplen con los estándares de codificación del proyecto.
Debido a que los informes de intenciones no coinciden completamente con el contexto creado o a que las soluciones rápidas que ofrece IntelliJ no coinciden con los patrones de código que se desean utilizar, se crean periódicamente recetas Sensei que ya existen en el conjunto de intenciones de IntelliJ.
No pretende sustituir por completo las herramientas existentes, sino complementarlas.
Sensei también resulta muy útil para identificar variantes contextuales de reglas comunes. Por ejemplo, si se utiliza 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 siguen siendo aplicables, se puede utilizar Sensei para crear variantes específicas de la biblioteca para esas reglas.
Sensei no proporciona recetas generales de inmediato, como las herramientas de análisis estático mencionadas anteriormente. Su punto fuerte es que permite crear fácilmente nuevas recetas utilizando QuickFix, que se configura según estilos de codificación y casos de uso específicos.
Nota: Actualmente, estamos creando un repositorio público de recetas para dar respuesta a los casos de uso más comunes. Puede encontrarlo aquí.
Resumen
Tiendo a elegir herramientas que funcionen en conjunto, sean configurables y se puedan ampliar fácilmente para adaptarse a contextos específicos. He utilizado durante muchos años herramientas de análisis estático de IDE para identificar problemas y profundizar en mi comprensión de los lenguajes de programación y las bibliotecas que utilizo.
Utilice todas las herramientas mencionadas anteriormente de forma combinada.
- IntelliJ Intentions ayuda a informar rápidamente de los problemas de código más comunes. En muchos casos, utiliza soluciones rápidas relacionadas.
- SpotBugs encuentra errores simples que podrían haberse pasado por alto y notifica los problemas de rendimiento.
- SonarLint identifica funciones de Java que yo no había detectado y me enseña otras formas de modelar el código.
- CheckStyle ayuda a cumplir con los estilos de codificación acordados que se aplican también durante la integración continua.
- Sensei ayuda a crear soluciones rápidas para reforzar los escenarios comunes que se observan en las herramientas de análisis estático y para crear recetas tecnológicas y proyectos específicos que son difíciles de configurar con otras herramientas.
---
Utilice «Preferencias\ Complementos» (Mac) o «Configuración\ Complementos» (Windows) para instalar Sensei desde IntelliJ y busque «código seguro de Sensei».
El repositorio de código de ejemplo y recetas para casos de uso generales se encuentra en el proyectosensei de la cuenta deSecure Code Warrior deSecure Code Warrior .
https://github.com/securecodewarrior/sensei-blog-examples
Más información sobre el profesor
¿Qué es el análisis estático?
El análisis estático consiste en analizar automáticamente el código fuente sin ejecutar la aplicación.
Cuando el análisis se ejecuta durante la ejecución del programa, se denomina análisis dinámico.
El análisis estático se utiliza a menudo para detectar lo siguiente:
- Vulnerabilidad de seguridad.
- Problemas de rendimiento.
- Infracción de las normas.
- Uso de una estructura de programación obsoleta.
¿Cómo funciona la 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 e identificar patrones de codificación específicos a los que se asocian advertencias o información.
Esto puede ser algo tan simple como «las clases de prueba de JUnit 5 no tienen por qué ser públicas». O puede ser algo difícil de detectar, como «se está utilizando una cadena de caracteres no fiable en una sentencia SQL».
Las herramientas de análisis estático implementan esta función de manera diferente.
- Técnicas de análisis de código fuente para crear árboles sintácticos abstractos (AST)
- Coincidencia de expresiones regulares de texto,
- La combinación mencionada anteriormente.
La coincidencia de expresiones regulares en el texto es muy flexible y permite describir fácilmente las reglas de coincidencia, pero en muchos casos puede producirse un gran número de detecciones erróneas, ya que las reglas de coincidencia no reconocen el contexto del código circundante.
En la comprobación AST, el código fuente no se trata como un simple archivo de texto, sino como código de programa. Esto permite una comprobación más específica y adaptada a cada situación, lo que reduce el número de falsos positivos detectados en el código.
Análisis estático en la integración continua
En muchos casos, el análisis estático se ejecuta durante el proceso de integración continua (CI) y genera informes sobre problemas de cumplimiento. La revisión de estos informes permite obtener una visión objetiva de la base de código a lo largo del tiempo.
Algunas personas utilizan el análisis estático como medida objetiva de la calidad del código configurando las herramientas de análisis estático para que midan solo partes específicas del código y reporten solo un subconjunto de reglas.
La objetividad viene determinada por las reglas que se utilizan, ya que estas no cambian con el tiempo en la evaluación del código. Es evidente que la combinación de reglas utilizadas y su configuración son decisiones subjetivas, y que diferentes equipos eligen utilizar reglas diferentes en momentos diferentes.
Aunque resulta útil realizar análisis estáticos en CI, es posible que se retrase la retroalimentación a los programadores. Los programadores no reciben retroalimentación mientras escriben el código, sino cuando ejecutan el código posteriormente con la herramienta de análisis estático. Otro efecto secundario de realizar análisis estáticos en CI es que resulta más fácil ignorar los resultados.
Para que el equipo pueda centrarse más fácilmente en los resultados del análisis estático, normalmente se pueden configurar métricas de umbral en el proceso de compilación, de modo que la compilación falle si se superan dichas métricas. Por ejemplo, cuando se activan numerosas reglas.
Análisis estático en IDE
Para recibir comentarios más rápidamente, hay muchos complementos IDE disponibles que ejecutan reglas de análisis estático IDE bajo demanda o periódicamente cuando se modifica el código.
A menudo, para que los programadores puedan comprobar las infracciones de las reglas en el IDE mientras escriben código y para que sea más difícil ignorar las reglas, se pueden configurar las infracciones para que se muestren como código subrayado en el editor.
Personalmente, creo que es una forma útil de mejorar la codificación. Esto es especialmente cierto cuando se utilizan nuevas bibliotecas cubiertas por herramientas de análisis estático. Sin embargo, puede haber «mucho ruido» si hay reglas erróneas o que no son de interés. No obstante, este problema se puede resolver tomando medidas adicionales para configurar la herramienta de análisis estático de modo que ignore reglas específicas.
Modificación del código basada en reglas de análisis estático
En la mayoría de las herramientas de análisis estático, la corrección de las reglas se deja en manos de los programadores, por lo que estos deben comprender la causa de la infracción de las reglas y cómo corregirla.
Hay muy pocas herramientas de análisis estático que incluyan funciones para corregir infracciones. Esto se debe a que, en la mayoría de los casos, las correcciones se realizan de acuerdo con el equipo, la tecnología utilizada y el estilo de codificación acordado.
Regla por defecto
Si las herramientas de análisis estático incluyen reglas predeterminadas, es posible que se genere una confianza errónea en la calidad de las reglas. Es fácil creer que cubren todos los problemas con los que se puede encontrar un programador y todas las situaciones en las que se deben aplicar dichas reglas. Las situaciones en las que se deben aplicar las reglas pueden ser sutiles y difíciles de identificar.
Se espera que, mediante el uso de herramientas de análisis estático y la investigación más detallada de las reglas y las infracciones, los programadores adquieran la capacidad de detectar y evitar problemas en el contexto de un dominio específico.
Cuando se necesitan reglas de contexto para un dominio, es posible que la herramienta de análisis estático no tenga reglas que coincidan con el dominio o la biblioteca, y además, puede resultar difícil configurar y ampliar la herramienta.
molestia
Ninguna de estas «molestias» es insuperable.
- Falso positivo
- Falta de corrección
- Configuración que ignora las reglas
- Añadir reglas específicas del contexto
Sin embargo, a menudo se utiliza como excusa para evitar el uso de herramientas de análisis estático. Es una lástima, ya que el análisis estático puede resultar muy útil en los siguientes casos:
- Enfatizar un mejor enfoque hacia los desarrolladores jóvenes.
- Obtener rápidamente comentarios sobre infracciones claras de codificación.
- Identificar problemas poco claros que los programadores nunca han encontrado antes.
- Destacar que los programadores están adoptando excelentes técnicas de codificación (si no se han reportado infracciones).
Herramienta de análisis estático basada en IDE
Como colaborador individual del proyecto, me gusta utilizar herramientas de análisis estático que se ejecutan desde el IDE para poder recibir rápidamente comentarios sobre el código.
Esto complementa el proceso de revisión de solicitudes de extracción y la posible integración de CI del proyecto.
Intento encontrar herramientas que me den ventaja y mejoren mi flujo de trabajo individual.
Cuando se ejecuta la herramienta en el IDE, la interfaz gráfica de usuario básica y el enfoque de configuración tienden a ser los mismos, por lo que es posible que desee que se muestre de la misma manera.
Las herramientas pueden tener funciones y conjuntos de reglas que se duplican, pero hemos instalado varias herramientas para aprovechar al máximo sus ventajas.
Las herramientas IDE de análisis estático que utilizo activamente durante la codificación son las siguientes.
- Inspección integrada de IntelliJ: patrones de codificación comunes
- Errores comunes
- SonarLint: patrones de uso generales
- Estilo de verificación: patrón de estilo general
- Profesor de Secure Code Warrior: creación de reglas personalizadas
Los utilizo todos porque se complementan entre sí y funcionan bien juntos.
Inspección de IntelliJ
Si utiliza IntelliJ, ya está utilizando esa inspección.
Estas son reglas de análisis estático marcadas en el IDE. Algunas de ellas incluyen la opción QuickFix para reescribir el código y solucionar el problema.
Las reglas se pueden activar y desactivar, y también se puede seleccionar el nivel de error que se resaltará en el IDE.
IntelliJ tiene muchas inspecciones excelentes. Lo sé porque las he revisado mientras escribía esto. Utilizo las inspecciones de IntelliJ como valor predeterminado, pero aún no las he configurado. Para sacar el máximo partido a las inspecciones, es necesario revisarlas, identificar las que son relevantes para tu estilo de programación y configurar el nivel de advertencia para que te avisen cuando las detecten en el código.
Lo mejor de las inspecciones de IntelliJ es que vienen incluidas de forma gratuita en el IDE y ayudan a desarrollar la memoria muscular, como se describe a continuación.
- Al escribir código, se detectan advertencias y errores en el código fuente.
- Al colocar el cursor sobre el código marcado con una bandera, se puede ver la infracción de la regla.
- Utilice las teclas Alt+Intro para aplicar una solución rápida al problema.
Spot Bug
El complemento SpotBug para IntelliJ utiliza análisis estático para advertir sobre errores en el código.
SpotBugs se puede configurar para escanear código desde las preferencias de IntelliJ. Las reglas que se utilizan realmente se encuentran en la pestaña Detector.
Tiendo a usar SpotBugs después de escribir y revisar el código, y luego ejecuto «Análisis de archivos de proyecto que contienen fuentes de prueba».
Esto ayuda a identificar errores, código muerto y optimizaciones evidentes. También es necesario investigar algunas de las infracciones marcadas para determinar qué se debe hacer.
SpotBugs detecta problemas, pero no ofrece soluciones rápidas para resolverlos.
SpotBugs es fácil de configurar y creo que resulta útil como segunda opinión objetiva de referencia en el IDE.
Sonarint
El complemento Sonarint.
SonarLint se puede configurar desde las preferencias de IntelliJ y permite seleccionar las reglas que se aplicarán a la verificación del código.
Por defecto, SonarLint se ejecuta en tiempo real y muestra los problemas del código actual que se está editando.
SonarLint no ofrece soluciones rápidas, pero los documentos relacionados con los informes de infracciones suelen ser claros y estar bien documentados.
SonarLint ha sido muy útil, ya que me ha advertido sobre las nuevas funciones de Java que reconocía en las nuevas versiones de Java.
Estilo de verificación
El complemento Check Style de Z提供 una combinación de reglas de formato y calidad del código.
El complemento CheckStyle incluye «Sun Check» y «Google Check».
Estas definiciones se pueden encontrarfácilmente en línea.
CheckStyle ofrece el máximo valor cuando un proyecto dedica tiempo a crear su propio conjunto de reglas. De esta forma, se puede configurar el complemento IDE para que utilice ese conjunto de reglas y los programadores pueden ejecutar un análisis antes de enviar el código a CI.
CheckStyle se utiliza a menudo como complemento de fallo de compilación del proceso de CI cuando el número de infracciones de CheckStyle supera el umbral.
先生
Utilizamos análisis estático basado en árboles de sintaxis abstracta (AST) para comparar códigos y crear soluciones rápidas. Esto nos permite identificar el código problemático de forma muy específica.
Al utilizar AST, QuickFix puede comprender el código circundante relacionado con la receta. Por ejemplo, al añadir una nueva clase al código, la importación de esa clase solo se añade una vez al archivo fuente y no se añade cada vez que se sustituye.
Sensei fue creado para facilitar la creación de reglas de emparejamiento personalizadas que no existen en otras herramientas o que son difíciles de configurar.
En lugar de modificar el archivo de configuración, todas las configuraciones se pueden realizar en la interfaz gráfica de usuario (GUI). Al crear una nueva receta, la GUI permite comprobar fácilmente con qué código coincide la receta. Además, al definir QuickFix, se puede comparar rápidamente el estado del código antes y después. Esto facilita la creación de recetas muy específicas para cada contexto, como recetas específicas para equipos, tecnologías o incluso programadores individuales.
Utilizo Sensei junto con otras herramientas de análisis estático. Por ejemplo, la mayoría de las herramientas de análisis estático detectan problemas, pero no los corrigen. Un uso habitual de Sensei es replicar las coincidencias encontradas por otras herramientas en Sensei y ampliarlas con Quick Fix. Esto tiene la ventaja de que las correcciones personalizadas aplicadas ya cumplen con los estándares de codificación del proyecto.
Debido a que los informes de intenciones no coinciden completamente con el contexto creado o a que las soluciones rápidas que ofrece IntelliJ no coinciden con los patrones de código que se desean utilizar, se crean periódicamente recetas Sensei que ya existen en el conjunto de intenciones de IntelliJ.
No pretende sustituir por completo las herramientas existentes, sino complementarlas.
Sensei también resulta muy útil para identificar variantes contextuales de reglas comunes. Por ejemplo, si se utiliza 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 siguen siendo aplicables, se puede utilizar Sensei para crear variantes específicas de la biblioteca para esas reglas.
Sensei no proporciona recetas generales de inmediato, como las herramientas de análisis estático mencionadas anteriormente. Su punto fuerte es que permite crear fácilmente nuevas recetas utilizando QuickFix, que se configura según estilos de codificación y casos de uso específicos.
Nota: Actualmente, estamos creando un repositorio público de recetas para dar respuesta a los casos de uso más comunes. Puede encontrarlo aquí.
Resumen
Tiendo a elegir herramientas que funcionen en conjunto, sean configurables y se puedan ampliar fácilmente para adaptarse a contextos específicos. He utilizado durante muchos años herramientas de análisis estático de IDE para identificar problemas y profundizar en mi comprensión de los lenguajes de programación y las bibliotecas que utilizo.
Utilice todas las herramientas mencionadas anteriormente de forma combinada.
- IntelliJ Intentions ayuda a informar rápidamente de los problemas de código más comunes. En muchos casos, utiliza soluciones rápidas relacionadas.
- SpotBugs encuentra errores simples que podrían haberse pasado por alto y notifica los problemas de rendimiento.
- SonarLint identifica funciones de Java que yo no había detectado y me enseña otras formas de modelar el código.
- CheckStyle ayuda a cumplir con los estilos de codificación acordados que se aplican también durante la integración continua.
- Sensei ayuda a crear soluciones rápidas para reforzar los escenarios comunes que se observan en las herramientas de análisis estático y para crear recetas tecnológicas y proyectos específicos que son difíciles de configurar con otras herramientas.
---
Utilice «Preferencias\ Complementos» (Mac) o «Configuración\ Complementos» (Windows) para instalar Sensei desde IntelliJ y busque «código seguro de Sensei».
El repositorio de código de ejemplo y recetas para casos de uso generales se encuentra en el proyectosensei de la cuenta deSecure Code Warrior deSecure Code Warrior .
https://github.com/securecodewarrior/sensei-blog-examples
Más información sobre el profesor
Haga clic en el siguiente enlace para descargar el PDF de este recurso.
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Mostrar informeReservar una demostración
Alan Richardson lleva más de 20 años trabajando como desarrollador y ha acumulado experiencia en todos los niveles de la jerarquía de pruebas, desde probador hasta responsable de pruebas.Es responsableSecure Code Warrior y colabora directamente con el equipo para mejorar el desarrollo de código seguro y de alta calidad. Alan es autor de cuatro libros, entre los que se incluyen Dear Evil Tester y Java for Testers. Además, ha creado cursos de formación en línea que ayudan a aprender pruebas web técnicas y Selenium WebDriver con Java.Alan publica artículos y vídeos de formación en SeleniumSimplified.com, EvilTester.com, JavaForTesters.com y CompendiumDev.co.uk.
¿Qué es el análisis estático?
El análisis estático consiste en analizar automáticamente el código fuente sin ejecutar la aplicación.
Cuando el análisis se ejecuta durante la ejecución del programa, se denomina análisis dinámico.
El análisis estático se utiliza a menudo para detectar lo siguiente:
- Vulnerabilidad de seguridad.
- Problemas de rendimiento.
- Infracción de las normas.
- Uso de una estructura de programación obsoleta.
¿Cómo funciona la 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 e identificar patrones de codificación específicos a los que se asocian advertencias o información.
Esto puede ser algo tan simple como «las clases de prueba de JUnit 5 no tienen por qué ser públicas». O puede ser algo difícil de detectar, como «se está utilizando una cadena de caracteres no fiable en una sentencia SQL».
Las herramientas de análisis estático implementan esta función de manera diferente.
- Técnicas de análisis de código fuente para crear árboles sintácticos abstractos (AST)
- Coincidencia de expresiones regulares de texto,
- La combinación mencionada anteriormente.
La coincidencia de expresiones regulares en el texto es muy flexible y permite describir fácilmente las reglas de coincidencia, pero en muchos casos puede producirse un gran número de detecciones erróneas, ya que las reglas de coincidencia no reconocen el contexto del código circundante.
En la comprobación AST, el código fuente no se trata como un simple archivo de texto, sino como código de programa. Esto permite una comprobación más específica y adaptada a cada situación, lo que reduce el número de falsos positivos detectados en el código.
Análisis estático en la integración continua
En muchos casos, el análisis estático se ejecuta durante el proceso de integración continua (CI) y genera informes sobre problemas de cumplimiento. La revisión de estos informes permite obtener una visión objetiva de la base de código a lo largo del tiempo.
Algunas personas utilizan el análisis estático como medida objetiva de la calidad del código configurando las herramientas de análisis estático para que midan solo partes específicas del código y reporten solo un subconjunto de reglas.
La objetividad viene determinada por las reglas que se utilizan, ya que estas no cambian con el tiempo en la evaluación del código. Es evidente que la combinación de reglas utilizadas y su configuración son decisiones subjetivas, y que diferentes equipos eligen utilizar reglas diferentes en momentos diferentes.
Aunque resulta útil realizar análisis estáticos en CI, es posible que se retrase la retroalimentación a los programadores. Los programadores no reciben retroalimentación mientras escriben el código, sino cuando ejecutan el código posteriormente con la herramienta de análisis estático. Otro efecto secundario de realizar análisis estáticos en CI es que resulta más fácil ignorar los resultados.
Para que el equipo pueda centrarse más fácilmente en los resultados del análisis estático, normalmente se pueden configurar métricas de umbral en el proceso de compilación, de modo que la compilación falle si se superan dichas métricas. Por ejemplo, cuando se activan numerosas reglas.
Análisis estático en IDE
Para recibir comentarios más rápidamente, hay muchos complementos IDE disponibles que ejecutan reglas de análisis estático IDE bajo demanda o periódicamente cuando se modifica el código.
A menudo, para que los programadores puedan comprobar las infracciones de las reglas en el IDE mientras escriben código y para que sea más difícil ignorar las reglas, se pueden configurar las infracciones para que se muestren como código subrayado en el editor.
Personalmente, creo que es una forma útil de mejorar la codificación. Esto es especialmente cierto cuando se utilizan nuevas bibliotecas cubiertas por herramientas de análisis estático. Sin embargo, puede haber «mucho ruido» si hay reglas erróneas o que no son de interés. No obstante, este problema se puede resolver tomando medidas adicionales para configurar la herramienta de análisis estático de modo que ignore reglas específicas.
Modificación del código basada en reglas de análisis estático
En la mayoría de las herramientas de análisis estático, la corrección de las reglas se deja en manos de los programadores, por lo que estos deben comprender la causa de la infracción de las reglas y cómo corregirla.
Hay muy pocas herramientas de análisis estático que incluyan funciones para corregir infracciones. Esto se debe a que, en la mayoría de los casos, las correcciones se realizan de acuerdo con el equipo, la tecnología utilizada y el estilo de codificación acordado.
Regla por defecto
Si las herramientas de análisis estático incluyen reglas predeterminadas, es posible que se genere una confianza errónea en la calidad de las reglas. Es fácil creer que cubren todos los problemas con los que se puede encontrar un programador y todas las situaciones en las que se deben aplicar dichas reglas. Las situaciones en las que se deben aplicar las reglas pueden ser sutiles y difíciles de identificar.
Se espera que, mediante el uso de herramientas de análisis estático y la investigación más detallada de las reglas y las infracciones, los programadores adquieran la capacidad de detectar y evitar problemas en el contexto de un dominio específico.
Cuando se necesitan reglas de contexto para un dominio, es posible que la herramienta de análisis estático no tenga reglas que coincidan con el dominio o la biblioteca, y además, puede resultar difícil configurar y ampliar la herramienta.
molestia
Ninguna de estas «molestias» es insuperable.
- Falso positivo
- Falta de corrección
- Configuración que ignora las reglas
- Añadir reglas específicas del contexto
Sin embargo, a menudo se utiliza como excusa para evitar el uso de herramientas de análisis estático. Es una lástima, ya que el análisis estático puede resultar muy útil en los siguientes casos:
- Enfatizar un mejor enfoque hacia los desarrolladores jóvenes.
- Obtener rápidamente comentarios sobre infracciones claras de codificación.
- Identificar problemas poco claros que los programadores nunca han encontrado antes.
- Destacar que los programadores están adoptando excelentes técnicas de codificación (si no se han reportado infracciones).
Herramienta de análisis estático basada en IDE
Como colaborador individual del proyecto, me gusta utilizar herramientas de análisis estático que se ejecutan desde el IDE para poder recibir rápidamente comentarios sobre el código.
Esto complementa el proceso de revisión de solicitudes de extracción y la posible integración de CI del proyecto.
Intento encontrar herramientas que me den ventaja y mejoren mi flujo de trabajo individual.
Cuando se ejecuta la herramienta en el IDE, la interfaz gráfica de usuario básica y el enfoque de configuración tienden a ser los mismos, por lo que es posible que desee que se muestre de la misma manera.
Las herramientas pueden tener funciones y conjuntos de reglas que se duplican, pero hemos instalado varias herramientas para aprovechar al máximo sus ventajas.
Las herramientas IDE de análisis estático que utilizo activamente durante la codificación son las siguientes.
- Inspección integrada de IntelliJ: patrones de codificación comunes
- Errores comunes
- SonarLint: patrones de uso generales
- Estilo de verificación: patrón de estilo general
- Profesor de Secure Code Warrior: creación de reglas personalizadas
Los utilizo todos porque se complementan entre sí y funcionan bien juntos.
Inspección de IntelliJ
Si utiliza IntelliJ, ya está utilizando esa inspección.
Estas son reglas de análisis estático marcadas en el IDE. Algunas de ellas incluyen la opción QuickFix para reescribir el código y solucionar el problema.
Las reglas se pueden activar y desactivar, y también se puede seleccionar el nivel de error que se resaltará en el IDE.
IntelliJ tiene muchas inspecciones excelentes. Lo sé porque las he revisado mientras escribía esto. Utilizo las inspecciones de IntelliJ como valor predeterminado, pero aún no las he configurado. Para sacar el máximo partido a las inspecciones, es necesario revisarlas, identificar las que son relevantes para tu estilo de programación y configurar el nivel de advertencia para que te avisen cuando las detecten en el código.
Lo mejor de las inspecciones de IntelliJ es que vienen incluidas de forma gratuita en el IDE y ayudan a desarrollar la memoria muscular, como se describe a continuación.
- Al escribir código, se detectan advertencias y errores en el código fuente.
- Al colocar el cursor sobre el código marcado con una bandera, se puede ver la infracción de la regla.
- Utilice las teclas Alt+Intro para aplicar una solución rápida al problema.
Spot Bug
El complemento SpotBug para IntelliJ utiliza análisis estático para advertir sobre errores en el código.
SpotBugs se puede configurar para escanear código desde las preferencias de IntelliJ. Las reglas que se utilizan realmente se encuentran en la pestaña Detector.
Tiendo a usar SpotBugs después de escribir y revisar el código, y luego ejecuto «Análisis de archivos de proyecto que contienen fuentes de prueba».
Esto ayuda a identificar errores, código muerto y optimizaciones evidentes. También es necesario investigar algunas de las infracciones marcadas para determinar qué se debe hacer.
SpotBugs detecta problemas, pero no ofrece soluciones rápidas para resolverlos.
SpotBugs es fácil de configurar y creo que resulta útil como segunda opinión objetiva de referencia en el IDE.
Sonarint
El complemento Sonarint.
SonarLint se puede configurar desde las preferencias de IntelliJ y permite seleccionar las reglas que se aplicarán a la verificación del código.
Por defecto, SonarLint se ejecuta en tiempo real y muestra los problemas del código actual que se está editando.
SonarLint no ofrece soluciones rápidas, pero los documentos relacionados con los informes de infracciones suelen ser claros y estar bien documentados.
SonarLint ha sido muy útil, ya que me ha advertido sobre las nuevas funciones de Java que reconocía en las nuevas versiones de Java.
Estilo de verificación
El complemento Check Style de Z提供 una combinación de reglas de formato y calidad del código.
El complemento CheckStyle incluye «Sun Check» y «Google Check».
Estas definiciones se pueden encontrarfácilmente en línea.
CheckStyle ofrece el máximo valor cuando un proyecto dedica tiempo a crear su propio conjunto de reglas. De esta forma, se puede configurar el complemento IDE para que utilice ese conjunto de reglas y los programadores pueden ejecutar un análisis antes de enviar el código a CI.
CheckStyle se utiliza a menudo como complemento de fallo de compilación del proceso de CI cuando el número de infracciones de CheckStyle supera el umbral.
先生
Utilizamos análisis estático basado en árboles de sintaxis abstracta (AST) para comparar códigos y crear soluciones rápidas. Esto nos permite identificar el código problemático de forma muy específica.
Al utilizar AST, QuickFix puede comprender el código circundante relacionado con la receta. Por ejemplo, al añadir una nueva clase al código, la importación de esa clase solo se añade una vez al archivo fuente y no se añade cada vez que se sustituye.
Sensei fue creado para facilitar la creación de reglas de emparejamiento personalizadas que no existen en otras herramientas o que son difíciles de configurar.
En lugar de modificar el archivo de configuración, todas las configuraciones se pueden realizar en la interfaz gráfica de usuario (GUI). Al crear una nueva receta, la GUI permite comprobar fácilmente con qué código coincide la receta. Además, al definir QuickFix, se puede comparar rápidamente el estado del código antes y después. Esto facilita la creación de recetas muy específicas para cada contexto, como recetas específicas para equipos, tecnologías o incluso programadores individuales.
Utilizo Sensei junto con otras herramientas de análisis estático. Por ejemplo, la mayoría de las herramientas de análisis estático detectan problemas, pero no los corrigen. Un uso habitual de Sensei es replicar las coincidencias encontradas por otras herramientas en Sensei y ampliarlas con Quick Fix. Esto tiene la ventaja de que las correcciones personalizadas aplicadas ya cumplen con los estándares de codificación del proyecto.
Debido a que los informes de intenciones no coinciden completamente con el contexto creado o a que las soluciones rápidas que ofrece IntelliJ no coinciden con los patrones de código que se desean utilizar, se crean periódicamente recetas Sensei que ya existen en el conjunto de intenciones de IntelliJ.
No pretende sustituir por completo las herramientas existentes, sino complementarlas.
Sensei también resulta muy útil para identificar variantes contextuales de reglas comunes. Por ejemplo, si se utiliza 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 siguen siendo aplicables, se puede utilizar Sensei para crear variantes específicas de la biblioteca para esas reglas.
Sensei no proporciona recetas generales de inmediato, como las herramientas de análisis estático mencionadas anteriormente. Su punto fuerte es que permite crear fácilmente nuevas recetas utilizando QuickFix, que se configura según estilos de codificación y casos de uso específicos.
Nota: Actualmente, estamos creando un repositorio público de recetas para dar respuesta a los casos de uso más comunes. Puede encontrarlo aquí.
Resumen
Tiendo a elegir herramientas que funcionen en conjunto, sean configurables y se puedan ampliar fácilmente para adaptarse a contextos específicos. He utilizado durante muchos años herramientas de análisis estático de IDE para identificar problemas y profundizar en mi comprensión de los lenguajes de programación y las bibliotecas que utilizo.
Utilice todas las herramientas mencionadas anteriormente de forma combinada.
- IntelliJ Intentions ayuda a informar rápidamente de los problemas de código más comunes. En muchos casos, utiliza soluciones rápidas relacionadas.
- SpotBugs encuentra errores simples que podrían haberse pasado por alto y notifica los problemas de rendimiento.
- SonarLint identifica funciones de Java que yo no había detectado y me enseña otras formas de modelar el código.
- CheckStyle ayuda a cumplir con los estilos de codificación acordados que se aplican también durante la integración continua.
- Sensei ayuda a crear soluciones rápidas para reforzar los escenarios comunes que se observan en las herramientas de análisis estático y para crear recetas tecnológicas y proyectos específicos que son difíciles de configurar con otras herramientas.
---
Utilice «Preferencias\ Complementos» (Mac) o «Configuración\ Complementos» (Windows) para instalar Sensei desde IntelliJ y busque «código seguro de Sensei».
El repositorio de código de ejemplo y recetas para casos de uso generales se encuentra en el proyectosensei de la cuenta deSecure Code Warrior deSecure Code Warrior .
https://github.com/securecodewarrior/sensei-blog-examples
Más información sobre el profesor
Índice
Alan Richardson lleva más de 20 años trabajando como desarrollador y ha acumulado experiencia en todos los niveles de la jerarquía de pruebas, desde probador hasta responsable de pruebas.Es responsableSecure Code Warrior y colabora directamente con el equipo para mejorar el desarrollo de código seguro y de alta calidad. Alan es autor de cuatro libros, entre los que se incluyen Dear Evil Tester y Java for Testers. Además, ha creado cursos de formación en línea que ayudan a aprender pruebas web técnicas y Selenium WebDriver con Java.Alan publica artículos y vídeos de formación en SeleniumSimplified.com, EvilTester.com, JavaForTesters.com y CompendiumDev.co.uk.
Secure Code Warrior le ayuda a proteger el código a lo largo de todo el ciclo de vida del desarrollo de software y a crear una cultura que dé prioridad a la ciberseguridad. Tanto si es gestor de seguridad de aplicaciones, desarrollador, CISO o responsable de seguridad, le ayudamos a reducir los riesgos asociados al código inseguro.
Reservar una demostración[Descargar]Recursos para empezar
Temas y contenidos de la formación en código seguro
Nuestro contenido, líder en el sector, evoluciona constantemente para adaptarse al entorno de desarrollo de software en constante cambio, teniendo siempre en cuenta las funciones de nuestros clientes. Abarca todo tipo de temas, desde la inteligencia artificial hasta la inyección de XQuery, y está diseñado para satisfacer las necesidades de diversos perfiles, desde arquitectos e ingenieros hasta gestores de productos y responsables de control de calidad. Echemos un vistazo al contenido que ofrece nuestro catálogo, clasificado por temas y funciones.
La Cámara de Comercio establece el estándar para la seguridad impulsada por desarrolladores a gran escala
Kamer van Koophandel comparte cómo ha integrado la codificación segura en el desarrollo diario mediante certificaciones basadas en roles, evaluaciones comparativas de Trust Score y una cultura de responsabilidad compartida en materia de seguridad.
%20(1).avif)
.avif)
Modelado de amenazas con IA: convertir a cada desarrollador en un modelador de amenazas
Saldrá mejor equipado para ayudar a los desarrolladores a combinar ideas y técnicas de modelado de amenazas con las herramientas de IA que ya utilizan para reforzar la seguridad, mejorar la colaboración y crear software más resistente desde el principio.
Recursos para empezar
Cybermon ha vuelto: la misión de IA para derrotar al jefe ya está disponible bajo demanda.
Ahora se puede jugar a «Cybermon 2025 Beat the Boss» en SCW durante todo el año. Introduzca retos de seguridad avanzados de IA/LLM y refuerce a gran escala el desarrollo seguro de la IA.
Explicación de la Ley de Resiliencia Cibernética: su significado para el desarrollo de software seguro desde el diseño
Descubra qué exige la Ley de Resiliencia Cibernética (CRA) de la UE, a quién se aplica y cómo puede prepararse el equipo de ingeniería para las prácticas de seguridad desde el diseño, la prevención de vulnerabilidades y el desarrollo de las capacidades de los desarrolladores.
Enable 1: Criterios de éxito predefinidos y medibles
Enabler 1 es la primera parte de la serie Enablers of Success, compuesta por diez partes, y presenta cómo madurar un programa a largo plazo vinculando la codificación segura con resultados empresariales como la reducción de riesgos y la velocidad.
