Claude findet 493 Sicherheitsprobleme in Open-Source-Projekten

Claude hat bei der Analyse von 25 Open-Source-Projekten insgesamt 493 Sicherheitsprobleme gemeldet. Anthropic untersuchte dabei nicht nur einzelne Fehler, sondern auch, ob unnötig viel Code erreichbar ist und ob bestimmte Einstellungen Schutzmaßnahmen aushebeln können.

Die Zahl bedeutet nicht, dass Claude 493 bestätigte, unmittelbar ausnutzbare Schwachstellen gefunden hat. Ein Teil der Meldungen betrifft unnötige Zugänge zu Funktionen. Die Untersuchung zeigt einen Ansatz, den Entwickler für die eigene Prüfung übernehmen können. Eine kostenlose Claude-Prüffunktion wird in den vorliegenden Angaben nicht beschrieben.

Inhaltsverzeichnis

Warum unnötig erreichbarer Code zählt

Mehr erreichbarer Code bietet mehr Ansatzpunkte

Programme wachsen mit neuen Funktionen, Abhängigkeiten und Einstellungen. Dadurch kann Code erreichbar bleiben, obwohl er für den vorgesehenen Betrieb nicht gebraucht wird. Eine Angreiferin oder ein Angreifer kann diesen Code unter Umständen ansprechen, bevor eine Anmeldung erfolgt oder eine Sicherheitsprüfung greift.

Eine Prüfung auf einzelne Fehler reicht laut Anthropic nicht immer aus: Selbst wenn ein bekannter Fehler behoben ist, sagt das nichts über alle übrigen Schwachstellen aus. Wird unnötiger Code hinter eine passende Zugangskontrolle verschoben, kann das auch unbekannte Fehler schwerer erreichbar machen. Es beseitigt diese Fehler nicht, kann aber ihre Auswirkungen begrenzen.

Was die Analyse ergeben hat

Anthropic ordnete die Befunde drei Bereichen zu: unnötig erreichbarer Code in der Standardkonfiguration, problematische Kombinationen von Einstellungen sowie komplexe oder sicherheitsrelevante Verarbeitung vor einer Prüfung oder Anmeldung.

Prüfbereich	Beispiel aus der Untersuchung
Voreinstellungen	Unnötige Funktion bleibt erreichbar
Einstellungskombinationen	94 Fälle schalteten Schutz still ab
Zugangskontrollen	Code war vor Anmeldung erreichbar

In allen elf untersuchten Projekten, die Funktionen auf angemeldete Nutzer beschränken sollten, fand Claude Code, der vor der Anmeldung erreichbar war. Die Untersuchung stufte diese Befunde nicht automatisch als direkt ausnutzbare Fehler ein. Sie zeigen aber, dass die tatsächliche Zugriffskontrolle von der geplanten abweichen kann.

So prüfen Entwickler ein eigenes Projekt

1. Einsatz und Zugriff festhalten

Notieren Sie zuerst, wie das Programm tatsächlich eingesetzt wird: Welche Funktionen sollen standardmäßig aktiv sein? Welche Nutzer dürfen darauf zugreifen? Welche Prüfungen müssen vor einer Verarbeitung stattfinden? Diese Angaben helfen, unnötig erreichbare Funktionen von solchen zu unterscheiden, die absichtlich offen sind.

2. Standardwerte und Zugangspfade durchgehen

Prüfen Sie, welche Funktionen mit der ausgelieferten Standardkonfiguration erreichbar sind. Verfolgen Sie anschließend, ob eine Anfrage vor der Anmeldung bereits komplexe Verarbeitung auslöst oder sicherheitsrelevanten Code erreicht. Achten Sie auch auf Protokolle: Manche Prüfungen sollten erst nach einem bestimmten Schritt im Verbindungsablauf stattfinden.

Für die Untersuchung nutzte Anthropic Claude, um erreichbaren Code in großen Codebeständen zu analysieren. Entwickler können dieselben Fragen als Prüfauftrag an ein geeignetes Analysewerkzeug stellen. Das ist eine Übertragung der beschriebenen Methode, kein offizieller Gratis-Klickpfad für Claude.

3. Einstellungen paarweise prüfen

Testen Sie nicht nur einzelne Optionen, sondern auch Kombinationen. Prüfen Sie, ob zwei jeweils plausibel wirkende Einstellungen zusammen eine Schutzmaßnahme abschalten, und ob das Programm davor warnt. In der Studie wurden 162 sicherheitsrelevante Kombinationen ohne Fehler, Warnung oder erklärende Dokumentation akzeptiert; in 94 Fällen fiel dadurch ein Schutz still weg.

4. Befunde bestätigen und Änderungen prüfen

Behandeln Sie einen Analysehinweis zunächst als Verdacht. Stellen Sie die betreffende Konfiguration nach, prüfen Sie den Zugriff und lassen Sie Änderungen von einer verantwortlichen Person kontrollieren. Anthropic beschreibt, dass die Methode unnötige Zugänge verringern soll, nicht alle Fehler im Code findet oder behebt.

Praktische Hinweise für den Alltag

Auf Kombinationen und frühe Verarbeitung achten

Besonders aufschlussreich sind Einstellungen, die zusammenarbeiten müssen. Anthropic nennt als Beispiel Hostnamen-Regeln, deren Wirkung von einer separaten Einstellung für Reverse-DNS-Abfragen abhing. War diese Abfrage ausgeschaltet, konnte ein Server eine Hostnamen-Regel mit der IP-Adresse des Clients vergleichen. Das kann dazu führen, dass eine vorgesehene Sperre nicht greift.

Werkzeuge und Erwartungen unterscheiden

Anthropic berichtet über eine Forschungsanalyse mit Claude. Daneben beschreibt die Hilfe zu Claude Security eine öffentliche Beta für Nutzer mit Enterprise-Tarif. Die verfügbaren Angaben belegen daher keine kostenlose Nutzung für alle Entwickler. Klären Sie vor dem Einsatz eines externen Werkzeugs außerdem, ob Ihr Team den betreffenden Quellcode dort prüfen lassen darf.

Für kleinere Teams ist ein enger Prüfauftrag oft ein guter Start: eine einzelne Anwendung, eine klar beschriebene Standardkonfiguration und wenige konkrete Fragen zu Zugangskontrollen. Halten Sie fest, welche Befunde bestätigt wurden und welche nur mögliche Risiken darstellen. So bleibt nachvollziehbar, was tatsächlich geändert werden muss.