Coders Conquer Security Infrastructure as Code Series - Uso de componentes de fuentes no fiables
Nos acercamos al final de nuestra serie Infrastructure as Code, pero ha sido estupendo ayudar a desarrolladores como tú en su viaje de seguridad IaC.
¿Has jugado a los retos? ¿Cuál es tu puntuación hasta ahora? Antes de empezar, veamos cuánto sabes ya sobre los peligros de usar componentes de fuentes no confiables:
¿Todavía tiene trabajo que hacer? Sigue leyendo:
El comportamiento que induce a la vulnerabilidad en el que nos vamos a centrar hoy es el uso de código de fuentes no confiables, una práctica aparentemente benigna que está causando grandes problemas. El uso de código y recursos de código abierto tiene muchas ventajas. En general, permite que los expertos aporten sus ideas, su trabajo e incluso el código completo a repositorios como GitHub para que lo utilicen otras personas que luchan por hacer que un programa o una aplicación se comporten correctamente. El uso de código completo para gobernar las funciones del programa evita que los desarrolladores tengan que reinventar la rueda cada vez que necesitan crear una nueva aplicación.
Sin embargo, utilizar fragmentos de código de fuentes no fiables, no verificadas o incluso potencialmente peligrosas conlleva un gran riesgo. De hecho, el uso de código de fuentes no confiables es una de las formas más comunes en que las vulnerabilidades de seguridad, tanto mayores como menores, se cuelan en aplicaciones que de otro modo serían seguras. A veces, esas vulnerabilidades son inducidas accidentalmente por sus creadores. También ha habido casos en los que el código malicioso fue escrito por atacantes potenciales. El código se comparte entonces con la esperanza de atrapar a las víctimas que lo introducirán en sus aplicaciones.
¿Por qué es peligroso utilizar código de fuentes no fiables?
Supongamos que un desarrollador tiene prisa y necesita configurar una aplicación que está desarrollando. Puede ser un proceso complicado. Así que en lugar de pasar mucho tiempo tratando de resolver todas las configuraciones posibles, hacen una búsqueda en Google y encuentran a alguien que ya ha completado un archivo de configuración aparentemente perfecto. Aunque el desarrollador no sabe nada de la persona que escribió el código, añadirlo a una nueva aplicación es relativamente fácil. Se puede hacer en el entorno Docker utilizando dos líneas:
RUN cd /etc/apache2/sites-available/ && \00 wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\3 fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Ahora la imagen de Docker tirará dinámicamente del archivo de configuración de terceros. E incluso si el archivo se prueba y se encuentra bien en el momento, el hecho de que el puntero está ahora incrustado en el código de la nueva aplicación significa que hay una dependencia permanente en el lugar. Días, semanas o meses después, el archivo podría ser alterado por el autor original o por un atacante que haya comprometido el repositorio de código. De repente, el archivo de configuración compartido puede decirle a la aplicación que funcione de forma muy diferente a la prevista, posiblemente dando acceso a usuarios no autorizados o incluso robando directamente los datos y exfiltrándolos.
Una mejor manera de utilizar los recursos compartidos
Si su organización permite el uso de código de fuentes externas, deben establecerse procesos para garantizar que se hace de forma segura. Cuando evalúe el código externo para su posible uso, asegúrese de adquirir componentes de fuentes oficiales sólo mediante enlaces seguros. E incluso en ese caso, nunca debe enlazar con una fuente externa para extraer ese código, ya que eso elimina el proceso de su control. En su lugar, el código aprobado debe ser llevado a una biblioteca segura y sólo utilizado desde esa ubicación protegida. Así que en un entorno Docker, el código se vería así:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
En lugar de depender de archivos de configuración de terceros remotos, esto se basaría en una copia local de esos archivos. Esto evitará que se realicen cambios inesperados o maliciosos.
Además de utilizar una biblioteca de código seguro, debe establecerse un proceso de gestión de parches para supervisar continuamente los componentes a lo largo del ciclo de vida del software. Todos los componentes del lado del cliente y del servidor también deben ser revisados para detectar alertas de seguridad utilizando herramientas como NVD o CVE. Por último, hay que eliminar las dependencias y funciones no utilizadas o innecesarias que puedan aparecer en el código externo.
Siguiendo estos pasos, los desarrolladores pueden hacer un uso más seguro de los recursos externos sin inducir accidentalmente vulnerabilidades en sus aplicaciones y código.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puedes probar una demostración de los retos de IaC en la plataforma de formación Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.
El comportamiento que induce a la vulnerabilidad en el que nos vamos a centrar aquí es el uso de código de fuentes no confiables, una práctica aparentemente benigna que está causando grandes problemas.
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
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
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
Nos acercamos al final de nuestra serie Infrastructure as Code, pero ha sido estupendo ayudar a desarrolladores como tú en su viaje de seguridad IaC.
¿Has jugado a los retos? ¿Cuál es tu puntuación hasta ahora? Antes de empezar, veamos cuánto sabes ya sobre los peligros de usar componentes de fuentes no confiables:
¿Todavía tiene trabajo que hacer? Sigue leyendo:
El comportamiento que induce a la vulnerabilidad en el que nos vamos a centrar hoy es el uso de código de fuentes no confiables, una práctica aparentemente benigna que está causando grandes problemas. El uso de código y recursos de código abierto tiene muchas ventajas. En general, permite que los expertos aporten sus ideas, su trabajo e incluso el código completo a repositorios como GitHub para que lo utilicen otras personas que luchan por hacer que un programa o una aplicación se comporten correctamente. El uso de código completo para gobernar las funciones del programa evita que los desarrolladores tengan que reinventar la rueda cada vez que necesitan crear una nueva aplicación.
Sin embargo, utilizar fragmentos de código de fuentes no fiables, no verificadas o incluso potencialmente peligrosas conlleva un gran riesgo. De hecho, el uso de código de fuentes no confiables es una de las formas más comunes en que las vulnerabilidades de seguridad, tanto mayores como menores, se cuelan en aplicaciones que de otro modo serían seguras. A veces, esas vulnerabilidades son inducidas accidentalmente por sus creadores. También ha habido casos en los que el código malicioso fue escrito por atacantes potenciales. El código se comparte entonces con la esperanza de atrapar a las víctimas que lo introducirán en sus aplicaciones.
¿Por qué es peligroso utilizar código de fuentes no fiables?
Supongamos que un desarrollador tiene prisa y necesita configurar una aplicación que está desarrollando. Puede ser un proceso complicado. Así que en lugar de pasar mucho tiempo tratando de resolver todas las configuraciones posibles, hacen una búsqueda en Google y encuentran a alguien que ya ha completado un archivo de configuración aparentemente perfecto. Aunque el desarrollador no sabe nada de la persona que escribió el código, añadirlo a una nueva aplicación es relativamente fácil. Se puede hacer en el entorno Docker utilizando dos líneas:
RUN cd /etc/apache2/sites-available/ && \00 wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\3 fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Ahora la imagen de Docker tirará dinámicamente del archivo de configuración de terceros. E incluso si el archivo se prueba y se encuentra bien en el momento, el hecho de que el puntero está ahora incrustado en el código de la nueva aplicación significa que hay una dependencia permanente en el lugar. Días, semanas o meses después, el archivo podría ser alterado por el autor original o por un atacante que haya comprometido el repositorio de código. De repente, el archivo de configuración compartido puede decirle a la aplicación que funcione de forma muy diferente a la prevista, posiblemente dando acceso a usuarios no autorizados o incluso robando directamente los datos y exfiltrándolos.
Una mejor manera de utilizar los recursos compartidos
Si su organización permite el uso de código de fuentes externas, deben establecerse procesos para garantizar que se hace de forma segura. Cuando evalúe el código externo para su posible uso, asegúrese de adquirir componentes de fuentes oficiales sólo mediante enlaces seguros. E incluso en ese caso, nunca debe enlazar con una fuente externa para extraer ese código, ya que eso elimina el proceso de su control. En su lugar, el código aprobado debe ser llevado a una biblioteca segura y sólo utilizado desde esa ubicación protegida. Así que en un entorno Docker, el código se vería así:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
En lugar de depender de archivos de configuración de terceros remotos, esto se basaría en una copia local de esos archivos. Esto evitará que se realicen cambios inesperados o maliciosos.
Además de utilizar una biblioteca de código seguro, debe establecerse un proceso de gestión de parches para supervisar continuamente los componentes a lo largo del ciclo de vida del software. Todos los componentes del lado del cliente y del servidor también deben ser revisados para detectar alertas de seguridad utilizando herramientas como NVD o CVE. Por último, hay que eliminar las dependencias y funciones no utilizadas o innecesarias que puedan aparecer en el código externo.
Siguiendo estos pasos, los desarrolladores pueden hacer un uso más seguro de los recursos externos sin inducir accidentalmente vulnerabilidades en sus aplicaciones y código.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puedes probar una demostración de los retos de IaC en la plataforma de formación Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.
Nos acercamos al final de nuestra serie Infrastructure as Code, pero ha sido estupendo ayudar a desarrolladores como tú en su viaje de seguridad IaC.
¿Has jugado a los retos? ¿Cuál es tu puntuación hasta ahora? Antes de empezar, veamos cuánto sabes ya sobre los peligros de usar componentes de fuentes no confiables:
¿Todavía tiene trabajo que hacer? Sigue leyendo:
El comportamiento que induce a la vulnerabilidad en el que nos vamos a centrar hoy es el uso de código de fuentes no confiables, una práctica aparentemente benigna que está causando grandes problemas. El uso de código y recursos de código abierto tiene muchas ventajas. En general, permite que los expertos aporten sus ideas, su trabajo e incluso el código completo a repositorios como GitHub para que lo utilicen otras personas que luchan por hacer que un programa o una aplicación se comporten correctamente. El uso de código completo para gobernar las funciones del programa evita que los desarrolladores tengan que reinventar la rueda cada vez que necesitan crear una nueva aplicación.
Sin embargo, utilizar fragmentos de código de fuentes no fiables, no verificadas o incluso potencialmente peligrosas conlleva un gran riesgo. De hecho, el uso de código de fuentes no confiables es una de las formas más comunes en que las vulnerabilidades de seguridad, tanto mayores como menores, se cuelan en aplicaciones que de otro modo serían seguras. A veces, esas vulnerabilidades son inducidas accidentalmente por sus creadores. También ha habido casos en los que el código malicioso fue escrito por atacantes potenciales. El código se comparte entonces con la esperanza de atrapar a las víctimas que lo introducirán en sus aplicaciones.
¿Por qué es peligroso utilizar código de fuentes no fiables?
Supongamos que un desarrollador tiene prisa y necesita configurar una aplicación que está desarrollando. Puede ser un proceso complicado. Así que en lugar de pasar mucho tiempo tratando de resolver todas las configuraciones posibles, hacen una búsqueda en Google y encuentran a alguien que ya ha completado un archivo de configuración aparentemente perfecto. Aunque el desarrollador no sabe nada de la persona que escribió el código, añadirlo a una nueva aplicación es relativamente fácil. Se puede hacer en el entorno Docker utilizando dos líneas:
RUN cd /etc/apache2/sites-available/ && \00 wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\3 fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Ahora la imagen de Docker tirará dinámicamente del archivo de configuración de terceros. E incluso si el archivo se prueba y se encuentra bien en el momento, el hecho de que el puntero está ahora incrustado en el código de la nueva aplicación significa que hay una dependencia permanente en el lugar. Días, semanas o meses después, el archivo podría ser alterado por el autor original o por un atacante que haya comprometido el repositorio de código. De repente, el archivo de configuración compartido puede decirle a la aplicación que funcione de forma muy diferente a la prevista, posiblemente dando acceso a usuarios no autorizados o incluso robando directamente los datos y exfiltrándolos.
Una mejor manera de utilizar los recursos compartidos
Si su organización permite el uso de código de fuentes externas, deben establecerse procesos para garantizar que se hace de forma segura. Cuando evalúe el código externo para su posible uso, asegúrese de adquirir componentes de fuentes oficiales sólo mediante enlaces seguros. E incluso en ese caso, nunca debe enlazar con una fuente externa para extraer ese código, ya que eso elimina el proceso de su control. En su lugar, el código aprobado debe ser llevado a una biblioteca segura y sólo utilizado desde esa ubicación protegida. Así que en un entorno Docker, el código se vería así:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
En lugar de depender de archivos de configuración de terceros remotos, esto se basaría en una copia local de esos archivos. Esto evitará que se realicen cambios inesperados o maliciosos.
Además de utilizar una biblioteca de código seguro, debe establecerse un proceso de gestión de parches para supervisar continuamente los componentes a lo largo del ciclo de vida del software. Todos los componentes del lado del cliente y del servidor también deben ser revisados para detectar alertas de seguridad utilizando herramientas como NVD o CVE. Por último, hay que eliminar las dependencias y funciones no utilizadas o innecesarias que puedan aparecer en el código externo.
Siguiendo estos pasos, los desarrolladores pueden hacer un uso más seguro de los recursos externos sin inducir accidentalmente vulnerabilidades en sus aplicaciones y código.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puedes probar una demostración de los retos de IaC en la plataforma de formación Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.
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
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
Nos acercamos al final de nuestra serie Infrastructure as Code, pero ha sido estupendo ayudar a desarrolladores como tú en su viaje de seguridad IaC.
¿Has jugado a los retos? ¿Cuál es tu puntuación hasta ahora? Antes de empezar, veamos cuánto sabes ya sobre los peligros de usar componentes de fuentes no confiables:
¿Todavía tiene trabajo que hacer? Sigue leyendo:
El comportamiento que induce a la vulnerabilidad en el que nos vamos a centrar hoy es el uso de código de fuentes no confiables, una práctica aparentemente benigna que está causando grandes problemas. El uso de código y recursos de código abierto tiene muchas ventajas. En general, permite que los expertos aporten sus ideas, su trabajo e incluso el código completo a repositorios como GitHub para que lo utilicen otras personas que luchan por hacer que un programa o una aplicación se comporten correctamente. El uso de código completo para gobernar las funciones del programa evita que los desarrolladores tengan que reinventar la rueda cada vez que necesitan crear una nueva aplicación.
Sin embargo, utilizar fragmentos de código de fuentes no fiables, no verificadas o incluso potencialmente peligrosas conlleva un gran riesgo. De hecho, el uso de código de fuentes no confiables es una de las formas más comunes en que las vulnerabilidades de seguridad, tanto mayores como menores, se cuelan en aplicaciones que de otro modo serían seguras. A veces, esas vulnerabilidades son inducidas accidentalmente por sus creadores. También ha habido casos en los que el código malicioso fue escrito por atacantes potenciales. El código se comparte entonces con la esperanza de atrapar a las víctimas que lo introducirán en sus aplicaciones.
¿Por qué es peligroso utilizar código de fuentes no fiables?
Supongamos que un desarrollador tiene prisa y necesita configurar una aplicación que está desarrollando. Puede ser un proceso complicado. Así que en lugar de pasar mucho tiempo tratando de resolver todas las configuraciones posibles, hacen una búsqueda en Google y encuentran a alguien que ya ha completado un archivo de configuración aparentemente perfecto. Aunque el desarrollador no sabe nada de la persona que escribió el código, añadirlo a una nueva aplicación es relativamente fácil. Se puede hacer en el entorno Docker utilizando dos líneas:
RUN cd /etc/apache2/sites-available/ && \00 wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\3 fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Ahora la imagen de Docker tirará dinámicamente del archivo de configuración de terceros. E incluso si el archivo se prueba y se encuentra bien en el momento, el hecho de que el puntero está ahora incrustado en el código de la nueva aplicación significa que hay una dependencia permanente en el lugar. Días, semanas o meses después, el archivo podría ser alterado por el autor original o por un atacante que haya comprometido el repositorio de código. De repente, el archivo de configuración compartido puede decirle a la aplicación que funcione de forma muy diferente a la prevista, posiblemente dando acceso a usuarios no autorizados o incluso robando directamente los datos y exfiltrándolos.
Una mejor manera de utilizar los recursos compartidos
Si su organización permite el uso de código de fuentes externas, deben establecerse procesos para garantizar que se hace de forma segura. Cuando evalúe el código externo para su posible uso, asegúrese de adquirir componentes de fuentes oficiales sólo mediante enlaces seguros. E incluso en ese caso, nunca debe enlazar con una fuente externa para extraer ese código, ya que eso elimina el proceso de su control. En su lugar, el código aprobado debe ser llevado a una biblioteca segura y sólo utilizado desde esa ubicación protegida. Así que en un entorno Docker, el código se vería así:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
En lugar de depender de archivos de configuración de terceros remotos, esto se basaría en una copia local de esos archivos. Esto evitará que se realicen cambios inesperados o maliciosos.
Además de utilizar una biblioteca de código seguro, debe establecerse un proceso de gestión de parches para supervisar continuamente los componentes a lo largo del ciclo de vida del software. Todos los componentes del lado del cliente y del servidor también deben ser revisados para detectar alertas de seguridad utilizando herramientas como NVD o CVE. Por último, hay que eliminar las dependencias y funciones no utilizadas o innecesarias que puedan aparecer en el código externo.
Siguiendo estos pasos, los desarrolladores pueden hacer un uso más seguro de los recursos externos sin inducir accidentalmente vulnerabilidades en sus aplicaciones y código.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puedes probar una demostración de los retos de IaC en la plataforma de formación Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.
Índice
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
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
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.
Recursos para empezar
Estableciendo el estándar: SCW publica reglas de seguridad de codificación de IA gratuitas en GitHub
El desarrollo asistido por IA ya no es una posibilidad: ya está aquí y está transformando rápidamente la forma de escribir software. Herramientas como GitHub Copilot, Cline, Roo, Cursor, Aider y Windsurf están transformando a los desarrolladores en sus propios copilotos, permitiendo iteraciones más rápidas y acelerando todo, desde la creación de prototipos hasta grandes proyectos de refactorización.
Cierre el círculo de las vulnerabilidades con Secure Code Warrior + HackerOne
Secure Code Warrior se complace en anunciar nuestra nueva integración con HackerOne, líder en soluciones de seguridad ofensiva. Juntos, estamos construyendo un ecosistema potente e integrado. HackerOne señala dónde se producen realmente las vulnerabilidades en entornos reales, exponiendo el "qué" y el "dónde" de los problemas de seguridad.
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.
