¿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 se realiza un análisis durante la ejecución del programa, se denomina análisis dinámico.
El análisis estático se utiliza principalmente para detectar lo siguiente:
- Vulnerabilidad de seguridad.
- Problemas de rendimiento.
- No cumple con los estándares.
- 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 para identificar patrones de codificación específicos que contengan advertencias o información relevantes.
Esto puede ser tan simple como «Las clases de prueba JUnit 5 no tienen por qué ser públicas» o tan complejo de identificar como «Entradas de cadenas no fiables utilizadas en sentencias de ejecución SQL».
Las herramientas de análisis estático implementan esta función de diferentes maneras.
- Técnica de análisis sintáctico del código fuente para generar árboles sintácticos abstractos (AST)
- Coincidencia de expresiones regulares de texto,
- Esta es la combinación.
Las expresiones regulares para el texto son muy flexibles y fáciles de escribir, pero a menudo pueden dar lugar a muchos falsos positivos y las reglas de coincidencia ignoran el contexto del código circundante.
AST Matching trata el código fuente no solo como un archivo lleno de texto, sino también como código de programa, lo que permite una coincidencia más específica y adecuada al contexto, y reduce el número de falsos positivos reportados sobre el código.
Análisis estático en la integración continua
El análisis estático se lleva a cabo a menudo durante el proceso de integración continua (CI) para generar informes sobre problemas de cumplimiento normativo. La revisión de estos informes permite obtener una visión objetiva de la base de código a lo largo del tiempo.
Algunos usuarios configuran las herramientas de análisis estático para que midan solo partes específicas del código y reporten solo sobre un subconjunto de reglas, utilizándolas como una medida objetiva de la calidad del código.
La objetividad está garantizada por las reglas utilizadas, ya que la evaluación del código no cambia con el paso del tiempo. Es evidente que la combinación de las reglas utilizadas y su configuración es una decisión subjetiva, y cada equipo elige utilizar reglas diferentes según el momento.
Realizar análisis estáticos en CI es útil, pero puede retrasar la retroalimentación para los programadores. Los programadores no reciben retroalimentación mientras codifican, sino más tarde, cuando ejecutan el código a través de herramientas de análisis estático. Otro efecto secundario de realizar análisis estáticos en CI es que es fácil ignorar los resultados.
Para que el equipo preste más atención a los resultados del análisis estático, normalmente es posible configurar indicadores de umbral en el proceso de compilación para que la compilación falle cuando se superen dichos indicadores (por ejemplo, el número de reglas activadas).
Análisis estático en IDE
Existen muchos complementos para IDE que ejecutan reglas de análisis estático en el IDE de forma periódica, según sea necesario o cuando se modifica el código, con el fin de obtener comentarios más rápidamente.
Entonces, cuando el programador escribe el código, el IDE puede detectar las infracciones de las reglas y, para que sea más difícil ignorarlas, se pueden configurar las infracciones para que se muestren en el editor como código subrayado.
Personalmente, creo que es una forma útil de mejorar la codificación. Especialmente cuando se trabaja con nuevas bibliotecas que se tratan en herramientas de análisis estático. Aunque puede haber mucho ruido debido a falsos positivos o reglas que no son relevantes. Sin embargo, este problema se resuelve configurando la herramienta de análisis estático para ignorar reglas específicas mediante la realización de pasos adicionales.
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 modificación de las reglas se deja en manos del programador, por lo que este debe comprender la causa de la infracción de las reglas y la forma de corregirla.
Hay muy pocas herramientas de análisis estático que incluyan la capacidad de corregir las infracciones. Esto se debe a que las correcciones suelen depender del equipo, la tecnología utilizada y el estilo de codificación acordado.
Reglas básicas
Cuando las herramientas de análisis estático se proporcionan junto con reglas básicas, puede surgir una falsa confianza en la calidad de las reglas. Es fácil creer que abarcan todos los problemas a los que se puede enfrentar un programador y todas las situaciones en las que deben aplicarse las reglas. A veces, las situaciones en las que deben aplicarse las reglas pueden ser sutiles y difíciles de detectar.
Esperamos que, al utilizar herramientas de análisis estático para investigar más a fondo las reglas y las infracciones, los programadores puedan desarrollar técnicas para detectar y prevenir problemas en el contexto de áreas específicas.
Si el dominio requiere reglas de contexto, es posible que la herramienta de análisis estático no tenga reglas que coincidan con el dominio o la biblioteca, y también puede ser difícil configurar y ampliar la herramienta.
성가심
No hay nada insuperable entre estas «molestias».
- 오탐지
- Falta de modificaciones
- Configuración para ignorar las reglas
- Añadir reglas por contexto
Sin embargo, es lamentable que a menudo se utilice como excusa para no utilizar herramientas de análisis estático, ya que el análisis estático puede resultar muy útil de las siguientes maneras.
- Enfoque mejorado para desarrolladores junior
- Obtención de comentarios rápidos sobre infracciones claras de codificación.
- El programador identifica problemas ambiguos que no ha experimentado anteriormente.
- Haga hincapié en que el programador ha adoptado un enfoque de codificación correcto (si no se han notificado 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 dentro del IDE, ya que así puedo obtener rápidamente comentarios sobre el código.
Esto complementa todos los procesos de revisión de solicitudes de incorporación de cambios y la integración de CI que pueden existir en el proyecto.
Busco herramientas que me den ventaja y trato de mejorar mi flujo de trabajo personal.
Cuando la herramienta se ejecuta en el IDE, es posible que desee cambiar de una herramienta a otra, ya que la interfaz gráfica de usuario y el enfoque de configuración son los mismos.
Las herramientas pueden tener funciones o conjuntos de reglas que se repiten, pero para aprovechar al máximo sus ventajas, se instalan varias herramientas y se aprovechan sus ventajas.
Las herramientas IDE de análisis estático que utilizo activamente al programar son las siguientes:
- Inspección integrada de IntelliJ: patrones de codificación comunes
- Spot Bug - Error común
- Sonarint: patrón de uso general
- Estilo de verificación: patrón de estilo general
- Sensei de Secure Code Warrior Sensei creación de reglas personalizadas
Se complementan y refuerzan mutuamente, por lo que se utilizan todos.
Inspección IntelliJ
Si utiliza IntelliJ, ya está utilizando esta comprobación.
Se trata de reglas de análisis estático marcadas en el IDE. Algunas de ellas incluyen la opción QuickFix, que permite reescribir el código para resolver el problema.
Se pueden establecer o desactivar reglas y seleccionar el nivel de error que se utilizará para resaltar en el IDE.
Hay muchas funciones de inspección excelentes en IntelliJ. Lo sé porque he leído todo el contenido mientras escribía este artículo. Utilizo IntelliJ Inspections como valor predeterminado y aún no lo he configurado. Sin embargo, para aprovechar al máximo la inspección, es necesario leerla detenidamente, identificar los elementos relacionados con el estilo de programación propio y configurar el nivel de advertencia para poder verificarlo en el código.
Lo bueno de IntelliJ Inspecing es que se ofrece de forma gratuita junto con el IDE y ayuda a desarrollar la siguiente memoria muscular.
- Comprobación de advertencias y errores en el código fuente al escribir código.
- Al colocar el cursor sobre el código marcado con una bandera, se puede saber si se ha infringido alguna regla.
- Utilice Alt+Intro para aplicar QuickFix al problema.
Spot Bug
El complemento Spot Bugs para IntelliJ utiliza análisis estático para detectar errores en el código.
Puede configurar SpotBugs en la configuración predeterminada de IntelliJ para escanear el código. Las reglas reales utilizadas se pueden encontrar en la pestaña Detector.
Tengo la costumbre de escribir y revisar el código y luego utilizar SpotBugs. A continuación, ejecutaré «Análisis de archivos de proyecto, incluyendo fuentes de prueba».
Esto ayuda a identificar errores, código muerto y optimizaciones evidentes. Además, es necesario investigar algunas de las infracciones denunciadas para ayudar a decidir qué medidas se deben tomar.
SpotBugs detecta problemas, pero no ofrece tareas QuickFix para intentar solucionarlos.
SpotBugs es fácil de configurar y considero que es una segunda opinión objetiva que puedo consultar en mi IDE.
Sona Lint
El complemento Sonar Lint.
En la configuración básica de IntelliJ, puede configurar SonarLint para seleccionar las reglas que verificarán la validez del código.
Básicamente, SonarLint se ejecuta en tiempo real y muestra los problemas del código que se está editando.
SonarLint no ofrece funciones de corrección rápida, pero los informes de infracciones y la documentación relacionada suelen ser claros y estar bien documentados.
SonarLint ha demostrado ser útil para informar sobre las nuevas funciones de Java conocidas en las últimas versiones de Java.
Estilo de verificación
El complemento Check Style ofrece una combinación de reglas de formato y calidad del código.
El complemento Checkstyle se proporciona junto con «Sun Check» y «Google Check».
La definición de estos términos puede ser sencilla. Encontrada en Internet.
CheckStyle aporta el mayor valor añadido cuando el proyecto dedica tiempo a crear su propio conjunto de reglas. De este modo, se puede configurar el complemento IDE para que utilice ese conjunto de reglas y los programadores pueden realizar un escaneo 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.
선생
Utiliza análisis estático basado en AST (árbol sintáctico abstracto) para la coincidencia de códigos de maestro y la generación de QuickFixs, lo que permite identificar el código problemático de forma muy específica.
Al utilizar AST, QuickFixs relacionado con la receta puede comprender el código circundante. Por ejemplo, al añadir una nueva clase al código, la importación de dicha clase solo se añade una vez al archivo fuente y no se añade a cada sustitución.
Sensei está diseñado 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 los archivos de configuración, puede realizar todas las configuraciones en la interfaz gráfica de usuario (GUI). Al crear una nueva receta, la GUI le permite verificar fácilmente el código que coincide con la receta. Además, al definir QuickFixs, puede comparar inmediatamente el estado anterior y posterior del código. Por lo tanto, puede crear fácilmente recetas adaptadas a cada situación (por ejemplo, recetas únicas que solo pueden utilizar equipos, tecnologías o incluso programadores individuales).
Yo 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 resuelven. Un caso de uso habitual de Sensei es replicar las búsquedas coincidentes de otras herramientas en Sensei y ampliarlas con Quick Fix. De esta forma, se obtiene la ventaja de que las correcciones personalizadas aplicadas ya cumplen con los estándares de codificación del proyecto.
A veces creo Sensei que ya están en el conjunto de intenciones de IntelliJ, porque el informe de intenciones no coincide exactamente con el contexto que he creado o porque la corrección rápida que ofrece IntelliJ no coincide con el patrón de código que quiero usar.
Prefiero reforzar las herramientas existentes en lugar de sustituirlas por completo.
Sensei también puede resultar muy útil a la hora de identificar variaciones de las reglas comunes según la situación. Por ejemplo, si se utiliza una biblioteca SQL que no es compatible con las herramientas de análisis estático, pero las reglas SQL generales del motor de análisis estático siguen siendo aplicables, se puede utilizar Sensei para crear una variación de la regla específica para la biblioteca.
Sensei no ofrece tantas recetas generales como las herramientas de análisis estático mencionadas anteriormente. La ventaja de Sensei es que permite crear fácilmente nuevas recetas con QuickFix configuradas para estilos de codificación y casos de uso específicos.
Nota: Estamos desarrollando un repositorio público de recetas para cubrir los casos de uso más comunes. Puede encontrarlo aquí.
Resumen
Tiendo a elegir herramientas que funcionen juntas, sean configurables y se puedan ampliar fácilmente para adaptarse a situaciones específicas. Llevo años utilizando herramientas de análisis estático de IDE que me ayudan a identificar problemas y a conocer en profundidad los lenguajes de programación y las bibliotecas que utilizo.
Utiliza una combinación de todas las herramientas mencionadas anteriormente.
- IntelliJ Intentions ayuda a identificar rápidamente los problemas comunes del código utilizando QuickFix, que suele estar relacionado.
- SpotBugs detecta errores simples que podrían haber pasado desapercibidos y me informa de los problemas de rendimiento.
- SonarLint identifica funciones de Java que yo desconocía y me enseña métodos adicionales para modelar el código.
- Con CheckStyle, puede cumplir con el estilo de codificación acordado que se aplica incluso durante la integración continua.
- Sensei ayuda a crear QuickFixs para complementar los escenarios comunes que se encuentran en las herramientas de análisis estático y crear recetas técnicas o proyectos específicos que son difíciles de configurar con otras herramientas.
---
En IntelliJ, instale Sensei utilizando «Preferencias\Complementos» (Mac) o «Configuración\Complementos» (Windows) y, a continuación, busque «Código de seguridad Sensei».
En la cuenta Secure Code Warrior de Secure Code Warrior , en el proyecto «sensei», encontrará un repositorio con ejemplos de código y recetas para casos de uso comunes.
https://github.com/securecodewarrior/sensei-blog-examples
Descubra el análisis estático y aprenda a escribir mejor código mediante el análisis estático con cinco enfoques basados en IDE y ejemplos de complementos.
Alan Richardson cuenta con más de veinte años de experiencia profesional en TI, trabajando como desarrollador y en todos los niveles de la jerarquía de pruebas, desde probador hasta jefe de pruebas. Jefe de Relaciones con los Desarrolladores en Secure Code Warrior, trabaja directamente con los equipos, para mejorar el desarrollo de un código seguro de calidad. Alan es autor de cuatro libros, entre ellos "Dear Evil Tester" y "Java For Testers". Alan también ha creado una formación en línea courses para ayudar a la gente a aprender las pruebas técnicas de la web y Selenium WebDriver con Java. Alan publica sus escritos y vídeos de formación en SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, y CompendiumDev.co.uk.
Secure Code Warrior está aquí para ayudar a las organizaciones a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura que priorice la ciberseguridad. Ya seas administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudarte a reducir los riesgos asociados al código inseguro en tu organización.
Reserva de demostración
Alan Richardson cuenta con más de veinte años de experiencia profesional en TI, trabajando como desarrollador y en todos los niveles de la jerarquía de pruebas, desde probador hasta jefe de pruebas. Jefe de Relaciones con los Desarrolladores en Secure Code Warrior, trabaja directamente con los equipos, para mejorar el desarrollo de un código seguro de calidad. Alan es autor de cuatro libros, entre ellos "Dear Evil Tester" y "Java For Testers". Alan también ha creado una formación en línea courses para ayudar a la gente a aprender las pruebas técnicas de la web y Selenium WebDriver con Java. Alan publica sus escritos 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 se realiza un análisis durante la ejecución del programa, se denomina análisis dinámico.
El análisis estático se utiliza principalmente para detectar lo siguiente:
- Vulnerabilidad de seguridad.
- Problemas de rendimiento.
- No cumple con los estándares.
- 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 para identificar patrones de codificación específicos que contengan advertencias o información relevantes.
Esto puede ser tan simple como «Las clases de prueba JUnit 5 no tienen por qué ser públicas» o tan complejo de identificar como «Entradas de cadenas no fiables utilizadas en sentencias de ejecución SQL».
Las herramientas de análisis estático implementan esta función de diferentes maneras.
- Técnica de análisis sintáctico del código fuente para generar árboles sintácticos abstractos (AST)
- Coincidencia de expresiones regulares de texto,
- Esta es la combinación.
Las expresiones regulares para el texto son muy flexibles y fáciles de escribir, pero a menudo pueden dar lugar a muchos falsos positivos y las reglas de coincidencia ignoran el contexto del código circundante.
AST Matching trata el código fuente no solo como un archivo lleno de texto, sino también como código de programa, lo que permite una coincidencia más específica y adecuada al contexto, y reduce el número de falsos positivos reportados sobre el código.
Análisis estático en la integración continua
El análisis estático se lleva a cabo a menudo durante el proceso de integración continua (CI) para generar informes sobre problemas de cumplimiento normativo. La revisión de estos informes permite obtener una visión objetiva de la base de código a lo largo del tiempo.
Algunos usuarios configuran las herramientas de análisis estático para que midan solo partes específicas del código y reporten solo sobre un subconjunto de reglas, utilizándolas como una medida objetiva de la calidad del código.
La objetividad está garantizada por las reglas utilizadas, ya que la evaluación del código no cambia con el paso del tiempo. Es evidente que la combinación de las reglas utilizadas y su configuración es una decisión subjetiva, y cada equipo elige utilizar reglas diferentes según el momento.
Realizar análisis estáticos en CI es útil, pero puede retrasar la retroalimentación para los programadores. Los programadores no reciben retroalimentación mientras codifican, sino más tarde, cuando ejecutan el código a través de herramientas de análisis estático. Otro efecto secundario de realizar análisis estáticos en CI es que es fácil ignorar los resultados.
Para que el equipo preste más atención a los resultados del análisis estático, normalmente es posible configurar indicadores de umbral en el proceso de compilación para que la compilación falle cuando se superen dichos indicadores (por ejemplo, el número de reglas activadas).
Análisis estático en IDE
Existen muchos complementos para IDE que ejecutan reglas de análisis estático en el IDE de forma periódica, según sea necesario o cuando se modifica el código, con el fin de obtener comentarios más rápidamente.
Entonces, cuando el programador escribe el código, el IDE puede detectar las infracciones de las reglas y, para que sea más difícil ignorarlas, se pueden configurar las infracciones para que se muestren en el editor como código subrayado.
Personalmente, creo que es una forma útil de mejorar la codificación. Especialmente cuando se trabaja con nuevas bibliotecas que se tratan en herramientas de análisis estático. Aunque puede haber mucho ruido debido a falsos positivos o reglas que no son relevantes. Sin embargo, este problema se resuelve configurando la herramienta de análisis estático para ignorar reglas específicas mediante la realización de pasos adicionales.
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 modificación de las reglas se deja en manos del programador, por lo que este debe comprender la causa de la infracción de las reglas y la forma de corregirla.
Hay muy pocas herramientas de análisis estático que incluyan la capacidad de corregir las infracciones. Esto se debe a que las correcciones suelen depender del equipo, la tecnología utilizada y el estilo de codificación acordado.
Reglas básicas
Cuando las herramientas de análisis estático se proporcionan junto con reglas básicas, puede surgir una falsa confianza en la calidad de las reglas. Es fácil creer que abarcan todos los problemas a los que se puede enfrentar un programador y todas las situaciones en las que deben aplicarse las reglas. A veces, las situaciones en las que deben aplicarse las reglas pueden ser sutiles y difíciles de detectar.
Esperamos que, al utilizar herramientas de análisis estático para investigar más a fondo las reglas y las infracciones, los programadores puedan desarrollar técnicas para detectar y prevenir problemas en el contexto de áreas específicas.
Si el dominio requiere reglas de contexto, es posible que la herramienta de análisis estático no tenga reglas que coincidan con el dominio o la biblioteca, y también puede ser difícil configurar y ampliar la herramienta.
성가심
No hay nada insuperable entre estas «molestias».
- 오탐지
- Falta de modificaciones
- Configuración para ignorar las reglas
- Añadir reglas por contexto
Sin embargo, es lamentable que a menudo se utilice como excusa para no utilizar herramientas de análisis estático, ya que el análisis estático puede resultar muy útil de las siguientes maneras.
- Enfoque mejorado para desarrolladores junior
- Obtención de comentarios rápidos sobre infracciones claras de codificación.
- El programador identifica problemas ambiguos que no ha experimentado anteriormente.
- Haga hincapié en que el programador ha adoptado un enfoque de codificación correcto (si no se han notificado 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 dentro del IDE, ya que así puedo obtener rápidamente comentarios sobre el código.
Esto complementa todos los procesos de revisión de solicitudes de incorporación de cambios y la integración de CI que pueden existir en el proyecto.
Busco herramientas que me den ventaja y trato de mejorar mi flujo de trabajo personal.
Cuando la herramienta se ejecuta en el IDE, es posible que desee cambiar de una herramienta a otra, ya que la interfaz gráfica de usuario y el enfoque de configuración son los mismos.
Las herramientas pueden tener funciones o conjuntos de reglas que se repiten, pero para aprovechar al máximo sus ventajas, se instalan varias herramientas y se aprovechan sus ventajas.
Las herramientas IDE de análisis estático que utilizo activamente al programar son las siguientes:
- Inspección integrada de IntelliJ: patrones de codificación comunes
- Spot Bug - Error común
- Sonarint: patrón de uso general
- Estilo de verificación: patrón de estilo general
- Sensei de Secure Code Warrior Sensei creación de reglas personalizadas
Se complementan y refuerzan mutuamente, por lo que se utilizan todos.
Inspección IntelliJ
Si utiliza IntelliJ, ya está utilizando esta comprobación.
Se trata de reglas de análisis estático marcadas en el IDE. Algunas de ellas incluyen la opción QuickFix, que permite reescribir el código para resolver el problema.
Se pueden establecer o desactivar reglas y seleccionar el nivel de error que se utilizará para resaltar en el IDE.
Hay muchas funciones de inspección excelentes en IntelliJ. Lo sé porque he leído todo el contenido mientras escribía este artículo. Utilizo IntelliJ Inspections como valor predeterminado y aún no lo he configurado. Sin embargo, para aprovechar al máximo la inspección, es necesario leerla detenidamente, identificar los elementos relacionados con el estilo de programación propio y configurar el nivel de advertencia para poder verificarlo en el código.
Lo bueno de IntelliJ Inspecing es que se ofrece de forma gratuita junto con el IDE y ayuda a desarrollar la siguiente memoria muscular.
- Comprobación de advertencias y errores en el código fuente al escribir código.
- Al colocar el cursor sobre el código marcado con una bandera, se puede saber si se ha infringido alguna regla.
- Utilice Alt+Intro para aplicar QuickFix al problema.
Spot Bug
El complemento Spot Bugs para IntelliJ utiliza análisis estático para detectar errores en el código.
Puede configurar SpotBugs en la configuración predeterminada de IntelliJ para escanear el código. Las reglas reales utilizadas se pueden encontrar en la pestaña Detector.
Tengo la costumbre de escribir y revisar el código y luego utilizar SpotBugs. A continuación, ejecutaré «Análisis de archivos de proyecto, incluyendo fuentes de prueba».
Esto ayuda a identificar errores, código muerto y optimizaciones evidentes. Además, es necesario investigar algunas de las infracciones denunciadas para ayudar a decidir qué medidas se deben tomar.
SpotBugs detecta problemas, pero no ofrece tareas QuickFix para intentar solucionarlos.
SpotBugs es fácil de configurar y considero que es una segunda opinión objetiva que puedo consultar en mi IDE.
Sona Lint
El complemento Sonar Lint.
En la configuración básica de IntelliJ, puede configurar SonarLint para seleccionar las reglas que verificarán la validez del código.
Básicamente, SonarLint se ejecuta en tiempo real y muestra los problemas del código que se está editando.
SonarLint no ofrece funciones de corrección rápida, pero los informes de infracciones y la documentación relacionada suelen ser claros y estar bien documentados.
SonarLint ha demostrado ser útil para informar sobre las nuevas funciones de Java conocidas en las últimas versiones de Java.
Estilo de verificación
El complemento Check Style ofrece una combinación de reglas de formato y calidad del código.
El complemento Checkstyle se proporciona junto con «Sun Check» y «Google Check».
La definición de estos términos puede ser sencilla. Encontrada en Internet.
CheckStyle aporta el mayor valor añadido cuando el proyecto dedica tiempo a crear su propio conjunto de reglas. De este modo, se puede configurar el complemento IDE para que utilice ese conjunto de reglas y los programadores pueden realizar un escaneo 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.
선생
Utiliza análisis estático basado en AST (árbol sintáctico abstracto) para la coincidencia de códigos de maestro y la generación de QuickFixs, lo que permite identificar el código problemático de forma muy específica.
Al utilizar AST, QuickFixs relacionado con la receta puede comprender el código circundante. Por ejemplo, al añadir una nueva clase al código, la importación de dicha clase solo se añade una vez al archivo fuente y no se añade a cada sustitución.
Sensei está diseñado 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 los archivos de configuración, puede realizar todas las configuraciones en la interfaz gráfica de usuario (GUI). Al crear una nueva receta, la GUI le permite verificar fácilmente el código que coincide con la receta. Además, al definir QuickFixs, puede comparar inmediatamente el estado anterior y posterior del código. Por lo tanto, puede crear fácilmente recetas adaptadas a cada situación (por ejemplo, recetas únicas que solo pueden utilizar equipos, tecnologías o incluso programadores individuales).
Yo 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 resuelven. Un caso de uso habitual de Sensei es replicar las búsquedas coincidentes de otras herramientas en Sensei y ampliarlas con Quick Fix. De esta forma, se obtiene la ventaja de que las correcciones personalizadas aplicadas ya cumplen con los estándares de codificación del proyecto.
A veces creo Sensei que ya están en el conjunto de intenciones de IntelliJ, porque el informe de intenciones no coincide exactamente con el contexto que he creado o porque la corrección rápida que ofrece IntelliJ no coincide con el patrón de código que quiero usar.
Prefiero reforzar las herramientas existentes en lugar de sustituirlas por completo.
Sensei también puede resultar muy útil a la hora de identificar variaciones de las reglas comunes según la situación. Por ejemplo, si se utiliza una biblioteca SQL que no es compatible con las herramientas de análisis estático, pero las reglas SQL generales del motor de análisis estático siguen siendo aplicables, se puede utilizar Sensei para crear una variación de la regla específica para la biblioteca.
Sensei no ofrece tantas recetas generales como las herramientas de análisis estático mencionadas anteriormente. La ventaja de Sensei es que permite crear fácilmente nuevas recetas con QuickFix configuradas para estilos de codificación y casos de uso específicos.
Nota: Estamos desarrollando un repositorio público de recetas para cubrir los casos de uso más comunes. Puede encontrarlo aquí.
Resumen
Tiendo a elegir herramientas que funcionen juntas, sean configurables y se puedan ampliar fácilmente para adaptarse a situaciones específicas. Llevo años utilizando herramientas de análisis estático de IDE que me ayudan a identificar problemas y a conocer en profundidad los lenguajes de programación y las bibliotecas que utilizo.
Utiliza una combinación de todas las herramientas mencionadas anteriormente.
- IntelliJ Intentions ayuda a identificar rápidamente los problemas comunes del código utilizando QuickFix, que suele estar relacionado.
- SpotBugs detecta errores simples que podrían haber pasado desapercibidos y me informa de los problemas de rendimiento.
- SonarLint identifica funciones de Java que yo desconocía y me enseña métodos adicionales para modelar el código.
- Con CheckStyle, puede cumplir con el estilo de codificación acordado que se aplica incluso durante la integración continua.
- Sensei ayuda a crear QuickFixs para complementar los escenarios comunes que se encuentran en las herramientas de análisis estático y crear recetas técnicas o proyectos específicos que son difíciles de configurar con otras herramientas.
---
En IntelliJ, instale Sensei utilizando «Preferencias\Complementos» (Mac) o «Configuración\Complementos» (Windows) y, a continuación, busque «Código de seguridad Sensei».
En la cuenta Secure Code Warrior de Secure Code Warrior , en el proyecto «sensei», encontrará un repositorio con ejemplos de código y recetas para casos de uso comunes.
https://github.com/securecodewarrior/sensei-blog-examples
¿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 se realiza un análisis durante la ejecución del programa, se denomina análisis dinámico.
El análisis estático se utiliza principalmente para detectar lo siguiente:
- Vulnerabilidad de seguridad.
- Problemas de rendimiento.
- No cumple con los estándares.
- 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 para identificar patrones de codificación específicos que contengan advertencias o información relevantes.
Esto puede ser tan simple como «Las clases de prueba JUnit 5 no tienen por qué ser públicas» o tan complejo de identificar como «Entradas de cadenas no fiables utilizadas en sentencias de ejecución SQL».
Las herramientas de análisis estático implementan esta función de diferentes maneras.
- Técnica de análisis sintáctico del código fuente para generar árboles sintácticos abstractos (AST)
- Coincidencia de expresiones regulares de texto,
- Esta es la combinación.
Las expresiones regulares para el texto son muy flexibles y fáciles de escribir, pero a menudo pueden dar lugar a muchos falsos positivos y las reglas de coincidencia ignoran el contexto del código circundante.
AST Matching trata el código fuente no solo como un archivo lleno de texto, sino también como código de programa, lo que permite una coincidencia más específica y adecuada al contexto, y reduce el número de falsos positivos reportados sobre el código.
Análisis estático en la integración continua
El análisis estático se lleva a cabo a menudo durante el proceso de integración continua (CI) para generar informes sobre problemas de cumplimiento normativo. La revisión de estos informes permite obtener una visión objetiva de la base de código a lo largo del tiempo.
Algunos usuarios configuran las herramientas de análisis estático para que midan solo partes específicas del código y reporten solo sobre un subconjunto de reglas, utilizándolas como una medida objetiva de la calidad del código.
La objetividad está garantizada por las reglas utilizadas, ya que la evaluación del código no cambia con el paso del tiempo. Es evidente que la combinación de las reglas utilizadas y su configuración es una decisión subjetiva, y cada equipo elige utilizar reglas diferentes según el momento.
Realizar análisis estáticos en CI es útil, pero puede retrasar la retroalimentación para los programadores. Los programadores no reciben retroalimentación mientras codifican, sino más tarde, cuando ejecutan el código a través de herramientas de análisis estático. Otro efecto secundario de realizar análisis estáticos en CI es que es fácil ignorar los resultados.
Para que el equipo preste más atención a los resultados del análisis estático, normalmente es posible configurar indicadores de umbral en el proceso de compilación para que la compilación falle cuando se superen dichos indicadores (por ejemplo, el número de reglas activadas).
Análisis estático en IDE
Existen muchos complementos para IDE que ejecutan reglas de análisis estático en el IDE de forma periódica, según sea necesario o cuando se modifica el código, con el fin de obtener comentarios más rápidamente.
Entonces, cuando el programador escribe el código, el IDE puede detectar las infracciones de las reglas y, para que sea más difícil ignorarlas, se pueden configurar las infracciones para que se muestren en el editor como código subrayado.
Personalmente, creo que es una forma útil de mejorar la codificación. Especialmente cuando se trabaja con nuevas bibliotecas que se tratan en herramientas de análisis estático. Aunque puede haber mucho ruido debido a falsos positivos o reglas que no son relevantes. Sin embargo, este problema se resuelve configurando la herramienta de análisis estático para ignorar reglas específicas mediante la realización de pasos adicionales.
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 modificación de las reglas se deja en manos del programador, por lo que este debe comprender la causa de la infracción de las reglas y la forma de corregirla.
Hay muy pocas herramientas de análisis estático que incluyan la capacidad de corregir las infracciones. Esto se debe a que las correcciones suelen depender del equipo, la tecnología utilizada y el estilo de codificación acordado.
Reglas básicas
Cuando las herramientas de análisis estático se proporcionan junto con reglas básicas, puede surgir una falsa confianza en la calidad de las reglas. Es fácil creer que abarcan todos los problemas a los que se puede enfrentar un programador y todas las situaciones en las que deben aplicarse las reglas. A veces, las situaciones en las que deben aplicarse las reglas pueden ser sutiles y difíciles de detectar.
Esperamos que, al utilizar herramientas de análisis estático para investigar más a fondo las reglas y las infracciones, los programadores puedan desarrollar técnicas para detectar y prevenir problemas en el contexto de áreas específicas.
Si el dominio requiere reglas de contexto, es posible que la herramienta de análisis estático no tenga reglas que coincidan con el dominio o la biblioteca, y también puede ser difícil configurar y ampliar la herramienta.
성가심
No hay nada insuperable entre estas «molestias».
- 오탐지
- Falta de modificaciones
- Configuración para ignorar las reglas
- Añadir reglas por contexto
Sin embargo, es lamentable que a menudo se utilice como excusa para no utilizar herramientas de análisis estático, ya que el análisis estático puede resultar muy útil de las siguientes maneras.
- Enfoque mejorado para desarrolladores junior
- Obtención de comentarios rápidos sobre infracciones claras de codificación.
- El programador identifica problemas ambiguos que no ha experimentado anteriormente.
- Haga hincapié en que el programador ha adoptado un enfoque de codificación correcto (si no se han notificado 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 dentro del IDE, ya que así puedo obtener rápidamente comentarios sobre el código.
Esto complementa todos los procesos de revisión de solicitudes de incorporación de cambios y la integración de CI que pueden existir en el proyecto.
Busco herramientas que me den ventaja y trato de mejorar mi flujo de trabajo personal.
Cuando la herramienta se ejecuta en el IDE, es posible que desee cambiar de una herramienta a otra, ya que la interfaz gráfica de usuario y el enfoque de configuración son los mismos.
Las herramientas pueden tener funciones o conjuntos de reglas que se repiten, pero para aprovechar al máximo sus ventajas, se instalan varias herramientas y se aprovechan sus ventajas.
Las herramientas IDE de análisis estático que utilizo activamente al programar son las siguientes:
- Inspección integrada de IntelliJ: patrones de codificación comunes
- Spot Bug - Error común
- Sonarint: patrón de uso general
- Estilo de verificación: patrón de estilo general
- Sensei de Secure Code Warrior Sensei creación de reglas personalizadas
Se complementan y refuerzan mutuamente, por lo que se utilizan todos.
Inspección IntelliJ
Si utiliza IntelliJ, ya está utilizando esta comprobación.
Se trata de reglas de análisis estático marcadas en el IDE. Algunas de ellas incluyen la opción QuickFix, que permite reescribir el código para resolver el problema.
Se pueden establecer o desactivar reglas y seleccionar el nivel de error que se utilizará para resaltar en el IDE.
Hay muchas funciones de inspección excelentes en IntelliJ. Lo sé porque he leído todo el contenido mientras escribía este artículo. Utilizo IntelliJ Inspections como valor predeterminado y aún no lo he configurado. Sin embargo, para aprovechar al máximo la inspección, es necesario leerla detenidamente, identificar los elementos relacionados con el estilo de programación propio y configurar el nivel de advertencia para poder verificarlo en el código.
Lo bueno de IntelliJ Inspecing es que se ofrece de forma gratuita junto con el IDE y ayuda a desarrollar la siguiente memoria muscular.
- Comprobación de advertencias y errores en el código fuente al escribir código.
- Al colocar el cursor sobre el código marcado con una bandera, se puede saber si se ha infringido alguna regla.
- Utilice Alt+Intro para aplicar QuickFix al problema.
Spot Bug
El complemento Spot Bugs para IntelliJ utiliza análisis estático para detectar errores en el código.
Puede configurar SpotBugs en la configuración predeterminada de IntelliJ para escanear el código. Las reglas reales utilizadas se pueden encontrar en la pestaña Detector.
Tengo la costumbre de escribir y revisar el código y luego utilizar SpotBugs. A continuación, ejecutaré «Análisis de archivos de proyecto, incluyendo fuentes de prueba».
Esto ayuda a identificar errores, código muerto y optimizaciones evidentes. Además, es necesario investigar algunas de las infracciones denunciadas para ayudar a decidir qué medidas se deben tomar.
SpotBugs detecta problemas, pero no ofrece tareas QuickFix para intentar solucionarlos.
SpotBugs es fácil de configurar y considero que es una segunda opinión objetiva que puedo consultar en mi IDE.
Sona Lint
El complemento Sonar Lint.
En la configuración básica de IntelliJ, puede configurar SonarLint para seleccionar las reglas que verificarán la validez del código.
Básicamente, SonarLint se ejecuta en tiempo real y muestra los problemas del código que se está editando.
SonarLint no ofrece funciones de corrección rápida, pero los informes de infracciones y la documentación relacionada suelen ser claros y estar bien documentados.
SonarLint ha demostrado ser útil para informar sobre las nuevas funciones de Java conocidas en las últimas versiones de Java.
Estilo de verificación
El complemento Check Style ofrece una combinación de reglas de formato y calidad del código.
El complemento Checkstyle se proporciona junto con «Sun Check» y «Google Check».
La definición de estos términos puede ser sencilla. Encontrada en Internet.
CheckStyle aporta el mayor valor añadido cuando el proyecto dedica tiempo a crear su propio conjunto de reglas. De este modo, se puede configurar el complemento IDE para que utilice ese conjunto de reglas y los programadores pueden realizar un escaneo 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.
선생
Utiliza análisis estático basado en AST (árbol sintáctico abstracto) para la coincidencia de códigos de maestro y la generación de QuickFixs, lo que permite identificar el código problemático de forma muy específica.
Al utilizar AST, QuickFixs relacionado con la receta puede comprender el código circundante. Por ejemplo, al añadir una nueva clase al código, la importación de dicha clase solo se añade una vez al archivo fuente y no se añade a cada sustitución.
Sensei está diseñado 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 los archivos de configuración, puede realizar todas las configuraciones en la interfaz gráfica de usuario (GUI). Al crear una nueva receta, la GUI le permite verificar fácilmente el código que coincide con la receta. Además, al definir QuickFixs, puede comparar inmediatamente el estado anterior y posterior del código. Por lo tanto, puede crear fácilmente recetas adaptadas a cada situación (por ejemplo, recetas únicas que solo pueden utilizar equipos, tecnologías o incluso programadores individuales).
Yo 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 resuelven. Un caso de uso habitual de Sensei es replicar las búsquedas coincidentes de otras herramientas en Sensei y ampliarlas con Quick Fix. De esta forma, se obtiene la ventaja de que las correcciones personalizadas aplicadas ya cumplen con los estándares de codificación del proyecto.
A veces creo Sensei que ya están en el conjunto de intenciones de IntelliJ, porque el informe de intenciones no coincide exactamente con el contexto que he creado o porque la corrección rápida que ofrece IntelliJ no coincide con el patrón de código que quiero usar.
Prefiero reforzar las herramientas existentes en lugar de sustituirlas por completo.
Sensei también puede resultar muy útil a la hora de identificar variaciones de las reglas comunes según la situación. Por ejemplo, si se utiliza una biblioteca SQL que no es compatible con las herramientas de análisis estático, pero las reglas SQL generales del motor de análisis estático siguen siendo aplicables, se puede utilizar Sensei para crear una variación de la regla específica para la biblioteca.
Sensei no ofrece tantas recetas generales como las herramientas de análisis estático mencionadas anteriormente. La ventaja de Sensei es que permite crear fácilmente nuevas recetas con QuickFix configuradas para estilos de codificación y casos de uso específicos.
Nota: Estamos desarrollando un repositorio público de recetas para cubrir los casos de uso más comunes. Puede encontrarlo aquí.
Resumen
Tiendo a elegir herramientas que funcionen juntas, sean configurables y se puedan ampliar fácilmente para adaptarse a situaciones específicas. Llevo años utilizando herramientas de análisis estático de IDE que me ayudan a identificar problemas y a conocer en profundidad los lenguajes de programación y las bibliotecas que utilizo.
Utiliza una combinación de todas las herramientas mencionadas anteriormente.
- IntelliJ Intentions ayuda a identificar rápidamente los problemas comunes del código utilizando QuickFix, que suele estar relacionado.
- SpotBugs detecta errores simples que podrían haber pasado desapercibidos y me informa de los problemas de rendimiento.
- SonarLint identifica funciones de Java que yo desconocía y me enseña métodos adicionales para modelar el código.
- Con CheckStyle, puede cumplir con el estilo de codificación acordado que se aplica incluso durante la integración continua.
- Sensei ayuda a crear QuickFixs para complementar los escenarios comunes que se encuentran en las herramientas de análisis estático y crear recetas técnicas o proyectos específicos que son difíciles de configurar con otras herramientas.
---
En IntelliJ, instale Sensei utilizando «Preferencias\Complementos» (Mac) o «Configuración\Complementos» (Windows) y, a continuación, busque «Código de seguridad Sensei».
En la cuenta Secure Code Warrior de Secure Code Warrior , en el proyecto «sensei», encontrará un repositorio con ejemplos de código y recetas para casos de uso comunes.
https://github.com/securecodewarrior/sensei-blog-examples
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está aquí para ayudar a las organizaciones a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura que priorice la ciberseguridad. Ya seas administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudarte a reducir los riesgos asociados al código inseguro en tu organización.
Ver informeReserva de demostración
Alan Richardson cuenta con más de veinte años de experiencia profesional en TI, trabajando como desarrollador y en todos los niveles de la jerarquía de pruebas, desde probador hasta jefe de pruebas. Jefe de Relaciones con los Desarrolladores en Secure Code Warrior, trabaja directamente con los equipos, para mejorar el desarrollo de un código seguro de calidad. Alan es autor de cuatro libros, entre ellos "Dear Evil Tester" y "Java For Testers". Alan también ha creado una formación en línea courses para ayudar a la gente a aprender las pruebas técnicas de la web y Selenium WebDriver con Java. Alan publica sus escritos 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 se realiza un análisis durante la ejecución del programa, se denomina análisis dinámico.
El análisis estático se utiliza principalmente para detectar lo siguiente:
- Vulnerabilidad de seguridad.
- Problemas de rendimiento.
- No cumple con los estándares.
- 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 para identificar patrones de codificación específicos que contengan advertencias o información relevantes.
Esto puede ser tan simple como «Las clases de prueba JUnit 5 no tienen por qué ser públicas» o tan complejo de identificar como «Entradas de cadenas no fiables utilizadas en sentencias de ejecución SQL».
Las herramientas de análisis estático implementan esta función de diferentes maneras.
- Técnica de análisis sintáctico del código fuente para generar árboles sintácticos abstractos (AST)
- Coincidencia de expresiones regulares de texto,
- Esta es la combinación.
Las expresiones regulares para el texto son muy flexibles y fáciles de escribir, pero a menudo pueden dar lugar a muchos falsos positivos y las reglas de coincidencia ignoran el contexto del código circundante.
AST Matching trata el código fuente no solo como un archivo lleno de texto, sino también como código de programa, lo que permite una coincidencia más específica y adecuada al contexto, y reduce el número de falsos positivos reportados sobre el código.
Análisis estático en la integración continua
El análisis estático se lleva a cabo a menudo durante el proceso de integración continua (CI) para generar informes sobre problemas de cumplimiento normativo. La revisión de estos informes permite obtener una visión objetiva de la base de código a lo largo del tiempo.
Algunos usuarios configuran las herramientas de análisis estático para que midan solo partes específicas del código y reporten solo sobre un subconjunto de reglas, utilizándolas como una medida objetiva de la calidad del código.
La objetividad está garantizada por las reglas utilizadas, ya que la evaluación del código no cambia con el paso del tiempo. Es evidente que la combinación de las reglas utilizadas y su configuración es una decisión subjetiva, y cada equipo elige utilizar reglas diferentes según el momento.
Realizar análisis estáticos en CI es útil, pero puede retrasar la retroalimentación para los programadores. Los programadores no reciben retroalimentación mientras codifican, sino más tarde, cuando ejecutan el código a través de herramientas de análisis estático. Otro efecto secundario de realizar análisis estáticos en CI es que es fácil ignorar los resultados.
Para que el equipo preste más atención a los resultados del análisis estático, normalmente es posible configurar indicadores de umbral en el proceso de compilación para que la compilación falle cuando se superen dichos indicadores (por ejemplo, el número de reglas activadas).
Análisis estático en IDE
Existen muchos complementos para IDE que ejecutan reglas de análisis estático en el IDE de forma periódica, según sea necesario o cuando se modifica el código, con el fin de obtener comentarios más rápidamente.
Entonces, cuando el programador escribe el código, el IDE puede detectar las infracciones de las reglas y, para que sea más difícil ignorarlas, se pueden configurar las infracciones para que se muestren en el editor como código subrayado.
Personalmente, creo que es una forma útil de mejorar la codificación. Especialmente cuando se trabaja con nuevas bibliotecas que se tratan en herramientas de análisis estático. Aunque puede haber mucho ruido debido a falsos positivos o reglas que no son relevantes. Sin embargo, este problema se resuelve configurando la herramienta de análisis estático para ignorar reglas específicas mediante la realización de pasos adicionales.
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 modificación de las reglas se deja en manos del programador, por lo que este debe comprender la causa de la infracción de las reglas y la forma de corregirla.
Hay muy pocas herramientas de análisis estático que incluyan la capacidad de corregir las infracciones. Esto se debe a que las correcciones suelen depender del equipo, la tecnología utilizada y el estilo de codificación acordado.
Reglas básicas
Cuando las herramientas de análisis estático se proporcionan junto con reglas básicas, puede surgir una falsa confianza en la calidad de las reglas. Es fácil creer que abarcan todos los problemas a los que se puede enfrentar un programador y todas las situaciones en las que deben aplicarse las reglas. A veces, las situaciones en las que deben aplicarse las reglas pueden ser sutiles y difíciles de detectar.
Esperamos que, al utilizar herramientas de análisis estático para investigar más a fondo las reglas y las infracciones, los programadores puedan desarrollar técnicas para detectar y prevenir problemas en el contexto de áreas específicas.
Si el dominio requiere reglas de contexto, es posible que la herramienta de análisis estático no tenga reglas que coincidan con el dominio o la biblioteca, y también puede ser difícil configurar y ampliar la herramienta.
성가심
No hay nada insuperable entre estas «molestias».
- 오탐지
- Falta de modificaciones
- Configuración para ignorar las reglas
- Añadir reglas por contexto
Sin embargo, es lamentable que a menudo se utilice como excusa para no utilizar herramientas de análisis estático, ya que el análisis estático puede resultar muy útil de las siguientes maneras.
- Enfoque mejorado para desarrolladores junior
- Obtención de comentarios rápidos sobre infracciones claras de codificación.
- El programador identifica problemas ambiguos que no ha experimentado anteriormente.
- Haga hincapié en que el programador ha adoptado un enfoque de codificación correcto (si no se han notificado 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 dentro del IDE, ya que así puedo obtener rápidamente comentarios sobre el código.
Esto complementa todos los procesos de revisión de solicitudes de incorporación de cambios y la integración de CI que pueden existir en el proyecto.
Busco herramientas que me den ventaja y trato de mejorar mi flujo de trabajo personal.
Cuando la herramienta se ejecuta en el IDE, es posible que desee cambiar de una herramienta a otra, ya que la interfaz gráfica de usuario y el enfoque de configuración son los mismos.
Las herramientas pueden tener funciones o conjuntos de reglas que se repiten, pero para aprovechar al máximo sus ventajas, se instalan varias herramientas y se aprovechan sus ventajas.
Las herramientas IDE de análisis estático que utilizo activamente al programar son las siguientes:
- Inspección integrada de IntelliJ: patrones de codificación comunes
- Spot Bug - Error común
- Sonarint: patrón de uso general
- Estilo de verificación: patrón de estilo general
- Sensei de Secure Code Warrior Sensei creación de reglas personalizadas
Se complementan y refuerzan mutuamente, por lo que se utilizan todos.
Inspección IntelliJ
Si utiliza IntelliJ, ya está utilizando esta comprobación.
Se trata de reglas de análisis estático marcadas en el IDE. Algunas de ellas incluyen la opción QuickFix, que permite reescribir el código para resolver el problema.
Se pueden establecer o desactivar reglas y seleccionar el nivel de error que se utilizará para resaltar en el IDE.
Hay muchas funciones de inspección excelentes en IntelliJ. Lo sé porque he leído todo el contenido mientras escribía este artículo. Utilizo IntelliJ Inspections como valor predeterminado y aún no lo he configurado. Sin embargo, para aprovechar al máximo la inspección, es necesario leerla detenidamente, identificar los elementos relacionados con el estilo de programación propio y configurar el nivel de advertencia para poder verificarlo en el código.
Lo bueno de IntelliJ Inspecing es que se ofrece de forma gratuita junto con el IDE y ayuda a desarrollar la siguiente memoria muscular.
- Comprobación de advertencias y errores en el código fuente al escribir código.
- Al colocar el cursor sobre el código marcado con una bandera, se puede saber si se ha infringido alguna regla.
- Utilice Alt+Intro para aplicar QuickFix al problema.
Spot Bug
El complemento Spot Bugs para IntelliJ utiliza análisis estático para detectar errores en el código.
Puede configurar SpotBugs en la configuración predeterminada de IntelliJ para escanear el código. Las reglas reales utilizadas se pueden encontrar en la pestaña Detector.
Tengo la costumbre de escribir y revisar el código y luego utilizar SpotBugs. A continuación, ejecutaré «Análisis de archivos de proyecto, incluyendo fuentes de prueba».
Esto ayuda a identificar errores, código muerto y optimizaciones evidentes. Además, es necesario investigar algunas de las infracciones denunciadas para ayudar a decidir qué medidas se deben tomar.
SpotBugs detecta problemas, pero no ofrece tareas QuickFix para intentar solucionarlos.
SpotBugs es fácil de configurar y considero que es una segunda opinión objetiva que puedo consultar en mi IDE.
Sona Lint
El complemento Sonar Lint.
En la configuración básica de IntelliJ, puede configurar SonarLint para seleccionar las reglas que verificarán la validez del código.
Básicamente, SonarLint se ejecuta en tiempo real y muestra los problemas del código que se está editando.
SonarLint no ofrece funciones de corrección rápida, pero los informes de infracciones y la documentación relacionada suelen ser claros y estar bien documentados.
SonarLint ha demostrado ser útil para informar sobre las nuevas funciones de Java conocidas en las últimas versiones de Java.
Estilo de verificación
El complemento Check Style ofrece una combinación de reglas de formato y calidad del código.
El complemento Checkstyle se proporciona junto con «Sun Check» y «Google Check».
La definición de estos términos puede ser sencilla. Encontrada en Internet.
CheckStyle aporta el mayor valor añadido cuando el proyecto dedica tiempo a crear su propio conjunto de reglas. De este modo, se puede configurar el complemento IDE para que utilice ese conjunto de reglas y los programadores pueden realizar un escaneo 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.
선생
Utiliza análisis estático basado en AST (árbol sintáctico abstracto) para la coincidencia de códigos de maestro y la generación de QuickFixs, lo que permite identificar el código problemático de forma muy específica.
Al utilizar AST, QuickFixs relacionado con la receta puede comprender el código circundante. Por ejemplo, al añadir una nueva clase al código, la importación de dicha clase solo se añade una vez al archivo fuente y no se añade a cada sustitución.
Sensei está diseñado 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 los archivos de configuración, puede realizar todas las configuraciones en la interfaz gráfica de usuario (GUI). Al crear una nueva receta, la GUI le permite verificar fácilmente el código que coincide con la receta. Además, al definir QuickFixs, puede comparar inmediatamente el estado anterior y posterior del código. Por lo tanto, puede crear fácilmente recetas adaptadas a cada situación (por ejemplo, recetas únicas que solo pueden utilizar equipos, tecnologías o incluso programadores individuales).
Yo 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 resuelven. Un caso de uso habitual de Sensei es replicar las búsquedas coincidentes de otras herramientas en Sensei y ampliarlas con Quick Fix. De esta forma, se obtiene la ventaja de que las correcciones personalizadas aplicadas ya cumplen con los estándares de codificación del proyecto.
A veces creo Sensei que ya están en el conjunto de intenciones de IntelliJ, porque el informe de intenciones no coincide exactamente con el contexto que he creado o porque la corrección rápida que ofrece IntelliJ no coincide con el patrón de código que quiero usar.
Prefiero reforzar las herramientas existentes en lugar de sustituirlas por completo.
Sensei también puede resultar muy útil a la hora de identificar variaciones de las reglas comunes según la situación. Por ejemplo, si se utiliza una biblioteca SQL que no es compatible con las herramientas de análisis estático, pero las reglas SQL generales del motor de análisis estático siguen siendo aplicables, se puede utilizar Sensei para crear una variación de la regla específica para la biblioteca.
Sensei no ofrece tantas recetas generales como las herramientas de análisis estático mencionadas anteriormente. La ventaja de Sensei es que permite crear fácilmente nuevas recetas con QuickFix configuradas para estilos de codificación y casos de uso específicos.
Nota: Estamos desarrollando un repositorio público de recetas para cubrir los casos de uso más comunes. Puede encontrarlo aquí.
Resumen
Tiendo a elegir herramientas que funcionen juntas, sean configurables y se puedan ampliar fácilmente para adaptarse a situaciones específicas. Llevo años utilizando herramientas de análisis estático de IDE que me ayudan a identificar problemas y a conocer en profundidad los lenguajes de programación y las bibliotecas que utilizo.
Utiliza una combinación de todas las herramientas mencionadas anteriormente.
- IntelliJ Intentions ayuda a identificar rápidamente los problemas comunes del código utilizando QuickFix, que suele estar relacionado.
- SpotBugs detecta errores simples que podrían haber pasado desapercibidos y me informa de los problemas de rendimiento.
- SonarLint identifica funciones de Java que yo desconocía y me enseña métodos adicionales para modelar el código.
- Con CheckStyle, puede cumplir con el estilo de codificación acordado que se aplica incluso durante la integración continua.
- Sensei ayuda a crear QuickFixs para complementar los escenarios comunes que se encuentran en las herramientas de análisis estático y crear recetas técnicas o proyectos específicos que son difíciles de configurar con otras herramientas.
---
En IntelliJ, instale Sensei utilizando «Preferencias\Complementos» (Mac) o «Configuración\Complementos» (Windows) y, a continuación, busque «Código de seguridad Sensei».
En la cuenta Secure Code Warrior de Secure Code Warrior , en el proyecto «sensei», encontrará un repositorio con ejemplos de código y recetas para casos de uso comunes.
https://github.com/securecodewarrior/sensei-blog-examples
Índice
Alan Richardson cuenta con más de veinte años de experiencia profesional en TI, trabajando como desarrollador y en todos los niveles de la jerarquía de pruebas, desde probador hasta jefe de pruebas. Jefe de Relaciones con los Desarrolladores en Secure Code Warrior, trabaja directamente con los equipos, para mejorar el desarrollo de un código seguro de calidad. Alan es autor de cuatro libros, entre ellos "Dear Evil Tester" y "Java For Testers". Alan también ha creado una formación en línea courses para ayudar a la gente a aprender las pruebas técnicas de la web y Selenium WebDriver con Java. Alan publica sus escritos y vídeos de formación en SeleniumSimplified.com, EvilTester.com, JavaForTesters.com, y CompendiumDev.co.uk.
Secure Code Warrior está aquí para ayudar a las organizaciones a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura que priorice la ciberseguridad. Ya seas administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudarte a reducir los riesgos asociados al código inseguro en tu organización.
Reserva de demostraciónDescargarRecursos útiles para empezar
Temas y contenidos de la formación sobre códigos de seguridad
El mejor contenido del sector evoluciona constantemente para adaptarse al entorno de desarrollo de software en constante cambio, teniendo en cuenta el papel de los clientes. Se ofrecen temas que abarcan desde la inteligencia artificial hasta la inyección de XQuery, para diversas funciones, desde arquitectos e ingenieros hasta gestores de productos y control de calidad. Eche un vistazo al contenido que ofrece el catálogo 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 útiles para empezar
Cybermon ha vuelto: la misión de IA para derrotar al jefe ahora está disponible bajo demanda.
Cybermon 2025 Bit the Boss ya está disponible en SCW durante todo el año. Implemente tareas de seguridad avanzadas de IA/LLM para impulsar el desarrollo de IA de seguridad a gran escala.
Explicación de la Ley de Resiliencia Cibernética: El significado del diseño de seguridad en el desarrollo de software
Descubra los requisitos y el ámbito de aplicación de la Ley de Resiliencia Cibernética (CRA) de la UE, y cómo el equipo de ingeniería puede prepararse de forma segura mediante el diseño, las prácticas, la prevención de vulnerabilidades y la creación de un entorno de desarrollo.
Factor de éxito 1: Criterios de éxito definidos y medibles
El habilitador 1 ofrece una serie de 10 partes sobre los habilitadores del éxito, mostrando cómo la codificación segura puede mejorar los resultados empresariales, como la reducción de riesgos y costes y la aceleración de la madurez de los programas a largo plazo.
