Tools zur Sicherheit in der Software-Lieferkette beobachten Angriffe, ohne sie zu verhindern

Wichtigste Erkenntnisse

• Die meisten Tools zur Sicherheit der Software-Lieferkette zeigen Ihnen, was bereits in Ihren Build gelangt ist, und weitaus weniger verhindern von vornherein, dass es überhaupt dorthin gelangt.
• Der Begriff umfasst fünf tatsächlich unterschiedliche Funktionen, und Käufer vergleichen sie regelmäßig so, als würden sie dieselbe Aufgabe erfüllen.
• Der entscheidende Unterschied zwischen ihnen besteht darin, was während der Installation geschieht, und nicht darin, was danach auf dem Dashboard angezeigt wird.
• Zwei Zahlen aus einem Sandbox-Test helfen dabei, eine Vorauswahl schneller einzugrenzen als jede Feature-Matrix, die Ihnen ein Anbieter vorlegt.

Die Sicherheit der Software-Lieferkette ist in diesem Jahr auf der Prioritätenliste der Sicherheitsteams rasch nach oben gerückt, und die Auswahllisten werden immer länger. Wer innerhalb einer Woche drei Anrufe von Anbietern durchsteht, bei denen die Demos langsam alle miteinander verschmelzen. Mehrere Anbieter, mehrere Dashboards, die alle mit anfälligen Abhängigkeiten in demselben übersichtlichen Beispiel-Repo aufleuchten – und keine wirkliche Möglichkeit zu erkennen, welche davon die Kampagnen dieses Jahres hätten verhindern können.

Das ist kein Problem der Käuferkompetenz. Es ist ein Problem der Produktkategorie. Diese Tools erfüllen grundlegend unterschiedliche Aufgaben, bedienen sich dabei jedoch fast identischer Marketingformulierungen, und der Unterschied wird erst deutlich, wenn jemand eine ganz konkrete Frage zum Zeitpunkt stellt.

Warum diese Kategorie plötzlich im Mittelpunkt des Interesses steht

Die Berichterstattung der Analysten folgt den Ausgaben, und die Ausgaben folgen Vorfällen wie diesen. Im Abstand von einer Woche Ende März 2026 wurde ein weit verbreitetes npm-Paket missbraucht, um innerhalb eines Zeitfensters von drei Stunden unbemerkt einen Fernzugriffstrojaner auf jedem neuen Build zu installieren, und ein weit verbreitetes PyPI-Paket wurde so manipuliert, dass es beim nächsten Start von Python Anmeldedaten stahl – in beiden Fällen war keine Benutzeraktion erforderlich. Beide Angriffe waren so konzipiert, dass sie ausgeführt wurden, bevor Scans nach der Auflösung etwas bewirken konnten: der eine während der Installation, der andere beim nächsten Start des Interpreters.

Das ist die Lücke, die die meisten Tools zur Sicherheit der Software-Lieferkette nicht schließen – und genau deshalb ist die Auswahl in dieser Kategorie so schwierig. Die Anbieter vermarkten ihre Produkte anhand völlig unterschiedlicher Kontrollpunkte: Einige führen nachträgliche Scans durch, andere blockieren bereits vor der Installation, verwenden dabei jedoch fast identische Formulierungen, um ihre Funktionsweise zu beschreiben.

Realitätscheck: Nur weil ein Anbieter behauptet, zu dieser Kategorie zu gehören, heißt das noch lange nicht, dass sein Produkt dasselbe Problem löst wie das des Anbieters neben ihm. Fragen Sie genau nach, welchen Kontrollpunkt das Produkt abdeckt, bevor Sie von Überschneidungen ausgehen.

Was Software-Tools für die Sicherheit in der Lieferkette tatsächlich leisten

Unter diesem Label werden fünf verschiedene Funktionen angeboten. Nur wenige Produkte decken alle fünf ab, und die meisten Teams kombinieren letztendlich mehrere davon.

Zusammensetzungsanalyse, SBOMs und Herkunftsnachweis sind die ausgereifteren, besser verstandenen Funktionen, und viele Unternehmen verfügen bereits über Tools, die zumindest einige davon abdecken. Die Überprüfung zum Zeitpunkt der Installation ist der Bereich, in dem die Angriffe des Jahres 2026 tatsächlich stattfanden, und es ist die Funktion, die in den meisten Auswahllisten nie direkt bewertet wird.

Wartung nach Ablauf der Lebensdauer ist das, woran niemand denkt, bis bei einem Audit eine Abhängigkeit auftaucht, deren Betreuer bereits 2021 den Betrieb eingestellt hat.

Der Unterschied zwischen Erkennung und Prävention

Beginnen Sie mit der Funktion, über die fast jedes Team bereits verfügt, da sich hier am deutlichsten erkennen lässt, wo die Erkennung endet und die Prävention beginnt. Die Software-Kompositionsanalyse gleicht Ihre aufgelöste Abhängigkeitsliste mit Beratungsdatenbanken ab. Diese Funktion erfüllt ihre Aufgabe wirklich gut und ist unabhängig davon, welche weiteren Lösungen Sie erwerben, auf jeden Fall empfehlenswert.

Der Haken daran ist, dass die auf Sicherheitshinweisen basierende Erkennung von Schwachstellen erst dann funktioniert, wenn die schädliche Komponente identifiziert wurde und diese Erkenntnis Ihr Tool erreicht hat. Und sie erreicht Ihr Tool erst, nachdem jemand das schädliche Paket gefunden, gemeldet und in einem Feed veröffentlicht hat. Bei den diesjährigen Kampagnen erfolgte die Erkennung oft sehr schnell, während die Pipeline für Sicherheitshinweise noch hinterherhinkte. Im TanStack-npm-Kompromittierung vom 11. Mai 2026 hat der Scanner von Socket die schädlichen Artefakte innerhalb von sechs Minuten nach der Veröffentlichung, und der Angriff wurde 20 bis 26 Minuten nach der ersten bösartigen Veröffentlichung öffentlich gemeldet – von einem externen Forscher, nicht durch die eigenen Tools des betroffenen Projekts. Sechs Minuten sind eine schnelle Erkennung. Dennoch sind es sechs Minuten, in denen ein bösartiges Paket live im Repository verbleibt, von jedem Build aufgelöst werden kann, und es dauerte erheblich länger, bis die meisten Tools über etwas verfügten, mit dem sie es abgleichen konnten.

Überlegen Sie nun, wo der Schadcode tatsächlich ausgeführt wird. Ein npm-Postinstall-Skript wird während des Befehls „npm install“ ausgeführt, und das ist keine theoretische Annahme. Am 31. März 2026 wurde das weit verbreitete Axios-Paket kompromittiert , als Angreifer ein gekapertes Konto des Betreuers nutzten, um zwei bösartige Versionen zu veröffentlichen, die jeweils unbemerkt eine manipulierte Abhängigkeit namens „plain-crypto-js“ enthielten. Deren „postinstall“-Skript fungierte als plattformübergreifender Dropper für einen Remote-Access-Trojaner (RAT) und lud plattformspezifische Payloads von einem aktiven Command-and-Control-Server herunter. Jeder, der während dieses Zeitfensters eine Neuinstallation durchführte, zog den RAT direkt in seinen Build ein – ganz ohne „import“-Anweisung.

Ein PyPI-Paket, das die .pth-Start-Hooks missbraucht, wird beim nächsten Start des Interpreters ausgeführt, und der LiteLLM-Vorfall ist das deutlichste Beispiel dafür. Am 24. März 2026 wurde festgestellt, dass zwei Versionen des Python-Pakets „litellm“ auf PyPI Schadcode enthielten, nachdem eine kompromittierte Version des Trivy-Sicherheitsscanners, der bereits in der CI/CD-Pipeline von LiteLLM im Einsatz war, die PyPI-Veröffentlichungszugangsdaten des Projekts offengelegt hatte. Beide Versionen enthielten eine Payload, wobei die zweite noch einen Schritt weiter ging: Sie installierte eine .pth-Datei, die bei jedem Start des Python-Interpreters automatisch ausgeführt wurde und eine Payload zum Diebstahl von Zugangsdaten auslöste, ohne dass ein expliziter Import erforderlich war.

Ein Rust-Crate mit einer bösartigen `build.rs`-Datei wird während der Kompilierung ausgeführt – derselbe Konstruktionsfehler, nur in einem anderen Ökosystem. In jedem Fall wird der bösartige Code ausgeführt, bevor die Anwendungslogik zum Einsatz kommt: während der Installation, während der Kompilierung oder automatisch beim nächsten Start der Laufzeitumgebung.

Bei einem Scanner, der sich nur um die Auflösung oder die Installation kümmert, gibt es keine sinnvolle Zeitspanne zwischen dem Eintreffen der Abhängigkeit und deren Ausführung. Der Scan selbst ist nicht langsam. Er findet lediglich auf der falschen Seite des Ereignisses statt.

Achtung: Wenn bei einer Anbieter-Demo das schädliche Paket in einer Liste der Fundstellen auftaucht, haben Sie gerade eine Erkennung gesehen, keine Prävention. Bitten Sie den Anbieter, denselben Test mit Überwachung des ausgehenden Netzwerkverkehrs zu wiederholen und Ihnen zu zeigen, ob die Payload eine Verbindung nach Hause hergestellt hat, bevor diese Fundstelle überhaupt angezeigt wurde.

Die Überprüfung am Ort der Auflösung ist eine der wenigen Kontrollmaßnahmen, die noch vor der Ausführung zum Zeitpunkt der Installation stattfindet, und genau das ist die Konzeption hinter SecureChain for OSS. Pakete werden aus geprüften Quellen mit SLSA-Level-3-Herkunftsnachweis neu erstellt, signiert und in einem einzigen Register veröffentlicht, auf das Sie Ihren bestehenden Paket- oder Repository-Manager verweisen. Somit ist die Prüfung bereits abgeschlossen, wenn ein Build-Agent das Paket anfordert.

Die Herkunftsangabe allein schließt diese Lücke nicht. Die bösartigen TanStack-Versionen wurden über die projektinterne Release-Pipeline unter der vertrauenswürdigen Identität des Projekts veröffentlicht und stellen den ersten dokumentierten Fall dar, in dem bösartige npm-Pakete eine gültige SLSA-Herkunftsangabe aufweisen. Die Herkunftsangabe belegt, wo ein Artefakt erstellt wurde. Sie sagt jedoch nichts darüber aus, ob die in diesen Build eingeflossenen Komponenten überprüft wurden – weshalb das Neuaufbauen aus verifizierten Quellen eine separate Kontrollmaßnahme darstellt und nicht mit der Herkunftsangabe gleichzusetzen ist.

Ein Vergleich von Snyk, Socket und der Überprüfung auf Registry-Ebene

Vier architektonische Ansätze dominieren derzeit die Auswahllisten der Anbieter von Lösungen für die Lieferkettensicherheit. Da sich die einzelnen Produkte erheblich voneinander unterscheiden, sollten Sie dies eher als Orientierungshilfe auf Kategorieebene betrachten und nicht als detaillierte Prüfung jeder einzelnen Funktion. Ein reiner Vergleich von SCA-Tools allein wird die Unterschiede nicht deutlich machen, da die eigentliche Unterscheidung in den Kontrollpunkten liegt und nicht in einer Checkliste von Funktionen.

Snyk verfolgt größtenteils den SCA-Scanner-Ansatz. Socket kombiniert die verhaltensbasierte Paketanalyse mit einer Blockierung bereits bei der Installation durch die „Socket Firewall“, die den Datenverkehr des Paketmanagers proxyiert und als bösartig bestätigte Pakete stoppt, bevor sie abgerufen werden. Nexus Firewall und JFrog Curation verfolgen den Repository-Firewall-Ansatz. Kuratierte und neu kompilierte Registries stellen ein kleineres Feld dar, da das Neukompilieren von Paketen aus dem Quellcode im Registry-Maßstab ein wesentlich anderes technisches Modell erfordert als die richtlinienbasierte Überprüfung. Es ist der Ansatz SecureChain für OSS aufgebaut ist: aus dem Quellcode neu kompilierte Pakete, die auch dann noch gepatcht werden, wenn der Upstream-Entwickler nicht mehr aktiv ist, sowie sechs Ökosysteme – JavaScript, Python, Java, Go, Rust und PHP –, die über ein einziges Repository abgedeckt werden.

Keiner dieser vier Ansätze geht näher darauf ein, was passiert, wenn der Betreuer eines Pakets nicht mehr zur Verfügung steht. Das ist ein eigenständiger Bereich, der unabhängig davon, für welchen Ansatz man sich entscheidet, zusätzlich berücksichtigt werden muss (mehr dazu weiter unten).

Und keiner der vier Ansätze ist an sich die falsche Antwort. Der Fehler besteht darin, zwei Produkte aus demselben Ansatz zu kaufen und davon auszugehen, dass man damit die gesamte Kategorie abgedeckt hat.

Profi-Tipp: Fragen Sie jeden Anbieter, welchem Ansatz er sich seiner Meinung nach zuordnet. Diejenigen, die sofort antworten und ihre eigenen Lücken benennen, sind es wert, ein zweites Mal getroffen zu werden. Prüfen Sie jede Behauptung einer durchgängigen Abdeckung anhand aller vier Ansätze, anstatt sie für bare Münze zu nehmen.

Ein Bewertungsrahmen, den Sie in zwei Wochen umsetzen können

Anbieter-Demos laufen auf bereinigten Beispiel-Repos, was Ihnen im Grunde nichts sagt. Führen Sie stattdessen dies aus.

Woche 1: Erstellen Sie den Testdatensatz. Wählen Sie drei echte Kampagnen aus dem Jahr 2026 aus, die Ökosysteme betreffen, die Sie tatsächlich nutzen. Diese drei decken vier Ökosysteme und drei unterschiedliche Mechanismen ab.

• Der Axios-Hack bei npm: Am 31. März 2026 veröffentlichte ein gehacktes Betreuerkonto einen RAT-Dropper für die Postinstallationsphase.
• Die LiteLLM-Sicherheitslücke auf PyPI: 24. März 2026 – eine bösartige .pth-Datei, die beim Start des Interpreters ausgeführt wird.
• PolinRider über npm, Go, Packagist und Chrome-Erweiterungen: Eine aktive, mit Nordkorea in Verbindung stehende Kampagne, bei der versteckte Malware-Loader in Paketdateien eingebettet werden, um eine Command-and-Control-Verbindung herzustellen und Payloads zum Diebstahl von Anmeldedaten zu platzieren.

Woche 2: Messen Sie zwei Zahlen. Bekanntlich bösartige Versionen werden in der Regel kurz nach ihrer Bekanntgabe entfernt oder unter Quarantäne gestellt, sodass Sie heute nicht mehr genau die Axios- oder LiteLLM-Payloads aus Ihrem Testsatz installieren können. Fragen Sie jeden Anbieter, ob er ein Artefakt zur sicheren Reproduktion bereitstellen kann – oder erstellen Sie Ihren eigenen „Canary“: ein harmloses Paket mit einem Postinstallationsskript, das eine Verbindung zu einem von Ihnen kontrollierten Server herstellt. Installieren Sie es in einer Sandbox-Umgebung und erfassen Sie die Zeit bis zur Blockierung sowie die Zeit bis zur Warnmeldung. Diese beiden Werte unterscheiden die vier oben genannten Ansätze schneller als jede Feature-Matrix, die Ihnen ein Anbieter vorlegt.

Von da an ergibt sich die Entscheidung in der Regel ganz klar.

• Überhaupt keine Blockierung, und die Reaktionszeit liegt unter einer Minute? Dann hast du es hier mit einem Erkennungstool zu tun. Behalte es, aber verwechsle es nicht mit deiner Kontrolle während der Installationsphase.
• Das Paket wird blockiert, bevor es abgerufen oder ausgeführt werden kann, aber es gibt keine verwertbare Warnmeldung? Das ist eine Präventionsmaßnahme, und Sie müssen die Überwachbarkeit für die Reaktion auf Vorfälle sicherstellen.
• Sehen beide Zahlen anständig aus? Prüfen Sie, ob die Blockierung von einem Advisory-Feed abhängt. Ist dies der Fall, ist Ihr Schutzfenster nur so gut wie die Latenz dieses Feeds.
• Der Anbieter lehnt den Sandbox-Test ab? Diese Weigerung ist schon die Antwort.

Ein praktischer Hinweis zum Umfang: Für Teams, die vier oder mehr Paket-Ökosysteme betreiben, können Lücken in der Abdeckung ebenso wichtig sein wie die Tiefe innerhalb eines einzelnen Ökosystems, und PolinRider ist die Kampagne, die dies direkt verdeutlicht. Laut der Analyse von Socket vom 1. Juli 2026 hatten nordkoreanische Akteure, die mit dem „Contagious Interview“-Cluster in Verbindung stehen, 162 bösartige Artefakte in 108 Paketen und Browser-Erweiterungen veröffentlicht, die sich über npm, Go-Module, Packagist und den Chrome Web Store erstreckten, wobei Spuren einer Kompromittierung in 80 Go-Modulen. Die Kampagne ist weiterhin aktiv, und diese Zahlen sind seitdem gestiegen. Zu den kompromittierten Paketen gehörten PHP-Pakete, die unter dem Namespace „sevenspan“ auf Packagist veröffentlicht wurden. Ein Team, das sich auf Kontrollen auf Paketebene stützte, die npm, aber nicht Go abdeckten, hätte für diese 80 Go-Module keinen gleichwertigen Schutz gehabt.

Fragen, die Sie jedem Anbieter auf der Auswahlliste stellen sollten

Sechs Fragen, grob geordnet nach dem Umfang der Informationen, die sie preisgeben.

1. Was genau passiert bei einem „npm install“ oder „pip install“, insbesondere bevor ein Scan ausgeführt wird?
2. Prüfen Sie die Pakete vor der Auflösung oder analysieren Sie sie danach?
3. Welche Ökosysteme werden bereits nativ unterstützt, und welche sind noch in Planung?
4. Erstellen Sie Pakete aus dem Quellcode neu oder scannen Sie das vom Upstream veröffentlichte Artefakt?
5. Wie hoch ist die mittlere Latenz zwischen dem Auftreten eines bösartigen Pakets im Upstream und dem Zeitpunkt, zu dem Ihr Produkt dieses tatsächlich blockiert?
6. Was macht Ihr Produkt, wenn ein vorgelagerter Betreuer ein Paket, von dem wir abhängig sind, nicht mehr weiterbetreut?

Frage vier ist wichtiger, als ihre Position auf der Liste vermuten lässt. Durch das Scannen eines veröffentlichten Artefakts lässt sich zwar bösartiger Code darin aufspüren, doch lässt sich damit nicht nachweisen, dass das Artefakt tatsächlich der Quelle entspricht, aus der es angeblich erstellt wurde, da der Scanner stets nur das Artefakt selbst sieht. Erst die Neuerstellung aus einer verifizierten Quelle mit vertrauenswürdiger Herkunft schließt diese spezifische Lücke – und das ist ein echter technischer Aufwand, keine bloße Abhakaufgabe.

Frage Nummer sechs ist die Frage, die während einer Bewertung niemand stellt, die aber achtzehn Monate später jeder stellt. Das weitere Patchen von Paketen, von denen sich der Upstream-Entwickler abgewendet hat, ist eine ganz andere Disziplin als die Überprüfung neuer Installationen, und weitaus weniger Produkte behandeln beides als ein und dasselbe Problem.

Die meisten Abhängigkeiten in einem typischen Projekt sind eher transitiv als direktund werden indirekt durch die von Ihnen tatsächlich ausgewählten Pakete eingebracht. Das macht den Großteil des Abhängigkeitsgraphen aus, was bedeutet, dass Ihre Bewertung prüfen muss, was jedes Tool mehrere Ebenen tiefer tut, und nicht nur an der Spitze Ihres Manifests.

Ihre Ergebnisse hängen stark von der Struktur Ihres Stacks ab. Ein Unternehmen, das nur eine Sprache verwendet und über eine streng geregelte CI verfügt, ist eine ganz andere Situation als eine mehrsprachige Organisation, die vierzig Repos betreibt und kein zentrales Plattformteam hat – und jeder Anbieter, der für beide Fälle dieselbe Empfehlung ausspricht, hat Ihnen nicht genügend Fragen gestellt.

Was das für Sie bedeutet

Es geht hier nicht darum, einen Sieger zwischen Snyk, Socket und den Anbietern von Registry-Firewalls zu küren. Es geht darum, zu wissen, für welchen Ansatz man sich entscheidet, und sich selbst gegenüber ehrlich zu sein, welcher Ansatz einem dabei fehlt.

Viele Organisationen verfügen bereits über eine gewisse Abdeckung der ausgereiften Funktionen. Kompositionsanalyse, SBOM -Tools und Provenienz sind mittlerweile gut verstanden, und was Sie in diesen Bereichen bereits besitzen, ist keine Verschwendung. Die Kontrollmaßnahme, die es ausdrücklich zu prüfen gilt, ist die Überprüfung zum Zeitpunkt der Installation – also die Frage, ob irgendetwas in Ihrem Stack ein risikobehaftetes Paket stoppen kann, bevor dessen Code ausgeführt wird. Das ist die Lücke, durch die die Kampagnen von 2026 ungehindert hindurchgingen, und kein noch so gutes Dashboard voller Befunde wird sie schließen können, egal wie gut diese Befunde auch sein mögen.

Führen Sie den zweiwöchigen Test durch. Sollte dabei bei der Installation eine echte Sicherheitslücke aufgedeckt werden, ist dies der Kontrollpunkt, dessen Finanzierung als Nächstes in Betracht gezogen werden sollte. SecureChain für OSS überprüft Pakete vor der Auflösung in JavaScript, Python, Java, Go, Rust und PHP und sorgt auch nach Ablauf des Upstream-Supports für die Aufrechterhaltung der Sicherheit. Der erste Teil davon ist die Abdeckung bei der Installation, die bei den meisten Vorauswahlen übersehen wird.

Erfahren Sie mehr über SecureChain → 

FAQs

Was sind Tools zur Sicherheit der Software-Lieferkette?

Produkte, die Risiken minimieren, die durch Code von Drittanbietern in den Phasen Entwicklung, Build, Vertrieb und Produktion entstehen. Diese Kategorie umfasst die Analyse der Softwarezusammensetzung, das SBOM-Management, die Herkunftsüberprüfung, die Überprüfung bei der Installation sowie die Wartung von Paketen nach Ablauf der Lebensdauer (EOL) – fünf verschiedene Aufgabenbereiche, die in der Regel unter einem gemeinsamen Begriff vermarktet werden.

Ist SCA dasselbe wie die Sicherheit der Software-Lieferkette?

Nein (und genau hier liegt der Fehler bei den meisten Vergleichen von SCA-Tools). Die Software-Kompositionsanalyse ist nur eine Funktion innerhalb dieser Kategorie. Sie kennzeichnet Komponenten im aufgelösten Abhängigkeitsgraphen, die als anfällig bekannt sind, doch dies allein stellt noch keine Kontrolle zum Zeitpunkt der Installation gegen ein neu auftauchendes schädliches Paket dar.

Sollen wir uns für Snyk oder Socket entscheiden?

Für den vorliegenden Vergleich steht Snyk Open Source für den auf Empfehlungen basierenden Ansatz zur Kompositionsanalyse, während Socket die verhaltensbasierte Paketanalyse zum Zeitpunkt des Pull-Requests mit einer Blockierung bei der Installation durch die Socket Firewall kombiniert. Teams, die eine der beiden Lösungen evaluieren, sollten genau prüfen, welche Ebene (PR-Prüfung, Installationszeit oder beides) auf ihren Stack zutrifft, bevor sie von einer vollständigen Abdeckung ausgehen.

Was sollte auf einer Checkliste zur Bewertung der Sicherheit der Software-Lieferkette stehen?

Umfang des Ökosystems, Zeitplanung der Kontrollpunkte, ob Pakete aus dem Quellcode neu kompiliert oder lediglich als veröffentlichte Artefakte gescannt werden, Feed-Latenz, Tiefe der transitiven Abhängigkeiten und was passiert, wenn ein Upstream-Betreuer die Betreuung eines Pakets aufgibt.

Gibt uns das Kategorie-Ranking eines Anbieters Aufschluss darüber, welches Tool wir kaufen sollten?

Es gibt Aufschluss darüber, ob ein Analyst oder eine Bewertungsplattform genügend oberflächliche Überschneidungen festgestellt hat, um Anbieter anhand gemeinsamer Bewertungskriterien zu vergleichen. Es gibt jedoch keinen Aufschluss darüber, welcher Kontrollpunkt in Ihrer eigenen Architektur fehlt – und genau das ist doch die Frage, die Sie eigentlich beantworten möchten.

Zusammenfassung

Artikel Name

Tools zur Sicherheit der Software-Lieferkette und die Lücke, die sie übersehen

Beschreibung

Die meisten Tools zur Sicherung der Software-Lieferkette erkennen Angriffe erst nach der Installation. Vergleichen Sie die vier Ansätze und testen Sie die in die engere Wahl gekommenen Lösungen innerhalb von zwei Wochen.

Autor

Artem Karasev

Name des Herausgebers

TuxCare

Logo des Herausgebers