Tres mejores prácticas de seguridad para todos los equipos 'DevSecOps'

Han pasado más de 10 años desde que Shannon Lietz introdujo el término DevSecOps, con el objetivo de conseguir que la seguridad se sentara a la mesa con los desarrolladores y operadores de TI. La pregunta es: ¿cuánto ha avanzado la seguridad desde entonces? ¿Disponen los equipos de DevSecOps de la cultura, las prácticas y las herramientas que necesitan para lanzar la tecnología a producción más rápidamente, pero también de forma fiable y segura?

La encuesta SANS DevSecOps Survey, publicada recientemente, muestra un avance significativo. Cada vez son más las organizaciones que recurren a la seguridad por turnos para garantizar que la seguridad ocupa un lugar destacado en sus prácticas de desarrollo. Más del 50% de los encuestados afirmaron que resolvían los riesgos y vulnerabilidades de seguridad críticos en siete días o menos. Pero aunque casi el 30% de los encuestados afirmaron que realizaban despliegues de producción semanales, sólo el 20% evaluaba o comprobaba las vulnerabilidades de seguridad a una velocidad similar. Además, la tasa de adopción de prácticas DevSecOps alcanzó un máximo del 61% para la automatización y del 50% para la integración continua (CI). Muchas organizaciones todavía están trabajando para conseguir una seguridad madura y un despliegue continuo.

Mejores prácticas

Los líderes tecnológicos y los equipos de DevSecOps luchan por determinar qué prácticas de seguridad tienen que priorizar y madurar. La encuesta de SANS enumera más de 25 prácticas y técnicas de seguridad que al menos el 50% de los encuestados consideraron útiles. La encuesta también identifica ocho métodos basados en código, pero menos del 30% de los encuestados afirmaron haberlos aplicado al menos al 75% de su código base.

Aunque hay que tener en cuenta muchas prácticas de DevSecOps, los expertos en seguridad comparten un mensaje coherente sobre los fundamentos de esta metodología. Frank Schugar, director general de Aerstone, dice: "Recuerde 'incorporar la seguridad, no intente atornillarla', y que 'si realiza un buen proceso de requisitos, debe incluir los requisitos de seguridad, no sólo los funcionales".

"El 'shift left' tiene que ser no intrusivo y sin fricciones en la seguridad del esfuerzo DevOps", añade John Morton, CTO de campo de Britive. "En la práctica, cada profesional debería exigir barreras de seguridad frente a bloqueos en políticas y herramientas".

Determinar en qué prácticas de seguridad centrarse requiere que tengamos en cuenta los objetivos empresariales, los riesgos, la velocidad de desarrollo, el elenco tecnológico, los requisitos de cumplimiento y otros factores. Los tres siguientes son mis candidatos más probables para los equipos que quieren cambiar a la izquierda e integrar la seguridad en su ciclo de vida de desarrollo de software y prácticas DevSecOps: instituir la seguridad en las estrategias 'API-first'; automatizar el análisis del código; y estandarizar las prácticas de observabilidad de datos.

1. Instituir la seguridad en las estrategias API-first

Desde el famoso mandato API de Jeff Bezos, los equipos de desarrollo han reconocido la importancia de las estrategias API-first. Muchos equipos de desarrollo crean API para uso interno, y los equipos avanzados que adoptan arquitecturas de microservicios utilizan pasarelas de API para ampliar y respaldar las capacidades de desarrollo y operativas de las API. Las API son fundamentales para crear productos de datos y modelos empresariales, y permiten la próxima generación de aprendizaje automático abierto y grandes modelos lingüísticos.

"Las API son ahora fundamentales para el desarrollo, desde la definición de especificaciones y contratos de API hasta la gestión de numerosas API gestionadas y no gestionadas", afirma Ivan Novikov, CEO de Wallarm.

El informe API ThreatStats Report Q3'2023 de Wallarm muestra 239 vulnerabilidades de API identificadas en el tercer trimestre, de las cuales el 33% están relacionadas con la autorización, la autenticación y el control de acceso. "Esta tendencia subraya la creciente relevancia de la seguridad de las API en DevOps, lo que la convierte en un aspecto crítico que hay que abordar para garantizar procesos de desarrollo de software sólidos y seguros y lograr los resultados empresariales deseados", afirma Novikov.

El informe enumera los principales riesgos para la seguridad de las API, como inyecciones, fallos de autenticación, problemas entre sitios, fugas de API y controles de acceso rotos.

Así pues, aunque muchas organizaciones han adoptado la práctica recomendada de implantar API, algunas no han aplicado del todo esta estrategia 'shift left' ni prácticas de seguridad durante el desarrollo de API. La escala y la velocidad que los grandes equipos de DevSecOps están llevando a cabo en el desarrollo de API y microservicios sugiere que más deberían considerar la actualización a estrategias de API de seguridad primero.

2. Automatizar el análisis de código

El análisis del código en busca de vulnerabilidades era antes un proceso manual y se realizaba como parte de las disciplinas de programación en parejas o se instituía como un paso tardío en el proceso de desarrollo. Hoy en día, existen muchas herramientas de análisis estático de código, también llamadas herramientas de pruebas estáticas de seguridad de aplicaciones (SAST), que los equipos DevSecOps pueden tener en cuenta.

Carl Froggett, CIO de Deep Instinct, afirma que las aplicaciones actuales son algo más que código. "A medida que los archivos, datos, código y componentes se consumen en un repositorio devops, deben ser escaneados en busca de contenido malicioso en la ingestión y mientras estén disponibles en el repositorio", dice. "Un servicio de escaneado de seguridad debería estar disponible y volver a comprobarse antes de cualquier lanzamiento para pruebas y lanzamiento a producción o clientes y durante cualquier elemento de los conductos CI/CD. Cuanto antes se detecte una amenaza, más fácil será solucionarla y menos perturbará el proceso en su conjunto".

Las herramientas de escaneado de código pueden encontrar muchos errores comunes de los desarrolladores que suponen un alto riesgo para la seguridad. "La revelación accidental de secretos en el código fuente ha sido la causa de muchos incidentes de seguridad a lo largo de los años", afirma Kyle Tobener, responsable de seguridad y tecnología de la información de Copado. "Al construir el escaneo de secretos en su tubería devops, puede detectar y prevenir la fuga de contraseñas y claves de API en su código".

El escaneo de código se convertirá en una herramienta aún más importante a medida que las organizaciones exploren el uso de IA generativa en los negocios y donde los copilotos y los grandes modelos de lenguaje impacten en el desarrollo de software. Los equipos de DevSecOps también deben considerar la ampliación de sus prácticas de pruebas continuas para admitir las capacidades de IA generativa.

Mientras que SAST ayuda a los desarrolladores a identificar vulnerabilidades antes de empujar a la producción, Dan García, CISO en EDB, recomienda agregar capacidades de pruebas dinámicas de seguridad de aplicaciones (DAST). "DAST es una forma de prueba contra el entorno en tiempo de ejecución que ejecuta técnicas automatizadas de actores de amenazas, permitiendo a los equipos escalar su cobertura de prueba a medida que la plataforma se expande", dice.

Si está invirtiendo en desarrollo de software, arquitectura nativa en la nube y pipelines CI/CD, no hay excusa para no incluir capacidades de escaneo de código para revisar el código y resaltar las vulnerabilidades de seguridad.

3. Estandarizar las prácticas de observabilidad de datos

Recientemente publiqué mi artículo número mil, después de casi 20 años escribiendo sobre tecnología, datos y mejores prácticas de transformación digital. Comencé en esto para compartir lo que había aprendido como CTO de startups y mi primer artículo fue sobre el registro de aplicaciones. En aquel momento, yo era el desarrollador, el ingeniero de fiabilidad del sitio y el departamento de operaciones de TI de mi startup, así que cuando había un incidente de producción, yo era el que lo solucionaba, identificaba la causa raíz y determinaba si había que solucionar los problemas de las aplicaciones y cómo hacerlo.

En aquel entonces, el registro de aplicaciones era la forma más fácil de obtener datos de observabilidad, pero hoy en día, hay una proliferación de herramientas y una explosión de fuentes de datos para ayudar a los desarrolladores y SRE a obtener visibilidad sobre el rendimiento de las aplicaciones en producción.

Jeremy Burton, CEO de Observe, afirma: "La mayoría de las herramientas utilizadas para solucionar problemas en las aplicaciones distribuidas modernas están aisladas -diseñadas originalmente para analizar registros, supervisar métricas o visualizar trazas- y nunca se diseñaron para gestionar los volúmenes de datos que vemos hoy en día".

Si los objetivos son la observabilidad de las aplicaciones, la mejora de la fiabilidad y el aumento del rendimiento, los equipos de DevSecOps encontrarán muchas herramientas y prácticas a tener en cuenta. Las soluciones de observabilidad incluyen herramientas de monitorización de aplicaciones, plataformas AIops y herramientas SRE para gestionar los objetivos de nivel de servicio.

DevSecOps debería ampliar el alcance de la observabilidad en dos áreas. Una es la observabilidad de la seguridad para cubrir todo el stack, incluidas las aplicaciones, la integración y la infraestructura de la nube. "La observabilidad de la seguridad implica recopilar datos de varias herramientas y sistemas de seguridad, incluidos registros de red, soluciones de seguridad de puntos finales y plataformas de gestión de eventos e información de seguridad (SIEM), y luego utilizar estos datos para obtener información sobre posibles amenazas", afirma David Linthicum.

DevSecOps también debería extender las prácticas de observabilidad al ámbito de los dataops y los modelos de aprendizaje automático (MLops), ya que los problemas en estos ámbitos también pueden afectar a la fiabilidad, el rendimiento y la seguridad.

"La observabilidad de los datos de 'shift left' significa abordar proactivamente los incidentes de datos en una etapa temprana y minimizar el impacto potencial y el costo asociado con los problemas de datos", dice Rohit Choudhary, cofundador y CEO de Acceldata. "Esto no solo garantiza la fiabilidad y precisión de los datos consumidos por los usuarios, sino que también salvaguarda la integridad y la confianza de los procesos descendentes y la toma de decisiones."

MLops es un canal de entrega para modelos de aprendizaje automático similar a lo que CI/CD es para las aplicaciones y la infraestructura como código (IaC) es para las arquitecturas en la nube. La incorporación de la capacidad de observación a MLops ayuda a detectar problemas de seguridad, como la activación de canalizaciones o la manipulación de datos por parte de agentes de amenazas.

Phil Morris, director general de NetSPI, sugiere ampliar devops a las prácticas MLops y afirma: "En el entorno cambiante actual, el trabajo, los procesos y los controles de cambio que tradicionalmente han conformado el término devops no tienen en cuenta los objetivos y paradigmas de MLOps".

Con tantas metodologías, herramientas y riesgos que puede abordar la mejora de la observabilidad, la clave para los equipos de DevSecOps es dónde crear estándares. Si cada aplicación, canalización de datos y modelo de ML utiliza diferentes convenciones de nomenclatura, prácticas y herramientas de observabilidad, se complica que los SRE y los centros de operaciones de seguridad (SOC) puedan identificar y resolver rápidamente los problemas de seguridad.

Más allá de estos consejos

He destacado tres prácticas de seguridad que probablemente afecten a muchos equipos de DevSecOps y en las que la inversión continua y las normas pueden abordar muchos riesgos de seguridad.

El informe de SAN destaca muchas otras prácticas de seguridad de aplicaciones que ya deberían ser habituales en las organizaciones de TI, como las pruebas de penetración de terceros, la formación en seguridad y la implementación de un cortafuegos de aplicaciones web (WAF). Otras prácticas, como el escaneado de seguridad de contenedores y las plataformas de protección de aplicaciones nativas de la nube, son relevantes cuando se implementa DevSecOps en arquitecturas modernizadas.

La elección de las áreas de seguridad en las que centrarse no está resultando fácil, pero existen demasiados riesgos cuando TI se centra en la seguridad. En su lugar, los equipos deben dar prioridad a las prácticas de seguridad continuas de DevSecOps.