Ataque de supply chain acontece quando uma dependência de terceiro — biblioteca, pacote, ferramenta que seu projeto usa — é comprometida na origem, e o código malicioso chega a todo mundo que instala ou atualiza aquele pacote. É um risco que todo projeto corre, mesmo escrevendo código próprio impecável.
Por que isso preocupa mais do que parece
Um projeto Laravel médio depende de centenas de pacotes via Composer, cada um com suas próprias dependências. Confiar cegamente em atualização automática de todos eles é assumir um risco que a maioria dos times nem percebe que está correndo — o mesmo tipo de vulnerabilidade silenciosa que discuto em OWASP na prática.
O que já faço pra reduzir esse risco
Reviso changelog antes de atualizar dependência crítica, fixo versão em vez de usar range aberto em produção, e uso ferramenta de auditoria de vulnerabilidade conhecida integrada ao pipeline de CI/CD. Nenhuma dessas práticas elimina o risco, mas reduz a superfície de exposição.
O equilíbrio que busco
Não dá pra reescrever tudo do zero pra evitar dependência de terceiro — isso simplesmente não é viável. O objetivo realista é ter processo de atualização deliberado, não automático e cego, e monitorar alerta de segurança das bibliotecas mais críticas do projeto.
