Sicherheit

Sicherheitslücke melden

Schreiben Sie an security@ict-baden.de. Bitte eröffnen Sie kein öffentliches Issue auf GitHub. Jedes Produkt-Repository enthält außerdem eine SECURITY.md mit dem vertraulichen Meldeweg über GitHub („Report a vulnerability“).

Was eine gute Meldung enthält

• Produkt und Version (steht im Info-Fenster der Anwendung und im Namen des Releases)
• Betriebssystem und Version, bei Vitrine auch das Anmeldeverfahren
• Schritte zum Nachstellen, möglichst knapp
• die mögliche Auswirkung aus Ihrer Sicht
• bei Bedarf Protokollauszüge – bitte ohne Mandanten- oder Client-IDs, Kontonamen oder echte Protokolldateien

Was Sie erwarten können

Eingangsbestätigung

innerhalb von drei Werktagen

Einschätzung

innerhalb von zehn Werktagen, mit einer ersten Bewertung der Schwere

Behebung

so schnell wie möglich, abhängig von der Schwere

Veröffentlichung

koordiniert: erst die Behebung, dann der Hinweis

Wir halten uns an koordinierte Offenlegung. Richtwert sind 90 Tage ab Meldung; braucht eine Behebung länger, sprechen wir den Zeitpunkt mit Ihnen ab. Behobene Lücken veröffentlichen wir als GitHub Security Advisory im jeweiligen Repository und nennen Sie dort auf Wunsch als Finder. Ein Prämienprogramm gibt es nicht.

Möchten Sie verschlüsselt kommunizieren, schreiben Sie uns zuerst unverschlüsselt ohne Einzelheiten; wir vereinbaren dann einen Weg (S/MIME oder PGP). Die Angaben dieser Seite stehen maschinenlesbar nach RFC 9116 unter /.well-known/security.txt.

Sicherheitsupdates gibt es für die jeweils neueste veröffentlichte Version eines Produkts; Kunden mit Support-Vertrag zusätzlich für die vorherige Hauptversion, bis zwölf Monate nach Erscheinen der Nachfolgerin. Kunden mit Supportvertrag erhalten Sicherheitsinformationen vorab per E-Mail.

Wie ein Release entsteht

Der Quellcode aller Produkte liegt öffentlich unter github.com/ict-baden, Lizenz MIT. Jede Version wird in GitHub Actions gebaut, aus dem Git-Tag des Repositorys; die Workflow-Datei liegt im Repository, das Protokoll jedes Laufs ist einsehbar. Niemand baut Releases auf einem Arbeitsplatzrechner.

• Tag-Releases (v1.2.3) sind die Versionen für den Betrieb. Sie sind auf GitHub als „Latest“ markiert, die Dateinamen tragen die Version.
• Das rollierende Release „latest“ ist eine Vorabversion: der jeweils neueste Stand des Hauptzweigs, zum Testen. Für den Produktivbetrieb nehmen Sie das neueste Tag-Release.
• Tests laufen in jedem Build, vor dem Packen: Unit-Tests bei allen Produkten, bei den Android-Apps dazu Android Lint. Bei Vitrine wird die MSI zusätzlich auf einem frischen Windows-Runner in GitHub Actions installiert, aktualisiert und deinstalliert; scheitert das, entsteht kein Release. Tests auf echten Geräten stehen bei allen Produkten noch aus (siehe „Grenzen“ auf den Produktseiten).

Die Stückliste (SBOM) im Format CycloneDX nennt alle Bibliotheken mit Version und Lizenz, die im Paket stecken. Sie lässt sich in gängige Werkzeuge zur Schwachstellen- und Lizenzprüfung laden. Für Industrial Keyboard fehlt sie noch; wir ergänzen sie.

Abhängigkeiten aktualisiert Dependabot: wöchentlich für die Bibliotheken (NuGet bei den Windows-Produkten, Gradle bei den Android-Apps), monatlich für die verwendeten GitHub Actions. Versionssprünge, die die Lizenz einer Bibliothek ändern würden – etwa ein Wechsel von MIT zu AGPL – sind in der Konfiguration ausgenommen und werden nicht automatisch übernommen.

Sicherheitshinweise veröffentlichen wir als GitHub Security Advisory im betroffenen Repository und verweisen auf dieser Seite darauf. Bisher gibt es keinen veröffentlichten Sicherheitshinweis. Kunden mit Supportvertrag informieren wir vorab per E-Mail, bevor ein Hinweis öffentlich wird.

Signatur der Downloads

Windows: Vitrine, Lupe, Zutritt, Riegel

Die Windows-Pakete sind derzeit nicht code-signiert. Beim ersten Start einer EXE oder MSI warnt Windows SmartScreen, bei Lupe fragt macOS Gatekeeper einmal nach. Ein Code-Signatur-Zertifikat für ICT Baden ist beantragt; die Signatur über einen Signaturdienst ist in den Build-Workflows bereits vorbereitet und greift, sobald das Zertifikat vorliegt. Bis dahin prüfen Sie die Dateien über die Prüfsummen:

• Windows (PowerShell): Get-FileHash .\Vitrine-x64.msi -Algorithm SHA256 und den Wert mit der Zeile in SHA256SUMS.txt vergleichen
• Linux und macOS: sha256sum -c --ignore-missing SHA256SUMS.txt im Download-Ordner

Die Prüfsummen entstehen im selben Build wie die Dateien. Sie belegen, dass ein Download unverändert bei Ihnen angekommen ist – nicht, wer ihn gebaut hat. Diese Lücke schließt erst die Code-Signatur. Riegel empfiehlt in seiner Dokumentation deshalb ausdrücklich, vor der Signatur keine Piloten auf OT- oder validierten Rechnern zu fahren; sein Sammler wird bis dahin über den Hash auf Allowlists genommen.

Android: Industrial Keyboard, Industrial Kiosk Browser

APK und App Bundle werden im Build mit dem Release-Schlüssel von ICT Baden signiert; der Schlüssel liegt als Secret in GitHub Actions, der Build prüft die Signatur nach dem Packen. Ohne Schlüssel veröffentlicht der Build keine APK. Industrial Keyboard ist seit Version 2.0.0 (Oktober 2026) so signiert. Industrial Kiosk Browser hat mit Version 0.7.0 einen neuen Paketnamen bekommen; die aktuellen Builds unter diesem Namen sind signiert, Android behandelt sie gegenüber den alten Paketen als neue App.

Was die Software nicht tut

Alle sechs Produkte dokumentieren in ihrem Repository (docs/data-and-privacy.md), was sie wo speichern und welche Verbindungen sie aufbauen. Gemeinsam ist ihnen:

• Keine Daten an ICT Baden. Keine Telemetrie, keine Absturzberichte, keine Nutzungsstatistik, kein Update-Check. Vitrine und Zutritt zeigen diesen Satz im Info-Fenster an.
• Keine Cloud-Pflicht, kein Lizenzserver, kein Konto bei ICT Baden. Die Software ist MIT-lizenziert, es gibt keine Lizenzschlüssel. Lupe, Riegel und Industrial Keyboard enthalten gar keinen Netzwerkcode; Industrial Keyboard hat nicht einmal die Internet-Berechtigung von Android, Riegel sichert das mit einem Test gegen den Quellcode ab.
• Verbindungen nur zu dem, was Sie konfigurieren: Vitrine zur Microsoft-Anmeldung, wenn Sie Entra ID einrichten; Zutritt zu den Dateiservern und Domänencontrollern, die es auswertet; Industrial Kiosk Browser zu den Web-Anwendungen, die Sie eintragen – die Android System WebView prüft Adressen dabei wie üblich mit Google Safe Browsing, siehe die Produktseite.
• Die Daten bleiben bei Ihnen. Protokolle, Signaturen, Auswertungen und Berichte liegen auf Ihren Systemen. Sie sind Verantwortlicher im Sinne der DSGVO; ICT Baden verarbeitet nichts davon durch die Software.

Die Datenschutzhinweise der Apps, auf die die Programme verlinken, stehen auf dieser Website: Vitrine, Lupe, Zutritt, Riegel, Industrial Kiosk Browser, Industrial Keyboard.

NIS2, GxP und die Rolle des Betreibers

NIS2

Unsere Produkte sind Werkzeuge, die Sie als Betreiber einsetzen; ICT Baden ist in Ihrer Lieferkette der Hersteller. Wir sagen nicht zu, dass ein Produkt „NIS2-konform“ ist – das ist keine Eigenschaft einer Software, sondern Ihres Betriebs. Was wir dafür liefern:

• den vollständigen Quellcode und die Stückliste (SBOM) je Release, für Ihre Lieferkettenbewertung
• Prüfsummen zu jedem Download und, sobald das Zertifikat vorliegt, Code-Signaturen
• einen festen Meldeweg, koordinierte Offenlegung und Sicherheitshinweise als GitHub Security Advisory
• Sicherheitsupdates für die jeweils neueste Version; Abhängigkeiten werden laufend aktualisiert
• die Dokumentation, was die Software speichert, verbindet und bewusst nicht kann (docs/data-and-privacy.md, docs/limitations.md in jedem Repository)

Bei Ihnen bleiben Risikobewertung und Freigabe, Verteilung und Patch-Management, Konfiguration und Härtung der Systeme, die Überwachung im Betrieb und die Meldung von Vorfällen an Ihre Behörden.

Pharma und GxP: Teil 11 und Annex 11

ICT Baden sagt für kein Produkt zu, dass sein Einsatz 21 CFR Part 11, EU GMP Annex 11 oder eine andere Vorschrift erfüllt. Vitrine liefert Bausteine, die GxP-Arbeitsplätze verlangen – Zugriffskontrolle, eindeutige Identifikation, einen manipulationserkennenden Audit-Trail und elektronische Signaturen mit Bedeutung; Einzelheiten im GxP-Abschnitt der Vitrine-Seite. Unterlagen für Ihre eigene Qualifizierung (Spezifikation, Risikobewertung, Testprotokolle) erstellen wir nach Aufwand, siehe Leistungen nach Aufwand auf der Support-Seite. Validierung und Risikobewertung liegen beim Betreiber; Code und Protokollformat sind bewusst einfach gehalten, damit eine Validierung machbar ist.

Diese Website

Die Website ist statisch: keine Server-Logik, keine Datenbank, keine Formulare. Sie setzt keine Cookies, bindet keine Fremdinhalte ein (Schriften und Skripte kommen vom eigenen Server) und verwendet kein Tracking. Was der Webserver protokolliert, steht in der Datenschutzerklärung.

Der Server sendet mit jeder Antwort diese Sicherheits-Header:

Content-Security-Policy

default-src 'none'; Skripte, Stylesheets, Bilder, Schriften, Medien und Verbindungen nur vom eigenen Server; frame-ancestors 'none', base-uri 'none', form-action 'none', object-src 'none'

Strict-Transport-Security

max-age=31536000 (ein Jahr, ohne includeSubDomains, ohne preload)

X-Content-Type-Options

nosniff

X-Frame-Options

DENY

Referrer-Policy

strict-origin-when-cross-origin

Permissions-Policy

Kamera, Mikrofon, Standort, Bewegungssensoren, Zahlung und USB abgeschaltet

Cross-Origin-Opener-Policy

same-origin

Cross-Origin-Resource-Policy

same-origin

Die Konfiguration des Webservers liegt mit dem Quellcode der Website im Repository ict-baden/website.