Sicherheit für die Software-Lieferkette

Wie verwundbar Lieferketten sein können, hat die Corona-Pandemie nur allzu deutlich gemacht. Nicht weniger stark ist der Fokus dabei auch auf die Lieferkette von Software gerückt, nachdem Arbeits- und Geschäftsleben seither in zunehmendem Maße im Online-Raum stattfinden. Entsprechend unabdingbar ist der Schutz von Software-Lieferketten vor böswilligen Akteuren, die durch Exploits oder Hacks auf darin enthaltene Schwachstellen abzielen. Denn neben dem Risiko der Kompromittierung personenbezogener Daten, finanzieller Verluste oder Strafzahlungen können damit im schlimmsten Fall auch irreparable Schäden der Markenreputation einhergehen.

Was Sicherheit in der Software-Lieferkette genau bedeutet, warum sie so wichtig ist und wie Sie Ihre Lieferketten mit Snyk durchgängig absichern, das alles beleuchten wir im Folgenden im Detail.

Die meisten Software-Produkte, die wir im Alltag einsetzen, stützen sich heute auf Open-Source-Code und andere Komponenten aus externen Quellen. Sie stammen also von Entwicklern oder Anbietern, die nicht zu dem Hersteller gehören, von dem wir die Software erwerben oder dessen Markenname seine Website schmückt. Die Nutzung solcher Elemente macht zwar deutlich schnellere Dev-Cycles möglich, als sie komplett neu in Eigenregie zu entwickeln. Zugleich ist damit aber auch eine ganze Bandbreite an Sicherheitsrisiken verbunden. Genau deshalb gilt es, die Software-Lieferkette adäquat abzusichern.

Relevant ist dabei nicht nur die Evaluierung der Sicherheit aller externen Software-Komponenten und Open-Source-Bibliotheken, die in den Dev-Prozess einfließen. Ebenso ist zu gewährleisten, dass sie frei von Schwachstellen, Malware oder anderen Cyber-Bedrohungen sind. Es geht also darum, Sicherheit für die Software-Lieferkette auf eine umfassende Methodik zum Schutz von Integrität und Vertraulichkeit zu stützen, die an jedem Punkt des Lifecycle eines Software-Produkts greift.

Sicherheit in der Software-Lieferkette als Kernprämisse

Bedrohungen für die Software-Lieferkette sind alles andere als ein abstraktes Problem. Deutlich macht dies etwa ein Report aus dem Jahr 2022, demzufolge in einem Zeitraum von drei Jahren eine Zunahme der Angriffe auf Software-Lieferketten um 742 % verzeichnet wurde. Nicht weniger besorgniserregend sind zudem Incidents wie die Folgenden, die in der jüngeren Vergangenheit für besonders großes Aufsehen gesorgt haben:

• SolarWinds-Hack: Im Dezember 2020 wurde ein Einbruch in das Netzwerk des Software-Anbieters SolarWinds bekannt, der Enterprise-Kunden mit IT-Management-Lösungen ausstattet. Mutmaßlich im Auftrag der russischen Regierung schleuste eine Hackergruppe dabei Malware in ein Software-Update von SolwarWinds ein, die auf diesem Wege in die Netzwerke tausender seiner Kunden gelangte – darunter Regierungsstellen ebenso wie Unternehmen aus dem privaten Sektor.

• Operation ShadowHammer: 2019 wurde ASUS Opfer eines Angriffs, bei dem Hacker Software-Updates für die Desktops und Laptops des taiwanischen Herstellers kompromittierten und so eine Malware namens ShadowHammer an nicht weniger als eine Millionen Nutzer auslieferten. 

• Huawei: Der US-Regierung zufolge bestehen enge Verbindungen zwischen Huawei und den chinesischen Behörden. Demnach bestünde das Risiko, dass die Software des chinesischen Smartphone-Herstellers und Netzwerkausrüsters auf den Systemen seiner Kunden für Spionage und andere schädliche Zwecke genutzt werden könnte.

Lesen Sie für weitere Insights zu Incidents wie diesen unseren Guide zu Angriffen auf die Software-Lieferkette.

Sicherheit in der Software-Lieferkette hilft dabei, Cyberangriffe abzuwehren und ihre Auswirkungen in Grenzen zu halten Noch besser aber: Durch sie lässt sich auch vermeiden, dass die für einen Angriff ursächliche Schwachstelle überhaupt erst in Ihre Anwendung gelangt. Voraussetzung hierfür sind starke Maßnahmen, die Software-Entwicklung und -Deployment gleichermaßen vor der Einbindung schädlicher oder kompromittierter Komponenten wie Malware, Schwachstellen und anderen Bedrohungen schützen. Zu einer sicheren Lieferkette gehört außerdem die Erfüllung gesetzlicher und branchenspezifischer Standards, durch die zugleich auch die Aspekte Datenschutz und Vertraulichkeit in der Entwicklung wie auch im Deployment eines Software-Produkts belegt werden.

Tatsächlich ist die Thematik von so grundlegender Bedeutung, dass sie etwa in den USA inzwischen zur Angelegenheit der nationalen Sicherheit geworden ist: Im September 2022 erließ Präsident Joe Biden dazu Verordnung M-21-30, die für Software, die für den Verkauf an Stellen der US-Regierungsstellen vorgesehen ist, einen Sicherheitsnachweis gemäß den Leitlinien der US-Standardisierungsbehörde NIST vorsieht. Erforderlich sind hierzu folgende Angaben:

• Name des Software-Herstellers

• Name des Software-Produkts

• Erklärung des Herstellers oder der ihn beauftragenden Regierungsstelle betreffend der Umsetzung sicherer Prozesse der Software-Entwicklung

Wodurch ist ein Angriff auf die Software-Lieferkette charakterisiert?

Ausgangspunkt hierfür ist eine Schwachstelle innerhalb der Lieferkette der Software-Entwicklung. Diese wird dann von Angreifern als Einfallstor genutzt, um Schadcode oder Malware in die Software einschleusen. Erfolgen kann dies einmal in der Entwicklung, genauso aber auch beim Testing oder in der Phase der Auslieferung oder Installation der Software. Hat die Malware erst einmal ihren Weg in die Software gefunden, können die Drahtzieher sie aktivieren, um so etwa Computing-Ressourcen zu kapern, sensible Daten abzugreifen, Ausfälle auszulösen oder Kontrolle über kompromittierte Systeme zu erhalten. 

Ausgenutzt werden Schwachstellen in der Lieferkette über verschiedene Verfahren und Taktiken. Auch Vektoren genannt, gehören dazu u. a. die Folgenden:

• Komponenten aus externen Quellen: Komponenten wie Programmbibliotheken oder Frameworks, auf die Entwickler aus externen Quellen zurückgreifen, leuchten böswillige Akteure auf Wege aus, über die sich Malware in die Software einschleusen lässt.

• Kompromittierte Dev-Tools: Im Visier der Angreifer stehen hier Compiler, Build-Systeme und andere Tools zur Software-Entwicklung, die sie ebenfalls als Vehikel zur Einschleusung von Malware zu nutzen versuchen.

• Kompromittierte Konten von Entwicklern: Hierbei geht es Exploits gegen Schwachstellen in Benutzerkonten für GitHub oder andere Plattformen, die Entwickler zum Code-Sharing nutzen.

• Kompromittierte Infrastruktur für Software-Updates: Entsprechende Infrastruktur ist ein häufiges Angriffsziel, da sich Malware darüber besonders effektiv verbreiten lässt. So etwa auch bei der bereits genannten Operation ShadowHammer.

• Social Engineering: Der Weg führt hier über die direkte Kontaktaufnahme mit Mitarbeitern oder Entwicklern. Anhand verschiedener Taktiken versuchen böswillige Akteure dabei, das Vertrauen der Betroffenen zu gewinnen und sie so dazu zu bewegen, ihnen Zugang zu sensiblen Daten oder Systemen zu gewähren.

4 Best Practices gegen Angriffe auf die Software-Lieferkette

Ganz gleich, ob Unternehmen Software selbst entwickeln oder vom Markt beziehen, bleibt die Absicherung der zugehörigen Lieferkette stets oberste Prämisse – bei Software für den internen genauso wie solcher für den externen Einsatz. Bestmöglich verringern lässt sich das Risiko eines Angriffs auf die Software-Lieferkette dabei anhand der nachfolgenden vier Best Practices, die Sie direkt umsetzen können (und sollten): 

1. Unterbinden von Dependency Confusion

2. Keine unkoordinierten Installationsanweisungen durch Open-Source-Pakete

3. Multi-Faktor-Authentifizierung in der gesamten Software-Lieferkette

4. Sensible Daten: immer unter Verschluss

1. Unterbinden von Dependency Confusion

Dependency Confusion ist ein Angriffsvektor, der böswilligen Akteuren einen besonders einfachen Weg bietet, Exploits gegen Schwachstellen in der Software-Lieferkette von Unternehmen zu fahren. Schutzlos ausgeliefert sind Sie dem jedoch nicht – wenn Sie folgende Maßnahmen umsetzen:

• Eingegrenzter Namespace: Bei sogenannten „Scoped Packages“ ist der Paket-Namespace festgeschrieben und kann spezifisch nach Benutzer/Organisation zugewiesen werden. Dependency Confusion wird so ein Riegel vorgeschoben, da das ursprünglich vom Nutzer definierte Paket nicht mehr upstream durch ein anderes ersetzt werden kann. 

• Upstream-Registries allesamt durch jeweils eigene Konfiguration definieren: Paket-Manager wie pip oder npm sind so angelegt, dass sie den Abruf paketbezogener Informationen automatisch ausführen, wenn keine spezifischen Definitionen vorliegen. Ohne diese durchsuchen sie in der Regel öffentliche Registries (z. B. npmjs oder PyPi) nach neuen Versionen eines Pakets und rufen so potenziell ein Schadpaket ab. Bei Nutzung interner Paket-Repositories bzw. Proxies wie Artifactory oder Verdaccio müssen Sie also unbedingt unterbinden, dass diese Abfragen privater Pakete gegen solche ersetzt werden, die auf öffentliche Registries lauten.

Zur Umsetzung der genannten Gegenmaßnahmen hat npmjs-Mitgründer Isaac Schlueter eine Reihe detaillierter Beispiele und Empfehlungen zur Konfiguration zusammengestellt. Orientierungshilfen zur Mitigierung dieser Art von Angriffen innerhalb der Software-Lieferkette finden Sie außerdem auch in diesem Whitepaper von Microsoft.

2. Keine unkoordinierten Installationsanweisungen durch Open-Source-Pakete

Bei einigen Paket-Managern, darunter auch npm, wird die Installation oder Deinstallation beliebiger Pakete zugelassen. Gleiches gilt für die Ausführung beliebiger Befehle – eine Standardeinstellung, die bereits von diversen Schadpaketen ausgenutzt wurde. Ebenso kann der Angriff aber auch mittels Typosquatting erfolgen. Ausgelöst wird die Installation eines Schadpakets dabei via Dependency Tree oder einen fälschlicherweise vom Nutzer eingegebenen Namen in der Kommandozeile. 

Die Krux hierbei ist, dass ebensolche Falscheingaben leichter passieren, als man vielleicht denkt. Oder wüssten Sie beispielsweise bei den folgenden beiden direkt, welches das legitime Paket und welches der Übeltäter ist?

coffeescript

cofeescript

In jedem Fall dürfte dies deutlich machen, wie schwierig die Angriffsvektoren für Dependency Confusion auszumachen sind. Daher gilt es, bei Paketen grundsätzlich Kontrolle vor Vertrauen walten zu lassen: Installieren Sie sie niemals ungeprüft oder binden sie einfach via Copy+Paste ein. Äußerst nützlich ist hierbei außerdem der Snyk Advisor, mit dem Sie die Paket-Health ermitteln können.

Was ist Dependency Confusion?

Dependency Confusion ist ein Angriffsvektor, der sich mit besonders wenig Aufwand ausnutzen lässt, und entsprechend auch zu den gängigsten zählt. Ins Visier nehmen Angreifer dabei Schwachstellen, die in Unternehmen im Hinblick auf ihren Umgang mit Software-Abhängigkeiten bestehen. Hierzu führen sie einen Upload schädlicher Versionen von Open-Source-Paketen in öffentlich verfügbare Paket-Manager (npm oder PyPI) aus, die sie so benennen, dass sie dem Namen legitimer Paketen ähneln – eine Technik, die auch als Typosquatting oder Brandjacking bekannt ist. Verwechseln Entwickler nun die Namen, führen sie unbewusst ein Upgrade mit dem Schadpaket aus oder installieren es und infizieren so ihre Systeme.

3. Multi-Faktor-Authentifizierung in der gesamten Software-Lieferkette

Die Open-Source-Community hat uns alle näher zusammenwachsen lassen – und damit auch engere Verbindungen als je zuvor geschaffen. Umso mehr gilt es daher, dass alle miteinander wie mit der Software vertrauenswürdig umgehen, die wir jeweils verwalten. Eine zunehmend wichtige Säule hierfür bilden adäquate Authentifizierungsmechanismen. So würde man gerade aufseiten von Entwickler wohl am ehesten den Einsatz von Zwei-Faktor-Authentifizierung erwarten, sollten sie die Risiken doch am besten kennen, die mit dem Fehlen solcher Mechanismen einhergehen. Die Realität, so scheint es, sieht jedoch etwas anders aus. 

Denn wie aus einem im Januar 2020 veröffentlichten Bericht hervorgeht, nutzen noch nicht einmal 10 % der Entwickler 2FA auf npmjs – obwohl das Feature bereits seit 2017 verfügbar ist. 

Nicht nur vor diesem Hintergrund legen wir Entwicklern wie auch allen anderen, die in einer Software-Umgebung tätig sind, dringend nahe: Wenden Sie stets die bestmöglichen verfügbaren Sicherheitsmechanismen auf sämtliche Accounts der Registries und Dev-Ökosysteme an, die Sie nutzen. Ganz gleich, ob für npmjs, RubyGems, Docker oder GitHub sollten Sie daher in jedem Fall Multi-Faktor-Authentifizierung implementieren.

4. Sensible Daten: immer unter Verschluss

Infolge der ausgedehnten Nutzung von Open-Source-Software ist Zusammenarbeit zwischen Entwicklern und Beitragenden auf öffentlichem Parkett heute quasi die Regel. Positiv ist dies für Innovation, zugleich birgt es aber auch das Risiko, dass vertrauliche Informationen ungewollt preisgegeben oder anderweitig öffentlich gemacht werden. Und dass es allerhöchstens unter größtem Aufwand möglich ist, ihre Veröffentlichung wieder rückgängig zu machen, dürfte klar sein. Daher ist Prävention hier oberstes Gebot, dies anhand folgender Maßnahmen. 

• Legen Sie in keinem Fall vertrauliche Daten in Repositories, Konfigurationen oder Code ab. Wie Sie in diesem Zusammenhang am sichersten fahren, haben wir in unseren 10 Security Best Practices für GitHub zusammengefasst.

• Halten Sie Pakete oder Container-Images, die potenziell vertrauliche Informationen beinhalten und ihren Weg in öffentliche Registries finden könnten, grundsätzlich unter Verschluss. Unsere 10 Security Best Practices für npm bieten in diesem Kontext nützliche Hinweise dazu, wie Sie .npmignore korrekt konfigurieren.

In ganzer Tiefe beleuchten wir das Thema außerdem in unserer Videopräsentation zur Risikomitigierung in der Lieferkette.

Vom Dreigespann aus Sicherheit für die Lieferkette, AppSec und DevSecOps

Konzeptionell hat Sicherheit für die Lieferkette wie auch AppSec bzw. Anwendungssicherheit und DevSecOps zum Ziel, Komponenten und Systeme zur Entwicklung, Auslieferung und Wartung von Software abzusichern. Unterschiede bestehen hierbei nur perspektivisch: 

• Sicherheit für die Lieferkette: Software und Komponenten, die in der Entwicklung und Auslieferung eines Produkts zum Einsatz kommen, werden dahingehend untersucht, ob sie aus vertrauenswürdigen Quellen stammen und frei von Schwachstellen sind.

• AppSec: Neben dem Software-Produkt selbst geht es hierbei um die Absicherung der Systeme, auf denen es ausgeführt wird, sowie den Schutz der Daten, die es verarbeitet. 

• DevSecOps: Hierbei steht die Integration von Sicherheitsthemen in den Prozess der Software-Entwicklung im Fokus. Security-Teams bringen ihre Prozesse dabei bereits in die Frühphasen von Entwicklung, Testing und Deployment ein, damit potenzielle Sicherheitsprobleme so proaktiv wie möglich und nicht erst im Nachgang adressiert werden.

Sicherheit in der Lieferkette ist also als Verbundelement zu AppSec und DevSecOps anzusehen, aus dem ein Dreigespann zur Stärkung der Sicherheit eine Software-Produkts oder -Systems entsteht.

Mehr Sicherheit in der Lieferkette durch Automatisierung

Effizient lassen sich die Prozesse und Aufgaben zur Absicherung der Software und Komponenten, die für die Entwicklung und Auslieferung von Software-Produkten zum Einsatz kommen, durch Automatisierung bewerkstelligen. So trägt sie zur Stärkung des Cybersecurity-Status bei, da mit ihrer Hilfe nicht nur Bedrohungen effizienter und effektiver aufgedeckt und abgewehrt, sondern auch Sicherheitskontrollen über sämtliche Systeme und Komponenten hinweg konsequent umgesetzt werden. Dies wiederum reduziert das Risiko menschlicher Fehler.

Ansatzpunkte zur Automatisierung bieten dabei folgende Security-Prozesse innerhalb der Lieferkette:

• Schwachstellen-Scans: Passende Tools hierfür leuchten Software und Komponenten aus externen Quellen automatisch auf Schwachstellen und andere Bedrohungen aus. Ergänzend dazu wenden diese idealerweise auch Custom-Policies von Securitiy-Teams an, durch die kritische Risikoherde effektiv angegangen und Alerts zu diesen ausgegeben werden, um sie aus Anwendungen fernzuhalten.

• Management von Abhängigkeiten: Tracking und andere mit Abhängigkeiten verbundene Prozesse können Tools übernehmen, die Bibliotheken, Frameworks etc. erfassen und Entwickler via Alert darauf aufmerksam machen, wenn eine dieser Komponenten bekannte oder neu veröffentlichte Schwachstellen aufweist.

• Analyse der Lieferkette: Hierbei lässt sich die Analyse von Elementen innerhalb der Lieferkette auf potenzielle Sicherheitsrisiken wie nicht vertrauenswürdige Komponenten externer Quellen untersuchen.

• Management von Konfigurationen: Anhand automatisierter Tools kann die Umsetzung sicherheitsbezogener Systemkonfigurationen etwa für Software, Server und Cloud-Ressourcen automatisch erzwungen werden.

Starker Schutz vor Angriffen auf Ihre Software-Lieferkette mit Snyk

Mit Snyk bringen Sie Sicherheit proaktiv in Ihre Lieferkette. Hierzu erhalten Sie ein umfassendes Toolset, mit dem Sie anfällige oder Schadpakete erkennen, das passende Fixing einsteuern und ihnen einen Riegel vorschieben, bevor sie in Ihre Codebase gelangen – ganz gleich, ob über die Open-Source-Pakete oder Container, die Sie zur Umsetzung Ihrer Anwendungen einbinden. 

Open-Source-Sicherheit

Unsere Experten haben den Finger stets am Puls potenzieller Bedrohungen im Open-Source-Kontext, veröffentlichen ihre Erkenntnisse verantwortungsvoll und überführen diese zusammen mit adäquaten Lösungsansätzen in unsere Tools. Open-Source-Abhängigkeiten in Ihrer Codebase leuchten Sie damit präzise auf Schadpakete aus und beseitigen sie effektiv. So haben wir etwa allein im Jahr 2020 mehr als 700 Schadpakete in Open-Source-Registries aufgedeckt. 

Wie aktiv unser Team nicht nur beim Aufspüren von Schadpaketen, sondern auch bei der Erarbeitung von Strategien für ihre Abwehr ist, machen diverse Beispiele deutlich. Hierzu gehören etwa das als Abhängigkeit in npmjs eingeschleuste Schadpaket electron-native-notify, die Remote-Ausführung von Code über das RubyGem strong_passwords oder etwa auch der Fall von Ad-Fraud und Daten-Leaks durch die SourMint-Malware, von der tausende Mobile-Apps über ein infiziertes SDK befallen waren.

Probleme wie diese decken Sie mit Snyk anhand von Scans der Manifest-Dateien Ihrer Pakete auf. Die Ergebnisse visualisiert die Lösung dann in einer umfassenden Baumstruktur aller Pakete, die in Ihre jeweilige Anwendung eingebunden sind – einschließlich all jener aus dem komplexen Geflecht aus transitiven Abhängigkeiten, die darin verschachtelt sind. Sämtliche Abhängigkeiten werden dann mit der Snyk Vulnerability Intelligence Datenbank abgeglichen. Wird dabei eine Referenz auf ein als schädlich bekanntes Paket festgestellt, schlägt die Lösung Alarm, markiert es als Schwachstelle und gibt Vorschläge für passende Behebungsmaßnahmen. 

Abhängig davon, wie Sie Snyk in Ihr SDLC integrieren, lässt sich auch die Einbindung von schädlichen Paketen oder Container-Base-Images automatisiert unterbinden. Hierzu erzwingt die Lösung den Abbruch des Build- oder CI-Vorgangs und versendet passend zu Ihrem jeweiligen Workflow entweder eine Benachrichtigung oder öffnet ein Jira-Ticket.

Software-BOM

Eine Software Bill of Materials bzw. SBOM ist eine formelle Bestandsaufnahme der Komponenten, die in die in Entwicklung eines Software-Produkts einfließen, sowie davon, wie diese innerhalb der Lieferkette in Zusammenhang stehen. So eignet sich eine SBOM ideal, um Schwachstellen noch in den Frühphasen der Software-Produktion aufzudecken und Eintrittswege für Bedrohungen von vornherein zu schließen.

Mit Snyk lassen sich sämtliche Open-Source-Komponenten und -Abhängigkeiten, die in einer Software zum Einsatz kommen, ganz einfach automatisch in einer SBOM erfassen. Dabei ist ein Scan dieser Komponenten auf Schwachstellen mit unserer Lösung für Sicherheit in der Software-Lieferkette ebenfalls direkt möglich, die bei Erkennung zudem konkret umsetzbare Empfehlungen für ihre Behebung gibt. Was bei der Generierung einer SBOM im Einzelnen zu beachten ist und wie genau sie erfolgt, haben wir in diesem Artikel für Sie zusammengefasst.

Container-Sicherheit

Mit den Tools von Snyk wird es möglich, Pakete innerhalb von Containern zu scannen – unabhängig davon, ob sie aus Base-Images übernommen wurden oder anhand nutzerseitiger Anweisungen über Linux Paket-Manager installiert wurden. Snyk Container erkennt, ob die entsprechenden Base-Images oder darin enthaltene Pakete (oder Abhängigkeiten) Schwachstellen aufweisen und gibt direkt passende Empfehlungen für ihre Behebung. Für Upgrades von Base-Images auf sicherere Versionen braucht es dabei nicht mehr als einen Klick, bei via Benutzeranweisungen installierten Paketen bietet die Lösung Vorschläge für eine Auswahl sicherer Versionen. Möglich ist darüber hinaus auch Monitoring Ihrer Container-Images auf Schwachstellen, die neu bekannt werden. Via Alert macht Snyk Container Sie darauf aufmerksam, wenn diese in Ihren Image-Deployments erkannt werden, und gibt nach dem gleichen Prinzip wie im klassischen Dev-Workflow Empfehlungen zur Behebung.

Erkannt werden dabei zudem auch Binärdateien, die auf anderem Wege als über einen der diversen Linux Paket-Manager installiert wurden. Sollte also etwa ein besonders unbequemes Paket nicht durch Installation via Paket-Manager in weitläufig genutzte Container-Base-Images gelangt sein, wird es von unserer Lösung dennoch erkannt. Dies ist enorm nützlich, darf dabei aber keinesfalls als Ersatz für Malware-Erkennungssysteme gesehen werden. 

Nächste Schritte

Zur Stärkung der Sicherheit in der Lieferkette gilt es zuallererst, an Risikoherden innerhalb Ihrer eigenen Umgebung anzusetzen. Entsprechend wichtig ist es also, Entwicklungen rund um moderne Konzepte der Software-Entwicklung ebenso zu verstehen wie die Angriffsvektoren, die mit ihnen einhergehen. All diese Kenntnisse gilt es dabei auch sämtlichen Entwicklern in Ihrem Team zu vermitteln, denn erst so lassen sich adäquate Vorkehrungsmaßnahmen auch durchgängig implementieren. 

Dabei unterstützt werden Sie von unseren Teams bei Snyk, die sämtliche Dev-Ökosysteme laufend auf Schadpakete durchleuchten. Und wie unsere Erkenntnisse daraus nahelegen, werden die Problematiken in diesem Kontext auch in Zukunft sicherlich nicht weniger werden. Im privaten wie geschäftlichen Kontext wird Software zudem auch weiterhin eine immer tragendere Rolle spielen und sich somit auch die Bedrohungslage immer weiter verschärfen. Wer dies aber erkennt und entsprechend vorausschauend agiert, wird auch diese Risiken effektiv bewältigen können.

Noch mehr spannende Insights dazu, wie Sie Ihren Cybersecurity-Status stärken, finden Sie in unserem Artikel zur Prävention von Angriffen auf die Lieferkette mit NPM.