Con todas las bondades que las libretas Jupyter traen, como suele pasar, cuando se abusa de algo o se toma a la ligera, el ecosistema de las libretas Jupyter puede ser un arma de dos filos y traer riesgos consigo. A este respecto, del que más se habla es del la seguridad informática pero hay issues logísticas o metodológicas que uno debe tener presentes también.
Si bien las libretas no fueron creadas con la ingeniería de software en mente sino la ciencia de datos y los entornos científicos y educativos, es fácil entender cómo es que muchos científicos de datos, practicantes del aprendizaje automático e incluso desarrolladores, incorporaron a los Jupyter notebooks como un elemento importante de su arsenal de desarrollo.
Quienes usamos estas libretas sabemos que su complejidad se va incrementado conforme crecen, con la posibilidad de que no se siga un «flujo lineal» en algún momento. Conforme el notebook crece en número de celdas, se incrementa la posibilidad de reejecutar celdas previas o posteriores hasta obtener un resultado. A veces el autor de la libretas está consiente de ello y a veces no.
Quienes hacemos uso intensivo de éstas y trabajamos en entornos donde igualmente se emplean intensamente (sean libretas Jupyter, Colab, Databricks o similares) nos es familiar encontrarnos en algún momento con que el autor de una de ellas se sorprende al otro día porque ésta no funciona o porque algún colega así se lo reporta. Situaciones en las que se pierde tiempo revisando nuevamente a la. libreta y su código, reentendiendo el flujo en sus celdas o preguntando al autor cómo proceder con algo. Esto, por supuesto, no es más que un asunto de disciplina y pulcritud en el desarrollo, aspectos que se cultivan cuando hay una disciplina orientada el desarrollo de software. No es extraño esperar conflictos por esto cuando el científico de datos, estadístico o actuario entrega su notebook como producto para ser liberado a producción y espera que la gente de DevOps se encargue de «empacarlo y pulirlo» para liberarla a producción como un programa o servicio.
Ahora, del respecto de la seguridad informática, el asunto es mucho más complejo para colocarlo en un sólo post y lo más seguro es que lo desarrolle en varios. Por el momento, dejaré sólo algunas referencias1-5 para que mis lectores se den una idea sobre el tema.
Referencias
- Phuong Cao, «Jupyter Notebook Attacks Taxonomy: Ransomware, Data Exfiltration, and Security Misconfiguration«, arxiv.org, web. Visited: 2025.07.09. URL: https://arxiv.org/html/2409.19456v1.
- Pierluigi Paganini, «Unsecured JupyterLab and Jupyter Notebooks servers abused for illegal streaming of Sports events«, securityaffairs.com, web. Published: 2024.11.20; visited: 2025.07.09. URL: https://securityaffairs.com/171193/cyber-crime/misconfigured-jupyterlab-and-jupyter-notebooks-illegal-live-sports-streaming.html.
- «Security in the Jupyter Server», readthedocs.io, web. Visited: 2025.07.09. URL: https://jupyter-server.readthedocs.io/en/stable/operators/security.html.
- Andy Tate, «Working Securely with Jupyter«, hackernoon.com, web. Published: 2023.10.11; visited: 2025.07.09. URL: https://hackernoon.com/working-securely-with-jupyter.
- «Jupyter Notebooks Considered Harmful: The Parables of Anne and Beth«, tdda.info, web. Published: 2024.11.14; visited: 2025.07.09. URL: https://www.tdda.info/jupyter-notebooks-considered-harmful-the-parables-of-anne-and-beth.
- Assaf Morag, «The threats to Jupyter Notebook«, Computer Fraud & Security, Vol. 2022, No. 12. URL: https://www.magonlinelibrary.com/doi/abs/10.12968/S1361-3723%2822%2970606-9.
Dr. Edu 