Governança de software: controle do código da origem ao deploy

Governança de software decide o que entra em produção por meio de política escrita, portão automatizado na esteira e trilha de evidência do commit ao comportamento observado. É medida pelas métricas DORA, apoiada em normas como a ISO/IEC/IEEE 12207 e o Cyber Resilience Act, e implantada em quatro ondas sem parar a entrega.

Uma alteração de regra de cálculo sobe numa quinta-feira e ninguém no time de tecnologia percebe nada. Quem percebe é a central de atendimento, na segunda, pelo volume de ligações. Entre a mudança e a descoberta houve quatro dias e nenhum registro que ligue uma coisa à outra.

Governança de software é o sistema de decisão que define quem pode alterar um sistema em produção, sob qual evidência a alteração é aprovada e como isso se comprova depois. Sem essa cadeia, a organização descobre o efeito de uma mudança pelo canal de atendimento, e não pelo próprio ambiente.

O que é governança de software

A finalidade da governança de software é tornar previsível o efeito de uma mudança sobre o negócio. O mecanismo tem três elementos. Uma política escrita define o que pode entrar em produção. Um portão automatizado aplica essa política na esteira. Uma trilha de evidência liga a demanda ao artefato em execução.

O requisito de base é a observabilidade do comportamento real em produção. Política que não pode ser verificada contra dados de execução vale como intenção, e não como controle.

Governança de software e governança de TI não são a mesma coisa

Seis diferenças separam as duas disciplinas.

A governança de software é uma disciplina dentro da governança de TI, e não uma alternativa a ela. A prestação de contas desce da governança corporativa: conselho, diretoria, área de tecnologia, time de produto. O alinhamento estratégico se comprova quando cada mudança carrega evidência.

Governança de software também não é gestão de ativos de software

Software Asset Management, ou SAM, cuida de licença, inventário e conformidade contratual do software adquirido. Governança de software cuida do que a organização constrói e opera, do commit à implantação. Software de governança corporativa, a ferramenta de atas e compliance societário, é outra categoria ainda.

Os seis componentes da governança de software

A governança de software se apoia em seis componentes, e a ausência de um derruba os demais.

• Política: a regra escrita do que pode entrar em produção.
• Portão: o ponto da esteira que aplica a política a cada mudança.
• Esteira: o caminho automatizado do commit à implantação.
• Evidência: o registro que liga demanda, código, artefato e implantação.
• Indicador: a medida de velocidade e de estabilidade da entrega.
• Cadência de revisão: a revisitação periódica de política e de limite.

A liderança de tecnologia define a política com o negócio, e o time dono do serviço responde pelo resultado. Sem essa separação, a política vira recomendação e o portão vira formalidade.

Da origem ao deploy: a esteira como objeto de governança

A esteira de CI/CD, integração contínua e entrega contínua, é onde a governança acontece. A esteira é o corredor, e a governança é a regra do corredor. Cinco etapas concentram os controles.

Build, artefato e SBOM: o que exatamente foi empacotado

Software Bill of Materials, ou SBOM, é a lista legível por máquina de tudo que compõe um artefato, incluindo bibliotecas de terceiros. O Cyber Resilience Act, Regulamento (UE) 2024/2847, obriga essa geração para produtos com elementos digitais a partir de 11 de dezembro de 2027.

Ambientes: o mesmo artefato, do legado à nuvem

O mesmo artefato é promovido entre desenvolvimento, homologação e produção, em vez de reconstruído a cada estágio. Artefato reconstruído não é o artefato testado, e a diferença entre os dois só aparece no incidente.

Monolito legado, contêiner, carga sem servidor e sistema de terceiro convivem no mesmo negócio. O OneAgent encurta a cobertura, porque uma instalação descobre toda a stack de um host, contêiner ou ambiente cloud, sem configuração manual por componente.

Quality gate: o portão que decide sem reunião

Quality gate, ou portão de qualidade, é o ponto da esteira em que uma mudança é avaliada contra critérios objetivos antes de avançar. O critério é medido, em vez de opinado. Assim como a governança de dados define o dono de cada dado, a governança de software define quem responde por cada mudança.

Sete critérios compõem um portão maduro: cobertura de teste, vulnerabilidade em dependência, conformidade de configuração, disponibilidade, latência, consumo de recurso e comparação com a linha de base.

Como um portão automatizado avalia uma release

O portão consulta os dados de execução da nova versão e compara cada objetivo contra dois limites, de alerta e de falha. As saídas são três: aprovar, alertar ou barrar. O resultado binário ensina o time a ignorar o amarelo, e é por isso que o terceiro estado existe.

O Site Reliability Guardian da plataforma Dynatrace automatiza a análise de impacto e valida objetivos de disponibilidade, performance, capacidade e segurança. O valor de cada indicador vem de uma consulta no Dynatrace Query Language, ou DQL, disparada por Workflows ou por API.

O dado consultado vem da plataforma de observabilidade, que entrega cinco capacidades essenciais: Application Performance Monitoring, ou APM, monitoramento de infraestrutura e cloud, Digital Experience Monitoring, ou DEM, AIOps, e compliance e governança de performance. Para o Site Reliability Engineer, ou SRE, em plantão, o portão derruba a release que ameaça o Service Level Objective, ou SLO, antes de o gráfico virar chamado.

O portão precisa barrar o que quebra, não o que atrasa

A pesquisa consolidada em Accelerate, de Forsgren, Humble e Kim, publicada em 2018, analisou os State of DevOps Reports de 2014 a 2017. O achado é direto: aprovações externas têm correlação negativa com lead time de mudança, frequência de implantação e tempo de restauração, e nenhuma correlação apareceu com a taxa de falha de mudanças.

O comitê de aprovação cobra tempo e não entrega estabilidade em troca. Quem viu comitê semanal falhar em impedir incidente leu certo o que aconteceu: o erro estava no instrumento, e não na disciplina do time.

Como medir governança de software: as métricas DORA

Cinco métricas descrevem a entrega com número, em vez de percepção.

As quatro primeiras são as métricas clássicas do DORA. A taxa de retrabalho é indicador antecedente, porque mostra a dívida técnica sendo paga às pressas antes de a instabilidade aparecer nas demais. Para o gerente de infraestrutura, é o indicador que antecipa consumo não planejado de capacidade e de plantão.

O que o relatório DORA 2025 mostrou sobre inteligência artificial

O relatório DORA de 2025 passou a se chamar State of AI-assisted Software Development, reuniu respostas de quase 5.000 profissionais e trocou os clusters de performance por sete perfis de time.

A conclusão que interessa à governança é que a adoção de inteligência artificial aumenta a vazão de entrega e a instabilidade juntas, com mais falhas de mudança e mais retrabalho. O gargalo se desloca para revisão, teste e validação de release. O portão automatizado acompanha esse ritmo, e o comitê não acompanha.

A base normativa da governança de software

ISO/IEC 38500:2024 e ISO/IEC/IEEE 12207:2017

A ISO/IEC 38500:2024 é a terceira edição da norma internacional de governança de TI e alinha seus princípios à ISO 37000. A ISO/IEC/IEEE 12207:2017 é a norma vigente de ciclo de vida de software, de novembro de 2017. A governança de software fica na interseção das duas, e a ISO/IEC 27001 entra como referência de segurança dentro do portão.

Setor financeiro: Resolução CMN nº 4.893/2021 e Resolução CMN nº 5.274/2025

A Resolução CMN nº 5.274, de 18 de dezembro de 2025, alterou a Resolução CMN nº 4.893/2021 e estabeleceu um conjunto mínimo obrigatório de controles de segurança cibernética. O prazo de adequação se encerrou em 1º de março de 2026, com a Resolução BCB nº 538/2025 no mesmo pacote. Conformidade exige registro, e não declaração.

Setor público: Lei nº 14.133/2021 e IN SGD/ME nº 94/2022

A Instrução Normativa SGD/ME nº 94, de 23 de dezembro de 2022, rege a contratação de TIC no âmbito do SISP, sob a Lei nº 14.133/2021, e vigora desde 1º de fevereiro de 2023. Sem trilha de auditoria, o órgão comprova o contrato e não comprova a entrega.

Cyber Resilience Act e a conversa com COBIT e ITIL

O Cyber Resilience Act, Regulamento (UE) 2024/2847, entrou em vigor em 10 de dezembro de 2024. As obrigações de notificação passam a valer em 11 de setembro de 2026, e as principais em 11 de dezembro de 2027. A empresa brasileira que exporta produto com elemento digital para a Europa entra no alcance.

COBIT e ITIL descrevem o quê e o porquê, no nível de controle e de gestão de serviço. A governança de software descreve o como. O objetivo de controle hoje auditado por entrevista passa a ser auditado por registro de execução.

Evidência: como provar o que foi para produção

A trilha de auditoria da mudança separa controle de constatação. Descobrir meses depois que a alteração foi irregular é auditoria retrospectiva, e não governança. Cinco artefatos compõem a cadeia.

• Registro da demanda que originou a alteração.
• Histórico de revisão do código, com autor e aprovador.
• Identificação do artefato construído, com o SBOM.
• Registro do evento de implantação, com versão, ambiente e horário.
• Comportamento observado do serviço depois da mudança.

A trilha que liga demanda, commit, artefato, implantação e comportamento

A cadeia é percorrida nas duas direções: do incidente de volta ao commit, para achar a causa raiz, e do commit para frente, para medir o efeito.

O Release monitoring da plataforma Dynatrace detecta versões por variáveis de ambiente, rótulos de Kubernetes e eventos de CI/CD. O Smartscape mantém o mapa de dependências atualizado em tempo real. Davis, dentro do Dynatrace Intelligence, é responsável pela análise causal da plataforma, e a IA causal atua na identificação da causa e do contexto do problema, enquanto os dashboards organizam e tornam exploráveis os sinais operacionais.

O Dynatrace Query Language sustenta a pergunta que nenhum dashboard previu, e o Grail retém logs, métricas, traces e eventos em volume massivo, com períodos de retenção que variam conforme o tipo de dado e a configuração adotada, e permite consulta rápida sobre o histórico disponível, porque a auditoria pode chegar meses depois do incidente.

Telemetria como evidência: o que precisa estar padronizado

Telemetria padronizada é pré-requisito de prova. Nomes divergentes para o mesmo serviço impedem o agrupamento nos dashboards e a comparação entre ambientes.

O OpenTelemetry, padrão aberto e vendor-neutral da CNCF, define APIs, SDKs, convenções semânticas e protocolo de transporte. É o padrão USB-C da telemetria. Nele, service.name é o único atributo obrigatório de recurso, com valor padrão unknown_service quando não informado. O OTLP transporta os dados por gRPC na porta 4317 ou por HTTP com protobuf na porta 4318.

Sem visão do comportamento real, a política não tem contra o que ser verificada, e daí a dependência da observabilidade full-stack, que reúne aplicações, infraestrutura, cloud e experiência digital no mesmo contexto correlacionado.

Dois erros de campo derrubam a evidência. Coletar tudo sem propósito dispara o custo de ingestão. Cardinality de métricas, com identificador único por requisição virando dimensão, inviabiliza a consulta. Os dois se resolvem na origem, com convenção de atributo escrita, prefixo reservado para atributo customizado e validação antes da entrada em produção.

Como implementar governança de software em ondas

Quatro ondas colocam a governança de pé sem parar a entrega, cada uma com resultado visível antes da seguinte.

1. Diagnóstico de maturidade: o estágio atual e as dores prioritárias.
2. Primeiro portão: um serviço, poucos objetivos, reprovação com motivo legível.
3. Evidência: fechar a trilha da demanda ao comportamento observado.
4. Governança contínua: revisar política e limite na cadência do ambiente.

A objeção legítima: quando a governança vira fila

A objeção de que governança trava o time é razoável, porque boa parte das tentativas anteriores falhou exatamente assim. A diferença está no instrumento. O portão medido contra dado de execução decide em segundos e devolve o motivo. O comitê semanal decide em dias, sem informação nova.

Quanto tempo leva e o que muda primeiro

O primeiro portão, com escopo restrito, entrega valor visível em poucas semanas, e uma release barrada antes do usuário paga o esforço. Nenhum prazo curto fecha a trilha completa em ambiente heterogêneo, porque cada integração legada exige tratamento próprio nos pontos de fronteira.

Governança de software por setor

Em órgãos públicos, um portal de guia de tributo recebe alteração de regra de cálculo na véspera do vencimento, e o custo da falha é social e político antes de ser técnico. Os picos são previsíveis, entre prazo de tributo e matrícula escolar, o que torna o portão de release mais valioso justamente nas semanas de maior risco.

Em instituições financeiras, a organização precisa demonstrar ao regulador controle sobre mudanças em sistemas de transação. A governança de software transforma essa afirmação em evidência: política escrita, portão que a aplica e registro que a comprova, com trilha auditável completa.

Em cooperativas, uma plataforma digital atende dezenas de praças com perfis de rede diferentes, e a release que vai bem na capital pode degradar onde a conectividade é pior. O portão avalia o comportamento por praça, e a governança regional recebe evidência comparável em vez de média nacional.

Em empresas privadas de grande porte, o produto digital é o diferencial competitivo e cada semana de atraso custa mercado. A governança de software permite aumentar a frequência de implantação sem aumentar a taxa de falha, que é a única forma de acelerar sem transferir o custo para o cliente.

Governança de software não termina no deploy

A implantação aprovada abre o período em que a mudança precisa provar que se sustenta. Limite calibrado em janeiro deixa de descrever o risco quando o volume dobra em julho, e portão vencido ensina o time a ignorar o alerta.

Três movimentos mantêm a política viva. O primeiro é revisar cada limite na cadência do ambiente. O segundo é reavaliar quais objetivos ainda descrevem o risco do serviço. O terceiro é aposentar o critério que só gera ruído.

Governança de performance continuada é o nome dessa frente: acompanhar o comportamento real do serviço e devolver esse dado ao portão seguinte. Para o CIO, o CTO e o CEO, a pergunta sobre o que mudou passa a ter resposta com versão e horário, em vez de depender da memória de quem estava de plantão.

Perguntas frequentes sobre governança de software

Governança de software atrasa a entrega?

Depende do instrumento. A pesquisa consolidada em Accelerate mostra correlação negativa entre aprovação externa e velocidade, sem ganho de estabilidade em troca. Portão automatizado tem efeito oposto, porque decide em segundos contra dado de execução e devolve o motivo da reprovação junto com o resultado.

Quantos critérios um quality gate deve ter?

Menos do que a vontade inicial sugere. O primeiro portão de um serviço funciona melhor com três ou quatro objetivos bem calibrados do que com sete mal ajustados, porque reprovação sem motivo claro destrói a confiança da equipe antes de a política amadurecer. Os critérios entram por onda.

Governança de software exige comitê de mudança?

Não. O requisito é política escrita, portão que a aplique, evidência retida e cadência de revisão. Comitê é um dos formatos possíveis de instância decisória, e a evidência disponível indica que ele custa tempo sem reduzir a taxa de falha de mudanças.

Como provar para auditoria o que foi para produção?

Pela cadeia de cinco artefatos: demanda, revisão de código com autor e aprovador, identificação do artefato com SBOM, registro do evento de implantação com versão, ambiente e horário, e comportamento observado depois da mudança. O último é o que exige retenção longa e consultável.

Por onde começar quando o ambiente é heterogêneo?

Por um serviço crítico com esteira já automatizada, e não pelo mais antigo. O primeiro portão prova o mecanismo com risco contido, e a cobertura dos sistemas legados entra depois, com instrumentação manual nos pontos de fronteira, que é onde a trilha costuma se romper.

Calibrar os limites do portão e sustentar isso em um ambiente que muda a cada trimestre é trabalho de campo, e não de documento. A Rike IS atua com consultoria, implantação, treinamento e governança contínua em observabilidade sobre a plataforma Dynatrace, junto a órgãos públicos, instituições financeiras, cooperativas e empresas privadas de grande porte, começando o desenho por um serviço crítico e expandindo em ondas.

As referências normativas citadas são informativas e não substituem análise jurídica específica. A conformidade com as normas aplicáveis é responsabilidade do contratante.