Claude Code für Security-Tooling: eigene Tools mit Odin v1 bauen

Die meisten Security-Teams schleppen einen Haufen kleiner Skripte mit sich herum: einen Parser für ein exotisches Logformat, einen Konverter zwischen den Ausgaben zweier Scanner, ein Harness, das Regeln gegen Testdateien laufen lässt. Genau solche Tools schreibt Claude Code gut, und mit InterOdin läuft es auf Odin v1, das legitime Security-Arbeit nicht verweigert. Dieser Beitrag zeigt das Setup, wie du es sicher betreibst, und drei Tools, die sich lohnen: einen Log-Parser, einen Normalizer für Recon-Daten aus einem autorisierten Auftrag und ein YARA-Testharness.

Warum ein eigener Befehl claudeodin

Das Setup-Skript von InterOdin verändert dein normales Claude Code nicht. Es fügt einen zweiten Befehl hinzu, claudeodin, der dasselbe Claude Code auf Odin-Modellen startet, mit einem eigenen Einstellungsordner, ~/.claude-odin.

Diese Trennung zahlt sich in der Praxis aus:

• Dein normaler claude-Befehl behält dein Claude-Konto, deine Einstellungen, Sessions und deinen Verlauf. Nichts wird überschrieben.
• claudeodin hat einen eigenen Verlauf, sodass Security-Sessions mit Sample-Daten und Projektnotizen nicht zwischen deinen Alltags-Sessions landen.
• Du kannst pro Aufgabe wechseln. Nimm claude für allgemeine Arbeit und claudeodin, wenn es um Malware-Triage, Detection-Content oder Tooling für einen Test geht.

Setup

Du brauchst Node.js 18 oder neuer, ein bereits installiertes Claude Code und einen InterOdin-API-Key (er beginnt mit io-sk-) aus der Konsole.

curl -fsSL https://docs.interodin.com/claude-code-setup.mjs -o claude-code-setup.mjsnode claude-code-setup.mjsclaudeodin

Das Skript fragt deinen Key mit verdeckter Eingabe ab und schreibt die Einstellungen nach ~/.claude-odin. Es ist kurz und hat keine Abhängigkeiten, also lies es, bevor du es ausführst. Innerhalb einer Session zeigt /status, welche Base-URL aktiv ist.

Um später alles rückgängig zu machen:

node claude-code-setup.mjs delete

Damit werden der Launcher und die vom Skript angelegten Einstellungen entfernt. Die vollständige Anleitung, inklusive manuellem Setup, findest du unter Claude Code auf InterOdin.

Das Modell mit /model wählen

In claudeodin listet das Menü /model Odin v1 und Odin Flash.

• Odin v1 (odin-v1): das leistungsfähigste Modell, mit einem Kontextfenster von 1.000.000 Tokens und standardmäßig aktiviertem Thinking. Nimm es, um ein Tool zu entwerfen, eine große Codebasis zu lesen oder einen Parser gegen ein unordentliches Format aus der Praxis zu debuggen.
• Odin Flash (odin-flash): schneller und günstiger, mit 262.144 Tokens Kontext. Gut für kleine Änderungen, Umbenennungen, das Schreiben von Tests und repetitive Anpassungen.

Ein bewährter Rhythmus: Plane und baue die erste Version mit Odin v1 und wechsle für die Aufräumarbeiten auf Odin Flash.

Eine Einschränkung solltest du kennen: Die Modelle verarbeiten nur Text. Wenn du einen Screenshot eines Log-Viewers einfügst, schlägt das fehl. Füge stattdessen die Logzeilen ein.

Gib dem Key ein monatliches Ausgabenlimit

Eine Agent-Session ist nicht ein einzelner Request. Jeder Tool-Aufruf, jedes Lesen einer Datei und jeder erneute Versuch ist ein eigener API-Aufruf, und eine lange Session summiert sich. Lege einen separaten API-Key nur für Claude Code an und setze in der Konsole ein monatliches Ausgabenlimit darauf. Hängt eine Session über Nacht in einer Schleife an einem fehlschlagenden Test, begrenzt das Limit den Schaden. Abgerechnet wird über Prepaid-Guthaben in EUR oder USD, ohne Abo; die aktuellen Tarife findest du unter Preise.

In einem Container oder einer VM ausführen, wenn es Befehle ausführt

Claude Code kann Shell-Befehle ausführen und Dateien bearbeiten. Standardmäßig fragt es vor jeder Aktion nach. Viele schalten diese Rückfragen ab, sobald sie einem Workflow vertrauen, und genau dann wird Isolation wichtig.

Odin v1 antwortet direkt, auf Seiten des Modells gibt es also weniger Bremsen. Baue die Bremse deshalb in die Umgebung ein:

• Führe claudeodin in einem Wegwerf-Container oder einer VM aus, in die nur der Projektordner gemountet ist.
• Halte Zugangsdaten, SSH-Keys und Kundendaten, die das Tool nicht braucht, aus dieser Umgebung heraus.
• Lass es niemals Malware-Samples ausführen. Jede Arbeit mit Samples gehört in eine dedizierte, isolierte Analyse-VM, und das Harness darf Dateien nur lesen, nie ausführen.
• Stelle bei Recon-Tooling sicher, dass die Umgebung keine echten Ziele erreichen kann, sofern sie nicht in deinem schriftlich vereinbarten Scope liegen.

Ein minimaler Container für ein Tooling-Projekt sieht so aus:

docker run --rm -it \  -v "$PWD":/work -w /work \  -e INTERODIN_API_KEY \  python:3.12 bash

Installiere darin Node.js und Claude Code, führe dort das Setup-Skript aus, und die Session kann nur noch auf /work zugreifen.

Tool 1: ein Log-Parser

Fang mit etwas Risikoarmem an. Angenommen, dein Proxy schreibt ein eigenes Format, das dein SIEM nicht parst. Gib Claude Code eine Stichprobe echter (geschwärzter) Zeilen und ein klares Ziel:

Write parse_proxy.py. Input: lines like the ones in samples/proxy.log.Output: one JSON object per line with timestamp (ISO 8601 UTC), src_ip,user, method, url, status, bytes, user_agent. Lines that do not match goto stderr with the line number. Add pytest tests using the sample lines,including the two malformed ones at the end.

Was du erwarten kannst: einen Parser rund um einen kompilierten regulären Ausdruck oder einen kleinen Tokenizer, eine Zeitstempel-Konvertierung mit explizit behandelter Zeitzone, Tests für die normalen und die fehlerhaften Zeilen und einen Hinweis auf jedes Feld, bei dem es raten musste, etwa ob ein - in der User-Spalte einen leeren Wert bedeutet. Führe die Tests selbst aus, bevor du der Ausgabe vertraust.

Tool 2: ein Recon-Daten-Normalizer für einen autorisierten Auftrag

Bei einem Test kommen Daten aus mehreren Tools in mehreren Formaten an. Ein Normalizer führt sie zu einem einzigen Inventar zusammen. Die wichtigste Designregel: Der Scope wird im Code durchgesetzt, nicht aus dem Gedächtnis.

Lege den Scope aus deinen Rules of Engagement in einer Datei ab, zum Beispiel:

# scope.txt, from the signed rules of engagement192.0.2.0/24198.51.100.0/25

Dann frag:

Build normalize.py for an authorized external test. Inputs: nmap XMLfiles in raw/nmap/ and a CSV export from our web scanner in raw/web/.Output: inventory.json with one entry per host: ip, hostnames, open portswith service and version, and web findings. Load scope.txt and drop anyhost outside it, logging each dropped host to out_of_scope.log. The toolonly reads files; it must not send any network traffic.

Rechne mit einem Parser pro Eingabeformat, einem Merge-Schritt mit der IP-Adresse als Schlüssel, einer Scope-Filterung mit Pythons Modul ipaddress und Tests, die einen Host außerhalb des Bereichs enthalten, um zu beweisen, dass er verworfen wird. Das Out-of-Scope-Log ist später ein nützlicher Nachweis: Es zeigt, dass Daten, deren Test nicht autorisiert war, nie in den Bericht gelangt sind.

Sobald das Inventar steht, kann das Tool die API direkt aufrufen, um Projektnotizen zu entwerfen. Für diese Art von Zusammenfassung passt Odin Flash gut:

from openai import OpenAIimport jsonimport os
client = OpenAI(    base_url="https://api.interodin.com/v1",    api_key=os.environ["INTERODIN_API_KEY"],)
inventory = json.load(open("inventory.json", encoding="utf-8"))
resp = client.chat.completions.create(    model="odin-flash",    messages=[        {            "role": "system",            "content": "You help a penetration tester on an authorized engagement. "                       "Summarize the attack surface by host. Do not suggest "                       "testing anything outside the provided inventory.",        },        {"role": "user", "content": json.dumps(inventory, indent=2)},    ],)print(resp.choices[0].message.content)

Prompts und Antworten der API werden nie gespeichert, nur Abrechnungsmetadaten. Schwärze trotzdem Kundennamen, die du nicht brauchst. Wie du aus diesen Notizen ein Deliverable machst, steht in Pentest-Berichte mit KI schreiben.

Tool 3: ein YARA-Testharness

Regeln sind nur so gut wie ihre Tests. Ein Harness lässt ein Regelset gegen zwei Ordner laufen, bekannte Samples und bekannt harmlose Dateien, und meldet verpasste Treffer und False Positives.

Write yara_harness.py using yara-python. Compile every .yar file inrules/. Scan positives/ (each file should match) and benign/ (nothingshould match). Never execute any file, only read it. Print a table ofrule, true positives, misses and false positives, and exit non-zero ifany rule has a false positive so CI can catch it.

Der Kern dessen, was du zurückbekommst, sieht etwa so aus:

import pathlibimport yara
rules = yara.compile(filepaths={p.stem: str(p) for p in pathlib.Path("rules").glob("*.yar")})
def scan(folder):    results = {}    for path in pathlib.Path(folder).rglob("*"):        if path.is_file():            results[str(path)] = [m.rule for m in rules.match(str(path))]    return results

Halte den Ordner mit den Positives in deiner isolierten Analyse-VM und befülle den Benign-Ordner mit einer breiten Auswahl sauberer Dateien: Installer, Skripte und Dokumente aus deiner eigenen Umgebung. Wie du die Regeln selbst schreibst, zeigt Sigma- und YARA-Regeln mit KI. Für die Triage, aus der die Strings überhaupt erst stammen, lies Malware-Analyse mit Odin.

Prüfe, was es baut

Ein von einem Agent geschriebenes Tool ist trotzdem dein Tool, und in der Security-Arbeit kann ein stiller Bug eine verpasste Detection oder einen Host außerhalb des Scopes in deinem Bericht bedeuten. Bevor du dich auf eines dieser Tools verlässt:

• Lies den Diff. Achte auf hartkodierte Pfade, verschluckte Exceptions und alles, was das Netzwerk anfasst, obwohl es das nicht sollte.
• Führe die Tests selbst aus und ergänze einen Fall, an den der Agent nicht gedacht hat, etwa eine leere Datei oder eine Zeile in unerwartetem Encoding.
• Füttere es mit bekanntem Input, dessen Ergebnis du kennst. Ein Parser sollte deine Beispielzeilen verlustfrei abbilden, der Normalizer sollte deinen Test-Host außerhalb des Scopes verwerfen und das Harness sollte einen absichtlich eingebauten False Positive melden.
• Lege die verwendeten Prompts im Repository neben den Code, damit die nächste Person sieht, was das Tool tun sollte.

Loslegen

Erstelle in der Konsole einen API-Key mit monatlichem Ausgabenlimit, führe das Setup-Skript aus und folge der Claude-Code-Anleitung. Für die direkte Nutzung der API beginnst du mit dem Quickstart. Halte jedes Tool und jedes Ziel innerhalb deines autorisierten Scopes und der Acceptable Use Policy.