Script Python revela errores de seguridad críticos

Un desarrollador compartió un script Python con la comunidad gaming y se encontró con miles de vulnerabilidades de seguridad que sus tests internos nunca detectaron: excepciones mal manejadas, dependencias maliciosas, credenciales hardcodeadas, permisos de archivos inseguros e imports inconsistentes. El caso demuestra que los usuarios reales encuentran fallos a velocidades que ningún QA interno puede igualar.

Qué pasó: El script, la comunidad y las vulnerabilidades que nadie vio

Ponele que programás un script Python re útil, lo pulís en tu máquina local, lo testás concienzudamente y decís “esto está listo”. Lo subís a GitHub, lo compartís con la comunidad de un juego popular y esperás feedback constructivo.

Lo que pasó en realidad: en cuestión de horas, gente de todo tipo comenzó a instalarlo en máquinas viejas, con dependencias conflictivas, en entornos raros que ni te imaginabas. Corrieron el script sin leer el README, lo metieron en carpetas con caracteres especiales, lo ejecutaron sin permisos correctos y lo combinaron con otros tools que generaban condiciones imposibles de predecir.

Y en cada paso, encontraban algo roto.

No es sorpresa, pero golpea diferente cuando ocurre en tiempo real, cuando ves los reportes llegando uno tras otro, cuando tenés que admitir que ni vos ni tu equipo pensaron en esa combinación de librería + sistema operativo + versión de Python que alguien más estaba usando.

Ese desarrollador aprendió lo que la industria sabe desde hace años: el testing verdadero comienza cuando públicas.

Por qué los usuarios reales descubren lo que las pruebas no

Las pruebas internas siguen un patrón. Vos (o tu equipo QA) testean en máquinas controladas, con versiones específicas, en entornos predecibles. Usás el software como esperás que se use. Seguís los happy paths primero, luego probás los edge cases que imaginaste.

Los usuarios, en cambio, no tienen ese filtro mental. Instalan cosas en sistemas con 15 años sin actualizar. Meten archivos en carpetas con ñ y acentos. Ejecutan comandos sin permiso. Ignoran warnings. Dejan cosas corriendo en background. Combinan tu herramienta con otras seis que interfieren.

Un desarrollador interno pregunta: “¿y si la carpeta no existe?” Un usuario simplemente: instala en una carpeta que no existe y reporta que se rompió.

La velocidad de descubrimiento es brutal. Estudios de testing muestran que comunidades de usuarios descubren vulnerabilidades y bugs 10-15 veces más rápido que equipos QA tradiciones, porque la cantidad de variaciones que prueban es exponencialmente mayor. Es el efecto de los números: si tu equipo QA tiene 5 personas testeando, pero hay 500 usuarios corriendo tu código de formas distintas, los segundos encuentran cosas que los primeros jamás cubrieron.

Además está el factor psicológico. Un usuario que descargó tu script y le interesa hacerlo fallar (porque busca bugs, o porque simplemente es curioso) va a intentar quebrantarlo de formas que ni un QA remunerado pensaría. Relacionado: ejecutar código sin depender de APIs externas.

Las 5 vulnerabilidades más comunes que descubrieron

1. Excepciones mal manejadas (information disclosure)

El script se caía con un error y mostraba el stack trace completo: rutas absolutas del sistema, nombres de variables internas, versiones de librerías, paths de archivos de configuración, todo. Un atacante con ese información sabe exactamente qué versión de Python corrés, qué dependencias tenés instaladas (y si alguna tiene vulnerabilidades conocidas), y dónde están tus carpetas de config.

El fix es simple: cachá las excepciones, loguea el error completo en un log privado, devolvele al usuario un mensaje genérico: “algo falló, contactá al soporte”. Nada de stacktraces en stdout.

2. Dependencias maliciosas o comprometidas

El script tenía `requirements.txt` pero sin versiones fijas. Alguien instalaba y PyPI le bajaba la última versión de cada paquete. Pasó que una librería menor (una que vos ni sabías que necesitabas) fue compromida, el mantenedor fue comprometido, subieron código malicioso y empezó a propagarse.

Peor aún: typosquatting. Si el script decía “instala requests”, un atacante podría subir un paquete llamado “requets” (con una ‘e’ en vez de ‘s’), esperar a que alguien lo instale por error, e inyectar malware. Pasa constantemente en PyPI.

3. Credenciales hardcodeadas o en .env sin protección

Si tu script necesita API keys, tokens o contraseñas, están hardcodeadas en el código o en un archivo `.env` que el usuario podría ver fácilmente. Alguien hace reverse engineering del binario compilado (sí, existe pyinstaller), extrae el `.env` y ahora tiene acceso a tus cuentas.

Correcto: nunca metas credenciales en código. Si el usuario necesita configurar algo sensible, pedile que lo ponga en variables de entorno, cargalas en runtime, y nunca las printees en logs.

4. Permisos de archivos demasiado abiertos

El script crea archivos de output con permisos 777 (lectura, escritura, ejecución para todos). Si corre en un servidor compartido, otro usuario puede leer, modificar o ejecutar esos archivos. O peor: el script instala un daemon en el sistema y lo configura para correr como root sin restricciones.

Mínimo: crea archivos con permisos 600 (solo tú). Si necesitas que otro usuario lea, usá 640. Nunca 777 a menos que explícitamente lo necesites y lo documentés.

5. Paths e imports frágiles o absolute

El script asume que la carpeta de trabajo es `/home/usuario/mi_script/` (hardcodeado) y que las librerías están en `C:\Python39\Lib`. Cuando alguien instala desde `/opt/` o en Windows con una carpeta distinta, los imports se rompen. Peor si usás `import sys; sys.path.append(‘/absolute/ruta/peligrosa’)`, acabas de abrir una puerta a path traversal attacks.

Mejor: usa relative imports, usa `__file__` para conocer la carpeta actual del script, no hardcodees rutas absolutas, y deja que el sistema maneje los imports estándar. Tema relacionado: consideraciones de privacidad al compartir código.

Vulnerabilidades en dependencias: El riesgo real de PyPI

PyPI es el npm de Python. Cualquiera puede subir un paquete. No hay validación exhaustiva, no hay firma de código obligatoria, no hay auditoría de seguridad. Lo que ves es una reputación de mantenedor y puntuación comunitaria, nada más.

Mensualmente, investigadores de seguridad reportan entre 40 y 60 intentos de ataque en PyPI: typosquatting, dependencias maliciosas, paquetes abandonados con backdoors, librerías que reclaman tener funcionalidad legítima pero en realidad roban datos.

Ojo: si tu `requirements.txt` dice `requests`, pero en PyPI alguien sube un paquete `requets` (sin la ‘s’), y un usuario escribe mal el comando pip, instala malware. O si vos tenías una dependencia indirecta (libA depende de libB) y libB fue abandonada hace años, un atacante la toma y sube código malicioso a esa versión antigua que nadie updateó.

Herramientas como Safety y Bandit escanean tu `requirements.txt` en busca de dependencias conocidas como inseguras. Pylint detecta patrones de código peligroso. GitHub Actions puede correr estos checks automáticamente en cada commit.

Lo correcto: siempre specifica versiones exactas en `requirements.txt` (no solo nombres). Usá `pip freeze > requirements.txt` para congelar exactamente qué versión tenés. Si necesitás actualizar una librería, hacelo manualmente, testeá, y committeá el nuevo `requirements.txt`.

Exposición accidental de información sensible

El caso clásico: un usuario reporta un bug, copea el stacktrace completo en el issue de GitHub. Ahí está todo: rutas de system, nombres de variables, funciones internas, versiones de librerías. Un atacante automatizado busca en GitHub por patterns como “Traceback”, extrae la información y compila un mapa de vulnerabilidades conocidas para esa versión específica.

Otro caso: el script loguea “conectando a DB: user=admin, password=supersecret123”. El usuario reporta un error y adjunta el log. Listo, tenés credenciales públicas en un issue de GitHub (sí, aunque lo cierres, GitHub nunca borra el contenido).

Tercero: el script menciona en output “usando biblioteca X versión Y.Z.W” (porque printea sys.version, os.name, imports, etc). Si esa versión tiene una CVE (Common Vulnerabilities and Exposures) publicada, un atacante ya sabe cómo explotarte.

La regla: loguea con máxima verbosidad en archivos privados (que solo vos accedés). Devolvele al usuario solo lo que necesita saber. Si algo sensible va a un log que el usuario podría ver, sanitizalo: “conectado a BD” en lugar de “conectado a DB: user=admin, password=***”.

Testing en condiciones reales: Playtesting vs QA tradicional

El QA tradicional es así: escribís test cases, sigues un script, documentás resultados, marcás pass/fail. Es metódico, reproducible, pero finito. Tu equipo testea 50 casos. Listo.

El playtesting (o testing con usuarios reales) es desorganizado, impredecible y extremadamente efectivo. Alguien instala, intenta cosas, abandona a mitad, lo mezcla con otros tools, lo usa de formas que nunca pensaste. Lo explicamos a fondo en optimizar rendimiento con herramientas de IA.

La velocidad es el factor clave. En playtesting, cada usuario es un nodo independiente que prueba combinaciones únicas. Cinco usuarios normales pueden cubrir más casos que un equipo QA de 10 personas en una semana. Porque los usuarios genuinamente intentan quebrar cosas (o simplemente son indiferentes a lo que supuestamente debería pasar).

Feedback cualitativo vs cuantitativo: QA te da “test case 15 falló, expected X, got Y”. Un usuario te dice “lo instalé en mi laptop con Windows 11 y un montón de Python IDEs, el script vuela, no sé qué pasa, acá está el error”. Ahora tenés más pistas: qué SO, qué IDEs, qué config, qué contexto del sistema. Es menos pulido pero mucho más valioso.

Tabla: Testing controlado vs usuarios reales

Checklist antes de publicar: Lo que debería haber revisado

Después de esto, el desarrollador compiló una lista de verificación. No es perfecta, pero cubre el 90% de vulnerabilidades comunes:

• Dependencias versionadas: pip freeze > requirements.txt con versiones exactas. Nunca “requests” sin número. Ejecutá bandit -r . para detectar patrones inseguros en el código y safety check para vulnerabilidades conocidas en librerías.
• Manejo de excepciones: Todos los posibles except blocks capturan el error, loguean el stacktrace en un archivo privado, devuelven un mensaje seguro al usuario. Zero stacktraces en stdout.
• Credenciales: Cero hardcodeado. Si necesitas config sensible, forzá que el usuario la ponga en variables de entorno (.env o export VAR=value) y cargalas con os.getenv('VAR') en runtime. Nunca las printees, nunca las mandes a logs públicos.
• Permisos de archivos: Todo lo que creás tiene permisos 600 (solo tú) o 640 (tú + grupo). Nunca 777. Documentá claramente qué permisos necesita el script para correr correctamente.
• Paths relativos: Usá os.path.dirname(os.path.abspath(__file__)) para obtener la carpeta del script, construí rutas relativas desde ahí, nunca hardcodees `/home/usuario/` o `C:\…`. Deja que el usuario instale donde quiera.
• Documentación README: Tiene instrucciones claras de instalación, sección “Requirements”, ejemplos de uso, sección “Security” (qué hace el script, qué datos toca, qué permisos necesita), y cómo reportar bugs de seguridad sin exponerlos públicamente.
• Test coverage: Si el script es crítico, Unit tests con pytest o unittest. Si es simple, al menos smoke tests (instalar en una VM limpia y correr los comandos básicos). Documentá exactamente qué testaste.
• GitHub secrets: Nunca committeás `.env`, keys, tokens. Agregá `.env` al `.gitignore`. Si accidentalmente pusheaste algo sensible, usa git filter-branch o BFG para limpiarlo del historio (no solo borrar el archivo).
• Logging seguro: Loguea con verbosidad en archivos locales. Si logueás a stdout, sanitizá primero: `”Error conectado a {obfuscate_password(pwd)}”`. Nunca loguees el valor completo de variables sensibles.
• Versionado semántico: Si vas a actualizar, usá versiones (v1.0, v1.1, v2.0). En cada release, documentá qué cambió, qué bugs se corrigieron, qué vulnerabilidades se parcharon. Si encontrás un bug crítico, comunicalo claramente a todos los usuarios de versiones viejas.

Lecciones aprendidas: Cambios para la v2 del script

Con el feedback acumulado, el desarrollador refactorizó. Acá lo principal:

Primero, arquitectura. El script monolítico se dividió en módulos: core (lógica principal), config (cargar variables de entorno), logging (manejador de logs centralizado), utils (helpers). Cada módulo tiene una responsabilidad clara. Es más fácil de testeá, debuggear y auditar.

Segundo, testing. Sumó unittest para los módulos críticos: “si falla config, todo falla”, “si el logger se rompe, perdemos visibilidad”, “si utils.validate_input está roto, pasamos datos sucios a la DB”. Luego, integración: instalar desde cero en VMs distintas (Windows 10, 11, Ubuntu 22.04, macOS) y correr comandos reales. No test cases abstractos, testing real.

Tercero, documentación. README ahora tiene sección “Seguridad: Qué hace este script, qué permisos pide, qué datos toca, por qué”. Archivo `SECURITY.md` con instrucciones para reportar bugs de seguridad sin exponerlos (email privado, no issues públicos). Y changelog detallado donde cada versión lista qué se parcheó, qué se mejoró, qué vulnerabilidades se cerraron.

Cuarto, automatización. GitHub Actions ahora corre Bandit, Safety y Pylint en cada commit. Si encontrá dependencias vulnerables o patrones inseguros, el build falla. No se puede mergear si los checks de seguridad no pasan.

Errores comunes que ves una y otra vez

Asumir que “mi máquina funciona, todas funcionan igual”

Tu laptop tiene Python 3.11, pip actualizado, una GPU con CUDA, y corrés Linux en una máquina con 32GB de RAM. El usuario corre Python 3.7, pip sin actualizar, Windows 7 sin actualizaciones, 4GB de RAM. El script que funciona perfecto en tu máquina explota en la de él de formas que no pronto imaginaste.

Loguear datos sensibles pensando que “es solo para debugging”

Escribís un log que dice “conectando a BD admin:super123, status 200” pensando que solo vos lo vas a ver. El usuario reporta un bug, adjunta el log al issue de GitHub, y ahora 500 personas leyeron tu credencial.

No versionador las dependencias (“requirements.txt sin versiones”)

Hoy instalás “requests” y te baja v2.31. Mañana, alguien más instala y le baja v2.35 (con un cambio que rompe tu código). O peor, malware injected en v2.35. Complementá con elegir la plataforma adecuada para tus proyectos.

Excepción genérica “except:” que oculta todo

Cachás cualquier excepción con un `except:` y no hacés nada. El script se cuelga silenciosamente. El usuario no sabe qué pasó, vos tampoco, y el debugging es pesadilla.

Ignorar plataformas distintas (paths de Windows vs Linux)

Hardcodeás `\User\Documents\config.txt` (Windows). En Linux, el usuario corre el script y te tira “archivo no encontrado”. O viceversa, hardcodeás `/home/user/config` y Windows explota porque “/” no existe.

Preguntas Frecuentes

¿Qué es PyPI y por qué es riesgoso?

PyPI (Python Package Index) es el repositorio oficial donde se publican librerías Python. Es abierto: cualquiera puede crear una cuenta y subir un paquete. No hay auditoría obligatoria ni validación exhaustiva. Mensualmente se reportan decenas de paquetes maliciosos, typosquatting, o versiones comprometidas. Siempre usa requirements.txt con versiones exactas, scannea con Safety, y solo descargá paquetes de mantendedores reconocidos.

¿Cuál es la diferencia entre testing QA y playtesting?

QA sigue scripts predefinidos en entornos controlados. Playtesting deja que usuarios reales usen el software de formas impredecibles. Usuarios reales encuentran bugs 10-15 veces más rápido porque naturalmente prueban combinaciones que ni un QA profesional imaginaría. No hay sustituto para poner el código en manos de la comunidad.

¿Cómo sanitizó credenciales en logs sin perder debugging?

Loguea la máxima verbosidad en archivos privados locales (que solo vos accedés), pero sanitizá antes de mostrar al usuario o subir a GitHub. Ejemplo: `logger.debug(f”DB connection: {obfuscate(password)}”)` y `obfuscate()` devuelve “***”. O loguea hashes en lugar de valores. Los logs privados tienen todo el detalle; los públicos, nada sensible.

¿Bandit y Safety encuentran todas las vulnerabilidades?

No. Bandit (análisis estático) detecta patrones comunes de código inseguro: credenciales hardcodeadas, assert en verificaciones, uso de eval(). Safety detecta dependencias conocidas como vulnerables. Pero ninguno te dice si tu lógica de negocio tiene bugs, si tu arquitectura es frágil, o si exponés datos sin querer. Usálos como primer filtro, pero no como validación total.

¿Cuánto testing “real” necesito antes de publicar?

Mínimo: instalar el script en dos máquinas distintas (pueden ser VMs), desde cero, como lo haría un usuario. Corré todos los comandos principales. Si rompe, arregla. Si funciona, publicá con confianza. No necesitás un QA dedicado. Lo que SÍ necesitás es pensar en tus usuarios: ¿qué SO usan? ¿Qué versiones de Python? ¿Qué configuraciones? Y testea en al menos dos de esas combinaciones.

Conclusión

El viaje del desarrollador con su script Python fue humbling. Creyó haber hecho un trabajo sólido, pasó testing interno, se veía bien. Luego publicó y descubrió que la realidad es compleja: usuarios instalan en máquinas viejas, ignorant documentación, combinan herramientas de formas inesperadas y, sin querer, encuentran todo lo que falta.

No es un fracaso. Es la evidencia de que el testing verdadero comienza cuando el código sale al mundo.

Las lecciones son claras: automatizá tu seguridad (Bandit, Safety), versioná todo (dependencias, código, credenciales), loguea sin exponer, documentá clara, y aceptá que los usuarios son el QA final. El playtesting no reemplaza testing interno, pero lo complementa de formas que ningún equipo puede. Antes de publicar un script, checklist de seguridad, dependencias versionadas, excepciones controladas, credenciales seguras, paths relativos y documentación honesta. Después de publicar, escuchá el feedback, arregla rápido, y documenta qué pasó y cómo lo solucionaste. Eso construye confianza y robustez.

Si sos desarrollador y estás a punto de compartir código, recordá: tu máquina es un caso especial. El testing verdadero empieza cuando otros lo usan.

Fuentes

• Aikido – Vulnerabilidades comunes de seguridad en código
• SimeonOnSecurity – Mejores prácticas de seguridad Python
• OpenWebinars – Buenas prácticas de código Python
• TuxCare – Problemas de seguridad en Python
• GenBeta – Vulnerabilidades en Python y supply chain