Evolución de la seguridad en las OSPO: el modelo de Kübler-Ross del código abierto

¿Qué hay en una OSPO? Las oficinas de programas de código abierto están surgiendo por todas partes, en reconocimiento de la realidad: el software de código abierto (y también los estándares abiertos, diría yo) desempeña un papel enorme en la creación y el mantenimiento del software que cada vez impulsa más al planeta. El informe The Evolution of the Open Source Program Office (OSPO) de la Linux Foundation habla de cinco etapas en el desarrollo de una OSPO:

• Etapa 0: Adoptar el código abierto de manera ad hoc

• Etapa 1: Ofrecer cumplimiento de OSS, inventario y capacitación para desarrolladores

• Etapa 2: Promover el uso de OSS y la participación en el ecosistema

• Etapa 3: Alojar proyectos de OSS y hacer crecer comunidades

• Etapa 4: Convertirse en un socio estratégico para la toma de decisiones

 Pero, cuando se trata de seguridad, quizá sea más instructivo pensar en cinco etapas diferentes (al estilo del modelo de Kübler-Ross):

• Negación: Las organizaciones niegan hasta qué punto dependen del código abierto. Tal vez crean saberlo, pero cuando empiezan a pensarlo, se dan cuenta de cuánto dependen de una variedad de código y herramientas de código abierto, especialmente en el pipeline de compilación. Puedes consultar el 2022 Snyk Open Source Security Report sobre este tema. 

• Ira: Como no han prestado atención, las organizaciones ni siquiera saben cuánto código abierto usan. Esta ira (con suerte) las lleva a una intensa labor de capacitación y registro de proyectos de código abierto, y a darse cuenta aún más de lo fundamental que es el OSS para su organización.

• Negociación: En esta etapa, las organizaciones empiezan a dialogar y a ponerse en contacto con la comunidad de OSS. A menudo, aprovechan los conocimientos que las personas han adquirido mediante una participación ad hoc y comienzan a orientar esa participación hacia una estrategia coherente.

• Depresión: En esta etapa, la situación empieza a volverse real, ya que otras áreas de la organización comienzan a reconocer el valor de la OSPO. Y eso debería ser genial, ¿no? Por desgracia, también es la etapa en la que se dan cuenta de que las dependencias de OSS representan un riesgo para toda la organización, especialmente si se tienen en cuenta las vulnerabilidades de seguridad.

• Aceptación: Aceptar plenamente que vivimos en un ecosistema de código abierto implica aprender a asumir un rol de liderazgo en ese ecosistema y aceptar que la OSPO no solo es un centro de excelencia para los ecosistemas abiertos, sino también un centro de excelencia en seguridad.

De acuerdo, lo anterior es un poco exagerado. El punto es que el código abierto llegó para quedarse. Desempeña un papel muy importante en la creación y el mantenimiento de la gran mayoría del software, especialmente el que usamos todos a lo largo de nuestras vidas. El código abierto implica ceder parte del control a la comunidad a cambio de mayor calidad y menores costos operativos. Las organizaciones que aprendan a aceptar esta realidad y comiencen a asumir un rol de liderazgo en esa comunidad se convertirán en líderes del mercado. Y la seguridad es una parte clave de esto.

Entonces, ¿cómo pueden las OSPO asumir eficazmente su rol no solo como promotoras de la apertura, sino también como referentes en seguridad? En primer lugar, incorporando experiencia en seguridad al equipo de la OSPO. Contrata a un especialista en seguridad que conozca los desafíos de la cadena de suministro de software. Participar en el grupo de trabajo “End User” de la Open Source Security Foundation puede ser una forma de compartir información en un espacio seguro con otras organizaciones similares.

Un excelente punto de partida son algunos materiales que acaba de publicar la Open Source Security Foundation (OpenSSF).

• Guía concisa para desarrollar software más seguro

• Guía concisa para evaluar software de código abierto

• Guía de mejores prácticas de NPM

Todos estos recursos de OpenSSF ayudan a empezar a reflexionar sobre los desafíos complejos de la seguridad del código abierto. Si estás creando una OSPO o una función similar dentro de una organización de cualquier tamaño, seguramente reconocerás de inmediato algunos de los problemas que se analizan en estas guías. Lo más probable es que tu organización use npm. Tu código está en sistemas de gestión de código fuente como GitHub. Usas software de código abierto de distintas fuentes, con diferentes licencias y antecedentes. Estas guías abordan todos estos temas e incluyen enlaces a información más detallada.

A partir de ahí, las OSPO deben contratar personal de seguridad o recurrir a especialistas para anticiparse a estos problemas. Empieza a pensar en la lista de materiales de software (SBOM) para los procesos de desarrollo, compilación e implementación. Liran Tal tiene una excelente publicación de blog sobre SBOM para ayudarte a comenzar.

Como nota aparte, es interesante y positivo ver legislación de EE. UU. destinada a proteger el software de código abierto usado en el desarrollo y la operación de servicios gubernamentales que exige la creación de OSPO en organismos gubernamentales.

¡Brindemos por un 2023 seguro (y abierto)!