Segurança de software não é um teste aplicado no fim. É um processo contínuo para preparar a organização, proteger componentes, produzir software com menos vulnerabilidades e responder ao que ainda surgir. O NIST SSDF organiza essas práticas; o OWASP Top 10 ajuda a reconhecer riscos críticos de aplicações web.

Nenhum checklist torna um sistema “100% seguro”. Ele cria evidência, prioridade e responsabilidade. O nível de controle deve refletir dados, impacto e contexto.

Segurança como processo

Risco não é apenas falha técnica

Risco combina ameaça, vulnerabilidade, probabilidade e impacto no negócio. O mesmo erro pode ser pequeno em catálogo público e grave em prontuário ou financeiro.

Classifique:

dados armazenados;
usuários e privilégios;
integrações;
operações irreversíveis;
disponibilidade necessária;
obrigações contratuais e regulatórias;
impacto em pessoas e clientes.

O NIST SSDF

O framework agrupa práticas em:

Prepare the Organization: pessoas, processos e tecnologia preparados;
Protect the Software: código, componentes e artefatos protegidos;
Produce Well-Secured Software: requisitos, design, implementação e verificação;
Respond to Vulnerabilities: identificar, corrigir e prevenir recorrência.

Ele é orientado a resultados, não a uma ferramenta específica.

Checklist de segurança baseado em preparar, proteger, produzir e responder — Guia visual LTA: segurança de software.

O que o OWASP Top 10:2025 destaca

A edição 2025 lista:

Broken Access Control;
Security Misconfiguration;
Software Supply Chain Failures;
Cryptographic Failures;
Injection;
Insecure Design;
Authentication Failures;
Software or Data Integrity Failures;
Security Logging and Alerting Failures;
Mishandling of Exceptional Conditions.

Controle de acesso permanece central

Usuário autenticado não pode acessar qualquer objeto. A aplicação valida função, tenant, propriedade e estado no servidor. Trocar ID na URL ou payload não deve expor outro registro.

Isso é crítico em sistemas multiempresa como a Atalaia, que organiza dados por empresa e perfis.

Cadeia de suprimentos ganhou destaque

Software depende de bibliotecas, imagens de container, serviços e ferramentas de build. Inventário, origem, atualização e integridade desses componentes fazem parte da segurança.

Condições excepcionais precisam de desenho

Timeout, falta de recurso, resposta parcial e estado inesperado não podem deixar operação inconsistente ou revelar detalhes. O caminho de erro merece teste.

Antes de desenvolver

Defina requisitos de segurança

Escreva critérios verificáveis:

quem pode acessar cada função;
quais dados precisam de proteção;
retenção e exclusão;
autenticação e recuperação;
auditoria;
disponibilidade e recuperação;
dependências e integrações;
resposta a incidente.

“Aplicação segura” não é requisito testável.

Faça threat modeling

Mapeie ativos, atores, fronteiras de confiança, fluxos e abusos. Pergunte como alguém poderia:

acessar objeto de outro usuário;
elevar privilégio;
manipular fluxo;
extrair dados em massa;
induzir integração a chamar destino interno;
duplicar pagamento ou transmissão;
interromper serviço;
comprometer dependência.

Defina ambientes e acessos

Separe desenvolvimento, homologação e produção. Produção deve ter acesso mínimo, MFA, registro e processo emergencial. Não copie dados reais sem necessidade e proteção.

Planeje segredos

Tokens e senhas não pertencem ao repositório. Use cofre, rotação, escopo e expiração. Credencial de desenvolvimento não deve acessar produção.

Durante o desenvolvimento

Autenticação e sessão

MFA para perfis sensíveis;
política de senha quando aplicável;
proteção de recuperação;
cookies seguros;
expiração e revogação;
defesa contra enumeração e força bruta;
mensagens sem revelar contas.

Autorização em toda ação

Negue por padrão. Teste usuários com papéis diferentes, objetos de outro dono e outro tenant. Interface esconder botão não substitui controle no backend.

No Portal do Cliente, acesso limitado deve ser aplicado também aos downloads e APIs, não só ao menu.

Validação e injeção

Use consultas parametrizadas, validação por allowlist e encoding conforme destino. Não execute entrada como comando. Upload exige tipo, tamanho, armazenamento e verificação.

Criptografia

Use protocolos e bibliotecas consolidados. Proteja trânsito e dados sensíveis em repouso conforme risco. Gerencie chaves separadamente e planeje rotação. Não crie algoritmo próprio.

Dependências e build

inventário de componentes;
versões fixadas de modo controlado;
análise de vulnerabilidade;
revisão de atualizações;
proteção do pipeline;
assinatura/proveniência quando aplicável;
acesso mínimo para automação.

Revisão e testes

Combine revisão de código, análise automatizada, testes de unidade/integração e testes de abuso. Scanner não entende todas as regras de negócio.

O Auto Gestor, por exemplo, precisa testar autorização e consistência em estoque, venda, financeiro e frota, não apenas formulário.

Antes do lançamento

Configuração segura

debug desativado;
mensagens de erro sem stack trace;
serviços e portas desnecessários removidos;
headers e TLS configurados;
permissões revisadas;
credenciais de padrão eliminadas;
CORS restrito;
backups configurados;
logs e alertas ativos.

Teste de restauração

Backup criado não prova recuperação. Restaure em ambiente controlado, valide integridade e registre tempo. Defina RPO e RTO coerentes com negócio.

Plano de incidente

Tenha contatos, severidade, contenção, comunicação, preservação de evidência, recuperação e retrospectiva. Simule antes de precisar.

Go/no-go

Riscos conhecidos devem ter responsável e decisão explícita. Não esconda vulnerabilidade para cumprir data.

Depois do lançamento

Monitore sinais técnicos e de negócio

Erros de autenticação, falhas de autorização, alteração de permissão, exportação incomum, filas, latência e indisponibilidade precisam de visibilidade. Alerta deve ser acionável.

Atualize e responda

Mantenha inventário, acompanhe vulnerabilidades, priorize por exposição e impacto, teste patch e faça rollout com rollback. Ofereça canal para relato responsável.

Aprenda com incidentes

Corrigir sintoma não basta. Investigue causa, condições, falha de detecção e outros locais semelhantes. Atualize requisitos, testes e processo.

Conheça o ecossistema de software da LTA para contextualizar requisitos por produto e operação.

Como avaliar um fornecedor

Peça explicação e evidência sobre:

arquitetura e isolamento;
identidade e acesso;
SDLC seguro;
inventário e dependências;
testes;
logs e auditoria;
backups e restauração;
resposta a incidente;
atualização;
exportação e encerramento;
subfornecedores.

Evite perguntas que aceitam “sim” como resposta. Em vez de “tem backup?”, pergunte quando a restauração foi testada, qual escopo e quem responde.

Como responder a um incidente sem ampliar o dano

Mesmo com prevenção, a organização precisa estar pronta para detectar e conter um incidente. O plano deve indicar responsáveis técnicos e de negócio, canal de emergência, critérios de severidade e autoridade para bloquear credenciais, limitar recursos ou interromper temporariamente uma função. Descobrir esses papéis durante a crise aumenta tempo de resposta e favorece decisões contraditórias.

Preserve evidências antes de apagar rastros. Logs, horários, identificadores de sessão, alterações de permissão e versões implantadas ajudam a entender escopo e causa. O acesso a esse material deve ser restrito, e a coleta precisa respeitar privacidade e obrigações aplicáveis. A comunicação externa não deve especular: informe o que foi confirmado, qual proteção foi tomada e quando haverá nova atualização.

Aprendizado após a contenção

Depois de restaurar a operação, faça uma análise sem procurar culpados. Identifique a sequência de eventos, os controles que funcionaram, os sinais ignorados e as mudanças necessárias em código, processo, treinamento e monitoramento. Cada ação precisa de responsável e prazo. Também revise se o mesmo padrão existe em outros módulos ou clientes; corrigir somente o ponto visível pode deixar a causa intacta.

Teste o plano com exercícios periódicos. Uma simulação de credencial comprometida ou dependência vulnerável revela contatos desatualizados, permissões excessivas e backups que nunca foram restaurados. Segurança melhora quando o ciclo de prevenção, detecção, resposta e aprendizado é praticado, não quando existe apenas em um documento arquivado.

Erros comuns

Segurança apenas no pentest final. Design inseguro pode exigir reconstrução.
Confiar no menu. Backend precisa autorizar.
Manter segredo no código. Histórico permanece.
Scanner como garantia. Ferramenta não cobre lógica.
Backup sem restauração. Cópia pode estar incompleta.
Não inventariar dependências. Vulnerabilidade passa despercebida.
Logar dados sensíveis. Controle vira risco.
Sem processo de patch. Descoberta não gera correção.
Prometer 100% seguro. Risco precisa ser gerido continuamente.

Checklist consolidado

Governança

[ ] Dados, impacto e tolerância a risco foram classificados.
[ ] Requisitos e responsáveis estão documentados.
[ ] Threat modeling foi realizado.

Desenvolvimento

[ ] Ambientes e acessos estão separados.
[ ] Segredos usam armazenamento adequado.
[ ] Autenticação e autorização foram testadas.
[ ] Entradas, uploads e saídas são validados.
[ ] Dependências e pipeline estão protegidos.
[ ] Testes incluem abuso e erro.

Produção

[ ] Configuração segura foi revisada.
[ ] Logs e alertas estão ativos.
[ ] Backup e restauração foram testados.
[ ] Existe plano de incidente e rollback.
[ ] Atualização e vulnerabilidades têm processo.
[ ] Exportação e encerramento estão definidos.

Perguntas frequentes

OWASP Top 10 é certificação?

Não. É documento de conscientização sobre riscos críticos. Pode orientar requisitos e testes, mas não certifica um sistema.

Pentest garante segurança?

Não. É uma fotografia limitada por escopo e tempo. Complementa design, revisão, testes, monitoramento e atualização.

Qual o risco mais comum?

Depende do sistema. Broken Access Control lidera o OWASP Top 10:2025, mas cada organização deve avaliar contexto e impacto.

Quem atualiza dependências?

O contrato e operação devem definir. Mesmo terceirizando, a organização precisa entender responsabilidade, prazo e evidência.

Backup faz parte da segurança?

Sim. Disponibilidade e recuperação são componentes de resiliência. A restauração precisa ser testada.

Vai contratar ou modernizar um sistema?

Converse com a LTA no WhatsApp para estruturar requisitos proporcionais ao risco. Use também a página de contato para enviar contexto.