Revisar un script ajeno antes de que llegue a producción

La primera pregunta de una revisión es qué código corre realmente. Un script que descarga otro y lo ejecuta en el mismo paso no es el que se revisó: es el que el servidor remoto sirva ese día. Eso rompe el control más básico, que es poder decir «esto es lo que se aprobó».

Abre rota-informes.sh y busca la línea que descarga algo de internet.

La construcción curl ... | sudo bash descarga un texto y se lo entrega a un intérprete con privilegios de administrador sin que nadie lo lea. No hace falta suponer mala fe del proveedor: basta con que su servidor se comprometa, o que el archivo cambie por un error, para que el efecto llegue a todos los servidores donde el script esté programado.

En Bash, una variable sin comillas se expande y se divide por espacios; y si está vacía, desaparece. Así, rm -rf $DIR/* con DIR vacío se convierte en rm -rf /*. Citar la variable con comillas y comprobar que no está vacía antes de usarla son los dos arreglos habituales. Tampoco ayuda que un cd falle sin que el script se detenga.

Mira las líneas 10 y 11 de rota-informes.sh. Al script le llega un argumento y lo guarda en una variable en la línea 5.

Una lista de revisión tiene valor cuando cada punto tiene un resultado. Un punto «sin revisar» no es un punto aprobado: es un hueco, y el veredicto no puede apoyarse en él. Conviene mirar cuál es antes de decidir, porque a veces es justo el que daría más información, como saber si el script deja huellas de lo que hace.

Con lo leído, el analista decide entre aprobar, devolver con cambios o rechazar. Un buen veredicto dice qué se pide cambiar, en términos que el proveedor pueda cumplir, y qué no se hace mientras tanto. No acusa a nadie: describe lo que el archivo hace y lo que el procedimiento de la empresa exige.