Portada
mis comunidades
otras secciones
![Análisis de lo de Crowdstrike [ENG]](https://cdn.mnmstatic.net/cache/3c/70/media_thumb_2x-link-3960883.webp?1721462286)
#2:
Ha sido el típico error de júnior. Todavía no sé cómo ha podido llegar esa porción de código a producción en una empresa como CS. Es una cagada superlativa y es imposible que hubiera pasado el más mínimo test o control sin que esto hubiera cantado.
Comentarios
Ha sido el típico error de júnior. Todavía no sé cómo ha podido llegar esa porción de código a producción en una empresa como CS. Es una cagada superlativa y es imposible que hubiera pasado el más mínimo test o control sin que esto hubiera cantado.
#2 las pruebas en producción. No hacerlo así es de cobardes.
#2 seguramente es una situación bastante más compleja que la sobre simplificación del tweet.
Entonces es que lo sacaron sin siquiera probarlo...
#1 Pero ni una sola prueba... y ni un test unitario ni nah de nah de nah.
Ahora habría que ver qué arreglaba el hotfix y si era realmente tan importante como para cometer tal cadena de temeridades.
#1 seguramente lo probaron pero no se la pruebas era errónea o incompleta.
No tengo ni idea, pero suele ser así.
Ha sido un ensayo para un próximo apagón por tormenta solar o ataque terrorista... O han subido una actualización sin probarla y eso casi da más miedo que la tormenta solar y el ataque terrorista juntos
#12 Sí, doy fe de que así ha sido de primera mano.
#10 Ya, pero tienes que respetar la decisión del cliente de no actualizarse a la última versión. Es a su cuenta y riesgo comprometer algo de ciberseguridad a cambio de ganar en estabilidad. Si das esa posibilidad y después no la respetas apaga y vámonos.
#11 Hostia... ¿Me estas diciendo que llegaron a joder sistemas con políticas de deploy retrasadas? Impresionante.
Hay que ser muy fino para programar a nivel de kernel.
No tiene sentido que ese código haya llegado a producción. Sospecho que no se probó bien en Windows.
Eso con Rust no habría pasado.
#5 Yo sospecho que no se probó nada en absoluto. Por lo que tengo entendido, no ha habido entorno Windows superior a la versión 6.1 en el que no haya fallado. Es un error terrible a nivel de organización, nunca habría tenido que llegar a producción.
#6 No me lo puedo explicar. No puedo entender que una empresa tan grande lleve código sin testear a producción. No es que les quiera exculpar. Es un caso de incompetencia extrema pero quiero creer que si existen esas medidas de calidad pero tuvieron la mala suerte de una cadena de errores no prevista.
Creo que no he visto ni un solo proyecto en 10 años que no tenga un pipeline de CI/CD que no incluya al menos correr unos cuantos tests.
Es que ..estoy pensando ahora mismo...que el propio IDE me avisa si no compruebo en valor de un puntero antes de acceder a el. Y los linters, y los tests, las pruebas manuales, etc, etc... Es inconcebible.
#7 Estoy como tú, es tan inverosímil que ya empiezo a plantearme que la posibilidad de un sabotaje por parte de uno o varios empleados descontentos puede hasta tener más sentido que semejante cadena de errores. Es más, a mí hay algo que también me llama mucho la atención: se que el Falcon tiene la posibilidad de definir las políticas de actualización automática del Sensor por grupos de hosts, permitiendo que estos no se actualicen a la última versión inmediatamente sino que se mantengan en la N-1 o N-2 según preferencias. Y, sin embargo, esta actualización coló a todos los hosts de los clientes con independencia de lo que dictara dicha política. Muy raro todo. Crowdstrike todavía debe muchas explicaciones.
#9 Un devops me comentaba ayer que por un lado tienes la presión de hacer el deploy n-1, pero por otro lado, están habiendo muchos ataques recientemente y nadie quiere estar retrasado y salir en las noticias, o sea que ja presión es actualizar ASAP.