Implementación de medidas de seguridad para desarrolladores en una organización con más de 5.000 ingenieros

A las grandes empresas de ingeniería les gusta creer que sus mayores problemas son de carácter técnico. Si tan solo alguien aprobara el presupuesto para la última herramienta, todo se resolvería. Últimamente, la apuesta mayoritaria es que la solución milagrosa es la programación intuitiva basada en tu modelo de lenguaje grande (LLM) preferido. Pero los problemas de las grandes organizaciones rara vez son de naturaleza técnica. 

Según mi experiencia, se trata de problemas relacionados con los procesos y pueden manifestarse en dos extremos opuestos. Por un lado, están los equipos atrapados en la «parálisis por análisis», que se ven envueltos en un ciclo interminable de reuniones, revisiones y diseños basados en el consenso, sin apenas resultados que mostrar. Por otro lado, están aquellos que «se lanzan sin mirar», con una tendencia a la acción que les lleva a sufrir muchos tropiezos por culpa de su propia falta de reflexión.

En algún momento, cuando una organización supera los 5.000 colaboradores activos, la naturaleza de la transformación de la seguridad cambia por completo. Las herramientas dejan de ser el factor limitante. El presupuesto deja de ser el factor limitante. Incluso el talento deja de ser el factor limitante. Lo que escasea es la coordinación.

La realidad es que, cuando una empresa alcanza este tamaño, ya cuenta con una estrategia de seguridad operativa, una tolerancia al riesgo definida y una estructura de seguridad basada, en líneas generales, en ratios de personal habituales. Una proporción habitual es de un profesional de seguridad por cada 100 ingenieros, lo que significa que una empresa con 5.000 desarrolladores probablemente cuente con un equipo de seguridad de 50 personas que intenta influir en miles de decisiones relacionadas con el software cada día. La cuestión no es si existe la seguridad. La cuestión es si se adapta a la escala.

Este artículo resume las lecciones aprendidas al implantar programas de seguridad para desarrolladores en organizaciones de esta envergadura y explica por qué el camino hacia el éxito es muy diferente de lo que la mayoría de los CISO esperan.

Por qué fracasan las implementaciones de seguridad para desarrolladores a escala empresarial

La mayoría de las implementaciones de seguridad fracasan por una razón sorprendentemente sencilla: se diseñan como si fueran implementaciones de software en lugar de cambios culturales. Los responsables de seguridad suelen partir de la premisa de que la combinación adecuada de herramientas (por ejemplo, SAST, SCA, análisis de contenedores, detección de secretos) producirán mejores resultados si se implementan con la suficiente amplitud. Pero la adopción de las herramientas es la parte fácil.

Lo difícil es establecer prioridades dentro de los equipos de ingeniería. Los desarrolladores ya tienen más trabajo del que pueden completar en un sprint. Los plazos de los productos marcan la prioridad de la lista de tareas pendientes. La rapidez en la implementación de nuevas funciones es visible y se premia. Las correcciones de seguridad suelen parecer algo abstracto e impuesto desde fuera. Cuando un programa de seguridad se introduce en ese entorno, la reacción habitual es previsible: se crean tickets de seguridad, se añaden a la lista de tareas pendientes y se van acumulando silenciosamente.

Los cambios en la cobertura de los análisis no alteran esta realidad. De hecho, cuantos más problemas se detectan sin que haya una responsabilidad clara, peor se vuelve la situación. Los equipos de seguridad suelen creer que están reduciendo el riesgo al aumentar la visibilidad, pero en la práctica a veces lo que hacen es agravar los riesgos no gestionados. Porque todo el mundo sabe que los problemas existen, pero nadie se hace realmente responsable de ellos.

Las limitaciones ineludibles a las que se enfrenta toda organización con más de 5.000 ingenieros

Las grandes organizaciones de ingeniería operan bajo una serie de limitaciones estructurales con las que las empresas más pequeñas rara vez se encuentran. En primer lugar, está la fragmentación del ciclo de vida del desarrollo (SDLC). Una empresa con miles de ingenieros gestiona, casi con toda seguridad, varios ciclos de vida de desarrollo simultáneamente. Algunos equipos realizan implementaciones a diario. Otros, trimestralmente. Algunos dependen de sistemas heredados creados hace una década que nadie se atreve a tocar por miedo a que dejen de funcionar por completo y se conviertan en su problema personal. En segundo lugar, está la heterogeneidad tecnológica. Un entorno empresarial típico puede incluir docenas de lenguajes de programación, múltiples sistemas de CI/CD, varias plataformas de infraestructura y una combinación de flujos de trabajo nativos de la nube y heredados.

Las herramientas de seguridad que funcionan a la perfección en un entorno pueden resultar casi imposibles de implementar en otro. En tercer lugar, la capacidad de control centralizado es limitada y no existe un único sistema que abarque todo el alcance de las aplicaciones de una organización y superficie de ataque en la nube. 

Aunque, técnicamente, el CISO dependa del CIO o del CTO, los equipos de seguridad rara vez controlan las prioridades de la cartera de proyectos de los equipos de ingeniería de producto. Influyen en ellas, pero no son los responsables. Esto genera una tensión fundamental.

Y los problemas de seguridad más peligrosos suelen ser aquellos que requieren cambios en la arquitectura, actualizaciones de dependencias o una refactorización importante. El tipo de trabajo que los ingenieros evitan instintivamente porque no encaja perfectamente en la planificación de sprints de dos semanas.

Las tareas cuya estimación supera aproximadamente los 13 puntos de historia suelen posponerse indefinidamente. Se trata de proyectos disfrazados de incidencias. El resultado es una acumulación creciente de tareas de seguridad que todo el mundo comprende a nivel teórico, pero que nadie se siente capacitado o motivado para priorizar.

El primer objetivo es la implicación, no la cobertura

Uno de los errores más comunes que cometen los responsables de seguridad es dar por sentado que la cobertura de las herramientas equivale a progreso. Ejecutar escáneres en todos los repositorios puede generar paneles de control impresionantes, pero sin una implicación real, esos paneles no son más que catálogos de riesgos. El verdadero progreso comienza con una pregunta diferente:

¿Quién se encarga de arreglar qué?

Los programas de seguridad escalables comienzan por identificar a las personas influyentes dentro de la organización de ingeniería. No se trata de los directivos oficiales, ni de los arquitectos que figuran en el organigrama, sino de los desarrolladores cuyas opiniones marcan realmente el comportamiento del equipo de ingeniería. Toda gran organización de ingeniería cuenta con ellos. Son los ingenieros y desarrolladores que transmiten la cultura y a quienes los demás consultan antes de tomar decisiones arquitectónicas. Un enfoque sorprendentemente eficaz es el modelo de «formación de formadores»:

1. Identifica a 10 desarrolladores expertos que gozan de prestigio en toda la organización
2. Formarles a fondo en prácticas de desarrollo seguro
3. Que formen a 100 expertos en ingeniería
4. Esos líderes influyen en sus propios equipos, formados por 50 desarrolladores cada uno

En cuestión de semanas, las prácticas de seguridad se extienden entre miles de ingenieros sin que el equipo de seguridad tenga que formar directamente a cada uno de ellos. A gran escala, la influencia se propaga a través de la credibilidad entre compañeros.

Cómo eligen los CISO los equipos piloto (y por qué la mayoría de los proyectos piloto resultan engañosos)

La mayoría de los programas de seguridad empresarial comienzan con una prueba piloto. En teoría, esto tiene sentido. Sin embargo, la forma en que se eligen las pruebas piloto suele dar lugar a resultados engañosos.

Los responsables de seguridad suelen elegir entre dos tipos de equipos:

1. El equipo de ingeniería con más experiencia
2. El equipo con más ganas de participar

Ambos generan resultados artificialmente positivos. Los equipos de alto rendimiento ya mantienen una sólida «higiene de ingeniería». Sus actualizaciones de dependencias están al día. Sus procesos de CI/CD son modernos. Su arquitectura se mantiene de forma activa. La implementación de herramientas de seguridad en ese contexto genera métricas impresionantes, pero también una peligrosa ilusión de que los despliegues se escalarán sin problemas. La realidad sale a la luz más tarde, cuando el despliegue llega a servicios heredados, equipos con falta de personal o sistemas que no se han actualizado de forma significativa en años.

Un enfoque más adecuado para la selección de pilotos incluye deliberadamente una complejidad representativa:

• Un servicio tradicional
• Un equipo moderno y nativo de la nube
• Un grupo de productos de alta rotación
• Una plataforma interna de movimiento lento

El objetivo de una prueba piloto es detectar los posibles obstáculos en una fase temprana.

El modelo de implementación en cuatro fases que funciona a gran escala

Los programas de seguridad para desarrolladores que tienen éxito suelen seguir un patrón de implementación coherente. Aunque rara vez ocurre de forma intencionada, los CISO con experiencia acaban adoptando el mismo modelo.

Fase 1: Visibilidad sin medidas coercitivas

La primera fase se centra en la observabilidad. Las herramientas de seguridad se ejecutan en los repositorios y la infraestructura, pero no bloquean las compilaciones ni las implementaciones. Los hallazgos se identifican, se clasifican y se analizan. Esta etapa ayuda a los equipos de seguridad a responder a preguntas fundamentales:

• ¿Cuáles son las vulnerabilidades que se dan con más frecuencia?
• ¿Qué equipos responden con rapidez?
• ¿Qué tipos de soluciones generan más resistencia?

Tómatelo como un ejercicio de aprendizaje.

Fase 2: Ciclos de retroalimentación de los desarrolladores

A continuación viene la implicación de los desarrolladores. Los resultados se presentan de forma que los ingenieros puedan actuar en consecuencia. Se eliminan de forma decidida los falsos positivos. La documentación mejora. Se comparten ejemplos de corrección. Esta fase también fomenta la motivación intrínseca. Los desarrolladores rara vez responden bien a las imposiciones impuestas desde arriba. Sin embargo, sí responden a los retos de resolución de problemas. Algunas organizaciones gamifican con éxito el trabajo de corrección, permitiendo que los equipos compitan en función del número de problemas de seguridad resueltos por sprint. Cuando los ingenieros empiezan a corregir problemas de forma voluntaria, sabes que el programa está empezando a funcionar.

{{falsos positivos}}

Fase 3: Medidas de protección y políticas

Solo cuando los desarrolladores confían en el sistema surgen los mecanismos de cumplimiento. Estos suelen adoptar la forma de medidas de protección. Algunos ejemplos son:

• Solución de vulnerabilidades críticas en nuevas dependencias
• Evitar que los secretos entren en los repositorios
• Aplicación de niveles mínimos de parches para las imágenes base

Se sigue haciendo hincapié en prevenir nuevos riesgos, más que en castigar las deficiencias del pasado. Es necesario que el «por qué» acompañe al «qué», para no limitarnos a jugar a una versión avanzada o acelerada del «golpea al topo» con las vulnerabilidades y las configuraciones erróneas.

Fase 4: Responsabilidad de los directivos

La fase final introduce la visibilidad del liderazgo. Las métricas aparecen en los paneles de control de liderazgo de ingeniería:

• Tiempo hasta la corrección
• Categorías de vulnerabilidades recurrentes
• Tendencias en el número de incidencias de seguridad pendientes

En este punto, la seguridad pasa a formar parte de los debates sobre el rendimiento de la ingeniería. Y es entonces cuando el cambio cultural se hace palpable y duradero.

Qué no se debe imponer desde el principio (y por qué)

La forma más rápida de hacer fracasar la implantación de una medida de seguridad es aplicarla antes de tiempo. Entre los errores habituales que se cometen al principio se encuentran:

• El bloqueo se basa en los umbrales de vulnerabilidad
• Establecer plazos obligatorios para la aplicación de parches
• Aplicación de políticas de gravedad globales

Estas medidas parecen decisivas, pero a menudo provocan una reacción contraria. Cuando los ingenieros se encuentran de repente con que sus implementaciones se ven bloqueadas por herramientas que no han solicitado, no tardan en encontrar soluciones alternativas. Desactivan los escáneres y crean ramificaciones en los flujos de trabajo. Ignoran las alertas. El resultado es una seguridad más deficiente y una relación deteriorada entre los equipos de ingeniería y de seguridad. La adopción debe preceder a la imposición. La confianza debe preceder al control.

Los indicadores que reflejan la adopción real

paneles de seguridad centrarse en las cifras equivocadas. El recuento de vulnerabilidades, los análisis realizados o los repositorios analizados aportan visibilidad, pero dicen poco sobre los cambios de comportamiento.

Entre los indicadores más significativos se incluyen:

• Índice de corrección: ¿Están los desarrolladores resolviendo realmente los problemas detectados? Un aumento en el índice de corrección suele indicar un mayor compromiso.
• Tiempo de corrección: ¿Con qué rapidez se resuelven los problemas de alta gravedad? Las organizaciones que cuentan con una sólida cultura de seguridad entre los desarrolladores suelen resolver los problemas críticos en cuestión de días, no de semanas.
• Hallazgos recurrentes: ¿Aparecen las mismas vulnerabilidades una y otra vez? Si es así, el problema no radica en la corrección de fallos, sino en la formación de los desarrolladores o en los patrones arquitectónicos.
• Señales de desinterés: Las primeras y más importantes señales de alerta de un posible fracaso son que los desarrolladores ignoren el sistema, cierren los tickets sin soluciones ni enlaces a las modificaciones del código, las quejas por «fatiga de alertas» y las caídas repentinas en la actividad de corrección.

Cuando la implementación de un programa de seguridad fracasa

Incluso las implementaciones mejor diseñadas pueden encontrar obstáculos. Los responsables de seguridad con experiencia saben detectar las señales de alerta a tiempo:

• Los atrasos crecen más rápido que las soluciones
• Ingenieros que eluden las herramientas de escaneo
• Los defensores de la seguridad pierden influencia

Cuando esto ocurre, la reacción instintiva suele ser endurecer las medidas de control, pero casi siempre es un error. En cambio, los CISO que tienen éxito se detienen a reflexionar y se plantean tres preguntas:

1. ¿Estamos sacando a relucir demasiados temas a la vez?
2. ¿Se proporciona a los desarrolladores una orientación clara sobre las medidas correctivas?
3. ¿Estamos dando prioridad a las vulnerabilidades que realmente importan?

La última pregunta nos lleva a uno de los principios más importantes de los programas de seguridad a gran escala:

Aquí se aplica el principio de Pareto: . En la mayoría de los entornos, aproximadamente el 20 % de las vulnerabilidades representan el 80 % del riesgo real para la organización. Los programas de seguridad que se centran en esos problemas de gran impacto reducen drásticamente el riesgo y, al mismo tiempo, minimizan las dificultades para los desarrolladores. Los programas que intentan solucionarlo todo a la vez se hunden bajo su propio peso.

Incorporar el enfoque de seguridad en el ciclo de vida del desarrollo de software (SDLC)

Un programa de seguridad para desarrolladores a largo plazo acaba trasladándose a las fases iniciales del proceso. En lugar de reaccionar ante los informes de vulnerabilidades, las organizaciones comienzan a prevenirlas ya en las fases de diseño y desarrollo.

Una de las herramientas más eficaces para esta transformación es la modelización de amenazas. Muchos desarrolladores solo se plantean la seguridad cuando un escáner detecta un problema. Aprenden la norma, pero no el razonamiento que hay detrás. La modelización de amenazas cambia esa dinámica.

Ayuda a los desarrolladores a comprender:

• Por qué son importantes las decisiones sobre el almacenamiento de sesión
• Cómo los patrones de autenticación crean superficies de ataque
• ¿Por qué? Top 10 OWASP aparecen repetidamente

Cuando los ingenieros comprenden el «porqué», dejan de ver las correcciones de seguridad como exigencias externas y comienzan a diseñar sistemas que evitan esos problemas por completo. La colaboración entre desarrolladores noveles e ingenieros experimentados acelera aún más este aprendizaje. Los desarrolladores sénior transmiten de forma natural hábitos como la disciplina en la documentación, las pruebas automatizadas y la configuración segura de la infraestructura. La seguridad deja de centrarse en el análisis del código para centrarse más en la forma de pensar de los ingenieros al escribirlo.

La única regla que determina el éxito a gran escala

Tras observar cómo decenas de programas de seguridad para desarrolladores han tenido éxito o han fracasado, hay un principio que determina sistemáticamente el resultado: la seguridad debe reducir la carga cognitiva de los desarrolladores, no aumentarla.

Si las herramientas generan un ruido abrumador, los ingenieros dejan de utilizarlas. Si las instrucciones para la corrección no están claras, los ingenieros posponen las soluciones. Si se impone el cumplimiento antes de ganarse la confianza, los ingenieros eluden los controles. Pero cuando las herramientas de seguridad:

• resultados procesables
• dar prioridad a los riesgos significativos
• integrarse en los flujos de trabajo existentes

Los desarrolladores reaccionan como siempre y resuelven el problema.

Y cuando un número suficiente de personas empieza a resolverlo, ocurre algo extraordinario. La seguridad se convierte en un hábito.

Y en una organización con 5.000 colaboradores, son los hábitos los que, en última instancia, determinan el nivel de seguridad de toda la empresa.

Estas lecciones influyeron enormemente en la filosofía de diseño que subyace a las plataformas modernas de seguridad para desarrolladores, como Aikido. Un sistema creado para detectar riesgos significativos y, al mismo tiempo, minimizar la carga cognitiva de los desarrolladores.

{{walkthrough}}