Eine Desktopanwendung steht sowohl auf ihrer Veröffentlichungsseite als auch auf einem Spiegelserver bereit. Dateinamen und Versionsnummern stimmen überein, doch Nutzer brauchen weitere Antworten: Sind es dieselben Dateien, wer hat sie veröffentlicht, stammen sie aus dem erwarteten Code und Build-Prozess und eignen sie sich für dieses Gerät?
Diese Fragen verlangen unterschiedliche Belege. Jede Prüfmethode als „Sicherheitszertifizierung“ zu bezeichnen, weckt Erwartungen, die sie nicht erfüllen kann, und kann Entwickler Lücken im Veröffentlichungsprozess übersehen lassen.
Prüfsummen klären, ob Dateien übereinstimmen
Ein nach dem Download berechneter und mit einem Sollwert verglichener Hash kann zeigen, ob die Dateiinhalte übereinstimmen. Voraussetzung ist, dass der Sollwert aus einem vertrauenswürdigen Kanal stammt. Kommen Datei und Prüfsumme von derselben ungeprüften Seite, belegt ihre Übereinstimmung keine Herausgeberidentität.
Ein abweichender Hash bedeutet umgekehrt, dass sich Dateien unterscheiden, beweist aber allein keine böswillige Absicht. Andere Builds, eine neue Verpackung oder ein falscher Download können Unterschiede verursachen. Behandeln Sie die Datei nicht länger als verifizierte Veröffentlichung und prüfen Sie Quelle, Zielplattform und zugehörigen Prüfsummeneintrag erneut.
Herausgeber sollten eindeutige Dateinamen, Versionsangaben und Prüfsummenverzeichnisse gemeinsam pflegen. Nutzer sollten keinen Hash aus einem alten Artikel mit einem Installer für eine andere Plattform oder einen anderen Build vergleichen müssen.
Signaturen verlangen die Prüfung der erwarteten Identität
Eine digitale Signatur verbindet einen Unterzeichner mit signierten Daten. Die Prüfung muss jedoch auch feststellen, ob dies die erwartete Identität ist. Sigstores Prüfdokumentation verlangt neben der Signaturprüfung entsprechende Bedingungen für Identität und Aussteller und verdeutlicht damit diesen Unterschied. Sigstore-Prüfdokumentation
Bei „gültige Signatur“ sollten Nutzer auch klären, für welchen Herausgeber oder Workflow sie steht. Entwickler sollten festlegen, welche Identitäten offizielle Veröffentlichungen signieren dürfen. Nicht jede mathematisch gültige Signatur darf automatisch den Status einer offiziellen Veröffentlichung verleihen.
Ändern Herausgeber Zertifikate oder Signierverfahren, brauchen Nutzer eine überprüfbare Erklärung. Sie spontan um Vertrauen in ein unbekanntes Zertifikat zu bitten, ist kein vollständiger Aktualisierungsprozess.
Build-Herkunft verbindet ein Paket mit seiner Herstellung
GitHubs Artefaktattestierungen können die Build-Herkunft dokumentieren und die Zuordnung eines Artefakts zu Repository- und Workflowinformationen prüfen helfen. Sie liefern Belege für die Herstellung einer Datei; trotzdem müssen das tatsächliche Artefakt und die erwartete Identität geprüft werden. GitHub-Dokumentation zu Artefaktattestierungen
Die Build-Stufen von SLSA unterscheiden zusätzlich zwischen vorhandenen Herkunftsaufzeichnungen, signierten Herkunftsbelegen einer gehosteten Plattform und strengeren Schutzmaßnahmen der Build-Plattform. Nennen Sie bei einer Stufe ihren Geltungsbereich und ihre Belege, statt die Zahl als Bewertung sämtlicher Softwarerisiken zu behandeln. SLSA-Build-Stufen
| Beleg | Was er vor allem nachweisen hilft | Was er allein nicht belegt |
|---|---|---|
| Prüfsumme | Ob die erwarteten Dateiinhalte vorliegen | Herausgeberidentität oder sicheres Programmverhalten |
| Digitale Signatur | Wer welche Daten signiert hat | Ob der Unterzeichner Ihre Vertrauensanforderungen erfüllt |
| Build-Herkunft | Welcher Build-Prozess das Artefakt erzeugt hat | Dass Quellcode und Abhängigkeiten vollständig fehlerfrei sind |
| Reproduzierbarer Build | Ob unter festgelegten Bedingungen dasselbe Artefakt erneut entsteht | Dass die Software keine Schwachstellen oder unerwünschten Verhaltensweisen hat |
Diese Belege können sich ergänzen. Entwickler sollten erklären, was sie bereitstellen und welche Prüfungen weiterhin unabhängig erfolgen müssen.
Reproduzierbare Builds brauchen ausdrückliche Eingaben und Umgebungen
Das Projekt Reproducible Builds definiert einen reproduzierbaren Build als einen, der aus demselben Quellcode, derselben Build-Umgebung und denselben Anweisungen die festgelegten Artefakte bitgenau erneut erzeugt. Das ist ein genaueres Prüfziel als „Auf meinem Rechner lässt es sich kompilieren“. Definition reproduzierbarer Builds
Wir empfehlen, Toolchain, festgeschriebene Abhängigkeiten, Build-Parameter und ihre Zuordnung zu veröffentlichten Artefakten aufzubewahren. Ist Reproduzierbarkeit nicht erreicht, dokumentieren Sie präzise, wie weit der Nachbau gelingt, statt Unterschiede auszulassen und die Prüfung als bestanden zu erklären.
Auch der Umfang eines öffentlichen Repositorys braucht eine Erklärung. Es kann den Kernquellcode enthalten oder überwiegend Build-Werkzeuge, Konfigurationen und vorgelagert erzeugte Anwendungspakete. Nutzer müssen wissen, welche Teile sie tatsächlich untersuchen und nachbauen können, um Herkunftsbelege angemessen zu bewerten.
Eine praktische Reihenfolge zur Downloadprüfung
- Das Veröffentlichungsrepository über den offiziellen Projekteinstieg bestätigen, statt nur Suchanzeigen oder weitergeleiteten Links zu vertrauen.
- Versionshinweise lesen und Betriebssystem, Prozessorarchitektur und Veröffentlichungskanal prüfen.
- Die Datei mit ihrer zugehörigen Prüfsumme vergleichen. Bei verfügbaren Signaturen oder Herkunftsbelegen auch erwartete Identität und Geltungsbereich prüfen.
- Wartungsstand und bekannte Einschränkungen prüfen, ohne aus der Markierung „latest“ eine Eignung für den Produktivbetrieb abzuleiten.
- Bei widersprüchlichen Angaben Version und Dateinamen festhalten und über die Supportkanäle des Projekts Klärung suchen.
Nicht jeder Nutzer muss dafür zum Build-Ingenieur werden. Produkte können komplexe Belege auf einer übersichtlichen Veröffentlichungsseite bündeln: woher Dateien stammen, für wen sie geeignet sind, wie sie geprüft werden und wo Abweichungen gemeldet werden können.
Für Entwickler ist die dauerhafte Pflege dieser Informationskette wertvoller als ein einmaliges „verifiziert“-Abzeichen. Auch wenn eine alte Version zurückgezogen wird, sich das Signierverfahren ändert oder ein Update scheitert, sollten Nutzer passende Erklärungen finden.
AlphaBiz unterscheidet in seiner öffentlichen Repositorybeschreibung zwischen Build-Werkzeugen und vorgelagert erzeugten Anwendungspaketen. Bei solchen Desktopanwendungen sollten wir ebenso den tatsächlichen Prüfumfang benennen, statt öffentliches Repository, vollständigen Quellcode und reproduzierbare Veröffentlichungen gleichzusetzen. AlphaBiz-Projektübersicht
Entwickler können zunächst ein vollständiges Verzeichnis ihrer Veröffentlichungsbelege erstellen; Nutzer können einen Download einer häufig verwendeten Anwendung prüfen. Teilen Sie in AlphaBiz Discussions, welche Prüfinformationen Veröffentlichungsseiten bieten sollten.