Todos los equipos están de acuerdo en que el desarrollo seguro es importante. ¿Pero cuando se trata de la propiedad? De repente todo el mundo mira a otro. Los desarrolladores piensan que es trabajo de Seguridad. Los equipos de seguridad esperan que los desarrolladores escriban código más seguro. DevOps sólo quiere mantener vivo el pipeline. ¿Y los directores? Quieren seguridad sin ralentizar los envíos.

La verdad es que el desarrollo de software seguro no es tarea de una sola persona, sino de todos. Eso significa definir claramente las funciones, las responsabilidades y, lo que es más importante, las expectativas. Si no se hace bien esta parte, todo el esfuerzo de SSDLC se convierte en un juego de culpas a cámara lenta. Analicemos quién está en el ruedo, qué les quita el sueño y qué buscan realmente a las 2 de la madrugada.

Imagen de marcador de posición: Descripción de la imagen: Diagrama de roles del equipo de desarrollo multifuncional con flechas que asignan responsabilidades para la codificación segura, pruebas, herramientas y entrega.

La alineación: Quién es quién en el ámbito del desarrollo seguro

Desarrolladores: En las trincheras, depurando código, esquivando CVEs

Los desarrolladores son los que más cerca están del código y, a menudo, los primeros a los que se culpa cuando algo se rompe. Se espera de ellos que escriban código seguro, aunque nunca se les haya enseñado a hacerlo. Se enfrentan a la fatiga de las alertas provocada por herramientas ruidosas y consejos contradictorios. Lo que necesitan son directrices de seguridad integradas en su flujo de trabajo, no añadidas a posteriori.

Ingenieros DevOps: Maestros de la tubería, herramientas de malabares y configuraciones de nube

DevOps mantiene el proceso en marcha y los despliegues fluyen. Gestionan los secretos, la infraestructura como código, la configuración de contenedores y la integración CI/CD. A menudo se espera de ellos que "simplemente hagan que la seguridad funcione" en toda la pila, sin romper la compilación. Lo que necesitan: seguridad que encaje en la automatización existente, no más pasos manuales.

Ingenieros de seguridad (AppSec/Seguridad de productos): Los guías, guardianes y, a veces, cuellos de botella

Los equipos de seguridad escriben políticas, eligen herramientas e intentan ampliar su influencia a docenas (o cientos) de desarrolladores. Pero a menudo se ven superados en número 100 a 1. Necesitan herramientas que reduzcan el ruido, destaquen lo que realmente importa y ayuden a los desarrolladores a solucionar los problemas sin tener que ir y venir de un ticket a otro.

Directores técnicos: pastoreo de gatos, equilibrio entre funciones y cordura

Los directivos caminan por la cuerda floja entre la velocidad y el riesgo. Se les mide por las funciones enviadas, pero también por el tiempo de inactividad, los incidentes y el cumplimiento. No son expertos en seguridad, pero se espera de ellos que tomen decisiones que eviten problemas a la empresa. Necesitan visibilidad, métricas y la implicación de todos los equipos.

Qué les quita el sueño

Para desarrolladores: "Seguridad frente a velocidad", el infierno de las herramientas (tantas alertas) y el síndrome de "no es mi trabajo".

Los desarrolladores temen las herramientas que bloquean los despliegues y los inundan con problemas de baja prioridad. Quieren información rápida y práctica, preferiblemente en su IDE o PR. Odian cualquier cosa que les haga sentir como culpables sin apoyo.

Para DevOps: cuellos de botella en las canalizaciones, pesadillas de configuración, mantener secretos en secreto

DevOps quiere menos pasos manuales y menos sorpresas. Se preocupan por la transmisión accidental de datos confidenciales o por abrir un bucket de S3 al mundo. Necesitan políticas y herramientas claras que no descarrilen la automatización.

Para los responsables de seguridad: Demasiado ruido, pocos recursos, siempre al día

Los equipos de seguridad se ven abrumados por las alertas, los falsos positivos y la proliferación de herramientas. Están cansados de ser reactivos. Lo que necesitan es contexto, priorización y formas de anticiparse a los riesgos sin tener que vigilar cada despliegue.

Para directivos: Justificar costes, gestionar riesgos, encontrar personas que entiendan de esto

Los directivos se preocupan por el retorno de la inversión. ¿Merece la pena esta herramienta de seguridad? ¿La utiliza siquiera el equipo? También están atascados intentando contratar ingenieros "unicornio" que entiendan tanto de código como de seguridad. Quieren ventajas prácticas, no otro cuadro de mandos que gestionar.

Lo que realmente buscan en Google (y a lo que responderá este Hub)

Consultas de desarrollo

• "codificación segura [mi idioma]"
• "cómo detener la inyección SQL rápidamente"
• "OWASP Top 10 explicado para humanos"

Los desarrolladores quieren respuestas claras y prácticas. No buscan PDF de 80 páginas, sino soluciones fáciles de copiar y consejos de codificación segura específicos para cada lenguaje.

Consultas DevOps

• "Automatizar la seguridad en CI/CD sin romperlo todo" 
• "Herramientas de análisis de seguridad Terraform" 
• "Las mejores prácticas de seguridad de Docker que no son de 2015"

DevOps busca formas de integrar la seguridad en las herramientas que ya utiliza, sin interrumpir los despliegues ni ralentizar las compilaciones.

Consultas de seguridad:

• "Guía de implantación de SSDLC para agile"
• "modelado de amenazas que los desarrolladores no odiarán"
• "Comparación de herramientas SAST"

Los ingenieros de seguridad quieren escalar. Buscan herramientas y guías que se integren con la metodología ágil y que les ayuden a cambiar a la izquierda sin tener que estar constantemente cuidando de ellos.

Consultas de los gestores: 

• "Coste de la violación de datos frente a inversión en seguridad"
• "Formación en seguridad para desarrolladores ROI"
• "cómo construir una cultura de seguridad que no implique caídas de confianza"

Los directivos buscan cifras concretas, inversiones justificables y formas sencillas de impulsar el desarrollo seguro, sin que ello afecte a la velocidad o la moral del equipo.

Todo el mundo quiere un software seguro. Nadie quiere más trabajo. La clave está en comprender los puntos débiles de cada función y proporcionarles herramientas y procesos que funcionen con su flujo, no contra él. 

Es hora de desentrañar qué motiva realmente a los equipos a adoptar prácticas seguras y qué suele interponerse en el camino.