Code-Audit

Statische Codeanalyse mit KI-gestützter Schwachstellenbewertung — ZIP-Upload, SFTP oder Git.

Kontingent & Credits

Jeder Code-Audit verbraucht einen Credit. Credits kommen aus:

• Monats-Abo — monatliches Kontingent je nach Plan
• Einmalkauf / Pakete — gekaufte Credits werden verbraucht wenn das Abo-Kontingent erschöpft ist
• Nachkauf-Credits — jederzeit zubuchbar unter Einstellungen → Abonnement

Wenn Ihr Kontingent erschöpft ist, gibt die API einen 402-Fehler zurück. Archiv-Uploads haben je nach Plan ein Größenlimit (413 bei Überschreitung).

Plan-Limits für KI-Analyse

Die KI-Analyse (SAST-Bewertung + Lösungsvorschläge) ist plan-abhängig begrenzt:

• Professional — max. 50 Dateien pro Scan für die KI-Analyse
• Agentur — max. 60 Dateien pro Scan
• Agentur Pro — max. 100 Dateien

Das Limit bezieht sich auf die Anzahl der an das KI-Modell gesendeten Quelldateien. Die statischen Analysen (SAST, Secrets, Dependencies, Malware) laufen immer über alle Dateien.

Methode 1 — ZIP-Upload

POST /api/code/analyze
Content-Type: multipart/form-data

file: project.zip
ai: true
system: wordpress

Methode 2 — Git-Repository

POST /api/code/connect
{
  "method": "git",
  "repoUrl": "https://github.com/org/repo",
  "branch": "main",
  "token": "ghp_...",
  "ai": true,
  "system": "laravel"
}

Unterstützt: GitHub, GitLab, Bitbucket (öffentlich und privat mit Token).

Methode 3 — SFTP / FTP

Option A: SSH-Key-Authentifizierung (empfohlen)

EMPEDIAcloud generiert einen systemweiten SSH-Key. Der Public Key wird im SFTP-Formular angezeigt und kann in die Datei ~/.ssh/authorized_keys auf dem Zielserver eingetragen werden — kein Passwort nötig.

1. SFTP als Methode auswählen — der Public Key wird automatisch angezeigt
2. Public Key kopieren und auf dem Zielserver in ~/.ssh/authorized_keys einfügen
3. Host und Benutzername eingeben, Passwort leer lassen
4. Verbindung testen und Analyse starten

Der Public Key kann auch über die API abgerufen werden:

GET /api/code/ssh-public-key
→ { "success": true, "publicKey": "ssh-ed25519 AAAA... auditcollector-code-audit" }

Option B: Passwort-Authentifizierung

POST /api/code/connect
{
  "method": "sftp",
  "host": "server.example.com",
  "port": 22,
  "username": "deploy",
  "password": "secret",
  "remotePath": "/var/www/html",
  "ai": true
}

Option C: Eigener Private Key (API)

Über die API kann auch ein eigener Private Key als String übergeben werden:

POST /api/code/connect
{
  "method": "sftp",
  "host": "server.example.com",
  "username": "deploy",
  "privateKey": "-----BEGIN OPENSSH PRIVATE KEY-----\n...",
  "remotePath": "/var/www/html",
  "ai": true
}

Wird weder password noch privateKey angegeben, nutzt EMPEDIAcloud automatisch den System-SSH-Key.

System-Parameter

Der optionale system-Parameter aktiviert framework-spezifische Prüfregeln:

• wordpress — $_GET/$_POST ohne Sanitierung, eval(), SQL-Injection, unsichere Hooks
• laravel — Mass Assignment, unvalidierte Redirects, Raw SQL
• shopware — Plugin-Sicherheit, Twig-Injection
• magento — Object Manager Misuse, Unsichere Konfiguration
• nextjs — Server-Side Props, API-Route-Validation, SSRF
• django — CSRF, SQL-Injection, Pickle-Deserialisierung
• symfony — Twig-Injection, unsichere Deserialisierung

Ohne system läuft eine allgemeine SAST-Analyse (OWASP Top 10).

Paket- und Lizenzprüfung

Zusätzlich zur Prüfung auf bekannte Schwachstellen vergleicht das Code-Audit die deklarierten Pakete aus package.json, composer.json und requirements.txt mit den öffentlichen Registries (npm, Packagist, PyPI). Das ist besonders bei KI-generiertem Code wichtig, denn KI-Assistenten erfinden gelegentlich Paketnamen.

Lokale Pakete (Workspaces, file:-Verweise, Git-URLs) werden nicht geprüft. Es werden nur Paketnamen an die Registries gesendet, nie Quellcode. Diese Befunde werden von der KI-Bereinigung bewusst nicht automatisch geändert, weil Herkunft, Lizenz und Ersatz eine Entscheidung des Menschen sind. Die Hinweise sind Indikatoren, keine Rechtsberatung.

Bekannte Schwachstellen, Geheimnisse und Datenfluss

Bekannte Schwachstellen in Abhängigkeiten: Aus den Lockfiles (package-lock.json, yarn.lock, composer.lock, requirements.txt mit ==, Gemfile.lock, go.mod) werden Paketname, Version und Ökosystem mit der Datenbank OSV.dev abgeglichen (npm, Composer/Packagist, PyPI, RubyGems, Go). Jeder Fund nennt die Kennung (GHSA/CVE) und die Version, ab der die Lücke behoben ist. Ohne Lockfile wird nur die Untergrenze der Versionsangabe geprüft; solche Funde sind höchstens „mittel“ und entsprechend gekennzeichnet. Entwicklungsabhängigkeiten werden eine Stufe niedriger eingestuft. Es werden nur Paketname, Version und Ökosystem übermittelt, nie Quellcode oder Dateinamen. Die Daten stammen aus Datenbanken mit eigener Lizenz (u. a. GitHub Advisory Database, PyPI Advisory Database, Go Vulnerability Database unter CC-BY 4.0).

Geheimnisse: Neben festen Formaten bekannter Anbieter (AWS, Google, GitHub, GitLab, Stripe, Slack, SendGrid, Telegram, Datenbank-URLs mit Passwort, private Schlüssel, WordPress-Salts u. a.) werden Zuweisungen mit auffälligem Namen (password, secret, token, api_key …) und zufällig wirkendem Wert gemeldet. Platzhalter, Umgebungsvariablen, Funktionsaufrufe und Übersetzungstexte zählen nicht; Treffer in Test- und Beispieldateien sind nur bei eindeutigen Schlüsselformaten „niedrig“. Im Bericht steht der Wert nur verkürzt.

Datenfluss-Analyse: Wo die Analyse-Engine (Opengrep) installiert ist, wird verfolgt, ob Eingaben aus der Anfrage ($_GET, req.query, request.args …) ohne Bereinigung in gefährliche Stellen gelangen: SQL, Systembefehle, Dateipfade, Datei-Einbindung, Ausgabe (XSS), Weiterleitungen, Serveranfragen, XML-Entity-Injection (XXE), Server-Side Template Injection sowie unsichere Token-/Signatur-Vergleiche (PHP) und Prototype Pollution sowie unsichere JWT-Prüfung (Node.js). Für WordPress gibt es zusätzlich Prüfungen auf ungeschützte REST-Routen und Änderungen ohne Nonce- oder Berechtigungsprüfung. Ein solcher Befund ist belastbarer als ein reiner Mustertreffer und ersetzt dessen Treffer an derselben Stelle. Die Analyse läuft lokal mit eigenen Regeln und Musterregeln von GitLab (MIT-Lizenz), ohne Telemetrie und ohne Internetzugriff; Kundencode verlässt den Server nicht. Die KI-Prüfung bewertet diese Funde danach im Code-Kontext (echt, abgeschwächt oder Fehlalarm) — bei Funden zur Zugriffskontrolle (IDOR) nur dann als bestätigt mit hoher Schwere, wenn die fehlende Prüfung in der Datei eindeutig belegt ist, da eine Rechteprüfung oft in einer nicht mitgelieferten Middleware liegt.

Ergebnis & Historie

Das Ergebnis enthält:

• Gefundene Schwachstellen mit Datei, Zeile und Schweregrad
• KI-generierte Erklärung und Lösungsvorschlag pro Finding
• Gesamtzusammenfassung nach Schweregrad (high / medium / low)
• WordPress-Analyse (Version, Plugins, Themes, Konfigurationsprobleme) wenn erkannt

Manche KI-Funde sind plausibel, aber nicht vollständig im Code nachweisbar — diese erscheinen mit der Markierung „Zu prüfen" statt mit einem festen Schweregrad und zählen nicht in der Gesamtzusammenfassung als bestätigt. Das verhindert, dass eine unsichere Einschätzung als Tatsache durchgeht, ohne den Hinweis ganz zu verlieren.

Alle Scans werden in der Code-Audit-Historie gespeichert. Über die API:

GET /api/code/scans          # Liste (paginiert)
GET /api/code/scans/:id      # Detail mit allen Findings

PDF-Report herunterladen

Zu jedem abgeschlossenen Code-Audit kann ein PDF-Report heruntergeladen werden — direkt im Dashboard (Schaltfläche "PDF" in der Detail-Ansicht) oder über die API:

GET /api/code/scans/:id/pdf          # Deutsch (Standard)
GET /api/code/scans/:id/pdf?lang=en  # Englisch

Der Report enthält Findings-Tabellen nach Schweregrad, Dateistatistiken, WordPress-Analyse und den KI-Ergebnisblock.

Wiederkehrende Code-Audits

Mit Geplanten Code-Audits können Sie Repositories und Server automatisch nach Zeitplan analysieren lassen — täglich, wöchentlich oder monatlich. Zugangsdaten werden verschlüsselt gespeichert.

→ Geplante Code-Audits einrichten

Vollständige KI-Analyse

Standardmäßig analysiert die KI die Top 30 relevantesten Dateien — ausgewählt nach einem Risiko-Wert (Nähe zu Benutzereingaben, Routen-Definitionen, Authentifizierungs-Code), nicht nach Dateigröße; zusammengehörige Dateien (die sich per require/include/import einbinden) werden im selben Durchlauf geprüft. Mit der Option „Vollständige KI-Analyse" werden alle Code-Dateien einzeln geprüft — mit erweiterter Ausgabe:

• Remediation-Steps (nummerierte Behebungsschritte pro Finding)
• Fix-Komplexität: easy / medium / hard
• Erfolgswahrscheinlichkeit in Prozent
• Kritisch-Markierung bei Malware / Backdoors

Kosten: Basispreis (1 Code-Audit-Credit) + tatsächliche Token-Kosten des gewählten Modells. Der Kostenvoranschlag kann vor dem Start über die API abgefragt werden:

POST /api/code/estimate-full-scan
{ "provider_id": "uuid", "file_count": 347, "avg_file_size": 3000 }
→ { "estimated_cost_cents": 12.5, "estimated_files": 347 }

KI-Analyse wiederholen

Wenn die KI-Analyse fehlschlägt (z.B. API-Fehler) oder Sie ein anderes Modell testen möchten, können Sie direkt auf der Detail-Seite die Analyse wiederholen. Token-Verbrauch wird pro Lauf einzeln getrackt.

POST /api/code/scans/:id/retry-ai
{ "provider_id": "uuid-des-gewuenschten-modells" }

GET /api/code/scans/:id/retry-ai-status
→ { "status": "done" }

KI-Bereinigung (Remediation)

Die KI-Bereinigung kann gefundene Sicherheitsprobleme automatisch beheben. Jeder Fix wird von einer zweiten KI adversarial gegengeprüft.

Drei Modi

Unterstützte Methoden

Sicherheitsmechanismen

• Backup: Bei SFTP/FTP wird ein vollständiges Backup erstellt bevor irgendein Fix angewendet wird. Schlägt das Backup fehl, wird die gesamte Bereinigung abgebrochen.
• Doppelte KI-Verifikation: Jeder Fix wird von einem zweiten KI-Prompt adversarial geprüft („Finde Probleme mit diesem Fix").
• Beide müssen zustimmen: Nur wenn Fix-Generator UND Verifier den Fix genehmigen, wird er angewendet.
• Rollback: Jederzeit über die Remediation-Seite — stellt alle Dateien aus dem Backup wieder her.
• Audit-Trail: Jede Dateiänderung wird mit SHA-256-Hashes (vorher/nachher) und Diff protokolliert.

API-Endpunkte

POST /api/code/scans/:id/start-remediation   # Job starten
GET  /api/code/remediation/:id                 # Status abfragen
GET  /api/code/remediation/:id/messages        # Agent-Nachrichten
POST /api/code/remediation/:id/respond         # Frage beantworten
GET  /api/code/remediation/:id/actions         # Fix-Aktionen
POST /api/code/remediation/:id/approve-fixes   # Review-Fixes anwenden
POST /api/code/remediation/:id/rollback        # Backup wiederherstellen
GET  /api/code/remediation/:id/download        # Archiv herunterladen

Backup & Download

Bei SFTP/FTP-Bereinigungen wird vor dem ersten Fix ein vollständiges Archiv aller Dateien erstellt. Dieses Backup ist auf der Remediation-Seite als Download verfügbar — unabhängig davon, ob Fixes angewendet wurden oder nicht.

Bei Upload-Jobs enthält der Download das gepatchte Archiv mit allen angewandten Fixes.

Archive und Backups enthalten Ihre Dateien einschließlich versteckter Konfigurationsdateien wie .env. Sie liegen deshalb verschlüsselt (AES-256) auf dem Server, werden beim Download automatisch entschlüsselt und nach 30 Tagen automatisch gelöscht. Laden Sie das Archiv rechtzeitig herunter; danach ist auch ein Rollback aus dem Backup nicht mehr möglich.

GET /api/code/remediation/:id/download
→ backup-abcd1234.tar.gz  (SFTP/FTP — Original-Backup)
→ remediated-abcd1234.tar.gz  (Upload — gepatchtes Archiv)

Git-Branch-Strategie

Bei Git-Bereinigungen legt EMPEDIAcloud einen dedizierten Branch mit einem deterministischen Namen an:

auditcollector/fix-{erste 8 Zeichen der Remediation-ID}

Der Branch-Name ist immer gleich für denselben Remediation-Job. Das ermöglicht idempotente Fortsetzung: Wenn der Branch bereits existiert (z.B. nach Server-Neustart), wird er ausgecheckt statt neu erstellt. Alle Fixes werden als Commits gepusht — der Branch kann anschließend reviewt und gemergt werden.

Fortsetzung nach Server-Neustart

Läuft ein Remediation-Job, wenn der Server neu startet, wird er als interrupted markiert. Beim nächsten Aufruf von „Bereinigung starten" auf der Scan-Seite erkennt das System den unterbrochenen Job und setzt ihn fort:

• SFTP/FTP: Das vorhandene Backup-Archiv wird lokal entpackt — kein erneuter SFTP-Download
• Git: Der bestehende Branch wird ausgecheckt und weitergenutzt
• Bereits verarbeitete Findings: Werden anhand der remediation_actions-Tabelle erkannt und übersprungen
• Zähler: Werden aus der Datenbank initialisiert, nicht von Null