Postura do OpenSSF Scorecard
A meta do Apothem no OpenSSF Scorecard e as superfícies de evidência usadas para manter a pontuação em melhoria.
O Apothem mira a pontuação máxima do OpenSSF Scorecard, mantendo a fachada pública honesta sobre o que o Scorecard pode e não pode inferir de um repositório novo com um único mantenedor. Este documento enumera cada verificação, a superfície de evidência que a respalda e o controle que mantém a postura atualizada.
A pontuação ao vivo está no visualizador do Scorecard; o selo está no cabeçalho do README.
Matriz de evidência por verificação
| Verificação | Superfície de evidência | Notas |
|---|---|---|
| Binary-Artifacts | binary-artifacts-sweep.md | Nenhum binário executável rastreado no código-fonte; os arquivos de distribuição gerados permanecem em dist/. |
| Branch-Protection | branch-protection-ruleset.md | main é protegida antes da promoção para lançamento público; force-pushes e exclusões são bloqueados depois que o novo commit de lançamento é integrado. |
| CI-Tests | .github/workflows/ci.yml | Matriz de Pytest, ruff, mypy, Trivy, build da documentação e verificações de fumaça do empacotamento. |
| CII-Best-Practices | Registro no OpenSSF Best Practices | Exige registro do lado do mantenedor no site do OpenSSF Best Practices; isso não pode ser concluído apenas com arquivos do repositório. |
| Code-Review | Proteção de branch + CODEOWNERS | Pull requests são obrigatórios para main para todos, exceto os administradores do repositório, e a proteção de branch exige 0 revisões de aprovação enquanto o projeto tiver um único mantenedor (consulte branch-protection-ruleset.md); o histórico do Scorecard permanece limitado até que existam PRs revisados. |
| Contributors | AUTHORS | Um projeto novo, com mantenedor solo, não pode criar artificialmente um histórico de contribuições de várias organizações; isso melhora naturalmente à medida que colaboradores entram. |
| Dangerous-Workflow | Auditoria de fluxos de trabalho | Sem pull_request_target; as Actions são fixadas por SHA e têm escopo definido com permissões explícitas. |
| Dependency-Update-Tool | .github/dependabot.yml | O Dependabot propõe atualizações semanais agrupadas para os pins de GitHub Actions, o site, o lockfile do empacotador vsce, o pip da CI travado por hash e os hooks de pre-commit, e atualizações mensais para o lockfile do channel-smoke; as atualizações de segurança do Dependabot cobrem todo manifesto detectado, exceto os conjuntos completos de dependências e ferramentas da CI em scripts/ci/, que o scripts/dev/refresh_ci_locks.py regenera quando um alerta cita um pacote travado. O .gitattributes mantém este único arquivo nos arquivos de código-fonte do GitHub, lidos por uma varredura no modo de arquivo padrão da ação; o fluxo de trabalho do Scorecard roda no modo git e lê o arquivo a partir do clone. |
| Fuzzing | tests/property/ | Testes de propriedade com Hypothesis exercitam invariantes do parser e do frontmatter; o Scorecard upstream pode não reconhecer o Hypothesis como integração de fuzzer. |
| License | LICENSE | Licença MIT na raiz do repositório. |
| Maintained | Histórico do Git | O commit de lançamento atual e a cadência ativa dos fluxos de trabalho demonstram manutenção; repositórios muito novos podem receber um aviso de idade. |
| Packaging | .github/workflows/ | Fluxos de trabalho de lançamento, Pages e npmjs.com que produzem o sdist, o wheel, o SBOM, a procedência SLSA e as assinaturas do Sigstore. |
| Pinned-Dependencies | Auditoria de fluxos de trabalho + requisitos travados por hash | As Actions são fixadas por SHA; as ferramentas de lançamento, a atualização do pip na CI, as dependências de projeto e de teste da CI e as ferramentas da CI (ruff, bandit, pip-audit, pip-licenses, pre-commit) são instaladas com --require-hashes. As instalações do projeto, dos testes e das ferramentas leem os nove lockfiles em scripts/ci/; a atualização do pip e as ferramentas de lançamento leem, cada uma, um lockfile próprio, e o pacote em si é instalado por --no-deps -e .. |
| SAST | .github/workflows/codeql.yml | Consultas security-extended do CodeQL em Python e Actions. |
| Security-Policy | SECURITY.md | Política de divulgação coordenada, matriz de versões suportadas e cronograma de resposta. |
| Signed-Releases | .github/workflows/release.yml | Assinaturas sem chave do Sigstore, procedência SLSA, SBOM, somas de verificação e artefatos de lançamento. |
| Token-Permissions | Auditoria de fluxos de trabalho | Os fluxos de trabalho usam permissões somente leitura por padrão; os escopos de escrita são locais ao job e vinculados a operações de implantação e de pacote. |
| Vulnerabilities | .github/workflows/pip-audit.yml + .github/workflows/dependency-review.yml | Varredura semanal de vulnerabilidades e varredura de CI com envio de SARIF; o portão de dependency-review bloqueia pull requests que introduzem dependências vulneráveis ou com licença não permitida. A própria verificação consulta no OSV as dependências que encontra nos manifestos do repositório; por isso, o pip-audit.yml também consulta o OSV (pip-audit -s osv), e um achado ali corresponde a um achado da verificação. |
Interpretação da pontuação
O Scorecard pontua cada verificação em uma escala de 0 a 10, e a pontuação geral é uma média ponderada. Os controles que dependem do histórico do repositório, de registro em terceiros ou da diversidade de colaboradores são acompanhados explicitamente, em vez de superestimados. Um desvio em qualquer verificação controlada por arquivos dispara remediação imediata.
O fluxo de trabalho do Scorecard executa a ação com file_mode: git, então o Scorecard lê um clone do repositório. Os arquivos de código-fonte deixam .github/ de fora (export-ignore no .gitattributes); por isso, o modo de arquivo padrão da ação esconderia os fluxos de trabalho de Dangerous-Workflow, Token-Permissions, Pinned-Dependencies e Packaging.
Pinned-Dependencies fica abaixo de 10 intencionalmente, por dois motivos. O gerador SLSA é referenciado pela sua tag de lançamento, a única exceção à fixação por SHA, porque sua procedência está ancorada nessa tag. O fluxo de trabalho evals instala a CLI do Claude Code com npm install --global, numa versão escolhida a cada execução. As instalações Python que o Scorecard varre nos fluxos de trabalho são travadas por hash, ou são instalações locais do próprio pacote ou de wheels construídos na mesma execução.
Cadência de atualização
- A cada push: o fluxo de trabalho do Scorecard é executado novamente a cada push para
main. - Semanal: às segundas-feiras, 02:30 UTC — capta mudanças na metodologia de pontuação upstream + novas vulnerabilidades divulgadas contra dependências fixadas existentes.
- A cada lançamento: antes da promoção pública, o mantenedor verifica a superfície ao vivo do visualizador do Scorecard e registra quaisquer limites do estado da plataforma.
Referências
- OpenSSF Scorecard — projeto upstream
- Referência das verificações do Scorecard — semântica de cada verificação
ossf/scorecard-action— wrapper para GitHub Actions- Framework SLSA — níveis da cadeia de suprimentos (o apothem é distribuído em SLSA-3)