¿Está amenazado el futuro del código abierto?

El software de código abierto (OSS) es la columna vertebral de la arquitectura de aplicaciones actual. Al acelerar el tiempo de comercialización y reducir la carga de los desarrolladores, que a menudo tienen exceso de trabajo, el código abierto ha consolidado su posición revolucionaria dentro del panorama de DevOps. Aunque profundamente transformador para el desarrollo de aplicaciones modernas, copiar y pegar de código abierto sigue representando un importante riesgo de seguridad tanto para las organizaciones como para las personas. Combatir esto exige una lista negra total de código fuente abierto o la implementación proactiva de contramedidas, como una solución WAF de próxima generación.

El código de terceros es vital para el desarrollo de aplicaciones

Las bibliotecas son depósitos de código fuente increíblemente útiles para componentes de aplicaciones web o móviles. Estas bibliotecas pueden ser de código abierto, disponibles para todos sin costo alguno, o propietarias, que bloquean el código detrás del pago. Aunque el código abierto reclama gran parte de la gloria, el código propietario también juega un papel en el funcionamiento continuo de las aplicaciones empresariales.

Este software de terceros, cuando se usa de manera responsable, evita que los desarrolladores tengan que reinventar constantemente la rueda. Esto mejora drásticamente la eficiencia del proceso de desarrollo, mientras ayuda en la producción de un producto final de alta calidad. En última instancia, el uso gratuito y liberal del código fuente abierto crea un ciclo de retroalimentación positiva, lo que permite a los desarrolladores lanzar su producto mínimo viable más rápido, lo que allana el camino para una rápida recopilación e implementación de la retroalimentación y evaluación de los usuarios. Si bien los desarrolladores son muy conscientes de la posición crítica del código abierto dentro del proceso DevOps, los ejecutivos a menudo se sorprenden al saber que el 80 % del código que admite aplicaciones modernas se origina a partir de código preexistente.

El oscuro peligro de las dependencias transitivas

No es ninguna novedad que el código fuente abierto conlleva riesgos. Las debilidades generalizadas recientes, como Log4j y HeartBleed, colocaron irrevocablemente el riesgo de fuente abierta en el mapa. Lo que sigue siendo un área creciente de comprensión es la gran frecuencia con la que se usa el código abierto y el sigilo con el que las vulnerabilidades pueden colarse en un proyecto activo. A pesar del riesgo continuo que presentan los proyectos de código abierto, se ha realizado muy poca investigación sobre el tipo específico de riesgo que presenta el código abierto. Los investigadores de Endor Labs se propusieron cambiar esto aclarando el origen de las principales amenazas de OSS.

Dentro del software, las dependencias transitivas describen una relación indirecta única entre dos componentes. Por ejemplo, supongamos que su equipo de desarrollo agrega el paquete B a un proyecto en curso. El paquete B, a su vez, descarga automáticamente el paquete C. En este escenario, mientras que el software en desarrollo disfruta de una relación directa con el paquete B, el paquete C permanece al acecho en segundo plano, integral pero en gran parte invisible. Lo que frustra cualquier intento de prácticas de desarrollo más seguras es el hecho de que solo el 5% de las dependencias de software de código abierto se seleccionan manualmente para su implementación dentro del proceso DevOps. De esta manera, la mayoría de las dependencias simplemente se introducen automáticamente en el código base. Esto describe la fuente de una vulnerabilidad transitiva. Un informe reciente de Endor Labs encontró que un asombroso 95 % de las vulnerabilidades de código abierto se originan en dependencias transitivas .

Los datos se compilaron a partir del informe Census II de Core Infrastructure, que enumera el software gratuito de código abierto más popular. Luego, estos datos se enriquecieron con otras fuentes que permitieron a los investigadores de Endor escanear administradores de paquetes populares y bibliotecas OSS. Los investigadores descubrieron que, de los 254 paquetes mencionados en los datos del Censo II, la mayoría sufre un promedio de 14 dependencias transitivas. En el vacío, 14 puede no parecer sorprendentemente alto, pero la mayoría de las aplicaciones se basan en docenas, si no cientos, de dependencias directas; sus contrapartes transitivas escalan exponencialmente.

La principal preocupación expresada por los investigadores se basa en la subestimación generalizada del problema por parte de la industria. Los ejecutivos continúan socavando la cantidad de código fuente en uso dentro del proceso de desarrollo: las dependencias transitivas aún no están en el radar. La gran profundidad de los problemas de seguridad continúa acechando debajo de la superficie, aumentando el radio de explosión de los ataques de ejecución remota de código y typosquatting. Si la reutilización constante del código fuente abierto está a la altura de su potencial, la seguridad debe convertirse en una prioridad más alta dentro del proceso DevOps.

Cómo protegerse contra las vulnerabilidades al acecho

El proceso de mantener una pila de tecnología segura nunca ha sido más complejo. Dado que las alertas de parches se vuelven rápidamente abrumadoras, es hora de que la seguridad empresarial priorice la protección automatizada y sin parches. Las medidas tradicionales que priorizan la seguridad del perímetro junto con el análisis estático y dinámico se basan en actualizaciones manuales, lo que significa que no hay protección contra los días cero. El código de puerta trasera que los atacantes usaron en el infame ataque de SolarWinds no fue detectado por ningún análisis estático, ya que técnicamente no hubo errores.

La identificación y el bloqueo de los intentos de explotación requieren un pequeño paquete de software de interbloqueo. Primero, para ayudar a definir y proteger el perímetro de una aplicación, se puede implementar un firewall de aplicaciones web (WAF) de última generación. Sentado en el límite entre lo externo y lo interno, el WAF monitorea todo el tráfico que fluye hacia y desde una aplicación. El aspecto de próxima generación permite que este WAF se adapte e implemente automáticamente nuevas políticas. La implementación automatizada de esta evolución constante libera una cantidad significativa de tiempo y energía para el equipo de seguridad que, de otro modo, consumiría un WAF de la vieja escuela.

Mientras que WAF controla cualquier intento externo de ejecutar código, la autoprotección de aplicaciones en tiempo de ejecución (RASP) protege contra las debilidades internas y las inyecciones de código. Este nivel de protección evalúa todas las cargas útiles (como consultas SQL y comandos del sistema operativo) en tiempo real. Este proceso no requiere firmas ni una fase de aprendizaje y se lleva a cabo completamente dentro del contexto de la aplicación. Como esto opera dentro de la aplicación, cubre casi todos los contextos. Esto significa que, incluso si un exploit permite que se rompa el perímetro, se evita que un atacante se mueva lateralmente, ya que cualquier comportamiento sospechoso de la aplicación desencadena un cierre de RASP. Esto pone fin a la actividad sospechosa y alerta a los equipos de seguridad. De esta forma, RASP es complementario a un WAF de próxima generación; mientras que el WAF ayuda a mantener alejado el tráfico malo, el RASP mitiga el riesgo que plantean los exploits transitivos al acecho. Con estos componentes que protegen una pila de tecnología, la carga que el OSS actualmente impone sobre la seguridad se aligera significativamente.