Revisar un script ajeno

La primera lectura de un script ajeno busca lo que no debería estar escrito en él. Un secreto dentro del código viaja con el código: queda en el historial del repositorio, en copias, en capturas de pantalla. Lo correcto es leerlo de fuera del código, de una variable de entorno o de un gestor de secretos, y poder renovarlo sin tocar el script.

En este módulo los secretos son marcadores obvios y no sirven en ninguna parte; en un caso real, el hallazgo se anota igual y se pide su rotación.

Abre /revision/exporta_alertas.py y busca la constante que guarda la credencial para hablar con el SIEM.

Cuando un script se conecta por HTTPS, la biblioteca comprueba por defecto que el certificado del servidor es válido. Hay un parámetro que apaga esa comprobación, y aparece en tutoriales para «resolver» un error de certificado. Apagarla deja la conexión cifrada, pero sin garantía de que el otro extremo es quien dice ser: quien se interponga puede leer y modificar lo que viaja.

El arreglo no es apagar la comprobación, sino instalar el certificado de la autoridad interna correcta en el servidor.

Busca en el script la llamada que envía datos al SIEM.

Un bloque que captura cualquier error y no hace nada oculta fallos reales: un servidor caído, una credencial vencida, un certificado inválido. El script seguiría diciendo que terminó bien mientras no envía nada. Para quien opera el servidor, no hay diferencia entre «no hubo alertas» y «el envío falló siempre».

Lo que se pide a un script de apoyo es que falle de forma visible: que escriba en un registro qué intentó, qué falló y por qué, y que termine con un código de salida distinto de cero.

Cuando una consulta se arma pegando texto, el texto que escribe el usuario pasa a formar parte de la sentencia. Si ese texto trae comillas y palabras de SQL, deja de ser un dato y se convierte en parte de la consulta. El script recibiría el nombre del usuario desde un formulario interno, así que cualquiera con acceso al formulario podría cambiar lo que la consulta pide.

La forma segura es usar parámetros: se escribe la consulta con un marcador, y el valor se entrega aparte, para que la biblioteca lo trate siempre como dato.

Busca la función que consulta la base de datos de alertas.

Una revisión útil no dice «está mal» ni reescribe el script por el autor. Lista hallazgos concretos, ordena por el daño que pueden hacer y para cada uno cita dónde está, por qué importa y qué cambio se propone. También dice qué está bien. Y responde la pregunta que hizo el compañero: si puede ponerlo en marcha ya, o después de qué cambios.

Piensa en el lugar donde correría: una cuenta de servicio con lectura de toda la base, un formulario como fuente de la entrada y archivos en una carpeta temporal que otros procesos pueden leer.