Dar más autonomía a tus desarrolladores

La autonomía de los desarrolladores consiste en que tengan espacio para tomar sus propias decisiones a partir de distintos factores, resolver sus propios problemas de seguridad y, en última instancia, asumir la responsabilidad y el control de la seguridad de sus aplicaciones. La autonomía requiere apoyo. Otros equipos la otorgan, la fomentan y la respaldan. Empecemos por el apoyo de arriba hacia abajo que se necesita para que los desarrolladores dediquen el tiempo necesario a entregar código seguro.

«Si lees el memorando sobre la cultura de Netflix en su sitio web, uno de los temas que suele llamar la atención es el debate sobre la libertad y la responsabilidad. Es un concepto que ha marcado la forma de trabajar de su organización de ingeniería. Es interesante porque, como seres humanos, tendemos a enfocarnos en el lado de la libertad. Decimos: “Ah, qué bien. Puedo hacer lo que quiera. Y seguro que tendré que responsabilizarme de algo, pero ya veremos cómo”. En realidad, hay una gran responsabilidad cuando desarrollas software para una empresa como Netflix. No quieres que el servicio deje de funcionar, así que la confiabilidad es fundamental. No quieres que lo hackeen, así que la seguridad también es fundamental. Por eso, como ingeniero, necesitas ser muy responsable. Y como organización de seguridad, a menudo nos veíamos como un equipo que estaba ahí para apoyar y habilitar al negocio. Queríamos que los ingenieros de software de la empresa pudieran enfocarse, en esencia, en las áreas para las que los contrataron. Pero si llegaban a un punto en el que la seguridad era realmente crítica para lo que hacían, entonces recurrían a nosotros para pedir ayuda. Y definir exactamente dónde está ese límite es cuestión de criterio; si existe una buena relación entre el equipo de seguridad y los ingenieros, pueden resolverlo juntos».

Bryan Payne, CISO de BetterUp y exdirector de Ingeniería, Seguridad de Productos y Aplicaciones en Netflix

¿Qué motiva a los desarrolladores a dedicar tiempo a la seguridad?

Tanto si quieren dedicar tiempo a la seguridad como si no, los desarrolladores deben contar con ese tiempo y poder priorizarlo junto con otros entregables funcionales o no funcionales. Deben poder decidir cuánto tiempo necesitan invertir en prácticas de desarrollo seguro frente a consideraciones de confiabilidad o escalabilidad, según las necesidades del negocio. Cuando toman estas decisiones, deben poder explicar lo que hicieron y lograron en su evaluación de fin de año, y contar con el respaldo de su gerente. Corresponde a los gerentes reconocer sus decisiones para que los desarrolladores sepan que invirtieron bien su tiempo. Si no es así, la empresa no les está dando autonomía para dedicar tiempo al desarrollo seguro.

¿Quién debe priorizar la seguridad para el equipo y el negocio?

En última instancia, la iniciativa debe venir desde lo más alto: el CEO. Si la seguridad es una preocupación del negocio, también debe serlo para el CEO. Esa prioridad debe transmitirse por toda la organización: al CIO y al CTO, a los vicepresidentes sénior y vicepresidentes de Ingeniería, a los directores, gerentes y líderes de equipo y, finalmente, al desarrollador que ejecuta las pruebas y corrige los problemas. Con el respaldo de los ejecutivos, los equipos pueden dedicar un porcentaje de sus sprints a la salud de ingeniería, incluida la seguridad, en lugar de tener que enfocarse siempre en nuevas funciones.

Cuando el apoyo y la priorización no vienen desde arriba, es muy difícil argumentar que las pruebas de seguridad son tan importantes (o quizá más) que la siguiente función o necesidad de un cliente. Si estas acciones o actividades se consideran extras que requieren justificación, la reacción por defecto es «no hacer nada» y las conversaciones empiezan con «por qué» en vez de «cómo».

Eso no significa que el CEO y los desarrolladores actúen por los mismos motivos inmediatos. Un desarrollador se enorgullece de su código. Quiere que sea preciso, rápido, confiable y seguro. Al CEO le importan la marca y los resultados financieros, y le preocupa el daño que un incidente de seguridad o una filtración de datos podría causar al negocio. Aunque ambos son buenos motivos para priorizar la seguridad, lo cierto es que un enfoque de adopción de seguridad de arriba hacia abajo tendrá más impacto que simplemente depender de que los desarrolladores sumen más tareas a su carga de trabajo.

«En cuanto al apoyo de los ejecutivos, en nuestro caso vino del CISO, que tenía acceso directo al CTO. Por eso, la iniciativa vino realmente de arriba hacia abajo en el área de tecnología. Desde los niveles más altos, se entendían la importancia y la necesidad de la seguridad. En cuanto a la implementación, dependes de la organización de ingeniería de software y de sus líderes».

Nicholas Vinson, líder de DevSecOps en Pearson

¿Tu equipo de seguridad apoya a tus desarrolladores?

Aunque el equipo de desarrollo es responsable de proteger sus aplicaciones y su código, necesita el apoyo del equipo de seguridad para hacerlo bien. Cuando ambos equipos colaboran, el equipo de seguridad deja de actuar como auditor —ejecutando las pruebas y entregando los resultados (por lo que se le percibe como un obstáculo)— y pasa a ser un equipo de ingeniería de seguridad que ayuda a los desarrolladores a automatizar este trabajo en sus procesos y ofrece asesoría y orientación experta sobre las áreas de mayor riesgo y su priorización.

El equipo de seguridad no puede obligar a los desarrolladores a priorizar el trabajo de seguridad por encima de sus otras tareas. Como mencionamos antes, esa decisión forma parte de las prioridades generales del equipo de ingeniería y del negocio. Históricamente, los desarrolladores han visto a los equipos de seguridad como obstáculos que les hacen auditorías de seguridad al final del ciclo de desarrollo. Al dar autonomía a los desarrolladores para que auditen su propio código y lo prueben por sí mismos, el equipo de seguridad puede dar un paso atrás. Así, puede ayudar a los equipos de desarrollo a analizar los resultados que requieren conocimientos especializados en seguridad y pasar de ser un obstáculo a ser un facilitador. Además, este enfoque permite al equipo de seguridad identificar responsables de seguridad dentro de los equipos de desarrollo, lo que genera aún más oportunidades de colaboración.

El equipo de seguridad también puede enseñar a los equipos de desarrollo sobre los tipos de vulnerabilidades y los riesgos de explotación. Esto puede hacerse mediante programas formales de responsables de seguridad, que también permiten coordinar bien otras actividades, como la implementación de procesos. Aunque los equipos de desarrollo trabajen con mayor independencia, sigue siendo necesaria una estructura general de gobernanza y visibilidad para que el negocio entienda sus riesgos y exposiciones. El equipo de seguridad puede proporcionar a los equipos lineamientos respaldados por políticas para sus pruebas de seguridad, que pueden aplicarse a sus pipelines y prácticas para ayudarlos a detectar problemas con anticipación y cumplir sus SLA.

«Cuando pienso en los responsables de seguridad y en los modelos exitosos, en realidad identificas a varias personas dentro de los equipos de ingeniería que se hacen cargo de la seguridad. Creas un cuadro de mando del que son responsables y que muestra lo que hacemos para proteger nuestro producto o función de la manera adecuada. Los ingenieros pueden comunicarse con la organización central de seguridad cuando lo necesitan, y también les ofrecemos la capacitación más actualizada. Si el equipo de seguridad se encarga de crear herramientas y otros recursos, esos responsables de seguridad ayudan a impulsar su adopción. Por eso, los responsables de seguridad deben formar parte de las organizaciones de ingeniería, no estar fuera de ellas. Son quienes realmente impulsan la seguridad».

Rinki Sethi, vicepresidenta y CISO de Bill.com

La documentación es otro aspecto fundamental para que los desarrolladores adopten estas prácticas. A menudo la escriben los propios desarrolladores, quienes aportan su perspectiva sobre la experiencia e incluyen consejos de uso, explicaciones de las decisiones y matices. El equipo de seguridad puede ayudar a coordinar y compartir esta documentación con otros equipos que también están incorporando prácticas, procesos o herramientas similares, y participar en su creación. Ofrecer al equipo de desarrollo una buena experiencia de autoservicio, similar a la que conoce con otras herramientas para desarrolladores, es clave para lograr una adopción exitosa.

¿Cómo se toman las decisiones sobre reglas de seguridad y procesos en los flujos de trabajo de desarrollo?

Una forma de medir la autonomía es evaluar cuánto pueden aportar y decidir los desarrolladores o los equipos sobre sus propios procesos y las pruebas de sus pipelines. Es comprensible que las reglas y políticas de seguridad se definan con la participación del equipo de seguridad y luego se comuniquen a los equipos de desarrollo, que reciben orientación sobre cómo incorporarlas a los procesos existentes y brindar capacitación efectiva. Lo importante es cómo se comunican e implementan. Los equipos de desarrollo deben poder asumir la responsabilidad y decidir cómo modificar sus flujos de trabajo. Esto no significa que cada equipo deba hacerlo a su manera, ya que es fundamental que aprendan las mejores prácticas entre sí. Los equipos de desarrollo necesitan espacio para tomar decisiones a partir de los aportes de otros equipos y del grupo de seguridad, de modo que las soluciones que implementen satisfagan las necesidades y los estándares que requiere el equipo de seguridad.

Una de las ventajas de este enfoque es la dinámica que genera. En primer lugar, si no impones una práctica o un proceso al equipo de desarrollo, como profesional de seguridad puedes trabajar con ese equipo para resolver un problema o requisito de seguridad, en lugar de encontrarte con la resistencia natural que surge cuando alguien externo impone algo. Si el equipo de seguridad adopta un papel de asesoría, ofrece una función de apoyo que los equipos de desarrollo suelen recibir mejor y que los ayuda a tomar las decisiones correctas.

En última instancia, todo se reduce a quién asume la responsabilidad. Si intentas que tu equipo de seguridad se haga cargo de proteger el código que escriben los equipos de desarrollo, le estás pidiendo que amplíe sus servicios a gran escala por toda la organización, lo que probablemente lo convertirá en un cuello de botella. Tradicionalmente, los equipos de seguridad suelen asumir el papel de imponer requisitos a una organización de desarrollo, algo que los desarrolladores a menudo perciben como una imposición sin mandato.

Si decides que necesitas restringir las tecnologías o la pila tecnológica que puede usar el equipo de desarrollo, es importante crear una ruta recomendada que les ofrezca opciones bien respaldadas por los equipos de seguridad y otros equipos. Por ejemplo, es común contar con un conjunto de imágenes de contenedores de referencia, probadas exhaustivamente por los equipos de seguridad y otros equipos, que los desarrolladores puedan elegir y usar como base. Si ofreces opciones que también funcionen como una ruta recomendada, no se te verá como un obstáculo y ayudarás a los equipos a mantener la seguridad.

Visibilidad y transparencia entre equipos

Obtener visibilidad sobre la postura de seguridad de tus aplicaciones, pipelines y procesos es el primer paso para identificar los riesgos y las exposiciones de tus equipos y tu negocio. Sin embargo, si no actúas en función de los hallazgos, obtener visibilidad no sirve de nada. En este estudio, descubrimos que usar esa visibilidad para resumir periódicamente la postura de seguridad en un cuadro de mando de rendición de cuentas o un informe fue uno de los factores decisivos para que los desarrolladores adoptaran las prácticas con éxito.

Los cuadros de mando de quienes lograron una mayor adopción abarcaban la seguridad y muchos otros aspectos, como el trabajo en funciones, la confiabilidad, el rendimiento y más. Se generaban mensualmente y mostraban métricas operativas como la cantidad de vulnerabilidades, la adopción de herramientas de seguridad, las métricas de pruebas de proyectos, los niveles de capacitación y mucho más. Algo muy importante: las métricas específicas incluidas por cada empresa en sus cuadros de mando estaban alineadas con sus objetivos de negocio. Veamos más en detalle cómo se usaban estos cuadros de mando.

Priorización y justificación

Con un cuadro de mando que incluya métricas del negocio —entre ellas, la seguridad—, es fácil ver si la seguridad es lo más importante en lo que hay que trabajar ahora o si hay problemas más urgentes que atender primero en otras áreas. Es importante evaluar más que solo la seguridad, porque solo se pueden tomar decisiones bien fundamentadas cuando se cuenta con todos los datos.

Los cuadros de mando deben generarse en distintos niveles y adaptar los datos a quien los consulta. Por ejemplo, a un ejecutivo le interesará ver menos detalles que a un líder de equipo, así como una relación más directa con los objetivos generales del negocio. El equipo ejecutivo puede ajustar sus prioridades según los resultados del informe sobre las áreas en las que el negocio necesita enfocarse más. En cambio, un equipo querrá saber en qué debería dedicar más tiempo y cómo se comparan sus resultados con los del resto de la organización.

Todos estos datos ayudan a los desarrolladores y equipos a priorizar mejor en qué deben trabajar en los próximos sprints, así como a justificar esas decisiones. Si alguien pregunta por qué se está haciendo tanto énfasis en un aspecto particular de la seguridad, es importante presentar un cuadro de mando objetivo en lugar de una explicación subjetiva.

Como parte de estos cuadros de mando, el equipo de seguridad también debe ofrecer recomendaciones concretas de priorización al equipo de desarrollo. Por ejemplo, puede destacar una lista de las principales vulnerabilidades (o tipos de vulnerabilidades) en las que enfocarse para lograr el mayor impacto.

Responsabilidad

Para que la seguridad sea una prioridad, debe haber responsabilidad de arriba abajo. El CTO responde ante el CEO, los vicepresidentes de Ingeniería responden ante los CTO, los gerentes ante los vicepresidentes, y así sucesivamente hasta llegar a los ingenieros. Cuando todos tienen un motivo para preocuparse por la seguridad, esta se incorpora como parte habitual de cualquier puesto.

Por suerte, los cuadros de mando son una forma sencilla y eficaz de hacer que las personas adecuadas respondan por los estándares que se espera que cumplan. Al publicar los cuadros de mando, todos en una organización pueden identificar rápidamente qué aspectos están en rojo y cuáles avanzan en la dirección correcta. Además, cuando se alcanzan los umbrales establecidos, quienes responden por métricas específicas pueden determinar las causas, las justificaciones y las posibles soluciones.

Al igual que vimos con la priorización de la seguridad, la responsabilidad en torno a la seguridad realmente debe llegar hasta los niveles más altos. Si no es así, el mensaje de que es importante para el negocio (y, por lo tanto, también debería serlo para el equipo de desarrollo) se diluye considerablemente y se perderá el apoyo.

Apóyate en los valores de los desarrolladores y la gamificación

Por lo general, a los desarrolladores les importa entregar aplicaciones que no solo funcionen, sino que también sean rápidas, confiables y seguras. Hay muchos factores que pueden impedir que un desarrollador entregue código con el nivel que desea, pero, en última instancia, siente orgullo por lo que entrega. Los cuadros de mando son una excelente forma de convertir ese deseo de entregar el mejor código posible en un juego, y de cambiar la responsabilidad entendida como castigo por una motivación positiva.

Darles visibilidad a tus equipos de desarrollo sobre el estado de sus proyectos es una buena forma de mostrarles qué están haciendo bien o dónde están mejorando, así como en qué tienen dificultades o se están quedando atrás. El orgullo de un desarrollador o de un equipo de desarrollo puede verse afectado si su cuadro de mando es el peor del departamento o está muy por debajo del promedio de la unidad de negocio o de toda la empresa. Naturalmente, querrán mejorar la situación, pero primero necesitan conocerla.

La gamificación funciona bien cuando se implementa correctamente. La forma de hacerlo dependerá en gran medida de la cultura de tu empresa, pero compartir los cuadros de mando entre los equipos y darles visibilidad impulsa una respuesta competitiva. Nadie quiere ser el peor equipo, y a la gente le gusta ver cómo progresa su cuadro de mando y cómo supera el promedio del área, o incluso se convierte en uno de los mejores del departamento. También es importante compartir ideas y logros mediante anuncios y conversaciones. Esto da lugar a nuevas iniciativas de equipos que buscan replicar esas ideas o llevarlas más lejos en sus áreas.