Ruby-E-Mail-Regel aus Snyk Code entfernt

Snyk Code unterstützt verschiedene Sprachen, die im Cloud-Native-Umfeld wichtig sind – darunter Ruby (und wir haben eine großartige Akzeptanz festgestellt – vielen Dank!). Unsere Researcher überwachen kontinuierlich unsere Regelsätze. Dafür nutzen sie unseren Trainingsdatensatz aus Open-Source-Projekten, aber auch – ja, das ist ein Vorteil eines SaaS-Dienstes – die Ergebnisse der Regeln im gescannten Code. Zur Erinnerung: Snyk verwendet Ihren Code nicht zum Trainieren unserer Modelle – wir erfassen jedoch Nutzungsstatistiken in aggregierter Form.

In den Ruby-Daten ist uns ein Ausreißer aufgefallen (zu dem wir auch Rückmeldungen von Nutzenden erhalten haben):

Relative Ergebnisse der Regel „HardcodedEmail“ im Verhältnis zu den anderen.

Warum wir die HardcodedEmail-Regel für Ruby entfernt haben

Wir hatten eine Regel, die nach E-Mail-Adressen im Ruby-Code suchte und sie als potenzielles Problem mit niedriger Priorität kennzeichnete. Auch wenn es weiterhin eine Best Practice ist, keine fest codierten E-Mail-Adressen im Code zu speichern, haben wir festgestellt, dass diese Regel oft ignorierte oder nicht behobene Probleme meldete. Wir haben die Zahlen genauer untersucht. Dabei zeigte sich, dass das durch die Regel verursachte Rauschen in keinem Verhältnis zur Nutzung der Empfehlung stand. Deshalb haben wir beschlossen, die Regel zu entfernen. Andere Regeln nutzen Datenflussanalysen, um missbräuchlich verwendete Zugangsdaten oder Passwörter zu finden. In dieser Hinsicht sind wir also weiterhin bestens aufgestellt.

Was bedeutet das für Sie? Wenn Sie Ruby verwenden, dürften Sie schon bald weniger Findings mit niedriger Priorität zu E-Mail-Adressen sehen.

Was lässt sich über die Ruby-Regel hinaus daraus lernen?

Jedes Tool für Static Application Security Testing (SAST) – und allgemein jedes Tool zur statischen Codeanalyse – muss ein Gleichgewicht zwischen Korrektheit (nur echte Sicherheitsprobleme erkennen, dabei aber einige übersehen) und Vollständigkeit (alle denkbaren Probleme erkennen, dabei jedoch viele Fehlalarme erzeugen) finden. Dank der Geschwindigkeit von Snyk Code können wir äußerst hilfreich 120.000 bis 150.000 Projekte pro Programmiersprache als Testsatz verwenden, um dieses Gleichgewicht zwischen Korrektheit und Vollständigkeit zu wahren.

Zusätzlich stehen uns Nutzungsdaten aus der Snyk-App zur Verfügung. Damit optimieren wir das System von Anfang an und kontinuierlich weiter. Dafür gibt es mehrere Gründe:

• Die Umgebung verändert sich ständig: JavaScript ist dafür bekannt, dass alle paar Wochen eine neue angesagte Bibliothek erscheint. Doch Spaß beiseite: In jeder Sprachumgebung kommen ständig neue Bibliotheken hinzu, oder bestehende werden geändert. Mithilfe von Machine Learning lernen wir diese Änderungen automatisch und ergänzen unsere Wissensdatenbank.

• Manche Best Practices werden nicht wirklich befolgt: Es gilt zwar als Best Practice, keine fest codierten E-Mail-Adressen in den Code aufzunehmen, doch wir müssen akzeptieren, dass die Realität davon abweichen kann und es gute Gründe dafür geben kann.

• Neue Arten von Problemen tauchen auf: Erinnern Sie sich an Trojan Source? Das war eine völlig neue Art von Problem, die zuvor noch nie aufgetreten war. Innerhalb weniger Tage konnte das Snyk Code-Team Regeln dafür bereitstellen – in jeder unterstützten Programmiersprache und mit hoher Erkennungsgenauigkeit.

Vielen Dank für Ihr Feedback und Ihre Vorschläge zur Verbesserung des Produkts. Neben datengestützten Entscheidungen sind sie für uns eine wertvolle Informationsquelle. Wir hören zu und reagieren. Falls Sie Snyk Code noch nicht verwendet haben, ist jetzt vielleicht ein guter Zeitpunkt für den Einstieg. Erstellen Sie einfach ein kostenloses Snyk-Konto und erhalten Sie innerhalb von Sekunden Ergebnisse.

Probieren Sie unser kostenloses Tool Ruby code checker aus und sehen Sie, wie die Snyk-Code-Engine Ihren Code auf Sicherheits- und Qualitätsprobleme analysiert.