Einführung
Anwendungen hängen von Bibliotheken ab, die andere Projekte entwickeln. Eine nützliche Bibliothek kann eine bekannte Schwachstelle haben, auch wenn dein eigenes Programm scheinbar funktioniert. Dieser DeskLite-Ticketclient verwendet eine betroffene Version der Python-HTTP-Bibliothek Requests.
Du liest eine festgelegte Offline-Sicherheitsmeldung, aktualisierst das Paket, das der Client tatsächlich importiert, und prüfst Funktionalität und Versionsaufzeichnungen gemeinsam. Die isolierte Python-Umgebung, der Installationscache und der Kurs-Snapshot mit zwei Sicherheitsmeldungen sind vorbereitet. Erfahrung mit Paketverwaltung oder Python-Programmierung wird nicht vorausgesetzt.
Den Client ausführen und sein Paket untersuchen
In diesem Schritt stellst du das aktuelle Geschäftsverhalten des Clients fest und findest seine installierte Abhängigkeit.
Eine Abhängigkeit ist Software, die deine Anwendung verwendet. Dieser Client verwendet direkt requests, um HTTP-Anfragen zu stellen; Requests selbst verwendet für Teile dieser Arbeit eine weitere Bibliothek, urllib3. Diese zweite Beziehung ist eine transitive Abhängigkeit.
cd /home/labex/project/desklite-dependencies
.venv/bin/python ist die vorbereitete, isolierte Python-Programmdatei für dieses Projekt. Ihre Pakete sind vom System-Python getrennt. Weder ein Aktivierungsbefehl noch eine globale Installation ist nötig. Führe den bereitgestellten Client so aus, wie du im Git-Lab ein bereitgestelltes Programm ausgeführt hast:
.venv/bin/python app.py
Erwartet wird das ursprüngliche Ticket mit dem Titel Printer offline. Das Programm funktioniert bereits vor der Sicherheitskorrektur; ein bekanntes Problem in einer Abhängigkeit bedeutet nicht, dass schon jede Anfrage fehlschlägt.
pip verwaltet Python-Pakete. -m pip weist genau dieses isolierte Python an, seinen Paketmanager auszuführen, während show Metadaten liest, ohne etwas zu verändern:
.venv/bin/python -m pip show requests urllib3
Suche nach Name, Version und Location. Requests sollte 2.32.3, urllib3 2.2.2 sein, und die Paketpfade sollten innerhalb der .venv dieses Projekts liegen. Wir aktualisieren diese Umgebung, keine andere Python-Installation.
Den Fund aus der Offline-Sicherheitsmeldung lesen
In diesem Schritt ordnest du einen Scannerfund der Paketversion zu, die Aufmerksamkeit benötigt.
Der vorbereitete Starter course-deps führt OSV-Scanner 2.7.0 mit einem festen lokalen Snapshot vom 2026-10-28 aus. Dieser bewusst kleine Snapshot enthält zwei ausgewählte Sicherheitsmeldungen für Requests und urllib3; er ist ein vorbereiteter Lerndatensatz, nicht der vollständige aktuelle Schwachstellenfeed für den Produktivbetrieb. Der Befehl sendet keine Netzwerkanfrage.
Übergib ihm die vorbereitete Lock-Aufzeichnung:
course-deps requirements.lock
Erwartet wird eine Zeile mit requests 2.32.3, GHSA-9hjg-9r4m-mvj7, CVE-2024-47081 und fixed: 2.32.4, gefolgt von Security findings: 1. Die beiden IDs bezeichnen dasselbe zugrunde liegende Problem in unterschiedlichen Meldesystemen.
Diese Sicherheitsmeldung betrifft einen möglichen Abfluss von Zugangsdaten, wenn bestimmte speziell präparierte URLs mit gespeicherten Clientzugangsdaten zusammenwirken. Du musst hier weder einen Angriff nachstellen noch solche Zugangsdaten konfigurieren. Deine Aufgabe ist es, die bereitgestellte kompatible Korrektur zu installieren und normale Anfragen zu erhalten.
Der Befehl endet absichtlich mit 1, wenn er ein bekanntes Problem findet. Ein CHECK ERROR bedeutet, dass die Prüfung nicht abgeschlossen werden konnte, und führt zum Exit-Status 2; dies ist kein Sicherheitsnachweis. Eine Schweregradeinstufung hilft bei der Priorisierung der Untersuchung, zeigt aber nicht, dass eine Schwachstelle dieser Anwendung bereits ausgenutzt wurde.
Der Bericht nennt eine korrigierte Version. Als Nächstes ordnest du den Bericht den Dateien zu, die für Installation und Reproduzierbarkeit verwendet werden.
Anforderungen vom installierten Zustand unterscheiden
In diesem Schritt liest du die Installationsliste mit festgelegten Versionen und die Aufzeichnung der aufgelösten Umgebung.
cat requirements.txt
Jede Zeile hat die Form package==version. Die doppelten Gleichheitszeichen fixieren dieses Paket auf eine Version. Die Liste dieses Kurses enthält sowohl die direkte Abhängigkeit als auch ihre aufgelösten unterstützenden Pakete, damit die Installation offline reproduziert werden kann.
Requests ist auf 2.32.3 festgelegt. Die Prüfung hat 2.32.4 als kompatible, im Cache verfügbare Korrektur gemeldet. Behalte alle nicht betroffenen Zeilen bei.
cat requirements.lock
Eine Lock-Aufzeichnung beschreibt die exakten aufgelösten Paketversionen. Hier ist sie eine einfache Datei im Requirements-Format, in der alle Versionen festgelegt sind. Anfangs stimmt sie mit der Installationsliste überein. Nach der Aktualisierung erzeugst du sie erneut aus der tatsächlichen Umgebung, statt allein durch das Bearbeiten von Text zu behaupten, ein Paket habe sich geändert.
Es gibt drei unterschiedliche Zustände: die vorgesehenen Versionen in requirements.txt, die tatsächlichen Pakete innerhalb von .venv und die aufgelöste Aufzeichnung in requirements.lock. Bei der Auslieferung müssen alle übereinstimmen. Der Scanner liest die von dir benannte Datei; er beweist nicht automatisch, dass eine laufende Anwendung diese Versionen importiert.
Der Cache unter /opt/labex-dependency-tools/wheels enthält die vorbereiteten ursprünglichen und korrigierten Pakete. Du installierst aus diesem Cache, sodass weder eine Online-Versionssuche noch das Lösen von Abhängigkeitskonflikten erforderlich ist.
Die kompatible korrigierte Version installieren
In diesem Schritt aktualisierst du die Installationsliste und installierst das korrigierte Paket in der tatsächlichen Projektumgebung.
nano requirements.txt
Ändere ausschließlich requests==2.32.3 zu requests==2.32.4. Behalte jede andere Versionsfestlegung bei. Speichere mit Ctrl+O, Enter, Ctrl+X.
Verwende jetzt den Paketmanager derselben Umgebung. install ändert installierte Pakete; -r requirements.txt liest die benannte Installationsliste. --no-index deaktiviert Online-Paketindizes, und --find-links verweist pip auf die vorbereiteten Wheel-Dateien. Ein Wheel ist ein vorgefertigtes Python-Installationspaket:
.venv/bin/python -m pip install --no-index --find-links /opt/labex-dependency-tools/wheels -r requirements.txt
Pip sollte Requests 2.32.3 durch 2.32.4 ersetzen, während die nicht betroffenen festgelegten Pakete weiterhin die Anforderungen erfüllen. Beurteile den genannten Versionswechsel; Fortschrittsmeldungen können abweichen. Führe kein einfaches System-pip aus, da dies eine andere Umgebung aktualisieren könnte.
.venv/bin/python -m pip show requests
Erwartet werden Version: 2.32.4 und ein Pfad innerhalb der .venv dieses Projekts. Das bloße Speichern der Liste würde diesen installierten Zustand nicht nachweisen. Der Client ist ein einmalig laufendes Programm, das seine Pakete bei jedem Lauf importiert. Spätere Anfragen verwenden daher die aktualisierte Umgebung.
Die Lock-Aufzeichnung neu erzeugen
In diesem Schritt sorgst du dafür, dass die aufgelöste Versionsaufzeichnung die tatsächlich installierten Pakete beschreibt.
pip freeze gibt die Versionsfestlegungen der in der Umgebung installierten Pakete aus. Der Shell-Operator > schreibt diese Ausgabe in eine Datei statt ins Terminal und ersetzt dabei den vorherigen Dateiinhalt. Das Ziel ist hier ausdrücklich die Lock-Aufzeichnung des Projekts:
.venv/bin/python -m pip freeze > requirements.lock
Der Befehl gibt normalerweise nichts aus, weil seine Ausgabe in die Datei geschrieben wurde. Lies sie:
cat requirements.lock
Requests sollte jetzt 2.32.4 sein; die anderen Abhängigkeitsversionen sollten gleich bleiben. Reihenfolge oder Groß-/Kleinschreibung können variieren, ohne zu ändern, welche Pakete aufgezeichnet sind.
Prüfe die Paketkompatibilität mit pip check. Dieser Befehl prüft die deklarierten Abhängigkeitsbeziehungen:
.venv/bin/python -m pip check
Erwartet wird No broken requirements found. Dies prüft die Paketkompatibilität, nicht das Geschäftsverhalten der Anwendung oder jede mögliche Schwachstelle.
Du hast jetzt eine konsistente Installationsabsicht, installierte Pakete und eine aufgelöste Aufzeichnung. Die Lock-Datei ist ein echtes Artefakt zur Reproduzierbarkeit, kein kopierter Bericht als Nachweis für die Ausführung eines Befehls. Eine gültige gleichwertige Methode, die dieselben korrekten Versionsfestlegungen erzeugt, erfüllt das Ziel ebenfalls.
Die funktionale Regressionsprüfung ausführen
In diesem Schritt bestätigst du, dass die Aktualisierung der Bibliothek die ursprüngliche Anfrage und Antwort erhalten hat.
Eine Regression ist zuvor funktionierendes Verhalten, das durch eine Änderung beschädigt wird. Der Kurs stellt test.sh bereit, eine kleine Funktionsprüfung für den ursprünglichen Client. Du lernst, diese Prüfung auszuführen; das Schreiben von Tests kommt später.
bash test.sh
Erwartet wird:
PASS: original ticket request and response.
Die Prüfung führt den Client tatsächlich gegen den lokalen Ticketdienst aus und vergleicht die zurückgegebenen Daten. Sie wertet eine geänderte Versionszeichenfolge nicht als geschäftlichen Erfolg.
Führe den Client selbst noch einmal aus:
.venv/bin/python app.py
Erwartet wird das ursprüngliche Ticket mit der ID 1 und dem Titel Printer offline. Weder das Löschen des Clients noch das Entfernen seiner Abhängigkeit würde dieses Verhalten erhalten.
Die Bibliothek ist auf dem Datenträger aktualisiert, und dieser neu gestartete Client importiert sie. Dauerhaft laufende Anwendungen können nach Abhängigkeitsaktualisierungen einen eigenen kontrollierten Neustart benötigen; der Client dieses Labs läuft jedes Mal neu. Im letzten Schritt prüfst du das bekannte Problem erneut mit der korrekten Lock-Aufzeichnung.
Den ausgelieferten Abhängigkeitszustand erneut prüfen
In diesem Schritt kombinierst du die Prüfung mit festem Snapshot mit Nachweisen zu den installierten Paketen und zur Geschäftsfunktion.
Führe denselben Offline-Scanner für die aktualisierte Lock-Aufzeichnung aus:
course-deps requirements.lock
Erwartet wird No findings in the selected course snapshot. Das bedeutet konkret, dass die ausgewählten Sicherheitsmeldungen nicht mehr auf die aufgezeichneten Versionen zutreffen. Es weist nicht nach, dass der Snapshot jedes gegenwärtige oder zukünftige Problem abdeckt.
Prüfe die vorgesehene Versionsfestlegung und das tatsächlich installierte Paket:
cat requirements.txt
.venv/bin/python -m pip show requests
Requests sollte in der Datei und in der Umgebung 2.32.4 sein; nicht betroffene Versionsfestlegungen bleiben erhalten. Die Funktionsprüfung aus dem vorherigen Schritt weist eine andere Anforderung nach: Der aktualisierte Client führt weiterhin seine ursprüngliche Anfrage aus.
Eine vollständige Korrektur benötigt beide Arten von Nachweisen. Das bloße Bearbeiten eines Manifests könnte die verwundbare Installation weiter in Verwendung lassen. Eine Installation zu aktualisieren, ohne dies aufzuzeichnen, würde die spätere Reproduktion unzuverlässig machen. Einen Scanner zu überspringen oder die Abhängigkeit zu löschen würde Nachweise verbergen, statt die erforderliche Anwendung zu korrigieren.
Ein Untersuchungsdokument oder ein kopierter Scannerbericht ist nicht erforderlich. Deine Liefergegenstände sind die tatsächlich aktualisierte Paketumgebung, korrekte Aufzeichnungen mit festgelegten Versionen und das erhaltene Geschäftsverhalten.
Zusammenfassung
Du hast eine Offline-Sicherheitsmeldung einer tatsächlich installierten Python-Abhängigkeit zugeordnet, ein kompatibles korrigiertes Paket aus dem vorbereiteten Cache installiert und die vorgesehenen und aufgelösten Versionsaufzeichnungen synchronisiert. Eine erneute Prüfung und eine echte funktionale Anfrage bestätigten die gezielte Korrektur und das erhaltene Verhalten innerhalb des ausdrücklich festgelegten Umfangs des Kurs-Snapshots.
