Los científicos de datos reducen el uso de código fuente abierto debido a preocupaciones de seguridad

Las vulnerabilidades en los componentes de código abierto, como las fallas generalizadas reveladas hace 10 meses en Log4j 2.0, han obligado a los científicos de datos a reevaluar el código fuente abierto que se usa con frecuencia en el análisis y la creación de modelos de aprendizaje automático.

Según un informe de Anaconda, una empresa de plataforma de ciencia de datos, el año pasado, el 40 % de los científicos de datos, analistas comerciales y estudiantes encuestados redujeron el uso de componentes de código abierto, mientras que un tercio se mantuvo estable y solo 7 % incorporó más código fuente abierto en sus proyectos. La mayoría de los encuestados no reporta al departamento de tecnología de la información (18 %), sino que trabaja dentro de su propio grupo de ciencia de datos o investigación y desarrollo (47 %), según Anaconda's “2022 Estado de la ciencia de datos” informe, publicado la semana pasada.

Si bien los desarrolladores de software y TI ya comenzaron a examinar el código seguro, las preocupaciones sobre la seguridad en el software de código abierto son una tendencia relativamente nueva para el mundo de la ciencia de datos, dice Peter Wang, cofundador y director ejecutivo de Anaconda.

“Vemos una gran cantidad de personas que están en organizaciones donde TI ha creado una postura muy estricta en torno al código abierto y Python”, dice. “Estos no son desarrolladores expertos. … Son científicos de datos y personas de aprendizaje automático que pueden no ser desarrolladores muy experimentados, usan todo lo que pudieron descargar para hacer su análisis, y luego se lo entregaron a TI”.

La seguridad de los componentes de código abierto, y la cadena de suministro de software, en general, se ha convertido en una consideración primordial entre los desarrolladores de software, las empresas y los gobiernos nacionales durante los últimos dos años. En mayo, por ejemplo, el Instituto Nacional de Estándares y Tecnología de EE. UU. (NIST) emitió una guía para abordar los riesgos de la cadena de suministro de software. Además, un número creciente de proveedores de software se han unido a la Fundación de Seguridad de Software Abierto de la Fundación Linux (OpenSSF).

En general, la madurez de los esfuerzos de seguridad de las organizaciones ha mejorado. Aproximadamente la mitad de las empresas cuentan con una política de seguridad de código abierto, lo que conduce a un mejor desempeño en las medidas de preparación para la seguridad, según la encuesta de junio. Además, los esfuerzos para controlar el riesgo de código abierto han aumentado un 51 % en los últimos 12 meses, un estudio de madurez de seguridad declaró en Septiembre 21.

“[Con] la atención puesta en las cadenas de suministro de software, la mayoría de las organizaciones empresariales están adoptando un enfoque basado en el riesgo para la seguridad de las aplicaciones”, dijo Jason Schmitt, gerente general de Synopsys Software Integrity Group, en un comunicado que anuncia el estudio. “Este enfoque reconoce que la seguridad no se limita al código base; incluye el proceso de desarrollo de software donde las revisiones y pruebas de seguridad 'cambian de lugar' para mejorar continuamente los resultados de seguridad”.

Los desarrolladores amplían el uso de código abierto 

Las empresas de software no están viendo ningún tipo de disminución en el uso de código abierto, según otros datos. En cambio, las organizaciones de desarrollo se están enfocando en mejorar la seguridad del software de fuente abierta y usar la seguridad como una guía principal en la selección de componentes.

En el2021 Estado de la cadena de suministro de software” informe, por ejemplo, Sonatype descubrió que los cuatro principales ecosistemas de código abierto (Maven Central Repository (Java), Node.js (JavaScript), Python Package Index (Python) y la galería NuGet (.NET)) albergaban 37 millones proyectos y componentes de código abierto, un aumento del 20% año tras año. La demanda de esos componentes también está aumentando: se descargaron más de 2.2 billones de componentes, un aumento anual del 73 %.

Un alejamiento autoinformado de los paquetes de código abierto por parte de la comunidad de ciencia de datos probablemente indica una mayor conciencia de los problemas de seguridad y menos acerca de deshacerse de los componentes de código abierto en desarrollo, dice Tracy Miranda, directora de código abierto en Chainguard.

Si bien los equipos de ciencia de datos y los equipos de desarrollo pueden haber reaccionado de manera diferente a los principales problemas de seguridad, como Log4j 2.0 — Las empresas tienen pocos recursos cuando se alejan de un paquete de código abierto que adoptar un paquete diferente cuyos mantenedores han puesto un mayor énfasis en la seguridad, dice.

“Las empresas aprovechan el código abierto como una forma de aumentar su velocidad, por lo que si están reduciéndose, ¿a qué están reduciéndose? ¿Escribir código internamente? ¿Usando versiones de terceros empaquetadas? Miranda dice, y agrega que, en cambio, "creo que podemos esperar que las empresas sean más exigentes con respecto a la calidad del código abierto que utilizan, especialmente en relación con las características de seguridad".

Los científicos de datos se están poniendo al día

La desconexión entre los dos lados probablemente se deba a las diferentes audiencias en las distintas encuestas. La encuesta de Anaconda se centró en los profesionales de la ciencia de datos, como se puede ver en la elección de lenguajes de programación de los encuestados: el 58 % usó Python y el 42 % usó SQL, mientras que solo el 26 % usó JavaScript. 

Una mejor medida de los sentimientos de los desarrolladores de software es StackOverflow "Encuesta para desarrolladores de 2022”, que encontró que mientras el 58 % de las 'personas que aprenden a codificar' usan Python, solo el 44 % de los desarrolladores profesionales codifican en ese lenguaje. Por otro lado, el 68% de los desarrolladores profesionales utilizan JavaScript, según la encuesta de StackOverflow.

Además, mientras que los profesionales de la ciencia de datos trabajan en empresas que abrumadoramente (87 %) permiten el software de código abierto, alrededor de una cuarta parte (26 %) tiene una supervisión mínima por parte del departamento de TI de sus opciones de código abierto, indicó el informe de Anaconda. En otro 18% de las empresas, el departamento de TI solo especifica alrededor de la mitad de los componentes de código abierto disponibles.

Los mantenedores de los proyectos más críticos, de los cuales hay cientos, si no miles, necesitan usar dependencias seguras, probar su propio código y validar la confiabilidad de los colaboradores. Los mantenedores también deben publicar un cuadro de mando de seguridad: una iniciativa creada por Google ahora administrada por Open Source Security Foundation (OpenSSF), que otorga un grado de seguridad a un proyecto basado en casi 20 criterios diferentes.

Si bien es probable que aumente la conciencia, no hay una solución rápida, dice Miranda.

“La realidad es que las opciones más seguras no han existido anteriormente”, dice ella. “Recortar las dependencias innecesarias para reducir la superficie de ataque es sensato, pero es difícil hacerlo una vez que el árbol de dependencias ha crecido”.