Qué es un troyano y cómo se cuela en tu código fuente
A principios de noviembre, la Universidad de Cambridge publicó su investigación llamada Trojan-Source. Esta investigación se centraba en cómo se pueden ocultar puertas traseras en el código fuente y en los comentarios, utilizando caracteres de formato direccional. Éstos pueden utilizarse para elaborar código cuya lógica es interpretada por el compilador de forma diferente a la de un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de forma nefasta en el pasado, como por ejemplo ocultando la verdadera extensión de un archivo invirtiendo la dirección de la última parte de un nombre de archivo. La reciente investigación reveló que muchos compiladores ignoran los caracteres Unicode en el código fuente sin avisar, mientras que los editores de texto, incluidos los editores de código, pueden reflotar las líneas que contienen comentarios y código basados en ellos. Por lo tanto, el editor puede mostrar el código y los comentarios de forma diferente, y en un orden distinto, de cómo lo analizará el compilador, incluso intercambiando el código y los comentarios.
Sigue leyendo para saber más. O si quieres arremangarte y probar el hackeo simulado de Trojan Source, entra en nuestra misión pública y gratuita para experimentarlo por ti mismo.
Texto bidireccional
Uno de estos ataques de origen troyano hace uso del algoritmo Unicode Bidi (bidireccional), que maneja la forma de agrupar texto con un orden de visualización diferente, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Los caracteres de formato direccional pueden utilizarse para reorganizar la agrupación y mostrar el orden de los caracteres.
La tabla anterior contiene algunos de los caracteres de anulación de Bidi relevantes para el ataque. Por ejemplo,
RLI e d o c PDI
La abreviatura RLI significa Right-to-Left Isolate. Aislará el texto de su contexto (delimitado por PDI, Pop-Directional-Isolate), y lo leerá de derecha a izquierda. El resultado es:
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidos los Bidi, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccional, los analizarán:
e d o c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado, se han insertado caracteres de formato direccional en los nombres de archivos para disfrazar su naturaleza maliciosa. Un archivo adjunto de correo electrónico mostrado como "myspecialexe.doc" podría parecer bastante inocente, si no fuera por el carácter RLO(Right-to-Left override) presente que revela que el nombre real es "myspecialcod.exe".
El ataque Trojan Source inserta caracteres de formato direccional en los comentarios y cadenas presentes en el código fuente, ya que estos no generan ningún error de sintaxis o de compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código haciendo que el compilador lea algo totalmente diferente a lo que haría un humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
se reordenará de la siguiente manera por los caracteres de formato direccional
lo que hace que el código se muestre así si los caracteres de formato direccional no se llaman explícitamente:
La RLO cambia la llave de cierre por una llave de apertura, y viceversa en la última línea. El resultado de ejecutar este código sería: "Usted es un administrador". La comprobación de admin fue comentada, sin embargo los caracteres de control dan la impresión de que todavía está presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo puede afectarle esto?
Muchos lenguajes son vulnerables al ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se supone que hay más. Ahora bien, el desarrollador medio podría fruncir el ceño al ver caracteres de formato direccional en el código fuente, pero un novato podría encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca es una garantía de que sean detectados.
Pero, ¿cómo pudo colarse esta vulnerabilidad en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza el código fuente de fuentes poco fiables, donde las contribuciones de código malicioso han pasado desapercibidas. En segundo lugar, podría ocurrir por un simple copiar y pegar del código encontrado en Internet, algo que la mayoría de los desarrolladores hemos hecho antes. La mayoría de las organizaciones dependen de componentes de software de múltiples proveedores. Esto plantea la cuestión de hasta qué punto podemos confiar plenamente en este código. ¿Cómo podemos detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y los pipelines de compilación deberían no permitir líneas de código fuente con más de una dirección, a menos que una dirección esté estrictamente limitada a cadenas y comentarios. Tenga en cuenta que un carácter de formato direccional en una cadena o comentario puede, si no se salta, extender un cambio de dirección hasta el final de la línea. En general, los editores de código deberían representar y resaltar explícitamente los caracteres Unicode sospechosos, como los homoglifos y los caracteres de formato direccional. Desde noviembre, GitHub añade una señal y un mensaje de advertencia a cada línea de código que contenga texto unicode bidireccional, aunque no resalta en qué parte de la línea se encuentran estos caracteres. Esto todavía puede permitir que se cuelen cambios de dirección maliciosos junto con cambios de dirección benignos.
La concienciación de los desarrolladores y revisores de código es esencial, por lo que hemos creado un recorrido que ilustra la vulnerabilidad. Actualmente esta guía está disponible para Java, C#, Python, GO y PHP.
Así que si quieres saber más, prueba nuestra simulación (pública missions) de Trojan Source, y lee la investigación de Trojan Source.
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ón
Laura Verheyde es una desarrolladora de software en Secure Code Warrior centrada en la investigación de vulnerabilidades y la creación de contenidos para Missions y Coding labs.
A principios de noviembre, la Universidad de Cambridge publicó su investigación llamada Trojan-Source. Esta investigación se centraba en cómo se pueden ocultar puertas traseras en el código fuente y en los comentarios, utilizando caracteres de formato direccional. Éstos pueden utilizarse para elaborar código cuya lógica es interpretada por el compilador de forma diferente a la de un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de forma nefasta en el pasado, como por ejemplo ocultando la verdadera extensión de un archivo invirtiendo la dirección de la última parte de un nombre de archivo. La reciente investigación reveló que muchos compiladores ignoran los caracteres Unicode en el código fuente sin avisar, mientras que los editores de texto, incluidos los editores de código, pueden reflotar las líneas que contienen comentarios y código basados en ellos. Por lo tanto, el editor puede mostrar el código y los comentarios de forma diferente, y en un orden distinto, de cómo lo analizará el compilador, incluso intercambiando el código y los comentarios.
Sigue leyendo para saber más. O si quieres arremangarte y probar el hackeo simulado de Trojan Source, entra en nuestra misión pública y gratuita para experimentarlo por ti mismo.
Texto bidireccional
Uno de estos ataques de origen troyano hace uso del algoritmo Unicode Bidi (bidireccional), que maneja la forma de agrupar texto con un orden de visualización diferente, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Los caracteres de formato direccional pueden utilizarse para reorganizar la agrupación y mostrar el orden de los caracteres.
La tabla anterior contiene algunos de los caracteres de anulación de Bidi relevantes para el ataque. Por ejemplo,
RLI e d o c PDI
La abreviatura RLI significa Right-to-Left Isolate. Aislará el texto de su contexto (delimitado por PDI, Pop-Directional-Isolate), y lo leerá de derecha a izquierda. El resultado es:
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidos los Bidi, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccional, los analizarán:
e d o c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado, se han insertado caracteres de formato direccional en los nombres de archivos para disfrazar su naturaleza maliciosa. Un archivo adjunto de correo electrónico mostrado como "myspecialexe.doc" podría parecer bastante inocente, si no fuera por el carácter RLO(Right-to-Left override) presente que revela que el nombre real es "myspecialcod.exe".
El ataque Trojan Source inserta caracteres de formato direccional en los comentarios y cadenas presentes en el código fuente, ya que estos no generan ningún error de sintaxis o de compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código haciendo que el compilador lea algo totalmente diferente a lo que haría un humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
se reordenará de la siguiente manera por los caracteres de formato direccional
lo que hace que el código se muestre así si los caracteres de formato direccional no se llaman explícitamente:
La RLO cambia la llave de cierre por una llave de apertura, y viceversa en la última línea. El resultado de ejecutar este código sería: "Usted es un administrador". La comprobación de admin fue comentada, sin embargo los caracteres de control dan la impresión de que todavía está presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo puede afectarle esto?
Muchos lenguajes son vulnerables al ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se supone que hay más. Ahora bien, el desarrollador medio podría fruncir el ceño al ver caracteres de formato direccional en el código fuente, pero un novato podría encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca es una garantía de que sean detectados.
Pero, ¿cómo pudo colarse esta vulnerabilidad en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza el código fuente de fuentes poco fiables, donde las contribuciones de código malicioso han pasado desapercibidas. En segundo lugar, podría ocurrir por un simple copiar y pegar del código encontrado en Internet, algo que la mayoría de los desarrolladores hemos hecho antes. La mayoría de las organizaciones dependen de componentes de software de múltiples proveedores. Esto plantea la cuestión de hasta qué punto podemos confiar plenamente en este código. ¿Cómo podemos detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y los pipelines de compilación deberían no permitir líneas de código fuente con más de una dirección, a menos que una dirección esté estrictamente limitada a cadenas y comentarios. Tenga en cuenta que un carácter de formato direccional en una cadena o comentario puede, si no se salta, extender un cambio de dirección hasta el final de la línea. En general, los editores de código deberían representar y resaltar explícitamente los caracteres Unicode sospechosos, como los homoglifos y los caracteres de formato direccional. Desde noviembre, GitHub añade una señal y un mensaje de advertencia a cada línea de código que contenga texto unicode bidireccional, aunque no resalta en qué parte de la línea se encuentran estos caracteres. Esto todavía puede permitir que se cuelen cambios de dirección maliciosos junto con cambios de dirección benignos.
La concienciación de los desarrolladores y revisores de código es esencial, por lo que hemos creado un recorrido que ilustra la vulnerabilidad. Actualmente esta guía está disponible para Java, C#, Python, GO y PHP.
Así que si quieres saber más, prueba nuestra simulación (pública missions) de Trojan Source, y lee la investigación de Trojan Source.
A principios de noviembre, la Universidad de Cambridge publicó su investigación llamada Trojan-Source. Esta investigación se centraba en cómo se pueden ocultar puertas traseras en el código fuente y en los comentarios, utilizando caracteres de formato direccional. Éstos pueden utilizarse para elaborar código cuya lógica es interpretada por el compilador de forma diferente a la de un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de forma nefasta en el pasado, como por ejemplo ocultando la verdadera extensión de un archivo invirtiendo la dirección de la última parte de un nombre de archivo. La reciente investigación reveló que muchos compiladores ignoran los caracteres Unicode en el código fuente sin avisar, mientras que los editores de texto, incluidos los editores de código, pueden reflotar las líneas que contienen comentarios y código basados en ellos. Por lo tanto, el editor puede mostrar el código y los comentarios de forma diferente, y en un orden distinto, de cómo lo analizará el compilador, incluso intercambiando el código y los comentarios.
Sigue leyendo para saber más. O si quieres arremangarte y probar el hackeo simulado de Trojan Source, entra en nuestra misión pública y gratuita para experimentarlo por ti mismo.
Texto bidireccional
Uno de estos ataques de origen troyano hace uso del algoritmo Unicode Bidi (bidireccional), que maneja la forma de agrupar texto con un orden de visualización diferente, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Los caracteres de formato direccional pueden utilizarse para reorganizar la agrupación y mostrar el orden de los caracteres.
La tabla anterior contiene algunos de los caracteres de anulación de Bidi relevantes para el ataque. Por ejemplo,
RLI e d o c PDI
La abreviatura RLI significa Right-to-Left Isolate. Aislará el texto de su contexto (delimitado por PDI, Pop-Directional-Isolate), y lo leerá de derecha a izquierda. El resultado es:
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidos los Bidi, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccional, los analizarán:
e d o c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado, se han insertado caracteres de formato direccional en los nombres de archivos para disfrazar su naturaleza maliciosa. Un archivo adjunto de correo electrónico mostrado como "myspecialexe.doc" podría parecer bastante inocente, si no fuera por el carácter RLO(Right-to-Left override) presente que revela que el nombre real es "myspecialcod.exe".
El ataque Trojan Source inserta caracteres de formato direccional en los comentarios y cadenas presentes en el código fuente, ya que estos no generan ningún error de sintaxis o de compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código haciendo que el compilador lea algo totalmente diferente a lo que haría un humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
se reordenará de la siguiente manera por los caracteres de formato direccional
lo que hace que el código se muestre así si los caracteres de formato direccional no se llaman explícitamente:
La RLO cambia la llave de cierre por una llave de apertura, y viceversa en la última línea. El resultado de ejecutar este código sería: "Usted es un administrador". La comprobación de admin fue comentada, sin embargo los caracteres de control dan la impresión de que todavía está presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo puede afectarle esto?
Muchos lenguajes son vulnerables al ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se supone que hay más. Ahora bien, el desarrollador medio podría fruncir el ceño al ver caracteres de formato direccional en el código fuente, pero un novato podría encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca es una garantía de que sean detectados.
Pero, ¿cómo pudo colarse esta vulnerabilidad en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza el código fuente de fuentes poco fiables, donde las contribuciones de código malicioso han pasado desapercibidas. En segundo lugar, podría ocurrir por un simple copiar y pegar del código encontrado en Internet, algo que la mayoría de los desarrolladores hemos hecho antes. La mayoría de las organizaciones dependen de componentes de software de múltiples proveedores. Esto plantea la cuestión de hasta qué punto podemos confiar plenamente en este código. ¿Cómo podemos detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y los pipelines de compilación deberían no permitir líneas de código fuente con más de una dirección, a menos que una dirección esté estrictamente limitada a cadenas y comentarios. Tenga en cuenta que un carácter de formato direccional en una cadena o comentario puede, si no se salta, extender un cambio de dirección hasta el final de la línea. En general, los editores de código deberían representar y resaltar explícitamente los caracteres Unicode sospechosos, como los homoglifos y los caracteres de formato direccional. Desde noviembre, GitHub añade una señal y un mensaje de advertencia a cada línea de código que contenga texto unicode bidireccional, aunque no resalta en qué parte de la línea se encuentran estos caracteres. Esto todavía puede permitir que se cuelen cambios de dirección maliciosos junto con cambios de dirección benignos.
La concienciación de los desarrolladores y revisores de código es esencial, por lo que hemos creado un recorrido que ilustra la vulnerabilidad. Actualmente esta guía está disponible para Java, C#, Python, GO y PHP.
Así que si quieres saber más, prueba nuestra simulación (pública missions) de Trojan Source, y lee la investigación de Trojan Source.
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ón
Laura Verheyde es una desarrolladora de software en Secure Code Warrior centrada en la investigación de vulnerabilidades y la creación de contenidos para Missions y Coding labs.
A principios de noviembre, la Universidad de Cambridge publicó su investigación llamada Trojan-Source. Esta investigación se centraba en cómo se pueden ocultar puertas traseras en el código fuente y en los comentarios, utilizando caracteres de formato direccional. Éstos pueden utilizarse para elaborar código cuya lógica es interpretada por el compilador de forma diferente a la de un revisor de código humano.
Esta vulnerabilidad es nueva, aunque Unicode se ha utilizado de forma nefasta en el pasado, como por ejemplo ocultando la verdadera extensión de un archivo invirtiendo la dirección de la última parte de un nombre de archivo. La reciente investigación reveló que muchos compiladores ignoran los caracteres Unicode en el código fuente sin avisar, mientras que los editores de texto, incluidos los editores de código, pueden reflotar las líneas que contienen comentarios y código basados en ellos. Por lo tanto, el editor puede mostrar el código y los comentarios de forma diferente, y en un orden distinto, de cómo lo analizará el compilador, incluso intercambiando el código y los comentarios.
Sigue leyendo para saber más. O si quieres arremangarte y probar el hackeo simulado de Trojan Source, entra en nuestra misión pública y gratuita para experimentarlo por ti mismo.
Texto bidireccional
Uno de estos ataques de origen troyano hace uso del algoritmo Unicode Bidi (bidireccional), que maneja la forma de agrupar texto con un orden de visualización diferente, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Los caracteres de formato direccional pueden utilizarse para reorganizar la agrupación y mostrar el orden de los caracteres.
La tabla anterior contiene algunos de los caracteres de anulación de Bidi relevantes para el ataque. Por ejemplo,
RLI e d o c PDI
La abreviatura RLI significa Right-to-Left Isolate. Aislará el texto de su contexto (delimitado por PDI, Pop-Directional-Isolate), y lo leerá de derecha a izquierda. El resultado es:
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidos los Bidi, antes de analizar el código fuente. Si simplemente ignoran los caracteres de formato direccional, los analizarán:
e d o c
¿Vino viejo en botellas nuevas?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado, se han insertado caracteres de formato direccional en los nombres de archivos para disfrazar su naturaleza maliciosa. Un archivo adjunto de correo electrónico mostrado como "myspecialexe.doc" podría parecer bastante inocente, si no fuera por el carácter RLO(Right-to-Left override) presente que revela que el nombre real es "myspecialcod.exe".
El ataque Trojan Source inserta caracteres de formato direccional en los comentarios y cadenas presentes en el código fuente, ya que estos no generan ningún error de sintaxis o de compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código haciendo que el compilador lea algo totalmente diferente a lo que haría un humano.
Por ejemplo, un archivo que contenga los siguientes bytes en este orden:
se reordenará de la siguiente manera por los caracteres de formato direccional
lo que hace que el código se muestre así si los caracteres de formato direccional no se llaman explícitamente:
La RLO cambia la llave de cierre por una llave de apertura, y viceversa en la última línea. El resultado de ejecutar este código sería: "Usted es un administrador". La comprobación de admin fue comentada, sin embargo los caracteres de control dan la impresión de que todavía está presente.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo puede afectarle esto?
Muchos lenguajes son vulnerables al ataque: C, C++, C#, JavaScript, Java, Rust, Go y Python, y se supone que hay más. Ahora bien, el desarrollador medio podría fruncir el ceño al ver caracteres de formato direccional en el código fuente, pero un novato podría encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres depende en gran medida del IDE, por lo que nunca es una garantía de que sean detectados.
Pero, ¿cómo pudo colarse esta vulnerabilidad en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza el código fuente de fuentes poco fiables, donde las contribuciones de código malicioso han pasado desapercibidas. En segundo lugar, podría ocurrir por un simple copiar y pegar del código encontrado en Internet, algo que la mayoría de los desarrolladores hemos hecho antes. La mayoría de las organizaciones dependen de componentes de software de múltiples proveedores. Esto plantea la cuestión de hasta qué punto podemos confiar plenamente en este código. ¿Cómo podemos detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, los compiladores y los pipelines de compilación deberían no permitir líneas de código fuente con más de una dirección, a menos que una dirección esté estrictamente limitada a cadenas y comentarios. Tenga en cuenta que un carácter de formato direccional en una cadena o comentario puede, si no se salta, extender un cambio de dirección hasta el final de la línea. En general, los editores de código deberían representar y resaltar explícitamente los caracteres Unicode sospechosos, como los homoglifos y los caracteres de formato direccional. Desde noviembre, GitHub añade una señal y un mensaje de advertencia a cada línea de código que contenga texto unicode bidireccional, aunque no resalta en qué parte de la línea se encuentran estos caracteres. Esto todavía puede permitir que se cuelen cambios de dirección maliciosos junto con cambios de dirección benignos.
La concienciación de los desarrolladores y revisores de código es esencial, por lo que hemos creado un recorrido que ilustra la vulnerabilidad. Actualmente esta guía está disponible para Java, C#, Python, GO y PHP.
Así que si quieres saber más, prueba nuestra simulación (pública missions) de Trojan Source, y lee la investigación de Trojan Source.
Índice
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
Panorama de la gestión de riesgos de los promotores
La gestión de riesgos del desarrollador es un enfoque holístico y proactivo de la seguridad de las aplicaciones, centrado en quienes contribuyen al código y no en los bits y bytes de la propia capa de la aplicación.
Seguridad desde el diseño: Definición de las mejores prácticas, capacitación de los desarrolladores y evaluación comparativa de los resultados de la seguridad preventiva
En este documento de investigación, los cofundadores Secure Code Warrior , Pieter Danhieux y el Dr. Matias Madou, Ph.D., junto con los expertos colaboradores, Chris Inglis, ex Director Nacional Cibernético de EE.UU. (ahora Asesor Estratégico de Paladin Capital Group), y Devin Lynch, Director Senior, Paladin Global Institute, revelarán los hallazgos clave de más de veinte entrevistas en profundidad con líderes de seguridad empresarial, incluyendo CISOs, un VP de Seguridad de Aplicaciones y profesionales de seguridad de software.
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.
Recursos para empezar
Revelado: Cómo define el sector cibernético la seguridad por diseño
En nuestro último libro blanco, nuestros cofundadores, Pieter Danhieux y el doctor Matias Madou, se sentaron con más de veinte líderes de seguridad empresarial, incluidos CISO, líderes de AppSec y profesionales de la seguridad, para averiguar las piezas clave de este rompecabezas y descubrir la realidad detrás del movimiento Secure by Design. Se trata de una ambición compartida por todos los equipos de seguridad, pero no de un libro de jugadas compartido.
¿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.
Codificación orientada al desarrollador.
Con seguridad.
Póngase en contacto con nosotros hoy mismo y haga de la seguridad del software una parte intrínseca de su proceso de desarrollo.
