Die Anforderungen an Sicherheit: Vertrauen, Geschwindigkeit und integrale Verteidigung

Die systemische Ausgestaltung von Angriffen auf die Software-Lieferkette wird immer komplexer. Das führt zu einem kritischen Konflikt zwischen Geschwindigkeit und Sicherheit.

Der aktuelle Bericht „Breaking the Chain” des Israelischen National Cyber Directorate (INCD) bestätigt, dass die größten Bedrohungen außerhalb Ihres First-Party-Codes liegen, und verdeutlicht damit die Vertrauenskrise in der Lieferkette von Open-Source-Software (OSS).

Während die neuen Durchbrüche in der agentenbasierten KI-Verteidigung einen fantastischen und willkommenen Fortschritt für die Codesicherheit und -qualität darstellen, erinnert der INCD-Bericht daran, dass Sicherheit die gesamte Software-Lieferkette umfassen, nativ und integraler Bestandteil des Softwarebereitstellungsprozesses sein und sich auf die Binärdatei konzentrieren muss, um den Konflikt zwischen Geschwindigkeit und Sicherheit in Unternehmen wirklich zu lösen.

JFrogs Haltung zum Thema Sicherheit: End-to-End. Nativ. Fortschrittlich.

Die Philosophie von JFrog basiert auf drei zentralen Zielen: die Produktivität von Entwicklern sicherzustellen, Entwicklungsteams die Gewissheit zu geben, dass jede Softwareversion vertrauenswürdig ist, und den gesamten Sicherheitsmanagementprozess einfach handhabbar zu machen. Diese Ziele lösen effektiv das Dilemma zwischen Geschwindigkeit und Sicherheit – und ermöglichen es Teams, beides zu erreichen. Doch was braucht es konkret, um dieses Ziel zu erreichen?

Drei Säulen der Verteidigung

Erstens: Sicherheit muss die gesamte Software-Lieferkette abdecken – von Anfang bis Ende.

Warum? Sicherheit ist kein einmaliger Checkpoint, sondern ein kontinuierlicher Prozess – vom ersten geschriebenen Code bis zur Bereitstellung des Artefakts in der Produktion. Dafür braucht es Kontext und Rückmeldungen aus dem gesamten Lebenszyklus eines Artefakts. Ein durchgängiger Ansatz (Ende-zu-Ende) schafft die zentrale Quelle der Wahrheit, die nötig ist, um Risiken ganzheitlich zu managen, Compliance sicherzustellen sowie Kontrolle und Nachverfolgbarkeit über die gesamte Pipeline hinweg zu gewährleisten.

Zweitens: Sicherheit muss nativ in den Softwarebereitstellungsprozess integriert sein – nicht nachträglich aufgesetzt.

Warum? Reaktive, externe Sicherheitstools verursachen Reibungsverluste, verzögern die Markteinführung und bieten schlichtweg nicht die nötige Transparenz für eine wirksame Governance. Durch das Erzwingen von Richtlinien und kontinuierliches Scanning innerhalb einer einzigen Plattform werden Compliance und Vertrauen bereits während der Ausführung der Pipeline sichergestellt – und nicht erst im Nachhinein überprüft. So wird jede automatisierte Kontrollinstanz zu einem Checkpoint für Sicherheit – und Sicherheit zu einem Beschleuniger statt zu einem Hindernis.

Drittens: Ihre Sicherheitsarchitektur sollte binärzentriert und forschungsbasiert sein.

Warum? Das kompilierte Artefakt – also die Binärdatei – ist das primäre Ziel von Angreifern. Wer sich ausschließlich auf das Scannen von Quellcode verlässt, übersieht eine kritische Schwachstelle: Sicherheitslücken, die erst später im CI/CD-Prozess durch manipulierte Build-Skripte oder kompromittierte Abhängigkeiten eingebracht werden. Durch das Erzwingen von Richtlinien und das kontinuierliche Scannen des Binärartefakts wird Vertrauen direkt in den Pipeline-Prozess integriert. Ihre Sicherheitsstrategie sollte außerdem auf fundierter Forschung basieren. JFrog unterhält ein dediziertes Team aus Sicherheitsexperten und Forschenden, das sich ausschließlich der Weiterentwicklung der Softwaresicherheit widmet – durch das gezielte Aufspüren, Analysieren und Offenlegen neuer Schwachstellen und Angriffsmethoden. Diese Erkenntnisse fließen kontinuierlich in die Weiterentwicklung unserer Plattform ein, um Unternehmen proaktiv vor neuen Bedrohungen zu schützen.

Die zentralen Sicherheitsherausforderungen laut INCD

Die Erkenntnisse aus dem aktuellen INCD-Report „Breaking the Chain: How Supply Chain Attacks Target Package Managers“ liefern eine wichtige externe Bestätigung dafür, warum ein ganzheitlicher Sicherheitsansatz unerlässlich ist.

Herausforderung 1: CI/CD-Pipelines als automatisierte Einfallstore für Risiken

CI/CD-Pipelines automatisieren den gesamten Software-Lebenszyklus – von der Entwicklung bis zur Bereitstellung – mit dem Ziel, hochwertige Software schnell auszuliefern. Doch gerade durch die enge Verzahnung von Entwicklung, Paketmanagement und automatisierten Abläufen wird die Pipeline selbst zum Haupteinfallstor für Risiken. Die Analyse des INCD zeigt: Angreifer nutzen kompromittierte Drittanbieterkomponenten, um sich Zugriff auf Unternehmensinfrastrukturen zu verschaffen – oft unter Umgehung traditioneller Perimeterschutzmaßnahmen.

Herausforderung 2: Die Vertrauenskrise und das Risiko sprachspezifischer Paketmanager

Ein strukturelles Risiko besteht im impliziten Vertrauen, das Paketregistries und ihren gehosteten Paketen entgegengebracht wird – und das bei einer enormen Skalierung. Laut dem Report werden „die 15.000 beliebtesten PyPI-Pakete zusammen über 83 Milliarden Mal pro Monat heruntergeladen.“ Die Kompromittierung einer einzigen transitiven Abhängigkeit kann daher gravierende Folgen haben.

Hinzu kommt: Sprachspezifische Paketmanager wie npm, pip oder Maven unterliegen – anders als zentral verwaltete Betriebssystem-Paketmanager – meist keinen strengen Wartungs- oder Freigabeprozessen. Entwickler können Updates direkt veröffentlichen – ohne manuelle Prüfung. Diese Flexibilität beschleunigt zwar Innovationen, erhöht aber zugleich das Sicherheitsrisiko erheblich.

Herausforderung 3: Der blinde Fleck für Malware bei herkömmlichen Tools

Ein weiteres großes Defizit: Traditionelle Sicherheitstools erkennen häufig keine echte Malware. Tools wie Static Application Security Testing (SAST) oder Software Composition Analysis (SCA) sind vor allem darauf ausgelegt, bekannte Schwachstellen, unsichere Codemuster oder logische Fehler aufzuspüren.

Was ihnen fehlt, ist eine verhaltensbasierte Analyse – also die Fähigkeit, auffälliges Verhalten oder Anzeichen echter Malware zu erkennen. Diese Lücke eröffnet Angriffsflächen für komplexe Zero-Day-Supply-Chain-Angriffe wie beim bekannten XZ-Utils-Backdoor-Vorfall – und stellt eine erhebliche Gefahr für die Software-Lieferkette dar.

Beobachtete Taktiken der Angreifer

Der INCD-Bericht beschreibt außerdem detailliert gängige Taktiken, die sich die mangelnde Ende-zu-Ende-Kontrolle und das implizite Vertrauen zunutze machen:

• Kompromittierung von Anmeldedaten und Identitäten: Zu dieser Kategorie gehören das Hijacking von Projektzugriffstoken und die Übernahme von Konten, bei denen Angreifer durchgesickerte Anmeldedaten oder Phishing ausnutzen, um die Kontrolle über das Konto eines Maintainers zu erlangen und bösartigen Code zu veröffentlichen. Dazu gehört auch das Erlangen von Berechtigungen für Repository-Mitwirkende, bei dem ein Angreifer über einen längeren Zeitraum das Vertrauen der Projektbetreuer gewinnt, um Schreibzugriff zu erhalten und bösartigen Code einzuschleusen, wie es beim XZ-Utils-Backdoor-Vorfall beobachtet wurde.
• Namensmissbrauch: Dazu gehören Typosquatting (Nachahmung legitimer Paketnamen mit Tippfehlern) und Brandjacking (Nachahmung der Merkmale bekannter Unternehmenspakete), um Entwickler zur Installation von bösartigem Code zu verleiten.
• Die KI-native Bedrohung (Slopsquatting): Angreifer nutzen Large Language Models (LLMs), indem sie bösartige Pakete mit Namen veröffentlichen, die LLMs halluzinieren oder generieren und die nicht existierenden Paketen entsprechen, was das Risiko einer Kompromittierung innerhalb von Unternehmensumgebungen erhöht.
• Konfigurations- und Vertrauensmissbrauch: Dazu gehört die Verwechslung von Abhängigkeiten, bei der unsichere Build-Systeme einem öffentlichen, bösartigen Paket (oft mit einer höheren Versionsnummer) Vorrang vor dem vorgesehenen internen Paket einräumen. Dazu gehört auch die Verwechslung von Manifesten (npm), bei der das Manifest (öffentlich angezeigte Metadaten) separat vom Paket-Tarball hochgeladen wird und die tatsächlichen Metadaten und Installationsskripte im Tarball nicht anhand des Manifests validiert werden, was Benutzer und automatisierte Tools in die Irre führt.

INCD empfiehlt mehrstufige Sicherheit für die Software-Lieferkette

Um diese Bedrohungen zu mindern, empfiehlt der INCD-Bericht die Umsetzung eines mehrstufigen Ansatzes. Die JFrog Software Supply Chain Plattform bietet diesen Schutz durch die Operationalisierung der drei Kernsäulen: E2E, nativ/integriert und binärfokussiert.

Säule 1: Ende-zu-Ende-Abdeckung und Governance

Diese Säule gewährleistet durchgängige Sicherheit und Kontrolle über den gesamten Lebenszyklus eines Artefakts hinweg – und adressiert damit Governance-Lücken und Compliance-Anforderungen, wie sie im INCD-Report identifiziert wurden.

• Proaktive Kuratierung und Richtlinienkontrolle: JFrog Curation stärkt die E2E-Kontrolle, indem es Entwickler auf Abhängigkeiten aus vertrauenswürdigen, genehmigten virtuellen Registries beschränkt. So werden Bedrohungen wie Typosquatting, Slopsquatting und Dependency Confusion von vornherein aus der Umgebung ausgeschlossen – in Übereinstimmung mit den INCD-Empfehlungen zur Umsetzung strikter Change-Management- und Testprozesse für neue Pakete in kontrollierten Umgebungen.
• Transparenz in der Lieferkette: JFrog Xray unterstützt nativ die Erstellung umfassender Software Bill of Materials (SBOMs) – ein zentrales Element der INCD-Empfehlungen, um Transparenz in der Software-Lieferkette zu schaffen und auf neue Bedrohungen schnell reagieren zu können.
• Identitäts- und Bedrohungsgovernance: JFrog Advanced Security erweitert den E2E-Schutz um essenzielle Governance-Funktionen – unter anderem unter Berücksichtigung der Empfehlungen aus NIST SP 800-204D. Dazu gehören Secret-Scanning-Tools zur Erkennung offengelegter Zugangsdaten (als Schutz vor der Übernahme von Accounts) und die Durchsetzung des Least-Privilege-Prinzips – sowohl für menschliche Nutzer als auch für Non-Human Identities (NHIs), um Risiken zu minimieren und die Ausbreitung schädlichen Codes zu verhindern.

Säule 2: Native und integrierte Sicherheit

Um Geschwindigkeit ohne Reibungsverluste zu erreichen, muss Sicherheit strukturell integriert sein – nicht nachträglich aufgesetzt.

• Native Richtlinienkontrolle: JFrog Curation dient als erste Verteidigungslinie und adressiert direkt das „implizite Vertrauen“, das in öffentlichen Registries besteht. Durch die native Integration der Richtlinienkontrolle werden riskante oder bösartige Pakete frühzeitig blockiert – noch bevor sie in die Umgebung gelangen. Dieser strukturelle Ansatz sorgt dafür, dass Compliance und Vertrauen automatisch während der Pipeline-Ausführung entstehen.
• Integriertes Tooling: Die JFrog Platform unterstützt alle zentralen DevSecOps-Tools – unter anderem gemäß den NIST SP 800-204D-Richtlinien zur Absicherung der Software-Lieferkette. Dazu gehört auch der empfohlene Einsatz von SAST (in Advanced Security enthalten) und SCA (über Xray).

Säule 3: Binärzentrierte Architektur

Diese Säule stellt sicher, dass der Schutz direkt am Artefakt selbst ansetzt – also am zentralen Ziel von Angreifern – und somit den blinden Fleck zwischen Quellcode und Build schließt.

• Kontinuierliches Artefakt-Scanning: JFrog Xray gewährleistet kontinuierliche Sicherheit, indem alle Inhalte des kompilierten Artefakts gescannt werden. Dieser binärfokussierte Ansatz ermöglicht vollständige Integritätsprüfungen dort, wo es für Angreifer am relevantesten ist.
• Kontextbasierte Analyse: Xray bietet transitive und kontextbezogene Analysen, damit Sicherheitsteams ihre begrenzten Ressourcen gezielt einsetzen können. Nur tatsächlich ausnutzbare Schwachstellen im Kontext der laufenden Codebasis werden priorisiert – das reduziert unnötige Alerts und steigert die Effizienz bei der Schwachstellenbehebung.

Ein Hinweis zu agentenbasierten Sicherheitsscannern: Vorteile und Einschränkungen

Die Einführung von LLM-gestützten Security-Tools markiert einen wichtigen Fortschritt in der Anwendungssicherheit. Diese Werkzeuge gehen über herkömmliche Scans hinaus, indem sie die Analysefähigkeit großer Sprachmodelle (LLMs) nutzen, um das Verhalten von Code ähnlich wie ein menschlicher Experte zu interpretieren.

Obwohl diese agentenbasierten Tools eine sinnvolle Ergänzung zur Verbesserung der Codequalität im First-Party-Bereich darstellen, ist ihr Wirkungsbereich begrenzt – und sie greifen zu früh im Entwicklungszyklus, um die systemischen Lieferkettenrisiken zu verhindern, die im INCD-Bericht beschrieben werden.

Das Potenzial – Wo LLM-gestützte Tools glänzen:

• Erweiterte Codeanalyse: LLMs können große Mengen an Code mit hoher Geschwindigkeit analysieren und dabei Muster oder Schwachstellen erkennen, die herkömmlichen SAST-Tools möglicherweise entgehen.
• Verbesserte Entwicklererfahrung: Durch die Integration in Entwickler-Workflows liefern LLMs direktes Feedback in Echtzeit und helfen dabei, von Anfang an sichereren Code zu schreiben. Hinzu kommt: Der Einsatz von KI erfreut sich wachsender Beliebtheit – und wird von Entwicklern eher angenommen als invasivere Sicherheitslösungen.
• Ergänzung zu bestehenden SAST-Tools: In Kombination mit klassischen SAST-Scannern können LLM-basierte Tools eine zusätzliche Sicherheitsschicht und neue Perspektiven liefern. Es wird empfohlen, beide parallel zu betreiben, bis die Wirksamkeit und Zuverlässigkeit der LLM-basierten Tools umfassend validiert ist.

Die Einschränkungen – Wo systemische Risiken bestehen bleiben

1. Fokus auf Quellcode: Agentische LLMs konzentrieren sich primär auf den Quellcode, der bereits geschrieben und in ein Repository eingecheckt wurde. Den eigentlichen Artefakten – den Binärdateien – widmen sie sich nicht. Dadurch bleibt ein Großteil des späteren Software-Lebenszyklus unberücksichtigt.
2. Sie verpassen den Einstiegspunkt: Die kritischsten Angriffe erfolgen direkt am Einstiegspunkt – dem Paket-Registry. Wenn ein Entwickler ein bösartiges Paket (z. B. durch Typosquatting) herunterlädt, ist der Angriff bereits erfolgreich, bevor der Code überhaupt in einem Repository landet – und lange bevor ein LLM-gestützter Scanner zum Einsatz kommen kann.
3. Keine Governance auf Artefaktebene: LLM-Tools bieten keine Ende-zu-Ende-Transparenz, um Binärdateien über ihren gesamten Distributions- und Bereitstellungszyklus hinweg zu verfolgen, zu sichern und zu verwalten – eine grundlegende Anforderung für echte Software-Lieferkettensicherheit.

Shift-Left-Tools sind wichtig, um Schwachstellen frühzeitig zu erkennen und die Kosten für deren Behebung zu senken – und die Entwicklung agentenbasierter Technologien ist zweifellos spannend. Teams sollten diese Tools gezielt einsetzen, aber dabei umsichtig vorgehen: Wer sich ausschließlich auf LLMs verlässt, ignoriert weite Teile der tatsächlichen Angriffsfläche – und geht ein unnötig hohes Risiko ein.

Die Software-Lieferkette absichern – mit durchgängigem, integriertem und binärzentriertem Schutz

Der Weg zu schnellen, vertrauenswürdigen Releases ist klar: Um eine robuste Software-Integrität zu erreichen und das Spannungsfeld zwischen Geschwindigkeit und Sicherheit aufzulösen, müssen Unternehmen auf ein Architekturfundament setzen, das auf drei Kernprinzipien basiert: Sicherheit, die durchgängig, nativ integriert und binary-fokussiert ist.

Leistungsstarke neue KI-Tools liefern dabei wertvolle ergänzende Einblicke, doch nur eine zentralisierte Plattform bietet die nötige Governance, Kontrolle und Artefaktsicherheit, um moderne Software-Lieferketten wirklich abzusichern.

Bereit, eine durchgehend sichere Software-Lieferkette aufzubauen – ohne dabei auf Geschwindigkeit zu verzichten? Dann starten Sie jetzt Ihre kostenlose Testversion oder vereinbaren Sie eine Demo der JFrog Plattform.