Insights sobre códigos de seguridad

Este artículo se publicó originalmente en. Información sobre seguridad, y lo hemos recogido de otras tiendas. Se ha actualizado aquí para su sindicación.

A finales del año pasado, la increíble comunidad MITRE publicó una lista con los 25 errores de software más peligrosos de CWE que afectaron al mundo en 2019. Esta lista no se basa en opiniones, sino que es el resultado de un análisis multifacético que utiliza el trabajo de organizaciones como Además del NIST, también se han publicado datos sobre vulnerabilidades y exposiciones comunes (CVE). Para identificar los defectos «principales», se puntúan en función de su gravedad, su potencial de explotación y su prevalencia en el software actual. No es el tipo de lista que pueda recibir elogios positivos. Eso está claro.

Sin embargo, a diferencia de la mayoría de los resúmenes anuales, muchos de los participantes que aparecen en esta lista ya habían aparecido anteriormente... Si esta lista fuera la lista Billboard Hot 100, sería como la lista de Britney Spears.Baby One More Time y BackstreetBoys. Quiero hacerlo así. Aparecen cada año desde su lanzamiento inicial.¿Y por qué elegí esas canciones? Bueno, tengo unos veinte años (¿todavía parece antiguo?) y, a pesar de haber sido descubiertas hace décadas, son muy similares a los peligrosos errores de software que nos siguen atormentando en 2020.

¿Por qué los errores antiguos siguen siendo peligrosos? ¿No sabes cómo solucionarlos?

El sexto elemento de la lista actual de MITRE es más conocido como CWE-89SQLInjection (SQLi). La vulnerabilidad SQLi se descubrió por primera vez en 1998, cuando mucha gente solía plantear sus preguntas más importantes a Zibs en lugar de a Google.Aunque poco después se dio a conocer la corrección, este método sigue siendo una de las técnicas de piratería más utilizadas en 2019. Informe sobre el estado de Internet , SQLi fue el culpable en dos tercios de los casos. Todos los ataques a aplicaciones web

En lo que respecta a la complejidad, la inyección SQL dista mucho de ser un abuso de nivel genial. Se trata de una solución sencilla para los desarrolladores web, y debemos conocer sin dudarlo cómo evitar que esta vulnerabilidad exponga datos valiosos a los atacantes... El problema es que, incluso hoy en día, la seguridad no es una prioridad para muchos desarrolladores. Puede que hace veinte años esto fuera más fácil, pero con la enorme cantidad de software que se crea actualmente y que se creará en el futuro, ya no puede ser algo habitual.

La mayoría de los desarrolladores trabajan en sistemas defectuosos.

Es muy fácil sentarse y culpar al desarrollador que proporcionó el código «incorrecto». De hecho, sus prioridades son muy diferentes a las del equipo de seguridad. Por lo general, al equipo de desarrollo se le pide que cree un software bonito y funcional lo más rápido posible. Debido a la demanda incesante de software por parte de la sociedad, el equipo de desarrollo ya está ampliado y la seguridad no es una consideración principal. Al fin y al cabo, ¿no es precisamente por eso por lo que existen los expertos en AppSec? Los ingenieros de software están acostumbrados a tener una relación algo fría con la seguridad. Solo se les pide su opinión cuando surge un problema, y ese problema puede retrasar el arduo trabajo.

Por otro lado, los expertos en AppSec están cansados de corregir errores que llevan décadas apareciendo en todos los escaneos y revisiones manuales de código. Estos expertos son caros y escasos, y es mucho mejor invertir su tiempo en fallos de seguridad complejos que en eliminar repetidamente errores bien conocidos.

Estos equipos tienen una cultura implícita de transferir responsabilidades, pero ambos comparten (o deberían compartir) el mismo objetivo: la seguridad del software. Los desarrolladores trabajan en un entorno en el que es casi imposible tener éxito en lo que respecta a la codificación segura. En los programas de educación superior rara vez se enseñan las mejores prácticas de seguridad, y la formación práctica es demasiado escasa o, en muchos casos, ineficaz. Hay una notable falta de énfasis en la concienciación sobre la seguridad y en la formación relacionada con ella. Como resultado, se avecina la amenaza de una violación de datos que dañaría la reputación y supondría un coste astronómico para corregir los antiguos errores del código confirmado.

El factor humano, también conocido como «¿Por qué todas estas herramientas no logran que los datos sean más seguros?».

Otro problema frecuente es que, en lugar de centrarse en la formación, se invierte una gran cantidad de recursos en herramientas de seguridad para detectar problemas antes del lanzamiento del software. Las herramientas de inspección y protección de aplicaciones en matriz (Fast/Dust/Raz/Toast) pueden ser de gran ayuda en la creación de software de seguridad, pero también tienen sus propios problemas. Depender completamente de estas soluciones no garantiza la seguridad. Las razones son las siguientes:

• No existe una herramienta «única» que permita examinar todas las vulnerabilidades en todos los casos de uso de todos los marcos.
• En particular, la velocidad puede disminuir cuando se ejecutan simultáneamente análisis de código estático y análisis de código dinámico.
• Los falsos positivos siguen siendo un problema. En estos casos, la producción se interrumpe con frecuencia y es necesario realizar revisiones manuales innecesarias del código para identificar las advertencias.
• Estas herramientas están creando una conciencia errónea sobre la seguridad, ya que se espera que resuelvan los problemas y se les da prioridad sobre la codificación segura.

Estas herramientas detectarán sin duda alguna las vulnerabilidades de seguridad que pueden ser parcheadas. Pero, ¿pueden detectarlo todo? No se puede garantizar una tasa de acierto del 100 %, y un atacante solo tiene que encontrar una puerta abierta para colarse y arruinarle el día.

Afortunadamente, muchas organizaciones se están dando cuenta de que el factor humano es importante. Vulnerabilidad del software. La mayoría de los desarrolladores no han recibido una formación adecuada en materia de codificación segura y su nivel de concienciación general sobre la seguridad es bajo. Sin embargo, se encuentran en las primeras fases del ciclo de vida del desarrollo de software y están en la mejor posición para evitar que las vulnerabilidades se introduzcan en el código comprometido. Si se codifica de forma segura desde el principio, se estará en primera línea de defensa contra los ciberataques destructivos que causan pérdidas de miles de millones de dólares cada año.

Los desarrolladores deben tener la oportunidad de triunfar mediante una formación que les permita hablar su propio idioma, que esté relacionada con su trabajo y que les permita interesarse activamente por la seguridad. El código sin errores debe ser motivo de orgullo. Al igual que crear algo funcionalmente impresionante puede ganarse el respeto de los compañeros.

Los programas de seguridad más recientes deben ser una prioridad empresarial.

El equipo de desarrollo no puede utilizar Bootstrap para mejorar la concienciación sobre la seguridad en toda la empresa. Para aplicar la seguridad al proceso de desarrollo de software desde el principio, se necesitan las herramientas, los conocimientos y el apoyo adecuados.

Si la lista de MITRE sigue conteniendo demasiados errores de seguridad antiguos, es evidente que los métodos de formación anteriores no están funcionando. Por lo tanto, pruebe algo nuevo. Busque soluciones de formación como las siguientes.

• Puede probarlo usted mismo. A los desarrolladores les gusta «aprender probando» en lugar de ver lo que se dice en los vídeos.
• Relevancia: Si utiliza Java a diario, no lo enseñe con C#.
• El aprendizaje interesante y sencillo es fácil de entender y permite a los desarrolladores seguir avanzando basándose en sus conocimientos previos.
• Medible. No se limite a marcar la casilla y seguir adelante. Compruebe si la formación es eficaz y establezca una ruta para mejorarla.
• Es interesante. Además de apoyar una cultura de seguridad positiva, explore cómo se puede fomentar la concienciación sobre la seguridad y cómo esto puede ayudar a crear un entorno de equipo coherente.

La seguridad debe ser la máxima prioridad para todos los miembros de la organización, y el CISO debe llevar a cabo de forma visible y transparente los esfuerzos necesarios para mantener los datos más seguros en todos los niveles. Quiero decir, ¿quién querría escuchar la misma vieja canción una y otra vez? Es hora de plantearse seriamente cómo eliminar para siempre los antiguos errores.

¿Qué le parecen estas frías estadísticas? El 60 % de las pequeñas y medianas empresas cierran en los seis meses siguientes a un ciberataque exitoso*. Las grandes empresas sufren pérdidas de millones (o miles de millones). Por otro lado, la reputación de la marca se ha esfumado. Cada vez son más las organizaciones que adoptan prácticas de codificación segura, lo que está provocando un cambio de tendencia. Con la llegada de DevSecOps, la codificación segura se ha convertido en el centro de atención desde el inicio del SDLC.Junto con Evans Data Corp***, Secure Code Warrior encargó un estudio reciente sobre la actitud de los desarrolladores hacia la codificación segura, las prácticas de código seguro y las operaciones seguras, con el fin de investigar el impacto real de esta tendencia.

Movimiento hacia la izquierda — Movimiento en varias etapas

Las empresas se han dado cuenta de que, tras corregir una vulnerabilidad, el coste de solucionarla es 30 veces mayor, por lo que las medidas preventivas se han convertido en la nueva norma*. Sin embargo, para que estas medidas sean eficaces, todos los implicados en el ciclo de vida del desarrollo de software (SDLC), especialmente los desarrolladores, deben ser conscientes de la seguridad.

Shift One — Entonces, ¿quién es ahora el responsable?

Con el auge de DevSecOps, las organizaciones están adoptando prácticas de codificación segura. Como resultado, uno de los cambios más destacados en este estudio es el traslado de la responsabilidad de la seguridad del código al nivel operativo.

Cuando se preguntó a los desarrolladores y gestores de desarrollo «¿Quién tiene la responsabilidad final de la seguridad del código?», el 46 % respondió que era el responsable del proyecto o del equipo, lo que supone casi el doble de los que respondieron que la responsabilidad debía recaer en el equipo de seguridad de las aplicaciones.

Esto demuestra claramente que la responsabilidad de la seguridad se está transfiriendo del equipo de seguridad de aplicaciones existente al líder del equipo de desarrollo.

Shift 2: El papel cambiante del gestor  

Los administradores se ven presionados desde múltiples frentes para implementar la formación en códigos de seguridad.

El 41 % afirmó que las tareas esenciales de la organización son las siguientes: formación en códigos de seguridad y proceder de la alta dirección. El aumento de las exigencias en materia de cumplimiento normativo también es un factor importante.

Los administradores desempeñan un papel fundamental a la hora de apoyar la transición del desarrollo tradicional a DevSecOps y se están convirtiendo en importantes responsables de la toma de decisiones en materia de formación y adquisición de herramientas.

Shift 3: desarrolladores que van un paso más allá

Sin embargo, se puede observar que la presión para el cambio desde abajo es cada vez mayor. El 24 % de los administradores afirma que implementa prácticas de codificación segura debido a las sugerencias y recomendaciones de los desarrolladores. Esto demuestra claramente que el papel de los desarrolladores en los programas de seguridad de las empresas es cada vez más importante. La transición a DevSecOps, que hace hincapié en las prácticas de codificación segura preventiva, convierte a los desarrolladores en la «primera línea de defensa».

4 turnos — Mejora de la dinámica del equipo  

La implementación de prácticas de código seguro tiene un impacto significativo en la calidad del software, pero también cambia la forma en que el equipo trabaja para mejorar. El 60 % de los desarrolladores que participaron en la encuesta cree que el uso de código seguro ha mejorado la comunicación con otros desarrolladores, pero los beneficios no se detienen ahí.

La mitad de los desarrolladores y administradores que participaron en la encuesta coincidieron en que las prácticas de codificación segura fomentan la colaboración entre desarrolladores y líderes. El 46 % respondió que la colaboración entre desarrolladores y partes interesadas ha aumentado. Al mismo tiempo, el 41 % respondió que la colaboración entre líderes y partes interesadas se ha vuelto más activa.

DevSecOps integra equipos, líderes y partes interesadas de una nueva forma para mejorar la colaboración en las diversas funciones y etapas del ciclo de vida del desarrollo de software.

El 62 % de los administradores que participaron en la encuesta afirmaron que las prácticas de código seguro ayudan a acelerar la velocidad de lanzamiento del código. Este hecho, combinado con todos los demás cambios, pone de relieve las ventajas evidentes que se obtienen al adoptar el enfoque DevOps.Sin embargo, como se ha explicado anteriormente en este artículo, para que estas medidas sean eficaces, todos deben ser conscientes de la seguridad en el SDLC. Esta idea tiene un impacto significativo en la forma en que las organizaciones forman a los desarrolladores. Los equipos deben aprender a identificar las vulnerabilidades recientemente descubiertas y a utilizar lenguajes específicos, es decir, el marco de trabajo de codificación. En pocas palabras, los equipos deben comprender cómo encontrar, identificar y corregir las vulnerabilidades conocidas del código en el contexto de su uso diario. Esta formación permite a los equipos pasar de ser un riesgo primario a una primera línea de defensa.

Secure Code Warrior, líder en el cambio del campo de la codificación segura, adopta un enfoque impulsado por personas para ayudar a las organizaciones a «dar un giro a la izquierda» y cambiar su enfoque general de seguridad de reactivo a preventivo.

Para obtener más información sobre la formación práctica, participativa y contrastada en código de seguridad que coordina las necesidades de los administradores, desarrolladores y organizaciones para alcanzar el futuro de DevSecOps, reserve ahora una demostración.

‍

*El 60 % de las pequeñas empresas cierran en los seis meses siguientes a haber sido víctimas de un ataque informático.
‍https://cybersecurityventures.com/60-percent-of-small-companies-close-within-6-months-of-being-hacked/

**IBM Software Group; Minimiza los errores de código para mejorar la calidad del software y reducir los costes de desarrollo.
‍https://docplayer.net/11413245-Minimizing-code-defects-to-improve-software-quality-and-lower-development-costs.html

***Transición de la respuesta a la prevención: cambios en la seguridad de las aplicaciones en 2021. Secure Code Warrior y Evans Data Corporation
https://scw.buzz/3169uzS

El 11 de junio de 2019, el Instituto Nacional de Estándares y Tecnología (NIST) publicó un informe actualizado con información detallada. Varios planes de acción para reducir las vulnerabilidades del software y los riesgos cibernéticos. Bajo el título «Mitigación de los riesgos de vulnerabilidad del software mediante la adopción del Marco de Desarrollo de Software Seguro (SSDF)», el NIST ofrece a las organizaciones directrices claras para evitar las costosas consecuencias de las violaciones de datos, por no hablar de los resultados desagradables.

A modo de referencia, el SSDF no asume que todas las organizaciones tengan los mismos objetivos de seguridad de software, ni prescribe los mecanismos exactos para alcanzarlos. El objetivo principal es implementar las mejores prácticas de seguridad. La autora Donna Dodson afirma lo siguiente: «Cada creador de seguridad desea que se cumplan todas las prácticas aplicables, pero es de esperar que el grado de implementación de cada práctica varíe en función de las hipótesis de seguridad del creador. Estas prácticas ofrecen flexibilidad al implementador, pero también es evidente que no deben dejar demasiado margen para la interpretación».

Por supuesto, fue especialmente interesante que se incluyeran detalles concretos sobre la formación en seguridad de software para desarrolladores. Hace tiempo que sabemos que los desarrolladores necesitan una formación adecuada para proteger a la organización desde el principio del proceso de desarrollo de software... Pero, ¿adecuada, exactamente? Hay muchas opiniones diferentes en el mundo. Sin embargo, creo que finalmente se están ampliando los límites en una dirección que traerá resultados muy positivos.

Hay formación en seguridad... y hay formación en seguridad eficaz.

El autor ha hablado extensamente sobre la necesidad de implementar la formación en seguridad de software de forma más eficaz y adaptarla a las necesidades de los desarrolladores. En la actualidad, muchas organizaciones se limitan a ofrecer, en el mejor de los casos, ejercicios «estándar».Es posible que se dediquen unas horas a la formación en vídeo o que se utilicen herramientas para el aprendizaje en el aula, lo que supone una pérdida de tiempo valioso. El hecho de que cada dos días se produzcan violaciones de datos a gran escala por parte de atacantes que aprovechan vulnerabilidades conocidas (y, por lo general, fáciles de corregir) es una prueba de que la formación en seguridad de software no es tan eficaz como debería. Y lo que es quizás más importante, apenas hay datos que permitan verificar si la formación ha sido eficaz. ¿Se han solucionado las vulnerabilidades más rápidamente? ¿Se está reduciendo la vulnerabilidad en el código? ¿La gente ha completado realmente la formación? ¿O simplemente han hecho clic en «Siguiente» para completar la formación?

Los desarrolladores son personas muy ocupadas que trabajan duro para cumplir con plazos estrictos. La seguridad suele ser un tema incómodo y, en muchos casos, la formación no proporciona los conocimientos necesarios para mitigar con éxito los riesgos cibernéticos. Por lo general, cuando los miembros del equipo de AppSec señalan fallos en el trabajo, se piensa en la palabra «seguridad», lo que da lugar a una relación algo fría y poco funcional. Es el típico escenario de «el bebé es feo, ve y arréglalo».

¿Qué nos dice esto? El hecho de que los desarrolladores no presten suficiente atención a la seguridad es una señal de alarma que lleva décadas presente. Los desarrolladores no están motivados para asumir responsabilidades y no buscan las herramientas necesarias para crear software funcional que tenga en cuenta las mejores prácticas de seguridad.

Los desarrolladores son inteligentes, creativos y les gusta resolver problemas. Es poco probable que ver vídeos interminables sobre vulnerabilidades de seguridad despierte el interés de los desarrolladores o les mantenga motivados.Como instructor de SANS, pronto me di cuenta de que la mejor forma de enseñar es ofrecer a los alumnos ejercicios prácticos que les permitan poner a prueba su capacidad intelectual y analizar y examinar casos reales basados en lo que han aprendido previamente. La gamificación y la competencia amistosa son herramientas poderosas que permiten a todo el mundo aprender nuevos conceptos, al tiempo que mantienen su utilidad y practicidad en el ámbito de la aplicación.

Las directrices del NIST establecen lo siguiente: «Proporcione formación específica para cada función a todos los empleados que desempeñen un papel responsable en el desarrollo de la seguridad. Revise periódicamente la formación específica para cada función y actualícela según sea necesario». A continuación: «Defina las funciones y responsabilidades del personal de ciberseguridad, los responsables de seguridad, la alta dirección, los desarrolladores de software, los propietarios de productos y otras personas relacionadas con el SDLC».

Esta declaración no es específica en cuanto al tipo de formación, pero sigue siendo útil para transformar la organización y tener en cuenta las mejores prácticas de seguridad. De este modo, se devuelve a la empresa la responsabilidad de encontrar soluciones de formación eficaces y más específicas, con la esperanza de que los desarrolladores dispongan de las herramientas y los conocimientos adecuados para alcanzar el éxito.

Cultura: el eslabón perdido.

Aunque se invierta tiempo y recursos en formar a los desarrolladores y otros empleados clave, haciendo hincapié en la importancia de prevenir las vulnerabilidades y reducir los riesgos de seguridad en la organización, estos esfuerzos pueden resultar en vano si la cultura de seguridad de la organización está fundamentalmente deteriorada.

Formar eficazmente a las personas, establecer objetivos y aclarar las expectativas facilita enormemente que comprendan su lugar en el entorno de seguridad y asuman las responsabilidades adecuadas. En el caso concreto de los desarrolladores, se les proporcionan desde el principio las herramientas y los conocimientos necesarios para escribir código seguro. Sin embargo, este enfoque se coordina mejor en un entorno de seguridad positivo, con menos duplicación de tareas, transferencia de responsabilidades y trabajo en proyectos aislados.

Debemos dar prioridad a la seguridad de toda la organización mediante el apoyo y la cooperación para proporcionar un software excelente y seguro. En otras palabras, podemos implementar una formación divertida y participativa que aproveche las vulnerabilidades reales del código y obtener el consenso de toda la organización para garantizar un presupuesto suficiente que permita mantener esta tendencia. En un entorno digital en constante evolución, la formación debe ser tan continua como la implementación. Si alguna vez ha oído decir que la formación en materia de cumplimiento normativo «se configura una vez y se olvida» es adecuada o eficaz, se trata de una idea errónea. «configurada una vez y olvidada», es una idea errónea.

Este nuevo marco del NIST no especifica concretamente los requisitos para crear una cultura de seguridad positiva, pero es imprescindible para cumplir con éxito las directrices. Sin embargo, cabe destacar que las organizaciones deben «definir políticas que especifiquen los requisitos de seguridad que debe cumplir el software de la organización, incluidas las prácticas de codificación segura que deben seguir los desarrolladores».

El contenido anterior es muy importante para ampliar y perfeccionar las tecnologías de seguridad dentro del equipo, y puede resultar útil tener en cuenta los siguientes aspectos a la hora de evaluar las políticas propias y el entorno actual de AppSec.

• ¿Están claramente definidas las directrices y expectativas en materia de seguridad del software?
• ¿Saben claramente todos los miembros del equipo qué papel desempeñan en la consecución de los objetivos?
• ¿La educación es frecuente y se evalúa?
• ¿Saben los desarrolladores lo importante que es eliminar los errores de seguridad comunes antes de que se produzcan?

Como mencioné anteriormente, la parte final depende principalmente de la organización y la formación que esta elija. Debe ser relevante, frecuente y contar con un alto nivel de participación. Busque soluciones que se puedan aplicar al trabajo diario y acumule conocimientos adaptados a cada situación.

¿Y ahora qué hacemos?

Examinar en detalle estas nuevas directrices puede resultar bastante complicado. Se requiere un gran esfuerzo para crear, verificar y distribuir el software de seguridad exhaustivo que necesitan la mayoría de las empresas de la forma más segura posible. Y no se limita solo a la formación. Hay directrices que deben tenerse en cuenta al utilizar software de terceros (el uso de componentes con vulnerabilidades conocidas sigue estando presente, como se indica en el Top 10 de OWASP), propuestas sobre verificación, pruebas de penetración y revisión de código, directrices para el mantenimiento de registros de seguridad, cadenas de herramientas adecuadas y todo lo demás. Se puede encontrar una visión general viable en el libro del Dr. Gary McGraw, el modelo BSIMM, al quese hace referencia en todos los documentos del NIST.

Sin embargo, si se proporciona a los desarrolladores las herramientas y los conocimientos adecuados para crear software seguro desde el principio, se puede alcanzar el éxito más rápidamente. Prevenir las vulnerabilidades comunes que surgen en la última fase del SDLC es más barato desde el punto de vista empresarial (y, en general, más rápido). Aproveche sus puntos fuertes y ofrézcales incentivos para que participen en la seguridad de la organización.Puede resultar muy interesante y ellos pueden convertirse en los héroes oportunos necesarios para detener a las personas malintencionadas y proteger los datos.

Referencias:

1. Mitigación del riesgo de vulnerabilidad del software mediante la introducción de SSDF (11 de junio de 2019) Página 2.
2. Mitigación del riesgo de vulnerabilidad del software mediante la introducción de SSDF (11 de junio de 2019) Página 5.
3. Mitigación del riesgo de vulnerabilidad del software mediante la introducción de SSDF (11 de junio de 2019) Página 4.

De niño tocaba mucho. Por supuesto,al principio tuve que completar varias partidas del juego con diferentes niveles de dificultad. Había desde «Demasiado joven para morir» (fácil) hasta «Pesadilla» (muy difícil). A veces me gustaría poder restablecer y cambiar fácilmente el nivel de dificultad de la gestión de una empresa tecnológica. Especialmente en la fase inicial, en la que hay muchos factores delicados e inestables y es fácil fracasar.

Las estadísticas son las siguientes. Es bien sabido y alucinante: las startups fracasan a un ritmo de aproximadamente el 90 %, lo que ha sido así desde hace años, pero si se analiza más a fondo, se observa que el 21 % de las startups fracasan en el primer año, el 30 % en los dos primeros años, el 50 % en los cinco primeros años y el 70 % en los primeros diez años.

Los cofundadores Matthias Madu, Fatema Beydoun, Colin Wong, Nathan Desmet y Yaf Karan Singh, junto con los inversores Goldman Sachs, Cisco Investments, Paladin Capital, Posit Point, AirTree, Tidal, y los miembros independientes del consejo Jim Flagg y Nanhi Singh, están orgullosos de haber alcanzado el «nivel 10».

El equipo fundador ha permanecido unido durante diez años, superando todas las lecciones, victorias y frustraciones. Estamos creciendo y, como líderes en el campo de la gestión de riesgos para desarrolladores, estamos preparados para dar la bienvenida al siguiente capítulo: SCW 2.0.

2024: El año en que se lanzó al mercado la primera herramienta de análisis de datos del sector.

Aunque resulta muy difícil demostrar el rendimiento de la inversión en personal técnico, en 2024 SCW logró lo que exigía todo el sector. «¿Es posible demostrar que el software es más seguro mediante la mejora de las habilidades de los desarrolladores?».Google ha recopilado datos sobre vulnerabilidades y resolución de problemas de algunos de sus principales clientes que ejecutan programas bien establecidos, y puede demostrar con orgullo, gracias a la verificación de los clientes, que la tasa de reducción de vulnerabilidades del código creado por desarrolladores de seguridad fue, de media, un 53 % inferior a la del código creado por otros desarrolladores. Además, se ha demostrado que los desarrolladores de seguridad resuelven los problemas de seguridad entre dos y tres veces más rápido, lo que ahorra tiempo y reduce la exposición al riesgo.

Fue el primero en dar el paso. SCW Trust Score, una función de evaluación comparativa que cuantifica el impacto de los programas de codificación de seguridad empresarial. Por primera vez, los responsables de seguridad pueden obtener información detallada basada en datos sobre las habilidades de codificación de seguridad de los equipos de desarrollo y compararlas con los estándares del sector. Se trata de una visibilidad perfecta que muchos esperaban para ajustar los programas de forma significativa y ofrecer a los desarrolladores individuales una ruta de aprendizaje que les permita mejorar sus habilidades de seguridad de por vida.Incluso hemos publicado el siguiente material. Un artículo de investigación en colaboración con Chris Inglis, exdirector nacional de ciberseguridad de EE. UU., y Kemba Walden, presidente del Paladin Global Institute y exdirector nacional de ciberseguridad de EE. UU.

Más tarde lanzamos SCW Trust Agent, una oferta complementaria que analiza todos los commits en comparación con las técnicas de codificación segura de los desarrolladoresy proporciona visibilidad sobre todo el repositorio de código de la organización. SCW Trust Agent se basa en SCW Trust Score y, en conjunto, muestran la eficacia con la que el programa de seguridad de la empresa se aplica a todos los commits.

Estas herramientas desempeñan un papel fundamental a la hora de ayudar a los responsables de seguridad empresarial a alcanzar los siguientes objetivos: verificar los elementos esenciales de los principios de diseño de seguridad contrastados mediante las directrices de diseño de seguridad de la CISA, las técnicas de seguridad para desarrolladores, los compromisos de seguridad y, en última instancia, la erradicación de las categorías de vulnerabilidades.

¡Hola, socio! Al igual que nuestra base de clientes, nuestra red de socios también sigue creciendo.

Una de las cosas más dolorosas del sector de la ciberseguridad es comprender que, en el fondo, todos formamos parte de una gran comunidad excéntrica y apasionada que, en la mayoría de los casos, está dispuesta a unir fuerzas no solo para lograr el éxito mutuo, sino también para crear un mundo digital más seguro para todos.

Tenemos el privilegio de poder llamar a una amplia gama de empresas de seguridad y tecnología asociadas. Ofrecemos un programa de socios que desempeña un papel fundamental en el impulso de nuestro crecimiento. A finales de 2024, anunciamos nuestra segunda asociación OEM con líderes mundiales en gestión de la información. Abrir texto. Este avance, junto con nuestro socio OEM principal, ofrece a Black Duckuna oportunidad increíble para proporcionar una solución completa y global que satisfaga las necesidades modernas de las empresas y los programas de seguridad.

Además, actualmente contamos con más de 650 clientes empresariales. Desde nuestros humildes comienzos hace diez años, cuando un equipo de cuatro personas celebró la llegada de nuestro primer gran cliente con una comida económica, hemos logrado crear una sólida base de clientes que no temen adoptar un enfoque preventivo de la seguridad, con los desarrolladores como agentes del cambio.

La IA, destructora definitiva y futuro de la seguridad impulsada por los desarrolladores.

La inteligencia artificial, LLM y las herramientas de codificación con IA han sido términos de moda en boca de todos los expertos en TI durante más de dos años, y nuestra sociedad se encuentra en un momento decisivo en la historia de la tecnología. Las diversas herramientas de IA, presentes en casi todas las categorías, prometen una enorme mejora de la productividad. En el campo del desarrollo de software, una encuesta reciente de GitHub reveló que la mayoría de los ingenieros han comenzado a adoptar asistentes de codificación basados en IA.

A pesar de que solo el 38 % de las organizaciones han aprobado su uso, estas herramientas se han convertido en parte del entorno de desarrollo de software. Su uso es inevitable, y los responsables de seguridad deben centrarse en guiar a los desarrolladores hacia un proceso de codificación seguro y responsable, en lugar de crear una situación de «IA en la sombra». Los desarrolladores con conocimientos de seguridad pueden utilizar estas herramientas basándose en su pensamiento crítico y sus conocimientos especializados en materia de seguridad, lo que les permite aprovechar realmente las ventajas de la mejora de la productividad sin agravar los riesgos continuos que plantean los desarrolladores con escasos conocimientos de seguridad.

El año 2025 será un año de continuo avance en la codificación de IA. Sin embargo, es posible que solo haya uno o dos aspectos en los que podamos ayudar a las empresas a aplicar eficazmente la gestión de riesgos de los desarrolladores en este y otros campos. Tendrán que seguir atentos para ver cómo continúa nuestro viaje.

A medida que las amenazas cibernéticas se vuelven cada vez más comunes y sofisticadas, la ciberseguridad se centra en la importancia del código de seguridad. La estrategia de ciberseguridad nacional de la Casa Blanca y la Agencia de Seguridad Cibernética y de Infraestructura (CISA) han puesto en marcha una iniciativa de diseño seguro que, junto con iniciativas y leyes de otros países, responsabiliza totalmente a los productores de software de la seguridad.Lo que antes se consideraba una ventaja, es decir, garantizar la seguridad desde el principio del ciclo de vida del desarrollo de software (SDLC), ahora es esencial para que las organizaciones protejan sus datos y sistemas y eviten las consecuencias normativas derivadas de las violaciones de seguridad.

La clave para garantizar las prácticas de codificación segura reside en la formación de los desarrolladores. Los ingenieros de software suelen recibir los siguientes beneficios: Casi o ninguna formación en ciberseguridad. Especialmente en el acelerado entorno DevOps actual, su misión era lanzar nuevas aplicaciones, actualizaciones y servicios lo más rápido posible con la ayuda de modelos de IA generativa de funcionamiento rápido, y permitir que el equipo de seguridad resolviera los problemas de ciberseguridad en algún momento posterior del SDLC. Se trata de un método ineficaz para resolver los innumerables fallos que se producen cuando se genera demasiado código y, a menudo, se filtran vulnerabilidades de software en el ecosistema.

Los desarrolladores deben recibir formación desde el principio para escribir código seguro y deben ser capaces de detectar código inseguro generado por IA o presente en el software de código abierto y de terceros que utilizan. Para muchos equipos de desarrollo y organizaciones, esta es un área que no se ha abordado. ¿Cómo se puede saber si los desarrolladores están recibiendo la formación necesaria? ¿Y si esa formación se aplica de forma regular?

Algunas empresas que se dedican a la formación de desarrolladores han descubierto que resulta útil establecer un conjunto de habilidades básicas para que los desarrolladores puedan aprender y medir su progreso basándose en unos parámetros de referencia claramente definidos. Para ayudar en esta tarea, Secure Code Warrior ha lanzado unos parámetros de referencia diseñados para medir con precisión el progreso de los desarrolladores en materia de formación en seguridad. La puntuación SCW Trust mide el grado de aplicación de la formación en el trabajo y permite la colaboración entre los equipos de seguridad, desarrollo e ingeniería.

Esta es una forma de identificar las áreas que necesitan mejorar y, al mismo tiempo, ver la evidencia de que la formación en códigos de seguridad se está llevando a cabo correctamente.

Casos prácticos para un diseño seguro

Los creadores de software tienen motivos suficientes para introducir la seguridad en el SDLC desde el principio del proceso. El aumento de la demanda de aplicaciones y servicios, y la velocidad que la IA aporta al proceso de desarrollo, han demostrado ser útiles para los desarrolladores que han adoptado rápidamente la IA generativa. Sin embargo, el resultado es que, inevitablemente, se están lanzando al mercado productos de software defectuosos. Cuanto más código se genera, más defectos hay. Según un estudio reciente, casi tres cuartas partes de las aplicaciones (independientemente de cómo se hayan creado) contienen al menos un defecto de seguridad, y casi el 20 % de ellos se consideran graves.

Encontrar vulnerabilidades en la última fase del SDLC requiere una enorme inversión de tiempo y dinero. El Instituto Nacional de Estándares y Tecnología (NIST) ha descubierto que corregir defectos durante las pruebas lleva 15 veces más tiempo que proteger el software al inicio del SDLC, y que corregir defectos en las fases de implementación y mantenimiento puede llevar entre 30 y 100 veces más tiempo.

Todo esto demuestra que es importante aplicar la seguridad desde el principio del ciclo de desarrollo. Se ha demostrado que esta es la forma más eficaz de reducir los riesgos y también la más rentable. Los desarrolladores, en lugar de dejar que el equipo de seguridad funcione como una entidad separada, están en la mejor posición para introducir la seguridad al principio del SDLC si colaboran con el equipo de seguridad. Además, los desarrolladores que han recibido formación sobre las mejores prácticas de seguridad han podido reducir eficazmente las vulnerabilidades. El problema es que muy pocos de ellos han recibido dicha formación.

La belleza de los puntos de referencia

La ruta básica de la empresa incluye establecer estándares de tecnología de seguridad, proporcionar formación y verificar, tanto para la organización como para los organismos reguladores, que los desarrolladores hayan adquirido las habilidades necesarias. Esto ha demostrado ser un reto para muchas organizaciones de todos los sectores económicos, pero no tiene por qué ser así.

Uno de los problemas señalados por los responsables de seguridad es la dificultad de ampliar los programas de formación a toda la empresa. Sin embargo, según un estudio de SCW, las organizaciones, especialmente aquellas con un gran número de desarrolladores, pueden implementar con éxito un enfoque de diseño de seguridad. Los resultados de las organizaciones más pequeñas tienden a variar mucho en función de cómo aplican los principios de diseño de seguridad. No obstante, estas empresas también pueden beneficiarse de un enfoque que incluya puntuaciones de confianza y es probable que muestren mejoras más rápidamente.

La puntuación de confianza utiliza indicadores de referencia para medir el progreso de cada alumno, agrega las puntuaciones para evaluar el rendimiento de todo el equipo y compara el progreso de la organización con los puntos de referencia y las mejores prácticas del sector. Esto no solo permite realizar un seguimiento de la formación, sino que también muestra en qué medida los desarrolladores están aplicando cada día las nuevas tecnologías. Además, destaca las áreas que necesitan mejorar, lo que permite a la organización optimizar los programas de formación y mejora de las habilidades.

En general, la mayoría de las organizaciones se encuentran en un nivel similar en cuanto a la implementación de los principios de diseño de seguridad, independientemente del tipo de datos de infraestructura crítica que pudieran utilizar. Las puntuaciones de confianza de diversos sectores, desde los servicios financieros y la industria de defensa hasta la sanidad, las tecnologías de la información y la fabricación, se situaron en el mismo rango. Se superó ligeramente la puntuación de 300 en una escala de 1000 puntos. A pesar de la creencia generalizada de que el sector de los servicios financieros, que es el más regulado, estaría a la cabeza, ningún sector superó a los demás.

Los sectores de infraestructura clave que no se incluyen en la clasificación de puntuación de confianza, como la química, la energía y la energía nuclear, no suelen crear su propio software, sino que dependen de otros sectores, especialmente de las tecnologías de la información. Sin embargo, el hecho de que sea importante mantener la seguridad de los sistemas en estos sectores (nadie quiere ver cómo se daña una central nuclear) demuestra lo importante que es proteger el software que se utiliza en primer lugar.

Conclusión

Debido al aumento de la presión regulatoria y a la realidad del entorno de amenazas cibernéticas, el enfoque Secure By-Design se ha vuelto imprescindible para las organizaciones que desean proteger sus datos, sistemas, operaciones comerciales y reputación. La creación de software de seguridad depende en gran medida de los desarrolladores, pero estos necesitan recibir la formación necesaria y contar con el apoyo de programas de formación y mejora de habilidades exhaustivos que les muestren cómo se aplica el método de desarrollo.

Los programas que incluyen puntos de referencia basados en herramientas como Trust Score permiten comprender claramente el progreso general del equipo de desarrollo. Se trata de un enfoque totalmente nuevo para todas las empresas que trabajan con desarrolladores, que deben cumplir los nuevos requisitos de seguridad desde el diseño y, al mismo tiempo, mejorar continuamente sus habilidades de desarrollo de software seguro.

‍

En Secure Code Warrior, nuestro lema era proporcionar a los desarrolladores una experiencia de aprendizaje ágil y práctica, así como una formación en seguridad realista y práctica como parte de su experiencia laboral diaria. Nos gusta llamarlo «aprender haciendo».

Sabemos que la formación personalizada centrada en el trabajo actual de los desarrolladores proporciona una experiencia gratificante que ayuda a las empresas a obtener resultados mucho más significativos. En otras palabras, podemos ofrecer resultados mucho más significativos a las empresas mediante pruebas prácticas, control de calidad y lanzamientos rápidos de código listos para salir al mercado en el momento oportuno. ¿A qué empresa no le gustaría eso?

Estamos mejorando esta experiencia con una nueva e interesante integración. Apiroes la plataforma líder del sector en gestión del estado de la seguridad de las aplicaciones (ASPM), que proporciona al equipo y a los responsables de AppSecla visibilidad necesaria para priorizar, corregir, prevenir y gestionar los riesgos importantes de las aplicaciones. La integración de ambas plataformas proporciona a los desarrolladores información relevante y formación en seguridad en tiempo real a la hora de abordar los riesgos de seguridad. De este modo, los desarrolladores pueden aprender sin tener que cambiar de contexto ni salir del entorno familiar de las herramientas de desarrollo que utilizan a diario.

Entonces, ¿cómo se produce esta magia? Apiiro mapea los resultados de seguridad de las aplicaciones detectados por Apiiro o recopilados por herramientas de seguridad de terceros con la formación relevante de Secure Code Warrior por tipo y lenguaje, y luego los transmite a los desarrolladores o equipos relevantes a través de tickets, incidencias o mensajes.La integración de Apiiro y Secure Code Warrior minimiza las interrupciones en el ciclo de vida del desarrollo de software, ya que elimina la necesidad de tomar medidas en diferentes momentos utilizando herramientas separadas. Es solo otra forma de ayudar a las empresas a mejorar la eficiencia de los desarrolladores y a lanzar código de alta calidad más rápidamente.

Para obtener más información sobre esta nueva integración y asociación, consulte lo siguiente. El blog de Apiiro se encuentra aquí.

‍

La mayoría de las organizaciones siguen teniendo dificultades para enfatizar la seguridad como un elemento clave del ciclo de vida del desarrollo de software (SDLC), y son pocas las que logran superar el sólido enfoque DevSecOps. Muchos siguen dando prioridad a las funciones y los plazos de lanzamiento por encima de la seguridad. Esto tiene varias consecuencias, como el aumento del riesgo de costosas violaciones de datos y la disminución de la productividad, ya que los equipos deben revisar minuciosamente los tickets de seguridad y las tareas pendientes.

La primera línea de defensa para eliminar los factores de riesgo son los desarrolladores. Es importante que las organizaciones piensen en aumentar la madurez de su equipo de desarrollo en lo que respecta a las vulnerabilidades del software. Sin embargo, esto plantea varias preguntas.

¿Cómo evalúa la organización la madurez de seguridad del equipo de desarrollo? ¿Cómo se puede hacer que el establecimiento de una hoja de ruta para la madurez de seguridad no parezca imposible? ¿Cómo se puede mantener la participación de los desarrolladores y motivarlos para que mejoren la madurez de seguridad?

Aprovechamos la información proporcionada por Secure Code Warrior. Encuesta sobre el estado de la seguridad impulsada por los desarrolladores. Comprendimos las respuestas a estas preguntasy, con la ayuda de nuestro equipo de atención al cliente de primer nivel, averiguamos qué están haciendo otras organizaciones para encontrar respuestas.

¿Cómo se puede aumentar la madurez de seguridad del equipo de desarrollo?

En lo que respecta a la mejora de la madurez de la seguridad, ninguna organización es igual a otra. Esto se debe a que hay que tener en cuenta muchas variables que pueden influir en el éxito de los esfuerzos de transformación digital de las empresas. De este modo, se obtienen muchas ventajas, como la posibilidad de generar y publicar código rápidamente sin necesidad de utilizarlo o utilizando muy poco. Existen vulnerabilidades. Como resultado, se reducen los costosos trabajos de reelaboración y, en última instancia, se minimizan los riesgos.

Las organizaciones que logran el desarrollo cuentan con planes definidos, que incluyen apoyo administrativo, y con un enfoque coherente para mejorar continuamente la madurez de la seguridad a lo largo del tiempo. Esto incluye lo siguiente:

• Definición de los criterios de madurez de la seguridad
• Evaluación de la madurez de seguridad del equipo
• Identificación de las principales vulnerabilidades de seguridad
• Creación de una cultura de seguridad positiva

Consulte el nuevo informe técnico La importancia de la madurez de la seguridad del equipo de desarrollo Para obtener más información:

• ¿Qué es la madurez de seguridad del equipo de desarrollo y por qué es importante?
• ¿Cuáles son las etapas y características de la madurez de seguridad del equipo de desarrollo?
• ¿Qué se necesita para aumentar la madurez de seguridad del equipo de desarrollo?

Hace cinco años, los bancos belgas se unieron para crear este fantástico anuncio de televisión. Contaban la historia de Dave, un hombre con un gran talento y una gran perspicacia, que conocía información personal y financiera muy concreta. Con ello, informaban a millones de consumidores de que podían comprobar su vida en línea y les animaban a no bajar la guardia.

Si ve el vídeo, verá que hoy en día es mucho más relevante que en 2012. Y sé que el resultado es mucho más aterrador.

Si las aburridas presentaciones de diapositivas, las normas opresivas y las constantes advertencias sobre lo que no se debe hacer le parecen un gran problema para la alta dirección y los empleados, le recomendamos que vea este vídeo para obtener inspiración creativa.

¡Vea el vídeo, compártalo con el equipo de relaciones públicas y comunicación, y solicite ayuda para que la seguridad de la información vuelva a ser divertida!

No importa si se trata de impartir formación en ciberseguridad a los altos directivos o de ayudar a los desarrolladores con técnicas de codificación segura en JAVA o C#. Hay espacio para la creatividad, la gamificación y la diversión.

No importa si se trata de impartir formación en ciberseguridad a los altos directivos o de ayudar a los desarrolladores con técnicas de codificación segura en JAVA o C#. Hay espacio para la creatividad, la gamificación y la diversión.

Durante mucho tiempo, VxWorks no ha sido un producto muy conocido entre los consumidores generales. Este producto de software, inevitablemente, beneficiará a muchas personas como usted y como yo a diario. Este software, el sistema operativo en tiempo real (RTOS) más popular del mundo, es un producto estrella que se utiliza a través de proxies para alimentar redes empresariales y cortafuegos, interfaces aeroespaciales, equipos industriales e incluso algunos dispositivos médicos. Por citar algunos ejemplos de aplicaciones ampliamente utilizadas.

Y ahora nos enfrentamos a la posibilidad de que, de no ser así, se pierdan miles de millones de dólares. Se han detectado más de 11 vulnerabilidades en miles de millones de estosdispositivos. Arlen Baker, diseñador jefe de seguridad de Wind River, cuestionó esta cifra en un artículo. La seguridad de la búsqueda, cuyo alcance exacto no se ha confirmado, no parece ser tan alta. No obstante, ya sabemos que siempre se producen violaciones de datos y ataques, pero esto es un nivel superior. Las fallas identificadas pueden explotarse con relativa facilidad y, en su mayoría, permiten a los atacantes controlar los dispositivos de forma remota a través de la transmisión de paquetes de red.

Por supuesto, Wind River ha lanzado una serie de correcciones y parches para los clientes y empleados afectados. El problema es que hay demasiados dispositivos que necesitan actualizaciones de parches. Al igual que Thanos acabó con el mundo con un solo chasquido de dedos, muchos dispositivos inevitables permanecerán vulnerables durante mucho tiempo sin los parches.

La empresa de seguridad Armis fue la responsable de este gran descubrimiento, que también se denominó «su descubrimiento». Emergencia/11. El equipo de investigación determinó sin lugar a dudas que se trataba de una enfermedad grave, ya que facilitaba el ataque de múltiples vectores y tenía un amplio potencial de infección. Es perfectamente posible crear y distribuir un gusano en el software que controla todo, desde escáneres de resonancia magnética y productos VOIP hasta redes ferroviarias y semáforos.

¿Es hora de ponerse nervioso?

Como persona que considera la concienciación sobre la seguridad como una misión importante en la vida, cada día veo muchos problemas potenciales de seguridad. Si me dejara llevar por el pánico, pasaría la mayor parte del día histérico. (¡Al fin y al cabo, es mejor que me dedique a educar y corregir errores!).Sin embargo, el alcance de lo que ha descubierto URGENT/11 es bastante aterrador. Seis de las once vulnerabilidades descubiertas se consideran graves. Se ha confirmado que estos defectos están presentes en dispositivos que ejecutan VxWorks desde la versión 6.5 de Hacker News (excepto las versiones diseñadas para la certificación, como VxWorks 653 y VxWorks Cert Edition). Esto significa que algunas tecnologías importantes llevan más de diez años expuestas a la amenaza de ataques de secuestro de dispositivos. Aunque no todos los dispositivos son vulnerables a las 11 fallas (algunas solo pueden ser explotadas si el atacante se encuentra en la misma subred LAB), un hacker común solo necesita una oportunidad.

Es importante tener en cuenta que Wind River ha tomado medidas rápidas y ha proporcionado asesoramiento detallado. Al igual que Armis, se trata de mitigar el problema. Además, el sistema operativo en tiempo real VxWorks está muy extendido. Esto se debe a que es muy estable y ha obtenido una alta puntuación en las normas de seguridad de software. Por lo general, los cazadores de recompensas por errores no le prestan mucha atención. Sin embargo, las empresas de seguridad y Wind River no pueden hacer mucho para resolver el problema. Descargar parches, familiarizarse con los consejos de seguridad y reforzar los propios dispositivos es responsabilidad del usuario final, y eso es precisamente lo complicado.

아직 당황할 필요는 없겠지만, 이 야수를 굴복시키려면 마을이 필요할지도 모릅니다.

Urgente/11 Descripción de la vulnerabilidad

En este momento, todos los dispositivos conectados a la pila IPNet TCP/IP de VxWorks dañada desde la versión 6.5 pueden verse afectados por al menos uno de los URGENT/11. (Consulte la lista completa de CVE de Wind River aquí).

La mayoría de estas vulnerabilidades permiten ataques de ejecución remota de código (RCE) y denegación de servicio, y algunas de ellas provocan la exposición de información. Lo mismo ocurre con los problemas de lógica empresarial. En este caso, la ejecución remota de código es un problema especialmente delicado, ya que permite a los atacantes controlar los dispositivos sin necesidad de interactuar con el usuario final. Nadie tiene que hacer clic accidentalmente en un elemento sospechoso, descargar nada ni introducir datos. Esto hace que los dispositivos VxWorks sean muy «operativos» y que el ataque en sí mismo ocupe una vida útil automatizada. ¿Recuerda el producto EternalBlue del gusano WannaCry? URGENT/11 es similar, pero tiene un potencial más letal que puede causar problemas en todo el mundo.

¿Qué podemos hacer al respecto?

Bueno, en el momento de escribir este artículo, aún se desconocen los resultados de URGENT/11. Los medios de comunicación han despertado un gran interés en el sector, y Wind River está proporcionando un apoyo firme a las personas afectadas. En los próximos meses se sabrá si hay atacantes que intentan explotar estas vulnerabilidades conocidas de forma significativa. Pero hasta entonces, la solución más segura es seguir los numerosos consejos y aplicar los parches a los dispositivos afectados.

A largo plazo, nuestra misión sigue siendo la misma: todos debemos mejorar nuestros resultados en materia de seguridad del software. URGENT/11 CVE es una puerta trasera preocupantemente sencilla, y el hecho de que haya pasado desapercibida durante tanto tiempo es una prueba de que la preocupación y la concienciación al respecto son bastante bajas en todo el sector.

Todos los desarrolladores tienen la oportunidad de desempeñar su función y necesitan apoyo para aprender métodos de seguridad del código desde las primeras fases de la producción. Desde AppSec hasta la alta dirección, contar con un equipo influyente a su alrededor puede ayudar a que prospere una cultura de seguridad positiva en todos los puntos de contacto del software dentro de la empresa.

¿Quiere poner a prueba su propio conocimiento sobre seguridad? Con nuestra plataforma gamificada, podrá resolver problemas de código reales similares a algunos de los detectados en URGENT/11. Compruébelo y vea cómo le va.

• Desbordamiento de pila en el análisis sintáctico de ofertas/ACK DHCP de ipdhcpc (CVE-2019-12257)
  Daño de memoria: desbordamiento de pila
• Conexión TCP DoS a través de opciones TCP con formato incorrecto (CVE-2019-12258)
  Protección insuficiente de la capa de transporte: transmisión sin protección de información confidencial
• ipdhcpc Falla lógica en la asignación de IPv4 por parte del cliente DHCP (CVE-2019-12264)
  Fallo de lógica empresarial
• Ataque DoS mediante referencias nulas en el análisis IGMP (CVE-2019-12259)
  Daño de memoria: referencia nula
• Fuga de información IGMP a través del informe de miembros específicos IGMPv3 (CVE-2019-12265)
  Exposición de información: exposición de datos confidenciales