Segurança dentro do desenvolvimento, não só no final
Levamos a segurança para dentro do desenvolvimento: modelagem de ameaças, revisão de código, varredura de dependências e de segredos e verificações automáticas a cada mudança.
Para quem é
Para empresas que tratam dados ou dinheiro de clientes e só olham a segurança quando algo acontece.
O que resolve
- Uma chave de acesso foi parar no repositório, e ninguém sabe desde quando.
- Uma falha conhecida numa biblioteca fica meses no sistema sem ninguém perceber.
- Um cliente grande mandou um questionário de segurança, e ninguém sabe responder.
- A segurança só é discutida depois do incidente, nunca no desenho da funcionalidade.
O que fazemos
- Modelagem de ameaças
- Para cada funcionalidade sensível, o que pode dar errado, quem ganharia com isso e como impedir.
- Revisão de código seguro
- Revisão focada em autenticação, autorização, validação de entrada e tratamento de dados sensíveis.
- Dependências e segredos
- Varredura de bibliotecas com falhas conhecidas e de chaves esquecidas no código e no histórico.
- Verificações no pipeline
- Análise estática e de dependências a cada mudança, dentro do pipeline de publicação.
- Referências abertas
- Os guias da OWASP servem de referência para os controles; isso não é uma declaração de conformidade.
- Correção de achados
- Achados de testes de invasão feitos por terceiros, priorizados e corrigidos com teste de regressão.
O que você recebe
- Modelo de ameaças das funcionalidades sensíveis
- Verificações de código, dependências e segredos rodando no pipeline
- Relatório da revisão de segurança, com prioridade e correção sugerida
- Plano de correção dos achados, acompanhado até o fechamento
- Respostas técnicas para os questionários de segurança dos seus clientes
Como fazemos
Mapa de riscos
Dados sensíveis, pontos de entrada e quem pode fazer o quê no sistema.
Modelagem de ameaças
Sessões curtas com a equipe sobre as funcionalidades de maior risco.
Verificações automáticas
As análises entram no pipeline, primeiro avisando, depois bloqueando o que é grave.
Correção
Achados priorizados por risco e corrigidos junto com o trabalho normal.
Teste independente
Quando for o caso, um teste de invasão feito por terceiros confere o resultado.
Exemplos de tecnologia
- OWASP ASVS
- Semgrep
- Trivy
- Gitleaks
- Dependabot
- ZAP
Serviços relacionados
Perguntas frequentes
Quem faz o teste de invasão?
Um especialista independente, contratado por você ou definido no projeto, com autorização formal. A Balkan prepara o ambiente e o escopo técnico, responde às dúvidas e corrige o que for encontrado.
Depois disso o sistema fica seguro?
Nenhum trabalho elimina todo risco. O que muda é que as falhas conhecidas são procuradas o tempo todo, e não só depois de um incidente, e cada achado tem dono e prazo de correção.
Vocês ajudam com questionários de segurança de clientes?
Na parte técnica, sim: como os dados são guardados, quem tem acesso, como as mudanças são publicadas. Declarações em nome da empresa e cláusulas de contrato ficam com o seu jurídico.
Isso substitui uma auditoria ou uma certificação?
Não. É trabalho de engenharia feito dentro do desenvolvimento, e a Balkan não emite certificação. Para ver o estado do sistema num momento, existe a auditoria técnica.
Escreva para a Balkan
Falar sobre o seu projeto