Fehlerbehebung

Der Container startet nicht

Logmeldung	Ursache	Abhilfe
JIRA_CREDENTIAL_ENCRYPTION_KEY must be set to a base64-encoded 256-bit key	Die Variable fehlt oder ist leer.	Setzen Sie sie. Erzeugen mit openssl rand -base64 32.
JIRA_CREDENTIAL_ENCRYPTION_KEY must decode to a 256-bit key	Der Wert ist eine Passphrase, kein base64-kodierter 32-Byte-Schlüssel.	Erzeugen Sie einen echten Schlüssel; eine beliebige Zeichenfolge funktioniert nicht.
finding.fingerprint.hmac-secret must be configured	Das prod-Profil läuft ohne FINDING_FINGERPRINT_HMAC_SECRET.	Setzen und stabil halten - siehe Produktivbetrieb.
Ein Flyway-Validierungs- oder Migrationsfehler	Das Datenbankschema passt nicht zum Image, meist nach dem Start eines älteren Images gegen ein neueres Schema.	Spielen Sie das vor dem Upgrade erstellte Datenbank-Backup ein. Migrationen laufen nur vorwärts.

Nach einem Neustart ist alles verschwunden

Sie laufen mit dem Standardprofil auf einer In-Memory-H2-Datenbank. Setzen Sie SPRING_PROFILES_ACTIVE=prod und richten Sie den Scanner auf PostgreSQL aus. Siehe Produktivbetrieb.

Die Anmeldung schlägt fehl

• Endlose Rückleitung auf die Anmeldeseite - die Issuer-URI, an die der Browser geschickt wird, und die, gegen die das Backend prüft, müssen dieselbe URL sein. Ein containerinterner Hostname in OIDC_ISSUER_URI bricht das: die Browser der Benutzer erreichen ihn nicht.
• Angemeldet, aber jede Seite verweigert den Zugriff - der Rollen-Claim liegt nicht dort, wo das Backend sucht; das Token trägt damit keine Rolle, die das Backend kennt, und jede Anfrage kommt als HTTP 403 mit einem bereinigten Fehlerkörper zurück. Dekodieren Sie das Access Token und prüfen Sie, ob der Pfad in APP_SECURITY_ROLES_CLAIM (Standard realm_access.roles) die Rollen tatsächlich enthält.
• Angemeldet, aber die Seite meldet, das Konto habe keinen Zugriff - das Konto hat weder die Benutzer- noch die Admin-Rolle und wird deshalb überall abgewiesen. Vergeben Sie die Rolle aus APP_SECURITY_USER_ROLE (Standard USER) oder APP_SECURITY_ADMIN_ROLE (Standard ADMIN) und melden Sie sich erneut an.
• Angemeldet, aber fast nichts ist da - der Benutzer hat USER und nicht die Admin-Rolle; die Navigation zeigt dann nur die rein lesenden Seiten: Risiko-Dashboard, Funde und Unterdrückungen. Der Name der Admin-Rolle ist über APP_SECURITY_ADMIN_ROLE konfigurierbar (Standard ADMIN).

Der Jira-Verbindungstest schlägt fehl

Der Test zeigt einen bereinigten Fehler - Zugangsdaten erscheinen nie in Fehlermeldungen oder Logs - prüfen Sie deshalb in dieser Reihenfolge:

1. Erreichbarkeit - kann der Scanner-Container die Jira-Basis-URL erreichen? Testen Sie aus dem Container heraus, nicht von Ihrem Rechner. Proxys und Egress-Firewalls sind die häufigste Ursache.
2. TLS - eine Jira-Instanz mit einem Zertifikat aus eigener CA benötigt diese CA im Truststore der JVM im Container.
3. Zugangsdaten - Benutzername des Service-Accounts plus API-Token oder Passwort. Kann sich das Konto nur per SSO anmelden, stellen Sie stattdessen ein Token aus.
4. Berechtigungen - das Konto benötigt Projekte durchsuchen in jedem Projekt im Scope. Ein erfolgreicher Test bei gleichzeitig leeren Scans bedeutet meist, dass sich das Konto anmelden kann, aber keine Projekte sieht.

Ein Scan findet nichts oder viel weniger als erwartet

• Der Service-Account kann die Projekte im Scope nicht durchsuchen. Prüfen Sie die Projektliste in der Scope-Vorschau der Scan-Konfiguration.
• Die Feldauswahl schliesst genau die Felder aus, in denen die Inhalte stehen. Prüfen Sie eingeschlossene und ausgeschlossene Felder sowie die Einstellung für Kommentare.
• Viele Regeln sind bewusst inaktiv ausgeliefert. Siehe Eingebaute Regeln, welche und warum.

Ein geplanter Scan lief nicht

Öffnen Sie die Scan-Konfiguration und prüfen Sie das Zeitplan-Panel:

• Letzter geplanter Lauf zeigt eine Überspringung, weil noch ein Scan derselben Konfiguration lief. Geplante Läufe überlappen sich nie - der Takt wird übersprungen und als SCAN_SCHEDULE_SKIPPED im Audit-Log festgehalten.
• Letzter geplanter Lauf zeigt eine Überspringung, weil der Auslösezeitpunkt ausserhalb aller erlaubten Scan-Fenster lag. Der Takt wird übersprungen statt verschoben; ein Cron-Ausdruck, der nie mit einem Fenster zusammenfällt, läuft also nie. Vergleichen Sie beide - sie werden unabhängig voneinander konfiguriert.
• Cron-Ausdrücke haben sechs Felder (Sekunde Minute Stunde Tag-des-Monats Monat Wochentag) und werden in der Zeitzone des Servers ausgewertet.

Anhänge werden nicht gescannt

• Das Scannen von Anhängen ist aus, solange Anhangsinhalte scannen in der Scan-Konfiguration nicht aktiviert ist.
• Es erfordert zusätzlich das Lizenzmerkmal SCAN_ATTACHMENTS. Ohne dieses läuft der Scan über Felder und Kommentare normal durch und meldet: "Attachment scanning is not included in your license; attachments were not scanned."
• Einzelne Anhänge werden aus dokumentierten Gründen übersprungen - nicht unterstütztes Format, verschlüsselt, zu gross, Parse-Timeout. Siehe Anhänge scannen.

Report-E-Mails kommen nicht an

• Nutzen Sie zuerst Test-E-Mail senden unter Administration -> Reporting; das trennt SMTP-Probleme von der Reporting-Logik.
• Empfänger werden aus den Jira-Projektverantwortlichen ermittelt. Ein Projekt, dessen Verantwortlicher keine E-Mail-Adresse in Jira hat, wird im letzten Lauf unter Projekte ohne E-Mail-Adresse gezählt.
• Empfänger ohne offene Funde werden bewusst übersprungen - der Lauf zählt sie als übersprungen, statt einen leeren Report zu senden.
• Die Links in der E-Mail verweisen auf APP_BASE_URL. Erhalten Empfänger localhost-Links, ist diese Variable nicht gesetzt.

Neue Scans melden alte Funde als neu

FINDING_FINGERPRINT_HMAC_SECRET hat sich geändert. Die Identität eines Fundes wird daraus abgeleitet, sodass frühere Prüfentscheidungen und Unterdrückungen nicht mehr passen. Stellen Sie das ursprüngliche Secret wieder her, falls Sie es noch haben.