Introduction
Les applications dépendent de bibliothèques écrites par d'autres projets. Une bibliothèque utile peut présenter une faiblesse connue même lorsque votre propre programme semble fonctionner. Ce client de tickets DeskLite utilise une version affectée de Requests, la bibliothèque HTTP Python.
Vous lirez un avis de sécurité hors ligne fixe, mettrez à jour le paquet que le client importe réellement et vérifierez ensemble les fonctionnalités et les enregistrements de versions. L'environnement Python isolé, le cache d'installation et l'instantané du cours contenant deux avis sont préparés. Aucune expérience de gestion des paquets ni de programmation Python n'est requise.
Exécuter le client et inspecter son paquet
Dans cette étape, vous établirez le comportement métier actuel du client et repérerez sa dépendance installée.
Une dépendance est un logiciel utilisé par votre application. Ce client utilise directement requests pour effectuer des requêtes HTTP ; Requests utilise lui-même une autre bibliothèque, urllib3, pour certaines parties de ce travail. Cette seconde relation est une dépendance transitive.
cd /home/labex/project/desklite-dependencies
.venv/bin/python est l'exécutable Python isolé préparé pour ce projet. Ses paquets sont séparés du Python système. Aucune commande d'activation ni installation globale n'est nécessaire. Exécutez le client fourni comme vous avez exécuté un programme fourni dans le lab Git :
.venv/bin/python app.py
Le ticket d'origine dont le titre est Printer offline est attendu. Le programme fonctionne avant la correction de sécurité ; un problème de dépendance connu ne signifie pas que toutes les requêtes échouent déjà.
pip gère les paquets Python. -m pip demande à ce même Python isolé d'exécuter son gestionnaire de paquets, tandis que show lit les métadonnées sans rien modifier :
.venv/bin/python -m pip show requests urllib3
Repérez Name, Version et Location. Requests doit être en version 2.32.3, urllib3 en version 2.2.2, et les emplacements des paquets doivent se trouver dans le répertoire .venv de ce projet. Nous mettrons à jour cet environnement, pas une autre installation Python.
Lire la détection liée à l'avis hors ligne
Dans cette étape, vous relierez une détection du scanner à la version du paquet qui nécessite une intervention.
Le lanceur préparé course-deps exécute OSV-Scanner 2.7.0 sur un instantané local fixe daté du 2026-10-28. Cet instantané volontairement réduit contient deux avis sélectionnés pour Requests et urllib3 ; il s'agit d'un jeu de données pédagogique, pas du flux complet et actuel de vulnérabilités de production. La commande n'effectue aucune requête réseau.
Fournissez-lui l'enregistrement de verrouillage préparé :
course-deps requirements.lock
Une ligne contenant requests 2.32.3, GHSA-9hjg-9r4m-mvj7, CVE-2024-47081 et fixed: 2.32.4 est attendue, suivie de Security findings: 1. Les deux identifiants désignent le même problème sous-jacent dans des systèmes d'avis différents.
Cet avis concerne une fuite possible d'identifiants lorsque certaines URL spécialement conçues interagissent avec les identifiants stockés du client. Vous n'avez pas besoin de reproduire une attaque ni de configurer ces identifiants ici. Votre tâche consiste à installer le correctif compatible fourni et à préserver les requêtes ordinaires.
La commande se termine intentionnellement avec le code 1 lorsqu'elle trouve un problème connu. Un CHECK ERROR signifie que l'analyse n'a pas pu se terminer et produit le code 2 ; ce n'est pas une preuve de sécurité. Une évaluation de gravité aide à hiérarchiser l'examen, mais ne montre pas que cette application a déjà été exploitée.
Le rapport donne une version corrigée. Vous relierez ensuite ce rapport aux fichiers utilisés pour l'installation et la reproductibilité.
Distinguer les versions requises de l'état installé
Dans cette étape, vous lirez la liste d'installation aux versions fixées et l'enregistrement de l'environnement résolu.
cat requirements.txt
Chaque ligne a la forme package==version. Le double signe égal fixe ce paquet à une version précise. La liste de ce cours comprend à la fois la dépendance directe et ses paquets de support résolus, afin de pouvoir reproduire l'installation hors ligne.
Requests est fixé à 2.32.3. L'analyse a indiqué 2.32.4 comme correctif compatible disponible dans le cache. Conservez toutes les lignes sans lien avec cette correction.
cat requirements.lock
Un enregistrement de verrouillage décrit les versions exactes des paquets résolus. Ici, il s'agit d'un simple fichier au format requirements dont toutes les versions sont fixées. Il correspond initialement à la liste d'installation. Après la mise à jour, vous le régénérerez à partir de l'environnement réel, au lieu de prétendre qu'un paquet a changé simplement en modifiant du texte.
Il existe trois états distincts : les versions prévues dans requirements.txt, les paquets réels dans .venv et l'enregistrement résolu dans requirements.lock. Tous doivent correspondre au moment de la livraison. Le scanner lit le fichier que vous indiquez ; il ne prouve pas automatiquement qu'une application en cours d'exécution importe ces versions.
Le cache sous /opt/labex-dependency-tools/wheels contient les paquets initiaux et corrigés préparés. Vous installerez les paquets depuis ce cache : aucune recherche de version en ligne ni résolution de conflit de dépendances n'est donc nécessaire.
Installer la version corrigée compatible
Dans cette étape, vous mettrez à jour la liste d'installation et installerez le paquet corrigé dans l'environnement réel du projet.
nano requirements.txt
Remplacez uniquement requests==2.32.3 par requests==2.32.4. Conservez toutes les autres versions fixées. Enregistrez avec Ctrl+O, Enter, Ctrl+X.
Utilisez maintenant le gestionnaire de paquets du même environnement. install modifie les paquets installés ; -r requirements.txt lit la liste d'installation indiquée. --no-index désactive les index de paquets en ligne et --find-links indique à pip les fichiers wheel préparés. Un wheel est un paquet d'installation Python préconstruit :
.venv/bin/python -m pip install --no-index --find-links /opt/labex-dependency-tools/wheels -r requirements.txt
Pip doit remplacer Requests 2.32.3 par 2.32.4, tandis que les paquets aux versions fixées sans lien avec la correction restent satisfaits. Vérifiez le changement de version nommé ; les messages de progression peuvent différer. N'exécutez pas le simple pip système, car cela pourrait mettre à jour un autre environnement.
.venv/bin/python -m pip show requests
Le résultat attendu est Version: 2.32.4 et un emplacement dans le répertoire .venv de ce projet. Enregistrer uniquement la liste ne suffirait pas à établir cet état installé. Le client est un programme ponctuel qui importe ses paquets à chaque exécution ; les requêtes suivantes utiliseront donc l'environnement mis à jour.
Régénérer l'enregistrement de verrouillage
Dans cette étape, vous ferez décrire à l'enregistrement résolu les paquets réellement installés.
pip freeze affiche les versions fixées des paquets installés dans l'environnement. L'opérateur de shell > écrit cette sortie dans un fichier au lieu du terminal, en remplaçant le contenu précédent du fichier. Ici, la destination est précisément l'enregistrement de verrouillage du projet :
.venv/bin/python -m pip freeze > requirements.lock
La commande n'affiche normalement rien, car sa sortie est allée dans le fichier. Lisez-le :
cat requirements.lock
Requests doit maintenant être en version 2.32.4 ; les versions des autres dépendances doivent rester identiques. L'ordre ou la casse peuvent varier sans changer les paquets enregistrés.
Vérifiez la compatibilité des paquets avec pip check, qui contrôle les relations de dépendances déclarées :
.venv/bin/python -m pip check
Le message attendu est No broken requirements found. Cela vérifie la compatibilité des paquets, pas le comportement métier de l'application ni toutes les vulnérabilités possibles.
Vous avez maintenant une intention d'installation, des paquets installés et un enregistrement résolu cohérents. Le fichier de verrouillage est un véritable élément de reproductibilité, pas un rapport copié prouvant qu'une commande a été exécutée. Une méthode équivalente valide produisant les mêmes versions fixées exactes satisfait aussi le résultat attendu.
Exécuter la vérification de non-régression fonctionnelle
Dans cette étape, vous confirmerez que la mise à jour de la bibliothèque a préservé la requête et la réponse d'origine.
Une régression est un comportement auparavant fonctionnel qu'une modification a cassé. Le cours fournit test.sh, une petite vérification fonctionnelle du client d'origine. Vous apprenez à exécuter cette vérification ; l'écriture de tests viendra plus tard.
bash test.sh
Résultat attendu :
PASS: original ticket request and response.
La vérification exécute réellement le client contre le service de tickets local et compare les données renvoyées. Elle ne considère pas qu'une chaîne de version modifiée suffit à démontrer une réussite métier.
Exécutez vous-même le client une nouvelle fois :
.venv/bin/python app.py
Le ticket d'origine avec l'ID 1 et le titre Printer offline est attendu. Ni supprimer le client ni retirer sa dépendance ne préserverait ce comportement.
La bibliothèque est mise à jour sur disque et ce client nouvellement lancé l'importe. Les applications qui restent longtemps en fonctionnement peuvent nécessiter leur propre redémarrage contrôlé après une mise à jour des dépendances ; le client de ce lab repart à neuf à chaque exécution. La dernière étape revérifie le problème connu à l'aide de l'enregistrement de verrouillage exact.
Réanalyser l'état des dépendances livré
Dans cette étape, vous combinerez l'analyse sur l'instantané fixe avec les preuves des paquets installés et du comportement métier.
Exécutez le même scanner hors ligne sur l'enregistrement de verrouillage mis à jour :
course-deps requirements.lock
Le message attendu est No findings in the selected course snapshot. Cela signifie précisément que les avis sélectionnés ne correspondent plus aux versions enregistrées. Cela ne démontre pas que l'instantané couvre tous les problèmes présents ou futurs.
Examinez la version fixée prévue et le paquet réellement installé :
cat requirements.txt
.venv/bin/python -m pip show requests
Requests doit être en version 2.32.4 dans le fichier et dans l'environnement ; les versions fixées sans lien avec la correction sont conservées. La vérification fonctionnelle de l'étape précédente prouve une exigence différente : le client mis à jour effectue toujours sa requête d'origine.
Une correction complète nécessite les deux types de preuves. Modifier uniquement un manifeste pourrait laisser l'installation vulnérable en service. Mettre à jour une installation sans l'enregistrer rendrait sa reproduction ultérieure peu fiable. Ignorer un scanner ou supprimer la dépendance masquerait les preuves au lieu de corriger l'application requise.
Aucun document d'investigation ni rapport de scanner copié n'est requis. Vos livrables sont l'environnement de paquets réellement mis à jour, les enregistrements exacts des versions fixées et le comportement métier préservé.
Résumé
Vous avez relié un avis hors ligne à une véritable dépendance Python installée, installé un paquet corrigé compatible depuis le cache préparé et synchronisé les enregistrements des versions prévues et résolues. Une nouvelle analyse et une véritable requête fonctionnelle ont confirmé la correction ciblée et le comportement préservé dans le périmètre explicite de l'instantané du cours.
