Decidir se uma biblioteca de código aberto pode entrar em produção é uma decisão de cadeia de fornecimento que muita equipe ainda toma sem evidência. O OpenSSF Scorecard existe para reduzir essa cegueira: o projeto mantido pela OpenSSF aplica verificações automatizadas a repositórios públicos e transforma práticas de segurança em critérios comparáveis. Cada verificação recebe uma nota em escala até 10, acompanhada de um nível de risco, o que permite trocar opinião por regra auditável. Se o seu time consome pacotes de terceiros — ou seja, quase todos —, a ação prioritária é rodar a ferramenta sobre as dependências mais críticas do produto ainda esta semana.
O que o Scorecard avalia
O Scorecard avalia cinco áreas que correspondem aos pontos de risco da cadeia de fornecimento de software: código-fonte, processo de build, dependências, testes contínuos e manutenção do projeto. A lista de verificações cobre desde proteção de branch e revisão obrigatória de código até permissões de token em workflows, dependências fixadas por hash, releases assinadas e presença de política de segurança declarada. Cada item aponta um comportamento observável no repositório, não um autorrelato do mantenedor.
O projeto define três objetivos explícitos: automatizar a análise e as decisões de confiança sobre a postura de segurança de projetos abertos; usar os dados para melhorar os projetos críticos dos quais o mundo depende; e servir como instrumento de medição de políticas existentes. O terceiro objetivo é o que interessa a times de governança: se a empresa já exige revisão de código e releases assinadas de fornecedores, o Scorecard mede o cumprimento sem depender de questionário respondido pelo próprio fornecedor.
Dois usos se destacam na prática. Para mantenedores, o Scorecard funciona como checklist de melhoria contínua. Para consumidores, funciona como instrumento de decisão: antes de adotar um pacote, o time consulta as verificações que interessam à sua política e registra a escolha. O projeto lista como usuários destacados TensorFlow, Angular, Flutter e serviços como o deps.dev — sinal de que os resultados já alimentam decisões reais de adoção em escala. Para uma visão mais ampla de terceiros, combine essa leitura com o modelo de avaliação de fornecedores críticos já publicado aqui no portal.
Como rodar as verificações
Em repositórios que você administra, o caminho mais curto é a GitHub Action oficial: ela roda a cada mudança, publica alertas na aba Security e, com a opção publish_results habilitada, disponibiliza o resultado pela API pública. Em repositórios de terceiros, use a interface de linha de comando. O binário exige Go instalado e roda em macOS e Linux; também existe imagem oficial de Docker, o que facilita incluir a execução em pipelines de auditoria sem instalar dependências na estação do analista.
A execução manual aceita selecionar verificações específicas e controlar o nível de detalhe da saída — o que importa quando o objetivo é uma auditoria pontual, e não uma varredura completa. Para consultas em repositórios abertos, um token de acesso pessoal com escopo público é suficiente; guarde o token fora do código e do histórico do shell.
Para consulta rápida, o visualizador web mostra as notas de projetos já escaneados no ciclo semanal: a ferramenta examina mais de um milhão de repositórios toda semana e expõe os resultados por API. Quem constrói painéis internos precisa conhecer duas ressalvas operacionais documentadas pelo projeto. Primeiro, a consulta semanal via API omite as verificações CI-Tests, Contributors e Dependency-Update-Tool, porque executá-las em escala custa caro demais. Segundo, o dataset público do BigQuery não está mais disponível; integrações antigas que leiam esse dataset precisam migrar para a API.
Como ler as notas
A nota agregada é útil como termômetro e perigosa como critério único. A documentação do próprio projeto avisa: a agregação esconde comportamentos individuais, há mais de um caminho para chegar à mesma nota, e as heurísticas têm falso positivo e falso negativo. Uma política madura lê verificação por verificação. Desde a versão V5, o Scorecard aposta em resultados estruturados para isso: em vez de confiar num número só, o consumidor consulta propriedades específicas — por exemplo, se o repositório está arquivado — e aplica a própria regra de decisão.
Na prática, isso muda o desenho do controle. Bloquear dependência por nota média baixa gera atrito e falsos bloqueios. Exigir presença de verificações específicas — revisão de código, proteção de branch, release assinada — produz critérios explicáveis, que o mantenedor consegue atender e o auditor consegue reproduzir. Mantenedores também podem exibir o badge oficial no README, que se atualiza a cada mudança e torna a postura visível para quem avalia a adoção.
Exemplo de política de aceitação
O quadro abaixo é um exemplo próprio de política para o momento de incluir um pacote novo. Adapte os cortes ao seu contexto; o valor está em ter regra escrita antes da pressão do prazo.
| Verificação | Sinal observado | Risco documentado | Ação sugerida |
|---|---|---|---|
| Dangerous-Workflow | Padrões perigosos em workflows do GitHub Actions | Crítico | Bloquear adoção até correção |
| Branch-Protection | Branch principal protegida | Alto | Exigir antes de produção |
| Token-Permissions | Tokens de workflow declarados como somente leitura | Alto | Exigir em pacotes usados no build |
| Pinned-Dependencies | Dependências declaradas e fixadas | Médio | Exigir em ferramentas de CI |
| Signed-Releases | Releases assinadas criptograficamente | Alto | Exigir em binários distribuídos |
| Maintained | Projeto em manutenção ativa | Alto | Revisar manualmente se insuficiente |
Plano de adoção defensiva
Prioridade P1: comece pelo inventário. Liste as dependências diretas que o produto não consegue substituir em um trimestre e rode a CLI do Scorecard sobre elas, guardando o resultado como baseline. Em seguida, defina a política de aceitação por escrito e aplique a GitHub Action nos repositórios próprios, com publicação de resultados. Essas duas frentes cobrem o risco mais provável: adoção nova sem critério e degradação silenciosa de projeto antes mantido.
Prioridade P2: integre a consulta a dependências no fluxo de revisão de pull request, monitore a nota das dependências críticas ao longo do tempo e encadeie o resultado com controles adjacentes — pacotes aprovados podem seguir para verificação de artefato, como as assinaturas de imagem com controle de admissão no Kubernetes. Registre exceções com prazo e responsável: política sem gestão de exceção vira papel.
O Scorecard não substitui teste, auditoria de código ou SBOM; substitui achismo por evidência no ponto em que a maioria das decisões acontece — a escolha inicial do pacote. Comece pequeno, com a lista de dependências que realmente dói se falhar, e expanda a política a partir do que os primeiros resultados mostrarem.