Open Source Security Foundation coordinará los esfuerzos para corregir errores de seguridad en el software de código abierto.
La Open Source Security Foundation (OpenSSF) ya tiene unos meses, pero la pregunta es por qué no tiene años. Transcurridos años desde que los atacantes explotaran errores en OpenSSL, Apache Struts entre otros proyectos, junto con nuestra pereza para parchearlos, era necesiario combinar esfuerzos para proteger la cadena de suministro del open source de la que depende toda organización. Pero no se había hecho. No fue hasta 2020 que la industria decidió dejar de fragmentar el enfoque sobre la seguridad.
¿Qué justifica a la Open Source Security Foundation?
Esa es la pregunta que le hice a Kim Lewandowski, gerente de productos de Google y miembro de la junta directiva de Open Source Security Foundation. Según Lewandowski, “Todos dependemos del código abierto, y no hay razón para que intentemos resolver esto individualmente o en un silo”. Tiene razón, pero ¿por qué se tardó tanto en llegar a este punto?
Uno de los problemas de la seguridad del código abierto es que no es un problema de una sola empresa. Goldman Sachs, por ejemplo, quiere que el software del que depende sea seguro, pero ¿por quién o qué debería soportar el peso de pagar para proteger el software que todos usan? Lo mismo ocurre con Google, que ha contribuido y utiliza una gran cantidad de software de código abierto. Como dijo Lewandowski, “Google no va a entrar y reescribir todos los paquetes de software de código abierto que existen en Internet hoy en día que nuestros clientes y nosotros estamos usando”.
Incluso si Google quisiera hacerlo, realmente no podría. Simplemente hay demasiado. Claro, la compañía podría arreglar OpenSSL o Apache Struts o cualquier proyecto que esté actualmente comprometido, pero el universo del código fuente abierto es gigantesco y siempre está en expansión.
Esta, simplemente, no es una tarea que cualquier empresa pueda abordar por sí sola.
Diferentes proyectos, diferentes necesidades
Este hecho se complica por las diversas necesidades de cada proyecto. Según Lewandowski, cada proyecto es diferente y tan conveniente como sería tirar dinero al problema de seguridad, eso no necesariamente funciona. “Hemos visto a algunos mantenedores en los que no quieren el dinero, o no pueden aceptarlo, o simplemente no pueden aplicarlo para las cosas que necesitamos”.
Otros proyectos necesitan ayuda con las auditorías de seguridad, que la Open Source Security Foundation planea habilitar. Actualmente, tales auditorías se llevan a cabo dentro de la CNCF y otras fundaciones u organizaciones, pero están incompletas como están. Según Lewandowski, “las auditorías que hemos visto han sido excelentes y han descubierto muchas cosas, pero luego los proyectos pueden atascarse con un montón de trabajo que debe arreglarse si [el auditor] no ve [la auditoría] hasta el final”, hasta la remediación. Y a veces, continuó, “la gente corrige errores solo para pasar la auditoría o como una solución rápida y el problema de seguridad subyacente más profundo todavía está ahí”.
Entonces, ¿cómo puede una comunidad reunirse no solo para encontrar sino también solucionar problemas?
Lewandowski explicó que OpenSSF actualmente está considerando diferentes modelos para involucrar a los contribuyentes para ayudar a resolver las vulnerabilidades de seguridad. Sin embargo, resulta que no es necesariamente sencillo. Algunas organizaciones, por ejemplo, quieren contribuir con la experiencia de sus ingenieros para ayudar a corregir los errores, lo cual es genial, pero ¿cómo puede OpenSSF hacerlos responsables? Si varias organizaciones miembros se comprometen con cinco ingenieros cada una, por ejemplo, “¿Cómo demuestra su responsabilidad de tal manera que todos esos ingenieros están haciendo exactamente lo que esperábamos que hicieran dentro de la Fundación?” Estos son problemas difíciles y se necesita más ayuda.
A pesar de los enormes desafíos, se están logrando avances. En asociación con ISRG, por ejemplo, el popular cURL está obteniendo un nuevo back-end escrito en Rust que promete brindar una seguridad aún mejor. Esta colaboración es un gran ejemplo del tipo de cosas que OpenSSF puede fomentar.
Pero ¿por qué tardó tanto?
Mejor tarde que nunca
“Es un poco inquietante la cantidad de similitudes que se pueden establecer con la pandemia actual”, señaló Lewandowski. “Es como si a nadie realmente le importara hacer demasiado al respecto hasta que este gran brote nos afecte a todos”. Si bien no hubo ningún evento desencadenante para OpenSSF, ha habido un ritmo constante que nos alerta sobre la necesidad durante años. De vez en cuando reaccionamos. La ruptura Heartbleed de OpenSSL, por ejemplo, dio lugar a la Iniciativa de Infraestructura Central , liderada por la Fundación Linux. En otros lugares surgieron objetivos similares en respuesta a diferentes amenazas.
Aun así, todavía eran esfuerzos en gran parte aislados.
Algunos de esos silos provienen de empresas que ejecutan código abierto en (periódicamente, no tan feliz) ignorancia. Las organizaciones pueden pensar que están pagando por software propietario, pero, como WhiteSource y otros han destacado, más del 95 por ciento de todo el software incluye componentes de código abierto. No importa cuál sea la licencia externa, hay código abierto adentro. Siempre.
Este hecho está comenzando a asimilar, lo que hace que sea el momento perfecto para que OpenSSF tenga un impacto significativo en la industria. Por supuesto, como destacó Lewandowski, “es un equilibrio delicado en cómo se habla de ello. Quieres generar conciencia, pero no puedes asustar a todos “.
Entonces, digámoslo de esta manera: el código abierto es fundamental para todo el software actual, y el software potencia cada vez más incluso los aspectos más remotos de nuestras vidas. El proceso detrás del código abierto, el proceso mediante el cual encontramos y corregimos errores, es la forma correcta de abordar la seguridad del software, pero puede ser mucho mejor si coordinamos nuestros esfuerzos. OpenSSF nos ofrece la oportunidad de hacerlo, y necesita la participación no solo de los proveedores de software, sino también de empresas como JP Morgan Chase, Facebook, Uber y, con suerte, usted.