Mantenha o software durante toda a sua vida útil

Defina um responsável pela manutenção do serviço

Software útil continua mudando depois do primeiro release. Dependências recebem correções. Runtimes perdem suporte. Certificados expiram. Regras de negócio mudam. Acessos concedidos durante a configuração podem durar mais que o planejado.

Mantenha um inventário de serviços, responsáveis, versões implantadas, dependências e prazos de suporte. Inclua trabalho agendado e trabalho provocado por novos achados. Reserve capacidade para ambos. Um backlog de manutenção sem responsável não protege o serviço.

Separe manutenção de resposta imediata a incidentes. Uma credencial exposta ou evidências de comprometimento ativo podem exigir contenção antes de terminar um ciclo comum de desenvolvimento. Encaminhe esses casos ao processo de resposta de segurança.

Priorize a exposição real

A severidade descreve consequências potenciais. A prioridade também depende de exploração, possibilidade de execução do código vulnerável, dados, controles existentes e custo do atraso. Um serviço interno com pouco tráfego ainda pode conter credenciais importantes.

O catálogo Known Exploited Vulnerabilities da CISA registra vulnerabilidades com evidências de exploração. Use-o como uma entrada para priorização. A ausência no catálogo não prova que uma vulnerabilidade seja segura. Catálogo da CISA.

Considere estes achados fictícios. Os prazos pertencem à organização do exemplo; não são prazos universais.

Não transforme automaticamente todo achado em uma grande atualização. Escolha uma correção suportada, inspecione a compatibilidade e teste o comportamento importante. Registre mitigações temporárias com responsável e condição de validade.

Acompanhe a correção até a produção

Use uma sequência rastreável: achado, decisão, alteração, revisão, deployment e verificação. Registre o identificador do artefato que a produção realmente usa. Faça novo escaneamento do artefato ou ambiente relevante após a alteração.

Para um pacote fictício de PDF vulnerável, uma equipe faz o merge de uma atualização às 10:00. Às 11:00, a produção ainda executa a imagem de ontem. A correção no repositório está completa. A correção em produção está incompleta.

Após o deployment, verifique a versão do pacote e a geração de PDFs. Um escaneamento de vulnerabilidades não comprova que a exportação continua funcionando. Um teste funcional não comprova que o componente vulnerável foi removido.

O SSDF do NIST inclui identificação e resposta contínuas a vulnerabilidades. Aplique essas práticas ao longo do ciclo de vida, inclusive a software que recebe poucos pedidos de novas funcionalidades. NIST SSDF.

Use automação com limites visíveis

O Maintaining da Taiga escaneia repositórios vinculados e pode transformar achados em iniciativas de correção. Verifique a varredura bem-sucedida mais recente, a versão afetada e a alteração resultante. Escanear o repositório não comprova se o código vulnerável pode ser executado em produção. Maintaining.

A automação pode reduzir trabalho repetido, mas o serviço ainda precisa de responsáveis pelo deployment e pela verificação. Mantenha explícitas as decisões de release, o acesso emergencial e a validade das exceções.

A manutenção também inclui desativação. Remova rotas, credenciais, integrações e infraestrutura sem uso por um processo controlado. Verifique requisitos de retenção e serviços dependentes antes de excluir. Desative o serviço em execução e atribua quaisquer obrigações restantes de retenção ou auditoria.

A próxima lição aborda em detalhe o escaneamento e a correção contínuos de vulnerabilidades.