Introdução
Aplicativos dependem de bibliotecas escritas por outros projetos. Uma biblioteca útil pode ter uma falha conhecida mesmo quando seu próprio programa parece funcionar. Este cliente de tickets do DeskLite usa uma versão afetada da biblioteca HTTP Requests para Python.
Você interpretará um aviso de segurança offline fixo, atualizará o pacote que o cliente realmente importa e verificará a funcionalidade e os registros de versões em conjunto. O ambiente Python isolado, o cache de instalação e o snapshot do curso com dois avisos de segurança estão preparados. Não é necessário ter experiência com gerenciamento de pacotes nem programação Python.
Execute o cliente e inspecione seu pacote
Nesta etapa, você verificará o comportamento de negócio atual do cliente e localizará sua dependência instalada.
Uma dependência é um software usado pelo seu aplicativo. Este cliente usa diretamente requests para fazer requisições HTTP; o próprio Requests usa outra biblioteca, urllib3, para partes desse trabalho. Essa segunda relação é uma dependência transitiva.
cd /home/labex/project/desklite-dependencies
.venv/bin/python é o executável Python isolado preparado para este projeto. Seus pacotes são separados dos pacotes do Python do sistema. Não é necessário executar um comando de ativação nem fazer uma instalação global. Execute o cliente fornecido como executou um programa fornecido no laboratório de Git:
.venv/bin/python app.py
Espere o ticket original com o título Printer offline. O programa funciona antes da correção de segurança; um problema conhecido em uma dependência não significa que todas as requisições já falhem.
pip gerencia pacotes Python. -m pip instrui este mesmo Python isolado a executar seu gerenciador de pacotes, enquanto show lê metadados sem alterar nada:
.venv/bin/python -m pip show requests urllib3
Localize Name, Version e Location. O Requests deve estar na versão 2.32.3, o urllib3 na 2.2.2, e as localizações dos pacotes devem estar dentro da .venv deste projeto. Atualizaremos este ambiente, não outra instalação de Python.
Interprete a detecção do aviso de segurança offline
Nesta etapa, você relacionará uma detecção do scanner à versão do pacote que precisa de atenção.
O inicializador preparado course-deps executa o OSV-Scanner 2.7.0 com um snapshot local fixo datado de 2026-10-28. Este snapshot intencionalmente pequeno contém dois avisos de segurança selecionados para Requests e urllib3; é um recurso de aprendizagem, não a base completa e atual de vulnerabilidades de produção. O comando não faz requisições de rede.
Informe a ele o registro de versões resolvidas preparado:
course-deps requirements.lock
Espere uma linha contendo requests 2.32.3, GHSA-9hjg-9r4m-mvj7, CVE-2024-47081 e fixed: 2.32.4, seguida de Security findings: 1. Os dois IDs identificam o mesmo problema subjacente em sistemas diferentes de avisos de segurança.
Este aviso trata de um possível vazamento de credenciais quando determinadas URLs especialmente criadas interagem com credenciais armazenadas do cliente. Você não precisa reproduzir um ataque nem configurar essas credenciais aqui. Sua tarefa é instalar a correção compatível fornecida e preservar as requisições normais.
O comando termina intencionalmente com 1 quando encontra um problema conhecido. Um CHECK ERROR significa que a varredura não pôde ser concluída e termina com 2; isso não é evidência de segurança. Uma classificação de severidade ajuda a priorizar a análise, mas não demonstra que este aplicativo já foi explorado.
O relatório informa uma versão corrigida. A seguir, você relacionará esse relatório aos arquivos usados para instalação e reprodutibilidade.
Diferencie os requisitos do estado instalado
Nesta etapa, você lerá a lista de instalação com versões fixadas e o registro do ambiente resolvido.
cat requirements.txt
Cada linha tem a forma package==version. Os dois sinais de igual fixam esse pacote em uma versão. A lista deste curso inclui tanto a dependência direta quanto seus pacotes de suporte resolvidos para que a instalação possa ser reproduzida offline.
O Requests está fixado em 2.32.3. A varredura informou 2.32.4 como a correção compatível disponível no cache. Preserve todas as linhas não relacionadas.
cat requirements.lock
Um registro de versões resolvidas descreve as versões exatas dos pacotes após a resolução das dependências. Aqui, ele é um arquivo simples no formato de requisitos, com todas as versões fixadas. Inicialmente, ele corresponde à lista de instalação. Após a atualização, você o gerará novamente a partir do ambiente real, em vez de afirmar que um pacote mudou apenas por editar texto.
Existem três estados distintos: as versões pretendidas em requirements.txt, os pacotes reais dentro de .venv e o registro resolvido em requirements.lock. Todos devem corresponder na entrega. O scanner lê o arquivo que você indicar; ele não comprova automaticamente que um aplicativo em execução importa essas versões.
O cache em /opt/labex-dependency-tools/wheels contém os pacotes iniciais e corrigidos preparados. Você instalará a partir desse cache, portanto não será necessário pesquisar versões online nem resolver conflitos de dependências.
Instale a versão corrigida compatível
Nesta etapa, você atualizará a lista de instalação e instalará o pacote corrigido no ambiente real do projeto.
nano requirements.txt
Altere apenas requests==2.32.3 para requests==2.32.4. Preserve todas as outras versões fixadas. Salve com Ctrl+O, Enter, Ctrl+X.
Agora use o gerenciador de pacotes do mesmo ambiente. install altera os pacotes instalados; -r requirements.txt lê a lista de instalação indicada. --no-index desativa os índices de pacotes online, e --find-links aponta o pip para os arquivos wheel preparados. Um wheel é um pacote de instalação Python pré-construído:
.venv/bin/python -m pip install --no-index --find-links /opt/labex-dependency-tools/wheels -r requirements.txt
O pip deve substituir o Requests 2.32.3 por 2.32.4, enquanto os pacotes não relacionados continuam atendendo às versões fixadas. Avalie a mudança da versão indicada; as mensagens de progresso podem variar. Não execute simplesmente o pip do sistema, pois isso poderia atualizar outro ambiente.
.venv/bin/python -m pip show requests
Espere Version: 2.32.4 e uma localização dentro da .venv deste projeto. Apenas salvar a lista não comprovaria esse estado instalado. O cliente é um programa de execução única que importa seus pacotes a cada execução, portanto as requisições posteriores usarão o ambiente atualizado.
Gere novamente o registro de versões resolvidas
Nesta etapa, você fará o registro de versões resolvidas descrever os pacotes realmente instalados.
pip freeze imprime as versões fixadas dos pacotes instalados no ambiente. O operador do shell > grava essa saída em um arquivo em vez de exibi-la no terminal, substituindo o conteúdo anterior do arquivo. Aqui, o destino é especificamente o registro de versões resolvidas do projeto:
.venv/bin/python -m pip freeze > requirements.lock
Normalmente, o comando não imprime nada porque sua saída foi para o arquivo. Leia-o:
cat requirements.lock
O Requests agora deve estar na versão 2.32.4; as versões das outras dependências devem permanecer iguais. A ordem ou o uso de maiúsculas e minúsculas pode variar sem alterar quais pacotes estão registrados.
Verifique a compatibilidade dos pacotes com pip check, que verifica as relações de dependência declaradas:
.venv/bin/python -m pip check
Espere No broken requirements found. Isso verifica a compatibilidade dos pacotes, não o comportamento de negócio do aplicativo nem todas as vulnerabilidades possíveis.
Agora, a intenção de instalação, os pacotes instalados e o registro resolvido são coerentes entre si. O arquivo de versões resolvidas é um artefato real de reprodutibilidade, não um relatório copiado para comprovar que um comando foi executado. Um método equivalente válido que produza as mesmas versões fixadas corretas também atende ao resultado.
Execute a verificação de regressão funcional
Nesta etapa, você confirmará que atualizar a biblioteca preservou a requisição e a resposta originais.
Uma regressão é um comportamento que antes funcionava e que uma alteração interrompe. O curso fornece test.sh, uma pequena verificação funcional do cliente original. Você está aprendendo a executar essa verificação; a criação de testes virá depois.
bash test.sh
Espere:
PASS: original ticket request and response.
A verificação realmente executa o cliente contra o serviço local de tickets e compara os dados retornados. Ela não considera uma string de versão alterada como sucesso de negócio.
Execute o cliente por conta própria mais uma vez:
.venv/bin/python app.py
Espere o ticket original com ID 1 e título Printer offline. Excluir o cliente ou remover sua dependência não preservaria esse comportamento.
A biblioteca está atualizada no disco, e este cliente recém-iniciado a importa. Aplicativos de longa duração podem precisar de sua própria reinicialização controlada após atualizações de dependências; o cliente deste laboratório inicia uma nova execução a cada vez. A etapa final verifica novamente o problema conhecido usando o registro correto de versões resolvidas.
Examine novamente o estado das dependências entregues
Nesta etapa, você combinará a varredura com snapshot fixo com as evidências dos pacotes instalados e do comportamento de negócio.
Execute o mesmo scanner offline no registro de versões resolvidas atualizado:
course-deps requirements.lock
Espere No findings in the selected course snapshot. Isso significa especificamente que os avisos de segurança selecionados não correspondem mais às versões registradas. Não comprova que o snapshot abranja todos os problemas presentes ou futuros.
Revise a versão fixada pretendida e o pacote realmente instalado:
cat requirements.txt
.venv/bin/python -m pip show requests
O Requests deve estar na versão 2.32.4 no arquivo e no ambiente; as versões fixadas não relacionadas permanecem. A verificação funcional da etapa anterior comprova um requisito diferente: o cliente atualizado ainda realiza sua requisição original.
Uma correção completa precisa dos dois tipos de evidência. Editar apenas um manifesto poderia deixar a instalação vulnerável em uso. Atualizar uma instalação sem registrá-la tornaria a reprodução posterior pouco confiável. Pular um scanner ou excluir a dependência ocultaria evidências em vez de corrigir o aplicativo exigido.
Não é necessário criar um documento de investigação nem copiar um relatório do scanner. Suas entregas são o ambiente de pacotes realmente atualizado, os registros corretos de versões fixadas e o comportamento de negócio preservado.
Resumo
Você relacionou um aviso de segurança offline a uma dependência Python realmente instalada, instalou um pacote corrigido compatível a partir do cache preparado e sincronizou os registros das versões pretendidas e resolvidas. Uma nova varredura e uma requisição funcional real confirmaram a correção específica e preservaram o comportamento dentro do escopo explícito do snapshot do curso.
