Resumo

  • O OpenSSF Scorecard aplica verificações automatizadas selecionadas, dá nota de 0 a 10 a cada uma e calcula um agregado ponderado por risco.
  • O projeto afirma que suas heurísticas têm falsos positivos e negativos e que não pretende ser relatório definitivo ou exigência única para todos os projetos.
  • O resultado pode orientar investigação, mas não autoriza uma dependência, não prova um release e não decide a resposta local a uma limitação.

A utilidade começa pela modéstia

O OpenSSF Scorecard transforma sinais observáveis de repositórios em controles e em uma pontuação agregada. Para quem mantém software, isso ajuda a localizar práticas que merecem melhoria. Para quem consome software, ajuda a formular perguntas sobre uma dependência. Esse é um trabalho importante, mas não é uma delegação de decisão.

O próprio projeto estabelece a fronteira. A escolha dos controles, dos pesos e do cálculo é opinativa. A ferramenta pode tanto detectar algo que não representa risco material como deixar de detectar uma prática existente. Ela não pretende oferecer uma conclusão definitiva, válida para qualquer projeto. Uma nota agregada também não conta quais comportamentos individuais contribuíram para ela; combinações diferentes podem chegar ao mesmo valor e mudanças nas heurísticas podem alterar o resultado.

Ler essas ressalvas como fraqueza seria um engano. Elas impedem que uma fotografia automatizada vire uma garantia sobre todo o ciclo de vida de um software. A nota diz respeito a um alvo, uma referência, uma execução e uma capacidade de observação determinados. Não certifica cada artefato distribuído nem prevê como outro operador utilizará esse software.

Média ponderada não é uma licença de confiança

O número único é cômodo para um painel ou uma lista de fornecedores. Justamente por isso pode ser confundido com um semáforo de aprovação. Porém, Scorecard forma sua nota a partir de controles com pesos de risco diferentes. Projetos com a mesma média podem ter lacunas ou sinais fortes em pontos opostos. O que é decisivo para uma organização pode ser irrelevante para outra.

A documentação dos controles dá exemplos claros. Maintained usa atividade publicamente observável em uma janela de tempo e, ainda assim, reconhece que pouco movimento não torna automaticamente um software inseguro. SBOM procura a existência de uma lista de componentes em locais definidos. Encontrar uma lista é evidência de presença, não prova de que ela esteja completa, seja correta para o binário implantado ou responda à exposição de quem a consulta.

Também importa como a observação foi feita. Varreduras públicas semanais têm cobertura declarada. A API deixa de executar alguns controles por custo em escala. Uma execução com outro acesso pode enxergar outra superfície. Referência resolvida, data, versão da ferramenta, dados acessíveis, resultados individuais e detalhes precisam acompanhar a nota para que seu significado não seja perdido.

Contexto do mantenedor não substitui verificação

Resultado baixo não prova vulnerabilidade, abandono, conduta inadequada ou incidente. Ele mostra que uma verificação definida não obteve o sinal esperado. Scorecard adverte que uma prática pode existir sem que a ferramenta a reconheça. Assim, a saída é um convite à inspeção, não um veredito.

As anotações de mantenedor tornam esse limite visível. Rótulos como test-data, remediated, not-applicable, not-supported e not-detected permitem contextualizar uma avaliação incompleta. A informação é útil, mas continua sendo fornecida pelo mantenedor. Não é auditoria independente nem instrução para que cada consumidor aceite a dependência.

Há, portanto, três registros distintos: a leitura do instrumento, a explicação do mantenedor e a decisão do consumidor. O terceiro precisa tratar do pacote, da versão ou do commit efetivamente usado, das permissões, da exposição, das alternativas e do responsável por aceitar uma exceção ou impor uma condição.

A decisão pertence a quem opera

Uma empresa pode usar um pacote publicado, um commit fixado, um espelho interno ou um artefato de sua própria compilação. Pode expô-lo a dados e redes diferentes, possuir controle compensatório ou ter data de retirada próxima. Pode aceitar provisoriamente, isolar, monitorar, pedir provas adicionais, migrar ou não adotar. Nenhuma dessas escolhas sai automaticamente de uma média.

Um registro de decisão enxuto deve separar os papéis. Na parte de medição: identificador do repositório e referência resolvida, versão e hora do Scorecard, restrições de acesso, agregado, controles relevantes, detalhes e anotações. Na parte de decisão: dependência exata, uso previsto, evidência adicional, responsável, justificativa de limiar ou exceção, ação e gatilho de revisão.

Esse vínculo conserva a utilidade do Scorecard sem fingir que uma observação pública autorizou uma decisão que somente o usuário do software pode tomar.

Fontes

  1. OpenSSF Scorecard README
  2. Documentação de verificações do Scorecard
  3. Anotações de mantenedor do Scorecard