¿Qué medidas de seguridad toman PyPI y los repositorios de software de terceros similares?

En realidad escribí una publicación de blog sobre este tema recientemente.

Para responder a tus puntos:

  

¿Cómo evita PyPI que las personas suban malware?

No lo hace. Cualquier código Python puede ser cargado. La ejecución de código arbitrario es posible durante la instalación del paquete. Audita tus dependencias con cuidado.

  

Cuando busco un software, ¿cómo puedo estar (más) seguro de que no es un malware?

Descargue el archivo tar y mire el código.

  

¿Qué puedo hacer yo, como desarrollador de paquetes, para que otros se sientan más seguros al usar mis paquetes?

Si sus usuarios confían en usted, PyPI funciona perfectamente bien. Los paquetes se sirven a través de HTTPS y las sumas de verificación están disponibles para su verificación.

  

¿Hay ejemplos "históricos" de malware en los repositorios? ¿Cuánto daño hicieron?

No tengo conocimiento de ningún ejemplo histórico, pero puedo cargar fácilmente un paquete de demostración. PyPI no hace nada para evitar esto. Actúa como un simple índice de paquetes de Python, depende de los desarrolladores en qué confían.

Aquí hay dos modelos de amenaza:

1. Desarrollador malicioso que carga paquetes maliciosos
2. El atacante malicioso carga paquetes maliciosos que pertenecen a desarrolladores legítimos

PyPI no hace ningún intento de intentar resolver el # 1. La auditoría de código antes de las instalaciones y solo la instalación de paquetes de desarrolladores acreditados es la única "protección" que tiene contra estos. Si encontró un paquete malicioso, puede reportarlo a los mantenedores de PyPI y el paquete probablemente se eliminará. Pero, efectivamente, no hay protección contra él, ya que los paquetes PyPI no se revisan antes de que estén disponibles para la instalación.

En el segundo modelo de amenaza, hay una serie de medidas de seguridad. La versión más reciente de PyPI descarga paquetes a través de HTTPS, y los paquetes pueden opcionalmente firmar con GPG . Hay propuestas para implementar theupdateframework (tuf) , aunque no sé hasta qué punto han llegado.

La instalación en sus paquetes de usuario o virtualenv puede limitar los daños que puede tener un paquete malicioso, al limitar el instalador para que no use sudo durante la instalación. Pero no confíes demasiado en ello.

Por lo que yo sé, en general, existen garantías muy limitadas sobre el código disponible en los repositorios de códigos en línea (por ejemplo, rubygems, npm, nuget, PyPI, etc.). En muchos casos, no admiten ni aplican elementos como el código firmado u otras medidas de seguridad basadas en integridad y la autenticación en los sitios para implementar es, en algunos casos, solo una combinación de nombre de usuario y contraseña, por lo que no solo depende de los desarrolladores no están colocando deliberadamente malware en su código, sino que también tienen un buen nivel de seguridad operativa.

Un problema aún mayor es que en muchos casos las bibliotecas que instala tienen dependencias, en algunos casos una gran cantidad de dependencias, por lo que depende de que los desarrolladores de esas dependencias tampoco sean maliciosos y tengan buenas prácticas de seguridad.

Como dice Terry con muchas librerías de código, hay ganchos para ejecutar código arbitrario en la instalación (incluso antes de que se use la biblioteca), por lo que el hecho de instalar puede tener malas consecuencias, especialmente si se hace como un usuario privilegiado.

En términos de instancias históricas de compromiso, bien hubo el compromiso Rubygems en 2013 como ejemplo de ataque a un repositorio.

En términos de solucionar el problema, bueno, está la iniciativa Update Framework para intentar mejorar la situación.