Manter o software durante toda a sua vida útil

Atribua a manutenção a um responsável pelo serviço

O software útil continua a mudar depois do primeiro lançamento. As dependências recebem correções. Os runtimes deixam de ter suporte. Os certificados expiram. As regras de negócio mudam. O acesso concedido durante a configuração pode durar mais do que o previsto.

Mantenha um inventário de serviços, responsáveis, versões instaladas, dependências e datas de fim de suporte. Inclua trabalho agendado e trabalho desencadeado por uma nova ocorrência. Reserve capacidade para ambos. Um backlog de manutenção sem responsável não protege o serviço.

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

Dê prioridade à exposição real

A gravidade descreve as consequências potenciais. A prioridade também depende da exploração, da possibilidade de executar o código vulnerável, dos dados, dos controlos existentes e do custo do atraso. Um serviço interno com pouco tráfego pode ainda guardar credenciais importantes.

O catálogo Known Exploited Vulnerabilities da CISA regista vulnerabilidades com evidências de exploração. Use-o como um dos elementos da priorização. Se uma vulnerabilidade não constar desse catálogo, isso não prova que seja segura. Catálogo da CISA.

Considere estas ocorrências fictícias. Os prazos pertencem à organização do exemplo; não são prazos universais.

Não transforme automaticamente cada ocorrência numa grande atualização. Escolha uma correção suportada, examine a compatibilidade e teste o comportamento relevante. Registe mitigações temporárias com um responsável e uma condição de expiração.

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

Use uma sequência rastreável: ocorrência, decisão, alteração, revisão, deployment e verificação. Registe o identificador do artefacto que a produção realmente utiliza. Volte a analisar o artefacto ou ambiente relevante depois da alteração.

Num exemplo fictício com um pacote PDF vulnerável, uma equipa faz 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á concluída. A remediação em produção está incompleta.

Após o deployment, verifique a versão do pacote e a geração de PDFs. Um scan de vulnerabilidades não permite determinar se o export continua a funcionar. Um teste funcional não permite determinar se o componente vulnerável foi removido.

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

Use automação com limites visíveis

O Taiga Maintaining analisa repositórios ligados e pode transformar as ocorrências em iniciativas de remediação. Verifique a última análise bem-sucedida, a versão afetada e a alteração resultante. A análise do repositório não permite determinar se o código vulnerável pode ser executado em produção. Maintaining.

A automação pode reduzir trabalho repetitivo, mas o serviço continua a precisar de um responsável pelo deployment e de verificação. Explicite as decisões de lançamento, o acesso de emergência e a expiração das exceções.

A manutenção também inclui a descontinuação. Remova rotas, credenciais, integrações e infraestrutura sem utilização através de um processo controlado. Verifique os requisitos de retenção e os serviços dependentes antes de apagar. 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 a análise contínua de vulnerabilidades e a remediação.