Sicherheitsfragebogen

Dies sind die Fragen, die eine Sicherheitsprüfung üblicherweise als Tabelle verschickt - einmal öffentlich beantwortet. Jede Antwort verweist auf die Seite oder das Verhalten, das sie belegt. Wo etwas nicht umgesetzt ist, steht hier nicht implementiert statt einer Lücke.

Betrieb und Datenstandort

Wo wird die Software betrieben? In Ihrer Infrastruktur. Sensitive Data Scanner wird als einzelner Container ausgeliefert, den Sie auf eigener Hardware oder in Ihrer Cloud betreiben, gegen Ihre eigene Datenbank und Ihre eigene Jira-Instanz. Es gibt keine SaaS-Variante und keinen herstellerseitigen Mandanten. Siehe Architektur und Datenfluss.

Wo liegen die Kundendaten? Dort, wo Sie den Container und seine PostgreSQL-Datenbank betreiben. Der Hersteller ist an dieser Wahl nicht beteiligt und hat keinen Einblick.

Hält der Hersteller Kundendaten? Nein. Zu keinem Zeitpunkt werden Jira-Inhalte, Funde oder Metadaten an arcsoft übermittelt. Das ist eine Eigenschaft der Software und keine blosse Zusage - es existiert keine ausgehende Verbindung zum Hersteller, die etwas übertragen könnte. Siehe Sicherheit und Datenverarbeitung.

Lässt sich das Produkt ohne Internetzugang betreiben? Ja. Die Lizenzierung ist offline und wird lokal gegen einen in die Anwendung kompilierten öffentlichen Schlüssel geprüft; es gibt kein Phone-Home, keine Telemetrie und keinen externen Analysedienst. Der Scanner ist dafür ausgelegt, in einem Netz ganz ohne Route ins Internet zu laufen.

Kann der Hersteller für den Support auf unsere Installation zugreifen? Nicht implementiert. Es gibt keinen Fernwartungskanal, kein eingebautes Screen-Sharing und keine Hintertür. Diagnoseinformationen erreichen uns nur, wenn Sie sie uns senden.

Datenschutz und Verschlüsselung

Was speichert das Produkt zu einem gefundenen Geheimnis? Einen geschlüsselten Fingerabdruck und eine Fundstelle - Projekt, Issue-Schlüssel, das Feld, den Kommentar oder den Anhang, die Textvariante und die Zeichen-Offsets. Sonst nichts. Es gibt keinen Ausschnitt, weder maskiert noch anders: Nichts, was aus dem getroffenen Text oder dem Text darum herum abgeleitet ist, wird gespeichert. Der Trefferwert selbst wird nie in die Datenbank geschrieben, nie geloggt, nie exportiert und nie in der Oberfläche angezeigt. Um den tatsächlichen Wert zu sehen, folgen Sie dem Link nach Jira, wo er ohnehin liegt. Siehe Sicherheit und Datenverarbeitung.

Ist der Fingerabdruck umkehrbar? Es handelt sich um ein HMAC-SHA256, geschlüsselt mit FINDING_FINGERPRINT_HMAC_SECRET, nicht um einen einfachen Hash. Eine entwendete Datenbank erlaubt damit keinen Wörterbuchangriff auf kurze Trefferwerte.

Was geschieht mit Anhangsinhalten? Sie werden heruntergeladen, im Arbeitsspeicher geparst, gescannt und verworfen. Extrahierter und per OCR erkannter Text wird nie in die Datenbank oder in Logs geschrieben und fliesst nie in die Mustererkennung ein. Bildanhänge werden für die Dauer der OCR 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, Vorschaubilder oder OCR-Text. OCR läuft in einem separaten Prozess mit Speicher-, CPU- und Zeitgrenzen und ohne die Geheimnisse des Scanners in seiner Umgebung; sein Netzwerkzugriff ist nicht eingeschränkt, und Tesseract enthält keinen Netzwerkcode. Siehe Anhänge scannen.

Wie sind Zugangsdaten im Ruhezustand geschützt? Die gespeicherten Zugangsdaten des Jira-Service-Accounts und das SMTP-Passwort werden mit AES-256-GCM und JIRA_CREDENTIAL_ENCRYPTION_KEY verschlüsselt, der Ihre Umgebung nie verlässt. Keines von beiden wird je von der API zurückgegeben, nach dem Speichern angezeigt oder in eine Fehlermeldung aufgenommen. Ein OIDC-Benutzer-Zugangsdatum wird überhaupt nicht gespeichert.

Ist die Datenbank im Ruhezustand verschlüsselt? Das liegt in Ihrer Verantwortung, nicht in der des Produkts. Der Scanner verschlüsselt die gespeicherten Jira- und SMTP-Zugangsdaten unabhängig von Ihrer Datenbankkonfiguration auf Anwendungsebene. Das übrige Schema - Funde, Fingerabdrücke, Audit-Ereignisse - ist jedoch nur so geschützt, wie Ihre PostgreSQL-Installation und deren Speicher es leisten.

Sind die Daten bei der Übertragung verschlüsselt? Teils Sache des Produkts, teils Ihre:

Verbindung	Wer sie absichert
Browser zum Scanner	Sie. Der Container liefert reines HTTP auf Port 8080 und terminiert kein TLS. Sie stellen ihn hinter Ihren eigenen Reverse Proxy und terminieren TLS dort - siehe Produktivbetrieb.
Scanner zu Jira	Bestimmt durch die Basis-URL, die Sie für die Jira-Verbindung konfigurieren. Konfigurieren Sie eine HTTPS-URL.
Scanner zu PostgreSQL	Bestimmt durch Ihre JDBC-URL und die Konfiguration Ihres PostgreSQL-Servers.
Scanner zu SMTP	Bestimmt durch Ihre SMTP-Host- und Portkonfiguration.

Das Produkt erzwingt auf diesen Verbindungen kein TLS und verweigert ohne TLS den Start nicht.

Zugriffssteuerung und Authentifizierung

Wie authentifizieren sich Benutzer? Gegen Ihren eigenen OIDC Identity Provider. Das Backend validiert JWTs als OAuth2 Resource Server. Es gibt keine lokalen Konten und keine vom Hersteller verwalteten Identitäten. Siehe Identity Provider.

Unterstützt das Produkt MFA, SSO, Passwortrichtlinien oder Kontosperrungen? Diese Punkte sind vollständig an Ihren Identity Provider delegiert. Das Produkt speichert kein Benutzer-Zugangsdatum und implementiert keine eigene Authentifizierung; es gilt also, was Ihr Provider durchsetzt. Das Produkt selbst implementiert nichts davon.

Welches Berechtigungsmodell wird verwendet? Zwei Rollen, aufgelöst aus einem Claim im OIDC-Access-Token. ADMIN hat vollen Zugriff auf jede Seite und jede Aktion. USER ist rein lesend und auf das Risiko-Dashboard, die Fundliste samt Funddetail und die Historie der Unterdrückungen beschränkt: Ein USER kann einen Fund nicht prüfen, keine Unterdrückung anlegen oder aufheben und keinen Scan steuern. Jede andere Seite - Scans, Regeln, Audit-Log und jede Administrationsseite - ist ADMIN-only. Die Navigation blendet aus, was ein USER nicht erreichen kann, und eine nicht berechtigte Anfrage wird mit HTTP 403 abgewiesen, mit demselben bereinigten Fehlerkörper wie in der übrigen API. Funde ausserhalb des durchsuchbaren Scopes sind eingeschränkt - Details verborgen, nicht für Sammelaktionen auswählbar. Dieser Scope ist das, was das konfigurierte Jira-Service-Konto durchsuchen darf, und damit für alle angemeldeten Benutzer gleich; das Produkt schränkt Funde nicht pro Benutzer ein.

Gibt es feinere oder projektbezogene Berechtigungen? Über das beschriebene Einschränkungsverhalten hinaus nicht implementiert. Es gibt keinen Rolleneditor und kein Berechtigungsmodell auf Feldebene.

Welche Rechte benötigt das Produkt in Jira? Projekte durchsuchen in den Projekten im Scope, mehr nicht. Keine Jira-Administratorrechte. Der Scanner installiert kein Jira-Plugin, rührt die Jira-Datenbank nie an und führt keinerlei Schreibvorgänge aus - keine Bearbeitungen, Kommentare, Löschungen, Schwärzungen oder Feldänderungen.

Protokollierung und Audit

Gibt es einen Audit-Trail? Ja. Jede wesentliche Aktion wird mit Akteur, Zeitstempel, Aktion, Ziel und bereinigten Metadaten protokolliert: Konfigurations- und 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. Siehe Audit-Log.

Lässt sich der Audit-Trail bearbeiten oder löschen? Audit-Ereignisse lassen sich über die Oberfläche nicht bearbeiten. Sie sind standardmässig von der Bereinigung ausgenommen und überdauern damit die Funde, die sie beschreiben. Wer direkten Datenbankzugriff hat, kann sie selbstverständlich verändern; das Produkt bietet keine Manipulationssicherheit wie Signierung oder einen ausschliesslich anfügenden Speicher. Das ist nicht implementiert.

Enthalten Logs sensible Werte? Nein. Audit-Metadaten enthalten nie Rohwerte, und der Trefferwert wird in kein Log geschrieben. Jira- und SMTP-Fehler, die Benutzern angezeigt werden, sind gerade deshalb bereinigt, weil roher Antworttext Hostnamen und Zugangsdaten zurückspiegeln kann.

Lassen sich Logs an ein SIEM übergeben? Anwendungslogs gehen nach stdout, sodass die Log-Pipeline Ihrer Container-Plattform sie einsammeln kann. Eine eingebaute Syslog-, CEF- oder SIEM-Anbindung gibt es nicht, ebenso wenig einen Webhook für Audit-Ereignisse. Audit-Ereignisse lassen sich in der Oberfläche lesen und über den CSV-Export ausgeben.

Schwachstellenmanagement und Meldung

Wie melden wir eine Schwachstelle? Vertraulich an info@arcsoft.ch, nicht als öffentliches Issue. Wir bestätigen Meldungen und halten Sie auf dem Laufenden, während wir an einer Behebung arbeiten.

Gibt es ein veröffentlichtes Behebungs-SLA? Nicht implementiert. Es besteht keine vertragliche Zusage zur Behebungsdauer.

Ist eine Stückliste (SBOM) verfügbar? Ja. Für jedes Release wird aus dem Build je eine CycloneDX-SBOM erzeugt - für den aufgelösten Maven-Graph des Backends in JSON und XML, für den aufgelösten Abhängigkeitsbaum des Frontends in JSON. Beide werden bewusst generiert statt von Hand gepflegt und bewusst nicht im Repository abgelegt: Eine handgeschriebene oder eingecheckte SBOM veraltet unbemerkt, und eine veraltete SBOM ist schlechter als keine. Beide hängen am GitHub-Release der jeweiligen Version, Sie können sie also selbst herunterladen, statt sie bei uns anzufragen. Das Quell-Repository ist privat; ohne Zugriff darauf fordern Sie die SBOM zu einem bestimmten Release unter info@arcsoft.ch an.

Gibt es eine automatisierte Prüfung der Abhängigkeiten? Ja. Ein Workflow Dependency Check prüft alle drei Abhängigkeitsbäume - den aufgelösten Maven-Graph des Backends über die erzeugte CycloneDX-SBOM, das Angular-Frontend und die Dokumentationsseite - bei jedem Pull Request, bei jedem Push auf main und zusätzlich einmal wöchentlich nach Zeitplan.

Entscheidend ist der wöchentliche Lauf: Eine Schwachstelle wird in der Regel lange nach dem Hinzufügen der Abhängigkeit bekannt, eine Prüfung nur bei Codeänderungen würde sie also nie sehen. Befunde ohne verfügbare Korrektur werden ausgewiesen statt als Fehler gewertet, weil ein Fehlschlag an etwas Unbehebbarem nur dazu erzieht, den Job zu ignorieren. Beide SBOMs werden als Build-Artefakte veröffentlicht, sodass Sie Ihren eigenen Scanner auf ein Release ansetzen können, statt sich auf unseren zu verlassen.

Wurde das Produkt einem Penetrationstest unterzogen? Nein. Es wurde kein Penetrationstest und kein Sicherheitsaudit durch Dritte durchgeführt.

Wie werden Patches ausgeliefert? Als neues Container-Image. Das Produkt aktualisiert sich nicht selbst und hat keinen Auto-Update-Kanal; das Einspielen eines Releases ist Ihr Betriebsschritt.

Sichere Entwicklung

Was läuft bei jeder Änderung? Änderungen gelangen über einen Pull Request nach main. Diese Workflows laufen am Pull Request und noch einmal beim Merge:

Workflow	Was er abdeckt
Build and Test	Unit- und Integrationstests des Backends, die ArchUnit-Regeln für die hexagonalen Grenzen, Frontend-Unit-Tests, Linting und Abhängigkeitsgrenzen
Dependency Check	Bekannte Schwachstellen in den Abhängigkeitsbäumen von Backend, Frontend und Website sowie die SBOM-Erzeugung
Code Scanning	CodeQL-Analyse des Java- und TypeScript-Codes und ein gitleaks-Scan der gesamten Commit-Historie

Dependency Check und Code Scanning laufen zusätzlich wöchentlich nach Zeitplan, weil das meiste davon erst bekannt wird, lange nachdem sich der Code nicht mehr ändert. Die Playwright-E2E-Suite läuft auf Anforderung statt bei jeder Änderung; sie braucht ein veröffentlichtes Image zum Testen. Build Docker Image läuft nur nach einem erfolgreichen Build and Test, ein Image entsteht also nie aus einem Build mit fehlgeschlagenen Tests.

Wird der Quellcode statisch analysiert? Ja. CodeQL läuft über beide Sprachen - Java für das Backend, TypeScript für das Frontend - mit GitHubs Abfragesatz security-and-quality, bei jedem Pull Request, bei jedem Push auf main und wöchentlich.

Scannen Sie Ihr eigenes Repository auf Geheimnisse? Ja. gitleaks läuft über die gesamte Commit-Historie statt über die aktuellen Dateien, damit auch ein Zugangsdatum gefunden wird, das committet und später gelöscht wurde. Die Prüfung blockiert: Ein Treffer lässt den Build scheitern.

Testfixtures, generierte Testkorpora und Planungsdokumente des Repositories enthalten absichtlich synthetische Geheimnisse - gegen sie werden die Erkennungsregeln getestet -, deshalb sind diese Verzeichnisse in .gitleaks.toml per Pfad ausgenommen. Zugangsdaten an jeder anderen Stelle lassen den Build scheitern.

Sind die veröffentlichten Images signiert? Ja. Jedes veröffentlichte Image wird mit cosign schlüssellos signiert: Das Signaturzertifikat wird auf die Identität des Build-Workflows ausgestellt und läuft nach Minuten ab. Es gibt also keinen langlebigen Signaturschlüssel, den jemand aufbewahrt - auch wir nicht. Signiert wird der Image-Digest, nicht das Tag, denn Tags wandern.

cosign verify arcsoftklg/sensitive-data-scanner:latest \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp '^https://github.com/lombold/project-risk-scanner/.github/workflows/publish-release.yml@'

Gibt es eine Build-Provenienz? Ja. Jedes Image trägt eine SLSA-Provenienz-Attestierung des Builders, die Quell-Repository und Commit, den bauenden Workflow und die Digests der Basis-Images festhält, dazu eine SBOM des Images als zweite Attestierung.

docker buildx imagetools inspect arcsoftklg/sensitive-data-scanner:latest \
  --format '{{ json .Provenance }}'

Beide hängen im Registry am Image und reisen mit ihm: Wer per Digest zieht und die Signatur prüft, weiss, dass das Image aus dem Build dieses Repositories stammt und seither nicht verändert wurde.

Unterauftragsverarbeiter und Dritte

Wer sind die Unterauftragsverarbeiter für Kundendaten? Es gibt keine, weil keine Kundendaten zum Hersteller gelangen. Das Produkt baut keine ausgehende Verbindung zu arcsoft auf, und es gibt herstellerseitig weder Speicherung noch Verarbeitung, die sich weitervergeben liesse.

Welche Dritten sind überhaupt beteiligt? Nur für das eigene Geschäft des Herstellers, nie für Scanner-Daten:

• Lizenzierung. Zur Ausstellung einer Lizenzdatei verarbeitet arcsoft die von Ihnen genannten geschäftlichen Kontaktdaten und das lizenzierte Siehe Datenschutzerklärung.
• Diese Website. Betrieben auf GitHub Pages. Sie setzt keine Tracking- oder Werbe-Cookies, verwendet keinerlei Analyse und lädt keine externen Schriften oder CDNs. Die Dokumentationsseite ist nicht Teil des Produkts, und Ihre Installation kontaktiert sie nicht.

Nutzt das Produkt Cloud-KI oder einen externen Analysedienst? Nein. Erkennung und Mustererkennung laufen lokal in Ihrem Container.

Fortführung des Geschäftsbetriebs und Lieferantenrisiko

Was passiert, wenn arcsoft den Betrieb einstellt? Sie behalten einen lauffähigen Container und eine dauerhafte Lizenz für die Version, die Sie besitzen; nichts deaktiviert sich, und kein Lizenzserver muss erreichbar sein. Sie erhielten jedoch keine weiteren Korrekturen, Releases oder Support. Eine Quellcode-Hinterlegung besteht nicht.

Welche Support-Zusage gibt es? Zu Geschäftszeiten (Schweizer Zeit), nach bestem Bemühen, per E-Mail. Es gibt keinen 24/7-Support und kein veröffentlichtes SLA und keine vertragliche Reaktionszeit.

Wie sieht der Wiederanlaufplan für unsere Daten aus? Den definieren Sie. Der Scanner hat weder eine eigene Backup-Funktion noch einen eigenen Wiederherstellungsweg; Ihre Datenbanksicherungen sind der Wiederherstellungsmechanismus. Beachten Sie, dass JIRA_CREDENTIAL_ENCRYPTION_KEY und FINDING_FINGERPRINT_HMAC_SECRET zusammen mit der Datenbank gesichert werden müssen - ohne den ersten lassen sich die gespeicherten Jira-Zugangsdaten nicht entschlüsseln, ohne den zweiten ändert jeder Fund seine Identität und verliert seine Prüfhistorie.

Ist das Produkt hochverfügbar? Es kann als mehrere Instanzen gegen eine PostgreSQL-Datenbank laufen, ohne geplante Scans oder Reports doppelt auszulösen, weil Planung und Arbeitsverteilung über die Datenbank beansprucht werden. Alles darüber hinaus - Lastverteilung, Failover, Datenbank-HA - ist Sache Ihrer Infrastruktur.

Compliance

Sind Sie DSGVO- beziehungsweise revDSG-konform? Konformität ist eine Eigenschaft Ihres Betriebs und nicht einer Software, die der Hersteller nicht einsehen kann. Sachlich feststellbar ist: arcsoft erhält keine der personenbezogenen Daten, die Ihr Scanner verarbeitet. Für diese Daten bleiben Sie allein verantwortlich, und arcsoft ist nicht Auftragsverarbeiter. arcsoft KLG hat ihren Sitz in Zürich, Schweiz. Die veröffentlichte Datenschutzerklärung trägt den Hinweis, dass sie noch nicht anwaltlich geprüft wurde; lesen Sie sie mit diesem Vorbehalt.

Hilft das Produkt, Compliance nachzuweisen? Es kann Belege beisteuern, mehr nicht. Es hält fest, was seine konfigurierten Regeln getroffen haben, wie eine prüfende Person jeden Fund eingestuft hat und wann - in einem Audit-Trail, der in Ihrer Datenbank bleibt.

Es stellt keine Compliance her und kann Ihnen nicht bestätigen, dass eine Instanz sauber ist. Ein Scan findet, was seine Regeln in den lesbaren Inhalten treffen. Ein leeres Ergebnis heisst also, dass nichts getroffen wurde - nicht, dass nichts vorhanden ist. Die Erkennung ist regelbasiert, Regeln können etwas übersehen, und manche Anhänge sind gar nicht lesbar - was übersprungen wird und warum, steht unter Anhänge scannen. Ob die entstandenen Belege eine bestimmte Pflicht erfüllen, ist eine Beurteilung, die Ihnen und Ihrer Prüfung obliegt.

Aufbewahrung und Löschung

Wie lange werden Daten aufbewahrt? Funde, Vorkommen, Prüfereignisse, Scan-Läufe, Scan-Arbeitspakete und abgelöste Regelversionen werden endgültig gelöscht, sobald sie älter als die konfigurierte Aufbewahrungsfrist sind. Diese wird mit retention.window als ISO-8601-Periode gesetzt und beträgt standardmässig zehn Jahre (P10Y). Eine Frist von null oder eine negative Frist wird beim Start abgewiesen. Siehe Datenaufbewahrung.

Werden Audit-Ereignisse gelöscht? Standardmässig nicht. retention.purge-audit-events steht auf false, sodass das Audit-Log die Funde überdauert, die es beschreibt. Setzen Sie es auf true, wenn Ihre eigene Richtlinie das Ablaufen von Audit-Einträgen verlangt; sie verwenden dann dieselbe Frist, denn eine eigene gibt es für sie nicht.

Ist die Löschung endgültig? Ja, kein Soft-Delete-Kennzeichen. Regeln, Scan-Konfigurationen, Unterdrückungen, die Jira-Verbindung, die Lizenz und die Reporting-Einstellungen unterliegen der Aufbewahrungsfrist nicht und bleiben, bis Sie sie entfernen.

Können wir unsere Daten auf Verlangen löschen? Ja. Administratoren können eine Bereinigung sofort über einen Admin-API-Endpunkt auslösen, statt auf den täglichen Lauf um 03:00 zu warten. Darüber hinaus gehört die Datenbank Ihnen, und Sie können sie verwerfen.

Wie bekommen wir unsere Daten heraus? Über den CSV-Export, der selbst auditiert wird, oder direkt aus Ihrer eigenen Datenbank.

Umgang mit Sicherheitsvorfällen

Gibt es einen dokumentierten Notfallplan mit festen Fristen? Nicht implementiert. Es gibt keinen veröffentlichten Incident-Response-Plan und keine vertragliche Meldefrist.

Wer benachrichtigt wen bei einer Verletzung des Datenschutzes? Für Daten, die Ihr Scanner verarbeitet, stellt sich die Frage herstellerseitig nicht: arcsoft hält keine davon und hätte nichts offenzulegen. Erkennung und Meldung für Ihre Installation liegen bei Ihnen, wie bei jeder Software, die Sie selbst betreiben. Bei einer im Produkt entdeckten Schwachstelle benachrichtigt arcsoft betroffene Kunden über die hinterlegte Kontaktadresse und veröffentlicht die Behebung als neues Release.

Rechtliche Vereinbarungen

Ist ein AVV beziehungsweise DPA verfügbar? Nicht veröffentlicht. Ein Auftragsverarbeitungsvertrag ist ein Rechtsdokument, das anwaltlich geprüft werden muss, und eine ungeprüfte Vorlage auszuliefern wäre schlechter, als keine auszuliefern - zumal hier die interessantere Frage ist, ob überhaupt einer erforderlich ist, da arcsoft keine der personenbezogenen Daten erhält, die Ihr Scanner verarbeitet. Sprechen Sie uns unter info@arcsoft.ch darauf an; es wird als Vertragsthema behandelt.

Welche Lizenz gilt für die Software? Ihr Lizenzvertrag mit arcsoft KLG, der mit Ihrer Lizenzdatei geliefert wird. Die Nutzungsbedingungen dieser Website gelten nur für die Website und tragen ihrerseits den Hinweis, dass sie nicht anwaltlich geprüft wurden.

Fehlt etwas?

Wenn Ihre Prüfung etwas fragt, das diese Seite nicht beantwortet, schreiben Sie an info@arcsoft.ch. Eine Antwort, die spontan erfunden werden muss, ist genau die, die sich später als falsch herausstellt - erwarten Sie also entweder eine belegte Antwort oder ein schlichtes "nicht implementiert".