SCA: Software Composition Analysis e a Cadeia de Suprimentos de Software
A análise de composição de software (SCA) é um conjunto de práticas e ferramentas que permite identificar, monitorar e gerenciar todas as dependências externas presentes em um projeto de software. Diferentemente de testes de segurança tradicionais que analisam o código que você escreve, o SCA foca nas bibliotecas de terceiros que você utiliza — um aspecto crítico, pois estudos mostram que mais de 80% do código em aplicações modernas vem de dependências externas.
O principal desafio que o SCA resolve é a visibilidade. Quando você adiciona uma dependência no seu projeto, não está adicionando apenas um pacote isolado: está herdando toda a árvore de dependências transitivas dessa biblioteca. Uma única vulnerabilidade em uma dependência indireta pode comprometer toda sua aplicação. Ferramentas de SCA mapeiam essa complexidade, identificam versões vulneráveis e alertam sobre riscos antes que eles cheguem à produção.
Dependabot: Automação Inteligente de Atualizações de Dependências
O Dependabot é um serviço oferecido nativamente pelo GitHub que automatiza a detecção e atualização de dependências vulneráveis. Ao contrário de uma ferramenta que apenas reporta problemas, o Dependabot cria pull requests automaticamente, mantendo seu repositório seguro sem exigir intervenção manual constante.
Como o Dependabot Funciona
O Dependabot monitora seus arquivos de configuração de dependências (como package.json, requirements.txt, pom.xml, Gemfile) e verifica regularmente se existem versões mais novas disponíveis. Quando encontra uma atualização, particularmente uma que corrija uma vulnerabilidade conhecida, ele cria um PR com a mudança proposta. O diferencial é que o Dependabot executa os testes automaticamente antes de criar o PR, reduzindo drasticamente o risco de introduzir código quebrado.
Para ativar o Dependabot em um repositório GitHub, você precisa criar um arquivo de configuração:
# .github/dependabot.yml
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
open-pull-requests-limit: 10
reviewers:
- "seu-usuario"
assignees:
- "seu-usuario"
commit-message:
prefix: "chore"
include: "scope"
- package-ecosystem: "pip"
directory: "/"
schedule:
interval: "weekly"
allow:
- dependency-type: "production"
- package-ecosystem: "maven"
directory: "/"
schedule:
interval: "monthly"
O arquivo acima configura três ecossistemas diferentes: npm para JavaScript, pip para Python e Maven para Java. Note que cada um pode ter um intervalo diferente — você pode ser mais agressivo com linguagens críticas e mais conservador com outras.
Interpretando Alertas do Dependabot
Quando o Dependabot detecta uma vulnerabilidade, ele cria um aviso na aba "Security" do seu repositório. O aviso inclui o identificador CVE, a severidade, a versão afetada e a versão segura recomendada. Você pode visualizar essas informações via API ou dashboard do GitHub.
{
"number": 1,
"state": "open",
"dependency": {
"package": {
"ecosystem": "npm",
"name": "lodash"
},
"manifest_path": "package.json",
"version": "4.17.15"
},
"security_advisory": {
"ghsa_id": "GHSA-xxxxx",
"cve_id": "CVE-2021-23337",
"summary": "Prototype Pollution in lodash",
"description": "Versions of lodash before 4.17.21...",
"severity": "high",
"cvss": {
"score": 7.5
},
"vulnerable_version_range": "< 4.17.21",
"patched_versions": "4.17.21"
}
}
Snyk: Análise Profunda e Contexto de Risco
O Snyk é uma plataforma mais robusta que vai além da simples detecção de versões vulneráveis. Ele analisa vulnerabilidades no código, em dependências e em containers, oferecendo contexto sobre o impacto real da vulnerabilidade em seu projeto específico.
Diferenças Estratégicas entre Snyk e Dependabot
Enquanto o Dependabot é fundamentalmente um atualizador de dependências integrado ao GitHub, o Snyk é um analisador de segurança independente que fornece muito mais contexto. O Snyk determina não apenas que uma vulnerabilidade existe, mas se ela é realmente exploável no seu código. Por exemplo, uma biblioteca pode ter uma função vulnerável em um método que seu projeto nunca utiliza — o Snyk identifica isso e reduz a severidade do alerta.
Integração e Configuração do Snyk
O Snyk se integra a repositórios Git e oferece um modelo de funcionamento similar: você conecta seu repositório, e o Snyk monitora continuamente. A principal diferença é que o Snyk fornece muito mais contexto e oferece uma API rica para integração em pipelines CI/CD.
# Instalação do Snyk CLI
npm install -g snyk
# Autenticação
snyk auth
# Teste do projeto atual
snyk test
# Monitorar dependências continuamente
snyk monitor
# Gerar relatório detalhado
snyk test --json > vulnerability-report.json
A saída de um teste Snyk é significativamente mais rica:
{
"vulnerabilities": [
{
"id": "npm:lodash:20180130",
"url": "https://snyk.io/vuln/npm:lodash:20180130",
"title": "Prototype Pollution",
"type": "vulnerability",
"description": "lodash before 4.17.5 is vulnerable to Prototype Pollution...",
"severity": "high",
"cvssScore": 7.5,
"fixedIn": [
"4.17.5"
],
"introducedThrough": [
"lodash@4.17.4"
],
"isUpgradable": true,
"isPatchable": false,
"isExploitable": true,
"jiraKey": "SNYK-JS-LODASH-450202",
"publicationTime": "2018-01-30T12:00:00Z",
"disclosureTime": "2017-11-24T00:00:00Z",
"language": "js"
}
],
"dependencyCount": 456,
"org": "seu-organization",
"licensesPolicy": {}
}
Configuração no Pipeline CI/CD
O Snyk é particularmente poderoso quando integrado ao seu pipeline CI/CD. Você pode impedir merges se vulnerabilidades críticas forem detectadas:
# .github/workflows/security.yml
name: Snyk Security Scan
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
jobs:
snyk:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run Snyk Security Scan
uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
args: --severity-threshold=high
- name: Upload results to GitHub Security
uses: github/codeql-action/upload-sarif@v2
if: always()
with:
sarif_file: snyk.sarif
Gestão de Licenças: Conformidade Legal no Software
Gestão de licenças é frequentemente negligenciada, mas é tão crítica quanto segurança. Quando você utiliza bibliotecas de código aberto, você não está apenas herdando funcionalidade — está herdando obrigações legais. Diferentes licenças impõem diferentes restrições sobre como você pode usar e distribuir o software.
Tipos de Licenças e Implicações
Existem três categorias principais de licenças de software aberto. Licenças permissivas (MIT, Apache 2.0, BSD) permitem uso comercial praticamente sem restrições, exigindo apenas que você mantenha a atribuição de direitos autorais. Licenças copyleft fracas (LGPL) permitem uso em software proprietário, mas exigem que as modificações da própria biblioteca sejam compartilhadas. Licenças copyleft fortes (GPL) exigem que qualquer software que utilize código coberto pela GPL também seja lançado sob GPL, o que é problemático para software comercial.
A prática recomendada é manter uma política clara de licenças aceitas. Empresas como Microsoft, Google e Apple têm listas explícitas de licenças compatíveis com suas estratégias de negócio.
Detecção Automática com Ferramentas
Tanto Snyk quanto ferramentas dedicadas como FOSSA e Black Duck identificam licenças automaticamente. O Snyk fornece um relatório de licenças junto com o relatório de vulnerabilidades:
snyk test --license
Isso produz uma saída como:
License Report
==============
Dependencies with unapproved licenses:
┌─────────────┬──────────────┬──────────────┐
│ Package │ Version │ License │
├─────────────┼──────────────┼──────────────┤
│ lodash │ 4.17.21 │ MIT │
│ express │ 4.18.1 │ MIT │
│ uuid │ 8.3.2 │ MIT │
│ request │ 2.88.2 │ Apache 2.0 │
│ async │ 3.2.3 │ MIT │
└─────────────┴──────────────┴──────────────┘
Licenses: MIT (4), Apache 2.0 (1)
Configuração de Política de Licenças
Você pode criar uma política explícita de licenças no Snyk:
{
"version": "1.0.0",
"licensePolicy": {
"severities": {
"high": "error",
"medium": "warning",
"low": "info"
},
"licenseType": {
"AGPL": {
"templates": ["You should remove this"],
"severities": "high"
},
"GPL": {
"templates": ["GPL package detected"],
"severities": "high"
},
"LGPL": {
"templates": ["LGPL package detected"],
"severities": "medium"
},
"MIT": {
"severities": "low"
},
"Apache 2.0": {
"severities": "low"
},
"BSD": {
"severities": "low"
},
"ISC": {
"severities": "low"
}
}
}
}
Salve isso como .snyk na raiz do seu repositório, e o Snyk respeitará essas definições. Vulnerabilidades com severidade "high" causarão falha na verificação, "medium" gerará aviso e "low" apenas informará.
Exemplo Prático: Auditoria de Licenças em um Projeto Node.js
# Instalar ferramenta de análise de licenças
npm install -g license-report
# Gerar relatório
license-report --only=prod > licenses.json
# Resultado esperado
cat licenses.json
O arquivo gerado seria:
[
{
"name": "express",
"version": "4.18.1",
"license": "MIT",
"repository": "https://github.com/expressjs/express"
},
{
"name": "lodash",
"version": "4.17.21",
"license": "MIT",
"repository": "https://github.com/lodash/lodash"
},
{
"name": "pg",
"version": "8.7.3",
"license": "MIT",
"repository": "https://github.com/brianc/node-postgres"
}
]
A partir disso, você pode criar um script que valida a conformidade:
// check-licenses.js
const fs = require('fs');
const licenses = JSON.parse(fs.readFileSync('licenses.json', 'utf-8'));
const forbiddenLicenses = ['GPL', 'AGPL-3.0'];
const violations = licenses.filter(pkg =>
forbiddenLicenses.some(forbidden => pkg.license.includes(forbidden))
);
if (violations.length > 0) {
console.error('❌ Pacotes com licenças proibidas encontrados:');
violations.forEach(pkg => {
console.error(` - ${pkg.name}@${pkg.version}: ${pkg.license}`);
});
process.exit(1);
} else {
console.log('✅ Todas as licenças estão em conformidade');
}
Orquestração: Integração Completa em um Fluxo de Trabalho Real
A melhor prática não é escolher apenas Dependabot ou apenas Snyk, mas orquestrar ambos em um fluxo de trabalho complementar. O Dependabot atua como a primeira linha de defesa, mantendo dependências atualizadas e criando PRs automaticamente. O Snyk fornece análise mais profunda no pipeline CI/CD, bloqueando merges quando vulnerabilidades críticas são detectadas. E a análise de licenças garante conformidade legal antes da produção.
Pipeline Recomendado
# .github/workflows/full-dependency-scan.yml
name: Full Dependency & License Scan
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
schedule:
- cron: '0 2 * * *' # Diariamente às 2 da manhã
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '18'
cache: 'npm'
- name: Install dependencies
run: npm ci
# 1. Verificação com Snyk
- name: Run Snyk Security Scan
uses: snyk/actions/node@master
env:
SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
with:
args: --severity-threshold=high --fail-on=all
continue-on-error: true
# 2. Verificação de licenças
- name: Check Licenses
run: |
npm install -g license-report
license-report --only=prod > licenses.json
node check-licenses.js
# 3. Gerar SBOM (Software Bill of Materials)
- name: Generate SBOM
run: |
npm install -g @cyclonedx/npm
cyclonedx-npm --output-file bom.xml
# 4. Upload de artefatos
- name: Upload SBOM to GitHub
uses: actions/upload-artifact@v3
with:
name: sbom
path: bom.xml
# 5. Comentar no PR com resumo
- name: Comment PR with Results
if: github.event_name == 'pull_request'
uses: actions/github-script@v6
with:
script: |
const fs = require('fs');
const licenses = JSON.parse(fs.readFileSync('licenses.json', 'utf-8'));
const comment = `
## 📊 Relatório de Dependências
- **Total de dependências**: ${licenses.length}
- **Verificação Snyk**: ✅ Completa
- **Conformidade de Licenças**: ✅ Validada
[Visualizar SBOM](https://github.com/${{ github.repository }}/actions/runs/${{ github.run_id }})
`;
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: comment
});
Este workflow orquestra as três práticas principais: executa Snyk para vulnerabilidades, valida licenças com um script customizado e gera um SBOM (Software Bill of Materials) que oferece visibilidade completa sobre a composição do software.
Conclusão
Os três aprendizados principais que você deve levar adiante são: Primeiro, a maioria das vulnerabilidades em software moderno não vem do seu código, mas das dependências. Ferramentas como Snyk e Dependabot não são luxos, são necessidades. Segundo, automatizar é fundamental — um pipeline de segurança eficaz deve rodar sem intervenção humana constante, criando PRs, testando automaticamente e bloqueando merges apenas quando necessário. Terceiro, licenças importam legalmente, e ignorá-las pode expor sua organização a riscos legais sérios. Implementar SCA com gestão de licenças é parte obrigatória da engenharia de software profissional.