Protecção, Detecção e Resposta

Duração prevista: 120 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 35 minutos.
• Trabalho prático: 60 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Situar, no diagrama de cadeia de entrega fornecido, em que ponto entra cada tipo de verificação automática e o que cada uma detecta e não detecta.
• Definir critérios de bloqueio e de aviso para uma cadeia de entrega, distinguindo o que interrompe a entrega do que apenas gera registo, com justificação.
• Analisar o relatório fictício de dependências e decidir, para cada componente, entre actualizar, substituir, mitigar ou aceitar com prazo.
• Escrever cláusulas de segurança para um caderno de encargos de desenvolvimento externo, incluindo entrega de inventário de componentes e correcção de falhas após a entrega.

Explicação

DevSecOps é a ideia de que a segurança entra no processo de desenvolvimento desde o início, de forma automática e repetível, em vez de aparecer no fim como uma auditoria que atrasa tudo. O motivo é prático: corrigir uma falha na fase de desenho custa pouco; corrigi-la depois de o serviço estar em produção custa muito mais e envolve janelas de manutenção, comunicação e risco.

Há quatro verificações que cobrem a maior parte do terreno. A análise estática lê o código sem o executar e apanha padrões perigosos, como consultas construídas por concatenação de texto. A análise de dependências compara os componentes usados com listas públicas de falhas conhecidas — é a que dá mais retorno imediato, porque a maior parte do código de uma aplicação moderna vem de componentes de terceiros. A varredura de segredos procura chaves e senhas dentro do código. A análise dinâmica testa a aplicação a correr, num ambiente de ensaio, e apanha o que só se vê em execução. Cada uma tem ponto cego: a estática não vê erros de lógica de negócio; a de dependências não vê código próprio; a de segredos não vê segredos bem disfarçados; a dinâmica não vê o que não chega a exercitar.

Uma cadeia de entrega útil distingue bloqueio de aviso. Bloquear tudo paralisa a equipa e leva a que alguém desligue as verificações. Avisar tudo é o mesmo que não verificar. O critério tem de estar escrito e ser defensável: por exemplo, segredo detectado bloqueia sempre; componente com falha grave e com exploração observada bloqueia; falha de gravidade média gera aviso com prazo para tratamento; questão de estilo não bloqueia. Quem define este critério é a instituição, não a ferramenta.

Inventário de componentes é o documento que diz que peças entram no produto e em que versão. Sem ele, quando surge uma falha grave num componente muito usado, a pergunta «nós usamos isso?» fica dias sem resposta — e esses dias são exactamente a janela do atacante. Para software encomendado a terceiros, exigir este inventário na entrega é das cláusulas mais úteis que se podem escrever.

Para instituições que não desenvolvem, quase tudo isto continua a aplicar-se, na forma de exigências contratuais: entrega do inventário de componentes, prazo de correcção de falhas descobertas depois da entrega, direito a fazer teste de segurança antes de entrar em produção, e proibição de entregar com segredos embutidos. São cláusulas de contrato e boas práticas de gestão, não obrigações legais.

Caso fictício: a aplicação de processos e as suas 214 dependências

A aplicação de processos de Muteva foi entregue em 2021. Quando a equipa quis saber que componentes usava, não havia lista. Um levantamento feito à mão encontrou 214 componentes de terceiros, alguns dos quais já não são mantidos por ninguém desde 2019.

Em Agosto de 2026 foi divulgada uma falha grave num componente de tratamento de ficheiros muito comum. A pergunta «usamos este componente?» demorou quatro dias a ser respondida, porque foi preciso abrir a aplicação e procurar.

A resposta acabou por ser sim, em duas versões diferentes, uma delas na parte que recebe anexos dos cidadãos — exactamente a parte exposta.

Anexo A — Relatório de dependências da aplicação de processos (fictício, extracto)

Oito dos 214 componentes. A coluna «Decisão» é preenchida na actividade.

Anexo B — Cadeia de entrega actual da empresa externa (descrição fictícia)

Material de entrada. Descreve o processo tal como a empresa o declarou.

Etapa 1 — A pessoa que programa escreve o código no computador pessoal e envia-o para o repositório partilhado.

Etapa 2 — Não há revisão por outra pessoa; quem envia pode aprovar o seu próprio trabalho.

Etapa 3 — Uma tarefa automática compila o código e corre os testes funcionais. Se falharem, a entrega pára.

Etapa 4 — Não existe análise estática, nem análise de dependências, nem varredura de segredos.

Etapa 5 — A entrega é copiada directamente para o servidor de produção, à sexta-feira à tarde.

Etapa 6 — Não existe ambiente de ensaio; a verificação é feita em produção, depois de instalar.

Trabalho prático

Trabalho em grupos de três pessoas, com os anexos A e B em papel, com 60 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (20 minutos). Redesenhem a cadeia de entrega do anexo B, indicando em que etapa entra cada uma das quatro verificações automáticas e o que cada uma detecta. Marquem também as duas alterações de processo que fariam mesmo sem ferramentas nenhumas.

Passo 2 (20 minutos). Definam a política de bloqueio e aviso: que resultados interrompem a entrega, que resultados apenas registam, e com que prazo os avisos têm de ser tratados. Justifiquem cada limite.

Passo 3 (20 minutos). Decidam, para cada componente do anexo A, entre actualizar, substituir, mitigar ou aceitar com prazo. Para o motor de modelos, que não tem versão corrigida, escrevam a mitigação concreta e o prazo de substituição.

Produto esperado: Diagrama da cadeia de entrega revista, política escrita de bloqueio e aviso, e tabela de decisões para os oito componentes.

Como o produto é apreciado

• As quatro verificações estão colocadas em etapas onde fazem sentido, e não todas no fim.
• Entre as alterações de processo sem ferramentas está a revisão por outra pessoa e o fim da instalação directa em produção à sexta-feira.
• A política bloqueia segredos detectados e falhas graves com exploração observada, e deixa em aviso com prazo as de gravidade média.
• O componente de tratamento de ficheiros e o de compressão são tratados como prioritários por terem exploração observada.
• Para o motor de modelos abandonado há mitigação concreta e prazo de substituição, e não apenas «aceitar o risco».

Síntese em leitura fácil

• Segurança entra no princípio do trabalho, não no fim como auditoria.
• Quatro verificações: código, dependências, segredos e aplicação a correr. Cada uma tem pontos cegos.
• A cadeia distingue o que bloqueia do que apenas avisa. Bloquear tudo faz com que alguém desligue.
• Lista de componentes com versões: sem ela, no dia da falha ninguém sabe se somos afectados.
• Quem não desenvolve exige no contrato: lista de componentes, prazo de correcção e teste antes de entrar em produção.

Verificação formativa

Estas perguntas não contam para a nota final e não são perguntas do exame final. Servem para a pessoa formanda confirmar o que percebeu.

1. A análise de dependências não encontrou nada de grave. Significa que a aplicação não tem falhas graves?
2. O motor de modelos tem falha grave e o projecto foi abandonado, sem versão corrigida. Qual é a decisão defensável?

Respostas comentadas da verificação formativa

As respostas abaixo pertencem às perguntas de verificação formativa desta lição. Não são perguntas nem respostas do exame final e não têm efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. A análise de dependências não encontrou nada de grave. Significa que a aplicação não tem falhas graves?

Resposta: Não. Essa análise só compara os componentes de terceiros com listas de falhas conhecidas. Não vê falhas no código próprio, nem erros de lógica de negócio, nem problemas de configuração ou de controlo de acesso.

Comentário: Cada verificação cobre uma fatia. A leitura conjunta é que dá imagem; nenhuma delas isolada autoriza a conclusão «não há falhas».

Pergunta 2. O motor de modelos tem falha grave e o projecto foi abandonado, sem versão corrigida. Qual é a decisão defensável?

Resposta: Mitigar agora e planear a substituição com prazo: restringir quem pode submeter conteúdo tratado por esse componente, reforçar a validação à entrada, aumentar a vigilância sobre aquela funcionalidade e marcar data para trocar o componente. Aceitar sem prazo não é decisão, é adiamento.

Comentário: Componentes abandonados não melhoram com o tempo, pioram. A aceitação de risco só é séria quando tem prazo e responsável.

Referências consultadas

• CISA Known Exploited Vulnerabilities Catalog — vulnerabilidades exploradas conhecidas — https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Catálogo público de vulnerabilidades com exploração observada no mundo real. Usa-se como entrada para priorizar correcções: uma falha que consta do catálogo sobe na fila. Os prazos que o catálogo indica aplicam-se a organismos federais dos Estados Unidos e não a instituições moçambicanas.
• OWASP Web Security Testing Guide — guia de testes de segurança de aplicações web — https://owasp.org/projects/web-security-testing-guide (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Guia aberto que descreve, por categorias, o que testar numa aplicação web e como registar o que se encontra. Dá estrutura ao teste autorizado e ao relatório; é uma referência comunitária, não uma norma obrigatória.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.