En una publicación de blog de marzo de 2026, Daniel Stenberg, fundador y desarrollador principal de curl, sostiene que la posición predeterminada de la industria del software de depender de componentes conocidos ya no es apropiada. Stenberg dice que los usuarios y las organizaciones necesitan verificar activamente el software que consumen, y utiliza las prácticas de curl como un ejemplo concreto de cómo se puede hacer esto.
Curl se ejecuta en decenas de millones de dispositivos y es uno de los componentes de software más utilizados disponibles en la actualidad. Stenberg enumera una variedad de escenarios en los que un proyecto de esta escala podría estar en riesgo, incluido un colaborador malicioso que fusiona código infectado, un autor comprometido que distribuye inadvertidamente versiones modificadas, un miembro del equipo extorsionado que realiza cambios no deseados o un servidor de distribución pirateado que sirve archivos comprimidos modificados. Advierte que estos escenarios pueden ocurrir de forma independiente o en secuencia rápida, y que las consecuencias de un ataque exitoso a un proyecto al alcance de la mano pueden ser nefastas.
«El software y la seguridad digital deben basarse en la verificación, no en la confianza. Recomiendo encarecidamente a más usuarios y consumidores de software que verifiquen curl. E, idealmente, exija que pueda realizar al menos este nivel de verificación en otros componentes de software en sus cadenas de dependencia».
-Daniel Stenberg
El proyecto curl ha implementado una amplia gama de controles para hacer del repositorio git una fuente de verdad autorizada y auditable. Estas incluyen imponer un estilo de código consistente, prohibir el uso de ciertas funciones de C que se consideran difíciles de usar de forma segura, establecer un límite a la complejidad de las funciones, requerir una revisión automática y humana de todas las solicitudes de extracción y prohibir la mayoría de los usos de blobs binarios y contenido codificado en base64, los cuales podrían usarse para ocultar cargas útiles maliciosas. Stenberg describe más de 200 trabajos de CI que se ejecutan en cada confirmación, utilizando configuraciones estrictas del compilador que tratan las advertencias como errores, confusión continua a través del proyecto OSS-Fuzz de Google y autenticación obligatoria de dos factores para todas las confirmaciones. Cada uno de estos está diseñado para hacer visible una desviación del comportamiento esperado para cualquiera que siga el proyecto.
Además de estos controles internos, Stenberg aboga por un ecosistema de verificación más amplio. Explicó que el proyecto proporciona artefactos de lanzamiento firmados y una página de verificación dedicada en el sitio web de curl para que los usuarios independientes puedan verificar que un lanzamiento contiene solo lo que está en el repositorio de git y ha sido firmado por el administrador de versiones. Admite que no puede saber quiénes son esos usuarios, o si existen hoy en día, pero incluso un pequeño número de verificadores independientes es suficiente para proporcionar una verificación significativa: uno de ellos puede dar la alarma si algo parece mal.
«Si incluso unos pocos usuarios pueden verificar que obtuvieron una versión curl firmada por el administrador de versiones curl y que el contenido de la publicación no está contaminado y solo contiene bits generados desde el repositorio git, estamos en bastante buena forma».
-Daniel Stenberg
Stenberg finaliza su publicación con una recomendación directa de exigir dicha verificación para todas las dependencias, que «el software y la seguridad digital deben basarse en la verificación, no en la confianza». El debate comunitario previo a abril de 2025 se hace eco de esta posición de varias maneras. En LinkedIn, los profesionales de seguridad e ingeniería de plataformas han argumentado que la puerta trasera XZ Utils, descubierta en 2024 y que implicó un largo esfuerzo para inyectar código malicioso a través de un codificador confiable, mostró los límites de la confianza basada en la reputación, como en esta publicación de Cameron Stihel y esta publicación de Ryan Johnston. El ataque, que tuvo como objetivo el componente liblzma al ganarse la confianza de los mantenedores con el tiempo antes de introducir cambios en el código, es exactamente el tipo de escenario que Stenberg describe en su lista de vectores de amenazas.
Una de las herramientas de estructuración disponibles para especificar exactamente qué contiene una pieza de software es la Lista de materiales del software. En una charla en QCon London 2026 cubierta por InfoQ, Viktor Petersson, fundador de sbomify, argumentó que a los equipos se les está acabando el tiempo para adoptar SBOM. Citó la Ley de Resiliencia Cibernética de la UE, que abre su primera ventana de aplicación en septiembre de 2026 y exige el pleno cumplimiento de la SBOM para diciembre de 2027, y advirtió que sus consecuencias van más allá de las multas: «La CRA no se trata de multas. De hecho, pueden bloquear las ventas. Sus productos pueden ser bloqueados del mercado europeo». La Orden Ejecutiva 14028 de EE. UU., vigente a partir de 2021, convierte los SBOM en un requisito de adquisición para el software vendido al gobierno federal, y la FDA lo exige para los dispositivos médicos.
La charla de Petersson cubrió todo el ciclo de vida de producción de SBOM, incluido el paso que la mayoría de los equipos omiten: la firma. Dijo directamente que esto es un error y que firmar instrumentos específicos es menos importante que él, ya que esto proporciona una cadena de custodia verificable. Petersson fue directo: «Cualquier firma es mejor que no firmar ninguna. Firme sus SBOM en su canalización, no en la máquina de otra persona». Esto se relaciona directamente con el argumento de Stenberg: curl ya proporciona artefactos de autorización firmados y define claramente los pasos de verificación, brindando a los consumidores la cadena de custodia que Petersson describe como el objetivo.
La cartera de CI/CD también es un punto débil potencial. InfoQ recibió una confirmación de GitHub Action ampliamente utilizada en abril de 2025, que destaca cómo una sola acción maliciosa o comprometida puede exponer secretos y crear artefactos en muchos proyectos a la vez. El evento exige controles más estrictos sobre las acciones de terceros, fijando dependencias a hashes comprometidos específicos y rastreando cambios inesperados en las herramientas de CI. El enfoque de Stenberg aborda esto directamente: los trabajos de CI curl se configuran para tener acceso de solo lectura al repositorio de origen y se verifican con la herramienta zizmor para reducir el riesgo de configuraciones de trabajo inseguras.
Petersson también destacó el desafío del ciclo de vida, señalando que un producto real a menudo tiene docenas de SBOM que cambian con cada ejecución de CI, y que los reguladores pueden requerir SBOM para una versión anterior específica. Comparó la práctica actual con el desarrollo de software antes del control de versiones: «Tratar con SBOM hoy en día se siente como administrar el código fuente en los años 90, con parches enviados por correo electrónico». Esta cuestión de la gobernanza alimenta el punto más amplio de Stenberg. Existen herramientas para producir, firmar y verificar artefactos de software, y la presión regulatoria para usarlas está aumentando, por lo que las organizaciones deben cerrar el círculo verificando lo que consumen.
