Skip to main content

Seguridad vs. desarrollo: un juego de prioridades

Escrito por
Headshot of Andrew MacKenzie

Andrew MacKenzie

blog feature pypi spoof

6 de noviembre de 2023

0 minutos de lectura

En el dinámico ecosistema tecnológico actual, es fundamental gestionar programas de seguridad de aplicaciones (AppSec) a escala. A medida que las bases de código se expanden y las amenazas se vuelven más sofisticadas, el enfoque pasa de abordar vulnerabilidades aisladas a crear posturas de seguridad cohesivas en todos los equipos de desarrollo. Los enfoques emergentes, como la gestión de la postura de seguridad de las aplicaciones (ASPM), permiten a las organizaciones ir más allá de las vulnerabilidades individuales y coordinar programas integrales que se centran en gestionar los riesgos críticos para el negocio. Estas herramientas agilizan el proceso al automatizar los controles de seguridad, mejorar el análisis de riesgos y priorizar las vulnerabilidades.

Cabe señalar que, aunque para algunas personas ASPM pueda parecer un enfoque nuevo, en Snyk llevamos 8 años avanzando en esta dirección. Desde el primer día, Snyk ha sido pionero en herramientas de AppSec que priorizan a los desarrolladores. Nuestro objetivo siempre ha sido llevar los programas de AppSec más allá de simplemente «desplazar la seguridad a la izquierda» con herramientas tradicionales de AppSec, y mostrar a los equipos que, para que AppSec sea realmente eficaz, las empresas deben dar más responsabilidad por la seguridad a los desarrolladores. Para ello se necesitaba una categoría totalmente diferente de herramientas de seguridad diseñadas para desarrolladores.

Aunque se transfieran responsabilidades de seguridad a los desarrolladores, el equipo de seguridad sigue siendo responsable de la postura de riesgo de las aplicaciones de la empresa. Integrar las herramientas con las que usan los desarrolladores es solo una parte del trabajo que hacemos en Snyk. Una parte aún más importante consiste en ayudar a los equipos de seguridad y desarrollo a colaborar para adoptar un enfoque de seguridad más preventivo. Por supuesto, esto implica usar las herramientas de Snyk, pero también ofrecer capacitación y programas de promotores de seguridad; definir y medir métricas de éxito de AppSec; y ampliar los logros del primer equipo de aplicaciones a todas las aplicaciones y equipos. Durante estos años al servicio de nuestros clientes, ASPM es un testimonio de nuestro compromiso y de cómo hemos convertido nuestra experiencia acumulada en un producto, que establece un referente en seguridad de aplicaciones.

¿Qué es ASPM?

La gestión de la postura de seguridad de las aplicaciones (ASPM) es un enfoque de seguridad de aplicaciones que aprovecha una visión integral del entorno de las aplicaciones, la automatización y medidas de seguridad completas para implementar, medir y mejorar los programas de seguridad de aplicaciones.

ASPM reúne, correlaciona y evalúa señales de seguridad a lo largo del ciclo de vida del desarrollo, la implementación y la operación del software. Su objetivo es mejorar la visibilidad, gestionar las vulnerabilidades y controlar el cumplimiento para aumentar la eficacia de la seguridad de las aplicaciones y la gestión de riesgos.

Para aprovechar todo el potencial de estas herramientas, es fundamental lograr una alineación estratégica entre las áreas de Desarrollo y Seguridad. Esta alineación suele ser un desafío, ya que, a veces, los equipos de seguridad y desarrollo parecen trabajar en ámbitos distintos. Ante los beneficios que ofrece ASPM, es aún más importante comprender qué motiva específicamente a cada equipo.

Comprender qué motiva a cada equipo es clave para lograr que los desarrolladores adopten ampliamente herramientas de seguridad como Snyk.

Necesidades de los equipos

Diagrama que compara las prioridades de seguridad con las de los desarrolladores alrededor de un cerebro dividido entre Seguridad y Desarrollo: fundamentos, cumplimiento, velocidad, código limpio y más.

Puntos de fricción

  • Enfoque: Parches de seguridad urgentes frente a nuevas funciones prioritarias.

  • Ritmo: La cautela de Seguridad frente a los sprints de Desarrollo.

  • Adopción de herramientas: El entusiasmo de los desarrolladores por las herramientas nuevas podría hacer que se salten la fila de evaluación de seguridad.

  • Comunicación: A veces, cada equipo habla un idioma distinto: lo que para uno es documentación, para otro puede ser incomprensible.

  • Capacitación: Para un desarrollador, la capacitación en seguridad podría parecer un desvío.

Análisis: detectar la falta de alineación

Para resolver posibles problemas de adopción de herramientas de seguridad por parte de los desarrolladores, primero hay que diagnosticar cualquier falta de alineación existente:

Preguntas que pueden hacerse los líderes de seguridad

  • Estrategia: ¿Cómo incluimos a los desarrolladores en nuestra visión de seguridad?

  • Herramientas: ¿Cómo apoyamos a los desarrolladores para que integren la seguridad?

  • Aprendizaje: ¿Cuál es nuestro plan de capacitación en seguridad para los desarrolladores?

  • Ciclo de retroalimentación: ¿Cómo es la comunicación entre los equipos de desarrollo y seguridad?

Preguntas que pueden hacerse los líderes de ingeniería

  • Perspectiva de los desarrolladores: ¿Cómo perciben los desarrolladores su papel en la seguridad?

  • Desafíos: ¿Qué obstáculos enfrentan al usar herramientas de seguridad para desarrolladores?

  • Relación entre seguridad y desarrollo: ¿Cómo definirías la relación actual entre Seguridad y Desarrollo?

  • Aprender de los errores: Después de los incidentes de seguridad, ¿cómo se incorporan las lecciones aprendidas?

  • Asignación a los sprints: ¿Qué porcentaje de nuestros sprints dedicamos a la seguridad?

Crear sinergia: impulsar la adopción de herramientas de seguridad por parte de los desarrolladores

Una vez que hayas identificado la desconexión, es momento de construir un puente:

  • Líder de seguridad: Mantén a los desarrolladores al tanto de las novedades de seguridad y recibe sus comentarios con apertura.  

    • Prioriza las actualizaciones esenciales: Aunque la comunicación regular es fundamental, también es importante distinguir entre las notificaciones de seguridad críticas y las alertas de menor importancia para evitar abrumar a los desarrolladores.

    • Reúnete con regularidad: Organiza reuniones mensuales o trimestrales con los desarrolladores para compartir información sobre seguridad y analizar tendencias, en lugar de incidentes aislados.

  • Líder de ingeniería: Promueve la participación abierta de los desarrolladores en estas conversaciones. Designa a una persona de enlace que pueda trabajar directamente con el proveedor de herramientas de seguridad.

Integración fluida

  • Líder de seguridad: Incorporar verificaciones de seguridad en el SCM o en CI/CD es un primer paso. Asegúrate de que los datos de seguridad sean visibles y permitan tomar medidas. Al principio, no bloquees las verificaciones de seguridad de las solicitudes de cambios ni las compilaciones; fomenta la confianza de los desarrolladores mediante la capacitación, no la imposición.

  • Líder de ingeniería: Asegúrate de que los desarrolladores sepan usar las herramientas de seguridad. Coordina las alertas de vulnerabilidades, su clasificación y los planes de políticas.

Aprendizaje continuo

  • Líder de seguridad: Aprovecha las herramientas de seguridad para desarrolladores en talleres de seguridad específicos.

  • Líder de ingeniería: Anima a los desarrolladores a asistir cuando los temas de los talleres sean directamente relevantes para su trabajo.  Comparte comentarios periódicamente con el equipo de Seguridad sobre las sesiones para que sigan siendo interesantes y pertinentes para los desarrolladores.

Métricas unificadas

  • Líder de seguridad:  Pon en marcha indicadores clave de rendimiento (KPI) de vulnerabilidades. Compártelos, celebra los logros y recibe con apertura los comentarios de los desarrolladores.

  • Líder de ingeniería: Destina parte del presupuesto para deuda técnica a la seguridad, asignando un porcentaje de los sprints a corregir problemas existentes. Incorpora objetivos de seguridad en la planificación de los sprints, especialmente al lanzar nuevas funciones.  Anima a los desarrolladores a compartir comentarios continuos sobre las alertas de seguridad y a distinguir los problemas críticos del ruido de fondo.

Prioriza para mantener la seguridad

En conclusión, para optimizar los programas de AppSec a escala, debemos dejar de centrarnos exclusivamente en abordar vulnerabilidades individuales y establecer estrategias de seguridad integradas en todas las iniciativas de desarrollo. Comprender las motivaciones particulares de los desarrolladores y los equipos de seguridad es fundamental para lograrlo.

Plataformas como Snyk pueden impulsar la colaboración entre los equipos de seguridad y desarrollo al brindar mayor visibilidad, controles de seguridad, análisis de riesgos detallados y priorización estratégica. Este enfoque colectivo representa el futuro: la seguridad no solo identifica amenazas, sino que también colabora con los desarrolladores para diseñar defensas proactivas y garantizar un ecosistema tecnológico unificado, ágil y seguro.

Acelera el desarrollo seguro

Snyk reúne a desarrolladores y equipos de seguridad para garantizar velocidad y seguridad a escala.

Leer más

blog feature snyk container custom base recommendations
Blog

Presentamos Evo Agentic AppSec: seguridad al ritmo del desarrollo con IA

El desarrollo impulsado por IA supera el ritmo de los flujos de trabajo de seguridad tradicionales. Agentic AppSec de Snyk usa agentes de seguridad para encontrar, corregir y verificar vulnerabilidades de forma continua, mientras las personas definen el estándar.

blog feature ai violet
Blog

VulnBump: ¿Pueden los agentes de IA corregir dependencias vulnerables sin romper la compilación?

VulnBump prueba agentes de IA en 307 actualizaciones reales de dependencias. Una corrección cuenta solo si elimina la vulnerabilidad y mantiene en verde la compilación y las pruebas.

Blog

Los modelos de frontera encontraron las vulnerabilidades. Solo el atacante encontró las cadenas.

El análisis estático encontró las fallas, pero solo las pruebas de ataque en vivo demostraron cómo podían encadenarse para provocar brechas. Una comparación de Evo COS, Claude Security y Claude Code Security.