Você faz o commit, abre o pull request e corre para a próxima task. O código funciona, os testes passam, o prazo está apertado. Mas uma linha de string concatenada com input do usuário fica ali, quieta, esperando.
Ninguém olha para ela. Nem o Code Review, porque todo mundo está sobrecarregado. Só que um dia alguém digita algo malicioso e a aplicação inteira escancara dados. O custo de consertar isso em produção não tem comparação com o custo de corrigir na hora.
Segurança de código parece assunto de especialista, mas é a diferença entre um sistema que entrega e um sistema que sobrevive. A pergunta certa não é “será que eu deixei uma porta aberta?” — é “qual porta aberta é mais barata de fechar agora?”
- Segurança de código é o conjunto de práticas e ferramentas que impedem falhas exploráveis desde a primeira linha até o runtime, com foco em detectar cedo para reduzir custo e risco.
- As ameaças mais comuns incluem injeção de SQL, XSS, controle de acesso quebrado, exposição de credenciais e dependências vulneráveis, conforme os catálogos OWASP Top 10 e CWE Top 25.
- Ferramentas SAST, DAST, SCA, secret scanning e análise de IaC se complementam: analisam código parado, aplicação em execução, dependências e configurações.
- Rotina de segurança viável para time pequeno inclui bloqueio de credenciais no pre-commit, auditoria de dependências no CI, revisão de pull request com checklist e no máximo 30 minutos por commit.
- A LGPD exige medidas técnicas de proteção de dados, e profissionais de AppSec no Brasil têm faixas salariais que vão de R$ 4,5 mil a mais de R$ 16 mil conforme senioridade.
- Como decidir entre SAST, DAST e SCA sem virar refém de relatório confuso.
- O que exatamente olhar em um pull request para cortar falhas óbvias em minutos.
- Por que credencial commitada é incidente anunciado — e como recuperar a chave antes do atacante.
- Qual rotina de segurança cabe em uma sprint apertada sem travar a entrega?
O código que funciona também pode ser o elo mais frágil
Segurança de código não é uma camada extra. É a forma como você escreve, revisa e integra cada linha. A maioria das falhas não nasce de um atacante sofisticado; nasce de uma condição não prevista em uma entrada de formulário.
Todo sistema lida com incerteza. Conexão de banco, upload de arquivo, redirecionamento de URL, serialização de objeto. Cada fronteira entre o input do usuário e a lógica interna é um terreno fértil para exploração.
O problema é que a pressão por entrega empurra a checagem para depois. Só que depois, em produção, a falha já encontrou dados reais e usuários reais.
Antes de abrir qualquer ferramenta, treine o olhar: para cada entrada de dado, pergunte “O que acontece se alguém enviar algo que eu não esperava?”. Esse hábito de 10 segundos elimina metade das falhas de aplicação.
O que é segurança de código e por que ela começa antes do commit
Segurança de código é o conjunto de práticas, processos e ferramentas que impedem a introdução e a propagação de falhas exploráveis no software, da escrita da primeira linha até o runtime. Ela existe porque software é feito por humanos, e humanos cometem erros previsíveis: confiam demais no input, esquecem de validar contexto, deixam credencial exposta.
O objetivo não é escrever código perfeito, impossível, mas reduzir a superfície de ataque e detectar falhas o quanto antes. O NIST SSDF organiza isso em práticas de governança, proteção e verificação. Já o OWASP ASVS transforma requisitos abstratos em itens auditáveis.
Uma definição direta: segurança de código é a disciplina de escrever software que se comporta como esperado mesmo quando alguém tenta forçá-lo a se comportar mal.
A conta que fecha: quanto custa corrigir uma falha em cada etapa
O custo de correção cresce exponencialmente ao longo do ciclo de desenvolvimento. Um defeito encontrado em revisão de código custa minutos de trabalho. O mesmo defeito em produção custa incidente, comunicação, auditoria e, no Brasil, risco regulatório sob a LGPD, cujo artigo 46 exige medidas técnicas e administrativas de proteção de dados.
Detectar no commit é a forma mais barata de lidar com vulnerabilidade. Detectar em produção é a mais cara. Essa lógica econômica sustenta toda a conversa sobre shift-left.
Shift-left na prática: o que muda no dia a dia do dev
Shift-left significa mover a segurança para as etapas iniciais do desenvolvimento, em vez de deixá-la como uma auditoria final. Na rotina, isso vira três hábitos: testar entrada maliciosa na própria máquina, revisar código pensando em fluxo de dados e integrar análise automatizada no pipeline de CI/CD.
DevSecOps é a materialização disso: segurança como responsabilidade compartilhada, não como portão final. Cada pull request vira uma oportunidade de detectar falha antes do merge.
Na minha leitura, o maior erro não é a ferramenta, é deixar a segurança para a véspera do deploy. A automação no pipeline só faz sentido se a mentalidade já estiver ali.
As ameaças que mais derrubam aplicações hoje
Os catálogos de referência organizam o esforço de defesa. O OWASP Top 10 lista as categorias de risco mais críticas em aplicações web. O CWE Top 25 ranqueia os tipos de fraqueza mais perigosos segundo dados reais de vulnerabilidade.
Injeção de SQL e comandos: o clássico que nunca sai de moda
Injeção acontece quando o input do usuário é interpretado como parte de um comando, e não como dado. O exemplo mais comum é a concatenação de string em consultas SQL. Forma vulnerável: query = "SELECT * FROM users WHERE email = '" + input + "'". Basta input ' OR 1=1 -- para listar todos os usuários.
Forma segura: usar consulta parametrizada ou ORM com bind de parâmetros. O banco passa a tratar o valor como dado literal, não como parte da sintaxe. Nenhuma concatenação de string com entrada do usuário.
Também existe injeção de comando em shell, LDAP, XPath e expressões de template. A defesa é sempre a mesma: separar dado de instrução por meio de parametrização ou bind de parâmetros, e validar a entrada com lista positiva.
XSS, SSRF e controle de acesso quebrado: os campeões do OWASP Top 10
XSS (Cross-Site Scripting) injeta script malicioso no navegador da vítima. SSRF (Server-Side Request Forgery) faz o servidor executar requisições para destinos internos não previstos. Controle de acesso quebrado permite que um usuário acesse dados ou ações de outro perfil.
Esses três aparecem repetidamente em relatórios de bug bounty. A correção começa com escaping de saída por contexto (HTML, atributo, JavaScript, SQL, shell), validação de URLs de redirecionamento e verificação de autorização no servidor em cada requisição — nunca escondida apenas na interface. Uma camada adicional de Content Security Policy com default-src restritivo limita de onde scripts e recursos podem carregar, reduzindo o impacto de XSS refletido ou armazenado.
Exposição de credenciais e dependências vulneráveis: os riscos invisíveis
Chave de API, senha de banco, token de serviço. Com uma busca no histórico do Git, o atacante encontra tudo. Dependência vulnerável é ainda pior: você não escreveu a falha, mas ela roda no seu servidor mesmo assim.
Ataques à cadeia de suprimentos exploram bibliotecas comprometidas. Por isso o uso de lockfile, auditoria contínua de dependências e exportação de SBOM em CycloneDX ou SPDX deixou de ser opcional.
Autenticação frágil: hash de senha com Argon2id e cookies seguros
Senha nunca deve ser armazenada em texto puro nem com MD5 ou SHA-1 puro. O recomendado é Argon2id com parâmetros de referência: memória de 64 MB, 3 iterações, paralelismo 4. Alternativa viável é bcrypt com custo 12.
Cookies de sessão devem ter HttpOnly (inacessível a JavaScript), Secure (apenas HTTPS) e SameSite=Lax ou Strict. Token de sessão precisa de pelo menos 128 bits de entropia real.
Desserialização insegura e SSRF: quando o ataque vem de dentro
Desserialização insegura ocorre quando dados serializados vindos do cliente são aceitos sem validação e podem disparar execução de código. SSRF faz o servidor acessar a própria infraestrutura interna, como metadados de nuvem.
Defesas: não aceitar serialização de fontes não confiáveis, usar lista positiva de classes permitidas e bloquear requisições para IPs privados e loopback em bibliotecas HTTP.
O que os dados da Verizon e da Orca Security revelam sobre incidentes
Relatório da Verizon aponta crescimento expressivo de incidentes originados em exploração de vulnerabilidades, não em phishing. Levantamento da Orca Security mostra que a maioria das organizações convive com vulnerabilidades severas em repositórios de código, prontas para ir a produção.
Além disso, pesquisa da Linux Foundation com desenvolvedores aponta que cerca de três em cada quatro sentem falta de tempo para tratar segurança. Isso explica por que a automação dentro do pipeline venceu a discussão contra a revisão manual isolada.
Esses números reforçam algo que observo em revisão de código: a pressa em entregar é a principal aliada da vulnerabilidade.
SAST, DAST e SCA sem enrolação: qual usar e quando
Essas três categorias cobrem espectros diferentes da aplicação. SAST olha o código parado. DAST testa a aplicação em execução. SCA mapeia dependências. Juntas, formam a espinha dorsal de um programa de segurança de aplicação.
SAST: análise estática que enxerga o fluxo de dados no código
Ferramentas como Semgrep, SonarQube e CodeQL analisam o código-fonte sem executá-lo. Elas rastreiam fluxo de dados entre arquivos e identificam padrões de injeção, XSS e uso inseguro de bibliotecas.
É a categoria que melhor se encaixa no pull request, porque o feedback vem em minutos. O desafio é a taxa de falso positivo: alta se a regra for mal calibrada.
DAST: teste dinâmico que simula o atacante em execução
Ferramentas como OWASP ZAP e Burp Suite executam a aplicação e disparam requisições maliciosas contra ela. Assim, encontram falhas que só aparecem em runtime, como autenticação quebrada e exposição de endpoints.
DAST não enxerga o código, por isso é cego para algumas falhas de lógica, mas é excelente para validar configuração e comportamento externo. Deve rodar em ambiente de homologação, nunca em produção descontrolada.
SCA: o mapa das dependências vulneráveis e a SBOM
SCA analisa o lockfile e o manifesto de dependências para identificar versões com CVEs conhecidas. Ferramentas como Dependabot, Trivy e Snyk automatizam isso no CI e no repositório.
O resultado maduro é a SBOM (Software Bill of Materials) em CycloneDX ou SPDX, um inventário formal de tudo que compõe o software. Empresas grandes já exigem esse anexo contratual.
Na minha leitura, ter um SBOM é menos sobre obrigação contratual e mais sobre saber exatamente o que você está rodando. Para time pequeno, comece com auditoria de dependências e só depois evolua para automação de pipeline.
Secret scanning: o guarda-costas do repositório
GitGuardian, gitleaks e TruffleHog são exemplos. Eles varrem o histórico do Git em busca de padrões de chave, token e senha. O ideal é rodar no pre-commit hook, bloqueando antes que a credencial entre.
GitHub e GitLab oferecem versões gratuitas em repositórios públicos, o que tornou o recurso padrão de mercado.
Quem domina essas ferramentas e a lógica por trás delas encontra espaço em vagas de analista de segurança de aplicações. No Brasil, júnior fica na faixa de R$ 4,5 mil a R$ 7 mil, pleno entre R$ 9 mil e R$ 15 mil e sênior acima de R$ 16 mil, com boa parte das vagas exigindo vivência em SAST, SCA e revisão de código.
Credenciais fora do repositório: como evitar vazamento de chaves
GitGuardian, gitleaks e TruffleHog: bloqueio no pre-commit
O melhor lugar para detectar credencial é antes do commit. Configure um hook local de pre-commit com gitleaks ou TruffleHog. Se a string bater com padrão de chave, o commit é bloqueado na hora.
Isso vale para todo o time. Ferramentas de secret scanning no servidor também varrem pushes já realizados, mas aí a credencial já entrou no histórico.
O que fazer se uma credencial já foi commitada (e por que trocar a chave é urgente)
Se a credencial foi commitada, a primeira ação é considerar a chave comprometida e rotacioná-la imediatamente. Depois, remova do código atual e do histórico com ferramentas de limpeza de repositório. Mas rotacionar é o passo crítico: apagar do Git não apaga dos clones já existentes.
Comunique o incidente conforme a política interna. Se for chave de produção, o tempo de rotação é a janela de exposição real.
Cofres de credenciais: HashiCorp Vault e variáveis de ambiente seguras
Credenciais nunca devem estar em arquivo de configuração versionado. Variáveis de ambiente resolvem o caso simples, mas cofres como HashiCorp Vault oferecem rotação automática, controle de acesso fino e trilha de auditoria.
Para time pequeno, comece com variáveis de ambiente protegidas e um arquivo .env fora do repositório, com um modelo .env.example versionado. A medida mais importante: a credencial real não pode estar no Git.
Eu confesso que já entreguei código com a sensação de que algo estava errado, mas sem tempo para investigar. Depois de alguns incidentes, entendi que segurança não é fase, é postura. A maior mentira que contam para quem está começando é que você precisa dominar criptografia avançada para fazer diferença. Na verdade, os controles que mais evitam dano são simples: parametrizar consulta, validar entrada no servidor, não commitar credencial. O que muda o jogo é consistência, não genialidade.
Outra coisa que aprendi: ferramenta nenhuma substitui o olhar crítico. Ela aponta, mas quem decide o que é aceitável é você. E essa decisão precisa de critério técnico, não de medo. Por isso, a seguir, os cuidados e mitos que normalmente ficam fora das apostilas.
Dicas práticas para aproveitar segurança de código no dia a dia
A disciplina de escrever software seguro nasceu da necessidade de lidar com falhas exploráveis em sistemas conectados. No fim dos anos 90, buffer overflow em aplicações C se tornou crise de segurança. Com a web, a superfície de ataque explodiu, e a comunidade passou a sistematizar as falhas mais comuns em catálogos como OWASP.
Hoje, a segurança de código vai além da aplicação: inclui infraestrutura como código, pipeline de build e cadeia de suprimentos. A prática se estendeu do analista de segurança para o desenvolvedor, porque ninguém conhece melhor o fluxo de dados de uma função do que quem a escreveu.
Uma dúvida frequente: preciso ser especialista para escrever código seguro? Não. Preciso entender o básico de ameaças comuns e aplicar controles simples. Projeto pequeno não é desculpa: atacante automatizado não distingue tamanho, apenas oportunidade.
| Mito | Realidade |
|---|---|
| Framework moderno resolve tudo | Framework reduz, mas não elimina: configuração errada e código customizado ainda geram falhas. |
| Segurança é responsabilidade só do time de segurança | Segurança é qualidade. Quem escreve o código é a primeira linha de defesa. |
| Ferramenta de SAST só gera falso positivo | Taxa de falso positivo é real, mas filtrar por severidade e contexto transforma o relatório em ativo. |
| Meu projeto não interessa a atacante | Ataques automatizados escaneiam a internet inteira. Vulnerabilidade conhecida é alvo, independente do tamanho. |
Erros comuns e como evitá-los
- Concatenação de input em SQL ou shell — use parametrização ou bind de parâmetros, sempre.
- Committar .env, chave de API ou token — configure pre-commit hook de secret scanning e use variáveis fora do repositório.
- Ignorar atualização de dependências — rode npm audit ou pip-audit no CI e aceite PR de correção automática.
- Confiar só em validação no frontend — toda validação crítica precisa ser repetida no servidor.
- Não revisar código com olhar de atacante — no pull request, pergunte: qual é o pior input possível para esta função?
- Sem rate limiting em login — adicione limitação progressiva e bloqueio temporário para impedir força bruta.
Três decisões que transformam segurança de código em rotina real
O Essencial em 3 Passos
- 01 A Escolha Certa: Comece pela dependência e pelas credenciais, não pela análise estática complexa. Instale secret scanning no pre-commit e auditoria de dependências no CI hoje. Essas duas ações eliminam a maior parte do risco com menos de uma hora de configuração.
- 02 Ponto de Atenção: Não tente zerar todos os alertas de SAST na primeira semana. Filtre por severidade crítica e por arquivos que você acabou de mexer. Falso positivo existe, mas ignorar o relatório inteiro é pior.
- 03 Na Prática: Antes do próximo commit, rode o checklist: credencial fora do código, consulta parametrizada, senha com hash forte, dependência auditada, log sem dado pessoal. Leva 5 minutos e bloqueia a falha mais comum.
Três cenários brasileiros mostram que o primeiro passo muda conforme o porte: freelancer solo no Node deve priorizar auditoria de dependências e bloqueio de credenciais; squad de quatro em fintech precisa adicionar revisão de pull request com checklist e exportar SBOM; time de doze com Kubernetes precisa integrar análise de Infrastructure as Code e assinatura de imagem. O erro que queima a iniciativa nunca é a falta de ferramenta, é tentar implementar tudo na primeira semana sem dono e sem meta de severidade.
Escrever código seguro é uma decisão diária de atenção, não um projeto com fim. Cada commit é uma chance de reduzir a superfície de ataque.
Comece pequeno: bloqueie credenciais, audite dependências e revise criticamente as fronteiras de entrada. O mercado paga por essa maturidade, e a LGPD exige.
Não espere o incidente para provar que segurança importa. A falha que você encontra no pull request custa minutos; a mesma falha em produção custa reputação e dados.
O que pouca gente sabe: Segurança de código não reduz o número de bugs; ela reduz o raio do estrago quando um bug aparece. Um sistema seguro falha em um quarto fechado, não no salão principal.
