Vertrauen¶
Jedes Projekt hier entsteht aus einem Blueprint, der seine Releases baut, signiert und prüft, und so geben alle dieselben Garantien. Du musst ihnen nicht einfach glauben: Jede Garantie unten bringt einen Weg mit, sie selbst zu prüfen. Diese Seite handelt von den Projekten; Diese Website beschreibt die Sicherheit und den Datenschutz der Website selbst.
| Garantie | Autodarts | Paperless Sync | Paperless Unified Search | Issue assistant | Repo Blueprint |
|---|---|---|---|---|---|
| Neuestes Release | GitHub | GitHub | GitHub | GitHub | GitHub |
| Signierte Tags | gitsign, ohne Schlüssel | gitsign, ohne Schlüssel | gitsign, ohne Schlüssel | gitsign, ohne Schlüssel | gitsign, ohne Schlüssel |
| Build-Provenienz | SLSA Build Level 3 | SLSA Build Level 3 | SLSA Build Level 3 | SLSA Build Level 3 | SLSA Build Level 3 |
| Unveränderliche Releases | ja | ja | ja | ja | ja |
| SBOM | SPDX und CycloneDX | SPDX und CycloneDX | SPDX und CycloneDX | SPDX und CycloneDX | SPDX und CycloneDX |
| OpenVEX | für jedes akzeptierte Advisory | für jedes akzeptierte Advisory | für jedes akzeptierte Advisory | für jedes akzeptierte Advisory | für jedes akzeptierte Advisory |
| Testabdeckung | — | — | — | — | — |
| Mutations-Score | — | — | — | — | — |
| OpenSSF Scorecard | — | — | — | — | — |
| OpenSSF Best Practices | Silber | Silber | Silber | Silber | Silber |
| Sicherheitsrichtlinie | SECURITY.md | SECURITY.md | SECURITY.md | SECURITY.md | SECURITY.md |
| Sicherheitslücke melden | vertraulich | vertraulich | vertraulich | vertraulich | vertraulich |
Die neuesten Releases und die Zahlen der Tests und der Scorecard kommen beim Laden der Seite aus dem Dashboard und folgen ihm innerhalb von zwei Stunden; ein Strich steht für eine Zahl, die es nicht hat. Die Stufe der OpenSSF Best Practices liest der Build jeden Tag von bestpractices.dev.
Was die Garantien bedeuten¶
- Signierte Tags. Der Release-Workflow jedes Projekts signiert den Tag jedes Releases mit gitsign: mit einem Zertifikat von Sigstore für diesen Workflow, das zehn Minuten gilt, statt mit einem Schlüssel. Es gibt keinen Signaturschlüssel, der verloren gehen könnte, und der Workflow baut kein Release auf einem Tag, den er nicht selbst signiert hat. GitHub zeigt diese Tags als Unverified, weil es Zertifikate von Sigstore nicht prüft; gitsign prüft sie, wie Einen signierten Tag prüfen zeigt.
- Build-Provenienz. Jede Datei eines Releases entsteht in einem isolierten Build, dessen Workflow mit Sigstore signiert, wo und wie er die Datei gebaut hat, aus welchem Commit: ihre Provenienz, nach SLSA Build Level 3.
- Unveränderliche Releases. Ist ein Release veröffentlicht, können sich weder seine Dateien noch sein Tag ändern. GitHub signiert eine Attestierung, die den Tag an seinen Commit und an jede Datei des Releases bindet.
- SBOM. Jedes Release listet, was es ausliefert, mit jeder Komponente darin, unter seinem Namen und seiner Version, als SPDX und als CycloneDX, damit ein Scanner wie Grype es gegen die Advisories prüft, die er kennt.
THIRD_PARTY_NOTICES.mddaneben enthält die Lizenzen der Komponenten von Dritten. - OpenVEX. Akzeptiert ein Projekt ein Advisory, mit dem Grund, warum es das Projekt nicht betrifft, trägt sein Release ein OpenVEX-Dokument, das das einem Scanner sagt. Ein Release ohne akzeptiertes Advisory trägt keines.
- So geprüft, wie du prüfen kannst. Nach jedem Release und jede Woche prüft ein Workflow jedes Projekts sein neuestes Release so, wie die Befehle unten es tun.
- Testabdeckung und Mutations-Score. Der Anteil des Codes, den die Tests eines Projekts ausführen, und der Anteil der Mutanten, kleiner Änderungen am Code, die seine Tests erkennen.
- OpenSSF Scorecard. Die OpenSSF Scorecard bewertet jede Woche die Sicherheitspraktiken jedes Repositorys, mit bis zu 10 Punkten, etwa signierte Releases, fest gepinnte Abhängigkeiten, den Schutz seines Hauptzweigs und die Berechtigungen seiner Workflows.
- OpenSSF Best Practices. Das OpenSSF-Best-Practices-Badge jedes Projekts, auf der Stufe bestanden, Silber oder Gold, von denen jede mehr Kriterien verlangt als die vorige.
- Sicherheitsrichtlinie und vertrauliche Meldungen. Die SECURITY.md jedes Projekts beschreibt auf Englisch, was mit der Meldung einer Sicherheitslücke geschieht: eine Antwort innerhalb von 7 Tagen, eine erste Einschätzung innerhalb von 14 und ein Release mit dem Fix spätestens nach 90 Tagen. Meldungen gehen vertraulich an das Projekt, über das Formular von GitHub in der Tabelle, nie in ein öffentliches Issue. Meldungen auf Deutsch sind willkommen.
Ein Release selbst prüfen¶
Die GitHub CLI, gh, prüft die Signaturen mit den öffentlichen Schlüsseln von GitHub und Sigstore, die sie selbst abruft. Ohne Tag nimmt sie das neueste Release, das die Tabelle zeigt; diese Befehle prüfen die Releases, seit der Release-Workflow eines Projekts unveränderliche, signierte Releases baut, und ältere Releases geben die Garantien, die die SECURITY.md ihres Projekts damals beschrieb. Der erste Befehl prüft die Attestierung des Releases und gibt die Dateien aus, die sie an seinen Tag bindet; der zweite lädt das Paket herunter, das du installierst, oder die SBOM eines Projekts ohne Paket; und der dritte prüft die Provenienz dieser Datei und gibt Verification succeeded aus: Der Release-Workflow des Projekts hat sie aus dem Commit des Tags gebaut.
gh release verify --repo Dennis-Otto/ha-autodarts
gh release download --repo Dennis-Otto/ha-autodarts --pattern autodarts.zip --clobber
gh attestation verify autodarts.zip --repo Dennis-Otto/ha-autodarts --signer-workflow Dennis-Otto/ha-autodarts/.github/workflows/build-release.yml
gh release verify --repo Dennis-Otto/paperless-sync
gh release download --repo Dennis-Otto/paperless-sync --pattern paperless_sync.tar.gz --clobber
gh attestation verify paperless_sync.tar.gz --repo Dennis-Otto/paperless-sync --signer-workflow Dennis-Otto/paperless-sync/.github/workflows/build-release.yml
gh release verify --repo Dennis-Otto/paperless-unified-search
gh release download --repo Dennis-Otto/paperless-unified-search --pattern paperless_unified_search.tar.gz --clobber
gh attestation verify paperless_unified_search.tar.gz --repo Dennis-Otto/paperless-unified-search --signer-workflow Dennis-Otto/paperless-unified-search/.github/workflows/build-release.yml
gh release verify --repo Dennis-Otto/issue-assistant
gh release download --repo Dennis-Otto/issue-assistant --pattern issue-assistant.spdx.json --clobber
gh attestation verify issue-assistant.spdx.json --repo Dennis-Otto/issue-assistant --signer-workflow Dennis-Otto/issue-assistant/.github/workflows/build-release.yml
gh release verify --repo Dennis-Otto/repo-blueprint
gh release download --repo Dennis-Otto/repo-blueprint --pattern repo-blueprint.spdx.json --clobber
gh attestation verify repo-blueprint.spdx.json --repo Dennis-Otto/repo-blueprint --signer-workflow Dennis-Otto/repo-blueprint/.github/workflows/build-release.yml
Einen signierten Tag prüfen¶
gitsign prüft die Signatur eines Tags so, wie der Workflow es tut, der jedes Release prüft: dass der Release-Workflow des Projekts ihn auf seinem main signiert hat. In einer Shell wie Bash, mit dem Namen des Repositorys eines Projekts in repo:
repo=ha-autodarts
git clone --quiet --no-checkout --filter=blob:none "https://github.com/Dennis-Otto/$repo.git"
cd "$repo"
tag=$(gh release view --repo "Dennis-Otto/$repo" --json tagName --jq .tagName)
gitsign verify-tag "$tag" --certificate-identity "https://github.com/Dennis-Otto/$repo/.github/workflows/release.yml@refs/heads/main" --certificate-oidc-issuer https://token.actions.githubusercontent.com
Eine Sicherheitslücke melden¶
Bitte eröffne für eine vermutete Sicherheitslücke kein öffentliches Issue. Melde sie vertraulich an ihr Projekt, mit dem Link in der Tabelle; Diese Website sagt, wohin eine Sicherheitslücke der Website geht. Die Seite Über erzählt, wer die Projekte baut und wie.