¿Qué es el código fuente de Trojan y cómo se infiltra en el código fuente?
A principios de noviembre, la Universidad de Cambridge publicó lo siguiente: un estudio titulado «Trojan Horse-Source». Este estudio se centró en cómo se pueden ocultar puertas traseras en el código fuente y los comentarios utilizando caracteres de formato direccionales. Esto se puede utilizar para crear código que el compilador interprete de forma diferente a los revisores de código humanos.
Aunque Unicode se ha utilizado maliciosamente en el pasado, por ejemplo, para ocultar la extensión real del nombre de un archivo, esta vulnerabilidad es nueva. Cambio de la dirección de la parte final del nombre del archivo. Según estudios recientes, muchos compiladores ignoran los caracteres Unicode del código fuente sin mostrar ninguna advertencia, mientras que los editores de texto, incluidos los editores de código, pueden reajustar las líneas que contienen comentarios y código basándose en ellos. Por lo tanto, los editores pueden mostrar el código y los comentarios en un orden diferente al que utiliza el compilador para analizarlos. Esto también ocurre incluso cuando se intercambian el código y los comentarios.
Para obtener más información, siga leyendo. O si desea probar la simulación de hackeo de Trojan Source, acceda directamente al servicio gratuito. Experimente directamente las misiones públicas.
Texto bidireccional
Uno de estos ataques de código malicioso utiliza el algoritmo Unicode Bidi (bidireccional). Este algoritmo gestiona la forma de alinear textos con diferentes direcciones de visualización, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Se pueden utilizar caracteres de formato de dirección para reorganizar grupos y mostrar el orden de los caracteres.
La tabla anterior incluye algunos caracteres de anulación Bidi relacionados con el ataque. Por ejemplo,
RLI e d o c PD
La abreviatura RLI significa lo siguiente: Separación de derecha a izquierda. Separa el texto del contexto (separado por PDI). Haga clic en Pop Directional Isolate y lea de derecha a izquierda. El resultado es el siguiente.
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidos los de anulación bidireccional, antes de analizar el código fuente. Si se ignoran los caracteres de especificación de dirección, el análisis se realiza de la siguiente manera.
e d o c
¿Vino añejo en una botella nueva?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado se utilizaban caracteres de dirección. Se insertaban en los nombres de los archivos para ocultar su naturaleza maliciosa. Un archivo adjunto de correo electrónico con el nombre «myspecialexe.doc» podría parecer bastante inocente si no fuera por el RLO (override de derecha a izquierda), que revela que su nombre real es «myspecialcod.exe».
Los ataques de código fuente Trojan insertan caracteres de formato direccionales en los comentarios y cadenas de caracteres del código fuente. Esto se debe a que, en estos casos, no se producen errores sintácticos ni de compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, lo que hace que el compilador lea algo completamente diferente a lo que lee una persona.
Por ejemplo, un archivo que contenga los siguientes bytes en orden:
Se reordena según el formato de dirección por cada carácter, como se indica a continuación.
Si no se especifica explícitamente el carácter de formato de dirección, el código se renderizará de la siguiente manera.
RLO invierte el corchete de cierre de la última línea por un corchete de apertura, y viceversa. Al ejecutar este código, se obtiene el siguiente resultado: «Usted es administrador». Aunque la comprobación de administrador se ha comentado, al observar los caracteres de control se tiene la impresión de que dicha comprobación sigue existiendo.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo podría afectarles esto?
C, C++, C#, JavaScript, Java, Rust, Go, Python y muchos otros lenguajes son vulnerables a los ataques, y se cree que hay más idiomas vulnerables a los ataques. Ahora, los desarrolladores habituales pueden fruncir el ceño al ver los caracteres de dirección en el código fuente, pero los principiantes pueden encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres varía mucho según el IDE, por lo que no hay garantía de que se detecten.
Pero, ¿cómo pudo infiltrarse esta vulnerabilidad en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza código fuente de fuentes poco fiables en las que no se detectan contribuciones de código malicioso. En segundo lugar, esto puede ocurrir simplemente copiando y pegando código encontrado en Internet. Es algo que la mayoría de los desarrolladores hemos hecho alguna vez. La mayoría de las organizaciones dependen de componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto se puede confiar en este código y si es fiable. ¿Cómo se puede detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, el compilador y el canal de compilación no deben 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.Cabe señalar que los caracteres de formato de dirección de cadenas o comentarios pueden extender el cambio de dirección hasta el final de la línea si no se eliminan. Por lo general, los editores de código deben renderizar y resaltar explícitamente los caracteres Unicode sospechosos, como los homógrafos y los caracteres de formato de dirección. Desde noviembre, GitHub añade ahora un símbolo de advertencia y un mensaje a todas las líneas de código que contienen texto Unicode bidireccional. Sin embargo, la posición de estos caracteres en la línea no se resaltará. Esto significa que aún es posible introducir cambios de dirección maliciosos de forma encubierta.
La comunicación entre desarrolladores y revisores de código es esencial, por lo que hemos creado una guía que explica las vulnerabilidades. Actualmente, este ejercicio está disponible en Java, C#, Python, GO y PHP.
Si desea obtener más información, pruebe nuestro producto: simulación de código fuente Trojan (misión pública) y lea Investigación de código fuente Trojan.
Secure Code Warrior está aquí para ayudar a las organizaciones a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura que priorice la ciberseguridad. Ya seas administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudarte a reducir los riesgos asociados al código inseguro en tu organización.
Reserva de demostración
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ó lo siguiente: un estudio titulado «Trojan Horse-Source». Este estudio se centró en cómo se pueden ocultar puertas traseras en el código fuente y los comentarios utilizando caracteres de formato direccionales. Esto se puede utilizar para crear código que el compilador interprete de forma diferente a los revisores de código humanos.
Aunque Unicode se ha utilizado maliciosamente en el pasado, por ejemplo, para ocultar la extensión real del nombre de un archivo, esta vulnerabilidad es nueva. Cambio de la dirección de la parte final del nombre del archivo. Según estudios recientes, muchos compiladores ignoran los caracteres Unicode del código fuente sin mostrar ninguna advertencia, mientras que los editores de texto, incluidos los editores de código, pueden reajustar las líneas que contienen comentarios y código basándose en ellos. Por lo tanto, los editores pueden mostrar el código y los comentarios en un orden diferente al que utiliza el compilador para analizarlos. Esto también ocurre incluso cuando se intercambian el código y los comentarios.
Para obtener más información, siga leyendo. O si desea probar la simulación de hackeo de Trojan Source, acceda directamente al servicio gratuito. Experimente directamente las misiones públicas.
Texto bidireccional
Uno de estos ataques de código malicioso utiliza el algoritmo Unicode Bidi (bidireccional). Este algoritmo gestiona la forma de alinear textos con diferentes direcciones de visualización, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Se pueden utilizar caracteres de formato de dirección para reorganizar grupos y mostrar el orden de los caracteres.
La tabla anterior incluye algunos caracteres de anulación Bidi relacionados con el ataque. Por ejemplo,
RLI e d o c PD
La abreviatura RLI significa lo siguiente: Separación de derecha a izquierda. Separa el texto del contexto (separado por PDI). Haga clic en Pop Directional Isolate y lea de derecha a izquierda. El resultado es el siguiente.
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidos los de anulación bidireccional, antes de analizar el código fuente. Si se ignoran los caracteres de especificación de dirección, el análisis se realiza de la siguiente manera.
e d o c
¿Vino añejo en una botella nueva?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado se utilizaban caracteres de dirección. Se insertaban en los nombres de los archivos para ocultar su naturaleza maliciosa. Un archivo adjunto de correo electrónico con el nombre «myspecialexe.doc» podría parecer bastante inocente si no fuera por el RLO (override de derecha a izquierda), que revela que su nombre real es «myspecialcod.exe».
Los ataques de código fuente Trojan insertan caracteres de formato direccionales en los comentarios y cadenas de caracteres del código fuente. Esto se debe a que, en estos casos, no se producen errores sintácticos ni de compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, lo que hace que el compilador lea algo completamente diferente a lo que lee una persona.
Por ejemplo, un archivo que contenga los siguientes bytes en orden:
Se reordena según el formato de dirección por cada carácter, como se indica a continuación.
Si no se especifica explícitamente el carácter de formato de dirección, el código se renderizará de la siguiente manera.
RLO invierte el corchete de cierre de la última línea por un corchete de apertura, y viceversa. Al ejecutar este código, se obtiene el siguiente resultado: «Usted es administrador». Aunque la comprobación de administrador se ha comentado, al observar los caracteres de control se tiene la impresión de que dicha comprobación sigue existiendo.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo podría afectarles esto?
C, C++, C#, JavaScript, Java, Rust, Go, Python y muchos otros lenguajes son vulnerables a los ataques, y se cree que hay más idiomas vulnerables a los ataques. Ahora, los desarrolladores habituales pueden fruncir el ceño al ver los caracteres de dirección en el código fuente, pero los principiantes pueden encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres varía mucho según el IDE, por lo que no hay garantía de que se detecten.
Pero, ¿cómo pudo infiltrarse esta vulnerabilidad en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza código fuente de fuentes poco fiables en las que no se detectan contribuciones de código malicioso. En segundo lugar, esto puede ocurrir simplemente copiando y pegando código encontrado en Internet. Es algo que la mayoría de los desarrolladores hemos hecho alguna vez. La mayoría de las organizaciones dependen de componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto se puede confiar en este código y si es fiable. ¿Cómo se puede detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, el compilador y el canal de compilación no deben 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.Cabe señalar que los caracteres de formato de dirección de cadenas o comentarios pueden extender el cambio de dirección hasta el final de la línea si no se eliminan. Por lo general, los editores de código deben renderizar y resaltar explícitamente los caracteres Unicode sospechosos, como los homógrafos y los caracteres de formato de dirección. Desde noviembre, GitHub añade ahora un símbolo de advertencia y un mensaje a todas las líneas de código que contienen texto Unicode bidireccional. Sin embargo, la posición de estos caracteres en la línea no se resaltará. Esto significa que aún es posible introducir cambios de dirección maliciosos de forma encubierta.
La comunicación entre desarrolladores y revisores de código es esencial, por lo que hemos creado una guía que explica las vulnerabilidades. Actualmente, este ejercicio está disponible en Java, C#, Python, GO y PHP.
Si desea obtener más información, pruebe nuestro producto: simulación de código fuente Trojan (misión pública) y lea Investigación de código fuente Trojan.
A principios de noviembre, la Universidad de Cambridge publicó lo siguiente: un estudio titulado «Trojan Horse-Source». Este estudio se centró en cómo se pueden ocultar puertas traseras en el código fuente y los comentarios utilizando caracteres de formato direccionales. Esto se puede utilizar para crear código que el compilador interprete de forma diferente a los revisores de código humanos.
Aunque Unicode se ha utilizado maliciosamente en el pasado, por ejemplo, para ocultar la extensión real del nombre de un archivo, esta vulnerabilidad es nueva. Cambio de la dirección de la parte final del nombre del archivo. Según estudios recientes, muchos compiladores ignoran los caracteres Unicode del código fuente sin mostrar ninguna advertencia, mientras que los editores de texto, incluidos los editores de código, pueden reajustar las líneas que contienen comentarios y código basándose en ellos. Por lo tanto, los editores pueden mostrar el código y los comentarios en un orden diferente al que utiliza el compilador para analizarlos. Esto también ocurre incluso cuando se intercambian el código y los comentarios.
Para obtener más información, siga leyendo. O si desea probar la simulación de hackeo de Trojan Source, acceda directamente al servicio gratuito. Experimente directamente las misiones públicas.
Texto bidireccional
Uno de estos ataques de código malicioso utiliza el algoritmo Unicode Bidi (bidireccional). Este algoritmo gestiona la forma de alinear textos con diferentes direcciones de visualización, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Se pueden utilizar caracteres de formato de dirección para reorganizar grupos y mostrar el orden de los caracteres.
La tabla anterior incluye algunos caracteres de anulación Bidi relacionados con el ataque. Por ejemplo,
RLI e d o c PD
La abreviatura RLI significa lo siguiente: Separación de derecha a izquierda. Separa el texto del contexto (separado por PDI). Haga clic en Pop Directional Isolate y lea de derecha a izquierda. El resultado es el siguiente.
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidos los de anulación bidireccional, antes de analizar el código fuente. Si se ignoran los caracteres de especificación de dirección, el análisis se realiza de la siguiente manera.
e d o c
¿Vino añejo en una botella nueva?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado se utilizaban caracteres de dirección. Se insertaban en los nombres de los archivos para ocultar su naturaleza maliciosa. Un archivo adjunto de correo electrónico con el nombre «myspecialexe.doc» podría parecer bastante inocente si no fuera por el RLO (override de derecha a izquierda), que revela que su nombre real es «myspecialcod.exe».
Los ataques de código fuente Trojan insertan caracteres de formato direccionales en los comentarios y cadenas de caracteres del código fuente. Esto se debe a que, en estos casos, no se producen errores sintácticos ni de compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, lo que hace que el compilador lea algo completamente diferente a lo que lee una persona.
Por ejemplo, un archivo que contenga los siguientes bytes en orden:
Se reordena según el formato de dirección por cada carácter, como se indica a continuación.
Si no se especifica explícitamente el carácter de formato de dirección, el código se renderizará de la siguiente manera.
RLO invierte el corchete de cierre de la última línea por un corchete de apertura, y viceversa. Al ejecutar este código, se obtiene el siguiente resultado: «Usted es administrador». Aunque la comprobación de administrador se ha comentado, al observar los caracteres de control se tiene la impresión de que dicha comprobación sigue existiendo.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo podría afectarles esto?
C, C++, C#, JavaScript, Java, Rust, Go, Python y muchos otros lenguajes son vulnerables a los ataques, y se cree que hay más idiomas vulnerables a los ataques. Ahora, los desarrolladores habituales pueden fruncir el ceño al ver los caracteres de dirección en el código fuente, pero los principiantes pueden encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres varía mucho según el IDE, por lo que no hay garantía de que se detecten.
Pero, ¿cómo pudo infiltrarse esta vulnerabilidad en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza código fuente de fuentes poco fiables en las que no se detectan contribuciones de código malicioso. En segundo lugar, esto puede ocurrir simplemente copiando y pegando código encontrado en Internet. Es algo que la mayoría de los desarrolladores hemos hecho alguna vez. La mayoría de las organizaciones dependen de componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto se puede confiar en este código y si es fiable. ¿Cómo se puede detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, el compilador y el canal de compilación no deben 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.Cabe señalar que los caracteres de formato de dirección de cadenas o comentarios pueden extender el cambio de dirección hasta el final de la línea si no se eliminan. Por lo general, los editores de código deben renderizar y resaltar explícitamente los caracteres Unicode sospechosos, como los homógrafos y los caracteres de formato de dirección. Desde noviembre, GitHub añade ahora un símbolo de advertencia y un mensaje a todas las líneas de código que contienen texto Unicode bidireccional. Sin embargo, la posición de estos caracteres en la línea no se resaltará. Esto significa que aún es posible introducir cambios de dirección maliciosos de forma encubierta.
La comunicación entre desarrolladores y revisores de código es esencial, por lo que hemos creado una guía que explica las vulnerabilidades. Actualmente, este ejercicio está disponible en Java, C#, Python, GO y PHP.
Si desea obtener más información, pruebe nuestro producto: simulación de código fuente Trojan (misión pública) y lea Investigación de código fuente Trojan.
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está aquí para ayudar a las organizaciones a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura que priorice la ciberseguridad. Ya seas administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudarte a reducir los riesgos asociados al código inseguro en tu organización.
Ver informeReserva de demostración
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ó lo siguiente: un estudio titulado «Trojan Horse-Source». Este estudio se centró en cómo se pueden ocultar puertas traseras en el código fuente y los comentarios utilizando caracteres de formato direccionales. Esto se puede utilizar para crear código que el compilador interprete de forma diferente a los revisores de código humanos.
Aunque Unicode se ha utilizado maliciosamente en el pasado, por ejemplo, para ocultar la extensión real del nombre de un archivo, esta vulnerabilidad es nueva. Cambio de la dirección de la parte final del nombre del archivo. Según estudios recientes, muchos compiladores ignoran los caracteres Unicode del código fuente sin mostrar ninguna advertencia, mientras que los editores de texto, incluidos los editores de código, pueden reajustar las líneas que contienen comentarios y código basándose en ellos. Por lo tanto, los editores pueden mostrar el código y los comentarios en un orden diferente al que utiliza el compilador para analizarlos. Esto también ocurre incluso cuando se intercambian el código y los comentarios.
Para obtener más información, siga leyendo. O si desea probar la simulación de hackeo de Trojan Source, acceda directamente al servicio gratuito. Experimente directamente las misiones públicas.
Texto bidireccional
Uno de estos ataques de código malicioso utiliza el algoritmo Unicode Bidi (bidireccional). Este algoritmo gestiona la forma de alinear textos con diferentes direcciones de visualización, como el inglés (de izquierda a derecha) y el árabe (de derecha a izquierda). Se pueden utilizar caracteres de formato de dirección para reorganizar grupos y mostrar el orden de los caracteres.
La tabla anterior incluye algunos caracteres de anulación Bidi relacionados con el ataque. Por ejemplo,
RLI e d o c PD
La abreviatura RLI significa lo siguiente: Separación de derecha a izquierda. Separa el texto del contexto (separado por PDI). Haga clic en Pop Directional Isolate y lea de derecha a izquierda. El resultado es el siguiente.
c o d e
Sin embargo, los compiladores e intérpretes no suelen procesar los caracteres de control de formato, incluidos los de anulación bidireccional, antes de analizar el código fuente. Si se ignoran los caracteres de especificación de dirección, el análisis se realiza de la siguiente manera.
e d o c
¿Vino añejo en una botella nueva?
Por supuesto, esto no es nada nuevo bajo el sol. En el pasado se utilizaban caracteres de dirección. Se insertaban en los nombres de los archivos para ocultar su naturaleza maliciosa. Un archivo adjunto de correo electrónico con el nombre «myspecialexe.doc» podría parecer bastante inocente si no fuera por el RLO (override de derecha a izquierda), que revela que su nombre real es «myspecialcod.exe».
Los ataques de código fuente Trojan insertan caracteres de formato direccionales en los comentarios y cadenas de caracteres del código fuente. Esto se debe a que, en estos casos, no se producen errores sintácticos ni de compilación. Estos caracteres de control cambian el orden de visualización de la lógica del código, lo que hace que el compilador lea algo completamente diferente a lo que lee una persona.
Por ejemplo, un archivo que contenga los siguientes bytes en orden:
Se reordena según el formato de dirección por cada carácter, como se indica a continuación.
Si no se especifica explícitamente el carácter de formato de dirección, el código se renderizará de la siguiente manera.
RLO invierte el corchete de cierre de la última línea por un corchete de apertura, y viceversa. Al ejecutar este código, se obtiene el siguiente resultado: «Usted es administrador». Aunque la comprobación de administrador se ha comentado, al observar los caracteres de control se tiene la impresión de que dicha comprobación sigue existiendo.
(Fuente: https://github.com/nickboucher/trojan-source/blob/main/C%23/commenting-out.csx)
¿Cómo podría afectarles esto?
C, C++, C#, JavaScript, Java, Rust, Go, Python y muchos otros lenguajes son vulnerables a los ataques, y se cree que hay más idiomas vulnerables a los ataques. Ahora, los desarrolladores habituales pueden fruncir el ceño al ver los caracteres de dirección en el código fuente, pero los principiantes pueden encogerse de hombros y no pensar en ello. Además, la visualización de estos caracteres varía mucho según el IDE, por lo que no hay garantía de que se detecten.
Pero, ¿cómo pudo infiltrarse esta vulnerabilidad en el código fuente en primer lugar? En primer lugar, esto puede ocurrir cuando se utiliza código fuente de fuentes poco fiables en las que no se detectan contribuciones de código malicioso. En segundo lugar, esto puede ocurrir simplemente copiando y pegando código encontrado en Internet. Es algo que la mayoría de los desarrolladores hemos hecho alguna vez. La mayoría de las organizaciones dependen de componentes de software de varios proveedores. Esto plantea la pregunta de hasta qué punto se puede confiar en este código y si es fiable. ¿Cómo se puede detectar el código fuente que contiene puertas traseras ocultas?
¿De quién es el problema?
Por un lado, el compilador y el canal de compilación no deben 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.Cabe señalar que los caracteres de formato de dirección de cadenas o comentarios pueden extender el cambio de dirección hasta el final de la línea si no se eliminan. Por lo general, los editores de código deben renderizar y resaltar explícitamente los caracteres Unicode sospechosos, como los homógrafos y los caracteres de formato de dirección. Desde noviembre, GitHub añade ahora un símbolo de advertencia y un mensaje a todas las líneas de código que contienen texto Unicode bidireccional. Sin embargo, la posición de estos caracteres en la línea no se resaltará. Esto significa que aún es posible introducir cambios de dirección maliciosos de forma encubierta.
La comunicación entre desarrolladores y revisores de código es esencial, por lo que hemos creado una guía que explica las vulnerabilidades. Actualmente, este ejercicio está disponible en Java, C#, Python, GO y PHP.
Si desea obtener más información, pruebe nuestro producto: simulación de código fuente Trojan (misión pública) y lea Investigación de código fuente Trojan.
Índice
Secure Code Warrior está aquí para ayudar a las organizaciones a proteger el código durante todo el ciclo de vida del desarrollo de software y a crear una cultura que priorice la ciberseguridad. Ya seas administrador de AppSec, desarrollador, CISO o cualquier persona relacionada con la seguridad, podemos ayudarte a reducir los riesgos asociados al código inseguro en tu organización.
Reserva de demostraciónDescargarRecursos útiles para empezar
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
El poder de la seguridad de aplicaciones OpenText + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
.png)
