📦 Segurança de Dependências
💡 Nota prática:
Ferramentas como Snyk, OWASP Dependency-Check, Sonatype, Xygeni, entre outras, já permitem detetar vulnerabilidades conhecidas (CVEs) em bibliotecas e pacotes usados em tempo de build, execução ou testes.
Estas ferramentas são úteis para aplicar uma política de validação contínua e enforcement automático, mas não substituem a análise crítica da equipa técnica quanto à legitimidade, necessidade e atualidade das dependências utilizadas.
📌 Objetivos
- Reduzir o risco de exploração via bibliotecas desatualizadas ou comprometidas.
- Garantir que todas as dependências têm justificação técnica e validação de segurança.
- Estabelecer um processo rastreável de aprovação e controlo de versões.
- Facilitar a automação de verificações (SCA) e bloqueios em CI/CD.
- Apoiar auditorias internas e externas com evidência de controlo técnico.
Este documento define os critérios mínimos para a utilização segura de dependências externas (e internas reutilizadas), garantindo que são:
- Validadas quanto a vulnerabilidades conhecidas
- Legitimadas tecnicamente pela equipa
- Atualizadas e rastreáveis no tempo
👥 Quem deve aplicar
- Desenvolvedores: ao adicionar ou atualizar pacotes.
- Tech leads / revisores técnicos: ao aprovar PRs com alterações a
package.json,pom.xml,requirements.txt, etc. - Equipa de segurança / AppSec: ao definir listas permitidas ou regras de aprovação.
⏱️ Quando aplicar
- Sempre que for introduzida ou atualizada uma dependência.
- Periodicamente, por via automatizada (ex: nightly scans).
- Antes de cada release ou entrega a produção.
- Durante auditorias ou revisões de segurança.
🧱 Requisitos obrigatórios
-
Validação de CVEs por SCA (Software Composition Analysis)
- Scans automáticos com alertas e relatórios por PR ou build.
- Integração com CI/CD.
-
Lista aprovada (allowlist) e política de exclusão (denylist)
- Evitar bibliotecas não auditadas, não mantidas, ou abandonadas.
- Obrigatório para projetos com classificação L2/L3.
-
Validação técnica explícita em PRs
- Justificação da inclusão.
- Avaliação da manutenção da biblioteca e da sua origem.
-
Atualização regular de pacotes
- Exigir atualização de pacotes obsoletos, vulneráveis ou deprecated.
- Automatizar alertas por dependência com CVE conhecido não mitigado.
-
Gestão diferenciada de dependências de runtime vs. dev/test
- Aplicar validação proporcional ao risco de exploração em produção.
🚨 Sinais de risco
- Bibliotecas sem manutenção há mais de 1 ano.
- Pacotes com menos de 10 estrelas e nenhum release oficial.
- Scripts ou binários incluídos sem validação.
- Forks privados sem atualização de upstream.
✅ Como validar
- Scans automatizados em cada commit/PR (
dependency-check,snyk test, etc.). - Aprovação manual de cada novo pacote.
- Triggers de bloqueio no pipeline por vulnerabilidade severa.
- Revisão do changelog e do repositório da dependência.
🧾 Como evidenciar
- Logs de execução dos scanners de dependências.
- Ficheiro
.approved-deps.ymlou equivalente, versionado. - Comentário no PR com a validação e justificativa da nova dependência.
- Histórico de atualização no repositório ou sistema de gestão de pacotes.
🔄 Ligação a outras práticas
| Tema | Ficheiro associado |
|---|---|
| Linters e validações no pipeline | addon/02-linters-validacoes.md |
| Justificação de exceções | addon/05-excecoes-e-justificacoes.md |
| Validação integrada na revisão de código | addon/08-validacoes-codigo.md |
| Rastreabilidade no código e PRs | addon/09-anotacoes-evidencia.md |
📌 A inclusão de dependências inseguras é uma das causas mais comuns de compromissos aplicacionais.
O processo de validação deve ser sistemático, rastreável e bloqueante nos casos críticos.