Claude-Code-KI-Sicherheitsaudit-Tutorial: Security Audit Skill von der Installation über den Code-Scan bis zur Schwachstellenbehebung im vollständigen Praxiseinsatz

Sie erhalten von Claude Code eine Sicherheitswarnung, wissen aber nicht, ob sie einen echten Fehler beschreibt?
Gehen Sie in dieser Reihenfolge vor: Quelle und Skill-Datei prüfen, Berechtigungen begrenzen, einen klar umrissenen Codebereich scannen, jeden Fund manuell verifizieren, anschließend gezielt reparieren und erneut testen. Security Audit Skill liefert Hinweise, aber keinen eigenständigen Sicherheitsnachweis.

Diese Anleitung richtet sich an Entwickler, die Code mit Claude Code prüfen und den Ablauf vom Einrichten bis zur Nachkontrolle nachvollziehbar gestalten möchten.
Sicherheitsverantwortliche erhalten Kriterien zur Bewertung von Befunden und zur Begrenzung von Zugriffsrechten.
Technische Verantwortliche können damit einschätzen, ob ein KI-gestützter Scan in den Entwicklungsprozess passt.

Claude Code KI-Sicherheitsaudit: zuerst Grenzen und Ablauf festlegen

Behandeln Sie die Ergebnisse von Security Audit Skill als Hypothesen, die Sie am Code und mit reproduzierbaren Tests prüfen. Der Skill ist kein unabhängiger Auditor, und ein Scan kann weder beweisen, dass ein gemeldeter Fehler ausnutzbar ist, noch dass nicht gemeldete Schwachstellen ausgeschlossen sind.

Der Ablauf sollte vom geringsten Risiko zum überprüfbaren Ergebnis führen:

• Herkunft prüfen: Verwenden Sie die Installationshinweise des Skill-Repositories und vergleichen Sie sie mit dem Inhalt der tatsächlichen Skill-Datei. Die dort dokumentierte Arbeitsweise des Skills ist maßgeblich für die Einschätzung, welche Aufgaben er ausführt.
• Zugriff beschränken: Geben Sie nur den Projektbereich frei, der für die Prüfung nötig ist. Lassen Sie Änderungen, Befehle und Zugriffe auf sensible Ressourcen nicht stillschweigend zu.
• Umfang festlegen: Benennen Sie konkrete Dateien, Komponenten oder Datenflüsse und schließen Sie irrelevante Bereiche ausdrücklich aus.
• Befunde verifizieren: Prüfen Sie Codeposition, Auslöser und Auswirkungen. Ein hoher Schweregrad ersetzt diesen Nachweis nicht.
• Reparatur abnehmen: Testen Sie die Änderung, scannen Sie den betroffenen Bereich erneut und dokumentieren Sie verbleibende Unsicherheit.

Der Ansatz passt zu etablierten Verfahren für sichere Code-Reviews: Prüfer sollen nach konkreten Risiken suchen, den relevanten Kontext verstehen und Befunde nachvollziehbar belegen. Die OWASP-Anleitung für sichere Code-Reviews eignet sich als menschlicher Prüfmaßstab neben den Vorschlägen des Skills.

Wichtig: Ein Scan-Bericht ist eine Arbeitsliste, keine Sicherheitsfreigabe. Entscheiden Sie über Priorität und Behebung erst, wenn Sie den Fehlerpfad selbst nachvollziehen können.

Vor der Installation: Skill-Quelle und Verhalten prüfen

Security Audit Skill ist eine separat bereitgestellte Skill-Definition. Verwechseln Sie deren Anleitung nicht mit einer integrierten, automatisch garantierten Sicherheitsfunktion von Claude Code. Die Dokumentation zu Agent Skills beschreibt Skills als Anweisungen und zugehörige Inhalte, die ein Agent für bestimmte Aufgaben nutzen kann. Für Sie heißt das: Neben der Funktion zählt auch, was die installierte Datei tatsächlich vorgibt.

Prüfen Sie vor dem Einrichten:

• Quelle und Identität: Folgen Sie dem Link zum Repository nur über eine nachvollziehbare Projektseite. Kontrollieren Sie, ob der dort beschriebene Skill mit der Datei übereinstimmt, die Sie installieren wollen. Übernehmen Sie keine Installationsbefehle aus einer ungeprüften Kopie.
• Dateiinhalt: Lesen Sie SKILL.md und alle referenzierten Anweisungen. Achten Sie auf Anweisungen zum Ausführen von Shell-Befehlen, zum Ändern von Dateien, zum Lesen von Umgebungsvariablen und zum Zugriff auf Dateien außerhalb des Projekts.
• Änderungen am Projekt: Prüfen Sie, ob der Skill Änderungen selbst vorschlägt oder ausführt. Halten Sie das Arbeitsverzeichnis versioniert und beginnen Sie mit einer isolierten Testkopie, damit Sie Änderungen nachvollziehen und zurücksetzen können.
• Abhängigkeiten und Nebenwirkungen: Verifizieren Sie zusätzliche Downloads, Skripte oder Werkzeuge, bevor Sie sie starten. Führen Sie einen Befehl nicht allein deshalb aus, weil ihn eine Skill-Anweisung empfiehlt.
• Passung zur Installation: Vergleichen Sie die Anleitung des Skill-Projekts mit den offiziellen Installationshinweisen für Claude Code. Verwenden Sie nur dort beschriebene oder im Repository nachvollziehbar dokumentierte Schritte.

Die Skill-Datei des Projekts liegt laut Repository unter skills/security-audit/SKILL.md. Das ist ein überprüfbarer Hinweis auf den Inhalt des Projekts, aber keine allgemeine Aussage darüber, welcher Installationsweg in Ihrer Umgebung verfügbar ist. Übernehmen Sie deshalb keinen vermeintlich passenden Befehl aus einem anderen Setup. Folgen Sie den aktuellen Anweisungen des Repositorys und kontrollieren Sie danach, ob Claude Code den Skill tatsächlich im vorgesehenen Projektkontext erkennt.

Erster Test in einer kontrollierten Umgebung

Richten Sie den Skill zunächst in einem Wegwerf- oder Testprojekt ein, das keine produktiven Zugangsdaten enthält. Führen Sie dort eine klar begrenzte Aufgabe aus und prüfen Sie, welche Dateien Claude Code liest, welche Aktionen angefragt werden und ob Änderungen entstehen. Vergleichen Sie die Ausgabe mit der Skill-Datei. Wenn Verhalten, angeforderte Zugriffe oder Dokumentation nicht zusammenpassen, brechen Sie den Test ab und klären Sie die Ursache, bevor Sie den Skill in einem aktiven Repository verwenden.

Claude Code bietet Berechtigungssteuerung für Aktionen in der CLI. Lesen Sie vor dem Einsatz die offizielle Übersicht zu Nutzung und Berechtigungen; die konkrete Konfiguration hängt von Ihrer Umgebung und dem gewählten Arbeitsablauf ab. Erteilen Sie nicht pauschal Schreib- oder Ausführungsrechte, wenn eine lesende Prüfung genügt.

Den Scanbereich in Claude Code gezielt konfigurieren

Ein sinnvoller Scan beginnt nicht mit „Prüfe alles“, sondern mit einer präzisen Aufgabenbeschreibung. Beschreiben Sie, welcher Code geprüft werden soll, welche Eingaben nicht vertrauenswürdig sind und welche Sicherheitsannahmen für die Komponente gelten. Der Kontext hilft, relevante Datenflüsse zu untersuchen, statt allgemeine Hinweise über das ganze Repository zu verteilen.

Scan-Auftrag konkret formulieren

Ein Auftrag kann in natürlicher Sprache etwa so aufgebaut sein:

Prüfen Sie die Eingabevalidierung und Datenbankzugriffe im Verzeichnis src/api. Verfolgen Sie nicht vertrauenswürdige Eingaben bis zu SQL-Abfragen. Lesen Sie nur die relevanten Dateien und Tests. Ändern Sie keine Dateien und führen Sie keine Befehle ohne Rückfrage aus. Melden Sie zu jedem möglichen Problem die Codeposition, den erforderlichen Auslöser, den Datenfluss und die fehlende oder vorhandene Schutzmaßnahme. Kennzeichnen Sie unvollständige Belege ausdrücklich.

Passen Sie Verzeichnisnamen und Anforderungen an Ihr Projekt an. Geben Sie nur Kontexte an, die für die Prüfung notwendig sind. Bei einem Authentifizierungsmodul könnten das etwa die Vertrauensgrenze zwischen Anfrage und Anwendung oder die vorgesehene Zugriffskontrolle sein. Ein Scan ohne diesen Kontext kann eine legitime Schutzmaßnahme übersehen oder eine harmlose Nutzung als Risiko einstufen.

Legen Sie außerdem die Ausschlüsse fest. Beispiele sind generierte Dateien, gebündelte Abhängigkeiten oder unveränderte Drittanbieterkomponenten, sofern sie nicht selbst Prüfgegenstand sind. Ein Ausschluss ist keine Aussage, dass diese Bestandteile sicher sind: Halten Sie fest, was aus dem Scan herausfällt und warum. Andernfalls suggeriert ein Bericht eine größere Abdeckung, als tatsächlich geprüft wurde.

Datenschutz und Zugriffsgrenzen vor dem Lauf

Entfernen Sie unnötige Geheimnisse, Zugangsdaten, personenbezogene Daten und produktive Konfigurationswerte aus dem Arbeitsbereich. Ein API-Schlüssel gehört nicht in eine Aufgabenbeschreibung, wenn ein Platzhalter die Architektur ausreichend erklärt. Prüfen Sie ebenfalls, ob Testdaten vertrauliche Informationen enthalten. Bei Projekten mit Anforderungen nach der DSGVO sollten Sie Datenminimierung und interne Freigaberegeln vor dem Einsatz klären; ein KI-gestützter Scan hebt diese Pflichten nicht auf.

Treffen Sie die Berechtigungsentscheidung anhand der nötigen Arbeit:

• Wenn Sie zuerst nur Hinweise sammeln wollen, erlauben Sie eine lesende Prüfung und verlangen Sie eine Bestätigung für Änderungen oder Befehle.
• Wenn der Skill Änderungen vorschlägt, lassen Sie diese zunächst als Vorschlag ausgeben und prüfen Sie den Diff, bevor Sie ihn übernehmen.
• Wenn ein Befehl Zugriff auf externe Systeme, Geheimnisse oder produktive Dienste verlangen würde, stoppen Sie den Ablauf und ersetzen Sie ihn durch eine isolierte, kontrollierte Prüfung.
• Wenn der Scan auf einen breiten oder unklaren Bereich zugreift, grenzen Sie das Ziel neu ein, statt die Berechtigungen pauschal zu erweitern.

Scan-Ergebnisse anhand von Code und Auslöser bewerten

Lesen Sie einen Bericht nicht als Liste bestätigter Schwachstellen. Verlangen Sie für jede Fundstelle nachvollziehbare Belege: Welche Datei und Codeposition sind betroffen? Welche Eingabe oder welcher Zustand löst das Verhalten aus? Wie erreicht diese Eingabe die riskante Operation? Welche Auswirkung entsteht, und welche Schutzmaßnahme greift möglicherweise bereits?

Prüfen Sie die Kette vom Eingang bis zur Verwendung. Bei einem möglichen SQL-Injection-Problem ist die entscheidende Frage nicht, ob im Bericht „SQL Injection“ steht, sondern ob nicht vertrauenswürdige Eingaben ohne geeignete Bindung in eine Abfrage gelangen. Die Beschreibung von CWE-89 ordnet den Fehler als unsachgemäße Neutralisierung spezieller Elemente in einer SQL-Anweisung ein und erläutert geeignete Abhilfen. Nutzen Sie diese Definition zum Einordnen, nicht als Ersatz für den Nachweis im konkreten Programm.

Ein vereinfachtes Beispiel:

const query = "SELECT * FROM accounts WHERE name = '" + userInput + "'";

Hier ist zu prüfen, ob userInput tatsächlich vom Nutzer kontrolliert wird, ob es unverändert in die Abfrage gelangt und ob die verwendete Datenbankbibliothek weitere Schutzmechanismen einsetzt. Die konkrete Reparatur hängt von der Projektarchitektur ab. Bei einer Bibliothek mit Parameterbindung sollte die Eingabe als Parameter übergeben werden, statt SQL-Struktur durch Zeichenkettenverkettung aufzubauen. Prüfen Sie die Dokumentation der im Projekt verwendeten Bibliothek, bevor Sie die Änderung übernehmen.

Unterscheiden Sie die Ergebnisse sorgfältig:

• Bestätigter Befund: Der betroffene Code, der Auslöser und die relevante Wirkung sind nachvollziehbar. Ein Test, ein kontrollierter Reproduktionsschritt oder ein eindeutiger Codepfad stützt die Aussage.
• Wahrscheinlicher, aber unvollständiger Hinweis: Der Pfad ist plausibel, doch eine Annahme zu Eingabe, Berechtigungen oder Laufzeitverhalten ist noch nicht belegt. Erfassen Sie die offene Frage und prüfen Sie sie gezielt.
• Fehlalarm: Eine konkrete Schutzmaßnahme oder eine nicht erreichbare Eingabe widerlegt die angenommene Angriffskette. Dokumentieren Sie den Grund, statt den Fund kommentarlos zu verwerfen.
• Nicht bewertbar: Relevanter Kontext fehlt, beispielsweise die Implementierung einer externen Schnittstelle. Markieren Sie den Befund als ungeklärt und holen Sie den Kontext nach.

Der Schweregrad ist eine Priorisierungshilfe, kein Beweis. Prüfen Sie Reichweite, Voraussetzungen und Auswirkungen getrennt. Ein als kritisch markierter Fund kann auf einer falschen Annahme beruhen; ein weniger auffälliger Hinweis kann in einer sensiblen Komponente dennoch eine dringende Prüfung verlangen.

Entscheidung: lokal, isoliert oder remote prüfen?

Wählen Sie die Ausführungsumgebung anhand von Datenschutz, Projektzugriff und tatsächlich verfügbaren Funktionen. Eine lokale Umgebung kann passen, wenn Ihr Team den Quellcode dort kontrolliert und die nötigen Berechtigungen eng begrenzen kann. Eine isolierte Umgebung ist vorzuziehen, wenn Sie zunächst Skill-Verhalten oder Änderungen testen. Eine entfernte Entwicklungsumgebung kommt infrage, wenn Ihr Zugriffsmodell das verlangt und Sie Datenverarbeitung, Anmeldung und Ablage von Zugangsdaten geprüft haben. Keine dieser Optionen macht den Scan automatisch sicher oder vollständig.

• Wenn Sie sensible Quelltexte oder Geheimnisse nicht an eine externe Umgebung übermitteln dürfen, bleiben Sie innerhalb der freigegebenen Infrastruktur und klären Sie die geltenden Datenregeln, bevor Sie den Scan starten.
• Wenn Sie Skill-Inhalt oder Änderungsverhalten noch nicht kennen, verwenden Sie eine isolierte Projektkopie und begrenzen Sie die Rechte.
• Wenn mehrere Entwickler denselben reproduzierbaren Ablauf benötigen, dokumentieren Sie Installation, Berechtigungen, Scan-Auftrag und Abnahmekriterien im Teamprozess.
• Wenn keine passende Umgebung freigegeben ist, verzichten Sie auf den Scan, bis Datenschutz und Zugriffsweg geklärt sind.

Als zusätzlicher Maßstab eignet sich das NIST Secure Software Development Framework, SP 800-218. Es ordnet sichere Entwicklung in wiederholbare Praktiken ein. Für Ihren Ablauf bedeutet das: Ergebnisse und Entscheidungen in den Entwicklungsprozess einbetten, statt eine einzelne KI-Ausgabe als vollständige Sicherheitsprüfung zu behandeln. Auch der OWASP-Leitfaden zur statischen Analyse unterstützt die Einordnung: Automatisierte Analyse ist ein Prüfbaustein, dessen Resultate im Kontext interpretiert werden müssen.

Wenn Sie für ein Team eine entfernte Mac-Umgebung erwägen, prüfen Sie vorab, ob deren Zugriffsweg, Datenverarbeitung und verfügbare Funktionen zu Ihrem Projekt passen. Die Informationen von VPSSpark und eine konkrete Anfrage zur verfügbaren Umgebung können Sie dafür als Ausgangspunkt nutzen. Leiten Sie daraus keine nicht dokumentierten Konfigurationen oder Leistungszusagen ab. Für viele Teams ist die lokale, bereits freigegebene Entwicklungsumgebung die bessere Wahl; eine entfernte Umgebung löst weder die Frage der Quellcodefreigabe noch die Notwendigkeit menschlicher Prüfung.

Security Audit Skill: häufige Fragen aus der Praxis

Wie installieren Sie den Skill und prüfen die Herkunft?

Verwenden Sie die Installationsanleitung, die aktuell im verlinkten Repository bereitgestellt wird. Vergleichen Sie vor der Aktivierung die dort beschriebenen Schritte mit der tatsächlichen SKILL.md und den referenzierten Dateien. Prüfen Sie Maintainer und Änderungen und testen Sie das Verhalten in einem isolierten, versionierten Projekt. Wenn Sie keinen nachvollziehbaren Installationsweg verifizieren können, führen Sie keinen improvisierten Befehl aus.

Was muss vor dem Scan an Berechtigungen und Umfang feststehen?

Definieren Sie Zielverzeichnisse, Ausschlüsse, Sicherheitskontext und den gewünschten Lese- oder Schreibzugriff. Beginnen Sie mit einem engen Bereich und lassen Sie Aktionen mit Nebenwirkungen bestätigen. Entfernen Sie unnötige Zugangsdaten und personenbezogene Daten. Wenn eine Prüfung externe Dienste, Produktivsysteme oder weitergehende Rechte erfordert, stoppen Sie und klären zuerst, ob diese Zugriffe tatsächlich nötig und freigegeben sind.

Wie unterscheiden Sie einen echten Fehler von einem Fehlalarm?

Prüfen Sie den Codepfad, die Angreifereingabe, den Auslöser und die mögliche Wirkung. Suchen Sie nach vorhandenen Schutzmaßnahmen und belegen Sie Ihre Bewertung durch einen gezielten Test oder nachvollziehbare Codeanalyse. Ein Severity-Label allein reicht nicht. Kann eine Annahme noch nicht geprüft werden, dokumentieren Sie den Fund als unbestätigt oder nicht bewertbar, statt ihn als bestätigte Schwachstelle oder als Fehlalarm auszugeben.

Wie sieht die Abnahme nach einer Reparatur aus?

Vergleichen Sie die Änderung mit der belegten Ursache und prüfen Sie den Diff. Führen Sie passende Regressionstests aus und lassen Sie den geänderten Bereich erneut scannen. Halten Sie fest, welcher Test die Reparatur stützt, welche Annahmen offenbleiben und wer die Änderung freigegeben hat. Bleibt ein Risiko bestehen, dokumentieren Sie Verantwortlichkeit und nächsten Prüfschritt; ein erfolgreicher Folgescan ersetzt keine umfassendere Sicherheitsprüfung.

Vom Fund zur Reparatur und zur erneuten Prüfung

Ändern Sie den Code erst, nachdem Sie den Befund verstanden haben. Eine pauschale „Sicherheitskorrektur“ kann Geschäftslogik verändern oder an der Ursache vorbeigehen. Prüfen Sie daher die vorgeschlagene Lösung gegen die tatsächlichen Vertrauensgrenzen, die verwendeten Bibliotheken und die erwarteten Projektfunktionen.

Gehen Sie bei der Behebung so vor:

1. Befund eingrenzen: Notieren Sie betroffene Datei, Codeposition, Auslöser, Datenfluss und mögliche Auswirkung. Trennen Sie bestätigte Fakten von Vermutungen.
2. Abhilfe entwerfen: Wählen Sie eine Änderung, die die Ursache beseitigt, nicht nur die gemeldete Zeichenfolge. Bei SQL-Injection kann das etwa bedeuten, Daten und Abfragestruktur sauber zu trennen; die konkrete Umsetzung muss zur eingesetzten Bibliothek passen.
3. Änderung prüfen: Kontrollieren Sie den Diff und stellen Sie sicher, dass keine unnötigen Dateien, Konfigurationen oder Zugangsdaten verändert wurden.
4. Gezielt testen: Führen Sie Tests aus, die den zuvor beschriebenen Auslöser abdecken, und prüfen Sie zugleich, ob zulässige Eingaben weiterhin funktionieren.
5. Erneut scannen: Lassen Sie den betroffenen Bereich mit derselben klaren Abgrenzung prüfen. Vergleichen Sie den neuen Bericht mit der ursprünglichen Fundstelle, statt nur nach einer unveränderten Schweregradmarkierung zu suchen.
6. Entscheidung dokumentieren: Halten Sie Reparatur, Testergebnis, manuelle Freigabe und verbleibende Unsicherheit fest. Bei nicht behobenen Hinweisen dokumentieren Sie, warum sie offenbleiben und wer die weitere Prüfung übernimmt.

Die Schritte orientieren sich an einer wiederholbaren Sicherheitsentwicklung und nicht an der Annahme, ein einzelner Scan könne alle Fehler finden. NIST beschreibt mit SP 800-218 einen Rahmen für Praktiken über den Softwareentwicklungsprozess hinweg; die konkrete Umsetzung muss Ihr Team an Risiko und Projekt anpassen. Vermerken Sie deshalb auch den Scanbereich. Ohne diese Angabe kann später niemand erkennen, welche Dateien tatsächlich geprüft wurden.

Abnahme anhand einer überprüfbaren Checkliste

Arbeiten Sie die Punkte vor der Freigabe durch. Markieren Sie einen Punkt erst dann als erledigt, wenn Sie den zugehörigen Nachweis im Repository, im Testprotokoll oder in der Review-Dokumentation gefunden haben.

• [ ] Quelle geprüft: Repository, Skill-Datei und referenzierte Anweisungen stimmen nachvollziehbar überein.
• [ ] Berechtigungen begrenzt: Lesender Zugriff genügt oder weitergehende Aktionen wurden ausdrücklich geprüft und freigegeben.
• [ ] Scanumfang festgehalten: Geprüfte Dateien, Ausschlüsse und relevante Sicherheitsannahmen sind dokumentiert.
• [ ] Sensible Daten geschützt: Nicht benötigte Geheimnisse und personenbezogene Daten wurden aus dem Arbeitsbereich entfernt.
• [ ] Befund verifiziert: Codeposition, Auslöser, Datenfluss und mögliche Auswirkung sind belegt; die Schweregradmarkierung allein wurde nicht als Beweis verwendet.
• [ ] Reparatur überprüft: Der Diff beseitigt die bestätigte Ursache und führt keine unnötigen Änderungen ein.
• [ ] Tests bestanden: Ein gezielter Test deckt den Fehlerpfad ab; passende Regressionstests wurden ebenfalls ausgeführt.
• [ ] Erneuter Scan verglichen: Der geänderte Bereich wurde erneut geprüft und das Ergebnis mit dem ursprünglichen Befund abgeglichen.
• [ ] Offene Risiken dokumentiert: Nicht bestätigte Hinweise, nicht geprüfte Bereiche und weitere Verantwortlichkeiten sind festgehalten.

Fehlt ein Nachweis, ist der betreffende Punkt nicht abgenommen. Ein bestätigter, aber unbehandelter Befund bleibt ein offenes Risiko. Ein nicht reproduzierbarer Hinweis bleibt ungeklärt, bis Sie ihn mit zusätzlichem Kontext bewerten können. Ein erfolgreicher Folgescan belegt nur, was der Scan tatsächlich abgedeckt hat; er weist keine vollständige Sicherheit des Projekts nach.

Für Teams, die KI-gestützte Codeprüfung in einen belastbaren Ablauf integrieren wollen, ist der wichtigste Ertrag nicht die Zahl der gemeldeten Probleme. Entscheidend ist, ob Herkunft, Rechte, Scanbereich, Belege, Reparatur und Freigabe für andere Entwickler nachvollziehbar bleiben. Security Audit Skill kann Hinweise liefern; die Verantwortung für Validierung und Annahme liegt bei Ihrem Team.

Wenn Ihr bisheriger Ablauf manuelle Prüfungen ohne dokumentierte Rechte, uneinheitliche Scan-Aufträge und schwer nachvollziehbare Ergebnisse kombiniert, verbessern Sie zuerst diese Prozesslücken. Eine entfernte Umgebung ist nur dann sinnvoll, wenn sie zu den Datenschutzanforderungen, Ihrem Zugriffsmodell und dem tatsächlichen Entwicklungsbedarf passt. Prüfen Sie dafür die bei VPSSpark verfügbaren Umgebungsinformationen, bevor Sie Quellcode oder Zugangsdaten in einen neuen Arbeitskontext bringen. Langfristig intensive, dauerhaft verfügbare Arbeitslasten oder Anforderungen an lokale physische Schnittstellen sprechen eher für eine eigene passende Entwicklungsumgebung als für eine zeitweise gemietete Lösung.