OpenSSF-Scorecard-Haltung
Apothems OpenSSF-Scorecard-Ziel und die Nachweisoberflächen, mit denen die Bewertung weiter verbessert wird.
Apothem strebt die maximale OpenSSF-Scorecard-Bewertung an und hält dabei die öffentliche Fassade ehrlich darüber, was Scorecard aus einem neuen Repository mit einem einzigen Maintainer ableiten kann und was nicht. Dieses Dokument zählt jede Prüfung auf, die Nachweisoberfläche, die sie stützt, und die Kontrolle, die die Haltung aktuell hält.
Die Live-Bewertung steht im Scorecard-Viewer; das Badge befindet sich im README-Kopfbereich.
Nachweismatrix je Prüfung
| Prüfung | Nachweisoberfläche | Hinweise |
|---|---|---|
| Binary-Artifacts | binary-artifacts-sweep.md | Keine ausführbaren Binärdateien im Quellcode versioniert; generierte Distributionsarchive bleiben in dist/. |
| Branch-Protection | branch-protection-ruleset.md | main ist vor der Hochstufung zu einem öffentlichen Release geschützt; Force-Pushes und Löschungen werden blockiert, nachdem der frische Release-Commit gelandet ist. |
| CI-Tests | .github/workflows/ci.yml | Pytest-Matrix, ruff, mypy, Trivy, Dokumentations-Build und Paketierungs-Smoke-Checks. |
| CII-Best-Practices | OpenSSF-Best-Practices-Registrierung | Erfordert eine Registrierung durch den Maintainer auf der OpenSSF-Best-Practices-Website; dies lässt sich nicht allein durch Repository-Dateien erledigen. |
| Code-Review | Branch-Schutz + CODEOWNERS | Pull Requests sind für main für alle außer Repository-Administratoren erforderlich; der Branch-Schutz verlangt 0 genehmigende Reviews, solange das Projekt einen Maintainer hat (siehe branch-protection-ruleset.md); der Scorecard-Verlauf bleibt begrenzt, bis geprüfte PRs existieren. |
| Contributors | AUTHORS | Ein neues Projekt mit einem einzigen Maintainer kann keinen Beitragsverlauf über mehrere Organisationen hinweg fabrizieren; dies verbessert sich natürlich, sobald Mitwirkende hinzukommen. |
| Dangerous-Workflow | Workflow-Audit | Kein pull_request_target; Actions sind per SHA gepinnt und mit expliziten Berechtigungen eingegrenzt. |
| Dependency-Update-Tool | .github/dependabot.yml | Dependabot schlägt gruppierte wöchentliche Updates für die GitHub-Actions-Pins, die Website, die Lockfile des vsce-Packagers, das hash-gesperrte pip der CI und die pre-commit-Hooks vor sowie monatliche Updates für die channel-smoke-Lockfile; Dependabot-Sicherheitsupdates decken jedes erkannte Manifest ab, außer den vollständig gesperrten Abhängigkeits- und Werkzeugsätzen der CI in scripts/ci/, die scripts/dev/refresh_ci_locks.py neu erzeugt, wenn eine Warnung ein gesperrtes Paket nennt. .gitattributes hält genau diese Datei in den Quellarchiven von GitHub, die ein Scan im Standard-Archivmodus der Action liest; der Scorecard-Workflow läuft im Git-Modus und liest sie aus dem Klon. |
| Fuzzing | tests/property/ | Hypothesis-Eigenschaftstests prüfen Invarianten von Parser und Frontmatter; die Upstream-Scorecard erkennt Hypothesis möglicherweise nicht als Fuzzer-Integration an. |
| License | LICENSE | MIT-Lizenz im Wurzelverzeichnis des Repositorys. |
| Maintained | Git-Verlauf | Der aktuelle Release-Commit und die aktive Workflow-Kadenz belegen die Pflege; sehr neue Repositorys erhalten möglicherweise eine Alterswarnung. |
| Packaging | .github/workflows/ | Release-, Pages- und npmjs.com-Workflows, die sdist, Wheel, SBOM, SLSA-Provenienz und Sigstore-Signaturen erzeugen. |
| Pinned-Dependencies | Workflow-Audit + hash-gesperrte Anforderungen | Actions sind per SHA gepinnt; die Release-Werkzeuge, das pip-Upgrade der CI, die Projekt- und Testabhängigkeiten der CI und die CI-Werkzeuge (ruff, bandit, pip-audit, pip-licenses, pre-commit) werden mit --require-hashes installiert. Die Installationen für Projekt, Tests und Werkzeuge lesen die neun Lockfiles in scripts/ci/; das pip-Upgrade und die Release-Werkzeuge lesen jeweils eine eigene Lockfile, und das Paket selbst wird mit --no-deps -e . installiert. |
| SAST | .github/workflows/codeql.yml | CodeQL-Abfragen security-extended über Python und Actions. |
| Security-Policy | SECURITY.md | Richtlinie zur koordinierten Offenlegung, Matrix der unterstützten Versionen und Reaktionszeitplan. |
| Signed-Releases | .github/workflows/release.yml | Schlüssellose Sigstore-Signaturen, SLSA-Provenienz, SBOM, Prüfsummen und Release-Artefakte. |
| Token-Permissions | Workflow-Audit | Workflows verwenden standardmäßig schreibgeschützte Berechtigungen; Schreibbereiche sind job-lokal und an Deployment- und Paketoperationen gebunden. |
| Vulnerabilities | .github/workflows/pip-audit.yml + .github/workflows/dependency-review.yml | Wöchentlicher Schwachstellen-Scan und CI-Scan mit SARIF-Upload; das Dependency-Review-Gate blockiert Pull Requests, die verwundbare Abhängigkeiten oder Abhängigkeiten mit unzulässiger Lizenz einführen. Die Prüfung selbst schlägt die Abhängigkeiten, die sie in den Manifesten des Repositorys findet, in OSV nach. Deshalb fragt auch pip-audit.yml OSV ab (pip-audit -s osv), und ein Befund dort entspricht einem Befund der Prüfung. |
Interpretation der Bewertung
Scorecard bewertet jede Prüfung auf einer Skala von 0-10, und die Gesamtbewertung ist ein gewichteter Mittelwert. Kontrollen, die vom Repository-Verlauf, einer Registrierung bei Dritten oder der Vielfalt der Mitwirkenden abhängen, werden explizit verfolgt, statt überzogen beansprucht zu werden. Eine Drift bei einer dateigesteuerten Prüfung löst sofortige Behebung aus.
Der Scorecard-Workflow führt die Action mit file_mode: git aus, sodass Scorecard einen Klon des Repositorys liest. Quellarchive lassen .github/ weg (export-ignore in .gitattributes). Im Standard-Archivmodus der Action wären die Workflows deshalb für Dangerous-Workflow, Token-Permissions, Pinned-Dependencies und Packaging unsichtbar.
Pinned-Dependencies bleibt bewusst unter 10, aus zwei Gründen. Der SLSA-Generator wird über sein Release-Tag referenziert. Das ist die einzige Ausnahme vom Pinning per SHA, weil seine Provenienz an dieses Tag gebunden ist. Der evals-Workflow installiert die CLI von Claude Code mit npm install --global in einer Version, die bei jedem Lauf gewählt wird. Die Python-Installationen in Workflows, die Scorecard scannt, sind hash-gesperrt oder lokale Installationen des Pakets selbst oder von Wheels, die im selben Lauf gebaut wurden.
Aktualisierungskadenz
- Pro Push: Der Scorecard-Workflow läuft bei jedem Push auf
mainerneut. - Wöchentlich: Montags um 02:30 UTC — erfasst Änderungen an der Upstream-Bewertungsmethodik + neue Schwachstellen, die gegen bestehende gepinnte Abhängigkeiten offengelegt wurden.
- Pro Release: Vor der öffentlichen Beförderung verifiziert der Maintainer die Live-Oberfläche des Scorecard-Viewers und vermerkt etwaige Grenzen des Plattformzustands.
Referenzen
- OpenSSF Scorecard — Upstream-Projekt
- Referenz der Scorecard-Prüfungen — Semantik je Prüfung
ossf/scorecard-action— GitHub-Actions-Wrapper- SLSA-Framework — Lieferketten-Stufen (apothem wird auf SLSA-3 ausgeliefert)