Seguridad
Postura de OpenSSF Scorecard
El objetivo de OpenSSF Scorecard de Apothem y las superficies de evidencia que se usan para mantener la puntuación en mejora.
Apothem aspira a la puntuación máxima de OpenSSF Scorecard mientras mantiene la fachada pública honesta sobre lo que Scorecard puede y no puede inferir de un repositorio nuevo con un único responsable. Este documento enumera cada comprobación, la superficie de evidencia que la respalda y el control que mantiene la postura al día.
La puntuación en vivo está en el visor de Scorecard; la insignia está en el encabezado del README.
Matriz de evidencia por comprobación
| Comprobación | Superficie de evidencia | Notas |
|---|---|---|
| Binary-Artifacts | binary-artifacts-sweep.md | No se rastrea ningún binario ejecutable en el código fuente; los archivos de distribución generados permanecen en dist/. |
| Branch-Protection | branch-protection-ruleset.md | main queda protegido antes de la promoción a una versión pública; los force-pushes y las eliminaciones se bloquean tras aterrizar el commit de la versión nueva. |
| CI-Tests | .github/workflows/ci.yml | Matriz de Pytest, ruff, mypy, CodeQL, Trivy, compilación de la documentación y comprobaciones de humo del empaquetado. |
| CII-Best-Practices | Registro en OpenSSF Best Practices | Requiere un registro por parte del responsable en el sitio de OpenSSF Best Practices; esto no puede completarse solo con archivos del repositorio. |
| Code-Review | Protección de ramas + CODEOWNERS | Se aplica para futuras pull requests; el historial de Scorecard sigue siendo limitado hasta que existan PR revisadas. |
| Contributors | AUTHORS | Un proyecto nuevo con un único responsable no puede fabricar un historial de contribuciones de múltiples organizaciones; esto mejora de forma natural a medida que se incorporan colaboradores. |
| Dangerous-Workflow | Auditoría de flujos de trabajo | Sin pull_request_target; las Actions están fijadas por SHA y acotadas con permisos explícitos. |
| Dependency-Update-Tool | renovate.json | Renovate cubre GitHub Actions, los manifiestos de Python, los requisitos de versión con hash bloqueado y las superficies de npm, manteniendo disponibles las PR de dependencias agrupadas. |
| Fuzzing | tests/property/ | Las pruebas de propiedad de Hypothesis ejercitan las invariantes del analizador y del frontmatter; el Scorecard ascendente puede no acreditar a Hypothesis como una integración de fuzzing. |
| License | LICENSE | Licencia MIT en la raíz del repositorio. |
| Maintained | Historial de Git | El commit de la versión actual y la cadencia activa de flujos de trabajo demuestran el mantenimiento; los repositorios muy nuevos pueden recibir una advertencia de antigüedad. |
| Packaging | .github/workflows/ | Flujos de trabajo de Release, Pages y npmjs.com que producen el sdist, el wheel, el SBOM, la procedencia SLSA y las firmas de Sigstore. |
| Pinned-Dependencies | Auditoría de flujos de trabajo + requisitos con hash bloqueado | Las Actions están fijadas por SHA; las instalaciones de las herramientas de publicación usan --require-hashes; las herramientas de pip exclusivas de los flujos de trabajo usan fijaciones exactas. |
| SAST | .github/workflows/codeql.yml | Consultas security-extended de CodeQL sobre Python y Actions. |
| Security-Policy | SECURITY.md | Política de divulgación coordinada, matriz de versiones compatibles y cronograma de respuesta. |
| Signed-Releases | .github/workflows/release.yml | Firmas keyless de Sigstore, procedencia SLSA, SBOM, sumas de verificación y artefactos de la versión. |
| Token-Permissions | Auditoría de flujos de trabajo | Los flujos de trabajo usan permisos de solo lectura por defecto; los ámbitos de escritura son locales al trabajo y están ligados a operaciones de despliegue/empaquetado. |
| Vulnerabilities | .github/workflows/pip-audit.yml + .github/workflows/dependency-review.yml | Escaneo semanal de vulnerabilidades y escaneo de CI con carga de SARIF; el control de dependency-review bloquea las pull requests que introducen dependencias vulnerables o con licencias no permitidas. |
Interpretación de la puntuación
Scorecard puntúa cada comprobación en una escala de 0 a 10 y la puntuación global es una media ponderada. Los controles que dependen del historial del repositorio, del registro de terceros o de la diversidad de colaboradores se rastrean de forma explícita en lugar de sobreafirmarse. La deriva en cualquier comprobación controlada por archivos desencadena una remediación inmediata.
Cadencia de actualización
- Por push: el flujo de trabajo de Scorecard se vuelve a ejecutar en cada push a
main. - Semanal: lunes a las 02:30 UTC — detecta cambios en la metodología de puntuación ascendente y nuevas vulnerabilidades divulgadas contra dependencias fijadas existentes.
- Por versión: antes de la promoción pública, el responsable verifica la superficie del visor de Scorecard en vivo y registra cualquier límite del estado de la plataforma.
Referencias
- OpenSSF Scorecard — proyecto ascendente
- Referencia de comprobaciones de Scorecard — semántica de cada comprobación
ossf/scorecard-action— envoltorio de GitHub Actions- Marco SLSA — niveles de cadena de suministro (apothem se publica en SLSA-3)