Cómo Runna hizo de la seguridad un deporte de equipo, sin ralentizar el transporte marítimo

Hola, Walter. ¿Puedes hablarme un poco más de ti y de tu papel en Runna?

Sí, soy Water, director técnico de Runna. Como uno de los primeros empleados, al principio me centré en construir la plataforma y la aplicación móvil desde cero. Junto con la infraestructura de backend, todo esto estaba (y sigue estando) alojado en AWS y con una arquitectura totalmente sin servidores (lo que es una locura y a la vez genial para nosotros si lo piensas). Comparto este contexto porque a día de hoy nos permite escalar el producto rápidamente con un número reducido de ingenieros.

Desde que asumí el liderazgo, me he centrado en el crecimiento del equipo y la ampliación de la plataforma. Ahora somos un equipo de 45 personas estructurado en cinco equipos:

1. Equipo de aplicaciones: Ingenieros de pila completa que crean características integrales en nuestra pila: React Native, AWS Serverless, GraphQL, DynamoDB, S3.
2. Equipo de formación: Ingenieros de ML y Python que mejoran nuestro motor de formación y las funciones basadas en LLM, como la ingeniería de avisos con OpenAI y Gemini.
3. Equipo de datos: Centrado en la creación de un almacén de datos basado en Snowflake para extraer información de los datos de formación y actividad que actualmente se encuentran aislados en DynamoDB y S3.
4. Equipo de plataforma: Garantiza la escalabilidad y flujos de trabajo de desarrollo fluidos mediante la aplicación de las mejores prácticas sin servidor y la prevención de cuellos de botella de ingeniería.
5. Equipo de crecimiento: Desarrolla aplicaciones nativas para wearables como Apple Watch para ampliar nuestro ecosistema de productos.

Por supuesto, estos equipos cuentan con el apoyo de equipos de producto interfuncionales (con diseñadores, jefes de producto...).

¿Cómo enfoca Runna la seguridad? 

Nuestra forma de trabajar es como un equipo de generalistas. Animamos a todo el mundo a abordar todas las cosas de forma integral, incluida la seguridad.

Por lo general, el equipo de Plataforma de Runna se encarga de la seguridad de nuestra nube. Como todo está alojado en AWS, configuramos el centro de configuración y seguridad de AWS. Tenemos un ingeniero de seguridad responsable de todo lo relacionado con la seguridad: desde el punto de vista estratégico (que va más allá de la seguridad en la nube, como los programas de detección de errores, las pruebas de penetración externas...) hasta las herramientas y el seguimiento de las alertas (críticas), y nos aseguramos de que los diferentes equipos realicen el triaje.

Mientras oyes (o lees) esto, probablemente pensarás que es bastante difícil. Y lo es. No es factible que una sola persona se ocupe de todo. Es mucho trabajo manual y, a veces, algo secundario, que es donde entra en juego el Aikido.

"No es posible que una sola persona se ocupe de todo. Es mucho trabajo manual y, a veces, algo secundario. Ahí es donde entra el Aikido".

¿Hubo otros problemas de seguridad?

Dejando a un lado el tedio manual y las prioridades contrapuestas, buscábamos una solución de seguridad que pudiera servir como extensión de los conocimientos de seguridad internos más limitados que teníamos. Debía servir como una extensión de nuestro equipo, con la capacidad de automatizar tanto como fuera posible el marcado, la clasificación y la corrección.
‍

"Buscábamos una solución de seguridad que sirviera de ampliación de los conocimientos de seguridad internos más limitados que teníamos".

‍

Tenemos suerte de que nuestra plataforma solo tenga 2-3 años y de que alojemos todo en AWS. La aplicación móvil es bastante nueva y la aplicación web aún más, por lo que la consolidación de la seguridad en todos los productos que ofrecemos también era una prioridad.

¿Cuándo empezó a interesarse por las herramientas de seguridad?

La evaluación partió del deseo de desplazar todo hacia la izquierda. Queríamos que la seguridad fuera lo más autosuficiente posible y, al mismo tiempo, permitir que todos los equipos contribuyeran a proteger nuestro producto. Lo último que querríamos es que la seguridad se convirtiera en una fuente única y aislada de la que todo el mundo se desentendiera y afirmara que "no es su problema" (risas). 

Empezamos a buscar una herramienta que resolviera lo anterior, a la vez que fuera capaz de:

• Señale los problemas lo antes posible, y
• Enviar pull requests a repositorios específicos, planteando problemas de seguridad cuando alguien intente enviar código.

‍

"Queríamos que la seguridad fuera lo más autosuficiente posible y, al mismo tiempo, permitir que todos los equipos contribuyeran a asegurar nuestro producto".

‍

¿Evaluó otras herramientas de seguridad antes de que Aikido entrara en escena?

Ya utilizábamos Dependabot para la gestión básica de dependencias. Evaluamos brevemente Snyk también, sobre todo porque es uno de los grandes jugadores. Pero, sinceramente, nos pareció demasiado pesado para lo que necesitábamos. Venía con un montón de complejidad y un alto precio, y no vimos el valor para nuestro tamaño y configuración.

Lo que realmente hizo que Aikido destacara fue la rapidez con la que lo pusimos en marcha. La configuración fue pan comido, la interfaz de usuario parecía hecha a medida para desarrolladores, y funciones como AI AutoFix y PR automáticos nos dieron la sensación de que no se trataba de un panel de control más, sino de algo que realmente podía quitarnos trabajo de encima. Fue como añadir otro ingeniero al equipo, sin tener que pasar por el proceso de contratación.

‍

Lo que realmente hizo destacar a Aikido fue la rapidez con la que nos pusimos en marcha. Fue como añadir un ingeniero más al equipo, sin tener que pasar por el proceso de contratación.

‍

¿Cuál es el tiempo más rápido que ha pasado de alerta de seguridad a solución? 

Para cualquier cosa crítica (por ejemplo, una alerta de dependencia de alta gravedad) hemos sido capaces de parchear y enviar la solución en un par de horas desde que recibimos la alerta. Esto se debe en gran parte a la forma en que Aikido se integra en nuestro flujo de trabajo: los problemas aparecen con claridad, las relaciones públicas se generan automáticamente y nuestros ingenieros pueden intervenir con el contexto ya preparado. Es un cambio de juego en términos de reducción del retraso entre la detección y la resolución.