A funcionalidade tem quem peça. O controle não.

Toda empresa de software conhece a cena. A sprint está fechada, o backlog tem meses de fila e alguém levanta um item de segurança: revisar o controle de permissões, limpar o que o ambiente de teste carrega, substituir um mecanismo de autenticação que funciona mas não deveria mais estar ali. Ninguém na sala discorda de que o item é legítimo. E ele não entra.

Vale prestar atenção no motivo, porque ele não é o que costuma se dizer. O item não perdeu a disputa de prioridade. Ele não chegou a disputar.

Uma funcionalidade tem três coisas que um controle de segurança não tem: alguém que pediu, uma data em que precisa estar pronta e um número associado — o contrato que ela destrava, o cliente que ameaça sair, a proposta que depende dela. O controle de segurança não tem cliente pedindo, não tem prazo externo e não tem receita atrelada. Numa fila ordenada por demanda, ele é invisível.

Isso muda o diagnóstico. Se o problema fosse desconhecimento, treinamento resolveria. Como o problema é ausência de mecanismo de decisão, o que resolve é estrutura. Conscientização não pauta backlog.

O que torna software multicliente diferente de tudo o mais

Numa empresa que usa um sistema internamente, uma falha produz um problema. Numa empresa que opera software para terceiros, a mesma falha produz um problema por cliente, simultaneamente, cada um com seu contrato, sua relação comercial e sua própria conversa difícil.

A consequência é contraintuitiva e merece ser dita com todas as letras: o custo de uma fragilidade não é proporcional à gravidade dela, e sim ao tamanho da sua base. A mesma linha de código exposta há dois anos custa uma fração hoje do que custará depois de dois bons anos comerciais. Crescer sem corrigir não dilui o risco. Multiplica.

Some-se um segundo fator, específico do modelo: o cliente não enxerga nada disso. Ele contratou a tela. A arquitetura por trás dela é invisível para ele até o dia em que deixa de ser — e nesse dia a avaliação não recai sobre a funcionalidade que ele usa todos os dias, e sim sobre decisões técnicas que ele nunca teve como avaliar.

Dívida de segurança não se comporta como dívida técnica

A analogia com dívida técnica é útil até certo ponto, e depois engana.

Dívida técnica comum cobra juros em velocidade. Você paga em horas de desenvolvimento, de forma contínua, e sente o custo no dia a dia — a entrega demora mais, o time reclama, o retrabalho aparece. É desconfortável e mensurável, e por isso acaba sendo tratada.

Dívida de segurança não cobra nada durante todo o período em que existe. Não atrasa entrega, não aparece em métrica, não incomoda ninguém. Ela é paga de uma vez só, numa data que não é você quem escolhe, e o valor não guarda relação com o esforço que teria sido necessário para evitá-la.

Há ainda um detalhe que costuma passar despercebido e que pesa muito quando alguém reconstrói a história: uma fragilidade nascida no desenho de uma funcionalidade existe desde que a funcionalidade existe. A data relevante não é a da descoberta. É a da concepção. Isso vale tanto para uma discussão com cliente quanto para uma análise de investidor, e é a razão pela qual "corrigimos assim que soubemos" é uma resposta melhor do que nenhuma, mas não é a resposta que se gostaria de dar.

E as fragilidades que mais custam raramente são as sofisticadas. São as que todo mundo conhece, que custam pouco e ficaram de fora justamente por serem pequenas demais para competir por espaço no roadmap. Controle caro e complexo que falta admite explicação — porte, estágio, prioridade. Controle barato e corrente que falta não admite explicação nenhuma, porque a régua de comparação não é o seu roadmap. É a prática ordinária do mercado na mesma época.

Onde a decisão precisa morar

Se o problema é de mecanismo, a correção é de mecanismo. Não se trata de adotar um framework inteiro nem de parar a operação para uma reestruturação. Trata-se de garantir que quatro coisas existam e tenham dono.

Um critério de entrada, aplicado na chegada. O momento de classificar um item como sensível é quando ele nasce, e não quando alguém repara. Se toda demanda que toca autenticação, permissão, exposição de dado ou fronteira entre clientes é sinalizada na entrada, o item passa a existir na fila. Metade do problema é esse: ele não estava lá.

Um dono nomeado. Não "o time", não "a área técnica". Uma pessoa, mesmo que em tempo parcial, mesmo que acumulando função. Responsabilidade distribuída entre todos é responsabilidade de ninguém, e essa é a diferença entre um assunto que avança e um que reaparece em toda reunião.

Registro de decisão, inclusive das negativas. Este é o item mais barato da lista e o mais valioso depois. Quando se decide não fazer algo, registra-se o quê, por quê e em que data. Duas linhas. O valor não está no documento em si; está em poder demonstrar, mais tarde, que houve avaliação e escolha consciente, e não desconhecimento. É a diferença entre uma decisão de negócio e uma omissão.

Uma revisão com data no calendário. Revisão sem data não acontece. Não precisa ser trimestral nem formal; precisa ter dia marcado e alguém que a conduza.

Além disso, três disciplinas que não são projeto e sim rotina, e que respondem por uma parte desproporcional do risco real: separação entre ambientes, com ambiente de teste livre de dado real de cliente; gestão do acesso da própria equipe ao ambiente de produção, com revisão periódica; e desligamento de acesso vinculado ao desligamento da pessoa, sem depender de lembrança.

Há um último ponto, de natureza diferente dos anteriores, que costuma ser tratado como assunto de infraestrutura e é, na prática, assunto de gestão: a capacidade de reconstituir o que aconteceu. Registro de acesso íntegro e retido por período suficiente não previne nada. Ele determina se, no dia difícil, a empresa consegue dizer o que ocorreu, com que alcance e sobre quais clientes — ou se terá de responder que não sabe. Essas duas respostas produzem conversas radicalmente diferentes, com cliente, com investidor e com autoridade.

O que mudou e por que agora

Nada disso é novo. O que mudou foi quem passou a olhar.

O comprador aprendeu a perguntar. Diligência sobre fornecedor de software está deixando de ser exceção em contratações relevantes. Duplo fator disponível para contas de cliente, política de senha, segregação de ambientes, retenção de registro, cláusula de comunicação de incidente: são perguntas objetivas, de resposta sim ou não, que hoje aparecem antes da assinatura. Quem responde bem a elas ganha um argumento comercial que o concorrente não tem. Quem não responde perde negócio sem nunca saber por quê.

A régua regulatória é o estado da técnica, e ela corre desde a concepção. A LGPD não pergunta se a empresa fez o que podia com os recursos que tinha. Pergunta se as medidas correspondiam ao que estava disponível à época, e trata a segurança como exigência desde o desenho do produto, não a partir da entrega. Para quem desenvolve, isso desloca o assunto do fim da esteira para o começo dela.

O capital passou a incluir isso na conta. Em processo de investimento, M&A ou entrada de sócio, proteção de dados e governança de desenvolvimento saíram do anexo técnico e entraram na avaliação. Passivo de dimensão indeterminada, contratos sem definição de papéis e sem limitação de responsabilidade, ausência de registro que permita medir exposição: nada disso é apontamento de conformidade apenas. Vira desconto no preço, retenção de parte do pagamento, condição precedente ou, com alguma frequência, motivo para a conversa não avançar.

É aí que o argumento se fecha. Governança de desenvolvimento deixou de ser custo de conformidade porque passou a ser precificada. Ela não protege apenas contra o dia ruim. Ela integra o valor da empresa nos dias comuns, e é avaliada exatamente quando a empresa mais precisa de uma boa avaliação.

O que existe quando alguém olha

Toda estrutura de governança tem a mesma característica desconfortável: ela só é avaliada depois, e é avaliada pelo que já existia antes.

Não há como constituir retroativamente uma decisão que não foi tomada, um registro que não foi mantido, uma revisão que não aconteceu. O que a empresa organizar este ano é o que estará lá quando um cliente perguntar, quando um investidor abrir a pasta ou quando uma autoridade pedir explicação. O que ela adiar simplesmente não existirá, e o adiamento não deixa rastro que ajude — deixa rastro que atrapalha.

A funcionalidade tem quem peça. O controle não. É exatamente por isso que ele precisa de um dono.

Rogério Santos
Kayros Consultoria

Se o item de segurança nunca entra na fila porque ninguém o pede, a pergunta muda: sua operação está estruturada para ser analisada — ou apenas para entregar?

Na Kayros Consultoria, estruturamos governança, processos e gestão de risco em empresas de tecnologia - para que o valor construído no produto se sustente na análise, e não apenas na demonstração.