
Tribunal Regional Eleitoral - TO
Secretaria Judiciária e de Gestão da Informação
Coordenadoria de Gestão da Informação
Seção de Biblioteca, Memória e Arquivo
INSTRUÇÃO NORMATIVA Nº 29, DE 22 DE SETEMBRO DE 2025
Dispõe sobre as regras e os procedimentos para Desenvolvimento Seguro de Software do Tribunal Regional Eleitoral do Tocantins, em consonância com a Resolução nº 370/2021, do CNJ, Resolução nº 23.644/2021, do TSE e normas correlatas.
O Presidente do Tribunal Regional Eleitoral do Tocantins, no uso das atribuições que lhe são conferidas pelo art. 20, inciso XV, do Regimento Interno do Tribunal Regional Eleitoral do Tocantins, RESOLVE:
CAPÍTULO I
DISPOSIÇÕES PRELIMINARES
Art. 1º Fica instituída a norma complementar da Política de Segurança da Informação para Desenvolvimento Seguro de Software, que estabelece diretrizes obrigatórias para o desenvolvimento seguro de software, visando garantir a integridade, confidencialidade, disponibilidade e resiliência dos sistemas e aplicações.
Art. 2º Esta norma integra a Política de Segurança de Informação da Justiça Eleitoral, estabelecida pela Res. TSE 23.644/2021.
CAPÍTULO II
DAS DEFINIÇÕES
Art. 3º Para os efeitos da Política de Segurança da Informação do TSE e das normas a ela subordinadas, aplicam-se os termos e e definições conceituados na Portaria TSE nº 444, de 8 de julho de 2021.
CAPÍTULO III
DESENVOLVIMENTO E TESTE DE SEGURANÇA
Art. 4º Durante o desenvolvimento, devem ser aplicadas técnicas e ferramentas para análise estática e dinâmica de código, a fim de identificar e remediar vulnerabilidades de segurança.
Art. 5º Antes da liberação, o software poderá passar por uma fase de teste de penetração (pen-test) para validar a eficácia das medidas de segurança implementadas.
CAPÍTULO IV
GESTÃO DE VULNERABILIDADES DE SOFTWARE
Art. 6º Deve ser estabelecido um processo formal de gerenciamento de vulnerabilidades de software para rastrear, avaliar e mitigar as vulnerabilidades de segurança identificadas no software.
Art. 7º O processo de gerenciamento de vulnerabilidades de software deve ser documentado e comunicado a todas as partes relevantes dentro da organização.
Art. 8º As vulnerabilidades de software identificadas devem ser avaliadas quanto à sua gravidade, probabilidade de exploração e impacto potencial no ambiente de software.
Art. 9º Deve ser implementada uma política de priorização baseada no risco para determinar a ordem em que as vulnerabilidades serão corrigidas.
Art. 10 As correções de segurança devem ser aplicadas conforme necessário e de acordo com a política de priorização estabelecida:
I - Correções críticas e de alto risco devem ser aplicadas imediatamente, enquanto correções de menor prioridade podem ser agendadas de acordo com uma programação pré-definida.
II - Deve ser mantido um registro das correções aplicadas, incluindo detalhes sobre a vulnerabilidade corrigida e a data de implementação.
CAPÍTULO V
DO USO DE COMPONENTES
Art. 11 Antes de incorporar qualquer componente ou biblioteca de terceiros em um projeto de software, deve ser realizada uma avaliação rigorosa de segurança para verificar a confiabilidade e integridade do código.
Art. 12 A avaliação de segurança deve incluir a análise de possíveis vulnerabilidades conhecidas, histórico de patches e atualizações, além de revisões de código se disponíveis.
Art. 13 Componentes e bibliotecas de terceiros devem ser selecionados com base em critérios de segurança, preferindo-se aqueles que possuem um histórico de segurança sólido, suporte ativo da comunidade e atualizações regulares.
Art. 14 Deve-se dar preferência a componentes que tenham sido revisados e aprovados por fontes confiáveis de segurança, como organizações de segurança cibernética e grupos de pesquisa.
Art. 15 Uma vez incorporados ao projeto, os componentes e bibliotecas de terceiros devem ser continuamente monitorados quanto a novas vulnerabilidades e atualizados regularmente para mitigar riscos de segurança.
Art. 16 Deve ser estabelecido um processo formal de monitoramento de vulnerabilidades que inclua alerta de segurança, análise de impacto e implementação oportuna de patches e atualizações.
CAPÍTULO VI
DA INFRAESTRUTURA
Art. 17 O processo de desenvolvimento seguro de software deve integrar elementos de infraestrutura padronizada, aderindo a um Modelo Seguro de Configuração para os componentes de infraestrutura das aplicações. Estes componentes devem estabelecer uma funcionalidade mínima e serem baseados em imagens padrão que tenham passado por um processo de "hardening".
Art. 18 Os ambientes dos Sistemas de Produção e Não Produção devem ser claramente especificados e mantidos separados, garantindo a integridade e estabilidade das aplicações em ambos os cenários.
Art. 19 O repositório de informações e código-fonte deve ser segregado, com políticas rígidas de acesso e rastreamento de todas as ações realizadas, garantindo a segurança e a integridade dos dados e do código-fonte durante todo o ciclo de desenvolvimento.
CAPÍTULO VII
DA CAPACITAÇÃO DE DESENVOLVEDORES
Art. 20 A equipe de desenvolvimento de software deverá ter um programa de treinamento para desenvolvimento seguro estabelecido que contemple princípios gerais de segurança, práticas padrão de segurança de aplicações e proteção de dados pessoais.
Parágrafo único. O treinamento deverá ser realizado pelo menos uma vez ao ano para promover a segurança dentro da equipe e construir uma cultura de segurança entre os desenvolvedores.
CAPÍTULO VIII
DA PROTEÇÃO DE DADOS PESSOAIS
Art. 21 Medidas de segurança adequadas devem ser implementadas para proteger os dados pessoais contra acesso não autorizado, uso indevido, alteração ou destruição.
Art. 22 As medidas mencionadas no art. 21 podem incluir a criptografia de dados sensíveis, a pseudonimização ou anonimização sempre que possível, e o controle de acesso rigoroso para garantir que apenas usuários autorizados tenham acesso aos dados pessoais.
CAPÍTULO IX
INTEGRAÇÃO CONTÍNUA E ENTREGA CONTÍNUA NO DESENVOLVIMENTO SEGURO DE SOFTWARE
Art. 23 É obrigatória a implementação de um pipeline de CI/CD seguro que automatize processos de compilação, testes, análises estáticas de código, verificação de segurança e implantação, visando assegurar a entrega rápida e confiável de software de alta qualidade.
Art. 24 O pipeline de CI/CD deve incluir verificações automáticas de segurança em cada etapa do processo, identificando e alertando sobre possíveis vulnerabilidades de segurança o mais cedo possível no ciclo de desenvolvimento.
Art. 25 Deve-se integrar ao pipeline de CI/CD um conjunto abrangente de testes de segurança automatizados, incluindo análise estática de código, varreduras de vulnerabilidades e conformidade com padrões de segurança.
Art. 26 Os testes devem ser executados regularmente e de forma sistemática como parte do processo de integração e implantação contínuas, garantindo que quaisquer vulnerabilidades ou violações de segurança sejam identificadas e corrigidas rapidamente.
Art. 27 Esta Instrução Normativa entra em vigor na data de sua publicação e sua implementação se fará no prazo de 90 dias a contar dessa data.
Palmas, 22 de setembro de 2025.
Desembargador Adolfo Amaro Mendes
Presidente
Este texto não substitui o publicado no DJE-TRE-TO, nº 204, de. 10.11.2025 p. 23-26.

