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
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
El movimiento Secure-by-Design es el futuro del desarrollo de software seguro. Conozca los elementos clave que las empresas deben tener en cuenta cuando piensan en una iniciativa Secure-by-Design.
DigitalOcean reduce su deuda de seguridad con Secure Code Warrior
El uso por parte de DigitalOcean de la formación Secure Code Warrior ha reducido significativamente la deuda de seguridad, permitiendo a los equipos centrarse más en la innovación y la productividad. La mejora de la seguridad ha reforzado la calidad de sus productos y su ventaja competitiva. De cara al futuro, SCW Trust Score les ayudará a seguir mejorando las prácticas de seguridad y a continuar impulsando la innovación.
Recursos para empezar
La puntuación de confianza revela el valor de las iniciativas de mejora de la seguridad mediante el diseño
Nuestra investigación ha demostrado que la formación en código seguro funciona. Trust Score, que utiliza un algoritmo basado en más de 20 millones de puntos de datos de aprendizaje procedentes del trabajo de más de 250 000 alumnos en más de 600 organizaciones, revela su eficacia a la hora de reducir las vulnerabilidades y cómo hacer que la iniciativa sea aún más eficaz.
Seguridad reactiva frente a seguridad preventiva: Prevenir es mejor que curar
La idea de introducir la seguridad preventiva en el código y los sistemas heredados al mismo tiempo que en las aplicaciones más recientes puede parecer desalentadora, pero un planteamiento basado en el diseño seguro, aplicado mediante la mejora de las competencias de los desarrolladores, puede aplicar las mejores prácticas de seguridad a esos sistemas. Es la mejor oportunidad que tienen muchas organizaciones de mejorar su seguridad.
Ventajas de la evaluación comparativa de las competencias de seguridad de los desarrolladores
La creciente atención que se presta al código seguro y a los principios del diseño seguro exige que los desarrolladores reciban formación en ciberseguridad desde el principio del proceso de desarrollo de software, con herramientas como Secure Code Warrior's Trust Score, que ayudan a medir y mejorar sus progresos.
Impulsando iniciativas de seguridad por diseño para empresas con éxito significativo
Nuestro último documento de investigación, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise, es el resultado de un análisis profundo de iniciativas reales de Secure-by-Design a nivel empresarial y de la derivación de enfoques de mejores prácticas basados en hallazgos basados en datos.