Segurança
Postura do OpenSSF Scorecard
A meta de OpenSSF Scorecard do Apothem 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 atual.
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 é protegido antes da promoção para uma versão pública; force-pushes e exclusões são bloqueados depois que o commit da versão nova aterrissa. |
| CI-Tests | .github/workflows/ci.yml | Matriz de Pytest, ruff, mypy, CodeQL, Trivy, build da documentação e verificações de fumaça do empacotamento. |
| CII-Best-Practices | Registro no OpenSSF Best Practices | Exige registro pelo 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 | Aplicado para futuras pull requests; o histórico do Scorecard permanece limitado até que existam PRs revisadas. |
| Contributors | AUTHORS | Um projeto novo com mantenedor solo não pode fabricar um histórico de contribuições de múltiplas organizações; isso melhora naturalmente conforme colaboradores aparecem. |
| Dangerous-Workflow | Auditoria de workflows | Sem pull_request_target; as Actions são fixadas por SHA e escopadas com permissões explícitas. |
| Dependency-Update-Tool | renovate.json | O Renovate cobre GitHub Actions, manifestos Python, requisitos de versão com hash travado e superfícies npm, mantendo disponíveis PRs de dependências agrupadas. |
| Fuzzing | tests/property/ | Testes de propriedade do Hypothesis exercitam as invariantes do parser e do frontmatter; o Scorecard upstream pode não creditar o Hypothesis como uma integração de fuzzing. |
| License | LICENSE | Licença MIT na raiz do repositório. |
| Maintained | Histórico do Git | O commit da versão atual e a cadência ativa de workflows demonstram manutenção; repositórios muito novos podem receber um aviso de idade. |
| Packaging | .github/workflows/ | Workflows de Release, Pages e npmjs.com que produzem o sdist, o wheel, o SBOM, a proveniência SLSA e as assinaturas Sigstore. |
| Pinned-Dependencies | Auditoria de workflows + requisitos com hash travado | As Actions são fixadas por SHA; as instalações das ferramentas de release usam --require-hashes; as ferramentas pip exclusivas dos workflows usam fixações exatas. |
| 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 keyless do Sigstore, proveniência SLSA, SBOM, somas de verificação e artefatos da versão. |
| Token-Permissions | Auditoria de workflows | Os workflows usam permissões somente-leitura por padrão; os escopos de escrita são locais ao job e atrelados a operações de implantação/empacotamento. |
| Vulnerabilities | .github/workflows/pip-audit.yml + .github/workflows/dependency-review.yml | Varredura semanal de vulnerabilidades e varredura de CI com upload de SARIF; o gate de dependency-review bloqueia pull requests que introduzem dependências vulneráveis ou com licenças não permitidas. |
Interpretação da pontuação
O Scorecard pontua cada verificação numa 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 de terceiros ou da diversidade de colaboradores são rastreados explicitamente em vez de superafirmados. A deriva em qualquer verificação controlada por arquivos dispara remediação imediata.
Cadência de atualização
- A cada push: o workflow do Scorecard é reexecutado a cada push para
main. - Semanal: segundas-feiras às 02:30 UTC — capta mudanças na metodologia de pontuação upstream + novas vulnerabilidades divulgadas contra dependências fixadas existentes.
- A cada versão: antes da promoção pública, o mantenedor verifica a superfície do visualizador do Scorecard ao vivo 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 de GitHub Actions- Framework SLSA — níveis de cadeia de suprimentos (apothem é publicado em SLSA-3)