GitHub

Em quase todo roadmap de produto que já vi, segurança ocupa o mesmo lugar: o de "importante, vamos fazer depois". Ela perde para features que vendem, para correções que os clientes reclamam, para prazos que o mercado impõe. É sempre prioridade, só que nunca a desta sprint.

O problema é que segurança adiada não desaparece. Ela se acumula como dívida, silenciosa, até cobrar os juros de uma vez só, no pior momento, na forma de um incidente. E aí ela vira, da noite para o dia, a única prioridade que existe.

Este artigo usa casos reais, anonimizados, mas representativos de padrões que se repetem, para mostrar o que acontece quando segurança fica fora do roadmap. É para líderes de produto e tecnologia que estão decidindo onde investir e precisam entender o trade-off de verdade antes de empurrar segurança para a próxima versão.

Por que segurança sempre perde a priorização

A dinâmica é estrutural, não fruto de má-fé. Features novas geram receita visível e elogios. Segurança bem feita gera ausência de problemas, e ninguém comemora um incidente que não aconteceu. Quando você prioriza o que é visível, segurança naturalmente afunda na lista.

Some a isso a pressão de mercado, prazos de venda e a sensação de que "nunca aconteceu nada". O resultado é previsível: o roadmap se enche de funcionalidades e a segurança vira uma nota de rodapé que cada trimestre é reescrita como "próximo trimestre".

A tese que defendo: segurança não é um item do roadmap, é um atributo de cada item do roadmap. Tratar como linha separada é o que garante que ela será cortada quando o prazo apertar. Os casos a seguir mostram por que essa distinção importa.

Caso 1: a startup que cresceu rápido demais para a própria segurança

Uma startup de tecnologia atingiu tração rápida. O foco, corretíssimo no início, era crescer e provar o produto. Segurança era "depois do product-market fit". O roadmap só tinha features.

Com a base de usuários grande, veio o incidente: uma falha de controle de acesso permitia que um usuário visse dados de outro apenas alterando um identificador na requisição. A correção em si era simples. O estrago, não. Houve exposição de dados pessoais, notificação obrigatória sob a LGPD, desgaste com clientes e uma corrida desesperada para auditar tudo o que havia sido construído sem critério de segurança.

A lição: o que era barato resolver no início, embutir verificação de autorização desde o primeiro endpoint, virou caro de remediar com o produto grande e em produção. Segurança adiada não fica mais barata com o tempo. Fica mais cara, porque cresce junto com o produto.

Caso 2: o produto público que parou no dia mais importante

Um sistema de serviços ao cidadão foi desenvolvido com roadmap focado em entregar funcionalidades dentro do prazo político. Continuidade, backup testado e proteção contra ataques de carga ficaram para "uma fase futura".

A fase futura nunca chegou antes do incidente. Num dia de pico, prazo de um serviço essencial, o sistema ficou indisponível. Não por ataque sofisticado, mas por falta de resiliência básica que havia sido despriorizada no roadmap. O cidadão, que não tem aplicativo concorrente para recorrer, ficou sem o serviço público do qual dependia.

O custo aqui não foi só técnico. Foi de confiança pública, o ativo mais difícil de reconstruir no setor governamental. A lição é dura: no setor público, segurança e continuidade não são features negociáveis, porque a falha não atinge uma empresa, atinge a população.

Caso 3: a dívida de segurança que travou o crescimento

Um produto consolidado decidiu, finalmente, buscar clientes maiores. Esses clientes exigiram auditorias de segurança antes de fechar contrato. Foi quando a conta da segurança adiada apareceu.

Anos de roadmap sem critério de segurança haviam acumulado uma dívida enorme: dependências desatualizadas, falta de controles básicos, ausência de processos. Para passar nas auditorias e fechar os contratos grandes, o time precisou parar quase todo o desenvolvimento de features por meses para remediar.

O paradoxo é cruel. A segurança que foi adiada "para não atrapalhar o crescimento" acabou travando exatamente o crescimento que ela deveria ter viabilizado. A lição: segurança não é só proteção contra perda, é condição de acesso a mercados maiores e clientes mais exigentes.

O padrão que une os três casos

Olhando os três, o padrão é nítido. Em todos, segurança foi tratada como item separado e adiável. Em todos, o adiamento pareceu racional no momento. E em todos, a conta chegou maior do que teria sido se o trabalho fosse feito ao longo do caminho.

O custo de embutir segurança continuamente é distribuído e gerenciável. O custo de remediar de uma vez, sob pressão de incidente ou de auditoria, é concentrado e doloroso. É a diferença entre pagar uma assinatura mensal e ser surpreendido com uma fatura anual inteira de uma vez.

A visão estratégica: incluir segurança em cada item do roadmap não é desacelerar. É evitar as paradas bruscas que efetivamente matam o ritmo. Velocidade sustentável vem de não acumular dívida explosiva.

Como colocar segurança no roadmap sem travá-lo

A solução não é transformar o roadmap em um projeto de segurança. É integrar segurança ao fluxo normal de produto, de forma proporcional ao risco.

Cada funcionalidade nova deveria nascer com a pergunta "o que pode dar errado em termos de segurança e privacidade aqui?" respondida no próprio desenho. Funcionalidades que lidam com dados sensíveis, dinheiro ou autenticação merecem mais cuidado; uma mudança cosmética, menos. A régua é o risco.

Reservar uma fração consistente da capacidade do time para reduzir dívida de segurança e manter dependências atualizadas evita o acúmulo explosivo. Não é glamouroso, mas é o que mantém os juros sob controle. E tratar conformidade com a LGPD como requisito de desenho, não como remendo posterior, economiza retrabalho e protege a organização.

A reflexão para quem decide

A armadilha cultural é o otimismo da ausência. "Nunca tivemos um incidente" é interpretado como "estamos seguros", quando significa apenas "ainda não fomos cobrados". É a calmaria que precede a maioria das crises mal resolvidas.

A maturidade de um líder de produto aparece na disposição de proteger espaço no roadmap para o que não gera aplauso imediato. É mais fácil dizer sim para a feature que o cliente pediu do que para o controle de acesso que ninguém vai notar, até o dia em que sua ausência destrói a confiança construída em anos.

Os casos mostram a mesma moral por ângulos diferentes: segurança fora do roadmap não é economia, é dívida com juros altos. Quem entende isso para de perguntar "podemos deixar segurança para depois?" e passa a perguntar "qual o nível de risco que cada entrega carrega?". A segunda pergunta constrói produtos que duram.

Se a sua organização vem empurrando segurança para a próxima versão há vários ciclos, talvez já esteja acumulando a dívida que estes casos descrevem. Há outros artigos no blog sobre roadmap, LGPD e segurança que aprofundam como integrar isso. Se esse for um ponto sensível no seu produto, vale conversar antes que o assunto vire incidente.

Roadmap de produto digital: o que acontece quando a segurança fica de fora