Cloudflare Security-Audit-Skill für Codex – OpenClaw offen

Cloudflares Security-Audit-Skill gibt Coding-Agenten einen strukturierten Ablauf für die Sicherheitsprüfung von Quellcode. Für Codex dokumentiert das Projekt einen Installationsweg über die Skills-CLI. Bei OpenClaw ist dagegen sorgfältig zu trennen: Ein agentenneutraler Skill ist noch keine verifizierte Integration. Entscheidend sind die verfügbaren Werkzeuge und die Sicherheitsgrenzen der konkreten Laufzeitumgebung.

• Nutzen: Ein nachvollziehbarer Prüfprozess mit getrennten Rollen, dokumentierter Abdeckung und überprüften Befunden.
• Codex: Die Installation ist dokumentiert; ein eigener Installationstest liegt diesem Artikel nicht zugrunde.
• OpenClaw: Die grundsätzliche Übertragbarkeit muss an der jeweiligen Umgebung geprüft werden. Direkte Installation und ausreichende Sandbox sind hier nicht verifiziert.
• Grenze: Kein Ersatz für einen Live-Penetrationstest und keine Freigabe, produktive Dienste zu untersuchen.

Was leistet das Cloudflare Security-Audit-Skill?

Das Skill ist ein Regelwerk für einen Coding-Agenten. Es beschreibt, wie dieser ein Repository untersucht, mögliche Schwachstellen eingrenzt und die Ergebnisse verifiziert. Es ist damit nicht einfach eine Aufforderung, möglichst viele verdächtige Codezeilen aufzuzählen.

Der dokumentierte vollständige Audit umfasst sechs Phasen: Bestandsaufnahme, gezielte Suche nach Angriffsmöglichkeiten, Validierung von Kandidaten, strukturierte Ausgabe, unabhängige Verifikation der Einträge und ein sachlicher Abschlussbericht. Der Guidance-Modus folgt diesem Ablauf nicht. Isolierte Agenten übernehmen unterschiedliche Aufgaben. Eine dokumentierte Prüfabdeckung soll nachvollziehbar machen, welche Bereiche untersucht wurden.

Im Mittelpunkt stehen Vertrauensgrenzen: Wo gelangen nicht vertrauenswürdige Eingaben in einen Bereich, der mehr Rechte oder andere Annahmen hat? Die Prüfkategorien reichen von Web-Protokollen und Authentifizierung über clientseitigen Code und Software-Lieferketten bis zu Cloud-Konfigurationen, Datentrennung und Ressourcenerschöpfung. Auch lokale Schnittstellen von Desktop- und Mobilsoftware gehören zum beschriebenen Spektrum. Das bedeutet nicht, dass jedes Repository in jeder Kategorie einen Befund liefern muss.

Codex: Cloudflare dokumentiert Installation über Skills-CLI

Die Projektdokumentation von Cloudflare nennt die Skills-CLI als Installationsweg. Voraussetzung ist eine funktionierende Node.js-Umgebung. Für den vollständigen Prüfablauf braucht es außerdem einen Coding-Agenten mit einem Modell, das Werkzeugaufrufe und parallele Subagenten unterstützt. Node.js wird auch für die mitgelieferten Validatoren der Befunde und der Prüfabdeckung benötigt.

Der dokumentierte Installationsbefehl

Der folgende Befehl stammt aus der README. Er ist für die Installation über die Skills-CLI vorgesehen; er startet noch keinen Audit. Anschließend ist direkt zu prüfen, ob die konkrete Codex-Umgebung das Skill erkennt.

npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit

Für eine nutzerweite Installation dokumentiert das Projekt zusätzlich die Option --global:

npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit --global

Der Befehl belegt den vorgesehenen Installationsweg, nicht die erfolgreiche Einrichtung auf einem bestimmten Rechner. Vor einem Audit ist deshalb zu prüfen, ob das Skill in der verwendeten Codex-Umgebung tatsächlich verfügbar ist und ob die benötigten Werkzeuge nutzbar sind. Dieser Artikel beschreibt die dokumentierte Vorgehensweise, keinen selbst durchgeführten Installationstest.

Eine passende Prüfung beauftragen

Die README nennt beispielsweise security audit this codebase als Auslöser. Für einen sinnvollen Auftrag sollten Zielverzeichnis, erlaubter Umfang und gewünschte Ausgabe zusätzlich klar sein. Ein vollständiger Audit ist etwas anderes als eine Frage zu einer einzelnen Sicherheitsentscheidung.

Als formuliertes Auftragsbeispiel, nicht als zusätzlicher CLI-Befehl:

Führe mit dem security-audit-Skill einen vollständigen Audit dieses
lokalen Repositorys durch. Untersuche nur den freigegebenen Quellcode
und die enthaltenen Konfigurationen. Keine Live-Endpunkte prüfen.
Ziel-Code nur ausführen, wenn die vorgeschriebene Sandbox nachweislich
vorhanden ist. Fehlende Voraussetzungen als needs_validation ausweisen.

Ein solcher Auftrag ersetzt keine technische Abschottung. Er hält lediglich den gewünschten Umfang fest. Ob sich die erforderlichen Schutzmaßnahmen tatsächlich durchsetzen lassen, muss die Umgebung gewährleisten.

Beratung oder vollständiger Audit?

Das Skill unterscheidet einen Beratungsmodus, den Guidance-Modus, und den vollständigen Audit. Im Guidance-Modus entstehen weder ein Ausgabeverzeichnis noch Audit-Artefakte. Das passt zu eingegrenzten Sicherheitsfragen, ohne gleich einen kompletten Prüfprozess anzustoßen.

Im Full-Audit-Modus werden die Ergebnisse standardmäßig außerhalb des Ziel-Repositorys abgelegt:

~/security-audit-skill/<repo-name>/run-<N>

Ein anderes Ausgabeverzeichnis muss ausdrücklich gewählt und von der Versionskontrolle ignoriert sein. Der Speicherort gehört deshalb zur Vorbereitung: Er muss beschreibbar sein und zu den Zugriffsregeln für die untersuchten Projekte passen.

Ist das Skill in OpenClaw einsetzbar?

Eine verifizierte direkte OpenClaw-Integration lässt sich aus der vorliegenden Quellenbasis nicht ableiten. Das Skill verwendet agentenneutrale Rollen wie übergeordneter Agent, Recherche-Agent und allgemeiner Agent. Das erleichtert eine Übertragung grundsätzlich. Es beweist aber weder, dass OpenClaw das Paket direkt installieren kann, noch dass dessen Laufzeit alle Voraussetzungen erfüllt.

Hinzu kommt eine wichtige Unterscheidung: Codex aus OpenClaw heraus anzusprechen ist nicht dasselbe, wie das Skill nativ in OpenClaw auszuführen. Eine historische beziehungsweise optionale OpenClaw-Codex-Plugin-Referenz beschreibt Aufträge mit dem Präfix Mit Codex:. Das beschreibt einen möglichen Weg über das dort genannte Plugin, nicht einen allgemein gültigen Aktivierungsbefehl für jede aktuelle OpenClaw-Installation.

Für einen konkreten Einsatz bleiben damit drei Prüfaufgaben:

• Skill-Verfügbarkeit: Wie wird das Paket in genau dieser Umgebung geladen, und ist es für den ausführenden Agenten sichtbar?
• Werkzeuge und Rollen: Unterstützt der gewählte Ausführungsweg Werkzeugaufrufe, parallele Subagenten und die benötigten Validatoren?
• Ausführungsschutz: Sind die geforderten Sandbox-Kontrollen technisch vorhanden und wirksam?

Die offizielle OpenClaw-Dokumentation zu Skills beschreibt Skills als Verzeichnisse mit einer SKILL.md-Datei und definiert Such- und Ladeorte, etwa <workspace>/skills. Für Git- und lokale Installationen erwartet sie eine SKILL.md im Quellwurzelverzeichnis. Cloudflares README verlinkt die Skill-Datei dagegen unter skills/security-audit/SKILL.md. Daraus folgt kein Nachweis, dass sich das Repository unverändert über einen generischen Git-Root-Installationsweg installieren lässt. Möglicherweise muss das Skill zusätzlich passend bereitgestellt oder kopiert werden; einen Unterordner- oder Direktinstallationsweg hat dieser Artikel nicht verifiziert. Deshalb steht hier kein OpenClaw-Installationsbefehl. Die dokumentierte Skills-CLI-Installation für Codex ist kein Nachweis für eine native OpenClaw-Installation.

Die Sandbox ist eine Voraussetzung, kein Detail

Quellcode zu lesen und Code aus dem Zielprojekt auszuführen sind zwei verschiedene Eingriffe. Für Builds, Tests und andere Ausführung von Ziel-Code verlangt das Skill eine vom Betriebssystem erzwungene Sandbox. Zu den geforderten Kontrollen gehören kein externer Netzwerkzugriff, eine ausdrücklich freigegebene Umgebung, begrenzte Ressourcen und Schreibzugriffe nur im zugewiesenen Arbeitsbereich.

Eine Anweisung im Prompt ist dafür kein Ersatz. Ebenso wenig genügt die bloße Bezeichnung einer Umgebung als isoliert. Ob die konkrete OpenClaw-Laufzeit diese Anforderungen erfüllt, ist in der vorliegenden Recherche ausdrücklich offen.

Lassen sich die Kontrollen nicht durchsetzen, darf fehlende Ausführungssicherheit nicht durch einen Versuch auf dem Host übergangen werden. Der betroffene Befund bleibt needs_validation; die fehlende Sandbox-Fähigkeit ist als Validierungsblocker zu benennen. Quellenbasierte Analyse und ein Plan für die noch nötige Validierung sind nicht dasselbe wie ein ausgeführter Nachweis.

Die Sandbox erlaubt außerdem keine Live-Prüfungen. Das Skill untersagt das Prüfen ausgerollter Endpunkte, externer Dienste, gemeinsam genutzter Infrastruktur und produktiver Identitäten. Lokale Validierung unter den vorgeschriebenen Kontrollen bleibt von einem Penetrationstest gegen laufende Systeme getrennt.

So sind die Ergebnisse einzuordnen

Nicht jeder Verdacht ist eine Schwachstelle. Das Skill trennt bestätigte Grenzverletzungen von offenen Kandidaten und verworfenen Annahmen. Diese Unterscheidung ist für die weitere Arbeit wichtiger als die bloße Anzahl der Meldungen.

• confirmed: Eine Verletzung der untersuchten Vertrauensgrenze ist nach den Prüfkriterien bestätigt.
• needs_validation: Für eine Bestätigung fehlen Voraussetzungen oder konkrete Informationen. Der fehlende Nachweis muss benannt werden.
• rejected: Der Kandidat wurde im Prüfprozess verworfen.

Gerade Deployment-Fragen setzen der Analyse Grenzen. Liegen Proxy-Verhalten, Provider-Einstellungen oder andere entscheidende Betriebskontrollen nicht im Repository vor, darf der Agent sie nicht hinzuerfinden. Ein offener Befund mit einer präzisen Liste fehlender Fakten ist dann nützlicher als eine scheinbar eindeutige Sicherheitsbewertung.

Auch ein Bericht ohne bestätigte Befunde ist keine Sicherheitsgarantie für das gesamte System. Die Aussagekraft hängt vom sichtbaren Material, dem tatsächlich untersuchten Umfang und den möglichen Validierungsschritten ab.

Codex: Installationsweg dokumentiert, OpenClaw noch zu prüfen

Das Cloudflare Security-Audit-Skill bietet einen strukturierten Weg von der Codeprüfung zum nachvollziehbaren Befund. Für Codex ist die Installation über die Skills-CLI dokumentiert. Der sinnvolle erste Schritt ist ein klar begrenzter Auftrag an einem freigegebenen Repository, nicht eine Prüfung produktiver Endpunkte.

Für OpenClaw lautet die Antwort dagegen nicht einfach „installieren und starten“. Zuerst müssen der konkrete Ladeweg, die benötigten Agentenfunktionen und die Sandbox belegt sein. Bis dahin bleibt die Integration eine zu prüfende Möglichkeit. Wer diese Grenze beachtet und offene Befunde nicht als bestätigte Schwachstellen verkauft, kann den dokumentierten Prüfprozess sachgerecht nutzen.