Desenvolvimento seguro de software: o que exigir do fornecedor

A proposta do fornecedor tem uma linha que diz "o sistema seguirá as boas práticas de segurança". O projeto anda, o sistema entra no ar e, meses depois, alguém descobre que a senha do banco de dados estava escrita no código, que a base de homologação era uma cópia da produção com CPF e telefone de todos os clientes e que uma biblioteca usada no login tem uma falha conhecida há tempos. Ninguém mentiu. Só que "boas práticas" não dizia quais.

Esse é o problema central da segurança em projetos de software contratados: o gestor não consegue auditar o código, e o fornecedor raramente é cobrado por algo que não foi escrito. O resultado é que a segurança fica dependendo da disciplina de cada desenvolvedor, num dia bom ou num dia de prazo apertado.

Desenvolvimento seguro de software é o conjunto de práticas que a equipe aplica em todas as etapas do projeto, do desenho à manutenção, para evitar que falhas de segurança cheguem ao sistema em produção. Para quem contrata, a saída não é aprender a programar. É exigir práticas que deixam rastro: coisas que existem ou não existem, que aparecem num relatório, num repositório ou numa reunião. Este texto traz um checklist de desenvolvimento seguro de software que você pode colocar na proposta, no contrato e na pauta de acompanhamento do projeto.

O checklist em uma tabela

Antes dos detalhes, a resposta direta. Estas são as práticas que um fornecedor sério deve conseguir demonstrar, e a evidência que você pode pedir para cada uma:

Se o fornecedor responde com documentos e telas, ótimo sinal. Se responde "pode ficar tranquilo", você ainda não sabe nada.

Segurança não é etapa final do projeto

Um erro comum de planejamento é tratar segurança como uma fase: o sistema fica pronto e, antes de ir ao ar, alguém "faz um teste de segurança". Esse teste tem valor, mas chega tarde. Se ele encontra uma falha de desenho, como uma regra de permissão que só existe na tela e não no servidor, a correção pode exigir mexer em dezenas de pontos do sistema com o prazo já estourado.

Desenvolvimento seguro é o contrário: pequenos controles aplicados em toda entrega, desde a primeira semana. Na prática, isso começa no desenho:

• Quem pode fazer o quê está definido antes de as telas serem construídas, com perfis e permissões descritos por regra de negócio. O detalhamento está em perfis de acesso e trilha de auditoria.
• Quais dados são sensíveis está mapeado: dados pessoais, financeiros, de saúde, segredos comerciais. Isso define o que precisa de criptografia, de registro de acesso e de cuidado extra. A parte que a LGPD exige do sistema está em LGPD no software.
• Por onde o sistema conversa com o mundo está listado: APIs, integrações com ERP, banco, gateway de pagamento, aplicativo. Cada porta é uma superfície a proteger.

Pergunte ao fornecedor em que momento do projeto essas três coisas são discutidas. A resposta certa é "no começo".

Revisão de código e dependências

Revisão por outra pessoa, sempre

Nenhuma linha deveria chegar à produção sem que uma segunda pessoa tenha lido. A revisão de código pega erro de lógica, regra esquecida, consulta que devolve dado demais e atalhos perigosos que o autor, com pressa, não percebe.

O que exigir:

• O repositório tem proteção no ramo principal do código (a branch principal): ninguém publica direto, nem o líder técnico.
• Cada alteração passa por um pedido de alteração (pull request) com aprovação registrada de alguém que não escreveu o código.
• Existe um roteiro mínimo de revisão que inclui segurança: validação de entrada, autorização no servidor, tratamento de erro sem expor detalhes internos.

Como conferir: peça acesso de leitura ao repositório desde o início do projeto (isso também é uma questão de propriedade do código-fonte) e abra alguns pull requests ao acaso. Você não precisa entender o código para ver se houve aprovação e comentários.

Bibliotecas de terceiros

Um sistema moderno usa dezenas ou centenas de bibliotecas prontas: para gerar PDF, ler planilha, autenticar usuário, conversar com o banco. Cada uma delas pode ter uma falha publicada e corrigida em versão mais nova. O código da sua empresa pode estar impecável e o sistema continuar vulnerável por causa de uma dependência desatualizada.

O que exigir:

• Varredura automática de dependências em toda entrega, com ferramentas que comparam as versões usadas com bases públicas de vulnerabilidades conhecidas.
• Critério de tratamento: falha crítica bloqueia a publicação; falha média entra na lista de pendências com prazo.
• Lista das dependências do sistema (o chamado inventário de componentes, ou SBOM), entregue junto com o código. Ela permite saber rapidamente se o seu sistema é afetado quando uma falha grande vira notícia.

Gestão de segredos e acessos ao ambiente

Segredo não mora no código

Senha do banco, chave da API de pagamento, token de acesso ao ERP, certificado digital para emissão de nota fiscal: tudo isso é segredo. Se está escrito no código-fonte, qualquer pessoa com acesso ao repositório tem acesso à produção, incluindo ex-funcionários do fornecedor, prestadores temporários e quem herdar o projeto depois.

O que exigir:

• Segredos ficam em um cofre de segredos ou nas variáveis protegidas da plataforma de nuvem, nunca em arquivo versionado.
• O repositório passa por varredura de segredos a cada alteração, para pegar a chave colada por engano.
• Cada ambiente tem segredos próprios: a senha da homologação não abre a produção.
• Existe um procedimento de troca (rotação) de segredos, usado quando alguém sai da equipe ou quando há suspeita de vazamento.

Quem acessa o quê

Pergunte quantas pessoas do fornecedor têm acesso ao servidor de produção e ao banco de dados. Se a resposta for "todo mundo do time", há um problema.

• Acesso individual e nominal, nunca um usuário compartilhado como "admin" ou "dev".
• Mínimo privilégio: o desenvolvedor de interface não precisa de acesso ao banco de produção.
• Autenticação em dois fatores nas contas de nuvem, repositório e painéis administrativos.
• Contas da nuvem em nome da sua empresa, com o fornecedor como convidado. Assim, encerrar o contrato é revogar acessos, e não pedir de volta a chave da casa.
• Procedimento de saída: quando alguém deixa o projeto, os acessos são removidos no mesmo dia, e isso fica registrado.

Testes de segurança automatizados

Teste manual de segurança, feito uma vez antes do lançamento, envelhece na primeira versão seguinte. O que protege o sistema ao longo do tempo é a automação dentro da esteira de entrega (o pipeline, que testa e publica cada versão), rodando sempre que alguém altera o código.

As camadas mais comuns:

• Análise estática (SAST): lê o código-fonte e aponta padrões perigosos, como consulta ao banco montada com texto digitado pelo usuário.
• Análise de dependências: a varredura de bibliotecas descrita acima, agora como etapa obrigatória.
• Varredura de segredos: impede que uma chave entre no repositório.
• Análise dinâmica (DAST): testa o sistema rodando em homologação, como um visitante faria, procurando falhas de configuração e de entrada de dados.
• Testes de autorização escritos pela equipe: para cada operação sensível, um teste em que um usuário sem permissão tenta executá-la e precisa ser recusado. Ferramenta genérica nenhuma conhece as regras do seu negócio; esse teste é o que pega o caso "o vendedor da filial A consegue ver a comissão da filial B". Os erros que mais aparecem nessa área estão em segurança de APIs.

O que exigir não é uma ferramenta específica, e sim o resultado: cada versão publicada tem um relatório de segurança, e falha crítica impede a publicação. Peça para ver esse relatório nas reuniões de acompanhamento.

Para sistemas que lidam com dados sensíveis ou dinheiro, vale combinar também um teste de intrusão feito por terceiros independentes antes do lançamento e periodicamente depois. Ele não substitui a automação; complementa.

Ambientes separados e dados de teste

Três ambientes, três portas

O mínimo saudável são três ambientes isolados:

1. Desenvolvimento, onde a equipe experimenta.
2. Homologação, uma réplica da produção em configuração, onde a sua equipe valida as entregas.
3. Produção, onde estão os usuários reais e os dados reais.

Isolados significa: bancos diferentes, credenciais diferentes, e uma falha em homologação sem nenhum caminho até a produção. Publicar em produção acontece pelo pipeline, com registro de quem publicou e o quê, e não por alguém copiando arquivos para o servidor.

Dado real fora da produção é vazamento esperando acontecer

É tentador testar com uma cópia do banco de produção: os dados são realistas e os bugs aparecem. O problema é que ambientes de teste costumam ter controles mais frouxos, mais gente com acesso e menos monitoramento. Uma cópia com nome, CPF, endereço e histórico de compra dos seus clientes num ambiente desses amplia muito o risco: se alguém sem autorização acessar esses dados, é um incidente de segurança que a LGPD exige tratar e, conforme a gravidade, comunicar à ANPD e aos titulares.

O que exigir:

• Massa de dados fictícia para desenvolvimento e homologação, gerada com volume e variedade parecidos com os reais.
• Quando for indispensável usar uma cópia da produção, mascaramento: nomes, documentos, e-mails e telefones substituídos antes de os dados saírem da produção.
• Regra escrita sobre quem pode autorizar uma exceção e por quanto tempo.

Atualizações e correções após a entrega

O sistema entra no ar e o projeto termina, mas as vulnerabilidades continuam sendo descobertas. Uma biblioteca segura no dia do lançamento pode ter uma falha publicada seis meses depois. Sem alguém responsável por acompanhar e atualizar, o sistema fica mais exposto a cada mês, sem que nada no código tenha mudado.

Defina antes de assinar:

• Quem monitora as vulnerabilidades das dependências depois da entrega.
• Prazos de correção por gravidade: crítica em dias, alta em poucas semanas, média no ciclo normal de manutenção. Os números exatos são negociáveis; o que importa é que estejam escritos.
• Atualização periódica de linguagem, framework, banco de dados e sistema operacional, antes que saiam de suporte.
• Registro de incidentes: o que aconteceu, o que foi feito e o que mudou para não repetir.

Esse trabalho normalmente faz parte de um contrato de manutenção evolutiva. Se não houver contrato de manutenção, combine ao menos um pacote mínimo de atualizações de segurança.

Como colocar isso no contrato

Prática que não está escrita vira favor. Algumas formas de transformar o checklist em compromisso:

• Anexo técnico de segurança na proposta, listando as práticas da tabela acima. Peça que o fornecedor marque o que já faz por padrão e o que seria adicional.
• Critério de aceite por entrega: uma versão só é considerada entregue se passou pelas verificações automáticas sem falha crítica pendente.
• Acesso ao repositório e ao pipeline desde o início, com o código em conta da sua empresa.
• Entrega de documentação ao final: arquitetura, lista de dependências, procedimento de publicação, inventário de segredos (os nomes, não os valores) e acessos ativos.
• Obrigação de comunicar incidentes de segurança em prazo curto, com a descrição do que foi afetado, o que é essencial para a empresa cumprir as próprias obrigações perante a LGPD. Valide a redação com seu jurídico.
• Prazos de correção pós-entrega por gravidade, como descrito acima.

Na hora de comparar propostas, use o checklist como critério. Uma proposta mais enxuta pode simplesmente estar deixando essas práticas de fora. Outros critérios para avaliar fornecedores estão em como escolher uma software house.

Perguntas para a reunião com o fornecedor

• Posso ver um pull request recente de outro projeto, com a revisão registrada?
• Que ferramentas rodam no pipeline e o que acontece quando apontam uma falha crítica?
• Onde ficam as senhas e chaves dos sistemas que vocês mantêm hoje?
• Quantas pessoas da sua equipe teriam acesso à nossa produção?
• Com que dados vocês testam?
• Depois da entrega, quem acompanha as vulnerabilidades novas, e em quanto tempo corrigem?

Respostas vagas para mais de duas dessas perguntas indicam que a segurança depende de boa vontade, não de processo.

Perguntas frequentes

Qual a diferença entre SAST e DAST?

SAST, ou análise estática, lê o código-fonte sem executá-lo e aponta padrões perigosos, como consulta ao banco montada com texto digitado pelo usuário. DAST, ou análise dinâmica, testa o sistema em funcionamento, normalmente em homologação, como um visitante faria. Os dois se complementam e devem rodar de forma automática no pipeline de entrega do fornecedor.

Preciso contratar um teste de intrusão para o meu sistema?

Para sistemas que lidam com dados sensíveis ou dinheiro, sim. O teste de intrusão, ou pentest, é feito por especialistas independentes que tentam explorar falhas antes do lançamento e periodicamente depois. Ele não substitui as verificações automáticas feitas a cada entrega; complementa, porque costuma encontrar falhas de lógica e de configuração que ferramentas genéricas não pegam.

O que é SBOM no desenvolvimento de software?

SBOM é o inventário de componentes de software, a lista de bibliotecas e versões usadas no sistema. Exigir o SBOM junto com o código permite saber rapidamente se o seu sistema é afetado quando uma falha grave numa biblioteca vira notícia. O inventário também ajuda a controlar dependências desatualizadas ao longo da manutenção.

Posso usar uma cópia do banco de produção para testar o sistema?

Não é recomendável. Ambientes de teste costumam ter controles mais frouxos e mais gente com acesso, e uma cópia com dados pessoais de clientes amplia muito o risco de incidente sob a LGPD. O certo é usar massa de dados fictícia e, quando a cópia for indispensável, mascarar nomes, documentos, e-mails e telefones antes de os dados saírem da produção.

Como saber se um fornecedor de software segue práticas de segurança?

Peça evidências, não promessas. Um fornecedor de software que pratica desenvolvimento seguro consegue mostrar pull requests com revisão registrada, relatórios de varredura de dependências e de segredos, cofre de senhas configurado, ambientes separados e massa de dados fictícia. Se as respostas forem vagas em vários desses pontos, a segurança depende de boa vontade, não de processo.

Como a Pervian Tech trabalha desenvolvimento seguro

Na Pervian Tech, desenvolvimento seguro faz parte do nosso trabalho de arquitetura de software desde a primeira semana do projeto: começamos mapeando dados sensíveis, perfis de acesso e integrações, e montamos o repositório e o pipeline com revisão obrigatória, varredura de dependências e de segredos, ambientes separados e massa de dados fictícia. O código e as contas de nuvem ficam em nome do cliente, e cada versão publicada vem com o registro do que foi verificado.

Cada projeto é sob medida, e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito em que entendemos o sistema, os dados envolvidos e o nível de exigência do seu setor. Também revisamos sistemas já em produção para mostrar onde estão as lacunas. Mais conteúdo sobre o tema está em segurança e LGPD. Se você vai contratar um sistema e quer saber o que exigir, fale com a gente.