The EVerest Dataset for Secure Software Engineering
Het artikel introduceert de EVerest-dataset, een unieke multi-artifact bron bestaande uit beveiligingseisen, architecturale modellen en broncode van een elektrische voertuiglaadstack, die end-to-end onderzoek naar beveiligingsverificatie mogelijk maakt en de ontdekking en remediëring van een reële beveiligingskwetsbaarheid heeft gefaciliteerd.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je voor dat je een hoogtechnologisch laadstation voor elektrische voertuigen bouwt. Om ervoor te zorgen dat het veilig is voor hackers, moet je drie verschillende lagen van je project controleren:
- De Verlanglijst: Wat de ontwikkelaars zeggen dat ze willen (bijv. "Het moet veilig zijn").
- De Blauwdruk: De architecturale tekeningen die laten zien hoe de onderdelen met elkaar verbonden zijn.
- De Bakstenen: De eigenlijke computercode die de machine laat draaien.
Het probleem is dat de meeste onderzoeksinstrumenten slechts naar één van deze lagen kijken. Ze hebben misschien een lijst met wensen, of een stapel code, maar ze hebben deze drie lagen nooit met elkaar verbonden. Het is alsof je probeert een lekkend dak te repareren door alleen naar de blauwdrukken te kijken, zonder ooit de eigenlijke dakpannen of de klachtenlijst van de huiseigenaar te controleren.
De EVerest Dataset is een nieuwe, gigantische "alles-in-één" toolkit, gemaakt door onderzoekers van het Karlsruhe Institute of Technology om dit op te lossen. Het verbindt de Verlanglijst, de Blauwdruk en de Bakstenen voor een echt wereldwijd, open-source softwareproject genaamd EVerest (dat EV-laders aanstuurt).
Hier is hoe ze het gebouwd hebben, met behulp van een eenvoudige analogie:
1. Het verzamelen van de "Verlanglijst" (Requirements)
Eerst moesten de onderzoekers weten welke beveiligingsregels het project daadwerkelijk nodig had.
- De Enquête: Ze stuurden een vragenlijst naar de gemeenschap van ontwikkelaars met de vraag: "Wat zijn de beveiligingsdoelen?" (Zoals vragen: "Wil je dat de deur op slot zit?"). Dit leverde een ruwe lijst op van 6ft 67 ideeën.
- Het Interview: De ruwe lijst was te vaag. Daarom gingen ze in diepgaande gesprekken met vier deskundige ontwikkelaars. Ze namen die ruwe ideeën en verfijnden ze tot specifieke instructies, zoals het veranderen van "Sluit de deur op slot" naar "De OCPP-module moet malafide invoer van de CSMS afwijzen."
- Het Resultaat: Ze kwamen uit op 84 precieze beveiligingseisen.
2. Het tekenen van de "Blauwdruk" (Architectuur)
Het EVerest-project had geen formele architecturale kaart; het had alleen code.
- De Vertaling: Drie studenten, onder toezicht van experts, bekeken de broncode en bouwden handmatig een formeel Palladio-componentmodel. Denk hierbij aan het nemen van een stapel Lego-blokjes en het tekenen van een gedetailleerde diagram die precies laat zien hoe elk stukje met elkaar verbonden is, hoe data tussen hen stroomt en hoe ze met elkaar communicen.
- Het Resultaat: Een digitale blauwdruk met 29 componenten en 144 gedetailleerde servicenormen.
3. Het labelen van de "Bakstenen" (Code & Elementen)
Nu moesten ze de verbanden leggen tussen de Verlanglijst en de Blauwdruk.
- Het Labelspel: Drie mensen gingen door de 84 eisen heen en markeerden specifieke woorden. Ze labelden zaken als "componenten", "data", "statussen" en "datastromen".
- De Trace: Ze trokken digitale lijnen (trace links) die een specifieke zin in de eis (bijv. "De betalingsprovider moet veilig zijn") direct verbonden met het specifieke deel van de blauwdruk en de code die de betaling afhandelt.
- Het Resultaat: Ze labelden 1.445 kleine beveiligingselementen, waardoor een enorm web van verbindingen ontstond.
De Test in de Praktijk
Het beste deel van deze dataset is niet alleen dat deze bestaat; het is dat het ook daadwerkelijk een echte bug heeft gevonden.
Tijdens het bouwen van de dataset merkten de onderzoekers een mismatch op. Een van de eisen zei: "Authenticatietokens mogen niet in onversleutelde tekst worden opgeslagen." Echter, toen ze naar de eigenlijke code (de "bakstenen") keken, vonden ze een regel waar de code tokens inderdaad in onversleutelde tekst opsloeg.
- De Fix: Ze rapporteerden dit aan de beheerders van het project. De ontwikkelaars bevestigden dat dit een echt zwak punt was (bekend als CWE-1295) en herstelden het onmiddellijk.
Waarom dit ertoe doet
Vóór dit moment moesten onderzoekers die tools wilden bouwen om automatisch softwarebeveiliging te controleren, raden hoe de eisen, het ontwerp en de code met elkaar samenhingen, omdat geen enkele dataset alle drie leverde.
De EVerest-dataset is als een volledige, gelabelde handleiding voor AI en onderzoekers. Het stelt hen in staat om te oefenen met:
- Het computers leren om beveiligingseisen te begrijpen.
- Automatisch vinden waar een eis wordt geïmplementeerd in de code.
- Controleren of de uiteindelijke software daadwerkelijk overeenkomt met de oorspronkelijke veiligheidsbeloften.
Kortom, het artikel presenteert een unieke, meerlagige bron die de kloof overbrugt tussen wat software zou moeten doen, hoe het is ontworpen en hoe het is gebouwd, waarbij de waarde wordt bewezen door tijdens het proces een echt beveiligingslek te ontdekken.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.