Cómo Log4j se convierte en un grave problema de DevOps

Lo más preocupante de la vulnerabilidad (CVE-2021-44228) es la prevalencia del uso de Log4j. La vulnerabilidad se informa en una amplia gama de aplicaciones e impacta directamente en numerosos proyectos de Apache, incluidos Druid, Dubbo, Flink, Flume, Hadoop, Kafka, Solr, Spark y Struts. La lista de aplicaciones y bibliotecas afectadas parece ser casi infinita.

En pocas palabras, cualquier aplicación que utilice Log4J para el registro y el seguimiento está sujeta a la familia de ataques identificada conocida como Log4Shell. Esos ataques resultan fáciles de explotar y pueden usarse para tomar el control de servidores vulnerables.

Por qué deben preocuparse los profesionales de DevOps

El mundo de DevOps tiene que ver con la reiteración, donde las características y mejoras de las aplicaciones se incorporan a los entornos de producción. Para acelerar el desarrollo, el proceso de garantía de calidad suele limitarse a los cambios más recientes.

En otras palabras, los desarrolladores, a través de sus pipelines, a menudo pueden establecer una línea de base de calidad y luego acelerar sus pipelines de CI / CD probando solo lo que ha cambiado desde la última iteración de la aplicación. Este proceso asegura un nivel aceptable de calidad sin introducir pasos que se perciben como innecesarios.

Sin embargo, esos procesos no tienen en cuenta las fallas recién descubiertas en las API y bibliotecas más antiguas, lo que significa que esas fallas podrían transmitirse a las aplicaciones implementadas y dejar a los equipos de DevOps completamente inconscientes del impacto y la posible interrupción. Detectar fallas después de implementar una aplicación es como poner el carro frente al caballo.

Para complicar aún más la situación, muchos desarrolladores carecen de una lista de materiales de software (SBOM) bien definida y mantenida, lo que significa que los desarrolladores pueden desconocer los componentes y / o bibliotecas que se utilizan en una aplicación implementada.

Sin un SBOM, se vuelve cada vez más difícil solucionar un problema con una aplicación, especialmente si los desarrolladores no son conscientes del problema para empezar.

¿Dónde debería estar la responsabilidad?

La mayoría de las veces, las vulnerabilidades introducidas en las aplicaciones se convierten en un juego de señalar con el dedo, donde los desarrolladores culpan a los proveedores de bibliotecas o al personal de seguridad de la información, y la seguridad de la información culpa a los desarrolladores por no realizar la debida diligencia en los componentes que están seleccionando para incorporar en sus aplicaciones.

Por supuesto, señalar con el dedo solo aumenta la angustia y retrasa el proceso de corrección y no hace nada para determinar dónde reside la responsabilidad de detectar y remediar las vulnerabilidades. Los equipos de DevOps deben dejar de lado estas disputas y establecer un proceso que se ocupe de las vulnerabilidades introducidas involuntariamente. Además, los equipos de DevOps deben invertir en DevSecOps para asegurarse de que las vulnerabilidades se detecten y solucionen lo antes posible.

Descubre la innovación

Para asegurar el éxito empresarial, ahora y a futuro, es imprescindible maximizar el retorno de la inversión existente en software, a la vez que innovar y adoptar nuevas tecnologías. Los retos que hay abordar para competir en un mundo de TI Híbrida incluyen DevOps, Seguridad, Gestión de riesgos y Análisis predictivo. Puedes obtener más información sobre cómo abordar estos retos e innovar en este enlace.