Cuando el software no es un «suministro»

Nota del editor: Este artículo de opinión, escrito por Daniel Appelquist, director de Estrategia de Open Source y Estándares Abiertos de Snyk, analiza el origen del término «seguridad de la cadena de suministro» y si encaja con el proceso actual de desarrollo de software de código abierto.

Me inspiré para escribir esto después de leer una publicación de Thomas Depierre en Mastodon:

La publicación aborda algo que me ha estado preocupando últimamente. Cuando se trata de la seguridad del software, dedicamos mucho tiempo a hablar de la cadena de suministro de software y de conceptos relacionados, como la lista de materiales de software (SBOM). Esta metáfora proviene del léxico industrial. Quienes suelen hablar de economías y de cómo funciona la manufactura conocen la idea de la cadena de suministro. Por eso, cuando hablamos de software —en especial del software de código abierto, con sus dependencias anidadas—, es comprensible que muchas personas de la industria hayan adoptado esta metáfora. Es una forma abreviada de explicar el desarrollo de software moderno a quienes quizá no entienden conceptos como las dependencias.

Sin embargo, como muchas metáforas útiles, no es exacta y solo puede llevarse hasta cierto punto. La metáfora de la cadena de suministro pretende referirse no solo a quien mantiene el proyecto, sino a todo el ecosistema y a cada elemento que interviene para que una biblioteca llegue a un proyecto de código abierto. Por ejemplo, el registro de npm es una fuente de «suministro», mientras que el marketplace de GitHub Actions es otra.

A algunas personas les gusta tratar el mundo del código abierto como una comunidad unificada. La realidad es que está muy dividido en facciones. Hay un sector más corporativo del código abierto, a veces llamado el «complejo industrial del código abierto», para el cual la terminología de la cadena de suministro sería totalmente apropiada. En el otro extremo está el movimiento del software libre, que probablemente consideraría que el concepto de «cadena de suministro de software» va en contra de su forma de pensar. Y entre ambos hay un amplio espectro.

En su publicación, Thomas señala con razón que las dependencias del software de código abierto no implican ningún acuerdo real con proveedores. En ese sentido, quienes desarrollan software de código abierto no son proveedores de los proyectos que dependen de él. El uso de la metáfora de la «cadena de suministro» puede causar malentendidos, como cuando quienes mantienen proyectos de código abierto reciben avisos legales o cartas de empresas. De hecho, esto mismo ocurrió durante el incidente de Log4j. Daniel Stenberg, desarrollador de código abierto conocido por su trabajo fundamental en el proyecto Curl, recibió cartas de un equipo corporativo de compras (con buenas intenciones) sobre el proyecto Curl. El equipo trató a Daniel como proveedor y le exigió que proporcionara datos sobre el uso de Log4j en Curl en un plazo estricto. Este tipo de comunicación podría ser apropiado en una relación formal con un proveedor, establecida mediante un contrato con un acuerdo de nivel de servicio. Pero no es apropiado —en absoluto— en el contexto del código abierto.

Creo que la terminología y el modelo mental de la cadena de suministro de software siguen siendo muy útiles, en especial al comunicarse con responsables de políticas públicas u otras personas que toman decisiones y no conocen las dependencias de software ni cómo funciona el código abierto. Sin embargo, esta metáfora tiene sus límites. Cuando la usamos, también debemos tener en cuenta que las dependencias de código abierto no constituyen un acuerdo con proveedores y, lo que es más importante, que existe toda una comunidad de desarrolladores de software de código abierto que no se ve de esa manera. El ecosistema de seguridad del software debe ser inclusivo y dar cabida a quienes y a las comunidades que quizá no se sientan tan cómodos con la idea de la «cadena de suministro», si queremos elevar el nivel de la seguridad del software en toda la industria.

Entonces, ¿cómo podríamos abordar este problema? Creo que deberíamos considerar adoptar una terminología ligeramente diferente en algunos contextos. El término cadena de dependencias de software podría ser más adecuado cuando nos dirigimos a la comunidad general de desarrolladores de código abierto. O, como industria, debemos explicar con toda claridad a los desarrolladores de código abierto qué queremos decir —y qué no— con «cadena de suministro de software».