No registo de incidentes no desenvolvimento de software há duas coisas diferentes que frequentemente se confundem: uma vulnerabilidade ou falha no software que constrói e entrega, e um incidente na sua própria linha de desenvolvimento — o ambiente em que fabrica esse software. O que documenta, quem tem de saber e que passo seguinte se segue, varia consoante o tipo. Quem não faz essa distinção muitas vezes perde de vista o incidente que mais importa: uma contaminação na pipeline de construção que se propaga através do código para todos os clientes que o utilizam.
Uma vulnerabilidade no código entregue afecta o cliente directamente: ele executa o software, portanto corre o risco. Um incidente na linha de desenvolvimento — uma chave de acesso roubada, uma conta de construção comprometida, uma fuga no repositório de código-fonte — afecta-o a si em primeiro lugar, mas pode estender-se a qualquer cliente que trabalhe com esse código. Para ambos é verdade que um questionário de segurança ou um auditor não pergunta se algo correu alguma vez mal, mas se consegue demonstrar o que documentou sobre isso e o que aprendeu.
O que documenta num incidente no código
Para uma vulnerabilidade ou falha no software entregue trata-se de: quando foi descoberta, por quem ou o quê (teste interno, comunicação de cliente, análise, investigador externo), qual é a parte do software afectada, qual é o possível impacto, que acção foi tomada e em que data, e quem na sua organização é responsável pelo acompanhamento. Um bom registo também torna visível se uma correcção foi implementada em todos os clientes que utilizam a versão em questão, ou apenas em quem comunicou o problema. Este último é precisamente o que um utilizador pergunta num questionário: não se teve alguma vez uma vulnerabilidade, mas se o seu processo garante que todos os afectados por ela também ficam a saber.
O que documenta num incidente na linha de desenvolvimento
Um incidente no seu próprio ambiente de desenvolvimento — uma conta comprometida com acesso ao código-fonte, um servidor de construção que responde de forma inesperada, uma dependência que mais tarde se revela maliciosa — exige um registo ligeiramente diferente. Aqui trata-se de: que sistema ou conta foi envolvido, quem tinha acesso durante o período em questão, se há indícios de que o código foi alterado ou consultado, e quais os clientes que possivelmente utilizam software que foi construído ou entregue durante esse período. Este é o tipo de incidente em que o controlo de acesso na linha de desenvolvimento tem aplicação directa: sem uma visão actualizada de quem tem permissão para estar onde, responder a esta pergunta de investigação é significativamente mais difícil.
Quem informa e quem não informa
Se cai ou não sob a obrigação de cuidado da Lei de Cibersegurança determina quem informa sobre um incidente. As entidades que foram classificadas como essenciais ou importantes têm uma obrigação de comunicação junto da sua autoridade supervisora; o que exactamente é necessário e em que prazo está descrito na directiva e na lei nacional, e varia consoante a situação. Uma empresa de software que é afectada através da cadeia — ou seja, não é obrigada em si, mas entrega a um cliente que é — não tem essa obrigação de comunicação junto da autoridade supervisora, mas normalmente tem um acordo contratual para informar o cliente. Isto não torna o seu próprio registo menos importante: um cliente que pergunta se teve alguma vez um incidente quer ver uma resposta concreta, não uma estimativa retrospectiva.
Um registo dinâmico, não um arquivo
O registo de incidentes funciona melhor como documento vivo: uma lista em que, para cada incidente, se encontra o estado, a prova e o responsável, em vez de um relatório isolado que desaparece numa pasta após resolução. Isto alinha-se com a forma como o dever de diligência mais amplo é estruturado, com dez medidas que, uma a uma, exigem um estado e um responsável. Quem quiser ver como o registo de incidentes se relaciona com as outras nove medidas encontra esse resumo em a página com todos os tópicos por situação.
Se a sua organização está sujeita ao dever de diligência, é afetada através da cadeia de fornecimento, ou nenhuma das anteriores, é possível verificar com algumas perguntas através de a verificação NIS2 que em algumas perguntas dá uma indicaçãoQuem quiser saber exatamente de onde vêm as informações em secria.eu e como são mantidas, lê isso em a página sobre como funcionaE quem, após a leitura, quiser saber o que uma subscrição acrescenta ao que aqui está disponível gratuitamente, encontra isso de forma clara em o resumo do que está incluído.
Este texto é uma orientação geral e não constitui aconselhamento jurídico sobre a sua situação específica. Para uma avaliação sobre o seu processo específico de incidentes ou obrigação de notificação, pode contactar um juiz ou a autoridade reguladora competente para o seu setor.