Sicherheit und Datenverarbeitung

Ein Werkzeug, das Secrets jagt, darf nicht selbst zur Leckstelle werden. Diese Seite sagt genau, was der Sensitive Data Scanner aufbewahrt und was nicht.

Für eine Sicherheitsprüfung

Wenn Sie das Produkt bewerten statt betreiben, beginnen Sie hier:

• Architektur und Datenfluss - jede Komponente, jede ausgehende Verbindung und wo welche Daten liegen.
• Sicherheitsfragebogen - vorausgefüllte Antworten auf die üblichen Prüffragen, auch dort, wo die Antwort Nein lautet.
• Software-Stückliste (SBOM) - für jedes Release wird aus dem Build eine CycloneDX-SBOM erzeugt: der aufgelöste Maven-Graph des Backends in JSON und XML sowie der aufgelöste Abhängigkeitsbaum des Frontends in JSON. Beide hängen am GitHub-Release der jeweiligen Version und liegen nie im Repository, weil eine abgelegte SBOM unbemerkt veraltet. Wenn Sie das Release nicht erreichen, fordern Sie die SBOM zu einer bestimmten Version unter info@arcsoft.ch an.
• Signierte Images und Build-Provenienz - jedes veröffentlichte Image wird schlüssellos mit cosign signiert und trägt eine SLSA-Provenienz- sowie eine SBOM-Attestierung. Die Prüfbefehle stehen im Sicherheitsfragebogen.
• Was bei jedem Commit läuft - Tests und Architekturregeln, Abhängigkeitsprüfung, CodeQL und ein gitleaks-Scan der gesamten Commit-Historie. Ebenfalls im Sicherheitsfragebogen.

Die Kernzusage: Rohwerte werden nie gespeichert

Wenn eine Regel trifft, speichert der Scanner genau zwei Dinge:

• Einen geschlüsselten Fingerabdruck - ein HMAC-SHA256 des Treffers, mit dem derselbe Fund über Scans hinweg wiedererkannt wird, sodass Prüfentscheidungen und Unterdrückungen erhalten bleiben.
• Eine Fundstelle - Projekt, Issue-Schlüssel, das Feld, der Kommentar oder der Anhang, die Textvariante und die Zeichen-Offsets.

Das ist der gesamte Datensatz. Es gibt keinen Ausschnitt, in keiner Form - keinen maskierten, keinen gekürzten, auch nicht den umgebenden Kontext. Nichts, was aus dem getroffenen Text abgeleitet ist, wird gespeichert, exportiert, geloggt oder angezeigt: weder auf der Funddetailseite noch im Dashboard noch in einem CSV-Export noch in einem E-Mail-Report. Ein Fund sagt Ihnen, wo Sie nachsehen müssen und welche Regel ausgelöst hat, sonst nichts. Um den tatsächlichen Wert zu sehen, folgen Sie dem Link zum Jira-Issue und lesen ihn in Jira, wo er ohnehin bereits liegt.

Der Fingerabdruck ist geschlüsselt, kein einfacher Hash. Ohne FINDING_FINGERPRINT_HMAC_SECRET bietet eine entwendete Datenbank keinen Wörterbuchangriff auf kurze Trefferwerte.

Rein lesend gegenüber Jira

Der Scanner erreicht Jira ausschliesslich über die Jira REST API mit einem Service-Account. Er installiert kein Jira-Plugin und rührt die Jira-Datenbank nie an. Er führt überhaupt keine Schreibvorgänge aus: keine Bearbeitungen, keine Kommentare, keine Löschungen, keine Schwärzungen, keine Feldänderungen. Der Service-Account benötigt nur Projekte durchsuchen in den Projekten im Scope - keine Jira-Administratorrechte.

Anhangsinhalte werden heruntergeladen, im Arbeitsspeicher geparst, gescannt und verworfen; extrahierter und per OCR erkannter Text wird nie gespeichert. Bildanhänge sind die einzige Ausnahme von "nur im Arbeitsspeicher": Für die Dauer der OCR werden die Bild-Bytes in ein privates temporäres Verzeichnis (Berechtigungen nur für den Eigentümer) geschrieben und danach gelöscht. Manuelle Prüfungen speichern den Dateinamen des Anhangs, den Issue-Schlüssel und den Grund - nie Bild-Bytes oder OCR-Text. OCR läuft in einem separaten, ressourcenbegrenzten Prozess, der keines der Geheimnisse des Scanners erhält; der Netzwerkzugriff dieses Prozesses ist nicht eingeschränkt. Siehe Anhänge scannen.

Zugangsdaten im Ruhezustand

Zugangsdatum	Schutz
Zugangsdaten des Jira-Service-Accounts	AES-256-GCM-verschlüsselt mit JIRA_CREDENTIAL_ENCRYPTION_KEY, der Ihre Umgebung nie verlässt.
SMTP-Passwort für das Reporting	Dieselbe Verschlüsselung, derselbe Schlüssel.
OIDC	Es wird kein Zugangsdatum gespeichert. Benutzer authentifizieren sich gegen Ihren Identity Provider; das Backend validiert lediglich JWTs als OAuth2 Resource Server.

Keines der Zugangsdaten wird je von der API zurückgegeben, nach dem Speichern in der Oberfläche angezeigt oder in eine Fehlermeldung aufgenommen. Der Jira-Verbindungstest und die Reporting-Test-E-Mail liefern genau deshalb bereinigte Fehler: Roher SMTP- und Jira-Antworttext kann Hostnamen und Zugangsdaten zurückspiegeln.

Keine ausgehenden Aufrufe

• Kein Phone-Home. Die Lizenzierung ist offline: Die Signaturprüfung erfolgt lokal gegen einen in die Anwendung kompilierten öffentlichen Schlüssel. Siehe Lizenz.
• Keine Cloud-KI, keine externe Analyse. Die Mustererkennung läuft lokal.
• Keine Telemetrie, keine Nutzungsanalyse.

Die einzigen ausgehenden Verbindungen des Scanners gehen zu Ihrer Jira-Instanz, Ihrem Identity Provider, Ihrer Datenbank und - falls Sie Reporting einrichten - Ihrem SMTP-Server. Der Scanner ist dafür ausgelegt, in einem Netz zu laufen, das das Internet überhaupt nicht erreicht.

Zugriffssteuerung

Zwei Rollen, aufgelöst aus einem Claim im OIDC-Access-Token:

• ADMIN - voller Zugriff auf jede Seite und jede Aktion.
• USER - rein lesender Zugriff auf das Risiko-Dashboard, die Fundliste samt Funddetail und die Historie der Unterdrückungen. Ein USER kann einen Fund weder prüfen noch einstufen, keine Unterdrückung anlegen oder aufheben und keinen Scan starten, pausieren, fortsetzen oder abbrechen.

Jede andere Seite ist ADMIN-only: Scans, Regelkatalog, eigene Regel anlegen, Audit-Log, Jira-Verbindung, Lizenz, Scan-Konfiguration, Regelsatz-Transfer, Reporting und die ausgeblendeten Seiten der Mustererkennung. Die Navigation blendet aus, was ein USER nicht erreichen kann, und eine nicht berechtigte Anfrage wird mit HTTP 403 und demselben bereinigten Fehlerkörper abgewiesen, den die übrige API liefert.

Funde ausserhalb des durchsuchbaren Scopes sind eingeschränkt: Ihre Details sind verborgen, und sie lassen sich nicht für Sammelaktionen auswählen. Geprüft wird, was das konfigurierte Service-Konto durchsuchen darf, nicht was der angemeldete Benutzer durchsuchen darf - alle angemeldeten Benutzer sehen also dieselben Funde, und die Einschränkung begrenzt auf den Scope, nicht pro Benutzer. Eine benutzerbezogene Einschränkung setzt Jira-Impersonation voraus, die das Produkt nicht implementiert. Siehe Identity Provider.

Audit-Trail

Jede wesentliche Aktion wird mit Akteur, Zeitstempel, Aktion, Ziel und bereinigten Metadaten protokolliert: Konfigurationsänderungen, Verbindungsänderungen, Lizenz-Uploads, Scan-Starts, Prüfentscheidungen, Unterdrückungen, Regeländerungen und Rollbacks, Regelsatz-Importe und -Exporte, CSV-Exporte, Report-Läufe und Bereinigungsläufe. Audit-Metadaten enthalten nie sensible Rohwerte, und Audit-Ereignisse lassen sich über die Oberfläche nicht bearbeiten. Siehe Audit-Log.

Lebensdauer der Daten

Funde, Vorkommen, Prüfereignisse, Scan-Läufe und abgelöste Regelversionen werden endgültig gelöscht, sobald sie älter als die konfigurierte Aufbewahrungsfrist sind; diese beträgt standardmässig zehn Jahre. Audit-Ereignisse werden nicht gelöscht, sofern der Betreiber dies nicht ausdrücklich aktiviert. Siehe Datenaufbewahrung.

Self-hosted by design

Der Scanner läuft vollständig in Ihrer Infrastruktur: Ihr Container, Ihre Datenbank, Ihr Netz. Zu keinem Zeitpunkt werden Jira-Inhalte, Funde oder Metadaten an arcsoft oder an Dritte übermittelt.

Eine Schwachstelle melden

Wenn Sie glauben, eine Sicherheitslücke im Sensitive Data Scanner gefunden zu haben, melden Sie sie bitte vertraulich an info@arcsoft.ch, statt ein öffentliches Issue zu eröffnen. Nennen Sie die betroffene Version, Ihre Beobachtung und die Schritte zur Reproduktion. Wir bestätigen Ihre Meldung und halten Sie auf dem Laufenden, während wir an einer Behebung arbeiten.

Bitte testen Sie nicht gegen Systeme, die Sie weder besitzen noch betreiben.