Las APIs con fugas amenazan con arrastrar la reputación de las empresas
En la vida, por lo general, la comunicación es una gran cosa. No hay forma más rápida de llegar a un entendimiento, aprender algo nuevo o construir una relación. En el ámbito del software, las API cumplen una función comunicativa que permite que las aplicaciones se comuniquen entre sí, potenciando las funciones y la facilidad de uso. Esa conectividad suele crear una experiencia más rica que los usuarios finales adoran y, cada vez más, esperan del software en su vida cotidiana.
Sin embargo, como en la vida real, es un gran problema cuando hablan demasiado. Experian lo ha comprobado recientemente por las malas, cuando una de sus API -utilizada por un socio externo- filtró potencialmente las puntuaciones de crédito de... bueno, de casi todos los ciudadanos estadounidenses.
El problema fue parcheado rápidamente, pero siguen existiendo dudas sobre si esta vulnerabilidad fue realmente detenida en su camino. Si un proveedor se vio afectado, es muy probable que otros también lo estuvieran, y existe la posibilidad de que se trate de un fallo sistémico, que afecte a cualquiera que haga uso de esa API insegura.
La seguridad de las API es un tema que no está lejos de la mente de la mayoría de los expertos en seguridad, y es algo que tenemos que equiparnos con los conocimientos necesarios para combatirlo.
Cualquier geek de pacotilla puede saltarse la mala autentificación de la API
Una característica de muchas filtraciones de datos, brechas e incidentes de seguridad, es que rara vez se necesita una mente maestra para lograrlos. Los ataques complejos, insidiosos y dañinos como el que vimos con SolarWinds requieren equipos de genios cibercriminales para llevarse a cabo, y son la excepción más que la regla.
Cuando una API se construye con una autenticación débil, es bastante fácil que sea explotada. Bill Demirkapi, el investigador de seguridad que descubrió el fallo de la API de Experian, determinó que se podía acceder a ella sin ninguna autenticación. Al introducir el 00/00/0000 en el campo de la fecha de nacimiento, accedió a la puntuación de crédito de una persona, utilizando únicamente información disponible públicamente como el nombre y la dirección postal asociada. Aunque esto no se ha reportado, el potencial de estos registros para ser raspados y contextualizados como un volcado de datos relacionados con el crédito (y por lo tanto valiosos) está ciertamente allí.
Procesos de autenticación limpios y funcionales deben estar en su lugar, no importa lo pequeño que sea el caso de uso; una API de chatterbox que no está debidamente asegurada, y que potencialmente abre el acceso a múltiples sistemas, es una responsabilidad.
Broken Authentication es el número dos en la lista de las 10 principales vulnerabilidades de API de OWASP. Lee más aquí sobre cómo puedes evitar este fallo, y prueba tus habilidades en nuestra plataforma una vez que hayas terminado de alimentar tu cerebro.
Los malos controles de seguridad de las API son un problema generalizado que requiere un cambio cultural
No es justo señalar con el dedo únicamente a organizaciones como Experian, pero la falta de matiz y de diligencia en el control de la seguridad mostrada en esta exposición particular de la API no presagia nada bueno para las muchas empresas que navegan por las API como parte de sus sistemas de TI y puntos finales.
En general, tenemos mucho más trabajo que hacer no sólo para encontrar y arreglar las vulnerabilidades de las APIs, sino para entenderlas como parte de la superficie de ataque que debemos proteger. La visibilidad sobre las APIs - y cómo se han construido - es una gran preocupación, y es algo que debería exigirse como parte de las mejores prácticas de seguridad. Incluso una organización con las medidas de seguridad más estrictas puede verse perjudicada por una API que se publica y funciona fuera de los controles de seguridad de la empresa. Es más importante que nunca preguntarse de dónde procede una API, quién la mantiene en última instancia (¿es un proveedor externo? ¿Cómo de estrictos son con la seguridad?), y a qué información está accediendo.
Las vulnerabilidades de inyección siguen siendo un problema para todos los CISO.
La seguridad de las APIs puede parecer un módulo bastante nuevo para incluir en un programa de seguridad, pero puede ser explotado mediante algunos trucos (muy) antiguos que estamos acostumbrados a ver en el software web de toda la vida.
Un ataque recientemente revelado contra Acc ellion reveló que la inyección SQL encadenada y los ataques de ejecución de comandos del sistema operativo permitieron a los actores de la amenaza manipular las APIs, extrayendo un importante botín de datos sensibles, incluyendo los números de la Seguridad Social. Determinaron que los atacantes debían tener un amplio conocimiento del software FTA de Accellion para llevar a cabo el atraco, lo que habría sido posible mediante una importante ingeniería inversa.
Dado que la brecha se produjo en diciembre de 2020 y enero de 2021, los ladrones tuvieron tiempo suficiente para causar daños. Otros descubrimientos en febrero de 2021 revelaron una vulnerabilidad XSS almacenada, con un análisis forense que descubrió que solo un punto final de la API que tenía una entrada de usuario incorrectamente desinfectada hizo posible inyectar un argumento al llamar al script admin.pl.
Con más de 3.000 clientes, entre ellos muchas instituciones educativas de prestigio, esta brecha podría tener un gran alcance. Lo lamentable es que estos exploits fueron posibles aprovechando vulnerabilidades comunes, muchas de las cuales podrían haber sido abordadas a nivel de código, antes de la producción, por un desarrollador consciente de la seguridad. Como vemos una y otra vez, basta con dejar una pequeña ventana abierta para crear grandes problemas. Y una cultura de ciberdefensa dirigida por el ser humano debe formar parte de la estrategia para resolver un problema muy humano.
¿Quiere poner a prueba sus conocimientos de seguridad de la API ahora en Java Spring API, Kotlin Spring API, C# (.NET) Web API ¿y más? Pruebe algunos retos de API en nuestro Learning Platform (consulte todos los lenguajes:frameworks a través del desplegable):



La seguridad de las API es un tema que no está lejos de la mente de la mayoría de los expertos en seguridad, y es algo que tenemos que equiparnos con los conocimientos necesarios para combatirlo.
Director General, Presidente y Cofundador

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ónDirector General, Presidente y Cofundador
Pieter Danhieux es un experto en seguridad mundialmente reconocido, con más de 12 años de experiencia como consultor de seguridad y 8 años como instructor principal de SANS enseñando técnicas ofensivas sobre cómo atacar y evaluar organizaciones, sistemas y personas en busca de debilidades de seguridad. En 2016, fue reconocido como una de las personas más cool de la tecnología en Australia (Business Insider), galardonado como Profesional de Seguridad Cibernética del Año (AISA - Asociación Australiana de Seguridad de la Información) y tiene certificaciones GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.


En la vida, por lo general, la comunicación es una gran cosa. No hay forma más rápida de llegar a un entendimiento, aprender algo nuevo o construir una relación. En el ámbito del software, las API cumplen una función comunicativa que permite que las aplicaciones se comuniquen entre sí, potenciando las funciones y la facilidad de uso. Esa conectividad suele crear una experiencia más rica que los usuarios finales adoran y, cada vez más, esperan del software en su vida cotidiana.
Sin embargo, como en la vida real, es un gran problema cuando hablan demasiado. Experian lo ha comprobado recientemente por las malas, cuando una de sus API -utilizada por un socio externo- filtró potencialmente las puntuaciones de crédito de... bueno, de casi todos los ciudadanos estadounidenses.
El problema fue parcheado rápidamente, pero siguen existiendo dudas sobre si esta vulnerabilidad fue realmente detenida en su camino. Si un proveedor se vio afectado, es muy probable que otros también lo estuvieran, y existe la posibilidad de que se trate de un fallo sistémico, que afecte a cualquiera que haga uso de esa API insegura.
La seguridad de las API es un tema que no está lejos de la mente de la mayoría de los expertos en seguridad, y es algo que tenemos que equiparnos con los conocimientos necesarios para combatirlo.
Cualquier geek de pacotilla puede saltarse la mala autentificación de la API
Una característica de muchas filtraciones de datos, brechas e incidentes de seguridad, es que rara vez se necesita una mente maestra para lograrlos. Los ataques complejos, insidiosos y dañinos como el que vimos con SolarWinds requieren equipos de genios cibercriminales para llevarse a cabo, y son la excepción más que la regla.
Cuando una API se construye con una autenticación débil, es bastante fácil que sea explotada. Bill Demirkapi, el investigador de seguridad que descubrió el fallo de la API de Experian, determinó que se podía acceder a ella sin ninguna autenticación. Al introducir el 00/00/0000 en el campo de la fecha de nacimiento, accedió a la puntuación de crédito de una persona, utilizando únicamente información disponible públicamente como el nombre y la dirección postal asociada. Aunque esto no se ha reportado, el potencial de estos registros para ser raspados y contextualizados como un volcado de datos relacionados con el crédito (y por lo tanto valiosos) está ciertamente allí.
Procesos de autenticación limpios y funcionales deben estar en su lugar, no importa lo pequeño que sea el caso de uso; una API de chatterbox que no está debidamente asegurada, y que potencialmente abre el acceso a múltiples sistemas, es una responsabilidad.
Broken Authentication es el número dos en la lista de las 10 principales vulnerabilidades de API de OWASP. Lee más aquí sobre cómo puedes evitar este fallo, y prueba tus habilidades en nuestra plataforma una vez que hayas terminado de alimentar tu cerebro.
Los malos controles de seguridad de las API son un problema generalizado que requiere un cambio cultural
No es justo señalar con el dedo únicamente a organizaciones como Experian, pero la falta de matiz y de diligencia en el control de la seguridad mostrada en esta exposición particular de la API no presagia nada bueno para las muchas empresas que navegan por las API como parte de sus sistemas de TI y puntos finales.
En general, tenemos mucho más trabajo que hacer no sólo para encontrar y arreglar las vulnerabilidades de las APIs, sino para entenderlas como parte de la superficie de ataque que debemos proteger. La visibilidad sobre las APIs - y cómo se han construido - es una gran preocupación, y es algo que debería exigirse como parte de las mejores prácticas de seguridad. Incluso una organización con las medidas de seguridad más estrictas puede verse perjudicada por una API que se publica y funciona fuera de los controles de seguridad de la empresa. Es más importante que nunca preguntarse de dónde procede una API, quién la mantiene en última instancia (¿es un proveedor externo? ¿Cómo de estrictos son con la seguridad?), y a qué información está accediendo.
Las vulnerabilidades de inyección siguen siendo un problema para todos los CISO.
La seguridad de las APIs puede parecer un módulo bastante nuevo para incluir en un programa de seguridad, pero puede ser explotado mediante algunos trucos (muy) antiguos que estamos acostumbrados a ver en el software web de toda la vida.
Un ataque recientemente revelado contra Acc ellion reveló que la inyección SQL encadenada y los ataques de ejecución de comandos del sistema operativo permitieron a los actores de la amenaza manipular las APIs, extrayendo un importante botín de datos sensibles, incluyendo los números de la Seguridad Social. Determinaron que los atacantes debían tener un amplio conocimiento del software FTA de Accellion para llevar a cabo el atraco, lo que habría sido posible mediante una importante ingeniería inversa.
Dado que la brecha se produjo en diciembre de 2020 y enero de 2021, los ladrones tuvieron tiempo suficiente para causar daños. Otros descubrimientos en febrero de 2021 revelaron una vulnerabilidad XSS almacenada, con un análisis forense que descubrió que solo un punto final de la API que tenía una entrada de usuario incorrectamente desinfectada hizo posible inyectar un argumento al llamar al script admin.pl.
Con más de 3.000 clientes, entre ellos muchas instituciones educativas de prestigio, esta brecha podría tener un gran alcance. Lo lamentable es que estos exploits fueron posibles aprovechando vulnerabilidades comunes, muchas de las cuales podrían haber sido abordadas a nivel de código, antes de la producción, por un desarrollador consciente de la seguridad. Como vemos una y otra vez, basta con dejar una pequeña ventana abierta para crear grandes problemas. Y una cultura de ciberdefensa dirigida por el ser humano debe formar parte de la estrategia para resolver un problema muy humano.
¿Quiere poner a prueba sus conocimientos de seguridad de la API ahora en Java Spring API, Kotlin Spring API, C# (.NET) Web API ¿y más? Pruebe algunos retos de API en nuestro Learning Platform (consulte todos los lenguajes:frameworks a través del desplegable):


En la vida, por lo general, la comunicación es una gran cosa. No hay forma más rápida de llegar a un entendimiento, aprender algo nuevo o construir una relación. En el ámbito del software, las API cumplen una función comunicativa que permite que las aplicaciones se comuniquen entre sí, potenciando las funciones y la facilidad de uso. Esa conectividad suele crear una experiencia más rica que los usuarios finales adoran y, cada vez más, esperan del software en su vida cotidiana.
Sin embargo, como en la vida real, es un gran problema cuando hablan demasiado. Experian lo ha comprobado recientemente por las malas, cuando una de sus API -utilizada por un socio externo- filtró potencialmente las puntuaciones de crédito de... bueno, de casi todos los ciudadanos estadounidenses.
El problema fue parcheado rápidamente, pero siguen existiendo dudas sobre si esta vulnerabilidad fue realmente detenida en su camino. Si un proveedor se vio afectado, es muy probable que otros también lo estuvieran, y existe la posibilidad de que se trate de un fallo sistémico, que afecte a cualquiera que haga uso de esa API insegura.
La seguridad de las API es un tema que no está lejos de la mente de la mayoría de los expertos en seguridad, y es algo que tenemos que equiparnos con los conocimientos necesarios para combatirlo.
Cualquier geek de pacotilla puede saltarse la mala autentificación de la API
Una característica de muchas filtraciones de datos, brechas e incidentes de seguridad, es que rara vez se necesita una mente maestra para lograrlos. Los ataques complejos, insidiosos y dañinos como el que vimos con SolarWinds requieren equipos de genios cibercriminales para llevarse a cabo, y son la excepción más que la regla.
Cuando una API se construye con una autenticación débil, es bastante fácil que sea explotada. Bill Demirkapi, el investigador de seguridad que descubrió el fallo de la API de Experian, determinó que se podía acceder a ella sin ninguna autenticación. Al introducir el 00/00/0000 en el campo de la fecha de nacimiento, accedió a la puntuación de crédito de una persona, utilizando únicamente información disponible públicamente como el nombre y la dirección postal asociada. Aunque esto no se ha reportado, el potencial de estos registros para ser raspados y contextualizados como un volcado de datos relacionados con el crédito (y por lo tanto valiosos) está ciertamente allí.
Procesos de autenticación limpios y funcionales deben estar en su lugar, no importa lo pequeño que sea el caso de uso; una API de chatterbox que no está debidamente asegurada, y que potencialmente abre el acceso a múltiples sistemas, es una responsabilidad.
Broken Authentication es el número dos en la lista de las 10 principales vulnerabilidades de API de OWASP. Lee más aquí sobre cómo puedes evitar este fallo, y prueba tus habilidades en nuestra plataforma una vez que hayas terminado de alimentar tu cerebro.
Los malos controles de seguridad de las API son un problema generalizado que requiere un cambio cultural
No es justo señalar con el dedo únicamente a organizaciones como Experian, pero la falta de matiz y de diligencia en el control de la seguridad mostrada en esta exposición particular de la API no presagia nada bueno para las muchas empresas que navegan por las API como parte de sus sistemas de TI y puntos finales.
En general, tenemos mucho más trabajo que hacer no sólo para encontrar y arreglar las vulnerabilidades de las APIs, sino para entenderlas como parte de la superficie de ataque que debemos proteger. La visibilidad sobre las APIs - y cómo se han construido - es una gran preocupación, y es algo que debería exigirse como parte de las mejores prácticas de seguridad. Incluso una organización con las medidas de seguridad más estrictas puede verse perjudicada por una API que se publica y funciona fuera de los controles de seguridad de la empresa. Es más importante que nunca preguntarse de dónde procede una API, quién la mantiene en última instancia (¿es un proveedor externo? ¿Cómo de estrictos son con la seguridad?), y a qué información está accediendo.
Las vulnerabilidades de inyección siguen siendo un problema para todos los CISO.
La seguridad de las APIs puede parecer un módulo bastante nuevo para incluir en un programa de seguridad, pero puede ser explotado mediante algunos trucos (muy) antiguos que estamos acostumbrados a ver en el software web de toda la vida.
Un ataque recientemente revelado contra Acc ellion reveló que la inyección SQL encadenada y los ataques de ejecución de comandos del sistema operativo permitieron a los actores de la amenaza manipular las APIs, extrayendo un importante botín de datos sensibles, incluyendo los números de la Seguridad Social. Determinaron que los atacantes debían tener un amplio conocimiento del software FTA de Accellion para llevar a cabo el atraco, lo que habría sido posible mediante una importante ingeniería inversa.
Dado que la brecha se produjo en diciembre de 2020 y enero de 2021, los ladrones tuvieron tiempo suficiente para causar daños. Otros descubrimientos en febrero de 2021 revelaron una vulnerabilidad XSS almacenada, con un análisis forense que descubrió que solo un punto final de la API que tenía una entrada de usuario incorrectamente desinfectada hizo posible inyectar un argumento al llamar al script admin.pl.
Con más de 3.000 clientes, entre ellos muchas instituciones educativas de prestigio, esta brecha podría tener un gran alcance. Lo lamentable es que estos exploits fueron posibles aprovechando vulnerabilidades comunes, muchas de las cuales podrían haber sido abordadas a nivel de código, antes de la producción, por un desarrollador consciente de la seguridad. Como vemos una y otra vez, basta con dejar una pequeña ventana abierta para crear grandes problemas. Y una cultura de ciberdefensa dirigida por el ser humano debe formar parte de la estrategia para resolver un problema muy humano.
¿Quiere poner a prueba sus conocimientos de seguridad de la API ahora en Java Spring API, Kotlin Spring API, C# (.NET) Web API ¿y más? Pruebe algunos retos de API en nuestro Learning Platform (consulte todos los lenguajes:frameworks a través del desplegable):


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ónDirector General, Presidente y Cofundador
Pieter Danhieux es un experto en seguridad mundialmente reconocido, con más de 12 años de experiencia como consultor de seguridad y 8 años como instructor principal de SANS enseñando técnicas ofensivas sobre cómo atacar y evaluar organizaciones, sistemas y personas en busca de debilidades de seguridad. En 2016, fue reconocido como una de las personas más cool de la tecnología en Australia (Business Insider), galardonado como Profesional de Seguridad Cibernética del Año (AISA - Asociación Australiana de Seguridad de la Información) y tiene certificaciones GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
En la vida, por lo general, la comunicación es una gran cosa. No hay forma más rápida de llegar a un entendimiento, aprender algo nuevo o construir una relación. En el ámbito del software, las API cumplen una función comunicativa que permite que las aplicaciones se comuniquen entre sí, potenciando las funciones y la facilidad de uso. Esa conectividad suele crear una experiencia más rica que los usuarios finales adoran y, cada vez más, esperan del software en su vida cotidiana.
Sin embargo, como en la vida real, es un gran problema cuando hablan demasiado. Experian lo ha comprobado recientemente por las malas, cuando una de sus API -utilizada por un socio externo- filtró potencialmente las puntuaciones de crédito de... bueno, de casi todos los ciudadanos estadounidenses.
El problema fue parcheado rápidamente, pero siguen existiendo dudas sobre si esta vulnerabilidad fue realmente detenida en su camino. Si un proveedor se vio afectado, es muy probable que otros también lo estuvieran, y existe la posibilidad de que se trate de un fallo sistémico, que afecte a cualquiera que haga uso de esa API insegura.
La seguridad de las API es un tema que no está lejos de la mente de la mayoría de los expertos en seguridad, y es algo que tenemos que equiparnos con los conocimientos necesarios para combatirlo.
Cualquier geek de pacotilla puede saltarse la mala autentificación de la API
Una característica de muchas filtraciones de datos, brechas e incidentes de seguridad, es que rara vez se necesita una mente maestra para lograrlos. Los ataques complejos, insidiosos y dañinos como el que vimos con SolarWinds requieren equipos de genios cibercriminales para llevarse a cabo, y son la excepción más que la regla.
Cuando una API se construye con una autenticación débil, es bastante fácil que sea explotada. Bill Demirkapi, el investigador de seguridad que descubrió el fallo de la API de Experian, determinó que se podía acceder a ella sin ninguna autenticación. Al introducir el 00/00/0000 en el campo de la fecha de nacimiento, accedió a la puntuación de crédito de una persona, utilizando únicamente información disponible públicamente como el nombre y la dirección postal asociada. Aunque esto no se ha reportado, el potencial de estos registros para ser raspados y contextualizados como un volcado de datos relacionados con el crédito (y por lo tanto valiosos) está ciertamente allí.
Procesos de autenticación limpios y funcionales deben estar en su lugar, no importa lo pequeño que sea el caso de uso; una API de chatterbox que no está debidamente asegurada, y que potencialmente abre el acceso a múltiples sistemas, es una responsabilidad.
Broken Authentication es el número dos en la lista de las 10 principales vulnerabilidades de API de OWASP. Lee más aquí sobre cómo puedes evitar este fallo, y prueba tus habilidades en nuestra plataforma una vez que hayas terminado de alimentar tu cerebro.
Los malos controles de seguridad de las API son un problema generalizado que requiere un cambio cultural
No es justo señalar con el dedo únicamente a organizaciones como Experian, pero la falta de matiz y de diligencia en el control de la seguridad mostrada en esta exposición particular de la API no presagia nada bueno para las muchas empresas que navegan por las API como parte de sus sistemas de TI y puntos finales.
En general, tenemos mucho más trabajo que hacer no sólo para encontrar y arreglar las vulnerabilidades de las APIs, sino para entenderlas como parte de la superficie de ataque que debemos proteger. La visibilidad sobre las APIs - y cómo se han construido - es una gran preocupación, y es algo que debería exigirse como parte de las mejores prácticas de seguridad. Incluso una organización con las medidas de seguridad más estrictas puede verse perjudicada por una API que se publica y funciona fuera de los controles de seguridad de la empresa. Es más importante que nunca preguntarse de dónde procede una API, quién la mantiene en última instancia (¿es un proveedor externo? ¿Cómo de estrictos son con la seguridad?), y a qué información está accediendo.
Las vulnerabilidades de inyección siguen siendo un problema para todos los CISO.
La seguridad de las APIs puede parecer un módulo bastante nuevo para incluir en un programa de seguridad, pero puede ser explotado mediante algunos trucos (muy) antiguos que estamos acostumbrados a ver en el software web de toda la vida.
Un ataque recientemente revelado contra Acc ellion reveló que la inyección SQL encadenada y los ataques de ejecución de comandos del sistema operativo permitieron a los actores de la amenaza manipular las APIs, extrayendo un importante botín de datos sensibles, incluyendo los números de la Seguridad Social. Determinaron que los atacantes debían tener un amplio conocimiento del software FTA de Accellion para llevar a cabo el atraco, lo que habría sido posible mediante una importante ingeniería inversa.
Dado que la brecha se produjo en diciembre de 2020 y enero de 2021, los ladrones tuvieron tiempo suficiente para causar daños. Otros descubrimientos en febrero de 2021 revelaron una vulnerabilidad XSS almacenada, con un análisis forense que descubrió que solo un punto final de la API que tenía una entrada de usuario incorrectamente desinfectada hizo posible inyectar un argumento al llamar al script admin.pl.
Con más de 3.000 clientes, entre ellos muchas instituciones educativas de prestigio, esta brecha podría tener un gran alcance. Lo lamentable es que estos exploits fueron posibles aprovechando vulnerabilidades comunes, muchas de las cuales podrían haber sido abordadas a nivel de código, antes de la producción, por un desarrollador consciente de la seguridad. Como vemos una y otra vez, basta con dejar una pequeña ventana abierta para crear grandes problemas. Y una cultura de ciberdefensa dirigida por el ser humano debe formar parte de la estrategia para resolver un problema muy humano.
¿Quiere poner a prueba sus conocimientos de seguridad de la API ahora en Java Spring API, Kotlin Spring API, C# (.NET) Web API ¿y más? Pruebe algunos retos de API en nuestro Learning Platform (consulte todos los lenguajes:frameworks a través del desplegable):

Índice
Director General, Presidente y Cofundador

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.