Las solicitudes de incorporación maliciosas aumentan los riesgos para los flujos de trabajo de desarrollo ampliamente utilizados

Una vulnerabilidad recientemente destacada en los flujos de trabajo de CI/CD está llamando la atención sobre la forma en que los proyectos de código abierto y de desarrollo en la nube gestionan las contribuciones de código. El problema se centra en las solicitudes de incorporación maliciosas, que pueden utilizarse para introducir cambios dañinos en los procesos automatizados de compilación y lanzamiento si los controles de revisión y validación no son lo suficientemente sólidos.

Según el informe, la vulnerabilidad del flujo de trabajo afecta a varios proyectos y herramientas de desarrollo conocidos, incluidos Azure Sentinel de Microsoft, el kit de desarrollo de agentes de IA de Google, Apache Doris, el SDK de Workers de Cloudflare y el formateador Black de la Python Software Foundation. Aunque los proyectos atienden a comunidades y casos de uso diferentes, todos dependen de canalizaciones de entrega de software que pueden convertirse en objetivos atractivos cuando se combinan la confianza en los colaboradores y la automatización.

Los investigadores de seguridad y los responsables del mantenimiento de proyectos han advertido cada vez más que los ataques basados en solicitudes de incorporación pueden ser eficaces porque aprovechan las prácticas normales de colaboración. En muchos entornos de desarrollo modernos, el código de colaboradores externos se prueba automáticamente antes de integrarse. Si estas comprobaciones no están cuidadosamente aisladas, un atacante podría influir en los pasos de compilación, exponer secretos o introducir cambios difíciles de detectar durante una revisión rutinaria.

Por qué es importante el problema

Incluso cuando una solicitud de incorporación no modifica directamente los sistemas de producción, puede crear riesgos graves en toda la cadena de suministro de software. Un compromiso en la etapa de desarrollo puede propagarse a versiones posteriores, distribuciones de paquetes y entornos de los usuarios.

• La automatización puede ejecutar código no confiable durante la revisión o las pruebas.
• Los secretos, tokens o claves de firma pueden quedar expuestos si los controles de la canalización son débiles.
• Los proyectos de confianza pueden convertirse en puntos de entrada para abusos más amplios de la cadena de suministro.

El informe subraya la necesidad de establecer medidas de protección más sólidas en torno a los flujos de trabajo de los colaboradores, incluidos permisos más estrictos, una gestión más segura de los secretos y una ejecución de CI/CD más restrictiva para las contribuciones externas. Para los equipos que mantienen herramientas e infraestructuras populares, la conclusión es clara: la comodidad de la colaboración no debe lograrse a costa de la seguridad de las canalizaciones.