Desplazar la seguridad a la izquierda implica cultura, no solo herramientas

Esta es la segunda parte de una serie de cuatro partes sobre cómo crear una estrategia de AppSec para Kubernetes. La primera parte está aquí.

A medida que las organizaciones adoptan prácticas de DevOps y transforman la forma en que crean y mantienen aplicaciones, muchos aspectos del desarrollo de aplicaciones están cambiando.

La administración tradicional de sistemas ha cambiado en muchas organizaciones, que han adoptado la ingeniería de confiabilidad del sitio y la filosofía de «tú lo creas, tú lo operas». Cada vez más, las redes se describen mediante software, sobre todo con el auge de las mallas de servicios. Las conversaciones sobre monitoreo están pasando de resolver problemas conocidos pero inciertos a enfocarse en la observabilidad y en lo desconocido. La tendencia es clara. Cada vez más, trasladamos a los desarrolladores distintos aspectos de la operación de aplicaciones. En materia de seguridad, esta transición apenas comienza. Para que la seguridad pueda hacer esta transición de manera efectiva, debemos elegir cuidadosamente las herramientas y construir una cultura de forma deliberada.

Los contenedores como unidad de software

Exploremos los temas de las herramientas y la cultura a través de los contenedores. Como se señaló en la publicación anterior, los contenedores se están convirtiendo cada vez más en la unidad estándar de software. Creamos imágenes, las analizamos en distintas áreas de la organización, hacemos afirmaciones sobre ellas y, en general, las usamos para abstraernos de otros empaquetados específicos de plataformas o lenguajes.

La idea de un único formato de paquete, un repositorio de paquetes y un mecanismo para instalar esos paquetes en producción no es nueva. Por ejemplo, los paquetes y repositorios RPM, así como herramientas como Yum, podrían encajar en este modelo. Sin embargo, en el caso de los contenedores hay dos diferencias importantes que son más organizacionales que técnicas:

1. El empaquetado de sistemas operativos solía estar a cargo de un equipo independiente dentro de la organización de operaciones en general.

2. Pocas organizaciones usan un solo formato de empaquetado. Cada sistema operativo y cada lenguaje de programación tiene su propia cadena de herramientas de empaquetado.

Lo nuevo de las imágenes de contenedores es que la responsabilidad del empaquetado está pasando inevitablemente a los desarrolladores y a los equipos de desarrollo. Por eso, por ejemplo, hay más de 2 millones de archivos Dockerfile públicos en GitHub. Las herramientas de pruebas y seguridad creadas para una generación anterior de empaquetado y para normas organizacionales previas no se adaptan bien a los flujos de trabajo y las cadenas de herramientas de desarrollo actuales. Por ejemplo, el concepto de aplicar parches está pasando cada vez más de hacer cambios directamente en producción a reconstruir y volver a implementar artefactos inmutables.

¿Te interesa la gestión de vulnerabilidades en contenedores? Obtén más información sobre cómo Snyk puede ayudarte a proteger tus contenedores.

Herramientas centradas en los desarrolladores

La estandarización de las imágenes nos brinda muchas oportunidades para crear herramientas realmente centradas en los desarrolladores que acompañen la transición que estamos viendo. ¿Cuáles son algunas de las características de esta nueva generación de herramientas?

• Que se puedan usar localmente: la mayoría de los desarrolladores escriben y leen código en sus computadoras, y las herramientas que funcionan localmente les permiten comprender un nuevo ámbito.

• Que se integren con los IDE: cuando los desarrolladores usan entornos de desarrollo integrados, las herramientas que utilizan deben estar integradas.

• Que interactúen directamente con los sistemas de control de código fuente: estos sistemas, cada vez más basados en Git, dominan el trabajo diario de los desarrolladores. Las herramientas para desarrolladores deben convertirse en parte del equipo, sobre todo a medida que más desarrolladores adoptan enfoques como GitOps.

• Que se puedan configurar en los pipelines de CI/CD: la integración continua es un requisito previo para entregar software de manera efectiva y el lugar perfecto para integrar controles de calidad, cuando el ciclo de retroalimentación para los desarrolladores todavía es corto.

Una de las ventajas de las herramientas que abarcan el ciclo de vida del desarrollo de software (SDLC) es que ayudan a los desarrolladores a comprender mejor la aplicación y evitan el temido «en mi máquina sí funciona».

Una cultura DevOps basada en compartir

La calidad y la seguridad no son responsabilidad exclusiva de los desarrolladores; los operadores especializados y los expertos en seguridad siguen siendo esenciales para el éxito. Se necesitan expertos que orienten y capaciten sobre cómo desplazar la seguridad a la izquierda a medida que se transfieren responsabilidades a los equipos de desarrollo. Así como los equipos de ingeniería de confiabilidad del sitio (SRE) apoyan a los desarrolladores para que puedan operar mejor sus aplicaciones, el área de seguridad debe adoptar la misma mentalidad.

Las herramientas que facilitan la colaboración entre distintas disciplinas, a menudo a través de las barreras organizacionales, son imprescindibles, no solo deseables. Las alternativas —funciones separadas con herramientas propias que compiten entre sí, o un grupo con una experiencia de segunda categoría— no son suficientes. Si los operadores usan un conjunto de herramientas y los desarrolladores otro, solo se crearán silos organizacionales. Esto rara vez significa que deba existir una única herramienta que lo haga todo. Las herramientas modernas para desarrolladores se centran en las aplicaciones y en la retroalimentación dentro del proceso de desarrollo. Deben integrarse bien con las herramientas de operaciones —capaces de realizar investigaciones de bajo nivel y generar informes a lo largo del tiempo— y funcionar con las abstracciones que usan los distintos roles.

Conclusión

En las conversaciones sobre «desplazar a la izquierda», a menudo se habla de transferir responsabilidades de las funciones tradicionales de TI a los equipos de desarrollo, con el objetivo de acelerar el ciclo de retroalimentación. Sin embargo, cambiar fundamentalmente nuestra forma de trabajar sin cambiar también las herramientas rara vez funciona. El desarrollo de software complejo es en sí mismo un sistema sociotécnico complejo. A medida que involucramos más a los desarrolladores en la gestión de los desafíos de seguridad, también debemos entender que las herramientas que necesitan serán distintas de las de la generación anterior, enfocadas en los operadores.