Añadir automáticamente un constructor privado con Sensei
Añadir automáticamente un constructor privado con Sensei
En una clase de utilidad, cuando los campos y métodos son estáticos, no hay ninguna razón obvia por la que la instanciaría.
Por ejemplo, UtilityClass utility = new UtilityClass();
El código siguiente es una implementación sencilla de una clase Utility.
public class UtilityClass {
public static final Boolean ULTIMATE_TRUTH = true;
public static boolean getTrue(){
return ULTIMATE_TRUTH;
}
}
Este es el tipo de patrón de codificación que las herramientas de análisis estático pueden detectar, pero a menudo no ofrecen la posibilidad de solucionar el problema.
Puedo usar Sensei para identificar el patrón de codificación, y generar automáticamente un constructor privado para que me sea imposible instanciar la clase.
Búsqueda de la clase
Voy a añadir una nueva receta en la clase de Utilidad llamada:
- Clases estáticas: crear constructor privado.

Y en un principio, crearé un simple matcher para buscar una clase.
buscar:
class: {}
Esto coincidirá con cualquier clase, lo que es suficiente para permitirme empezar a escribir un Quick Fix. Una vez que tenga un Quick Fix que funcione, perfeccionaré la búsqueda para que destaque cuando sea más probable que haya una clase que requiera un constructor privado.

Solución rápida
Para el Quick Fix, voy a querer generar un constructor privado.
En la clase de ejemplo esto se vería así:
private UtilityClass(){}
Para añadir el código anterior a mi clase, mi Quick Fix añadirá un Método, y el nombre del método será una plantilla Mustache que utiliza el nombre de la clase.
availableFixes:
- name: "add private constructor"
actions:
- addMethod:
method: "private {{{ name }}}(){}"
En el Editor GUI, utilizo la opción Mostrar Variables para crear la plantilla Bigote y luego edito el campo para añadir el modificador privado, los corchetes y las llaves para que sea sintácticamente correcto.

Esto me permitiría ahora añadir un constructor privado a cualquier clase.
La vista previa de QuickFix me ayuda porque puedo ver el código generado mientras escribo la plantilla Mustache.

Ahora que sé que puedo solucionar el problema. Afinaré las condiciones de búsqueda para mostrar la receta cuando sea más apropiado.
Búsqueda de constructores desaparecidos
Idealmente, no quiero crear una receta que marque un error contra cada clase. Así que voy a añadir algunas condiciones adicionales en la búsqueda para que sólo coincidan en las clases que no tienen un constructor.
buscar:
clase:
sin:
hijo:
método:
constructor: true
El YAML es ligeramente diferente del GUI.
En la GUI lo configuro para que busque una clase sin un método hijo que sea un constructor 'yes'. Usamos 'yes' en la GUI en lugar de 'true' para hacer la GUI un poco más amigable.

Esta receta ahora sólo se revelará para cualquier clase sin un constructor.
Búsqueda estrecha de los posibles culpables
Así que podría ir más allá y buscar la presencia de métodos o campos estáticos.
Busco cualquier clase sin constructor y que tenga todos los campos estáticos públicos o todos los métodos estáticos públicos.
buscar:
class:
with:
anyOf:
- child:
method:
allOf:
- modifier: "public"
- modificador: "static"
- child:
field:
allOf:
- modifier: "static"
- modificador: "public"
sin:
child:
method:
constructor: true
Dado que Sensei se utiliza para ayudarme, como programador, en el IDE, más que para analizar estáticamente el código e informar de todos los errores, este filtro es lo suficientemente bueno como para descartar la mayoría de las clases de mi base de código en las que podría tener una buena razón para tener un constructor público por defecto.
En algunos proyectos, esto podría ser un paso demasiado lejos porque las clases de utilidad podrían tener métodos privados, por lo que podría optar por buscar la presencia de "cualquier" método estático público, en lugar de "todos".
- child:
field:
anyOf:
- modifier: "static"
- modificador: "público"
Consejos
Sensei no está diseñado para sustituir a una herramienta de Análisis Estático. Sensei puede aumentar una herramienta de Análisis Estático para problemas comunes asociados con su proceso de codificación, o tecnología. Reproduciendo una cantidad suficiente de coincidencias para poner de relieve un problema, y apoyando el proceso de desarrollo mediante la generación del código QuickFix.
Lo que trato de hacer es crear una receta lo suficientemente simple que incluya todas las situaciones que necesito, pero filtrarla para que no se sugiera en todas las clases.
Cuando trabajo en las recetas trato de des-riesgarlas, en este caso, no estaba seguro si podía crear el constructor privado así que creé el QuickFix primero. Luego refactoricé las condiciones de búsqueda para hacerlas más específicas.
A veces, cuando trabajo en recetas, no estoy seguro de cómo realizar la búsqueda, así que primero trabajo en eso.
Encuentro que las recetas son más fáciles de crear cuando las construyo de forma incremental, cambiando entre la refacción del QuickFix y la búsqueda.
---
Puedes instalar Sensei desde IntelliJ usando "Preferencias \N-Plugins" (Mac) o "Ajustes \N-Plugins" (Windows) y luego sólo busca "sensei secure code"
El código fuente y las recetas para esto se pueden encontrar en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior , en el módulo `pojoexamples`.
https://github.com/securecodewarrior/sensei-blog-examples


Aprenda cómo Sensei puede identificar un patrón de codificación, y generar automáticamente un constructor privado para que sea imposible instanciar la clase.
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.


Añadir automáticamente un constructor privado con Sensei
En una clase de utilidad, cuando los campos y métodos son estáticos, no hay ninguna razón obvia por la que la instanciaría.
Por ejemplo, UtilityClass utility = new UtilityClass();
El código siguiente es una implementación sencilla de una clase Utility.
public class UtilityClass {
public static final Boolean ULTIMATE_TRUTH = true;
public static boolean getTrue(){
return ULTIMATE_TRUTH;
}
}
Este es el tipo de patrón de codificación que las herramientas de análisis estático pueden detectar, pero a menudo no ofrecen la posibilidad de solucionar el problema.
Puedo usar Sensei para identificar el patrón de codificación, y generar automáticamente un constructor privado para que me sea imposible instanciar la clase.
Búsqueda de la clase
Voy a añadir una nueva receta en la clase de Utilidad llamada:
- Clases estáticas: crear constructor privado.

Y en un principio, crearé un simple matcher para buscar una clase.
buscar:
class: {}
Esto coincidirá con cualquier clase, lo que es suficiente para permitirme empezar a escribir un Quick Fix. Una vez que tenga un Quick Fix que funcione, perfeccionaré la búsqueda para que destaque cuando sea más probable que haya una clase que requiera un constructor privado.

Solución rápida
Para el Quick Fix, voy a querer generar un constructor privado.
En la clase de ejemplo esto se vería así:
private UtilityClass(){}
Para añadir el código anterior a mi clase, mi Quick Fix añadirá un Método, y el nombre del método será una plantilla Mustache que utiliza el nombre de la clase.
availableFixes:
- name: "add private constructor"
actions:
- addMethod:
method: "private {{{ name }}}(){}"
En el Editor GUI, utilizo la opción Mostrar Variables para crear la plantilla Bigote y luego edito el campo para añadir el modificador privado, los corchetes y las llaves para que sea sintácticamente correcto.

Esto me permitiría ahora añadir un constructor privado a cualquier clase.
La vista previa de QuickFix me ayuda porque puedo ver el código generado mientras escribo la plantilla Mustache.

Ahora que sé que puedo solucionar el problema. Afinaré las condiciones de búsqueda para mostrar la receta cuando sea más apropiado.
Búsqueda de constructores desaparecidos
Idealmente, no quiero crear una receta que marque un error contra cada clase. Así que voy a añadir algunas condiciones adicionales en la búsqueda para que sólo coincidan en las clases que no tienen un constructor.
buscar:
clase:
sin:
hijo:
método:
constructor: true
El YAML es ligeramente diferente del GUI.
En la GUI lo configuro para que busque una clase sin un método hijo que sea un constructor 'yes'. Usamos 'yes' en la GUI en lugar de 'true' para hacer la GUI un poco más amigable.

Esta receta ahora sólo se revelará para cualquier clase sin un constructor.
Búsqueda estrecha de los posibles culpables
Así que podría ir más allá y buscar la presencia de métodos o campos estáticos.
Busco cualquier clase sin constructor y que tenga todos los campos estáticos públicos o todos los métodos estáticos públicos.
buscar:
class:
with:
anyOf:
- child:
method:
allOf:
- modifier: "public"
- modificador: "static"
- child:
field:
allOf:
- modifier: "static"
- modificador: "public"
sin:
child:
method:
constructor: true
Dado que Sensei se utiliza para ayudarme, como programador, en el IDE, más que para analizar estáticamente el código e informar de todos los errores, este filtro es lo suficientemente bueno como para descartar la mayoría de las clases de mi base de código en las que podría tener una buena razón para tener un constructor público por defecto.
En algunos proyectos, esto podría ser un paso demasiado lejos porque las clases de utilidad podrían tener métodos privados, por lo que podría optar por buscar la presencia de "cualquier" método estático público, en lugar de "todos".
- child:
field:
anyOf:
- modifier: "static"
- modificador: "público"
Consejos
Sensei no está diseñado para sustituir a una herramienta de Análisis Estático. Sensei puede aumentar una herramienta de Análisis Estático para problemas comunes asociados con su proceso de codificación, o tecnología. Reproduciendo una cantidad suficiente de coincidencias para poner de relieve un problema, y apoyando el proceso de desarrollo mediante la generación del código QuickFix.
Lo que trato de hacer es crear una receta lo suficientemente simple que incluya todas las situaciones que necesito, pero filtrarla para que no se sugiera en todas las clases.
Cuando trabajo en las recetas trato de des-riesgarlas, en este caso, no estaba seguro si podía crear el constructor privado así que creé el QuickFix primero. Luego refactoricé las condiciones de búsqueda para hacerlas más específicas.
A veces, cuando trabajo en recetas, no estoy seguro de cómo realizar la búsqueda, así que primero trabajo en eso.
Encuentro que las recetas son más fáciles de crear cuando las construyo de forma incremental, cambiando entre la refacción del QuickFix y la búsqueda.
---
Puedes instalar Sensei desde IntelliJ usando "Preferencias \N-Plugins" (Mac) o "Ajustes \N-Plugins" (Windows) y luego sólo busca "sensei secure code"
El código fuente y las recetas para esto se pueden encontrar en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior , en el módulo `pojoexamples`.
https://github.com/securecodewarrior/sensei-blog-examples

Añadir automáticamente un constructor privado con Sensei
En una clase de utilidad, cuando los campos y métodos son estáticos, no hay ninguna razón obvia por la que la instanciaría.
Por ejemplo, UtilityClass utility = new UtilityClass();
El código siguiente es una implementación sencilla de una clase Utility.
public class UtilityClass {
public static final Boolean ULTIMATE_TRUTH = true;
public static boolean getTrue(){
return ULTIMATE_TRUTH;
}
}
Este es el tipo de patrón de codificación que las herramientas de análisis estático pueden detectar, pero a menudo no ofrecen la posibilidad de solucionar el problema.
Puedo usar Sensei para identificar el patrón de codificación, y generar automáticamente un constructor privado para que me sea imposible instanciar la clase.
Búsqueda de la clase
Voy a añadir una nueva receta en la clase de Utilidad llamada:
- Clases estáticas: crear constructor privado.

Y en un principio, crearé un simple matcher para buscar una clase.
buscar:
class: {}
Esto coincidirá con cualquier clase, lo que es suficiente para permitirme empezar a escribir un Quick Fix. Una vez que tenga un Quick Fix que funcione, perfeccionaré la búsqueda para que destaque cuando sea más probable que haya una clase que requiera un constructor privado.

Solución rápida
Para el Quick Fix, voy a querer generar un constructor privado.
En la clase de ejemplo esto se vería así:
private UtilityClass(){}
Para añadir el código anterior a mi clase, mi Quick Fix añadirá un Método, y el nombre del método será una plantilla Mustache que utiliza el nombre de la clase.
availableFixes:
- name: "add private constructor"
actions:
- addMethod:
method: "private {{{ name }}}(){}"
En el Editor GUI, utilizo la opción Mostrar Variables para crear la plantilla Bigote y luego edito el campo para añadir el modificador privado, los corchetes y las llaves para que sea sintácticamente correcto.

Esto me permitiría ahora añadir un constructor privado a cualquier clase.
La vista previa de QuickFix me ayuda porque puedo ver el código generado mientras escribo la plantilla Mustache.

Ahora que sé que puedo solucionar el problema. Afinaré las condiciones de búsqueda para mostrar la receta cuando sea más apropiado.
Búsqueda de constructores desaparecidos
Idealmente, no quiero crear una receta que marque un error contra cada clase. Así que voy a añadir algunas condiciones adicionales en la búsqueda para que sólo coincidan en las clases que no tienen un constructor.
buscar:
clase:
sin:
hijo:
método:
constructor: true
El YAML es ligeramente diferente del GUI.
En la GUI lo configuro para que busque una clase sin un método hijo que sea un constructor 'yes'. Usamos 'yes' en la GUI en lugar de 'true' para hacer la GUI un poco más amigable.

Esta receta ahora sólo se revelará para cualquier clase sin un constructor.
Búsqueda estrecha de los posibles culpables
Así que podría ir más allá y buscar la presencia de métodos o campos estáticos.
Busco cualquier clase sin constructor y que tenga todos los campos estáticos públicos o todos los métodos estáticos públicos.
buscar:
class:
with:
anyOf:
- child:
method:
allOf:
- modifier: "public"
- modificador: "static"
- child:
field:
allOf:
- modifier: "static"
- modificador: "public"
sin:
child:
method:
constructor: true
Dado que Sensei se utiliza para ayudarme, como programador, en el IDE, más que para analizar estáticamente el código e informar de todos los errores, este filtro es lo suficientemente bueno como para descartar la mayoría de las clases de mi base de código en las que podría tener una buena razón para tener un constructor público por defecto.
En algunos proyectos, esto podría ser un paso demasiado lejos porque las clases de utilidad podrían tener métodos privados, por lo que podría optar por buscar la presencia de "cualquier" método estático público, en lugar de "todos".
- child:
field:
anyOf:
- modifier: "static"
- modificador: "público"
Consejos
Sensei no está diseñado para sustituir a una herramienta de Análisis Estático. Sensei puede aumentar una herramienta de Análisis Estático para problemas comunes asociados con su proceso de codificación, o tecnología. Reproduciendo una cantidad suficiente de coincidencias para poner de relieve un problema, y apoyando el proceso de desarrollo mediante la generación del código QuickFix.
Lo que trato de hacer es crear una receta lo suficientemente simple que incluya todas las situaciones que necesito, pero filtrarla para que no se sugiera en todas las clases.
Cuando trabajo en las recetas trato de des-riesgarlas, en este caso, no estaba seguro si podía crear el constructor privado así que creé el QuickFix primero. Luego refactoricé las condiciones de búsqueda para hacerlas más específicas.
A veces, cuando trabajo en recetas, no estoy seguro de cómo realizar la búsqueda, así que primero trabajo en eso.
Encuentro que las recetas son más fáciles de crear cuando las construyo de forma incremental, cambiando entre la refacción del QuickFix y la búsqueda.
---
Puedes instalar Sensei desde IntelliJ usando "Preferencias \N-Plugins" (Mac) o "Ajustes \N-Plugins" (Windows) y luego sólo busca "sensei secure code"
El código fuente y las recetas para esto se pueden encontrar en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior , en el módulo `pojoexamples`.
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.
Añadir automáticamente un constructor privado con Sensei
En una clase de utilidad, cuando los campos y métodos son estáticos, no hay ninguna razón obvia por la que la instanciaría.
Por ejemplo, UtilityClass utility = new UtilityClass();
El código siguiente es una implementación sencilla de una clase Utility.
public class UtilityClass {
public static final Boolean ULTIMATE_TRUTH = true;
public static boolean getTrue(){
return ULTIMATE_TRUTH;
}
}
Este es el tipo de patrón de codificación que las herramientas de análisis estático pueden detectar, pero a menudo no ofrecen la posibilidad de solucionar el problema.
Puedo usar Sensei para identificar el patrón de codificación, y generar automáticamente un constructor privado para que me sea imposible instanciar la clase.
Búsqueda de la clase
Voy a añadir una nueva receta en la clase de Utilidad llamada:
- Clases estáticas: crear constructor privado.

Y en un principio, crearé un simple matcher para buscar una clase.
buscar:
class: {}
Esto coincidirá con cualquier clase, lo que es suficiente para permitirme empezar a escribir un Quick Fix. Una vez que tenga un Quick Fix que funcione, perfeccionaré la búsqueda para que destaque cuando sea más probable que haya una clase que requiera un constructor privado.

Solución rápida
Para el Quick Fix, voy a querer generar un constructor privado.
En la clase de ejemplo esto se vería así:
private UtilityClass(){}
Para añadir el código anterior a mi clase, mi Quick Fix añadirá un Método, y el nombre del método será una plantilla Mustache que utiliza el nombre de la clase.
availableFixes:
- name: "add private constructor"
actions:
- addMethod:
method: "private {{{ name }}}(){}"
En el Editor GUI, utilizo la opción Mostrar Variables para crear la plantilla Bigote y luego edito el campo para añadir el modificador privado, los corchetes y las llaves para que sea sintácticamente correcto.

Esto me permitiría ahora añadir un constructor privado a cualquier clase.
La vista previa de QuickFix me ayuda porque puedo ver el código generado mientras escribo la plantilla Mustache.

Ahora que sé que puedo solucionar el problema. Afinaré las condiciones de búsqueda para mostrar la receta cuando sea más apropiado.
Búsqueda de constructores desaparecidos
Idealmente, no quiero crear una receta que marque un error contra cada clase. Así que voy a añadir algunas condiciones adicionales en la búsqueda para que sólo coincidan en las clases que no tienen un constructor.
buscar:
clase:
sin:
hijo:
método:
constructor: true
El YAML es ligeramente diferente del GUI.
En la GUI lo configuro para que busque una clase sin un método hijo que sea un constructor 'yes'. Usamos 'yes' en la GUI en lugar de 'true' para hacer la GUI un poco más amigable.

Esta receta ahora sólo se revelará para cualquier clase sin un constructor.
Búsqueda estrecha de los posibles culpables
Así que podría ir más allá y buscar la presencia de métodos o campos estáticos.
Busco cualquier clase sin constructor y que tenga todos los campos estáticos públicos o todos los métodos estáticos públicos.
buscar:
class:
with:
anyOf:
- child:
method:
allOf:
- modifier: "public"
- modificador: "static"
- child:
field:
allOf:
- modifier: "static"
- modificador: "public"
sin:
child:
method:
constructor: true
Dado que Sensei se utiliza para ayudarme, como programador, en el IDE, más que para analizar estáticamente el código e informar de todos los errores, este filtro es lo suficientemente bueno como para descartar la mayoría de las clases de mi base de código en las que podría tener una buena razón para tener un constructor público por defecto.
En algunos proyectos, esto podría ser un paso demasiado lejos porque las clases de utilidad podrían tener métodos privados, por lo que podría optar por buscar la presencia de "cualquier" método estático público, en lugar de "todos".
- child:
field:
anyOf:
- modifier: "static"
- modificador: "público"
Consejos
Sensei no está diseñado para sustituir a una herramienta de Análisis Estático. Sensei puede aumentar una herramienta de Análisis Estático para problemas comunes asociados con su proceso de codificación, o tecnología. Reproduciendo una cantidad suficiente de coincidencias para poner de relieve un problema, y apoyando el proceso de desarrollo mediante la generación del código QuickFix.
Lo que trato de hacer es crear una receta lo suficientemente simple que incluya todas las situaciones que necesito, pero filtrarla para que no se sugiera en todas las clases.
Cuando trabajo en las recetas trato de des-riesgarlas, en este caso, no estaba seguro si podía crear el constructor privado así que creé el QuickFix primero. Luego refactoricé las condiciones de búsqueda para hacerlas más específicas.
A veces, cuando trabajo en recetas, no estoy seguro de cómo realizar la búsqueda, así que primero trabajo en eso.
Encuentro que las recetas son más fáciles de crear cuando las construyo de forma incremental, cambiando entre la refacción del QuickFix y la búsqueda.
---
Puedes instalar Sensei desde IntelliJ usando "Preferencias \N-Plugins" (Mac) o "Ajustes \N-Plugins" (Windows) y luego sólo busca "sensei secure code"
El código fuente y las recetas para esto se pueden encontrar en el repositorio `sensei-blog-examples` en la cuenta de GitHub de Secure Code Warrior , en el módulo `pojoexamples`.
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
Vibe Coding: Guía práctica para actualizar su estrategia AppSec para la IA
Vea el vídeo a la carta para aprender a capacitar a los administradores de AppSec para que se conviertan en facilitadores de IA, en lugar de bloqueadores, mediante un enfoque práctico que da prioridad a la formación. Le mostraremos cómo aprovechar Secure Code Warrior (SCW) para actualizar estratégicamente su estrategia de AppSec para la era de los asistentes de codificación de IA.
Asistentes de codificación de IA: Guía de navegación segura para la próxima generación de desarrolladores
Los grandes modelos lingüísticos ofrecen ventajas irresistibles en velocidad y productividad, pero también introducen riesgos innegables para la empresa. Las barandillas de seguridad tradicionales no bastan para controlar el diluvio. Los desarrolladores necesitan conocimientos de seguridad precisos y verificados para identificar y prevenir los fallos de seguridad desde el principio del ciclo de vida de desarrollo del software.
Recursos para empezar
Serie de vídeos sobre seguridad AI/LLM: Todos los episodios, actualizados semanalmente
Su guía todo en uno para nuestra serie de vídeos de seguridad AI/LLM de 12 semanas. Vea todos los episodios, aprenda conceptos clave de seguridad de IA y siga la serie semanalmente.
SCW lanza una serie de vídeos gratuitos sobre seguridad AI/LLM para desarrolladores
Presentamos nuestra serie de vídeos gratuitos sobre seguridad de IA/LLM de 12 semanas de duración. Conozca los riesgos fundamentales de la codificación asistida por IA y cómo crear aplicaciones más seguras.
Más de 10.000 actividades de aprendizaje sobre código seguro: Una década de gestión de riesgos para desarrolladores
Más de 10 000 actividades de aprendizaje de código seguro y una década ayudando a los desarrolladores a reducir riesgos, mejorar la calidad del código y abordar con confianza el desarrollo asistido por IA.