Ejecución de inspecciones de IntelliJ desde la integración continua
Ejecución de inspecciones de IntelliJ desde la integración continua
IntelliJ IDEA ofrece funcionalidad para ayudar a mejorar nuestra codificación, dentro del IDE al escribir código como Intenciones. Las Intenciones pueden ser usadas en lote para inspeccionar el código en busca de patrones a lo largo de la fuente e incluso extenderse al análisis de la Línea de Comandos o añadirse a la Integración Continua. Este post cubre la funcionalidad fuera de la caja de IntelliJ y la expansión con Intenciones personalizadas creadas en Sensei.
Inspecciones de IntelliJ
La función de Inspecciones de IntelliJ impulsa la visualización de muchos de los errores que se informan dinámicamente en el IDE cuando se codifica, por ejemplo
- detectar las clases abstractas que pueden convertirse en interfaces,
- identificar los campos de clase redundantes que pueden ser locales,
- advertencia sobre el uso de métodos obsoletos,
- etc.
Estas inspecciones resaltan el código que coincide en el IDE como Acciones de Intención que a menudo tienen un QuickFix asociado.

El resaltado del IDE en tiempo real cuando el código coincide con una Inspección puede ayudarnos a mejorar nuestra codificación de forma dinámica. Después de identificar el problema en el código, el uso de IntelliJ Intention Actions para QuickFix el código puede reforzar mejores patrones.
Perfil de las inspecciones
Las inspecciones pueden ejecutarse por lotes desde el IDE, y desde la línea de comandos o en un proceso de integración continua.
La clave para trabajar con las inspecciones de IntelliJ como un lote es mediante el uso de un Perfil de Inspección.
IntelliJ tiene dos perfiles de inspección por defecto: uno almacenado en el proyecto, y otro almacenado en el IDE.
Se pueden crear nuevos perfiles de inspección para configurar plugins o casos de uso específicos, por ejemplo
- Ejecutar sólo el escaneo en tiempo real de Checkstyle
- Ejecutar un conjunto específico de reglas de Sensei
- Ejecutar las comprobaciones de HTML
Las inspecciones de un perfil pueden activarse o desactivarse desde las Preferencias de IntelliJ. El cuadro de diálogo de Preferencias es también una forma sencilla de conocer la gama de Inspecciones disponibles.

El icono de la "herramienta" le permite duplicar un perfil y crear un nuevo perfil para recoger un conjunto específico de reglas.

Ejecución de un perfil de inspección en el IDE
Los Perfiles de Inspección pueden ser ejecutados desde el IDE usando el menú `Analizar | Inspeccionar Código...`.

La función de análisis le permite controlar el ámbito en el que se ejecutará la inspección, por ejemplo, todo el proyecto, incluyendo o excluyendo los orígenes de las pruebas, o un conjunto específico de archivos.

También puede gestionar los perfiles de inspección desde aquí para crear o configurar un perfil concreto.
Al hacer clic en [Aceptar] en el cuadro de diálogo "Especificar ámbito de inspección", IntelliJ ejecutará todas las inspecciones seleccionadas en el perfil en el ámbito definido.
IntelliJ informará de los resultados de la ejecución de las inspecciones en la pestaña `Resultados de la inspección`.

El plugin Sensei de Secure Code Warrior le permite crear recetas personalizadas de coincidencia de código. Sensei se integra estrechamente con IntelliJ para hacer que estas recetas personalizadas sean tan naturales de usar como las Acciones de Intención de IntelliJ. Esto significa que se cargan en IntelliJ como inspecciones y pueden agruparse, activarse y desactivarse utilizando perfiles de inspección. La creación de un perfil de inspección personalizado y el uso de la función de análisis del código de inspección es la forma recomendada de ejecutar las recetas de Sensei de forma masiva en un proyecto.
Ejecución de un perfil de inspección desde la línea de comandos
IntelliJ tiene la capacidad de ejecutar inspecciones desde la línea de comandos, tal y como documenta JetBrains:
- https://www.jetbrains.com/help/idea/working-with-the-ide-features-from-command-line.html
Yo uso principalmente macOS, y puedo ejecutar una sola instancia de IntelliJ desde la línea de comandos con:
open -na "IntelliJ IDEA CE.app"
Para facilitar la ejecución, añado esto a un script de comandos del shell.
vi /usr/local/bin/idea
El contenido del script proviene de la documentación oficial proporcionada por IntelliJ.
#!/bin/sh
open -na "IntelliJ IDEA CE.app" --args "$@"
Luego hice este ejecutable para permitirme simplificar el proceso de inspección de la línea de comandos.
chmod 755 /usr/local/bin/idea
La documentación oficial de intellij describe la forma general del comando de inspección como
idea inspect <project> <inspection-profile> <output></output></inspection-profile></project>
[<options>]</options>
En la práctica, califico completamente las rutas y no necesito ninguna opción:
idea inspect /Users/user/GitHub/sensei-blog-examples /Users/user/GitHub/sensei-blog-examples/.idea/inspectionProfiles/senseiprofile.xml /Users/user/GitHub/sensei-blog-examples/scan-results
Esto ejecuta todas las inspecciones que agregué al `senseiprofile` y reporta los resultados en la carpeta `scan-results`.

Visualización de los resultados de la inspección
Podemos informar de estos resultados desde la integración continua, como veremos más adelante.
También podemos verlos dentro del propio IntelliJ utilizando la función `Analyse \ View Offline Inspection Results...`.

Esto cargará los resultados en la pestaña "Resultados de la inspección".

Esto está oficialmente documentado en el sitio de JetBrains:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Esto podría utilizarse durante un proceso de revisión de código si la ejecución de la línea de comandos se incorporara a un proceso de Integración Continua y los revisores quisieran comprobar el contexto de origen completo de cualquiera de las entradas de resultados de la Inspección.
Perfiles de inspección en la integración continua
Al añadir la inspección de la línea de comandos en la integración continua, lo ideal es que queramos que se genere un informe de forma automática y hay varias opciones abiertas para nosotros.
TeamCity ofrece soporte inmediato para los perfiles de inspección en la integración continua.
- https://www.jetbrains.com/help/teamcity/inspections.html
El plugin Jenkins Warnings NG soporta la salida de línea de comandos de IntelliJ Inspections como uno de los formatos de informe.
- https://github.com/jenkinsci/warnings-ng-plugin
- https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md
Existen proyectos comunitarios como `idea CLI Inspector` para apoyar el uso de los Perfiles de Inspección en otras herramientas de CI, por ejemplo
- https://github.com/bentolor/idea-cli-inspector
El futuro de los Perfiles de Inspección en un proceso de CI parece aún más brillante con la introducción del proyecto JetBrains Qodana. El proyecto Qodana es una versión sin cabeza de IntelliJ con acciones oficiales de Github e imágenes Docker.
- https://github.com/JetBrains/Qodana
Qodana se encuentra actualmente en fase beta, pero el equipo de Sensei lo está supervisando para que se convierta en una plataforma soportada oficialmente para ejecutar las reglas de Sensei como parte de la Integración Continua.
Resumen
Las Acciones de Intención nos permiten reforzar los patrones de codificación y corregirlos rápidamente en el IDE cuando cometemos errores durante la codificación.
Los Perfiles de Inspección nos permiten reunirlos en perfiles que pueden ejecutarse por lotes como una acción de Análisis e Inspección de Código. Esto puede ser útil si encontramos un patrón y queremos volver a comprobar si lo hemos pasado por alto en alguna otra parte de nuestro código.
Los Perfiles de Inspección pueden ejecutarse desde la línea de comandos e incluso incorporarse a los procesos de Integración Continua apoyando un modelo de "confiar, pero verificar" y detectar cualquier desviación accidental.
Todo lo anterior está incorporado en la funcionalidad de IntelliJ y JetBrains está mejorando su proceso de Integración Continua con la introducción de Qodana.
Sensei recetas se cargan en IntelliJ para actuar como Acciones de Intención nativas y ser recogidas en Perfiles de Inspección para soportar la comprobación por lotes a través de Inspect Code y el soporte de Integración Continua proporcionado por la funcionalidad oficial de ejecución de Línea de Comandos de JetBrains.
---
Puede instalar Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego sólo busque "sensei secure code".
Si quieres probar a ejecutar un proyecto en IntelliJ desde la línea de comandos, el proyecto utilizado en este post se puede encontrar en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior . Un ejercicio para el lector es crear un perfil que ejecute sólo las reglas de Sensei . Pruébalo:
https://github.com/securecodewarrior/sensei-blog-examples


Aprenda a ejecutar Sensei y las Acciones de Intención de IntelliJ en modo de lote como Inspecciones dentro del IDE, desde la Línea de Comandos, y en Integración Continua.
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á a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónAlan 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.


Ejecución de inspecciones de IntelliJ desde la integración continua
IntelliJ IDEA ofrece funcionalidad para ayudar a mejorar nuestra codificación, dentro del IDE al escribir código como Intenciones. Las Intenciones pueden ser usadas en lote para inspeccionar el código en busca de patrones a lo largo de la fuente e incluso extenderse al análisis de la Línea de Comandos o añadirse a la Integración Continua. Este post cubre la funcionalidad fuera de la caja de IntelliJ y la expansión con Intenciones personalizadas creadas en Sensei.
Inspecciones de IntelliJ
La función de Inspecciones de IntelliJ impulsa la visualización de muchos de los errores que se informan dinámicamente en el IDE cuando se codifica, por ejemplo
- detectar las clases abstractas que pueden convertirse en interfaces,
- identificar los campos de clase redundantes que pueden ser locales,
- advertencia sobre el uso de métodos obsoletos,
- etc.
Estas inspecciones resaltan el código que coincide en el IDE como Acciones de Intención que a menudo tienen un QuickFix asociado.

El resaltado del IDE en tiempo real cuando el código coincide con una Inspección puede ayudarnos a mejorar nuestra codificación de forma dinámica. Después de identificar el problema en el código, el uso de IntelliJ Intention Actions para QuickFix el código puede reforzar mejores patrones.
Perfil de las inspecciones
Las inspecciones pueden ejecutarse por lotes desde el IDE, y desde la línea de comandos o en un proceso de integración continua.
La clave para trabajar con las inspecciones de IntelliJ como un lote es mediante el uso de un Perfil de Inspección.
IntelliJ tiene dos perfiles de inspección por defecto: uno almacenado en el proyecto, y otro almacenado en el IDE.
Se pueden crear nuevos perfiles de inspección para configurar plugins o casos de uso específicos, por ejemplo
- Ejecutar sólo el escaneo en tiempo real de Checkstyle
- Ejecutar un conjunto específico de reglas de Sensei
- Ejecutar las comprobaciones de HTML
Las inspecciones de un perfil pueden activarse o desactivarse desde las Preferencias de IntelliJ. El cuadro de diálogo de Preferencias es también una forma sencilla de conocer la gama de Inspecciones disponibles.

El icono de la "herramienta" le permite duplicar un perfil y crear un nuevo perfil para recoger un conjunto específico de reglas.

Ejecución de un perfil de inspección en el IDE
Los Perfiles de Inspección pueden ser ejecutados desde el IDE usando el menú `Analizar | Inspeccionar Código...`.

La función de análisis le permite controlar el ámbito en el que se ejecutará la inspección, por ejemplo, todo el proyecto, incluyendo o excluyendo los orígenes de las pruebas, o un conjunto específico de archivos.

También puede gestionar los perfiles de inspección desde aquí para crear o configurar un perfil concreto.
Al hacer clic en [Aceptar] en el cuadro de diálogo "Especificar ámbito de inspección", IntelliJ ejecutará todas las inspecciones seleccionadas en el perfil en el ámbito definido.
IntelliJ informará de los resultados de la ejecución de las inspecciones en la pestaña `Resultados de la inspección`.

El plugin Sensei de Secure Code Warrior le permite crear recetas personalizadas de coincidencia de código. Sensei se integra estrechamente con IntelliJ para hacer que estas recetas personalizadas sean tan naturales de usar como las Acciones de Intención de IntelliJ. Esto significa que se cargan en IntelliJ como inspecciones y pueden agruparse, activarse y desactivarse utilizando perfiles de inspección. La creación de un perfil de inspección personalizado y el uso de la función de análisis del código de inspección es la forma recomendada de ejecutar las recetas de Sensei de forma masiva en un proyecto.
Ejecución de un perfil de inspección desde la línea de comandos
IntelliJ tiene la capacidad de ejecutar inspecciones desde la línea de comandos, tal y como documenta JetBrains:
- https://www.jetbrains.com/help/idea/working-with-the-ide-features-from-command-line.html
Yo uso principalmente macOS, y puedo ejecutar una sola instancia de IntelliJ desde la línea de comandos con:
open -na "IntelliJ IDEA CE.app"
Para facilitar la ejecución, añado esto a un script de comandos del shell.
vi /usr/local/bin/idea
El contenido del script proviene de la documentación oficial proporcionada por IntelliJ.
#!/bin/sh
open -na "IntelliJ IDEA CE.app" --args "$@"
Luego hice este ejecutable para permitirme simplificar el proceso de inspección de la línea de comandos.
chmod 755 /usr/local/bin/idea
La documentación oficial de intellij describe la forma general del comando de inspección como
idea inspect <project> <inspection-profile> <output></output></inspection-profile></project>
[<options>]</options>
En la práctica, califico completamente las rutas y no necesito ninguna opción:
idea inspect /Users/user/GitHub/sensei-blog-examples /Users/user/GitHub/sensei-blog-examples/.idea/inspectionProfiles/senseiprofile.xml /Users/user/GitHub/sensei-blog-examples/scan-results
Esto ejecuta todas las inspecciones que agregué al `senseiprofile` y reporta los resultados en la carpeta `scan-results`.

Visualización de los resultados de la inspección
Podemos informar de estos resultados desde la integración continua, como veremos más adelante.
También podemos verlos dentro del propio IntelliJ utilizando la función `Analyse \ View Offline Inspection Results...`.

Esto cargará los resultados en la pestaña "Resultados de la inspección".

Esto está oficialmente documentado en el sitio de JetBrains:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Esto podría utilizarse durante un proceso de revisión de código si la ejecución de la línea de comandos se incorporara a un proceso de Integración Continua y los revisores quisieran comprobar el contexto de origen completo de cualquiera de las entradas de resultados de la Inspección.
Perfiles de inspección en la integración continua
Al añadir la inspección de la línea de comandos en la integración continua, lo ideal es que queramos que se genere un informe de forma automática y hay varias opciones abiertas para nosotros.
TeamCity ofrece soporte inmediato para los perfiles de inspección en la integración continua.
- https://www.jetbrains.com/help/teamcity/inspections.html
El plugin Jenkins Warnings NG soporta la salida de línea de comandos de IntelliJ Inspections como uno de los formatos de informe.
- https://github.com/jenkinsci/warnings-ng-plugin
- https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md
Existen proyectos comunitarios como `idea CLI Inspector` para apoyar el uso de los Perfiles de Inspección en otras herramientas de CI, por ejemplo
- https://github.com/bentolor/idea-cli-inspector
El futuro de los Perfiles de Inspección en un proceso de CI parece aún más brillante con la introducción del proyecto JetBrains Qodana. El proyecto Qodana es una versión sin cabeza de IntelliJ con acciones oficiales de Github e imágenes Docker.
- https://github.com/JetBrains/Qodana
Qodana se encuentra actualmente en fase beta, pero el equipo de Sensei lo está supervisando para que se convierta en una plataforma soportada oficialmente para ejecutar las reglas de Sensei como parte de la Integración Continua.
Resumen
Las Acciones de Intención nos permiten reforzar los patrones de codificación y corregirlos rápidamente en el IDE cuando cometemos errores durante la codificación.
Los Perfiles de Inspección nos permiten reunirlos en perfiles que pueden ejecutarse por lotes como una acción de Análisis e Inspección de Código. Esto puede ser útil si encontramos un patrón y queremos volver a comprobar si lo hemos pasado por alto en alguna otra parte de nuestro código.
Los Perfiles de Inspección pueden ejecutarse desde la línea de comandos e incluso incorporarse a los procesos de Integración Continua apoyando un modelo de "confiar, pero verificar" y detectar cualquier desviación accidental.
Todo lo anterior está incorporado en la funcionalidad de IntelliJ y JetBrains está mejorando su proceso de Integración Continua con la introducción de Qodana.
Sensei recetas se cargan en IntelliJ para actuar como Acciones de Intención nativas y ser recogidas en Perfiles de Inspección para soportar la comprobación por lotes a través de Inspect Code y el soporte de Integración Continua proporcionado por la funcionalidad oficial de ejecución de Línea de Comandos de JetBrains.
---
Puede instalar Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego sólo busque "sensei secure code".
Si quieres probar a ejecutar un proyecto en IntelliJ desde la línea de comandos, el proyecto utilizado en este post se puede encontrar en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior . Un ejercicio para el lector es crear un perfil que ejecute sólo las reglas de Sensei . Pruébalo:
https://github.com/securecodewarrior/sensei-blog-examples

Ejecución de inspecciones de IntelliJ desde la integración continua
IntelliJ IDEA ofrece funcionalidad para ayudar a mejorar nuestra codificación, dentro del IDE al escribir código como Intenciones. Las Intenciones pueden ser usadas en lote para inspeccionar el código en busca de patrones a lo largo de la fuente e incluso extenderse al análisis de la Línea de Comandos o añadirse a la Integración Continua. Este post cubre la funcionalidad fuera de la caja de IntelliJ y la expansión con Intenciones personalizadas creadas en Sensei.
Inspecciones de IntelliJ
La función de Inspecciones de IntelliJ impulsa la visualización de muchos de los errores que se informan dinámicamente en el IDE cuando se codifica, por ejemplo
- detectar las clases abstractas que pueden convertirse en interfaces,
- identificar los campos de clase redundantes que pueden ser locales,
- advertencia sobre el uso de métodos obsoletos,
- etc.
Estas inspecciones resaltan el código que coincide en el IDE como Acciones de Intención que a menudo tienen un QuickFix asociado.

El resaltado del IDE en tiempo real cuando el código coincide con una Inspección puede ayudarnos a mejorar nuestra codificación de forma dinámica. Después de identificar el problema en el código, el uso de IntelliJ Intention Actions para QuickFix el código puede reforzar mejores patrones.
Perfil de las inspecciones
Las inspecciones pueden ejecutarse por lotes desde el IDE, y desde la línea de comandos o en un proceso de integración continua.
La clave para trabajar con las inspecciones de IntelliJ como un lote es mediante el uso de un Perfil de Inspección.
IntelliJ tiene dos perfiles de inspección por defecto: uno almacenado en el proyecto, y otro almacenado en el IDE.
Se pueden crear nuevos perfiles de inspección para configurar plugins o casos de uso específicos, por ejemplo
- Ejecutar sólo el escaneo en tiempo real de Checkstyle
- Ejecutar un conjunto específico de reglas de Sensei
- Ejecutar las comprobaciones de HTML
Las inspecciones de un perfil pueden activarse o desactivarse desde las Preferencias de IntelliJ. El cuadro de diálogo de Preferencias es también una forma sencilla de conocer la gama de Inspecciones disponibles.

El icono de la "herramienta" le permite duplicar un perfil y crear un nuevo perfil para recoger un conjunto específico de reglas.

Ejecución de un perfil de inspección en el IDE
Los Perfiles de Inspección pueden ser ejecutados desde el IDE usando el menú `Analizar | Inspeccionar Código...`.

La función de análisis le permite controlar el ámbito en el que se ejecutará la inspección, por ejemplo, todo el proyecto, incluyendo o excluyendo los orígenes de las pruebas, o un conjunto específico de archivos.

También puede gestionar los perfiles de inspección desde aquí para crear o configurar un perfil concreto.
Al hacer clic en [Aceptar] en el cuadro de diálogo "Especificar ámbito de inspección", IntelliJ ejecutará todas las inspecciones seleccionadas en el perfil en el ámbito definido.
IntelliJ informará de los resultados de la ejecución de las inspecciones en la pestaña `Resultados de la inspección`.

El plugin Sensei de Secure Code Warrior le permite crear recetas personalizadas de coincidencia de código. Sensei se integra estrechamente con IntelliJ para hacer que estas recetas personalizadas sean tan naturales de usar como las Acciones de Intención de IntelliJ. Esto significa que se cargan en IntelliJ como inspecciones y pueden agruparse, activarse y desactivarse utilizando perfiles de inspección. La creación de un perfil de inspección personalizado y el uso de la función de análisis del código de inspección es la forma recomendada de ejecutar las recetas de Sensei de forma masiva en un proyecto.
Ejecución de un perfil de inspección desde la línea de comandos
IntelliJ tiene la capacidad de ejecutar inspecciones desde la línea de comandos, tal y como documenta JetBrains:
- https://www.jetbrains.com/help/idea/working-with-the-ide-features-from-command-line.html
Yo uso principalmente macOS, y puedo ejecutar una sola instancia de IntelliJ desde la línea de comandos con:
open -na "IntelliJ IDEA CE.app"
Para facilitar la ejecución, añado esto a un script de comandos del shell.
vi /usr/local/bin/idea
El contenido del script proviene de la documentación oficial proporcionada por IntelliJ.
#!/bin/sh
open -na "IntelliJ IDEA CE.app" --args "$@"
Luego hice este ejecutable para permitirme simplificar el proceso de inspección de la línea de comandos.
chmod 755 /usr/local/bin/idea
La documentación oficial de intellij describe la forma general del comando de inspección como
idea inspect <project> <inspection-profile> <output></output></inspection-profile></project>
[<options>]</options>
En la práctica, califico completamente las rutas y no necesito ninguna opción:
idea inspect /Users/user/GitHub/sensei-blog-examples /Users/user/GitHub/sensei-blog-examples/.idea/inspectionProfiles/senseiprofile.xml /Users/user/GitHub/sensei-blog-examples/scan-results
Esto ejecuta todas las inspecciones que agregué al `senseiprofile` y reporta los resultados en la carpeta `scan-results`.

Visualización de los resultados de la inspección
Podemos informar de estos resultados desde la integración continua, como veremos más adelante.
También podemos verlos dentro del propio IntelliJ utilizando la función `Analyse \ View Offline Inspection Results...`.

Esto cargará los resultados en la pestaña "Resultados de la inspección".

Esto está oficialmente documentado en el sitio de JetBrains:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Esto podría utilizarse durante un proceso de revisión de código si la ejecución de la línea de comandos se incorporara a un proceso de Integración Continua y los revisores quisieran comprobar el contexto de origen completo de cualquiera de las entradas de resultados de la Inspección.
Perfiles de inspección en la integración continua
Al añadir la inspección de la línea de comandos en la integración continua, lo ideal es que queramos que se genere un informe de forma automática y hay varias opciones abiertas para nosotros.
TeamCity ofrece soporte inmediato para los perfiles de inspección en la integración continua.
- https://www.jetbrains.com/help/teamcity/inspections.html
El plugin Jenkins Warnings NG soporta la salida de línea de comandos de IntelliJ Inspections como uno de los formatos de informe.
- https://github.com/jenkinsci/warnings-ng-plugin
- https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md
Existen proyectos comunitarios como `idea CLI Inspector` para apoyar el uso de los Perfiles de Inspección en otras herramientas de CI, por ejemplo
- https://github.com/bentolor/idea-cli-inspector
El futuro de los Perfiles de Inspección en un proceso de CI parece aún más brillante con la introducción del proyecto JetBrains Qodana. El proyecto Qodana es una versión sin cabeza de IntelliJ con acciones oficiales de Github e imágenes Docker.
- https://github.com/JetBrains/Qodana
Qodana se encuentra actualmente en fase beta, pero el equipo de Sensei lo está supervisando para que se convierta en una plataforma soportada oficialmente para ejecutar las reglas de Sensei como parte de la Integración Continua.
Resumen
Las Acciones de Intención nos permiten reforzar los patrones de codificación y corregirlos rápidamente en el IDE cuando cometemos errores durante la codificación.
Los Perfiles de Inspección nos permiten reunirlos en perfiles que pueden ejecutarse por lotes como una acción de Análisis e Inspección de Código. Esto puede ser útil si encontramos un patrón y queremos volver a comprobar si lo hemos pasado por alto en alguna otra parte de nuestro código.
Los Perfiles de Inspección pueden ejecutarse desde la línea de comandos e incluso incorporarse a los procesos de Integración Continua apoyando un modelo de "confiar, pero verificar" y detectar cualquier desviación accidental.
Todo lo anterior está incorporado en la funcionalidad de IntelliJ y JetBrains está mejorando su proceso de Integración Continua con la introducción de Qodana.
Sensei recetas se cargan en IntelliJ para actuar como Acciones de Intención nativas y ser recogidas en Perfiles de Inspección para soportar la comprobación por lotes a través de Inspect Code y el soporte de Integración Continua proporcionado por la funcionalidad oficial de ejecución de Línea de Comandos de JetBrains.
---
Puede instalar Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego sólo busque "sensei secure code".
Si quieres probar a ejecutar un proyecto en IntelliJ desde la línea de comandos, el proyecto utilizado en este post se puede encontrar en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior . Un ejercicio para el lector es crear un perfil que ejecute sólo las reglas de Sensei . Pruébalo:
https://github.com/securecodewarrior/sensei-blog-examples

Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostraciónAlan 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.
Ejecución de inspecciones de IntelliJ desde la integración continua
IntelliJ IDEA ofrece funcionalidad para ayudar a mejorar nuestra codificación, dentro del IDE al escribir código como Intenciones. Las Intenciones pueden ser usadas en lote para inspeccionar el código en busca de patrones a lo largo de la fuente e incluso extenderse al análisis de la Línea de Comandos o añadirse a la Integración Continua. Este post cubre la funcionalidad fuera de la caja de IntelliJ y la expansión con Intenciones personalizadas creadas en Sensei.
Inspecciones de IntelliJ
La función de Inspecciones de IntelliJ impulsa la visualización de muchos de los errores que se informan dinámicamente en el IDE cuando se codifica, por ejemplo
- detectar las clases abstractas que pueden convertirse en interfaces,
- identificar los campos de clase redundantes que pueden ser locales,
- advertencia sobre el uso de métodos obsoletos,
- etc.
Estas inspecciones resaltan el código que coincide en el IDE como Acciones de Intención que a menudo tienen un QuickFix asociado.

El resaltado del IDE en tiempo real cuando el código coincide con una Inspección puede ayudarnos a mejorar nuestra codificación de forma dinámica. Después de identificar el problema en el código, el uso de IntelliJ Intention Actions para QuickFix el código puede reforzar mejores patrones.
Perfil de las inspecciones
Las inspecciones pueden ejecutarse por lotes desde el IDE, y desde la línea de comandos o en un proceso de integración continua.
La clave para trabajar con las inspecciones de IntelliJ como un lote es mediante el uso de un Perfil de Inspección.
IntelliJ tiene dos perfiles de inspección por defecto: uno almacenado en el proyecto, y otro almacenado en el IDE.
Se pueden crear nuevos perfiles de inspección para configurar plugins o casos de uso específicos, por ejemplo
- Ejecutar sólo el escaneo en tiempo real de Checkstyle
- Ejecutar un conjunto específico de reglas de Sensei
- Ejecutar las comprobaciones de HTML
Las inspecciones de un perfil pueden activarse o desactivarse desde las Preferencias de IntelliJ. El cuadro de diálogo de Preferencias es también una forma sencilla de conocer la gama de Inspecciones disponibles.

El icono de la "herramienta" le permite duplicar un perfil y crear un nuevo perfil para recoger un conjunto específico de reglas.

Ejecución de un perfil de inspección en el IDE
Los Perfiles de Inspección pueden ser ejecutados desde el IDE usando el menú `Analizar | Inspeccionar Código...`.

La función de análisis le permite controlar el ámbito en el que se ejecutará la inspección, por ejemplo, todo el proyecto, incluyendo o excluyendo los orígenes de las pruebas, o un conjunto específico de archivos.

También puede gestionar los perfiles de inspección desde aquí para crear o configurar un perfil concreto.
Al hacer clic en [Aceptar] en el cuadro de diálogo "Especificar ámbito de inspección", IntelliJ ejecutará todas las inspecciones seleccionadas en el perfil en el ámbito definido.
IntelliJ informará de los resultados de la ejecución de las inspecciones en la pestaña `Resultados de la inspección`.

El plugin Sensei de Secure Code Warrior le permite crear recetas personalizadas de coincidencia de código. Sensei se integra estrechamente con IntelliJ para hacer que estas recetas personalizadas sean tan naturales de usar como las Acciones de Intención de IntelliJ. Esto significa que se cargan en IntelliJ como inspecciones y pueden agruparse, activarse y desactivarse utilizando perfiles de inspección. La creación de un perfil de inspección personalizado y el uso de la función de análisis del código de inspección es la forma recomendada de ejecutar las recetas de Sensei de forma masiva en un proyecto.
Ejecución de un perfil de inspección desde la línea de comandos
IntelliJ tiene la capacidad de ejecutar inspecciones desde la línea de comandos, tal y como documenta JetBrains:
- https://www.jetbrains.com/help/idea/working-with-the-ide-features-from-command-line.html
Yo uso principalmente macOS, y puedo ejecutar una sola instancia de IntelliJ desde la línea de comandos con:
open -na "IntelliJ IDEA CE.app"
Para facilitar la ejecución, añado esto a un script de comandos del shell.
vi /usr/local/bin/idea
El contenido del script proviene de la documentación oficial proporcionada por IntelliJ.
#!/bin/sh
open -na "IntelliJ IDEA CE.app" --args "$@"
Luego hice este ejecutable para permitirme simplificar el proceso de inspección de la línea de comandos.
chmod 755 /usr/local/bin/idea
La documentación oficial de intellij describe la forma general del comando de inspección como
idea inspect <project> <inspection-profile> <output></output></inspection-profile></project>
[<options>]</options>
En la práctica, califico completamente las rutas y no necesito ninguna opción:
idea inspect /Users/user/GitHub/sensei-blog-examples /Users/user/GitHub/sensei-blog-examples/.idea/inspectionProfiles/senseiprofile.xml /Users/user/GitHub/sensei-blog-examples/scan-results
Esto ejecuta todas las inspecciones que agregué al `senseiprofile` y reporta los resultados en la carpeta `scan-results`.

Visualización de los resultados de la inspección
Podemos informar de estos resultados desde la integración continua, como veremos más adelante.
También podemos verlos dentro del propio IntelliJ utilizando la función `Analyse \ View Offline Inspection Results...`.

Esto cargará los resultados en la pestaña "Resultados de la inspección".

Esto está oficialmente documentado en el sitio de JetBrains:
- https://www.jetbrains.com/help/idea/command-line-code-inspector.html#inspection-results
Esto podría utilizarse durante un proceso de revisión de código si la ejecución de la línea de comandos se incorporara a un proceso de Integración Continua y los revisores quisieran comprobar el contexto de origen completo de cualquiera de las entradas de resultados de la Inspección.
Perfiles de inspección en la integración continua
Al añadir la inspección de la línea de comandos en la integración continua, lo ideal es que queramos que se genere un informe de forma automática y hay varias opciones abiertas para nosotros.
TeamCity ofrece soporte inmediato para los perfiles de inspección en la integración continua.
- https://www.jetbrains.com/help/teamcity/inspections.html
El plugin Jenkins Warnings NG soporta la salida de línea de comandos de IntelliJ Inspections como uno de los formatos de informe.
- https://github.com/jenkinsci/warnings-ng-plugin
- https://github.com/jenkinsci/warnings-ng-plugin/blob/master/SUPPORTED-FORMATS.md
Existen proyectos comunitarios como `idea CLI Inspector` para apoyar el uso de los Perfiles de Inspección en otras herramientas de CI, por ejemplo
- https://github.com/bentolor/idea-cli-inspector
El futuro de los Perfiles de Inspección en un proceso de CI parece aún más brillante con la introducción del proyecto JetBrains Qodana. El proyecto Qodana es una versión sin cabeza de IntelliJ con acciones oficiales de Github e imágenes Docker.
- https://github.com/JetBrains/Qodana
Qodana se encuentra actualmente en fase beta, pero el equipo de Sensei lo está supervisando para que se convierta en una plataforma soportada oficialmente para ejecutar las reglas de Sensei como parte de la Integración Continua.
Resumen
Las Acciones de Intención nos permiten reforzar los patrones de codificación y corregirlos rápidamente en el IDE cuando cometemos errores durante la codificación.
Los Perfiles de Inspección nos permiten reunirlos en perfiles que pueden ejecutarse por lotes como una acción de Análisis e Inspección de Código. Esto puede ser útil si encontramos un patrón y queremos volver a comprobar si lo hemos pasado por alto en alguna otra parte de nuestro código.
Los Perfiles de Inspección pueden ejecutarse desde la línea de comandos e incluso incorporarse a los procesos de Integración Continua apoyando un modelo de "confiar, pero verificar" y detectar cualquier desviación accidental.
Todo lo anterior está incorporado en la funcionalidad de IntelliJ y JetBrains está mejorando su proceso de Integración Continua con la introducción de Qodana.
Sensei recetas se cargan en IntelliJ para actuar como Acciones de Intención nativas y ser recogidas en Perfiles de Inspección para soportar la comprobación por lotes a través de Inspect Code y el soporte de Integración Continua proporcionado por la funcionalidad oficial de ejecución de Línea de Comandos de JetBrains.
---
Puede instalar Sensei desde IntelliJ usando "Preferences \ Plugins" (Mac) o "Settings \ Plugins" (Windows) y luego sólo busque "sensei secure code".
Si quieres probar a ejecutar un proyecto en IntelliJ desde la línea de comandos, el proyecto utilizado en este post se puede encontrar en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior . Un ejercicio para el lector es crear un perfil que ejecute sólo las reglas de Sensei . Pruébalo:
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á a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
Encontrar datos significativos sobre el éxito de las iniciativas Secure-by-Design es notoriamente difícil. Los responsables de la seguridad de la información se enfrentan a menudo al reto de demostrar el rendimiento de la inversión (ROI) y el valor empresarial de las actividades de los programas de seguridad, tanto a nivel de las personas como de la empresa. Por no mencionar que a las empresas les resulta especialmente difícil obtener información sobre cómo se comparan sus organizaciones con los estándares actuales del sector. La Estrategia Nacional de Ciberseguridad del Presidente desafió a las partes interesadas a "adoptar la seguridad y la resiliencia desde el diseño". La clave para que las iniciativas de seguridad por diseño funcionen no es sólo dotar a los desarrolladores de las habilidades necesarias para garantizar un código seguro, sino también garantizar a los reguladores que esas habilidades están en su lugar. En esta presentación, compartimos una miríada de datos cualitativos y cuantitativos, derivados de múltiples fuentes primarias, incluidos puntos de datos internos recogidos de más de 250.000 desarrolladores, opiniones de clientes basadas en datos y estudios públicos. Aprovechando esta agregación de puntos de datos, pretendemos comunicar una visión del estado actual de las iniciativas Secure-by-Design en múltiples verticales. El informe detalla por qué este espacio está actualmente infrautilizado, el impacto significativo que un programa de mejora de las competencias puede tener en la mitigación de los riesgos de ciberseguridad y el potencial para eliminar categorías de vulnerabilidades de un código base.
Servicios profesionales - Acelerar con experiencia
El equipo de servicios de estrategia de programas (PSS) de Secure Code Warriorle ayuda a crear, mejorar y optimizar su programa de codificación segura. Tanto si empieza de cero como si está perfeccionando su enfoque, nuestros expertos le proporcionarán orientación personalizada.
Temas y contenidos de la formación sobre código seguro
Nuestro contenido, líder en el sector, evoluciona constantemente para adaptarse al cambiante panorama del desarrollo de software teniendo en cuenta su función. Temas que cubren todo, desde IA a XQuery Injection, ofrecidos para una variedad de roles desde Arquitectos e Ingenieros a Product Managers y QA. Eche un vistazo a lo que ofrece nuestro catálogo de contenidos por tema y función.
Búsqueda: Aprendizaje líder en la industria para mantener a los desarrolladores por delante mitigando el riesgo.
Quests es una learning platform que ayuda a los desarrolladores a mitigar los riesgos de seguridad del software mediante la mejora de sus habilidades de codificación segura. Con rutas de aprendizaje curadas, desafíos prácticos y actividades interactivas, capacita a los desarrolladores para identificar y prevenir vulnerabilidades.
Recursos para empezar
¿Vibe Coding va a convertir tu código en una fiesta de fraternidad?
Vibe Coding es como una fiesta de fraternidad universitaria, y la IA es la pieza central de todos los festejos, el barril. Es muy divertido dar rienda suelta a la creatividad y ver adónde te lleva tu imaginación, pero después de unas cuantas borracheras, beber (o usar IA) con moderación es, sin duda, la solución más segura a largo plazo.
La Década de los Defensores: Secure Code Warrior Cumple Diez Años
Secure Code Warriorha permanecido unido, dirigiendo el barco a través de cada lección, triunfo y contratiempo durante toda una década. Estamos creciendo y listos para afrontar nuestro próximo capítulo, SCW 2.0, como líderes en gestión de riesgos para desarrolladores.