Security Incentivization: An Empirical Study of how Micropayments Impact Code Security
Diese empirische Studie zeigt, dass die Verknüpfung von Team-Anreizen mit automatisierten Sicherheitsmetriken die Dichte von Sicherheitsproblemen im Code signifikant reduziert, insbesondere in Back-end-Komponenten, ohne die Code-Volumina künstlich aufzublähen, und damit die Wirksamkeit von Belohnungen im Mikrozahlungstil zur Verbesserung der Softwaresicherheit bestätigt.
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 leiten einen Kochkurs, in dem die Studierenden ein komplexes, mehrgängiges Menü zubereiten müssen. Üblicherweise bewertet die Lehrkraft sie nur danach, wie lecker das Essen schmeckt und wie ordentlich es angerichtet ist. Sicherheit ist wie der Teil „Lebensmittelsicherheit" in der Küche: Sie lässt das Essen nicht besser schmecken, und wenn Sie es richtig machen, fällt es niemandem auf. Das Essen macht die Leute einfach nicht krank. Da niemand den Nutzen sieht, überspringen die Studierenden oft die Sicherheitsmaßnahmen, um Zeit zu sparen.
Diese Arbeit stellt eine einfache Frage: Was passiert, wenn wir den Studierenden einen besonderen Bonus dafür geben, ihre Küche sicher zu halten?
Das Experiment: Eine Geschichte von zwei Küchen
Die Forscher richteten einen semesterlangen Kochkurs mit 84 Studierenden ein, die in 14 Teams aufgeteilt waren. Sie teilten den Kurs in zwei Gruppen auf:
- Die „Nur-Geschmack"-Gruppe (Kontrollgruppe): Diese Studierenden erhielten die Anweisung: „Erhalten Sie einen Bonus, wenn Sie die Anzahl der unordentlichen, unorganisierten Zutaten (allgemeine Codequalität) in Ihrer Küche reduzieren."
- Die „Sicherheit-zuerst"-Gruppe (Versuchsgruppe): Diese Studierenden erhielten die Anweisung: „Erhalten Sie einen Bonus, wenn Sie die Anzahl der Sicherheitsrisiken (Sicherheitsprobleme) in Ihrer Küche reduzieren."
Um dies zu messen, setzten die Forscher ein Team automatisierter „Kücheninspektoren" (Software-Tools namens Bearer, Detekt und mobsfscan) ein. Diese Inspektoren scannten den Code der Studierenden (die Rezepte) alle paar Wochen, um zu zählen, wie viele Sicherheitsrisiken vorhanden waren.
Der Mechanismus: Der „Sicherheits-Score"
Anstatt nur die Anzahl der Risiken zu zählen, untersuchten die Forscher die Verbesserung.
- Stellen Sie sich vor, ein Student beginnt mit 100 Sicherheitsrisiken.
- Wenn er 50 davon behebt, steigt sein „Sicherheits-Score", und er erhält einen Bonus.
- Entscheidend ist: Sie zählten nicht nur die Gesamtzahl der Risiken, sondern die Risiken pro Zeile des Rezepts. Dies stellte sicher, dass die Teams nicht einfach eine Million Zeilen unordentlichen Codes schreiben konnten, um ihre Probleme zu verbergen. Sie mussten den Code tatsächlich sauberer machen.
Die Ergebnisse: Der Back-End-Bereich vs. der Front-End-Bereich
Die Studie ergab einige faszinierende Ergebnisse, die sich durch eine Analogie „Vorderes Haus" vs. „Hinteres Haus" verstehen lassen:
- Das Vorderhaus (Die App/Schnittstelle): Dies ist der Teil des Restaurants, den die Kunden sehen – die Speisekarte, der Kellner, die Dekoration. Im Experiment war dies die mobile App (geschrieben in Kotlin).
- Das Hinterhaus (Der Server): Dies ist die Küche, der Vorratsraum und die Rohrleitungen. Im Experiment war dies der Server (geschrieben in Java).
Was passierte?
- Die Sicherheitsgruppe gewann: Die Studierenden, die für Sicherheit belohnt wurden, produzierten tatsächlich Code mit deutlich weniger Sicherheitsrisiken als die Gruppe, die für allgemeine Ordnung belohnt wurde.
- Die Küche war sauberer: Das „Hintere Haus" (der Server) in der Sicherheitsgruppe wurde fast makellos. Bis zum Ende des Semesters hatten ihre Server nahezu keine Sicherheitsrisiken mehr.
- Der Speisesaal war immer noch unordentlich: Interessanterweise hatte das „Vordere Haus" (die App) in der Sicherheitsgruppe immer noch einige Risiken, wenn auch weniger als die Kontrollgruppe. Es scheint, dass die Studierenden ihre zusätzliche Anstrengung auf den Server (die Küche) konzentrierten, weil dort die „schwere Arbeit" der Sicherheit stattfand, oder vielleicht, weil sich die Küche als kritischer für das Überleben des Projekts anfühlte.
- Kein Betrug: Die Studierenden schrieben nicht einfach mehr Code, um das Problem zu verwässern. Die Menge des geschriebenen Codes wuchs bei beiden Gruppen im gleichen Tempo. Die Sicherheitsgruppe machte ihren Code einfach besser, nicht nur größer.
Das Fazit
Die Arbeit kommt zu dem Schluss, dass Entwickler, wenn sie eine klare, messbare Belohnung für das Schließen von Sicherheitslücken erhalten, diese tatsächlich beheben werden. Es ist, als würde man einem Koch sagen: „Wenn Sie die Küche auf null Gesundheitsverstöße bringen, erhalten Sie einen Bonus." Der Koch beginnt plötzlich, die Böden zu schrubben und die Kühlschranktemperaturen zu prüfen.
Allerdings stellten die Forscher auch fest, dass dies eine Klasse von Studierenden war und keine professionellen Köche in einem echten Restaurant. Während die Methode im Klassenzimmer funktionierte, schlagen sie vor, zu prüfen, ob sie in der realen Welt mit bezahlten Fachkräften und längeren Projekten funktioniert.
Kurz gesagt: Geld (oder Noten) spricht. Wenn Sie Menschen dafür bezahlen, sicher zu sein, werden sie sicherer, insbesondere in den „Küchen"-Teilen der Software, auch wenn die „Speisesaal"-Teile noch etwas mehr Arbeit benötigen.
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.