Productos FTTH

Tienda FFTH desde 2004

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon GitHub implementa periodo de espera de 3 días en Dependabot para frenar la propagación de paquetes maliciosos


GitHub implementó un mecanismo de espera predeterminado de tres días para las actualizaciones de versión de Dependabot, buscando evitar la propagación rápida de paquetes maliciosos. Las actualizaciones de seguridad seguirán siendo inmediatas, y los usuarios pueden ajustar este tiempo según sus necesidades. Esta medida es una capa de defensa complementaria contra ataques de cadena de suministro, similar a controles adoptados por otras plataformas.





GitHub ha anunciado un nuevo mecanismo de enfriamiento en Dependabot, que permite a la herramienta esperar al menos tres días después de que se publique un lanzamiento antes de abrir un pull request.

"La opción de configuración de enfriamiento en el archivo dependabot.yml sigue controlando el comportamiento, por lo que puedes elegir un parámetro de enfriamiento diferente que se adapte a tu proyecto", afirmó la filial propiedad de Microsoft en su blog.

Según GitHub, el enfriamiento predeterminado de tres días solo se aplica a las actualizaciones de versión, diseñadas para mantener actualizadas las dependencias del software. Las actualizaciones de seguridad se seguirán enviando de inmediato, permitiendo que Dependabot emita una alerta y abra un pull request para mover el proyecto a la versión parcheada.

Con esta actualización, la idea es gestionar escenarios donde un actor de amenazas logre publicar una versión envenenada de un paquete popular, que luego sea rápidamente adoptada por proyectos dependientes antes de que dicha versión sea retirada del registro. Aunque estos paquetes troyanizados duran poco tiempo, el periodo en que permanecen accesibles es suficiente para ampliar el radio de impacto de un ataque a la cadena de suministro.

GitHub señaló que eligió los tres días como valor predeterminado porque considera que es la duración ideal. "Tres días como valor predeterminado equilibra dos objetivos: te permite superar la ventana donde ocurren la mayoría de estos ataques y no retiene tus dependencias más de lo necesario", añadió.

Al mismo tiempo, la plataforma de desarrollo de software enfatizó que este control debe ser solo una capa de defensa entre varias otras, incluyendo el anclaje de dependencias con lockfiles, la desactivación de scripts de instalación en CI, el limitación del alcance de los tokens en las tuberías de construcción y la revisión de las actualizaciones antes de fusionarlas.

"Un periodo de enfriamiento está hecho para un patrón específico: una versión maliciosa que se envía, se propaga y se detecta rápidamente", dijo GitHub. "Hace poco contra ataques que juegan a largo plazo, como puertas traseras plantadas en lanzamientos y dejadas inactivas, sabotaje de mantenedores o un sistema de construcción comprometido".

Vale la pena notar que se han anunciado controles de enfriamiento similares en varios ecosistemas de paquetes durante el último año, incluidos Microsoft Visual Studio Code (VS Code), Ruby, Bun, npm, pnpm y Yarn.

La defensa basada en tiempo de GitHub llega mientras los mantenedores del Python Package Index (PyPI) anunciaron planes para bloquear a los mantenedores la adición de nuevos archivos a un lanzamiento de paquete después de que hayan pasado 14 días desde su publicación.

"La medida pretende evitar que los atacantes que comprometan tokens o flujos de trabajo de publicación envenenen lanzamientos antiguos y confiables", señaló PyPI.

Fuente:
THN


0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.