Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Principales conclusiones
- Las correcciones de SecureChain estarán disponibles en JFrog Zero-Touch Remediation y se aplicarán sin que se produzca un cambio de versión.
- La detección nunca fue lo más difícil; lo difícil siempre fue crear y aplicar una solución que no provocara errores.
- La cobertura continúa incluso después de que los responsables del mantenimiento del proyecto original dejen de publicar correcciones de seguridad para un paquete.
- Cada corrección aplicada queda certificada a través de JFrog AppTrust, por lo que la evidencia de auditoría se genera directamente en el proceso de desarrollo.
Se detecta una vulnerabilidad CVE crítica en un paquete situado a tres niveles de profundidad en el árbol de dependencias. El escáner la detecta ese mismo día, lo cual es la parte fácil. Pero resulta que la corrección solo está disponible en una versión principal, esa versión modifica una API a la que recurren dos de tus servicios, y el paquete que la incorporó está fijado por un SDK de un proveedor sobre el que nadie del equipo tiene control. Dos semanas después, el ticket sigue abierto y el hallazgo sigue figurando en el informe.
Encontrar un paquete de código abierto vulnerable rara vez es lo más difícil. Lo complicado de la corrección es aplicar la solución adecuada a la versión correcta, sin generar un segundo problema en el proceso.
Esa es la brecha que pretende cubrir esta nueva colaboración. TuxCare se ha incorporado al «Ecosistema de seguridad de la cadena de suministro de software con autorreparación» de JFrog como socio fundador, y SecureChain se integrará con «JFrog Zero-Touch Remediation» como fuente de correcciones para los paquetes de código abierto vulnerables.
Dónde se estanca realmente la corrección de fallos en el software de código abierto
La cobertura de los escáneres es ya lo suficientemente buena como para que la mayoría de los equipos conozcan sus dependencias vulnerables mucho antes de que nadie tenga un plan para ellas. Lo que obtienen es una cola.
Un paquete de terceros vulnerable deja tres opciones reales: actualizar a la versión corregida, adaptar la corrección tú mismo o aceptar el riesgo y anotarlo. La primera es la que recomienda cualquier herramienta y, a menudo, la menos práctica, ya que los cambios de versión en las dependencias transitivas se propagan en cadena de formas que nadie puede predecir a partir del manifiesto. A veces, la versión afectada ya ha llegado al final de su ciclo de vida, por lo que no queda ninguna actualización que se pueda realizar. La segunda opción implica mantener una bifurcación de un código que no has escrito tú, en una base de código que no puedes probar adecuadamente. La tercera es la que suele ocurrir.
Imagina un equipo de plataforma formado por 30 personas que gestiona una docena de servicios Java, la mitad de los cuales están limitados a una versión antigua de Jackson debido a un SDK que tienen bajo licencia en lugar de ser de su propiedad. La actualización es un proyecto que abarca varios sprints y que no conlleva la incorporación de ninguna nueva funcionalidad. Los desarrolladores dedican días enteros a comparar opciones de solución antes de encontrar una que se pueda implementar de forma segura. Los mismos resultados aparecen en el informe semanal sea cual sea la opción elegida, y la fecha de la auditoría no se modifica.
Qué aporta SecureChain
Los paquetes de SecureChain se vuelven a compilar a partir del código fuente, se analizan en busca de malware antes de su publicación y se les aplican parches para las vulnerabilidades conocidas sin modificar la versión que figura en el manifiesto.
Hay dos aspectos importantes para esta integración. La corrección conserva el mismo número de versión, por lo que no es necesario modificar nada en el gráfico de dependencias. Además, la cobertura no finaliza cuando cesa el mantenimiento por parte de los desarrolladores originales, ya que el «Endless Lifecycle Support» sigue publicando correcciones para esa línea de versiones incluso después de que los mantenedores hayan dejado de hacerlo.
Esa segunda propiedad es donde se encuentran muchos hallazgos de larga duración. Un paquete que no ha recibido ninguna confirmación en tres años no va a recibir una corrección CVE por parte de su responsable de mantenimiento, por muchas incidencias que lo mencionen.
En la actualidad, la cobertura de SecureChain abarca npm, PyPI y Maven, y Go, Rust y PHP figuran en la hoja de ruta.
¿Qué ocurre dentro de la tubería?
Artifactory es la fuente de la que se obtienen las compilaciones, lo que lo convierte en el único lugar en el que se puede sustituir una corrección sin necesidad de pedir a ningún desarrollador que modifique nada.
La corrección «Zero-Touch Remediation» asocia un componente vulnerable con la mejor solución de un socio disponible según tu política, la aplica a través del proceso de integración que ya ejecutas y registra una certificación firmada de la acción mediante JFrog AppTrust. Cuando tu política prefiera un paquete reconstruido desde el código fuente y actualizado continuamente, se proporcionará la versión de SecureChain. La compilación solicita el mismo paquete que solicitó ayer y recibe uno actualizado.
Sin ticket. Sin tener que buscar una versión compatible. Sin tener que negociar con el equipo responsable del servicio.
La parte relativa a la certificación tiene más valor de lo que parece. La mayoría de los equipos pueden demostrar, en última instancia, que se ha aplicado un parche a un paquete. Sin embargo, son muchos menos los que pueden demostrar cuándo se aplicó el parche, para qué CVE y mediante qué proceso, de una forma que un auditor acepte sin necesidad de un hilo de seguimiento.
Dónde se nota primero el resultado
Los casos más evidentes son los paquetes cuyo soporte por parte de los desarrolladores originales ha finalizado, las dependencias transitivas que tu equipo nunca eligió y que no puede sustituir fácilmente, y cualquier entorno en el que los acuerdos de nivel de servicio (SLA) para la resolución de incidencias sean contractuales y no meramente orientativos.
Si ya utilizas Artifactory con Xray o Advanced Security, añadir SecureChain como fuente de correcciones es una decisión de política más que una migración. Si tus compilaciones se obtienen de una fuente distinta a JFrog, SecureChain sigue funcionando como un registro independiente y filtrado, y la integración estará disponible cuando la necesites.
En cualquier caso, el cambio al que hay que prestar atención no es que existan soluciones. Las soluciones ya existían antes. Es que una solución puede llegar a una versión en ejecución sin que nadie tenga que introducirla manualmente, lo que hace que la corrección pase de ser una tarea puntual del proyecto a formar parte de la rutina del proceso de lanzamiento del software.
Más información sobre la corrección sin intervención de JFrog: jfrog.com/zero-touch-remediation
Más información sobre TuxCare SecureChain: tuxcare.com/securechain-for-oss
