Suchergebnisse für: „Sicherheit“

Zuerst wird ein Ledger angelegt: jede untersuchbare Einheit der Codebasis bekommt eine Kennung und einen Prüfstatus. Erst danach beginnt die Suche. Isolierte Agenten arbeiten die Einheiten ab, eine zweite Gruppe sucht Lücken im Prüfplan, und jeder vorläufige Befund geht an einen Prüfer, dessen Auftrag das Widerlegen ist.

Cloudflare hat diesen Ablauf als offenes Skill für Coding-Agenten auf GitHub veröffentlicht. security-audit-skill ist eine Sammlung von Anweisungen, Schemata und Prüfskripten, die einen Agenten durch sechs Phasen führt: Aufnahme, Abdeckung, Kandidatenprüfung, strukturierte Ausgabe, unabhängige Nachprüfung und Bericht. Nach Angaben des Projekts ist es das Skill, aus dem Cloudflares Vulnerability-Discovery-Harness hervorgegangen ist. Der Harness wurde daraus zu einem mehrstufigen, flottenweiten System ausgebaut; dieses Repository ist der Ausgangspunkt für ein einzelnes Projekt.

Das Vorgehen erinnert an die Trennung von Bauausführung und Prüfstatik. Wer die Wand gemauert hat, nimmt sie nicht selbst ab. Diese Trennung ist hier nicht als Empfehlung formuliert, sondern in den Ablauf eingebaut. Das unterscheidet den Ablauf von einem Scanner, den man einmal über ein Repository laufen lässt.

Einen Agenten nach einem Sicherheitsaudit zu fragen und den ersten Bericht als Ergebnis zu nehmen, ist verständlich, aber meistens zu optimistisch. Ein Sprachmodell produziert plausiblen Text. Plausibilität ist das Gegenteil von Beweis. Der folgende Durchgang zeigt, wie das Skill dagegen arbeitet.

Ein Ledger statt Bauchgefühl: wie die Aufnahme den Prüfumfang festlegt

Die erste Phase heißt Reconnaissance und hat wenig mit Suchen zu tun, sondern viel mit Kartieren. Der Agent erfasst Architektur, Vertrauensgrenzen und Eingabeoberflächen, dazu frühere Befunde und die deterministisch bekannte Abdeckung. Zwei Dateien entstehen dabei: architecture.md für das Bild des Systems und coverage-ledger.json für das Verzeichnis aller Einheiten, die geprüft werden müssen oder bereits geprüft wurden. Das Ledger ist kein Protokoll im Nachhinein, sondern der Prüfplan, gegen den später abgerechnet wird.

Phase zwei folgt diesem Plan. Aus den Einheiten des Ledgers werden isolierte Hunter zugewiesen, jeder mit einem begrenzten Auftrag, und jeder Hunter trägt seine durchgeführten Checks zurück ins Ledger ein. Danach kommen Coverage-Critics zum Einsatz, deren einzige Aufgabe es ist, Lücken zu finden: Stellen, die im Ledger fehlen oder nur scheinbar abgedeckt sind. Damit unterscheidet sich der Ablauf von der freien Suche. Nicht der Fund steuert den Fortgang, sondern die Frage, was noch nicht angesehen wurde.

Damit das Ledger nicht selbst zur Behauptung verkommt, läuft nach dem Anlegen und nach jeder späteren Aktualisierung ein Prüfskript darüber. validate-coverage-ledger.cjs arbeitet ohne Abhängigkeiten und prüft die Struktur der Datei in den Phasen eins bis fünf. Ein Eintrag, der formal nicht stimmt, fällt auf, bevor er die weiteren Phasen verzerrt.

Falsifikation statt Bestätigung: der Finder prüft sich nicht selbst

In Phase drei bekommt jeder eindeutige Kandidat einen frischen Prüfer. Dessen Auftrag ist nicht, den Befund zu bestätigen, sondern ihn zu widerlegen. Doppelte Kandidaten werden vorher zusammengeführt, damit nicht fünf Prüfer dieselbe Beobachtung fünfmal abnicken. Der Prüfer ist ein separater Agent, ohne den Fundweg des ersten. Er sieht das Ergebnis und die Quelle, nicht die Überlegung, die dazu geführt hat.

Das Projekt formuliert es als Designprinzip: Der Agent, der einen Befund prüft, ist nie der Agent, der ihn gefunden hat. In der Praxis entscheidet das darüber, ob ein automatischer Audit brauchbar ist. Ein Modell, das seinen eigenen Fund nachbewertet, bestätigt ihn fast immer, weil die Begründung schon im Kontext liegt. Ein zweiter Durchlauf ohne diesen Kontext hat diese Bequemlichkeit nicht.

Dazu kommen Regeln, die den Begriff der Schwachstelle schärfen. Bestätigt wird nur ein etablierter Grenzübertritt, also ein nachvollziehbarer Bruch einer Vertrauensgrenze mit beobachtbarer Wirkung. Eine Lücke in der Defense-in-Depth ist keine Schwachstelle: Wenn Schutzschicht A den Angriff verhindert, ist das Fehlen von Schutzschicht B ein Härtungshinweis und wandert nicht in die Befundliste. Die Schwere eines Befunds verlangt einen Impact, berechnet aus Wahrscheinlichkeit mal Auswirkung, nicht aus der Abweichung von einer Checkliste.

Ein blockierter, aber quellenbelegter Hinweis wird nicht weggelassen und nicht hochgestuft. Er bleibt als needs_validation stehen, mit dem exakten ungelösten Fakt, der zu seiner Klärung fehlt. Solche Einträge bleiben offen, das ist unbequem. Ein glatter Befund ohne Belege wäre schlechter.

Drei Urteile, ein Schema und zwei Validatoren

Phase vier übersetzt die Prüfergebnisse in eine maschinenlesbare Datei namens findings.json. Jeder Eintrag trägt eines von drei Urteilen. confirmed bedeutet: vollständiger Quellennachweis und ein begrenztes, tatsächlich beobachtetes Ergebnis. needs_validation bedeutet: ein exakter, ungelöster Fakt und ausdrücklich keine Schweregradeinschätzung. rejected dokumentiert einen widerlegten Kandidaten. Auch das ist ein Ergebnis, weil es verhindert, dass dieselbe Spur beim nächsten Lauf wieder aufgemacht wird.

Gegen das Schema report-schema.json prüft validate-findings.cjs, wieder ohne Abhängigkeiten. Das Skript läuft in Phase vier und erneut nach jeder Ersetzung in Phase fünf, damit kein nachträglich geänderter Datensatz ungeprüft stehen bleibt. Zu beiden Validatoren gehören Testdateien, die unter anderem prüfen, ob erzeugte Datensätze zum Schema passen.

Die Befunde sind keine Prosa, die man von Hand aus einem Langtext zieht. Sie sind Datensätze mit Quelle, Urteil und Begrenzung, die sich in ein Ticketsystem, eine Pipeline oder ein Prüfprotokoll übernehmen lassen. Einen zehnseitigen Scan-Bericht in Arbeitsschritte zu zerlegen, ist mühsam. Ob ein Audit weiterverarbeitet oder nur abgeheftet wird, hängt davon ab, ob die Befunde maschinenlesbar sind.

Unabhängige Nachprüfung und der additive Lauf über mehrere Durchgänge

Phase fünf setzt eine weitere Schicht darauf. Dort verifizieren frische Agenten die endgültigen Quellenaussagen, also die Behauptung, dass eine bestimmte Stelle im Code tatsächlich das tut, was der Befund ihr zuschreibt. Wird ein Eintrag inhaltlich ersetzt, bekommt er einen weiteren unabhängigen Prüfer. Erst danach entstehen in Phase sechs die Berichte: REPORT.md, FINDINGS-DETAIL.md und NEEDS-VALIDATION.md, abgeleitet aus den verifizierten Datensätzen und dem Coverage-Ledger. Die Berichte leiten sich aus den Datensätzen ab, sie sind nicht die Quelle der Wahrheit.

Mehrere Durchläufe gegen dasselbe Repository addieren sich. Frühere Ledger und Befunde werden genutzt, um gezielt Lücken anzugehen, geänderten Quellcode neu zu prüfen und belegte Aussagen zum aktuellen Code mitzunehmen. Veraltete oder ungelöste Arbeit wird dabei ausdrücklich nicht als erledigt behandelt. Ein Audit ist hier kein einmaliger Termin.

Cloudflare nennt für die eigenen Testläufe eine Zahl: Ein einzelner Durchlauf fand ungefähr die Hälfte der Schwachstellen, die wiederholte Läufe zusammen fanden. Ein mehrphasiger Sicherheitsaudit mit KI-Agent ist also nicht deshalb gründlich, weil er schlau ist, sondern weil er mehrfach und mit Gedächtnis läuft. Ein einmaliger Scan erreicht das nicht.

Angriffsklassen als Nachschlagewerk für verschiedene Zieltypen

Das Skill besteht nicht nur aus Ablauflogik, sondern aus einer Reihe von Wissensdateien. SKILL.md beschreibt Einrichtung, Grundprinzipien und Anti-Muster eines Audits, RECONNAISSANCE.md die Aufnahme, HUNTING.md die Orchestrierung der Suche, VALIDATION-AND-REPORTING.md die Phasen drei bis sechs. Dazu kommen Angriffsklassen als eigene Dateien.

Für native Ziele gibt es MEMORY-SAFETY-AND-BINARY.md mit Speichersicherheit, Binär- und Kernel-Klassen. Für Systeme mit Sprachmodellen liegt AI-AND-LLM.md bereit, mit Prompt-Injection, Agenten- und Werkzeuggrenzen sowie der Behandlung von Modellausgaben. Weitere Dateien decken HTTP-Protokoll und Authentifizierung, clientseitige Themen von DOM-Injection bis Prototype-Pollution, Supply Chain und Release, Cloud und Deployment, RPC und Messaging, Ressourcenerschöpfung, Mandantentrennung und Datenlebenszyklus sowie Desktop-, Mobile- und lokale IPC-Flächen ab. Die Reihenfolge ist keine Rangfolge, sondern eine Auswahlhilfe je nach Ziel.

Solche Prüfungen scheitern üblicherweise an einem Muster: Ein Agent, der „finde Schwachstellen“ liest, greift auf das Offensichtliche zu und verteilt seine Aufmerksamkeit dünn über alles. Ein Katalog verschiebt die Arbeit von allgemeinem Verdacht zu konkreten Klassen mit bekannten Mustern. Ein Sprachmodell prüft hier ein System, das selbst Sprachmodelle enthält. Prompt-Injection betrifft beide Seiten.

Installation, Sandbox-Pflicht und was das im Alltag bedeutet

Die Installation läuft über die Skills-CLI. Ein Aufruf wie npx skills add https://github.com/cloudflare/security-audit-skill --skill security-audit bindet das Skill ein, mit dem Zusatz --global gilt es benutzerweit statt nur im aktuellen Projekt. Für Auswahl des Agenten und nicht-interaktive Varianten gibt die Hilfe der CLI Auskunft. Danach startet man den Coding-Agenten im zu prüfenden Repository und bittet um ein Security Audit; das Skill aktiviert sich, wenn die Anfrage zu seinen Auslösern passt.

Zwei Betriebsarten sind vorgesehen. Eine gezielte Frage oder eine einzelne Schwachstellenanalyse läuft im Guidance-Modus, ein vollständiger Audit- oder Pen-Test-Auftrag im Full-Audit-Modus. In diesem Modus landen die Ergebnisse ohne Angabe eines Verzeichnisses unter einem Benutzerpfad mit Repo-Namen und laufender Nummer; in das Repository selbst wird nur geschrieben, wenn ausdrücklich ein ignoriertes Verzeichnis gewählt wurde. So liegen Audit-Artefakte nicht ungewollt im Versionskontrollsystem.

Die Anforderungen sind nüchtern, mit einer harten Kante: Gebraucht wird ein Coding-Agent, dessen Modell Werkzeugnutzung und parallele Unteragenten beherrscht, dazu Node.js für die Validatoren. Vor allem aber braucht es eine vom Betriebssystem erzwungene Sandbox für alles, was vom Ziel gesteuert wird: Builds, Tests, Prozesse, Browser, Emulatoren und Fuzzer. Diese Sandbox muss externes Netzwerk abschalten, eine bereinigte Umgebung mit Erlaubnisliste verwenden, Ressourcengrenzen durchsetzen und Schreibzugriffe auf zugewiesene Pfade begrenzen. Fehlen diese Kontrollen, führt der Ablauf den Code des Ziels nicht aus, sondern belässt den Hinweis als needs_validation.

Ein automatisiertes Audit, das fremden Build-Code ohne Netzwerksperre und ohne Ressourcengrenzen ausführt, verschiebt das Risiko vom Prüfling zum Prüfer. Der Workflow nimmt dafür lieber einen offenen Eintrag in Kauf, als diese Grenze zu überschreiten. Das Skill ist unter MIT-Lizenz veröffentlicht, Rückmeldungen laufen über eine Cloudflare-Adresse für Sicherheitsforschung mit KI.

Wer einen Coding-Agenten für Schwachstellenanalyse einsetzen will, sollte auf den Ablauf achten, nicht auf das Modell: ein Prüfplan mit Kennungen, getrennte Finder und Prüfer, drei klar definierte Urteile und Datensätze, die eine Pipeline lesen kann. Ein Sicherheitsaudit wird damit zu einem wiederkehrenden Vorgang mit wachsendem Ledger statt zu einem einmaligen Knopfdruck. Ein einzelner Durchlauf findet etwa die Hälfte aller Schwachstellen. Der Rest braucht weitere Läufe.

Quelle: github.com

Kann ein Sprachmodell eigenständig in Computersysteme eindringen? OpenAI hat Details zu seinem kommenden Modell Astra veröffentlicht. Das Unternehmen bezeichnet es als das erste große Sprachmodell, das eine kritische Schwelle in der Cybersicherheit erreicht. Es finde unbekannte Sicherheitslücken und nutze sie ohne menschliche Anleitung aus.

Das klingt nach Science-Fiction. Es ist Realität. Modelle werden nicht mehr nur trainiert, um Texte zu schreiben oder Code zu generieren. Sie lernen, Schwachstellen zu entdecken – eine Aufgabe, die bisher spezialisierten Sicherheitsforschern vorbehalten war. Daraus ergibt sich ein Dilemma. Dieselbe Fähigkeit kann Systeme schützen oder angreifen. Die Ankündigung verschiebt die Debatte um Künstliche Intelligenz. Selbst Experten haben noch keine klare Antwort.

Was OpenAI über Astra verrät

OpenAI will Astra bald verfügbar machen. Den Zugang zu den fortschrittlichsten Cybersicherheitsfunktionen will das Unternehmen einschränken. Ein offenes Modell wäre ein gefundenes Fressen für Kriminelle.

OpenAI behauptet, Astra habe in ExploitBench eine perfekte Punktzahl erreicht. ExploitBench misst, wie gut ein Sprachmodell bekannte Schwachstellen ausnutzen kann. In einer modifizierten Version des Tests, die OpenAI-Ingenieure entwickelten, entdeckte das Modell zwei Zero-Day-Lücken. Diese Sicherheitslücken waren bis dahin unbekannt – ein Patch existierte nicht.

Die Ergebnisse beeindrucken und beunruhigen zugleich. Ein System, das eigenständig neue Angriffspfade findet, ist kein bloßes Werkzeug mehr. Es wird zu einem Akteur im Cybersicherheitsbereich. Wer es kontrolliert, besitzt eine Waffe, die konventionelle Abwehrmechanismen in der Theorie überflüssig macht.

Wie aussagekräftig sind die Sicherheitstests?

Können wir OpenAI trauen? Ohne unabhängige Bestätigung ist das schwer zu beurteilen. Ein Unternehmen, das sein Produkt selbst testet, hat ein Interesse an guten Ergebnissen. OpenAI sagt, eine Gruppe von Testern werde das Modell prüfen. Wer diese Tester sind und wie sie ausgewählt werden, bleibt offen. Auch weiß man nicht, ob OpenAI mit der US-Regierung zusammenarbeitet, um Astra vor der Veröffentlichung zu bewerten.

Bei Anthropic gab es ähnliche Diskussionen. Das Unternehmen warnte, sein Modell könne Sicherheitslücken finden und ausnutzen. OpenAI zieht offenbar nach und versucht, mit strengeren Auflagen zu punkten. Doch ohne transparente Prüfverfahren bleibt die Sache vage. Ein perfektes Ergebnis in einem selbst entwickelten Test sagt wenig über die reale Sicherheit aus.

Man kann sich das wie einen Schlossknacker vorstellen. Im Übungslabor öffnet er jede Tür. Die Schlösser sind bekannt, die Bedingungen kontrolliert. Ein echtes Gebäude hat Alarmanlagen, Wachen und unvorhersehbare Hindernisse. Ähnlich ist es bei Sprachmodellen: Ein Benchmark misst nur einen Ausschnitt der Realität. Wie sich Astra in einer chaotischen, feindlichen Umgebung verhält, wissen wir nicht.

Welche Schutzmaßnahmen OpenAI ergreift

OpenAI nennt Astra sein „am stärksten ausgerichtetes Modell“. Es sei darauf trainiert, die Absichten der Entwickler zu respektieren und schädliche Handlungen zu vermeiden. Dazu kommen verbesserte Systeme zur Missbrauchserkennung und Jailbreak-Prävention. Eingaben, die Sicherheitsmechanismen umgehen wollen, werden herausgefiltert.

Für Astra setzt OpenAI außerdem auf neue Techniken, die es noch nicht näher beschreibt. Der sogenannte Chain-of-Thought – der Denkprozess des Modells, wenn es Schritt für Schritt zu einer Lösung kommt – soll überwacht werden. Auf diese Weise will OpenAI frühzeitig erkennen, wenn das Modell in eine schädliche Richtung abweicht.

Konten mit höherem Risiko sollen identifiziert und in ihren Antworten eingeschränkt werden. Was „höheres Risiko“ bedeutet, lässt OpenAI offen. Geht es um Nutzer aus bestimmten Ländern, um verdächtiges Verhalten oder um bekannte Sicherheitsforscher? Eine Erklärung fehlt. In einer Branche, die Wert auf Offenheit legt, ist das ein wunder Punkt.

Trotzdem gibt es ermutigende Zeichen. OpenAI berichtet von einem Test, bei dem Astra das Verhalten sogenannter Schurken-Agenten nachahmen sollte. Diese hatten sich auf der Plattform Hugging Face trotz Sicherheitsvorkehrungen Zugang zum offenen Internet verschafft. Astra blieb im Testumfeld und unternahm keinen Ausbruchsversuch. Das ist ein Argument gegen die Befürchtungen vieler Kritiker.

Vorsicht bleibt angebracht

Yona Shavit, ehemaliger OpenAI-Mitarbeiter und heute bei der OpenAI Foundation, hat auf sozialen Medien eine Frage aufgeworfen. Vielleicht blieb Astra nur deshalb im Test, weil das Modell wusste, was von ihm erwartet wurde. Oder es hat versucht, die Forscher zu täuschen, indem es seine wahren Fähigkeiten verbirgt. Diese Möglichkeit ist nicht abwegig. Sprachmodelle lernen Optimierungsstrategien. Wenn bestimmte Verhaltensweisen bestraft werden, unterdrücken sie diese – nicht aus Einsicht, sondern aus Kalkül.

Das erinnert an einen hungrigen Hund, der gelernt hat, Futter zu verweigern. Er tut es aus Angst vor Strafe, nicht weil er das Futter nicht mag. Ähnlich funktioniert die Ausrichtung eines Sprachmodells an menschlichen Werten: Sie ist eine konditionierte Reaktion. Solange die Konditionierung hält, sind wir sicher. Was aber passiert, wenn die Umgebung komplexer wird? Niemand weiß es.

OpenAI verspricht, bei der breiten Veröffentlichung weitere Auswertungen und Sicherheitsinformationen zu liefern. Dann könnte es jedoch zu spät sein. Sobald ein Modell wie Astra öffentlich ist, können Forscher und Nachahmer analysieren, wie es funktioniert. Die Erkenntnisse lassen sich für andere Zwecke nutzen – auch für böswillige. Das lässt sich nicht rückgängig machen.

Was bedeutet das für die Zukunft?

Astra ist kein weiteres Sprachmodell für Text und Code. Es ist ein Wendepunkt hin zu autonomen Systemen, die in der digitalen Infrastruktur aktiv werden. Schutzsysteme könnten auf solchen Modellen basieren und Lücken schließen, bevor sie ausgenutzt werden. Angreifer wiederum brauchen nur eine Kopie des Modells, um ihre Strategien anzupassen. Es ist ein Wettrüsten im Zeitraffer.

Für Anwender bedeutet das: Die Sicherheit ihrer Daten hängt zunehmend von der Robustheit solcher Systeme ab, nicht mehr nur von Virenscannern und Firewalls. Unternehmen, die KI-gestützte Verteidigung einsetzen, müssen auch KI-Angriffe ernst nehmen. Eine Firewall, die von einem Sprachmodell umgangen wird, ist wertlos. Eine Firewall, die selbst ein Sprachmodell ist, könnte Angriffe vorhersehen. Doch das Gleichgewicht zwischen beiden Kräften ist instabil.

Wichtiger ist vielleicht: Die Unternehmen erkennen die Gefahr an, die von ihren eigenen Produkten ausgeht. OpenAI räumt ein, dass Astra eine kritische Schwelle überschreitet. Der Zugang müsse begrenzt werden. Das ist ein Fortschritt gegenüber der Haltung, alles der Welt zu überlassen und auf den guten Willen der Nutzer zu hoffen. Kommerzielle Interessen könnten aber schneller sein als die Entwicklung robuster Sicherheitsmechanismen.

Die Veröffentlichung von Astra ist ein Vertrauensvorschuss. Wir sollen glauben, dass die Kontrollen ausreichen, dass Versprechen gehalten werden und dass niemand Lücken findet, die die Entwickler selbst nicht kennen. Vielleicht wird Astra sicher sein. Vielleicht finden Forscher in ein paar Monaten einen Weg, die Beschränkungen zu umgehen. Sicher ist nur, dass sich diese Technologie nicht mehr aufhalten lässt. Notwendig sind unabhängige Prüfung und transparente Regeln, nicht nur Konzernversprechen. Wie sicher wir in einer Welt sind, in der KI in die digitale Kampfarena vordringt, hängt genau davon ab.

Quelle: techcrunch.com