Die Kompromittierung des npm-Pakets "is" hat hohe Wellen geschlagen und etliche Softwareprojekte gefährdet. Da sind Schutzmaßnahmen auch auf Anwenderseite gefragt. Diese erhöhen zumindest die Chance, eingeschleustem Schadcode auf die Schliche zu kommen.

Windows: Angriffsoberfläche reduzieren

Unter Windows bietet der Defender in der Standardkonfiguration einen guten Basisschutz gegen klassische Malware, doch bei legitimer, signierter Software mit eingebettetem Schadcode stoßen klassische Signatur- und Heuristikverfahren oft an ihre Grenzen. Genau hier setzen die "Attack Surface Reduction"-(ASR)-Regeln an.

Sie blockieren typische Angriffstechniken wie etwa das Starten von Code aus Office-Dokumenten, die Nutzung von LOLBins (wie regsvr32.exe oder mshta.exe), oder das Einfügen von Code in vertrauenswürdige Prozesse (Code Injection). Über Tools wie ConfigureDefender lassen sich diese ASR-Regeln einfach aktivieren – besonders empfehlenswert ist hier das High-Profil, das auch Speicherzugriffe durch nicht signierte Prozesse einschränkt und verdächtige Skript-Ausführung unterbindet.

Ein weiterer wichtiger Sicherheitsfaktor unter Windows ist die konsequente Nutzung eines Standard-Benutzerkontos im Alltag. Viele Schadprogramme benötigen administrative Rechte, um sich dauerhaft im System zu verankern, Dienste zu manipulieren oder systemweite Änderungen vorzunehmen. Wer dauerhaft mit einem eingeschränkten Konto arbeitet und Administratorrechte nur gezielt anfordert, reduziert die Angriffsfläche deutlich. Gerade in Unternehmen sollte das Prinzip der minimalen Rechte konsequent umgesetzt werden.

DNS-Filter als Verteidigungsschicht

Ein zusätzlicher Sicherheitsgewinn lässt sich durch die Nutzung von DNS-Filterdiensten wie Quad9, DNS4.EU oder dns0.eu erzielen. Diese blockieren bekannte Malware-, Phishing- und C2-Domains bereits auf DNS-Ebene – bevor ein Verbindungsaufbau zustande kommt. Gerade bei Supply-Chain-Angriffen, bei denen Schadsoftware nach dem ersten Start Kontakt zu externen Servern aufnehmen will oder weiteren Code nachlädt, kann das verhindern, dass sich Malware dauerhaft im System verankert.

Dienste wie Quad9 oder dns0.eu greifen dabei auf unterschiedliche Threat-Intelligence-Feeds zurück – je nach Anbieter mit Fokus auf Datenschutz, Malware-Abwehr oder auch Werbung und Tracking. Einige Filterdienste wie NextDNS bieten zudem konfigurierbare Blacklists, Protokollierung oder individuelle Blockregeln. Besonders im Unternehmensumfeld lassen sich DNS-Filter zentral über den Router, DHCP oder lokale Resolver-Dienste wie dnsmasq oder unbound integrieren.

Android: Sandbox und sichere App-Quellen

Unter Android erschwert die systemweite App-Sandbox, das granular geregelte Rechtemanagement und Googles Safe Browsing-Funktion viele klassische Angriffswege. Dennoch bleiben Risiken, wenn eine kompromittierte App umfangreiche Rechte besitzt oder sich durch Updates neue Berechtigungen erschleicht – zum Beispiel Zugriff auf die Zwischenablage, den Dateispeicher oder gar die mächtigen "Accessibility Services".

Deshalb ist es entscheidend, nicht nur auf die Herkunft einer App zu achten (etwa Google Play), sondern auch auf das Verhalten nach der Installation: Fordert eine App nachträglich neue Rechte ohne erkennbaren Grund? Ändert sie plötzlich ihr Icon oder ihre Kategorie? Solche Hinweise deuten oft auf ein kompromittiertes Update hin.

Google Play Protect und Privates DNS

Play Protect erkennt manche dieser Verhaltensmuster, arbeitet dabei jedoch weitgehend im Hintergrund. Zwar kann Google bei identifizierter Malware per Play Services sogar Apps nachträglich deaktivieren – doch verdächtige Netzwerkaktivitäten oder verhaltensbasierte Anomalien fallen nicht immer sofort auf.

Eine gewisse Abhilfe schafft auch hier ein "Privates DNS" mit den genannten DNS-Anbietern, das systemweit – also auch außerhalb des Browsers – den Kontakt zu bekannten schädlichen Infrastrukturen verhindert. In Kombination mit Play Protect und dem restriktiven Rechtekonzept ergibt sich so ein deutlich robusteres Sicherheitsniveau.

Strengeres App-Review bei Apple

Auch Apple-Plattformen wie iOS und macOS sind nicht grundsätzlich immun gegen Supply-Chain-Angriffe – allerdings greifen hier andere Schutzmechanismen. Unter iOS sorgt das streng kontrollierte App-Review-Verfahren des App Store dafür, dass manipulierte Apps seltener durchkommen – doch auch hier gab es bereits Fälle, bei denen kompromittierte Bibliotheken oder Entwickler-Accounts für Angriffe ausgenutzt wurden.

Die starke App-Sandbox, das verpflichtende Signieren von Code, restriktive Rechtevergabe und keine Möglichkeit zur dauerhaften Hintergrundausführung ohne Systemfreigabe bieten robuste Schutzbarrieren. Entscheidender Schwachpunkt bleibt aber die menschliche Komponente: Wenn Nutzer Apps Rechte wie Kamera, Mikrofon oder Bewegungsdaten freigeben, können auch dort legitime, aber kompromittierte Apps Schaden anrichten – etwa durch verdeckte Spionage oder Datenabfluss.

Präventive Maßnahmen für macOS

Auf macOS ist die Bedrohungslage komplexer, da es als vollwertiges Desktop-Betriebssystem deutlich mehr Ausführungsspielraum bietet. Zwar sorgen Gatekeeper, XProtect, SIP (System Integrity Protection) und notarized Apps für ein hohes Schutzniveau – doch gerade Entwickler-Tools, Scripting-Engines (Node.js, Python, Homebrew) oder CI-Werkzeuge sind Einfallstore für Supply-Chain-Angriffe.

Auch hier sind präventive Maßnahmen gefragt: Signaturen allein bieten keine Sicherheit, wenn Build-Prozesse manipuliert wurden. Admins sollten daher auf eingeschränkte Rechte, DNS-basierte Filter, minimal installierte Softwarepakete und automatisierte Updates mit Integritätsprüfung achten – besonders bei Macs im Unternehmenskontext. Apple selbst kann bei Missbrauch zentral Zertifikate sperren – eine Maßnahme, die bei plattformübergreifenden Angriffen allerdings häufig zu spät greift.

Linux: Paketquellen und Prozesse

Unter Linux hängt die Sicherheit stark vom eingesetzten Paketmanagement und den gewählten Repositories ab. Grundsätzlich gilt: Nur offiziell unterstützte Paketquellen und vertrauenswürdige Maintainer verwenden – insbesondere bei Tools aus dem AUR (Arch) oder über externe PPAs (Ubuntu). Um kompromittierte Software frühzeitig zu erkennen, empfiehlt sich der Einsatz von File Integrity Monitoring (etwa AIDE oder Tripwire) sowie die regelmäßige Kontrolle laufender Prozesse via ps, ss, auditd oder systemd-analyze.

DNS-Filterschutz lässt sich leicht über "/etc/resolv.conf", systemd-resolved oder Tools wie dnscrypt-proxy einrichten – etwa mit den erwähnten Anbitern Quad9, dns0.eu oder DNS4.EU. In sicherheitskritischen Umgebungen sollten AppArmor oder SELinux aktiviert und sinnvoll konfiguriert werden, um Rechte und Zugriffe auf Dateisystemebene zusätzlich abzusichern.

Anomalieerkennung in Firmennetzen

Firmen sollten sich nicht allein auf Endgeräteschutz verlassen, sondern das Netzwerk selbst als Sicherheitszone verstehen. Intrusion Detection- und Prevention-Systeme (IDS/IPS) können dabei helfen, auffälligen Datenverkehr zu identifizieren – etwa wenn kompromittierte Tools ungewöhnliche Verbindungen zu Command-&-Control-Servern aufbauen oder inaktive Ports nutzen.

Moderne IDS-Lösungen mit Deep Packet Inspection und Threat Intelligence-Integration (etwa Suricata, Zeek oder kommerzielle NGFWs) sind in der Lage, auch verschlüsselte Verbindungen anhand von Verhaltensmustern oder SNI-Analysen zu erkennen und zu blockieren. IPS-Systeme bieten zusätzlich aktive Eingriffsmöglichkeiten, beispielsweise durch das Zurücksetzen verdächtiger TCP-Verbindungen.

Systeme abschotten

Ein weiterer wichtiger Baustein ist die Netzwerk-Segmentierung, insbesondere in Entwicklungs- und CI/CD-Umgebungen. Wenn Systeme mit hoher Angriffswahrscheinlichkeit – etwa Build-Server, Entwicklerarbeitsplätze oder Container-Runner – logisch und physisch von Produktionssystemen getrennt sind, lassen sich potenzielle Angriffe begrenzen, bevor sie lateral eskalieren.

Ergänzt durch Anomalieerkennung (NDR, UEBA), zum Beispiel bei plötzlichem DNS-Verhalten, neuartigen Dateiübertragungen oder untypischen SSH-Sessions, lässt sich eine "Defense-in-Depth"-Strategie realisieren. Wichtig ist, dass nicht nur klassische Signaturen, sondern auch dynamische, verhaltensbasierte Modelle (etwa auf Basis von ML oder statistischer Baselines) zur Anwendung kommen – denn moderne Supply-Chain-Angriffe sind oft zu neu oder zu subtil für regelbasierte Erkennung.

Fazit

Supply-Chain-Angriffe nutzen das Vertrauen in vermeintlich legitime Software aus – oft mit erschreckender Tiefe und Reichweite. Weder Betriebssysteme noch App-Stores bieten vollständigen Schutz, wenn Schadcode früh in der Entwicklungskette eingeschleust wird. Umso wichtiger sind mehrschichtige Verteidigungsstrategien: Härten auf Endgeräten, DNS-basierter Netzwerkschutz, Segmentierung in der Infrastruktur und ein wachsames Auge für verdächtiges Verhalten.

Wer in Entwicklung, Betrieb oder Security Verantwortung trägt, muss heute auch Lieferketten absichern – nicht nur die eigenen, sondern die der Software. Hierzu gehören im Übrigen auch Software Bills of Material (SBOMs), mit denen IT-Verantwortliche den Überblick über die verwendeten Komponenten behalten. Nur so lässt sich rasch feststellen, ob und wie das eigene Unternehmen von einer möglichen Hintertür oder Schwachstelle betroffen ist.

Natürlich bietet keine der genannten Maßnahmen einen vollständigen Schutz vor Supply-Chain-Angriffen. Auch nicht in Kombination. Aber sie erhöhen zumindest die Chance, eine solche Attacke in ihren Anfängen zu stoppen und frühzeitig aufzudecken. Die Prinzipien "Zero Trust" und "Assume Breach" gehören nicht nur durch die gefährdeten Software-Lieferketten längst auf die IT-Security-Agenda.