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

Las grandes organizaciones de ingeniería suelen creer que sus mayores problemas son técnicos. Si alguien aprobara el presupuesto para la última herramienta, todo estaría resuelto. Últimamente, la apuesta predominante es que la solución mágica es el 'vibe coding' impulsado por su LLM favorito. Pero las patologías de las grandes organizaciones rara vez son de naturaleza técnica. 

Según mi experiencia, son problemas orientados a procesos y pueden manifestarse en dos extremos diferentes del espectro. Por un lado, hay equipos atrapados en la parálisis por análisis, que se mueven en un ciclo interminable de reuniones, revisiones y diseños basados en el consenso, con pocos resultados. Por otro lado, están aquellos que 'actúan antes de pensar', con un sesgo hacia la ejecución que provoca muchas heridas autoinfligidas debido a la falta de introspección.

Cuando una organización supera los 5.000 'committers' 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 alineación.

La realidad es que, cuando una empresa alcanza este tamaño, ya cuenta con una postura de seguridad funcional, una tolerancia al riesgo definida y una organización de seguridad estructurada aproximadamente según ratios de personal conocidos. Un patrón común es un profesional de seguridad por cada 100 ingenieros, lo que significa que una empresa con 5.000 desarrolladores probablemente tenga un equipo de seguridad de 50 personas intentando influir en miles de decisiones de software al día. La cuestión no es si la seguridad existe, sino si es escalable.

Este artículo describe las lecciones aprendidas al implementar programas de seguridad para desarrolladores en organizaciones de esta escala y por qué el camino hacia el éxito difiere mucho de lo que la mayoría de los CISOs esperan.

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

La mayoría de las implementaciones de seguridad fallan por una razón sorprendentemente simple: están diseñadas como despliegues de software en lugar de cambios culturales. Los líderes de seguridad a menudo parten de la suposición de que la combinación adecuada de herramientas (por ejemplo, SAST, SCA, escaneo de contenedores, detección de secretos) producirá mejores resultados si se implementa de forma suficientemente amplia. Pero la adopción de herramientas es la parte fácil.

La parte difícil es la priorización dentro de las organizaciones de ingeniería. Los desarrolladores ya tienen más trabajo del que pueden completar en un sprint. Los plazos de los productos dominan la priorización del backlog. La velocidad de las características es visible y recompensada. Las correcciones de seguridad a menudo parecen abstractas e impuestas externamente. Cuando un programa de seguridad aterriza en ese entorno, la respuesta predeterminada es predecible: se crean tickets de seguridad, entran en el backlog y se acumulan silenciosamente.

Nada de la cobertura de escaneo cambia esta realidad. De hecho, cuantos más hallazgos se detecten sin una propiedad clara, peor se vuelve la situación. Los equipos de seguridad a menudo creen que están reduciendo el riesgo al aumentar la visibilidad, pero en la práctica a veces están amplificando el riesgo no gestionado. Porque todo el mundo sabe que los problemas existen, pero nadie se hace realmente responsable de ellos.

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

Las grandes organizaciones de ingeniería operan bajo un conjunto de limitaciones estructurales que las empresas más pequeñas rara vez encuentran. En primer lugar, existe la fragmentación del SDLC. Una empresa con miles de ingenieros casi con toda seguridad ejecuta múltiples ciclos de vida de desarrollo simultáneamente. Algunos equipos despliegan a diario. Otros lo hacen trimestralmente. Algunos dependen de sistemas heredados construidos hace una década que todo el mundo teme tocar por miedo a que dejen de funcionar por completo y se conviertan en su problema personal. En segundo lugar, existe la heterogeneidad tecnológica. Un entorno empresarial típico puede incluir docenas de lenguajes de programación, múltiples sistemas CI/CD, varias plataformas de infraestructura y una mezcla de flujos de trabajo nativos de la nube y heredados.

Las herramientas de seguridad que funcionan elegantemente en un entorno pueden ser casi imposibles de desplegar en otro. En tercer lugar, existe un poder de aplicación central limitado y ningún sistema único que capture el alcance completo de la superficie de ataque de aplicaciones y la superficie de ataque en la nube de una organización. 

Incluso si el CISO reporta técnicamente al CIO o CTO, los equipos de seguridad rara vez controlan las prioridades del backlog de los grupos de ingeniería de producto. Los influyen, pero no los poseen. Esto crea una tensión fundamental.

Y los problemas de seguridad más peligrosos suelen ser los que requieren cambios arquitectónicos, 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 un sprint de dos semanas.

Las tareas estimadas por encima de aproximadamente 13 'story points' a menudo se posponen indefinidamente. Son proyectos disfrazados de tickets. El resultado es un backlog creciente de trabajo de seguridad que todo el mundo entiende intelectualmente, pero nadie se siente capacitado o incentivado para priorizar.

El primer objetivo es la propiedad, no la cobertura

Uno de los errores más comunes que cometen los líderes de seguridad es asumir que la cobertura de herramientas equivale a progreso. Ejecutar escáneres en cada repositorio puede generar paneles impresionantes, pero sin propiedad, esos paneles se convierten en poco más que catálogos de riesgos. El progreso real comienza con una pregunta diferente:

¿Quién es responsable de arreglar qué?

Los programas de seguridad escalables comienzan identificando a los 'influencers' dentro de la organización de ingeniería. No los gerentes formales. No los arquitectos del organigrama. Sino los desarrolladores cuyas opiniones realmente moldean el comportamiento de ingeniería. Toda gran organización de ingeniería los tiene. Son los ingenieros y desarrolladores que transmiten la cultura y a quienes otros consultan antes de tomar decisiones arquitectónicas. Un enfoque sorprendentemente efectivo es un modelo de formación de formadores:

1. Identificar a 10 desarrolladores maestros respetados en toda la organización
2. Formarlos en profundidad en prácticas de desarrollo seguro
3. Hacer que formen a 100 'engineering champions'
4. Esos 'champions' influyen en sus propios equipos de 50 desarrolladores cada uno

En pocas semanas, las prácticas de seguridad se propagan entre miles de ingenieros sin que el equipo de seguridad tenga que formar directamente a todo el mundo. A escala, la influencia se extiende a través de la credibilidad entre pares.

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

La mayoría de los programas de seguridad empresarial comienzan con un piloto. Esto es sensato en teoría, pero la forma en que se eligen los pilotos a menudo garantiza resultados engañosos.

Los líderes de seguridad suelen seleccionar uno de dos tipos de equipos:

1. El equipo de ingeniería más maduro
2. El equipo más dispuesto a participar

Ambos producen 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 pipelines de CI/CD son modernos. Su arquitectura se mantiene activamente. Desplegar herramientas de seguridad allí produce métricas impresionantes, pero también una peligrosa ilusión de que los despliegues se escalarán sin problemas. La realidad aparece más tarde, cuando el despliegue llega a servicios heredados, equipos con poco personal o sistemas que no se han actualizado significativamente en años.

Un mejor enfoque para la selección de pilotos incluye intencionadamente una complejidad representativa:

• Un servicio heredado
• Un equipo moderno nativo de la nube
• Un grupo de producto de alta velocidad
• Una plataforma interna de movimiento lento

El objetivo de un piloto es descubrir la fricción a tiempo.

El modelo de despliegue en cuatro fases que funciona a escala

Los programas de seguridad para desarrolladores exitosos suelen seguir un patrón de despliegue consistente. Raramente ocurre intencionadamente, pero los CISO experimentados acaban convergiendo en el mismo modelo.

Fase 1: Visibilidad sin aplicación

La primera fase se centra en la observabilidad. Las herramientas de seguridad se ejecutan en repositorios e infraestructura, pero no bloquean las compilaciones ni los despliegues. Los hallazgos se exponen, categorizan y analizan. Esta etapa ayuda a los equipos de seguridad a responder preguntas críticas:

• ¿Qué vulnerabilidades aparecen con mayor frecuencia?
• ¿Qué equipos responden rápidamente?
• ¿Qué tipos de correcciones generan más fricción?

Trátelo como un ejercicio de aprendizaje.

Fase 2: Bucles de retroalimentación del desarrollador

A continuación, llega el compromiso del desarrollador. Los hallazgos se presentan de formas en que los ingenieros pueden actuar realmente. Los falsos positivos se eliminan agresivamente. La documentación mejora. Se comparten ejemplos de remediación. Esta fase también introduce la motivación intrínseca. Los desarrolladores rara vez responden bien a la imposición descendente, pero sí responden a los desafíos de resolución de problemas. Algunas organizaciones gamifican con éxito el trabajo de remediación, permitiendo a los equipos competir en función del número de problemas de seguridad resueltos por sprint. Cuando los ingenieros empiezan a solucionar problemas voluntariamente, sabes que el programa está empezando a funcionar.

{{falsos-positivos}}

Fase 3: Guardrails y Política

Solo después de que los desarrolladores confían en el sistema aparecen los mecanismos de aplicación. Estos suelen adoptar la forma de guardrails. Los ejemplos incluyen:

• Bloqueo de vulnerabilidades críticas en nuevas dependencias
• Prevención de que los secretos entren en los repositorios
• Aplicación de niveles mínimos de parcheo para imágenes base

El énfasis sigue estando en prevenir nuevos riesgos, en lugar de penalizar la deuda histórica. El «porqué» debe estar presente junto con el «qué» para que no estemos simplemente jugando a una versión avanzada o acelerada del 'whack-a-mole' con vulnerabilidades y configuraciones erróneas.

Fase 4: Responsabilidad ejecutiva

La fase final introduce visibilidad para la dirección. Las métricas aparecen en los paneles de control de la dirección de ingeniería:

• Tiempo de remediación
• Categorías de vulnerabilidades recurrentes
• Tendencias del backlog de seguridad

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

Qué no aplicar al principio (y por qué)

La forma más rápida de descarrilar una implementación de seguridad es la aplicación prematura. Los errores comunes al principio incluyen:

• Bloquear compilaciones por umbrales de vulnerabilidad
• Establecer plazos universales para parches
• Aplicar políticas de gravedad globales

Estas acciones parecen decisivas, pero a menudo generan una reacción negativa. Cuando los ingenieros ven de repente sus despliegues bloqueados por herramientas que no solicitaron, rápidamente descubren soluciones alternativas. Deshabilitan escáneres y bifurcan pipelines. Ignoran las alertas. El resultado es una seguridad peor y una relación dañada entre los equipos de ingeniería y seguridad. La adopción debe preceder a la aplicación. La confianza debe preceder al control.

Las métricas que indican una adopción real

Los paneles de seguridad a menudo se centran en las cifras equivocadas. El recuento de vulnerabilidades, los escaneos completados o los repositorios analizados proporcionan visibilidad, pero dicen poco sobre el cambio de comportamiento.

Indicadores más significativos incluyen:

• Tasa de resolución: ¿Están los desarrolladores resolviendo realmente los hallazgos? Una tasa de remediación creciente suele indicar un compromiso cada vez mayor.
• Tiempo de remediación: ¿Con qué rapidez se solucionan los problemas de alta gravedad? Las organizaciones con culturas de seguridad de desarrolladores saludables a menudo ven las correcciones críticas resueltas en días, no en semanas.
• Hallazgos recurrentes: ¿Aparecen las mismas vulnerabilidades repetidamente? Si es así, el problema no es la remediación. Es la educación de los desarrolladores o los patrones arquitectónicos.
• Señales de desvinculación: El signo de advertencia más temprano e importante de un fallo es que los desarrolladores ignoren el sistema, cerrando tickets sin correcciones o enlaces a commits de código, las quejas de fatiga por alertas y las caídas repentinas en la actividad de remediación.

Cuando una implementación de programa de seguridad está fallando

Incluso las implementaciones bien diseñadas encuentran turbulencias. Los líderes de seguridad experimentados reconocen las señales de advertencia a tiempo:

• Los backlogs crecen más rápido que las correcciones
• Ingenieros eludiendo las herramientas de escaneo
• Los campeones de seguridad pierden influencia

Cuando esto ocurre, el instinto suele ser endurecer la aplicación de las normas, pero casi siempre es la decisión equivocada. En su lugar, los CISOs exitosos hacen una pausa y se hacen tres preguntas:

1. ¿Estamos revelando demasiadas incidencias a la vez?
2. ¿Se proporciona a los desarrolladores una guía de remediación clara?
3. ¿Estamos priorizando las vulnerabilidades que realmente importan?

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

El Principio de Pareto se aplica aquí: en la mayoría de los entornos, aproximadamente el 20% de las vulnerabilidades representan el 80% del riesgo organizacional real. Los programas de seguridad que se centran en estas incidencias de alto impacto reducen drásticamente el riesgo a la vez que minimizan la fricción para los desarrolladores. Los programas que intentan solucionarlo todo simultáneamente colapsan bajo su propio peso.

Integrar la mentalidad de seguridad en el SDLC

Un programa de seguridad para desarrolladores a largo plazo finalmente se desplaza hacia las fases iniciales. En lugar de reaccionar a los informes de vulnerabilidades, las organizaciones empiezan a prevenirlas durante el diseño y el desarrollo.

Una de las herramientas más eficaces para esta transformación es el modelado de amenazas. Muchos desarrolladores se encuentran con la seguridad solo cuando un escáner señala una incidencia. Aprenden la regla, pero no el razonamiento. El modelado de amenazas cambia esa dinámica.

Ayuda a los desarrolladores a entender:

• Por qué importan las decisiones de almacenamiento de sesiones
• Cómo los patrones de autenticación crean superficies de ataque
• Por qué las incidencias del Top 10 OWASP aparecen repetidamente

Cuando los ingenieros entienden el «porqué», dejan de ver las correcciones de seguridad como exigencias externas y empiezan a diseñar sistemas que evitan esos problemas por completo. Emparejar a desarrolladores junior con 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 se convierte en algo menos relacionado con el escaneo de código y más con la forma en que los ingenieros piensan mientras lo escriben.

La única regla que determina el éxito a escala

Después de observar cómo docenas de programas de seguridad para desarrolladores tienen éxito o fracasan, un principio 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 se desvinculan. Si la guía de remediación no es clara, los ingenieros posponen las correcciones. Si la aplicación de las normas llega antes que la confianza, los ingenieros eluden los controles. Pero cuando las herramientas de seguridad:

• revelan hallazgos accionables
• priorizan el riesgo significativo
• se integran en los flujos de trabajo existentes

los desarrolladores responden como siempre lo hacen y resuelven el problema.

Y cuando suficientes de ellos empiezan a resolverlo, ocurre algo extraordinario. La seguridad se convierte en un hábito.

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

Estas lecciones influyeron en gran medida en la filosofía de diseño de las plataformas modernas de seguridad para desarrolladores como Aikido. Un sistema diseñado para identificar riesgos significativos mientras minimiza la carga cognitiva de los desarrolladores.

{{walkthrough}}