Postura de OpenSSF Scorecard
El objetivo de OpenSSF Scorecard de Apothem y las superficies de evidencia que se usan para seguir mejorando la puntuación.
Apothem aspira a la puntuación máxima de OpenSSF Scorecard y, al mismo tiempo, mantiene la fachada pública honesta sobre lo que Scorecard puede y no puede inferir de un repositorio nuevo con un único mantenedor. 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 | Cero binarios ejecutables rastreados en el código fuente; los archivos comprimidos de distribución generados permanecen en dist/. |
| Branch-Protection | branch-protection-ruleset.md | main queda protegida antes de la promoción del lanzamiento público; los force-pushes y las eliminaciones se bloquean después de que llegue el commit de lanzamiento nuevo. |
| CI-Tests | .github/workflows/ci.yml | Matriz de Pytest, ruff, mypy, 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 mantenedor en el sitio de OpenSSF Best Practices; esto no puede completarse solo con archivos del repositorio. |
| Code-Review | Protección de ramas + CODEOWNERS | Las pull requests son obligatorias para main para todos excepto los administradores del repositorio, y la protección de ramas exige 0 revisiones de aprobación mientras el proyecto tenga un solo mantenedor (consulta branch-protection-ruleset.md); el historial de Scorecard sigue siendo limitado hasta que existan PR revisadas. |
| Contributors | AUTHORS | Un proyecto nuevo con un solo mantenedor no puede fabricar un historial de contribuciones de varias 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 | .github/dependabot.yml | Dependabot propone actualizaciones semanales agrupadas para las fijaciones de GitHub Actions, el sitio web, el archivo de bloqueo del empaquetador vsce, el pip de CI bloqueado por hash y los hooks de pre-commit, y actualizaciones mensuales para el archivo de bloqueo de channel-smoke; las actualizaciones de seguridad de Dependabot cubren todos los manifiestos detectados, salvo los conjuntos completos de dependencias y herramientas de CI en scripts/ci/, que scripts/dev/refresh_ci_locks.py regenera cuando una alerta menciona un paquete bloqueado. .gitattributes mantiene este único archivo en los archivos comprimidos del código fuente de GitHub, que lee un análisis en el modo de archivo comprimido predeterminado de la acción; el flujo de trabajo de Scorecard se ejecuta en modo git y lo lee desde el clon. |
| Fuzzing | tests/property/ | Las pruebas de propiedades de Hypothesis ejercitan los invariantes del analizador y del frontmatter; es posible que el Scorecard upstream no acredite a Hypothesis como integración de fuzzer. |
| License | LICENSE | Licencia MIT en la raíz del repositorio. |
| Maintained | Historial de Git | El commit de lanzamiento actual y la cadencia activa de los flujos de trabajo demuestran el mantenimiento; los repositorios muy nuevos pueden recibir una advertencia de antigüedad. |
| Packaging | .github/workflows/ | Los flujos de trabajo de lanzamiento, Pages y npmjs.com producen el sdist, el wheel, el SBOM, la procedencia SLSA y las firmas de Sigstore. |
| Pinned-Dependencies | Auditoría de flujos de trabajo + requisitos bloqueados por hash | Las Actions están fijadas por SHA; las herramientas de lanzamiento, la actualización de pip en CI, las dependencias de proyecto y de pruebas de CI y las herramientas de CI (ruff, bandit, pip-audit, pip-licenses, pre-commit) se instalan con --require-hashes. Las instalaciones del proyecto, de las pruebas y de las herramientas leen los nueve archivos de bloqueo de scripts/ci/; la actualización de pip y las herramientas de lanzamiento leen cada una su propio archivo de bloqueo, y el propio paquete se instala con --no-deps -e .. |
| 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 admitidas y calendario de respuesta. |
| Signed-Releases | .github/workflows/release.yml | Firmas sin clave de Sigstore, procedencia SLSA, SBOM, sumas de verificación y artefactos de lanzamiento. |
| Token-Permissions | Auditoría de flujos de trabajo | Los flujos de trabajo usan permisos de solo lectura por defecto; los permisos de escritura son locales de cada trabajo y están ligados a las operaciones de despliegue o de paquetes. |
| Vulnerabilities | .github/workflows/pip-audit.yml + .github/workflows/dependency-review.yml | Escaneo semanal de vulnerabilidades y escaneo en CI con carga de SARIF; la puerta dependency-review bloquea las pull requests que introducen dependencias vulnerables o con licencias no permitidas. La propia comprobación busca en OSV las dependencias que encuentra en los manifiestos del repositorio, por lo que pip-audit.yml también consulta OSV (pip-audit -s osv) y un hallazgo allí coincide con un hallazgo de la comprobación. |
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 con terceros o de la diversidad de colaboradores se rastrean de forma explícita en lugar de exagerarse. Una desviación en cualquier comprobación controlada por archivos desencadena una corrección inmediata.
El flujo de trabajo de Scorecard ejecuta la acción con file_mode: git, así que Scorecard lee un clon del repositorio. Los archivos comprimidos del código fuente omiten .github/ (export-ignore en .gitattributes), por lo que el modo de archivo comprimido predeterminado de la acción ocultaría los flujos de trabajo a Dangerous-Workflow, Token-Permissions, Pinned-Dependencies y Packaging.
Pinned-Dependencies se queda por debajo de 10 a propósito, por dos motivos. El generador de SLSA se referencia por su etiqueta de lanzamiento, la única excepción a la fijación por SHA, porque su procedencia está anclada a esa etiqueta. El flujo de trabajo evals instala la CLI de Claude Code con npm install --global, en una versión elegida en cada ejecución. Las instalaciones de Python que Scorecard analiza en los flujos de trabajo están bloqueadas por hash o son instalaciones locales del propio paquete o de wheels compilados en la misma ejecución.
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 del proyecto de origen + nuevas vulnerabilidades divulgadas contra dependencias fijadas existentes.
- Por lanzamiento: antes de la promoción pública, el mantenedor verifica la superficie del visor de Scorecard en vivo y registra cualquier límite del estado de la plataforma.
Referencias
- OpenSSF Scorecard — proyecto de origen
- Referencia de comprobaciones de Scorecard — semántica de cada comprobación
ossf/scorecard-action— envoltorio para GitHub Actions- Marco SLSA — niveles de la cadena de suministro (apothem se distribuye con SLSA-3)
Seguridad
Postura de seguridad de Apothem — objetivo de OpenSSF Scorecard, reporte de vulnerabilidades, superficies de endurecimiento.
Protección de ramas
Protección de ramas de Apothem en main: la regla de protección vigente, sus verificaciones de estado requeridas y las verificaciones pendientes de agregar.