Introducción
Las aplicaciones dependen de bibliotecas escritas por otros proyectos. Una biblioteca útil puede tener una debilidad conocida incluso cuando tu propio programa parece funcionar. Este cliente de tickets de DeskLite usa una versión afectada de Requests, la biblioteca HTTP de Python.
Leerás un aviso fijo sin conexión, actualizarás el paquete que el cliente importa realmente y comprobarás en conjunto la funcionalidad y los registros de versiones. Ya están preparados el entorno aislado de Python, la caché de instalación y la instantánea del curso con dos avisos. No se requieren conocimientos previos de gestión de paquetes ni de programación en Python.
Ejecutar el Cliente e Inspeccionar su Paquete
En este paso establecerás el comportamiento de negocio actual del cliente y localizarás su dependencia instalada.
Una dependencia es software que usa tu aplicación. Este cliente usa directamente requests para realizar solicitudes HTTP; Requests, a su vez, usa otra biblioteca, urllib3, para parte de ese trabajo. Esa segunda relación es una dependencia transitiva.
cd /home/labex/project/desklite-dependencies
.venv/bin/python es el ejecutable de Python aislado y preparado para este proyecto. Sus paquetes están separados de los de Python del sistema. No se necesita ningún comando de activación ni instalación global. Ejecuta el cliente suministrado como ejecutaste un programa suministrado en el laboratorio de Git:
.venv/bin/python app.py
Espera el ticket original con el título Printer offline. El programa funciona antes de la corrección de seguridad; un problema conocido en una dependencia no implica que todas las solicitudes ya fallen.
pip gestiona paquetes de Python. -m pip indica a este mismo Python aislado que ejecute su gestor de paquetes, mientras que show lee metadatos sin cambiar nada:
.venv/bin/python -m pip show requests urllib3
Busca Name, Version y Location. Requests debería ser 2.32.3, urllib3 2.2.2 y las ubicaciones de los paquetes deberían estar dentro del directorio .venv de este proyecto. Actualizaremos este entorno, no otra instalación de Python.
Interpretar el Hallazgo del Aviso sin Conexión
En este paso relacionarás un hallazgo del analizador con la versión del paquete que requiere atención.
El lanzador preparado course-deps ejecuta OSV-Scanner 2.7.0 sobre una instantánea local fija con fecha 2026-10-28. Esta instantánea, intencionadamente pequeña, contiene dos avisos seleccionados para Requests y urllib3; es material de práctica, no la fuente completa y actual de vulnerabilidades de producción. El comando no realiza solicitudes de red.
Proporciónale el registro de versiones bloqueadas preparado:
course-deps requirements.lock
Espera una línea que contenga requests 2.32.3, GHSA-9hjg-9r4m-mvj7, CVE-2024-47081 y fixed: 2.32.4, seguida de Security findings: 1. Los dos identificadores designan el mismo problema subyacente en distintos sistemas de avisos.
Este aviso se refiere a una posible filtración de credenciales cuando ciertas URL especialmente diseñadas interactúan con credenciales del cliente almacenadas. Aquí no necesitas reproducir un ataque ni configurar esas credenciales. Tu tarea consiste en instalar la corrección compatible proporcionada y conservar las solicitudes normales.
El comando termina intencionadamente con 1 cuando encuentra un problema conocido. Un CHECK ERROR significa que el análisis no pudo completarse y termina con 2; no es una prueba de seguridad. Una calificación de gravedad ayuda a priorizar la revisión, pero no demuestra que esta aplicación ya haya sido atacada aprovechando la vulnerabilidad.
El informe indica una versión corregida. A continuación relacionarás ese informe con los archivos usados para la instalación y la reproducibilidad.
Distinguir los Requisitos del Estado Instalado
En este paso leerás la lista de instalación con versiones fijadas y el registro del entorno resuelto.
cat requirements.txt
Cada línea tiene la forma package==version. Los dos signos de igual fijan ese paquete a una versión. La lista de este curso incluye tanto la dependencia directa como sus paquetes auxiliares resueltos para que la instalación pueda reproducirse sin conexión.
Requests está fijado a 2.32.3. El análisis indicó 2.32.4 como la corrección compatible disponible en la caché. Conserva todas las líneas no relacionadas.
cat requirements.lock
Un registro de versiones bloqueadas describe las versiones exactas de los paquetes resueltos. Aquí es un archivo sencillo en formato requirements con todas las versiones fijadas. Inicialmente coincide con la lista de instalación. Después de la actualización lo regenerarás a partir del entorno real, en lugar de afirmar que un paquete cambió simplemente por editar texto.
Hay tres estados distintos: las versiones previstas en requirements.txt, los paquetes reales dentro de .venv y el registro resuelto en requirements.lock. Todos deben coincidir en la entrega. El analizador lee el archivo que indiques; no demuestra automáticamente que una aplicación en ejecución importe esas versiones.
La caché de /opt/labex-dependency-tools/wheels contiene los paquetes iniciales y corregidos preparados. Instalarás desde esa caché, por lo que no se necesita buscar versiones en línea ni resolver conflictos de dependencias.
Instalar la Versión Corregida Compatible
En este paso actualizarás la lista de instalación e instalarás el paquete corregido en el entorno real del proyecto.
nano requirements.txt
Cambia únicamente requests==2.32.3 por requests==2.32.4. Conserva todas las demás versiones fijadas. Guarda con Ctrl+O, Enter, Ctrl+X.
Ahora usa el gestor de paquetes del mismo entorno. install cambia los paquetes instalados; -r requirements.txt lee la lista de instalación indicada. --no-index desactiva los índices de paquetes en línea y --find-links dirige pip a los archivos wheel preparados. Un wheel es un paquete de instalación de Python precompilado:
.venv/bin/python -m pip install --no-index --find-links /opt/labex-dependency-tools/wheels -r requirements.txt
Pip debería reemplazar Requests 2.32.3 por 2.32.4, mientras los paquetes fijados no relacionados siguen cumpliendo los requisitos. Céntrate en el cambio de versión indicado; los mensajes de progreso pueden variar. No ejecutes simplemente el pip del sistema, porque podrías actualizar un entorno diferente.
.venv/bin/python -m pip show requests
Espera Version: 2.32.4 y una ubicación dentro del directorio .venv de este proyecto. Guardar la lista por sí solo no demostraría este estado instalado. El cliente es un programa de una sola ejecución que importa sus paquetes cada vez que se ejecuta, por lo que las solicitudes posteriores usarán el entorno actualizado.
Regenerar el Registro de Versiones Bloqueadas
En este paso harás que el registro de versiones resueltas describa los paquetes realmente instalados.
pip freeze imprime las versiones fijadas de los paquetes instalados en el entorno. El operador de shell > escribe esa salida en un archivo en lugar de mostrarla en el terminal, reemplazando el contenido anterior del archivo. Aquí, el destino es específicamente el registro de versiones bloqueadas del proyecto:
.venv/bin/python -m pip freeze > requirements.lock
Normalmente el comando no imprime nada porque su salida se ha guardado en el archivo. Léelo:
cat requirements.lock
Requests debería ser ahora 2.32.4; las versiones de las demás dependencias deberían permanecer iguales. El orden o el uso de mayúsculas y minúsculas puede variar sin cambiar los paquetes registrados.
Comprueba la compatibilidad de paquetes con pip check, que revisa las relaciones de dependencia declaradas:
.venv/bin/python -m pip check
Espera No broken requirements found. Esto comprueba la compatibilidad de paquetes, no el comportamiento de negocio de la aplicación ni todas las vulnerabilidades posibles.
Ahora tienes una intención de instalación, unos paquetes instalados y un registro resuelto coherentes. El archivo de bloqueo es un recurso real de reproducibilidad, no un informe copiado que demuestre que se ejecutó un comando. Un método equivalente válido para producir las mismas versiones fijadas correctas también cumple el resultado esperado.
Ejecutar la Comprobación Funcional de Regresión
En este paso confirmarás que la actualización de la biblioteca conservó la solicitud y la respuesta originales.
Una regresión es un comportamiento que funcionaba anteriormente y que un cambio rompe. El curso proporciona test.sh, una pequeña comprobación funcional del cliente original. Estás aprendiendo a ejecutar esta comprobación; la creación de pruebas viene más adelante.
bash test.sh
Espera:
PASS: original ticket request and response.
La comprobación ejecuta realmente el cliente contra el servicio local de tickets y compara los datos devueltos. No considera que cambiar una cadena de versión sea un éxito de negocio.
Ejecuta tú mismo el cliente una vez más:
.venv/bin/python app.py
Espera el ticket original con el ID 1 y el título Printer offline. Ni eliminar el cliente ni quitar su dependencia conservaría ese comportamiento.
La biblioteca está actualizada en disco y este cliente recién iniciado la importa. Las aplicaciones de larga ejecución pueden necesitar su propio reinicio controlado después de actualizar dependencias; el cliente de este laboratorio se inicia de nuevo cada vez. El paso final vuelve a comprobar el problema conocido usando el registro de versiones bloqueadas correcto.
Volver a Analizar el Estado de Dependencias Entregado
En este paso combinarás el análisis con instantánea fija con las pruebas de paquetes instalados y de negocio.
Ejecuta el mismo analizador sin conexión sobre el registro de versiones bloqueadas actualizado:
course-deps requirements.lock
Espera No findings in the selected course snapshot. Esto significa específicamente que los avisos seleccionados ya no coinciden con las versiones registradas. No demuestra que la instantánea cubra todos los problemas presentes o futuros.
Revisa la versión fijada prevista y el paquete realmente instalado:
cat requirements.txt
.venv/bin/python -m pip show requests
Requests debería ser 2.32.4 en el archivo y en el entorno; las versiones fijadas no relacionadas se conservan. La comprobación funcional del paso anterior demuestra un requisito diferente: el cliente actualizado sigue realizando su solicitud original.
Una corrección completa necesita ambos tipos de pruebas. Editar solo un manifiesto podría dejar en uso la instalación vulnerable. Actualizar una instalación sin registrarlo haría poco fiable su reproducción posterior. Omitir un analizador o eliminar la dependencia ocultaría pruebas en lugar de corregir la aplicación requerida.
No se requiere un documento de investigación ni copiar un informe del analizador. Tus entregables son el entorno de paquetes realmente actualizado, los registros correctos con versiones fijadas y la conservación del comportamiento de negocio.
Resumen
Relacionaste un aviso sin conexión con una dependencia real de Python instalada, instalaste un paquete corregido compatible desde la caché preparada y sincronizaste los registros de versiones previstas y resueltas. Un nuevo análisis y una solicitud funcional real confirmaron la corrección específica y la conservación del comportamiento dentro del alcance explícito de la instantánea del curso.
