curl: Mehr Sicherheitsmeldungen machen uns noch nicht sicherer

Eine Sicherheitsmeldung ist schnell geschrieben. Jemand muss anschließend prüfen, ob sie stimmt, welche Systeme betroffen sind und was sich ändern muss. Mich beschäftigt an der aktuellen curl-Debatte genau diese Verteilung: Wir können immer mehr Befunde erzeugen. Die Verantwortung für ihre Bewertung wächst nicht automatisch mit.

Meinung von Julian Köhn, CTO und Mitgründer von Kopexa. Quellenstand: 23. Oktober 2026.

Was sich bei curl am 26. Oktober ändert

Daniel Stenberg kündigte am 20. Oktober an, Meldungen der Schweregrade LOW und MEDIUM ab dem 26. Oktober öffentlich auf GitHub zu bearbeiten. HIGH und CRITICAL bleiben im privaten HackerOne-Verfahren. Wer die Schwere nicht sicher einschätzen kann, darf weiterhin dort melden; das Projekt nimmt die Einstufung vor.

Der Hintergrund ist die Überlastung der Maintainer. Die öffentliche Bearbeitung soll zusätzliche Beteiligung ermöglichen. Sie verringert nicht automatisch die Arbeit pro Meldung. Stenberg benennt auch den Nachteil: Angreifer können früher von noch ungepatchten Problemen erfahren. Ankündigung des neuen Verfahrens

Titelbild: Originalüberschrift und Veröffentlichungsangaben aus Daniel Stenbergs Blog, aufgenommen am 23. Oktober 2026; Kopexa-Logo als redaktionelle Kennzeichnung.

Für mich ist das eine Entscheidung unter Kapazitätsdruck. Das Team verteilt Arbeit und nimmt dafür ein konkretes Risiko in Kauf. Daraus lässt sich keine allgemeine Empfehlung ableiten, interne Sicherheitsbefunde künftig ungeprüft öffentlich zu stellen.

KI als Herkunft ist kein Ausschlusskriterium

In seinem Folgebeitrag vom 22. Oktober widerspricht Stenberg der Aufforderung, KI-generierte Meldungen einfach zu ignorieren: Solche Meldungen können tatsächliche Fehler und Sicherheitslücken belegen. Ihr Ursprung macht die Schwachstelle nicht unwirksam. Stenbergs Einordnung

Ich würde deshalb denselben Maßstab an jede Meldung anlegen: Welche überprüfbare Aussage enthält sie? Ein überzeugender Text ist kein Nachweis. Ein schlecht formulierter Bericht kann trotzdem einen reproduzierbaren Fehler beschreiben.

Eine Mindestanforderung wäre für mich ein kleiner, nachvollziehbarer Fall: betroffene Version, notwendige Konfiguration, erwartetes und tatsächliches Verhalten sowie die mögliche Sicherheitswirkung. Fehlen Angaben, bleibt der Befund offen und bekommt eine Rückfrage. Er wird dadurch weder bestätigt noch automatisch verworfen.

Die entscheidende Frage lautet: Trifft das unseren Betrieb?

Die technische Schwere ist ein Ausgangspunkt. Für die Reihenfolge unserer Arbeit brauche ich zusätzlich den Kontext der laufenden Anwendung.

Angenommen, ein Bericht beschreibt einen Fehler beim Verarbeiten einer bestimmten Eingabe. Dann will ich wissen: Kann ein Angreifer diese Eingabe in unserer Nutzung überhaupt beeinflussen? Wird der betroffene Codepfad aufgerufen? Mit welchen Rechten läuft der Prozess? Welche Informationen oder Dienste wären bei erfolgreicher Ausnutzung erreichbar?

Ein hypothetischer Vergleich: Derselbe Fehler steckt in einem isolierten Testwerkzeug und in einem öffentlich erreichbaren Dienst, der fremde Inhalte verarbeitet. Die Versionsnummer allein führt beide auf dieselbe Liste. Der tatsächliche Handlungsdruck kann sehr unterschiedlich sein.

„Nicht betroffen“ würde ich nur mit einer überprüften Begründung akzeptieren. „Das nutzen wir vermutlich nicht“ beschreibt eine Wissenslücke. Auch die muss jemand schließen. Und wenn sich Konfiguration, Eingabequelle oder Einsatzgebiet ändern, muss die Bewertung erneut auf den Tisch.

So würde ich ein überfülltes Schwachstellenticket verkleinern

Nehmt einen offenen Befund aus eurem eigenen Bestand. Ergänzt gemeinsam mit dem zuständigen Entwickler oder Administrator diese fünf Angaben:

1. Befund: Welche konkrete Sicherheitswirkung ist belegt, welche nur vermutet?
2. Betroffenheit: Welche laufende Komponente ist in welcher Konfiguration betroffen?
3. Entscheidung: Aktualisieren, vorübergehend isolieren, genauer untersuchen oder begründet zurückstellen?
4. Verantwortung: Wer setzt die nächste Handlung bis wann um?
5. Wiedervorlage: Welcher Termin oder welche neue Information ändert die Entscheidung?

Das Ergebnis muss kurz genug sein, dass jemand anderes die Entscheidung prüfen kann. Lange Scannerberichte können als Anlage bleiben. Sie sollten nicht die Begründung ersetzen.

Beim Zurückstellen hilft eine dokumentierte Risikoakzeptanz mit Verantwortlichem und Ablaufdatum. Die Annahme „dieser Dienst ist intern“ sollte beispielsweise erneut geprüft werden, bevor ihn jemand über einen neuen Zugang erreichbar macht.

Woran ich bessere Sicherheitsarbeit erkennen würde

Die Zahl geschlossener Tickets allein überzeugt mich nicht. Ich würde prüfen, wie lange bestätigte, für unseren Betrieb relevante Schwachstellen offen bleiben und wie viele Entscheidungen auf ungeprüften Annahmen beruhen. Auch fehlende Zuständigkeit ist ein Ergebnis, das sichtbar werden muss.

Dabei darf Priorisierung nicht zum dauerhaften Weglegen unbequemer Arbeit werden. Eine befristete Ausnahme braucht eine echte Wiedervorlage. Ein ausstehendes Update braucht einen umsetzbaren Plan. Und eine technische Entwarnung braucht aktuelle, überprüfbare Nachweise.

Genau dort sehe ich den Nutzen einer GRC-Plattform wie Kopexa: Risiken, Maßnahmen und Verantwortliche bleiben zusammen; Prüfergebnisse liegen als Nachweise an den Maßnahmen. Die Software nimmt uns die technische Bewertung nicht ab. Sie hilft, aus ihr verbindliche Arbeit zu machen.

Meine Prüffrage für das nächste Review: Welchen offenen Befund können wir heute begründet entscheiden – und bei welchem fehlt uns dafür noch eine konkrete Information?