
El lector antiguo de Slashdot, Alanw, compartió una publicación de Lista de correo de seguridad OSSEl administrador de sistemas Jan Schaumann se pregunta qué hacer después del kernel de Linux Completó 432 CVE en poco más de 24 horas.: «Entiendo la posición de que los CVE son siempre una forma defectuosa de rastrear o priorizar los cambios de seguridad… pero este ataque muestra que tratar de priorizar un único cambio central no es factible. No sé qué hacer a continuación». El Registro informó: Equipo nixCraft especulativo En las redes sociales, no tiene precedentes que los informes de errores de IA puedan ser la causa de todos estos CVE centrales: el propio Linus Torvalds dijo en mayo que la lista de correo de Linux Core Security se había vuelto «casi completamente inmanejable» debido a la búsqueda de errores asistida por IA. Aún así, Torvalds describió la inteligencia artificial como una herramienta útil para el desarrollo de Linux, aunque señaló que puede ser un lastre para los mantenedores, tanto desde la perspectiva de la carga de trabajo como por el hecho de que «sigue encontrando errores embarazosos». […]
Desafortunadamente para los administradores de sistemas Linux, el problema en el que se encuentran actualmente no es precisamente fácil de solucionar. Los CVE pueden ser una forma confusa de rastrear y priorizar las actualizaciones de seguridad, especialmente cuando se lanzan cientos de actualizaciones en un corto período de tiempo, pero sin una mejor manera, los equipos de seguridad y TI deben determinar qué vulnerabilidades afectan sus sistemas y qué actualizaciones principales deben implementarse. Greg Kroah-Hartman, mantenedor principal senior Respondió a la publicación de Jan.contrarrestando la idea de que los volúmenes CVE del kernel son particularmente difíciles de administrar. Él cree que el núcleo no es nada especial: las empresas de todo el mundo finalmente se están dando cuenta de que necesitan reevaluar cómo actualizan todos sus sistemas y dispositivos, algo que tradicionalmente ha sido «tristemente ignorado».
Con respecto al método «siempre actualizado», Greg dijo que esto es lo que reconoce la comunidad del kernel: «Esto es recomendado y respaldado por la comunidad de desarrolladores principal. Si necesita nuestro apoyo, hágalo». ¿No puedes gestionarlo tú mismo? Pague a la empresa por soporte o «simplemente use Debian o Yocto porque sus prácticas de seguridad son increíbles». Señala a Android como evidencia de la escalabilidad de este enfoque, llamándolo «la implementación de software más grande del mundo» con miles de millones de dispositivos que se actualizan constantemente «con un desarrollador con exceso de trabajo dirigiéndolo todo».
En cuanto a revisar cada CVE individualmente, señaló que esto se puede automatizar en gran medida al cruzar los archivos involucrados en el CVE con los archivos que realmente creó, lo que generalmente reduce el conjunto relevante «a aproximadamente el 10% del total», un enfoque que Enterprise Distros ya emplea para sus clientes. El parche selectivo del modo pánico recibe un sencillo «¡Buena suerte!» – o algo así Ley de ciberresiliencia de la UE Se aprobaría legislación para eliminar el hábito (una «obviedad», en su opinión), y «es posible que su compañía de seguros también quiera hablar con usted al respecto».
Greg también advirtió que la avalancha aún no ha terminado: «La cantidad de problemas descubiertos por LLM solo está aumentando en este momento, y tomará al menos 18 meses solucionarlos. Si las personas quieren estar seguras de alguna manera, es mejor seguir actualizando sus sistemas». En cuanto al 432-CVE. El brote en sí, explicó, fue simplemente una cuestión de ponerse al día con una cola de eventos públicos de semanas de duración durante el fin de semana, por lo que se pospuso a cualquier reunión pública perfecta, por lo que se pospuso a cualquier reunión pública perfecta, por lo que se pospuso a cualquier reunión pública perfecta, por lo que se pospuso a cualquier Esto no debería sorprender a nadie que trabaje con un repositorio (git) perfectamente público.







