1. La seguridad para más tarde

En la mayoría de las organizaciones, la cantidad de desarrolladores supera con creces la de los especialistas en seguridad. Postergar la seguridad hasta etapas avanzadas del desarrollo puede resultar ineficaz o problemático debido a la naturaleza veloz y abundante de los releases del software. Este enfoque no es adecuado para abordar todas las aplicaciones y evita que se descubran vulnerabilidades hasta que ya es demasiado tarde, lo que resulta en la implementación de código vulnerable en la etapa de producción.

Solución: mover la seguridad hacia la izquierda y escalar los esfuerzos de seguridad para cubrir todas las aplicaciones, comenzando desde las primeras etapas del desarrollo.

2. Silos y fricción entre desarrollo y seguridad (Dev-Sec).

Tradicionalmente, la comunicación entre desarrolladores y equipos de seguridad tiende a basarse en problemas o incidentes. Pero la comunicación masiva únicamente por correo electrónico, informes en PDF o incidencias en GitHub genera fricciones y resulta frustrante para todos. Para los desarrolladores, los problemas planteados por seguridad pueden no ser relevantes para el desarrollo diario o pueden incluir comentarios para un proyecto que ya debería haber sido finalizado. Abordar estos problemas solo agrega estrés al tener que reorganizar las tareas y los esfuerzos de la iteración, convirtiendo la seguridad en un obstáculo para la innovación. Para los equipos de seguridad, resulta frustrante no participar en la arquitectura, el diseño y las primeras etapas de desarrollo. También puede resultar difícil explicarles a los desarrolladores los riesgos de seguridad de las aplicaciones y de organización, ya que no tienen experiencia en seguridad. Al final, una comunicación deficiente conduce a una menor colaboración y empatía en general.

Solución: convierte la seguridad en parte del desarrollo mediante la integración de herramientas en el flujo de trabajo del desarrollador. Promueve los debates y la colaboración asíncrona entre ambos equipos.

3. Abordar la seguridad como una tarea diaria

Así como la importancia de la seguridad varía de una organización a la otra, las prácticas reales de seguridad también varían, incluso dentro de una misma organización. La diferencia entre las políticas de seguridad formales y su puesta en práctica puede resultar confusa y complicar aún más la priorización de los problemas de seguridad.

También hay que tener en cuenta que la seguridad de las aplicaciones es solo una pequeña parte de los esfuerzos generales de ciberseguridad de una organización, y tiende a estar aislada del desarrollo y de CI/CD. Esto conlleva a malos hábitos como:

Valorar más la cantidad que la calidad. Concentrarse en un número elevado de resultados de análisis de seguridad o vulnerabilidades de baja calidad no resuelve problemas mayores y sólo aumenta el trabajo de los desarrolladores. Hacer de la seguridad un problema de desarrollo. Introducir los resultados brutos de los análisis de seguridad en los rastreadores de incidencias y dar por sentado que los desarrolladores los corregirán desensibiliza a los desarrolladores ante las incidencias relacionadas con la seguridad. No medir el valor. Al igual que cualquier otra iniciativa, el valor y la rentabilidad de la inversión en seguridad de las aplicaciones deben medirse y evaluarse continuamente. De lo contrario, la falta de datos puede frenar a tu organización y no mostrar evidencia de que se están realizando mejoras en seguridad.

Solución: para una solución inmediata, concéntrate en destacar un número limitado de problemas de seguridad reales, luego priorízalos y preséntalos a los desarrolladores en lugar de compartir una avalancha de falsos positivos. A mayor escala, busca herramientas de seguridad que puedan “codificar” nuevos problemas de seguridad y evitar que se fusionen en una branch de producción. Recuerda: las herramientas de seguridad deben mejorar realmente el código, así que sigue midiendo el valor y el impacto de tu programa de seguridad de las aplicaciones en el tiempo.