The EVerest Dataset for Secure Software Engineering
Das Paper stellt den EVerest-Datensatz vor, eine einzigartige Multi-Artefakt-Ressource, die Sicherheitsanforderungen, Architekturmodelle und Quellcode eines Elektrofahrzeug-Lade-Stacks umfasst, was die End-to-End-Sicherheitsverifizierungsforschung ermöglichte und die Entdeckung sowie Behebung einer realen Sicherheitslücke erleichterte.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich vor, Sie bauen eine hochmoderne Ladestation für Elektrofahrzeuge. Um sicherzustellen, dass sie vor Hackern geschützt ist, müssen Sie drei verschiedene Ebenen Ihres Projekts überprüfen:
- Die Wunschliste: Was die Entwickler sagen, dass sie wollen (z. B. „Es muss sicher sein“).
- Der Bauplan: Die architektonischen Zeichnungen, die zeigen, wie die Teile miteinander verbunden sind.
- Die Ziegel: Der eigentliche Computercode, der die Maschine am Laufen hält.
Das Problem ist, dass die meisten Forschungswerkzeuge nur eine dieser Ebenen betrachten. Sie haben vielleicht eine Liste von Wünschen oder einen Haufen Code, aber sie haben niemals alle drei miteinander verknüpft. Es ist, als würde man versuchen, ein undichtes Dach zu reparieren, indem man nur den Bauplan betrachtet, ohne jemals die tatsächlichen Schindeln oder die Beschwerdeliste des Hausbesitzers zu prüfen.
Der EVerest-Datensatz ist ein neues, riesiges „All-in-one“-Toolkit, das von Forschern des Karlsruher Instituts für Technologie entwickelt wurde, um genau dies zu beheben. Er verbindet die Wunschliste, den Bauplan und die Ziegel für ein reales Open-Source-Softwareprojekt namens EVerest (das die Steuerung von E-Ladestationen übernimmt).
Hier ist, wie sie ihn aufgebaut haben, unter Verwendung einer einfachen Analogie:
1. Das Sammeln der „Wunschliste“ (Anforderungen)
Zuer Sie die Forscher wissen mussten, welche Sicherheitsregeln das Projekt tatsächlich benötigte.
- Die Umfrage: Sie schickten einen Fragebogen an die Entwickler-Community mit der Frage: „Was sind die Sicherheitsziele?“ (Wie die Frage: „Möchten Sie, dass die Tür abgeschlossen ist?“). Dies ergab eine grobe Liste von 6f Ideen.
- Das Interview: Die grobe Liste war zu vage. Also setzten sie sich mit vier Experten-Entwicklern für tiefgehende Gespräche zusammen. Sie verfeinerten diese groben Ideen zu spezifischen Anweisungen, etwa indem sie aus „Die Tür abschließen“ die Anweisung machten: „Das OCPP-Modul muss fehlerhafte Eingaben vom CSMS ablehnen“.
- Das Ergebnis: Sie erhielten 84 präzise Sicherheitsanforderungen.
2. Das Zeichnen des „Bauplans“ (Architektur)
Das EVerest-Projekt besaß keinen formellen architektonischen Plan; es besaß lediglich Code.
- Die Übersetzung: Drei Studenten erstellten unter Aufsicht von Experten anhand des Quellcodes manuell ein formelles Palladio-Komponentenmodell. Stellen Sie sich das so vor, als würde man einen Haufen Lego-Steine nehmen und ein detailliertes Diagramm zeichnen, das genau zeigt, wie jedes Teil verbunden ist, wie Daten zwischen ihnen fließen und wie sie miteinander kommunizieren.
- Das Ergebnis: Ein digitaler Bauplan mit 29 Komponenten und 144 detaillierten Leistungsbeschreibungen.
3. Das Beschriften der „Ziegel“ (Code & Elemente)
Nun mussten sie die Verbindung zwischen der Wunschliste und dem Bauplan herstellen.
- Das Tagging-Spiel: Drei Personen gingen die 84 Anforderungen durch und markierten spezifische Wörter. Sie beschrifteten (taggten) Dinge wie „Komponenten“, „Daten“, „Zustände“ und „Datenflüsse“.
- Die Spur (Trace): Sie zeichneten digitale Linien (Trace-Links), die einen spezifischen Satz in der Anforderung (z. B. „Der Zahlungsanbieter muss sicher sein“) direkt mit dem spezifischen Teil des Bauplans und dem Code verbinden, der die Zahlung abwickelt.
- Das Ergebnis: Sie beschrifteten 1.445 winzige Sicherheitselemente und schufen so ein massives Netz von Verbindungen.
Der Praxistest
Das Beste an diesem Datensatz ist nicht nur, dass er existiert; er hat tatsächlich einen echten Fehler gefunden.
Während des Erstellungsprozesses des Datensatzes bemerkten die Forscher eine Diskrepanz. Eine der Anforderungen besagte: „Authentifizierungstoken dürfen nicht im Klartext gespeichert werden.“ Als sie jedoch den eigentlichen Code (die „Ziegel“) betrachteten, fanden sie eine Zeile, in der der Code die Token tatsächlich im Klartext speicherte.
- Die Lösung: Sie meldeten dies den Projektverwaltern. Die Entwickler bestätigten, dass es sich um eine echte Schwachstelle (bekannt als CWE-1295) handelte, und behoben sie umgehend.
Warum das wichtig ist
Bevor es dies gab, mussten Forscher, die versuchten, Werkzeuge zur automatischen Überprüfung der Softwaresicherheit zu entwickeln, raten, wie die Anforderungen, das Design und der Code zusammenhingen, da kein Datensatz alle drei Ebenen bereitstellte.
Der EVerest-Datensatz ist wie ein vollständiges, beschriftetes Handbuch für KI und Forscher. Er ermöglicht es ihnen, Folgendes zu üben:
- Computern beizubringen, Sicherheitsanforderungen zu verstehen.
- Automatisch zu finden, wo eine Anforderung im Code implementiert ist.
- Zu prüfen, ob die fertige Software tatsächlich den ursprünglichen Sicherheitsversprechen entspricht.
Kurz gesagt: Die Arbeit präsentiert eine einzigartige, mehrschichtige Ressource, die die Lücke zwischen dem, was Software tun sollte, wie sie entworfen wird und wie sie gebaut wird, schließt, und beweist ihren Wert durch das Aufdecken einer echten Sicherheitslücke während des Prozesses.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.