Histórico de Alterações da Biblioteca

Nota 11 do capítulo 27 - Governança da Biblioteca de CTI. Fecha o capítulo e o acervo com a política que registra a evolução da biblioteca no tempo.
Define o versionamento semântico major, minor e patch, o formato do changelog, a revisão periódica semestral do conteúdo técnico e a deprecação de notas com redirecionamento, além do changelog inicial da versão 1.0.
Dialoga com os critérios da nota 10, que alimentam cada ciclo de revisão, com os templates da nota 07 e com o framework CTH do capítulo 15, que estrutura o conteúdo auditado.

1. Contexto e Posicionamento na Biblioteca

Conteúdo técnico sobre CTI envelhece mais rápido que conteúdo de quase qualquer outra área de engenharia: versões de ATT&CK mudam duas vezes por ano, ferramentas mudam de nome ou de modelo de licença, grupos aparecem e desaparecem e padrões como STIX evoluem. Uma biblioteca sem política de atualização carrega silenciosamente informação errada e transmite confiança indevida justamente quando o leitor mais precisa de exatidão. Esta nota fecha o capítulo 27 e a biblioteca com o mecanismo que sustenta a atualidade do acervo: versionamento do todo, changelog por versão, revisão periódica semestral e deprecação disciplinada de notas que deixaram de ser válidas.

O registro de alterações cumpre ainda um segundo papel, o de memória institucional. Quando um analista pergunta por que uma nota mudou, quando um auditor pergunta quando a biblioteca incorporou uma versão nova de ATT&CK e quando um novo curador pergunta o que foi removido e por quê, a resposta está nesta nota e no changelog que ela define. Acervo sem histórico é acervo sem responsável, e a governança do capítulo 27 existe para que cada linha do acervo tenha dono, data e motivo verificáveis.

2. Versionamento Semântico do Acervo

A biblioteca inteira tem uma única versão, no formato MAJOR.MINOR.PATCH, e cada componente sobe segundo regras fixas que removem a subjetividade da decisão de quando mudar a versão. O princípio é o mesmo do versionamento de software: o número comunica impacto ao leitor, e o leitor deve poder saber, só de olhar a versão, o quanto o acervo que ele já leu deixou de estar atualizado.

A regra prática de fronteira é o sentido técnico: se a correção muda o que o leitor deve fazer ou entender, é MINOR; se apenas conserta como isso está escrito, é PATCH. Sobe-se um componente por vez e nunca se reutiliza número: versão publicada é versão imutável, e erro no changelog de uma versão publicada se corrige na próxima, com nota de errata no registro. Quando uma publicação contém mudanças de mais de um tipo, o maior componente vence e os demais são descritos na mesma entrada, sem versões paralelas para o mesmo instante.

Vale também fixar o que não muda versão: ajuste de formatação que não altera texto, edição de ortografia em comentário interno e movimento de arquivo sem mudança de conteúdo são registrados apenas no histórico de controle de versões, sem entrada de changelog. O objetivo é preservar o sinal, e a pergunta que o curador faz antes de registrar é sempre a mesma: algum leitor precisa saber disso para confiar no que está lendo?

3. Responsabilidades da Curadoria

Política sem papéis nomeados é política de intenção, e a governança do acervo fixa quatro papéis com responsabilidades explícitas no versionamento e no ciclo semestral. A separação mais importante é entre autor e revisor, que nunca são a mesma pessoa na mesma nota, porque auto-aprovação anula o efeito da revisão por pares definida na nota 10.

Em times pequenos, os papéis giram: a mesma pessoa pode ser autor de uma nota e revisor de outra, mas nunca de ambas as posições na mesma nota no mesmo ciclo. Esse rodízio, registrado no changelog pela coluna de autoria, mantém a separação efetiva mesmo em programa de um ou dois analistas, e cria distribuição de conhecimento sobre o acervo que ajuda na continuidade quando alguém sai do time.

Os papéis vigentes por ciclo aparecem no relatório de indicadores da nota 10, e a designação é pública antes do início do ciclo, o que evita o problema clássico do revisor de fato descoberto depois. Quando o acervo cresce a ponto de nenhum curador único dar conta, os papéis se dividem por capítulos, com um curador por domínio e um curador geral responsável pela versão única da biblioteca.

4. Política de Changelog

O changelog é a parte pública da política e vive na raiz da biblioteca, em arquivo próprio mantido no formato de seções por versão, com a data de publicação e a lista de mudanças classificadas. Toda versão publicada tem entrada no changelog, e a disciplina mínima é a de quatro classificações, herdada das convenções consagradas de changelog: Added para conteúdo novo, Changed para conteúdo alterado, Deprecated para conteúdo marcado para saída e Removed para conteúdo retirado de fato.

A entrada mais recente fica no topo do arquivo, na convenção usual, e o arquivo é lido de cima para baixo como um diário invertido do acervo. A posição fixa importa: o changelog é o segundo arquivo que um novo leitor abre, logo depois do mapa geral do capítulo 27, e é também o primeiro anexo citado em toda comunicação de versão para o time.

O registro de cada mudança segue três exigências que valem o arquivo inteiro. Primeiro, rastreabilidade: cada linha aponta os arquivos afetados pelo caminho relativo completo, sem o que o changelog não permite auditar nada. Segundo, motivo: cada mudança de conteúdo relevante carrega em uma frase o porquê, como nova versão de ATT&CK, incidente que motivou revisão ou decisão do ciclo semestral. Terceiro, autoria: revisor e autor da mudança aparecem na entrada, porque responsabilidade compartilhada por todos é responsabilidade de ninguém. O changelog não registra opinião, debate ou plano futuro; isso pertence às issues do processo de revisão da nota 10, e o changelog registra apenas o que de fato entrou no acervo.

5. Revisão Periódica Semestral

A revisão semestral é o mecanismo que transforma a política em rotina, e cada ciclo percorre o acervo em quatro passos com janela de quatro semanas. No primeiro passo, o curador amostra o acervo: revisam-se integralmente os capítulos mais técnicos e mais sensíveis a tempo, como os capítulos de ferramentas, de ATT&CK e de EASM, e amostra aleatória de um terço das notas dos demais capítulos, com prioridade para as de idade de revisão maior. No segundo passo, cada nota da amostra passa pelo checklist da nota 10, com atenção especial a versões citadas, números de eventos, custos e ferramentas descontinuadas. No terceiro passo, os achados viram issues classificadas e corrigidas, e o resultado agregado alimenta os indicadores de qualidade. No quarto passo, o curador publica a nova versão com entrada completa no changelog, MINOR quando o ciclo acrescenta ou revisa conteúdo, PATCH quando apenas corrige.

O calendário fixo protege o ciclo da urgência: o primeiro ciclo fecha no fim do primeiro semestre e o segundo no fim do segundo, e datas móveis só mudam com registro no changelog, nunca em silêncio. Eventos fora de ciclo, como atualização major de ATT&CK publicada fora da janela, geram ciclo extraordinário de escopo recortado ao material afetado, seguido de entrada própria no changelog. A meta realista do programa é a de que nenhuma nota técnica fique mais de dois anos sem passar por revisão, meta que os indicadores da nota 10 monitoram.

A participação do ciclo é mais ampla que a da revisão corrente de notas: o curador coordena, os revisores da nota 10 executam as auditorias, e o dono de cada capítulo, quando existir, responde pela verificação factual das notas da sua área, com foco em versões de ferramenta, em números citados e em links vivos. O resultado do ciclo é publicado em duas partes, o relatório de indicadores para a gestão e a entrada de changelog para todos os leitores, e as duas partes se citam mutuamente.

6. Ferramentas e Práticas de Apoio ao Versionamento

O versionamento do acervo não exige plataforma pesada, e a combinação de controle de versões de texto com convenções simples desta nota cobre a necessidade de qualquer time pequeno ou médio. As práticas a seguir automatizam o lado mecânico da política e liberam o esforço humano para o que realmente precisa de julgamento, a leitura atenta e a decisão de conteúdo.

A automação cobre os critérios C-01, C-09, C-10 e C-11 da nota 10, que são verificáveis por comando, e nunca substitui a decisão de conteúdo: ferramenta nenhuma sabe se a versão de ATT&CK citada está correta ou se o custo listado ainda faz sentido. O mantenedor técnico mantém a rotina de triagem versionada junto ao acervo, e o relatório que ela gera entra como anexo do registro do ciclo no changelog.

7. Deprecação de Notas e Redirecionamento

Nota não se apaga, se deprecia. O conteúdo do acervo tem valor de história e de rastro de decisão, e a remoção silenciosa quebra links internos, referências cruzadas e a confiança do leitor que já havia lido o material. A deprecação é o estado intermediário em que a nota permanece no acervo, marcada como substituída, e aponta explicitamente para o conteúdo que a sucede. Marca-se deprecada a nota cujo conteúdo ficou tecnicamente errado sem correção possível no lugar, aquela cujo tema foi absorvido por outra nota melhor e aquela criada por duplicidade de estrutura.

O procedimento fixo tem três tempos. Na publicação da versão que depreca, a nota recebe o banner de redirecionamento no topo, abaixo do blockquote, e entra na seção Deprecated do changelog, com o motivo e a nota sucessora. No ciclo seguinte, a nota sucessora já cobre o conteúdo com profundidade, verificado na revisão, e a nota deprecada passa para Removed, com redirecionamento preservado em arquivo stub quando existirem links externos para ela. O stub mínimo é curto e padrão:

> NOTA DEPRECADA em 2.1.0. Este conteúdo foi substituído pela nota
> 06 - Feeds e Fontes Atualizadas do capítulo 02, que cobre o tema
> com dados revistos no ciclo semestral de 2026.
> Motivo da deprecação: feed descrito encerrou operação e a nota
> sucessora consolidou as fontes vivas do mesmo tipo.

A regra da biblioteca é a de que toda nota deprecada deve ser alcançável pelo índice, e todo leitor que chegar a ela por link antigo deve sair da página sabendo exatamente para onde ir, sem depender de busca nem de memória do time. Deprecar bem é o que permite ao acervo mudar sem quebrar a confiança que o sustenta.

Renomear nota é caso especial de deprecação leve, e a regra do acervo é tratar mudança de nome de arquivo como entrada Changed de nível MINOR, com a atualização de todos os links internos na mesma publicação. O padrão de H1 sem prefixo numérico adotado pela biblioteca existe exatamente para reduzir esse custo: renomear a posição de ordenação de uma nota muda o nome do arquivo e não o título interno, o que mantém a maioria dos links de referência estáveis.

8. Changelog Inicial da Biblioteca

O changelog desta biblioteca começa na versão 1.0.0, que documenta a criação do acervo com as 27 seções temáticas, e as entradas seguintes ilustram a aplicação das regras das seções 2 e 4 nos níveis de versão. A tabela traz o registro resumido, e o bloco de código da seção 9 mostra o formato expandido de entrada.

O registro de 1.0.0 merece atenção especial porque documenta a fundação: o acervo nasceu com as 27 seções já estruturadas, os capítulos numerados de 01 a 27 cobrindo o arco completo de CTI, de fundamentos e fontes a análise, hunting, integração, ferramentas, ambientes modernos e governança, e o guia de estilo foi aplicado desde a primeira linha escrita. Versões subsequentes contam a vida da biblioteca, e qualquer leitor que desejar entender por que o acervo tem a forma atual encontra na tabela o caminho completo de volta.

9. Exemplo de Entrada de Changelog

O bloco abaixo mostra o formato expandido de uma entrada de changelog, conforme a política da seção 4, e serve de padrão para o curador ao publicar cada versão. Note a rastreabilidade por caminho, o motivo de cada mudança e a autoria, que são as três exigências do registro.

## [2.1.0] - 2026-06-30 - Primeiro ciclo semestral de revisão

### Added
- 02 - Fontes de Dados e Coleta/14 - Fontes de Inteligência de IA.md:
  nota nova sobre fontes de inteligência de ameaças a sistemas de IA,
  com catálogo de feeds e de repositórios públicos (curadoria: A. Lima).

### Changed
- 20 - MITRE ATT&CK - Atualizações e Novidades/03 - ATT&CK v19.2 - Agosto
  de 2026/01 - Técnicas Específicas de Ameaças com IA (ATLAS).md: atualização
  das técnicas e do quadro de mapeamento para a revisão corrente (motivo:
  publicação de nova revisão do ATLAS; revisão: M. Duarte).
- 27 - Governança da Biblioteca de CTI/09 - Datasets e Laboratórios de
  Treinamento.md: substituída plataforma descontinuada no catálogo e
  atualizada tabela de custos (motivo: mudança de modelo de licença;
  revisão: A. Lima).

### Deprecated
- 02 - Fontes de Dados e Coleta/06 - Dark Web e Fóruns.md: substituída pela
  nota 15 do mesmo capítulo, que consolida os fóruns vivos e adiciona
  metodologia de coleta (motivo: sobreposição de conteúdo).

### Removed
- nenhuma nesta versão

A entrada ilustrada mostra também a granularidade correta: mudança por arquivo, com uma linha de motivo, e nunca um parágrafo genérico do tipo atualizações gerais, que não permite a nenhum leitor saber se a nota que ele leu foi afetada. Changelog que não responde essa pergunta básica falha em seu único propósito.

10. Erros Comuns e Pontos de Atenção

O erro mais comum de governança de changelog é o salto de versão sem registro intermediário: dois ciclos de trabalho comprimidos em uma única entrada MINOR, que destrói a granularidade e torna impossível saber o que mudou em cada momento. A disciplina que evita isso é publicar versão pequena e frequente, com PATCH para correções imediatas e MINOR por ciclo ou por entrega relevante, em vez de acumular mudanças para uma entrada monumental. O erro espelhado é o registro excessivo, com PATCH para cada vírgula trocada, que enterra o sinal; a balança prática é a de registrar versão sempre que o leitor precise saber que o conteúdo mudou.

Atenção também à depreciação adormecida: nota marcada como deprecada que nunca sai do estado intermediário porque a sucessora nunca ficou pronta. A regra do programa é a de que deprecação sem sucessora publicada no ciclo seguinte é cancelada e a nota volta ao acervo como ativa, com issue aberta para o caminho de consolidação correto. Por fim, o curador deve tratar o changelog como documento de leitura obrigatória para novos membros do time, porque vinte minutos de changelog ensinam a trajetória técnica e as decisões do acervo melhor que qualquer briefing verbal.

Um último ponto de atenção é o uso do histórico junto à liderança: números de versão e de mudanças por ciclo são a tradução mais honesta do esforço de manutenção do acervo, e o curador que os apresenta com regularidade constrói o argumento orçamentário do programa com dados próprios. Biblioteca que não mostra sua curva de atualização é tratada como custo fixo; biblioteca que mostra passa a ser tratada como capacidade mantida.

11. Integração com o Restante da Biblioteca

Esta nota depende da nota 10 para o processo que gera os achados de cada ciclo e fecha o arco do capítulo 27: templates da nota 07 padronizam o registro, critérios da nota 10 padronizam a qualidade e o versionamento desta nota padroniza a mudança no tempo. No acervo, as notas mais dependentes do ciclo semestral são as do capítulo 20, que rastreia versões de ATT&CK, as do capítulo 24, que acompanha ferramentas e seus modelos de licença, e as do capítulo 26, que cobre ambientes modernos de rápida mudança, e são elas as primeiras da amostra de cada ciclo.

Para operacionalizar esta nota, o curador cria o arquivo de changelog na raiz da biblioteca com a entrada 1.0.0 da seção 8, agenda os dois ciclos semestrais no calendário do time e publica a próxima versão com o formato da seção 9. A partir da primeira versão publicada, a biblioteca deixa de ser snapshot e passa a ser produto vivo, com histórico verificável e com curadoria que responde, a qualquer momento, o que mudou, quando e por quê.