Posture OpenSSF Scorecard
L'objectif OpenSSF Scorecard d'Apothem et les surfaces de preuve utilisées pour continuer à améliorer le score.
Apothem vise le score OpenSSF Scorecard maximal tout en gardant la façade publique honnête sur ce que Scorecard peut et ne peut pas inférer d'un nouveau dépôt à mainteneur unique. Ce document énumère chaque vérification, la surface de preuve qui la sous-tend et le contrôle qui maintient la posture à jour.
Le score en direct se trouve dans le visionneur Scorecard ; le badge se trouve dans l'en-tête du README.
Matrice de preuve par vérification
| Vérification | Surface de preuve | Notes |
|---|---|---|
| Binary-Artifacts | binary-artifacts-sweep.md | Aucun binaire exécutable suivi dans le code source ; les archives de distribution générées restent dans dist/. |
| Branch-Protection | branch-protection-ruleset.md | main est protégée avant la promotion vers une publication publique ; les force-pushes et les suppressions sont bloqués une fois le nouveau commit de publication déposé. |
| CI-Tests | .github/workflows/ci.yml | Matrice Pytest, ruff, mypy, Trivy, build de la documentation et vérifications de fumée de l'empaquetage. |
| CII-Best-Practices | Inscription à OpenSSF Best Practices | Nécessite une inscription côté mainteneur sur le site OpenSSF Best Practices ; les seuls fichiers du dépôt ne permettent pas de l'accomplir. |
| Code-Review | Protection de branche + CODEOWNERS | Les pull requests sont exigées pour main pour tous, sauf les administrateurs du dépôt, et la protection de branche exige 0 revue d'approbation tant que le projet n'a qu'un seul mainteneur (voir branch-protection-ruleset.md) ; l'historique Scorecard reste limité tant qu'il n'existe pas de PR revues. |
| Contributors | AUTHORS | Un nouveau projet à mainteneur unique ne peut pas fabriquer un historique de contributions multi-organisations ; cela s'améliore naturellement à mesure que des contributeurs rejoignent le projet. |
| Dangerous-Workflow | Audit des workflows | Aucun pull_request_target ; les Actions sont épinglées par SHA et restreintes par des permissions explicites. |
| Dependency-Update-Tool | .github/dependabot.yml | Dependabot propose des mises à jour hebdomadaires groupées pour les épinglages GitHub Actions, le site web, le fichier de verrouillage du packager vsce, le pip de la CI verrouillé par hash et les hooks pre-commit, et des mises à jour mensuelles pour le fichier de verrouillage channel-smoke ; les mises à jour de sécurité Dependabot couvrent chaque manifeste détecté, sauf les ensembles complets de dépendances et d'outils de la CI dans scripts/ci/, que scripts/dev/refresh_ci_locks.py régénère lorsqu'une alerte nomme un paquet verrouillé. .gitattributes conserve ce seul fichier dans les archives source de GitHub, que lit une analyse dans le mode archive par défaut de l'action ; le workflow Scorecard s'exécute en mode git et le lit depuis le clone. |
| Fuzzing | tests/property/ | Les tests de propriétés Hypothesis exercent les invariants du parseur et du frontmatter ; Scorecard en amont peut ne pas reconnaître Hypothesis comme une intégration de fuzzer. |
| License | LICENSE | Licence MIT à la racine du dépôt. |
| Maintained | Historique Git | Le commit de publication actuel et la cadence active des workflows démontrent la maintenance ; les dépôts très récents peuvent recevoir un avertissement d'ancienneté. |
| Packaging | .github/workflows/ | Workflows de publication, Pages et npmjs.com qui produisent le sdist, le wheel, le SBOM, la provenance SLSA et les signatures Sigstore. |
| Pinned-Dependencies | Audit des workflows + exigences verrouillées par hash | Les Actions sont épinglées par SHA ; l'outillage de publication, la mise à niveau de pip en CI, les dépendances de projet et de test de la CI et les outils de la CI (ruff, bandit, pip-audit, pip-licenses, pre-commit) s'installent avec --require-hashes. Les installations du projet, des tests et des outils lisent les neuf fichiers de verrouillage de scripts/ci/ ; la mise à niveau de pip et l'outillage de publication lisent chacun leur propre fichier de verrouillage, et le paquet lui-même s'installe par --no-deps -e .. |
| SAST | .github/workflows/codeql.yml | Requêtes security-extended de CodeQL sur Python et Actions. |
| Security-Policy | SECURITY.md | Politique de divulgation coordonnée, matrice des versions prises en charge et calendrier de réponse. |
| Signed-Releases | .github/workflows/release.yml | Signatures Sigstore sans clé, provenance SLSA, SBOM, sommes de contrôle et artefacts de publication. |
| Token-Permissions | Audit des workflows | Les workflows utilisent par défaut des permissions en lecture seule ; les portées d'écriture sont locales au job et liées aux opérations de déploiement ou de paquet. |
| Vulnerabilities | .github/workflows/pip-audit.yml + .github/workflows/dependency-review.yml | Analyse hebdomadaire des vulnérabilités et analyse CI avec téléversement SARIF ; le contrôle dependency-review bloque les pull requests qui introduisent des dépendances vulnérables ou sous licence interdite. La vérification elle-même recherche dans OSV les dépendances qu'elle trouve dans les manifestes du dépôt ; pip-audit.yml interroge donc aussi OSV (pip-audit -s osv), et un constat qu'il signale correspond à un constat de la vérification. |
Interprétation du score
Scorecard note chaque vérification sur une échelle de 0 à 10, et le score global est une moyenne pondérée. Les contrôles qui dépendent de l'historique du dépôt, d'une inscription tierce ou de la diversité des contributeurs sont suivis explicitement plutôt que surdéclarés. Toute dérive sur une vérification contrôlée par des fichiers déclenche une remédiation immédiate.
Le workflow Scorecard exécute l'action avec file_mode: git, si bien que Scorecard lit un clone du dépôt. Les archives source omettent .github/ (export-ignore dans .gitattributes) : le mode archive par défaut de l'action masquerait donc les workflows à Dangerous-Workflow, Token-Permissions, Pinned-Dependencies et Packaging.
Pinned-Dependencies reste sous 10 à dessein, pour deux raisons. Le générateur SLSA est référencé par son tag de publication, seule exception à l'épinglage par SHA, car sa provenance est ancrée sur ce tag. Le workflow evals installe la CLI Claude Code avec npm install --global, dans une version choisie à chaque exécution. Les installations Python que Scorecard analyse dans les workflows sont verrouillées par hash, ou ce sont des installations locales du paquet lui-même ou de wheels construits dans la même exécution.
Cadence de rafraîchissement
- À chaque push : le workflow Scorecard se relance à chaque push vers
main. - Hebdomadaire : les lundis à 02:30 UTC — capte les changements de méthodologie de notation en amont + les nouvelles vulnérabilités divulguées contre des dépendances épinglées existantes.
- À chaque publication : avant la promotion publique, le mainteneur vérifie la surface du visionneur Scorecard en direct et consigne toute limite liée à l'état de la plateforme.
Références
- OpenSSF Scorecard — projet amont
- Référence des vérifications Scorecard — sémantique de chaque vérification
ossf/scorecard-action— wrapper GitHub Actions- Framework SLSA — niveaux de chaîne d'approvisionnement (apothem est livré au niveau SLSA-3)
Sécurité
Posture de sécurité d'Apothem : objectif OpenSSF Scorecard, signalement des vulnérabilités, surfaces de durcissement.
Protection de branche
Protection de branche d'Apothem sur main : la règle de protection en vigueur, ses vérifications de statut requises et les vérifications en attente d'ajout.