Skip to main content

Serverless es genial, pero ¿qué pasa con la seguridad de mis funciones de AWS Lambda y sus dependencias?

Escrito por

3 de julio de 2019

0 minutos de lectura

Las plataformas de Function as a Service (FaaS) aplican parches a las dependencias del sistema operativo por ti, pero no hacen nada para proteger las dependencias de tu aplicación, como las que se obtienen de npm, PyPI, Maven y otros. Estas bibliotecas son tan frecuentes y vulnerables como las dependencias del sistema operativo, y tú, como responsable de la aplicación, debes actualizarlas o aplicarles parches cuando se divulga una vulnerabilidad en ellas.

Además, como los atacantes saben que las dependencias del servidor a nivel del sistema operativo, de las que se encarga el proveedor de la nube, se corrigen rápidamente, centrarán su atención en el código y las dependencias de la aplicación.

Para destacar la complejidad de rastrear las dependencias de una función, en un reciente informe State of Open Source Security 2019, Snyk mostró que las vulnerabilidades de seguridad en las dependencias indirectas representan el 78% del total de vulnerabilidades.

Gráfico de barras apiladas que muestra las proporciones de dependencias directas e indirectas en PyPI, PHP Packagist, Maven Central, RubyGems y npm.

Esto significa que, la mayoría de las veces, las vulnerabilidades de seguridad se encontrarán en dependencias indirectas instaladas por tus dependencias de nivel superior. En el ecosistema de npm, una dependencia promedio tiene más de 4 niveles de profundidad, lo que hace difícil rastrear tus dependencias y su seguridad.

Al igual que cuando desarrollas aplicaciones que no son serverless, debes proteger las funciones durante todo el ciclo de desarrollo. Empieza en el entorno de desarrollo integrado (IDE), con un complemento que te avise sobre las vulnerabilidades en las dependencias que necesitas durante el desarrollo, por ejemplo, en VSCode o IntelliJ. Luego, realiza pruebas de seguridad en tu CI durante la compilación y antes de implementar.

¿Y si existiera una herramienta que te ayudara con las pruebas de seguridad y abriera pull requests automáticamente para corregir las vulnerabilidades a medida que se descubren, o que interrumpiera las compilaciones de integración continua (CI) para evitar implementaciones cuando se introducen nuevas vulnerabilidades de seguridad?

En una publicación anterior compartí más información sobre la seguridad serverless: 10 prácticas recomendadas de seguridad serverless, que quizá te interese leer más adelante. Por ahora, continuemos con la historia de mi propio proyecto serverless:

¿Cómo se prueban la seguridad de mis funciones serverless en AWS?

Con una plataforma serverless, puede resultar complicado monitorear las dependencias de seguridad de las funciones que implementaste. Quiero hacer un breve recorrido por cómo lo hago con Snyk en mi propio proyecto personal serverless, que desarrollé con Node.js e implementé en AWS Lambda.

Para encontrar y corregir automáticamente las vulnerabilidades en las dependencias de tus funciones, empieza por conectar Snyk a un repositorio Git de tu elección.

Lo probé con mi propio repositorio. Exploré mis repositorios de GitHub para encontrar bazz, mi proyecto serverless, y cuando se analizó el proyecto, también descubrí vulnerabilidades de seguridad en las dependencias que usan mis funciones de Lambda:

Interfaz de Snyk que muestra la selección de un repositorio de GitHub y una vulnerabilidad de aleatoriedad insegura de gravedad alta en package.json

¡Vaya! Tengo bastantes vulnerabilidades tanto en el proyecto del frontend como en el servicio API de las funciones serverless. Es hora de hacerlas desaparecer. Puedo mitigarlas manualmente abriendo un PR de corrección desde la interfaz de Snyk en la página de cada proyecto, o el bot de Snyk puede detectarlas y abrir un PR automático en mi repositorio en mi nombre. Solo tengo que ver que las pruebas pasen y combinar el PR. Mira:

pull request de GitHub que muestra a Snyk Bot corrigiendo una dependencia vulnerable de npm en el repositorio lirantal/bazz-frontend

Exige implementaciones seguras de funciones serverless

Además del monitoreo de CI y del repositorio de código fuente, y de la aplicación proactiva de parches para las vulnerabilidades de seguridad, también se debe revisar la seguridad del flujo de implementación de una función. Las implementaciones deben detenerse cuando se detectan vulnerabilidades en las funciones que se van a implementar.

Exigir el monitoreo de seguridad de código abierto en las implementaciones serverless agrega otra capa de defensa para garantizar que las funciones no se implementen en sus entornos de destino si contienen vulnerabilidades conocidas de código abierto en las dependencias incluidas.

El framework Serverless es un conjunto de herramientas común para desarrollar e implementar funciones serverless. Su arquitectura de complementos permite integrar flujos de trabajo personalizados en el ciclo de vida de las funciones. Snyk ofrece un complemento Serverless de código abierto que se integra a la perfección con el framework.

A continuación, se muestra una imagen del complemento protegiendo activamente una función para evitar su implementación, ya que se detectaron vulnerabilidades de seguridad en las dependencias de código abierto:

Terminal que muestra una implementación de Serverless Framework bloqueada por alertas de Snyk sobre dependencias vulnerables, como minimatch y request.

También se recomienda configurar el complemento del framework Serverless para que capture instantáneas de las dependencias del proyecto en cada implementación y las monitoree para identificar nuevas vulnerabilidades cuando se descubran. Una solución como Snyk puede alertarte y corregir el problema automáticamente al abrir pull requests que reparan las dependencias vulnerables.

A veces, el flujo de trabajo de CI/CD serverless requiere más personalización y control. En esos casos, resulta útil la utilidad de línea de comandos de código abierto de Snyk, que ofrece a los desarrolladores e ingenieros de DevOps una herramienta de seguridad flexible para incorporar a sus flujos de trabajo.

Puedes instalar Snyk en un entorno local o en un trabajo de CI donde se compile el proyecto serverless y ejecutar snyk test para encontrar vulnerabilidades, así:


$ npm install -g snyk
$ snyk test

Corregir las vulnerabilidades de seguridad lo antes posible es una buena práctica. Sin embargo, todavía puede haber diferencias entre las versiones de las dependencias en el repositorio de código fuente y las versiones en la función implementada. Esto suele deberse a las demoras al promover el código a un entorno de pruebas o producción, lo que pone en riesgo la función implementada, ya que puede incluir dependencias desactualizadas con vulnerabilidades conocidas.

Por último, no olvides revisar esta lista completa que preparé: ¡10 prácticas recomendadas de seguridad serverless! Regístrate para obtener una cuenta gratuita de Snyk y empieza a corregir vulnerabilidades.

Empieza con Capture the Flag

Aprende a resolver desafíos de Capture the Flag viendo nuestro taller virtual introductorio a pedido.