El tema de la confianza es un clásico en la informática (recordemos ¿Te puedes fiar del vendedor de tu ordenador? o ¿En quién confías? El compilador). Se trata de que manejamos tecnología tan compleja que el engaño puede estar en cualquier parte de la cadena.

También hemos hablado del ataque a los datos que se utilizan para entrenar a las inteligencias articiales, en Ataques a los datos de entrenamiento de inteligencias artificiales y nos viene bien recordarlo para reunir ambos temas, como hizo Ross Anderson en ML models must also think about trusting trust.

Ellos hablan de insertar un troyano o una puerta trasera en un modelo de aprendizaje de máquina a través del compilador.

Our latest paper demonstrates how a Trojan or backdoor can be inserted into a machine-learning model by the compiler.

Se trata, nos dice, de hacer que el compilador reconozca el tipo de modelo que está compilando (procesado de imágenes, texto, ..) y con ellos imaginar un mecanismo para insertar nuestros ataques.

The answer is yes. The trick is for the compiler to recognise what sort of model it’s compiling – whether it’s processing images or text, for example – and then devising trigger mechanisms for such models that are sufficiently covert and general.

Nada es tan fácil, ni tan bueno como parece.

En Open Source Initiative expands its role to AI and machine learning nos hablan de cómo esta inciativa (OSI) está empezando a prestar atención a otros usos de los programas, relacionados con la inteligencia artificial.

La idea del software libre es que se puede utilizar de la forma que se considere oportuna.

It all boils down to the idea that with open source, you get the right to use the software code any way you want.

Pero se observa una tendencia de las empresas de comenzar con licencias libres para posteriormente cambiarlas, quedándose con su trabajo y el de la comunidad (porque consiguen la cesión previa, claro).

They build up their business and code over five to 10 years. Along the way, they collect contributor license agreements (CLA) that give the company the rights to their code. Then they change the license and take away those rights.”

Pero también hay otros usos en los que no se había pensado anteriormente: cuando ese código se utiliza para entrenar inteligencias artificiales.

Moving forward, the OSI will also address the roles that machine learning (ML) and Artificial Intelligence (AI) play in both using and building open-source software. This has become an increasingly urgent issue.

Pero no se trata sólo de una cuestión de legalidad, sino también de equidad y justicia con esos desarrolladores.

Maffulli thinks, “Legally, it appears that GitHub is within its rights.” That said, don’t get “lost in the legal weeds discussing if there is an open-source license issue here or a copyright issue. This would miss the wider point. There is a fairness issue that affects the whole of society, not just open-source developers.”

Java sigue siendo un lenguaje de amplio uso y por eso es bueno conocer los problemas de seguridad que podemos tener utilizándolo. En este caso XML Security in Java y los problemas que nos cuentan son casi todos viejos conocidos (expansión de entidades, inyecciones, y otras ‘diabluras’). Interesante, aunque no trabajes con Java, si necesitamos procesar XML de vez en cuando.

No suelo traer aquí con tanta frecuencia otros temas relacionados con mi trabajo (en particular, con mis clases) pero me gusta anotar algunas cosas y en esta ocasión le ha tocado a Finally, a Fast Algorithm for Shortest Paths on Negative Graphs por varios motivos.

El problema de encontrar los caminos mínimos (de menor peso) en un grafo está resuelto hace mucho tiempo (año 1956 por Edsger Dijsktra) con una estrategia vorazsiempre que los pesos sean positivos. Sin embargo, la cosa se complica cuando permitimos que haya pesos negativos en el grafo. Tanto, que sigue siendo un problema a la espera de buenas soluciones.

La existencia de estas soluciones eficientes pueden hacernos pensar que ya no es interesante preocuparse de estos problemas. Sin embargo, de vez en cuando recibimos ‘buenas’ noticias, como en este caso: se ha publicado una solución Negative-Weight Single-Source Shortest Paths in Near-linear Time para el problema más general, que permite ejes de peso negativo.

Aunque dicen que es un algoritmo sencillo de explicar y de programar, conviene rdecir que hay que descomponer el grafo y utilizar técnicas de aleatorización.

Seguimos con GitHub. En esta ocasión 5 tips for embedding security into your workflows. Como dice el título, cinco recomendaciones para integrar la seguridad en nuestro flujo de trabajo.

• Herramientas de seguridad cercanas al código.

Aquí tratan de ‘vendernos’ sus integraciones, claro.

• Reemplazar una aproximación reactiva por una proactiva.

Que los problemas no nos sorprendan porque ni siquiera habíamos pensado en ellos.

• Mantener una buena relación señal/ruido.

El problema de muchas herramientas de seguridad es que son muy ruidosas: se hace complicado discriminar el grano de la paja y terminan siendo una fuente de molestias en lugar de una ayuda.

While security tools are needed, they often cause more headache than help. This is because the aforementioned third-party security apps most organizations use are slow, create noise, and may not be integrated into the native developer environment.

• Permitir la realimentación sobre aspectos de seguridad cuando colaboramos con otros.

Cuando otros colaboran con nosotros (o nosotros con ellos) es bueno poder vigilar lo que va sucendiendo en el código.

• Automatizar los procesos de seguridad.

Cuando sea posible, hacer pruebas y comprobaciones de seguridad de manera automática.

Como decía arriba, se trata de publicitar su servicio GitHub Advanced Security pero los consejos son relevantes y podemos usar sus herramientas u otras.