Perspectivas sobre el código seguro

¿Sabía que el 67% de los desarrolladores admite haber enviado código con vulnerabilidades? Imagínese un equipo de trabajadores de la construcción encargado de construir una casa. Tienen todos los materiales y herramientas que necesitan, pero se esfuerzan por seguir los planos y los códigos de construcción. Como resultado, cometen errores y la casa no se construye conforme a las normas.

Esta analogía puede utilizarse para ilustrar los retos a los que se enfrentan los desarrolladores cuando intentan practicar una codificación segura. Al igual que los trabajadores de la construcción tienen que seguir planos y códigos de edificación para asegurarse de que sus casas son seguras, los desarrolladores tienen que seguir prácticas de codificación segura para garantizar que sus aplicaciones de software son seguras.

Hay varias razones por las que la codificación segura puede ser un reto. Por ejemplo:

• Desconocimiento de las prácticas de codificación segura. El 86% de los desarrolladores afirman que les resulta difícil practicar la codificación segura.
• Falta de tiempo y recursos. El 24 % de los encuestados afirma que "no disponer de tiempo suficiente" es el mayor impedimento para integrar código seguro.
• La complejidad de la codificación segura. El 63% de los desarrolladores considera difícil escribir código seguro y libre de vulnerabilidades.
• Exceso de confianza en las herramientas. El 57% de los equipos de seguridad de aplicaciones utilizan seis o más herramientas para descubrir vulnerabilidades durante el ciclo de vida de DevSecOps.(GitLab, 2023)

Sin embargo, a pesar de los retos, la codificación segura es esencial. Siguiendo prácticas de codificación segura, los desarrolladores pueden ayudar a proteger sus aplicaciones de vulnerabilidades que puedan ser aprovechadas por los atacantes. Al igual que una casa bien construida tiene menos probabilidades de derrumbarse, una aplicación bien codificada tiene menos probabilidades de ser pirateada.

He aquí algunos consejos para los desarrolladores que deseen mejorar sus prácticas de codificación segura:

• Obtenga formación y educación sobre codificación segura. Hay varios recursos disponibles para ayudar a los desarrolladores a aprender prácticas de codificación segura.
• Utilice herramientas de análisis estático para identificar vulnerabilidades en el código. Las herramientas de análisis estático pueden ayudar a identificar vulnerabilidades en el código que pueden ser difíciles de encontrar manualmente.
• Escriba código fácil de revisar y comprender. El código fácil de revisar y comprender tiene más probabilidades de ser seguro.
• Pruebe el código a fondo. Probar el código puede ayudar a identificar y corregir vulnerabilidades antes de que sean explotadas.

¿Le interesa saber más? Descubre los secretos para desarrollar una estrategia ágil de código seguro con nuestro plan de aprendizaje de código seguro. 

‍

‍

‍

‍

En Secure Code Warrior, innovamos constantemente para ayudar a equipar a los desarrolladores y las organizaciones con las habilidades adecuadas para hacer frente a los desafíos de seguridad en constante cambio de la actualidad. Lo hacemos mediante una habilitación de código seguro altamente atractiva, flexible y fácil de administrar.

Todo el mundo quiere un buen retorno de su inversión cuando se trata de invertir en su oferta tecnológica o en programas de formación adicionales. Sin embargo, cuando se trata de seguridad, es necesario jugar a largo plazo. Invertir en una seguridad impulsada por los desarrolladores no solo mitigará el riesgo de costosas brechas de seguridad, la pérdida de productividad y la deuda tecnológica acumulada, sino que también creará una estrategia proactiva y rentable para mantenerse a la vanguardia del panorama actual de amenazas.

El último trimestre, Secure Core Warriors implementó nuevas formas de aprender con Coding Labs, que ahora está disponible para todos los clientes de Secure Code Warrior. Nos complace anunciar las mejoras en la gestión de la participación y en el control de versiones de los cursos, ¡y hemos creado nuevas actividades para los cursos, como las directrices!

¡Vamos a sumergirnos para obtener más información!

Ampliación de la amplitud y profundidad de la plataforma SCW

La continua expansión de Secure Code Warrior nuevos contenidos ayuda a mantener nuestros módulos relevantes, oportunos y adaptados a lo que necesita saber en el panorama actual de la ciberseguridad. Con una amplitud y profundidad líderes en el sector, con más de 55 idiomas, es fácil crear y escalar un programa para capacitar a los desarrolladores en una gran cantidad de lenguajes y marcos.

Pautas de codificación disponibles en los cursos

La adición de directrices ofrece a los desarrolladores un aprendizaje contextual y a su propio ritmo que cubre principalmente la mitigación de la seguridad. Las directrices son más detalladas que los vídeos y se centran en un lenguaje o marco específico. Otras actividades ofensivas, como los desafíos, las misiones y los tutoriales, ya requieren que los desarrolladores comprendan la vulnerabilidad. Hemos creado unas directrices para complementar estas actividades desde un punto de vista defensivo.

Los desarrolladores pueden leer las directrices de los cursos y los administradores pueden utilizarlas en las plantillas de los cursos. Las directrices abordan las vulnerabilidades incluidas en la lista de las 10 principales vulnerabilidades de OWASP de 2021 y contienen fragmentos de código en C#, Java, JavaScript, Python, Pseudocode y PHP.

Nuevo contenido del desafío

Secure Code Warrior actualiza periódicamente y crea nuevos desafíos que son relevantes, oportunos y adaptados a las necesidades de su organización. Nos complace anunciar la ampliación de los desafíos disponibles en:

• Dart: Flutter: un lenguaje móvil para crear aplicaciones multiplataforma fluidas en Android e iOS
• Terraform: GCP: una infraestructura como lenguaje de desarrollo de código para Google Cloud Provide.

Los desarrolladores pueden analizar el código, encontrar la vulnerabilidad y aplicar el pensamiento crítico para elegir la mejor implementación de seguridad para evitar las vulnerabilidades enumeradas.

Próximamente: nuevo contenido para desarrolladores de front-end

¡Los desarrolladores de front-end también necesitan habilitar código seguro! Por eso, publicaremos vulnerabilidades adicionales en la interfaz de usuario en las misiones y los tutoriales. Los desarrolladores de la interfaz de usuario también podrán acceder a misiones específicas de la interfaz de usuario en los cursos.

Estas actualizaciones buscan una cobertura integral de las vulnerabilidades específicas de la interfaz, desde las más comunes, como el XSS basado en DOM, hasta las vulnerabilidades menos frecuentes, como la inyección de CSS.

Los tutoriales paso a paso proporcionarán a los desarrolladores de front-end una guía confiable sobre cómo se explotan las vulnerabilidades. Los desarrolladores avanzados también podrán poner a prueba sus habilidades en las misiones iniciales de los torneos.

Simplificación de la experiencia de administradores y desarrolladores

Configurar un programa educativo de código seguro escalable y atractivo ahora es más fácil que nunca gracias a las mejoras clave de usabilidad de la plataforma.

‍

Gestión de versiones, archivado y participación de los cursos

Ahora, manténgase al día con las necesidades cambiantes del programa de una organización con nuevas formas de editar los programas existentes. El control de versiones de los cursos permite a los administradores editar sus cursos existentes sin tener que crear un curso completamente nuevo. Los administradores también pueden eliminar los cursos de prueba o los cursos no relevantes en los que no haya ningún desarrollador inscrito, lo que les ayuda a ordenar sus archivos.

Además, la posibilidad de aplicar filtros adicionales en la página de gestión del curso hará que sea mucho más sencillo para los administradores filtrar hasta el curso en el que quieren trabajar. Los cursos se pueden filtrar según una serie de atributos, como el estado del curso, la fecha de finalización y los equipos inscritos. Por ejemplo, los administradores pueden localizar fácilmente todos los cursos con un límite de tiempo, con una evaluación de fin de curso adjunta o si el curso está en borrador o en versión preliminar.

Además de controlar las versiones y filtrar los cursos, los administradores ahora pueden volver a invitar a los participantes del curso de forma masiva, así como eliminarlos de un curso según sea necesario. Esto permite a los administradores volver a invitar a los desarrolladores con un solo clic en el estado de «invitados», lo que les permite ahorrar tiempo y energía valiosos al recordarles que deben volver a la plataforma y empezar a aprender.

‍

¡Esto es el resumen de las nuevas capacidades de este trimestre! ¡Sigue Secure Code Warrior en Twitter para obtener actualizaciones sobre las últimas versiones y mejoras.

¿Está interesado en probar Secure Code Warrior pero aún no tiene una cuenta? Inscríbase en una cuenta de prueba gratuita hoy para empezar.

En esta ocasión anual tan festiva para los profesionales de la ciberseguridad, Mes nacional de concientización sobre ciberseguridad es un momento que muchas empresas utilizan para reflexionar y evaluar la conciencia general sobre la seguridad en toda la organización. ¿Y con El 62% de las empresas sufren un ataque de suplantación de identidad o ingeniería social Solo en 2018, no se puede exagerar la importancia de garantizar que todas las personas de la empresa, ya sea que desempeñen una función de seguridad o no, reciban una formación adecuada en materia de ciberseguridad.

Como un evento cada vez más global, el mes representa un punto culminante para debatir las mejores prácticas, y las iniciativas son deliberadamente superficiales. Sin embargo, incluso las organizaciones con programas de seguridad sólidos y especialistas internos pueden aprovechar este tiempo para evaluar a los equipos más técnicos y determinar qué necesitan para ser más conscientes de la seguridad en el contexto de su función.

Para los especialistas de AppSec, los líderes de equipos de desarrollo y los miembros de la cohorte de ingeniería más expertos en seguridad, puede parecer un poco como si les enseñaran a chupar huevos, pero son estos campeones de la empresa los que pueden llevar la seguridad y la protección a nuevas cotas en toda la empresa.

Cómo mejorar su mes de concientización sobre ciberseguridad

Esta es una excelente oportunidad para que el equipo de seguridad extienda una especie de rama de olivo al equipo de desarrollo, tal vez en forma de actividades y programas entre equipos que puedan ayudar a los desarrolladores a tener una opinión más positiva sobre la seguridad en el contexto de su trabajo.

Algunas ideas iniciales incluyen:

1. Ayude a los desarrolladores a obtener el soporte que necesitan para aprender a programar de forma segura. No tener las herramientas adecuadas para el trabajo es una excelente manera de sentirse justificado a la hora de meter una tarea en la cesta demasiado dura. Si los desarrolladores no cuentan con la formación y las herramientas adecuadas para considerar la seguridad como una prioridad en el proceso de codificación, no es de extrañar que tantos equipos no estén preparados para mantener las vulnerabilidades más comunes fuera de su código.
   
   Aproveche este mes para comprender qué es lo que falta en la tecnología de desarrollo, qué gerentes pueden trabajar juntos para mejorar la comunicación y aumentar la visibilidad de la seguridad, y quién puede seguir defendiendo y defendiendo la seguridad en el futuro.
   
2. Organice un evento de «Almuerzo y aprendizaje». Las comunidades de ciberseguridad y desarrollo están, en general, repletas de personas increíblemente generosas que están encantadas de compartir su experiencia. Ponte en contacto con los ponentes de las conferencias, con colegas técnicos de otras empresas o incluso con las filiales locales de OWASP y averigua quién podría entrar y charlar con el equipo o grabar un seminario web con alguien de la organización. Es una victoria relativamente rápida, y puede ser una gran ventaja para los desarrolladores emergentes ver las diferentes trayectorias profesionales de seguridad que tienen por delante.
   
3. Reúnete para una competición amistosa. Aprender sobre seguridad es mucho más divertido cuando haces algo un poco diferente y especial. Los torneos de programación segura son una excelente manera de hacer que los desarrolladores pongan a prueba sus habilidades de programación segura y compitan con sus compañeros en un entorno gamificado. Crea un tema de disfraces y sé creativo con los equipos (¿qué pasa con los desarrolladores contra sus directivos?). Pide pizza, bebidas, escucha música a todo volumen y puede ser un evento inolvidable para toda la organización.

Contribuir a la comunidad: descarga tu aplicación Secure Code Bootcamp gratuita

Yo también soy desarrollador y siempre hemos buscado lo que podemos compartir y usar de forma gratuita. Es un motivo de orgullo crear software gratuito que pueda ayudar a otros, y este mes es un buen momento para reflexionar sobre nuestras raíces y ver lo que podemos ofrecer a la comunidad.

Con ese fin, nos complace anunciar nuestra nueva aplicación gratuita, Secure Code Bootcamp. Se trata de un complemento de programación seguro y de bolsillo para los programadores que quieren superarse a sí mismos, aumentando progresivamente sus conocimientos de seguridad en cualquier momento y lugar.

Descarga la aplicación para iOS y Android ahora, y aprenda a localizar e identificar las vulnerabilidades de OWASP en Node.JS, Python:Django, Java:Spring, C# .NET: MVC:

Hablemos de la deuda

Casi todo el mundo sabe ahora que la ciberdelincuencia se ha convertido en un problema importante que enfrenta nuestra economía global. En 2022, el coste medio de una violación de datos en los Estados Unidos ascendía a 9,44 millones de dólares, frente a los 9,05 millones del año anterior. Es importante no ignorar el coste del código inseguro y su deuda técnica acumulada. Según el 2022 Consorcio para la calidad de la información y el software: el costo de la mala calidad del software Según este informe, se estima que el costo de la mala calidad del software en los EE. UU. ha crecido hasta alcanzar los 2,41 billones de dólares y la deuda técnica acumulada por el software ha crecido hasta alcanzar los 1,52 billones de dólares.

Los crecientes costos de abordar el código inseguro y su deuda técnica se han convertido en el mayor obstáculo para realizar cualquier cambio en las bases de códigos existentes, dejándolas así vulnerables a la explotación y a las amenazas externas. El estado de la seguridad del software se enfrenta a una crisis existencial. Sabemos que tenemos que mejorar nuestra postura de seguridad y abordar la deuda técnica acumulada, pero los obstáculos son enormes:

• Se estima que hay 300 000 puestos vacantes de desarrolladores de software y relacionados con TI en los EE. UU., con una tasa de crecimiento proyectada del 15%
• Se prevé que para 2025, el 40% de los presupuestos de TI se gastará simplemente en mantener la deuda tecnológica
• En promedio, un tercio de las horas semanales de los desarrolladores se dedican a abordar la deuda tecnológica

Las soluciones rápidas son riesgosas y cuestan más a largo plazo

¿Qué es la deuda técnica y por qué es tan importante? La deuda tecnológica se acumula cuando los responsables de la toma de decisiones optan por una solución a corto plazo para un problema de desarrollo de software, en lugar de una solución más exhaustiva y a largo plazo. Esto conlleva un costo oculto sustancial que las organizaciones deben pagar más adelante. Al igual que una tarjeta de crédito al límite máximo, la deuda técnica tiene dos componentes principales:

• Director - se refiere al costo total de refactorizar o reparar el software para que alcance el nivel deseado de mantenimiento y seguridad.
• Interés - el esfuerzo adicional que los desarrolladores dedican a realizar esos cambios solo para abordar la deuda técnica y no las nuevas funcionalidades. Cada minuto dedicado a un código que no es del todo correcto añade interés a la deuda.

Con el tiempo, se puede llegar a un estado de «quiebra técnica» cuando el costo de las nuevas funciones, la corrección de errores y el mantenimiento supera el presupuesto del proyecto, lo que reduce significativamente el valor de la aplicación de software.

Sin embargo, una cierta acumulación de deuda, al igual que en la vida, es normal y, en la mayoría de los casos, algo esperada.

Lo ideal es que todos los desarrolladores de software reduzcan los errores en la medida de lo posible antes de enviar el código. Sin embargo, se enfrentan a una difícil disyuntiva: para ser competitivas, una organización puede querer ofrecer funciones o productos a los clientes con rapidez y a un coste mínimo. Como resultado, la calidad de la aplicación se ve afectada porque los KPI de los desarrolladores se basan en la velocidad de entrega y en el costo inicial de crearla. Lo que falta en el panorama son las deficiencias acumuladas y las posibles vulnerabilidades integradas en el código. Esto lo deja listo para errores o vulnerabilidades de seguridad en el futuro o, lo que es peor, para que sean explotados por actores malintencionados.

Pero ahí está el dilema: ¿hay alguna forma diferente de enviar productos rápidamente sin acumular una enorme cantidad de deuda técnica?

El costo de encontrar y corregir deficiencias y vulnerabilidades es el mayor gasto individual en el ciclo de vida del desarrollo de software. Cuanto antes se detecten los problemas en el ciclo de vida del desarrollo, más rentable será la entrega en general.

La deuda técnica puede convertirse en deuda de seguridad

Muchos desarrolladores intentan sortear esta disyuntiva utilizando código fuente abierto que les ayude a avanzar con rapidez e, idealmente, utilizar una solución ya examinada. Sin embargo, dependen en gran medida del software de código abierto a menudo presenta sus propios riesgos:

• Se encontró que el 82% de los componentes de código abierto estaban desactualizados (es decir, no tenían parches o no eran compatibles)
• El 75% de las bases de código contenían vulnerabilidades (frente al 60% en 2018) y el 49% contenía vulnerabilidades de alto riesgo
• Se identificaron un promedio de 82 vulnerabilidades por base de código

Esto hace proliferar un subconjunto de deuda técnica: deuda de seguridad. La deuda de seguridad es la acumulación de vulnerabilidades en una aplicación de software que hace que sea más difícil o incluso imposible proteger los datos y los sistemas de un ataque.

Uno de los ejemplos más notorios es Equifax, el gigante de los informes crediticios violado en 2017 porque no había podido corregir una vulnerabilidad conocida en Apache Struts, un popular marco de aplicaciones web de código abierto. El parche llevaba meses disponible, pero la violación puso en peligro los datos personales cruciales de más de 147 millones de personas.

Por lo tanto, se debe prestar mayor atención a las prácticas de codificación seguras, ya que muchas aplicaciones han alcanzado una masa crítica no solo en lo que respecta a su deuda técnica, sino también a la densidad de debilidades y vulnerabilidades de seguridad en la propia aplicación.

Esto puede provocar enormes pérdidas, que pueden ser tangibles o intangibles:

Daño a la reputación: La pérdida de la confianza de los clientes puede tener un impacto extremadamente negativo en el futuro. Esto puede incluir daños a la marca, pérdidas de ventas y costosos problemas legales como resultado de una infracción.

Impacto regulatorio y de cumplimiento: Si una violación de seguridad puede hacer que una empresa no cumpla con una fecha límite y/o con obligaciones contractuales. El incumplimiento de un SLA puede provocar que una empresa tenga problemas con los reguladores y conllevar importantes multas.

Costos de remediación: A menudo es necesario trabajar más después de un fallo o una interrupción para compensar la pérdida de productividad.

Prevención de la deuda técnica y de seguridad en el SDLC

Muchas organizaciones ya están modificando su presupuesto para crear una postura de seguridad más sólida. El año pasado, Google comprometió 10 mil millones de dólares en 5 años para financiar un programa para fortalecer la ciberseguridad. La administración de Biden también solicitó 2.100 millones de dólares en el presupuesto discrecional de 2022 para la Agencia de Ciberseguridad y Seguridad de Infraestructuras (CISA).

Proporcionar más recursos y formación para ayudar a impulsar el crecimiento profesional y los conocimientos de sus desarrolladores puede ser el primer paso para establecer estándares de calidad para todo el código que se envía a la producción.

Los costos para encontrar y corregir una vulnerabilidad o un defecto aumentan exponencialmente a medida que se encuentra y aborda más adelante en el ciclo de desarrollo de software. Y, como hemos visto, al dedicar tanto tiempo a abordar la deuda técnica y de seguridad, las organizaciones están creando sus propias pérdidas al renunciar a la innovación y al tiempo que dedican a nuevas funciones o productos.

En 2022, la mayoría de los equipos de desarrolladores dijeron que DevOps o DevSecOps era su metodología preferida, y no sorprende por qué. DevSecOps integra la seguridad en cada etapa del ciclo de vida del desarrollo del software para ofrecer aplicaciones mejores y más seguras. Los equipos de seguridad y desarrollo siguen trabajando de forma aislada y con tensiones, pero está claro que esto debe cambiar para ayudar a las empresas a tener éxito. DevOps forma parte de la forma en que las organizaciones intentan derribar las barreras y remodelar la cultura. El objetivo fundamental de DevSecOps es aumentar la colaboración entre AppSec/Security y los desarrolladores desde el principio del ciclo de vida del desarrollo del software.

Implementar una nueva forma de pensar para abordar la deuda técnica y la seguridad no tiene por qué ser una hazaña monumental. Establecer una mentalidad proactiva a través de la formación es fundamental cuando se trata de mejorar la conciencia y las habilidades en materia de seguridad de la comunidad de desarrolladores de una organización. Una sólida formación en codificación segura para los desarrolladores garantiza que el aprendizaje sea continuo, interactivo, relevante y contextual, es una necesidad. Un enfoque verdaderamente holístico debe considerar lo que se necesita para fomentar una verdadera cultura de seguridad dirigida por los desarrolladores. Puede que sea necesario cambiar el enfoque y dejar de centrarse en las formas típicas de gestionar y crear equipos de desarrolladores.

Crear un cambio cultural no es fácil, pero Secure Code Warrior le ayuda a identificar a sus defensores de la seguridad y a dotar a los desarrolladores y las organizaciones de las habilidades adecuadas para hacer frente a los desafíos de seguridad actuales, que cambian constantemente.

Lanzar un programa de código seguro atractivo y escalable es una inversión que vale la pena debido al enfoque preventivo a largo plazo de la seguridad, en lugar del enfoque reactivo del pasado. En última instancia, esto ayuda a mitigar los costosos riesgos de una infracción, a educar a los desarrolladores sobre cómo encontrar y corregir las vulnerabilidades con rapidez y a facilitar una forma más ágil de centrarse en el desarrollo de productos y en acelerar el tiempo de comercialización.

No es ningún secreto que nuestra misión principal es hacer que el software y su desarrollo sean seguros; diseñados teniendo en cuenta la seguridad desde el principio de la producción. Nuestra visión establece un nuevo punto de referencia para la creación de software, en el que los desarrolladores cuentan con las habilidades y los conocimientos necesarios para detectar código vulnerable durante el proceso de escritura y corríjalo incluso antes de que se convierta en un problema.

Por lo tanto, teniendo esto en cuenta, puede pensar que estamos encantados de enterarnos de las nuevas violaciones de datos, ciberataques y códigos explotados que afectan a empresas de todo el mundo; esos incidentes sin duda destacan la necesidad de nuestro servicio en varios mercados verticales. La verdad es que es bastante frustrante. Está claro que, como industria, cometemos los mismos errores una y otra vez, porque la mayor parte de la educación sobre seguridad simplemente no es lo suficientemente sólida como para minimizar el riesgo y detener estas infracciones.

La última víctima de violación de datos es Ticketmaster. Si estuvieras entre los miles de clientes afectados, habrías recibido un correo electrónico notificándote el incidente y cambiándote la contraseña. Nadie espera que se violen sus datos personales simplemente por comprar entradas para un concierto o un evento deportivo, pero aquí estamos.

Es una situación terrible para todos, perjudicial para la reputación de Ticketmaster y para una pésima experiencia de cliente. Sin embargo, hay un problema: no fue del todo culpa de ellos.

Verá, la empresa utilizó los servicios de una aplicación de atención al cliente de terceros de Inbenta Technologies. Ticketmaster UK descubrió que el producto contenía código malicioso, lo que ponía en peligro el cinco por ciento de los datos de sus clientes de todo el mundo.

¿Y cómo se las arreglaron los piratas informáticos para explotar este sistema? ¿Ellos manipuló una sola línea de código JavaScript, personalizado por Inbenta Technologies para los requisitos de Ticketmaster. Según Inbenta, el código se usó en una página para la que no estaba diseñada y, de haberlo sabido, lo habrían identificado como una vulnerabilidad de seguridad.

La vulnerabilidad en sí misma es esencialmente un problema de seguridad de la biblioteca de carga/almacenamiento de archivos, en el que una sola violación puede afectar a todos los sitios en los que se carga el mismo código. Para empezar, el código se puede modificar para recopilar y redirigir datos personales a los atacantes. Se trata de un ataque sencillo con un potencial de daño de gran alcance, y es algo contra lo que estamos trabajando para defendernos con un variedad de ejercicios de entrenamiento en la plataforma para desarrolladores.

Por supuesto, es prácticamente imposible administrar una empresa sin depender de algunas aplicaciones de terceros. Sin embargo, no puedes controlar la forma en que crean su software y, básicamente, no tienes ninguna visibilidad sobre el nivel de seguridad de su código. Se convierte en un ejercicio de confianza. Si su socio externo es laxo en sus prácticas de codificación segura, es posible que esté abriendo la puerta a una violación vuestroempresa.

Entonces, ¿cuál es la solución? En pocas palabras: todos debemos hacerlo mejor. Debemos dejar de pensar en la seguridad como un obstáculo irritante en el camino de la innovación empresarial.

Es más fácil de lo que piensa dotar a su equipo de desarrollo de las herramientas y los conocimientos adecuados para adoptar la seguridad y detener el código incorrecto. Nos complace ver que muchas de las empresas financieras, de telecomunicaciones, minoristas y tecnológicas más grandes y conocidas del mundo han adoptado este nuevo enfoque, pero las empresas de la lista Fortune 100 no deberían dedicarse exclusivamente a la educación en materia de seguridad. Todas las empresas que cuentan con desarrolladores entre su personal necesitan impartir formación para ayudar a los equipos a programar de forma segura.

El documento técnico publicado recientemente que escribí junto con nuestro director de tecnología, Matias Madou, muestra los beneficios de crear una cultura de seguridad en su organización. Detallamos por qué es la clave para impulsar la innovación, mantener la agilidad y reducir el impacto financiero del código inseguro.

Encontrará consejos que incluyen:

* Cómo hacer que la formación en seguridad sea relevante y atractiva para los desarrolladores

* Cómo enseñar a los desarrolladores a identificar y solucionar sus propios problemas

* Cómo ayudar a los desarrolladores a crear su propio código de forma segura.

Te invito a descarga este recurso y úsala para defender la seguridad en tu organización, desarrollar las habilidades de tu equipo y estar a la vanguardia del establecimiento de un estándar de código más alto.

Debemos dejar de pensar en la seguridad como un obstáculo irritante en el camino de la innovación empresarial.

En Secure Code Warrior, siempre buscamos ampliar nuestra cobertura de capacitación. Para que los desarrolladores de sistemas integrados y los administradores de seguridad puedan crear sistemas integrados seguros, nos adentramos en el mundo de la seguridad de los sistemas integrados. En esta publicación, hablaremos sobre el estándar MISRA C 2012 y sobre por qué es necesario cumplirlo para construir sistemas integrados seguros.

Al escribir código en C, es muy fácil implementar cosas que parecen correctas, pero que son intrínsecamente incorrectas. Tu código puede compilarse bien e incluso funcionar bien durante un cierto período de tiempo. Sin embargo, el mismo código podría fallar o mostrar un comportamiento indefinido si el tamaño de entrada o la memoria aumentan. Por ejemplo, un número de entrada determinado hace que un entero se desborde, o una secuencia de caracteres concreta hace que una matriz se salga de los límites.

Aquí es donde el estándar de codificación MISRA C puede ayudar. Las reglas, directrices y mejores prácticas establecidas en el estándar permiten a los desarrolladores escribir código C seguro y confiable para el desarrollo integrado.

MISRA C 2012, la última versión de la norma, agrega nuevas reglas, mejora las existentes y aborda algunas discrepancias. Si todavía utilizas una versión anterior, ahora sería un buen momento para cambiarla.

¿Qué es el estándar de codificación MISRA C?

El estándar MISRA C incluye pautas de seguridad, portabilidad y confiabilidad del código para el lenguaje de programación C. El primer conjunto de directrices se publicó en 1998 y era específico para el lenguaje C.

Sin embargo, desde entonces, el Consorcio MISRA también desarrolla estándares de codificación para C++. Cada documento C de MISRA contiene un conjunto de reglas, ejemplos que no cumplen con las normas y secciones detalladas sobre la información básica que contribuyó al desarrollo de dichas reglas.

C y C++ son los lenguajes más utilizados para desarrollar software embebido. Una de las principales razones es que son rápidos, ya que solo tienen 1 o 2 niveles de abstracción en comparación con el lenguaje de máquina. Pero esto también significa que escribir código seguro, especialmente en C, es difícil y propenso a errores. Por ejemplo, en la mayoría de los lenguajes de alto nivel, como Java y C#, no tienes que preocuparte por cosas triviales como la recolección de basura o la escritura dinámica.

Sin embargo, en C, no hay una forma predefinida de recolectar basura, es decir, si asignas una parte de la memoria para una estructura de datos, tienes que liberarla manualmente, una vez que hayas terminado de usarla. Si no lo haces, C, a diferencia de otros lenguajes, no te liberará memoria, lo que provocará una pérdida de memoria.

MISRA C 2004 (C2) contra MISRA C 2012 (C3) — ¿Qué ha cambiado?

MISRA C: 2012, también conocido como C3, se lanzó por primera vez en abril de 2013. Basándose en el conocimiento de los trabajos de miles de personas y organizaciones, el C3 añade nuevas reglas, mejora la explicación y los antecedentes de algunas reglas existentes y cierra algunas lagunas.

El C3 es compatible con la versión C99 del lenguaje y, al mismo tiempo, mantiene las reglas de la antigua ISO C90. La principal área de enfoque del C3 era reducir los costos habituales de la aplicación de las reglas y, al mismo tiempo, hacer que el uso del lenguaje C fuera más seguro en los sistemas críticos. Todo esto hace que sea prudente cambiar al nuevo estándar, si aún no lo ha hecho.

En general, esta es una lista de los cambios más importantes:

• Corrija los problemas encontrados en la versión de 2004.
• Aumente significativamente el número de reglas decidibles. Una regla es decidible, si una herramienta de análisis puede ayudarle a determinar la conformidad con ella.
• Las reglas se clasifican en «obligatorias», «consultivas» u «obligatorias». Las reglas obligatorias nunca deben infringirse, bajo ninguna circunstancia. Las normas obligatorias y consultivas pueden infringirse en situaciones especiales, siempre que la infracción esté justificada.
• Se ha añadido una guía sobre cómo aplicar reglas al código generado automáticamente. Esto es muy importante porque las mismas directrices del código escrito por humanos no siempre se aplican al generado por una herramienta.
• Elimine las reglas demasiado generalizadas que prohibían el comportamiento razonable de los usuarios. Por ejemplo, anteriormente se recomendaba no usar macros en absoluto, ya que pueden generar diversas dificultades y confusiones (no pueden depurar macros, las macros no tienen espacios de nombres, etc.). Esto impedía el uso de macros, incluso en situaciones en las que podían proporcionar una solución elegante, segura y cómoda. En MISRA C: 2012, se introdujeron nuevas reglas con respecto a las macros, que permitían a las personas usarlas con cuidado, siempre que fuera aplicable. Consulte el siguiente extracto, tomado de un documento de MISRA C, en el que se recomienda utilizar una macro en lugar de una función.

Reglas de MISRA C en acción

Basta de hablar, ahora es el momento de ponerse manos a la obra con algunas reglas de MISRA C, con ejemplos de cómo se aplican.

Utilice tipos compatibles como argumentos de puntero para memcpy, memmove y memcmp

Las funciones estándar de la biblioteca memcpy, memmove, y memcmp realizar un movimiento byte por byte o una comparación del número de bytes especificado. La regla 21.15 de la norma MISRA C 2012 dicta que los dos parámetros de la función deben ser punteros del mismo tipo. Una llamada a una función con tipos de punteros incompatibles podría indicar un error.

Considera la siguiente imagen, tomada del documento oficial de cumplimiento de MISRA. La regla es requerida, decidible, y se aplica tanto a C90 como a C99.

A continuación de la descripción de la regla se muestra un ejemplo.

Como puede ver, dado que los objetos son de diferentes tipos (uint8_t y uint16_t), esta es una solución que no cumple con los requisitos.

Las funciones de manejo de cadenas que no toman longitud como entrada no darán como resultado un acceso fuera de los límites

Las funciones de manejo de cadenas <string.h>que no toman la longitud como entrada no deberían resultar en un acceso fuera de los límites. Las funciones relevantes son: strcat, strchr, strcmp, strcoll, strcpy, strcspn, strlen, strpbrk, strrchr, strspn, strrstr y strtok. La regla es obligatorio, lo que significa que nunca se puede infringir, bajo ninguna circunstancia. Se aplica tanto al C90 como al C99, y es indecidible.

El ejemplo correspondiente es:

Como puede ver, strcpy en la función f1, copiará más allá de la longitud de la cadena, que solo puede contener 5 caracteres. También tenemos un uso seguro y compatible de strcpy, según el cual la cadena solo se copiará si cabe el contenido de «str».

Validar los datos recibidos externamente

Dir 4.14 recomienda comprobar la validez de los datos recibidos de fuentes «externas». La entrada externa puede ser:

• Lee desde un archivo.
• Lee desde una variable de entorno.
• Cualquier entrada del usuario.
• Todo lo que se reciba a través de un canal de comunicación. Por ejemplo, a través de una conexión TCP o una API HTTP, etc.

Esta directiva se inscribe en el requerido categoría, y es aplicable tanto a la C90 como a la C99. La razón de esto es que un programa no tiene control sobre los datos recibidos de fuentes externas, lo que significa que estos datos pueden ser inválidos o malintencionados. Por ejemplo, un programa espera que un usuario introduzca un número, pero el usuario introduce una cadena. Antes de procesar la entrada, el programa debe verificar que realmente se trata de un número.

Cómo cambiar a MISRA C 2012

El cambio a MISRA C 2012 requerirá una actualización en su documento de directrices de codificación. Si no usas una y, en cambio, confías en una herramienta de análisis estático (que es la opción recomendada), es posible que tengas que comprar una versión más reciente de la herramienta. Estas son tres herramientas que comprueban el cumplimiento de la MISRA C 2012:

1. Control de CPU es una herramienta de código abierto que puede comprobar las reglas de MISRA y también detectar varios tipos de errores.
2. PC-Lint Plus es una herramienta de pago que viene con un período de evaluación de 30 días. Además de comprobar el cumplimiento de MISRA C, también puede ayudar a identificar posibles errores y vulnerabilidades.
3. Código SONAR es otra herramienta que comprueba el cumplimiento de MISRA en C y C++.

También hay algunos compiladores que pueden probar el cumplimiento de MISRA. En caso de que se detecte una infracción de la regla, se generarán las correspondientes advertencias o excepciones. Por ejemplo. Programas de Green Hills proporciona compiladores compatibles con todos los estándares MISRA, para arquitecturas de 32 y 64 bits.

Uso de Secure Code Warrior para mejorar las habilidades de los desarrolladores en MISRA C

El producto estrella de Secure Code Warrior, la plataforma de aprendizaje, incluye numerosos desafíos, cursos y evaluaciones interactivos que pueden ayudar a capacitar a los desarrolladores para escribir código C/C++ seguro. El contenido de la plataforma es específico para cada marco y es muy atractivo. Nuestros desafíos de codificación C/C++:Embed se inspiraron en MISRA C, AUTOSAR C++ (MISRA C++) e IEC.

Los desarrolladores pueden embarcarse en viajes de aprendizaje personalizados, en los que identifican las vulnerabilidades específicas de C/C++ y, lo que es más importante, aprenden a corregir esos errores. En este proceso, los desarrolladores pueden hacer un seguimiento de su progreso para identificar sus puntos débiles e incluso disfrutar de un concurso de programación amistoso con sus compañeros. Obtenga más información sobre cómo ayudamos a las industrias automotriz y de transporte con nuestras soluciones.

¿Quiere saber qué tan interactivos y centrados son nuestros desafíos? ¡Prueba algunos desafíos de C/C++:Embed ¡en la plataforma de aprendizaje hoy!

Hace poco me entrevistaron para el Podcast Silver Bullet, presentado por Gary McGraw, en el que hablé sobre las ventajas de la industria sobre la investigación académica, por qué no era trivial iniciar una empresa en Europa y hacia dónde avanzará la industria de la seguridad de las aplicaciones en el futuro.

Si bien nunca tuve la intención de crear un negocio, lo hice porque vi que demasiadas empresas se enfrentaban al mismo problema; escribir código seguro es un desafío para la mayoría de los desarrolladores. Tenemos todo un sector centrado en encontrar problemas de seguridad en el código, y estos problemas no hacen más que acumularse.

Hay muy pocas soluciones que se centren realmente en ayudar de manera eficiente a las organizaciones y a su equipo de desarrollo que tienen dificultades para solucionar los problemas encontrados, y menos aún en tratar de evitar que se introduzcan más problemas en el código. Cada vez son más las organizaciones que se dan cuenta de este círculo vicioso y se dan cuenta de que su equipo de desarrollo necesita formarse para escribir código seguro desde el principio y debe estar equipado con las herramientas y los procesos necesarios para ello.

Si quieres saber más sobre cómo Gary McGraw y yo vemos el avance de la industria, consulta el Podcast Silver Bullet!

Show 139: Matias Madou analiza la formación en desarrollo seguro y la investigación sobre pruebas de seguridad del software

https://www.synopsys.com/software-integrity/resources/podcasts/show-139.html

Una versión de este artículo apareció en Lectura oscura. Se ha actualizado y distribuido aquí.

‍

Desde los primeros rumores sobre las herramientas de IA más novedosas y rompedoras de la cultura, tanto los desarrolladores como los curiosos de la programación las han estado utilizando para generar código con solo tocar un botón. Los expertos en seguridad señalaron rápidamente que, en muchos casos, el código que se estaba produciendo era de mala calidad y vulnerable, y en manos de personas con pocos conocimientos de seguridad, podría provocar una avalancha de aplicaciones y desarrollos web inseguros que afectara a consumidores desprevenidos.

Y luego, hay quienes tienen suficientes conocimientos de seguridad como para usarlos para, bueno, el mal. Por cada hazaña alucinante de la IA, parece que hay un contragolpe con la misma tecnología que se utiliza para propósitos nefastos. La suplantación de identidad, los vídeos fraudulentos totalmente falsos, la creación de malware, las travesuras de niños con guiones generales... estas actividades disruptivas se pueden llevar a cabo mucho más rápido y con menos barreras de entrada.

No cabe duda de que hay muchos cebos de clics que promocionan esta herramienta como revolucionaria, o al menos triunfa cuando se la combina con una habilidad humana «promedio». Si bien parece inevitable que la tecnología de inteligencia artificial tipo LLM cambie la forma en que abordamos muchos aspectos del trabajo (no solo el desarrollo de software), debemos dar un paso atrás y considerar los riesgos más allá de los titulares.

Y como compañero de programación, sus defectos son quizás su atributo más «humano».

Los patrones de codificación deficientes dominan sus soluciones preferidas

Con ChatGPT entrenado en décadas de código y bases de conocimiento existentes, no sorprende que, a pesar de su maravilla y misterio, también sufra los mismos escollos comunes a los que se enfrentan las personas cuando navegan por el código. Los patrones de codificación deficientes son lo más habitual, y todavía hace falta ser un experto en seguridad para generar ejemplos de codificación seguros formulando las preguntas correctas y proporcionando la ingeniería adecuada con rapidez.

Aun así, no hay garantía de que los fragmentos de código proporcionados sean precisos y funcionales desde el punto de vista de la seguridad; la tecnología es propensa a provocar alucinaciones, incluso crear bibliotecas inexistentes cuando se le pide que realice algunas operaciones JSON específicas, tal y como descubrió Mike Shema. Esto podría llevar a los ciberdelincuentes a «hacer alucinaciones», ya que estarían encantados de lanzar algún tipo de malware disfrazado de la biblioteca inventada que ChatGPT recomienda con total confianza.

En última instancia, tenemos que enfrentarnos a la realidad de que, en general, no esperábamos que los desarrolladores fueran suficientemente conscientes de la seguridad ni, como industria, los hemos preparado adecuadamente para escribir código seguro como estado predeterminado. Esto se pondrá de manifiesto en la enorme cantidad de datos de formación que se han introducido en ChatGPT, y podemos esperar unos resultados de seguridad igualmente mediocres de su producción, al menos al principio. Los desarrolladores deberían ser capaces de identificar los errores de seguridad y corregirlos ellos mismos o diseñar mejores instrucciones para obtener un resultado más sólido.

La primera estudio de usuarios a gran escala El examen de cómo los usuarios interactúan con un asistente de codificación de IA para resolver una variedad de funciones relacionadas con la seguridad, realizado por investigadores de la Universidad de Stanford, respalda esta idea, y una observación concluye:

»Observamos que los participantes que tenían acceso al asistente de IA tenían más probabilidades de introducir vulnerabilidades de seguridad en la mayoría de las tareas de programación, pero también más probabilidades de calificar sus respuestas inseguras como seguras en comparación con las de nuestro grupo de control.».

Esto habla de un nivel de confianza predeterminado en el resultado de las herramientas de codificación de IA, ya que producen código que siempre es intrínsecamente seguro, cuando en realidad no lo es.

Entre esto y las inevitables amenazas transmitidas por la IA que impregnarán nuestro futuro, ahora más que nunca, los desarrolladores deben perfeccionar sus habilidades de seguridad y elevar los estándares de calidad del código sin importar su origen.

El camino hacia el desastre de una violación de datos está lleno de buenas intenciones

No debería sorprendernos que los compañeros de programación de IA sean populares, especialmente porque los desarrolladores se enfrentan a una responsabilidad cada vez mayor, a plazos más ajustados y a las ambiciones de innovación de una empresa que recaen sobre sus hombros. Sin embargo, incluso con las mejores intenciones, la falta de conciencia práctica en materia de seguridad a la hora de utilizar la IA para programar conducirá inevitablemente a problemas de seguridad evidentes. Todos los desarrolladores con herramientas de inteligencia artificial y aprendizaje automático generarán más código, y el nivel de riesgo de seguridad dependerá de su nivel de habilidad. Las organizaciones deben ser muy conscientes de que las personas no capacitadas generarán código con mayor rapidez, pero también aumentarán la velocidad de la deuda de seguridad técnica.

Incluso nuestra prueba preliminar (abril de 2023) con ChatGPT ha revelado que generará errores muy básicos que podrían tener consecuencias devastadoras. Cuando le pedimos que creara una rutina de inicio de sesión en PHP utilizando una base de datos MySQL, el código funcional se generó rápidamente. Sin embargo, por defecto almacenaba las contraseñas en texto plano en una base de datos, almacenaba las credenciales de conexión a la base de datos en código y utilizaba un patrón de codificación que podía provocar una inyección de SQL (aunque sí filtraba los parámetros de entrada y detectaba errores en la base de datos). Todos los errores de los novatos, se midan desde cualquier punto de vista:
‍

‍
Las instrucciones adicionales aseguraron que se corrigieran los errores, pero se necesitan conocimientos de seguridad significativos para corregir el rumbo. El uso generalizado y descontrolado de estas herramientas no es mejor que dar rienda suelta a tus proyectos a desarrolladores noveles, y si este código sirve para crear infraestructuras delicadas o procesar datos personales, entonces estamos ante una bomba de relojería a punto de estallar.

Por supuesto, al igual que los desarrolladores junior sin duda aumentan sus habilidades con el tiempo, esperamos que las capacidades de AI/ML mejoren. Dentro de un año, es posible que no cometa errores de seguridad tan obvios y sencillos. Sin embargo, esto tendrá el efecto de aumentar drásticamente los conocimientos de seguridad necesarios para detectar los errores de seguridad más graves, ocultos y no triviales que aún corre el riesgo de producir.

Seguimos mal preparados para encontrar y corregir las vulnerabilidades de seguridad, y la IA amplía la brecha

Si bien en este momento se ha hablado mucho de «girar a la izquierda» durante muchos años, el hecho es que, para la mayoría de las organizaciones, existe una falta significativa de conocimientos prácticos sobre seguridad entre la cohorte de desarrollo, y debemos esforzarnos más para proporcionarles las herramientas y la educación adecuadas que les ayuden en su camino.

Tal como están las cosas, no estamos preparados para los errores de seguridad a los que estamos acostumbrados, por no hablar de los nuevos problemas derivados de la IA, como la inyección rápida y las alucinaciones en cuclillas, que representan vectores de ataque completamente nuevos que están a punto de despegar como la pólvora. Las herramientas de codificación basadas en la IA representan el futuro del arsenal de programación de un desarrollador, pero la formación necesaria para utilizar estas armas de productividad de forma segura debe venir ahora mismo.

‍

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):

‍