Technischer Support
Dokumentation
Anmeldung
Kontakt
Wichtigste Erkenntnisse
- Die SecureChain-Korrekturen werden im Rahmen von „JFrog Zero-Touch Remediation“ bereitgestellt und ohne Versionssprung angewendet.
- Das Aufspüren des Problems war nie der schwierige Teil; die Entwicklung und Bereitstellung einer fehlerfreien Lösung war es hingegen immer.
- Die Unterstützung wird fortgesetzt, auch nachdem die Upstream-Entwickler keine Sicherheitspatches mehr für ein Paket bereitstellen.
- Jeder angewendete Fix wird über JFrog AppTrust bestätigt, sodass die Prüfungsnachweise direkt aus der Pipeline stammen.
Eine kritische CVE taucht in einem Paket auf, das drei Ebenen tief in der Abhängigkeitsstruktur liegt. Der Scanner entdeckt sie noch am selben Tag – das ist der einfache Teil. Dann stellt sich heraus, dass der Fix nur in einer Hauptversion verfügbar ist, dass diese Version eine API ändert, die zwei Ihrer Dienste aufrufen, und dass das Paket, aus dem sie bezogen wurde, durch ein Anbieter-SDK festgeschrieben ist, über das niemand im Team die Kontrolle hat. Zwei Wochen später ist das Ticket noch offen, und der Befund steht immer noch im Bericht.
Ein anfälliges Open-Source-Paket zu finden, ist selten der schwierige Teil. Die Behebung wird erst dann kompliziert, wenn es darum geht, den richtigen Fix in den richtigen Build zu integrieren, ohne dabei ein zweites Problem zu verursachen.
Genau diese Lücke soll die neue Partnerschaft schließen. TuxCare ist als Gründungspartner dem „JFrog Self-Healing Software Supply Chain Security Ecosystem“ beigetreten, und SecureChain wird in „JFrog Zero-Touch Remediation“ integriert, um als Quelle für Korrekturen für anfällige Open-Source-Pakete zu dienen.
Wo die Open-Source-Sanierung tatsächlich ins Stocken gerät
Die Abdeckung durch Scanner ist mittlerweile so gut, dass die meisten Teams bereits lange bevor jemand einen Plan für sie hat, über ihre anfälligen Abhängigkeiten Bescheid wissen. Was sie bekommen, ist eine Warteschlange.
Ein anfälliges Drittanbieter-Paket lässt drei reale Optionen offen: Ein Upgrade auf die korrigierte Version, das eigenständige Backportieren des Fixes oder das Akzeptieren des Risikos und das Dokumentieren des Problems. Die erste Option wird von jedem Tool empfohlen, ist jedoch oft am wenigsten praktikabel, da Versionssprünge in transitiven Abhängigkeiten eine Kettenreaktion auslösen, die sich anhand des Manifests nicht vorhersagen lässt. Manchmal ist die betroffene Version bereits nicht mehr unterstützt, sodass kein Upgrade mehr möglich ist. Die zweite Option bedeutet, einen Fork von Code zu pflegen, den man nicht selbst geschrieben hat, und zwar auf einer Codebasis, die man nicht ordnungsgemäß testen kann. Die dritte Option ist das, was in der Regel passiert.
Stellen Sie sich ein 30-köpfiges Plattformteam vor, das ein Dutzend Java-Dienste betreibt, von denen die Hälfte aufgrund eines lizenzierten – und nicht im Eigenbesitz befindlichen – SDKs an eine ältere Jackson-Version gebunden ist. Das Upgrade ist ein Projekt, das sich über mehrere Sprints erstreckt und keine neuen Funktionen mit sich bringt. Die Entwickler verbringen Tage damit, verschiedene Lösungsansätze zu vergleichen, bevor sie eine Option finden, die sich sicher bereitstellen lässt. Die Ergebnisse finden sich so oder so im Wochenbericht wieder, und der Termin für das Audit verschiebt sich nicht.
Was SecureChain leistet
SecureChain-Pakete werden aus dem Quellcode neu kompiliert, vor ihrer Veröffentlichung auf Malware überprüft und hinsichtlich bekannter Sicherheitslücken gepatcht, ohne dass dabei die im Manifest angegebene Version geändert wird.
Für diese Integration sind zwei Aspekte entscheidend: Der Fix behält die gleiche Versionsnummer bei, sodass im Abhängigkeitsgraphen keine Änderungen erforderlich sind. Und der Support endet nicht mit dem Ende der Wartung durch den Upstream-Entwickler, da im Rahmen des „Endless Lifecycle Support“ auch nach dem Ende der Wartung durch die Entwickler weiterhin Fixes für diese Versionsreihe bereitgestellt werden.
In diesem zweiten Bereich finden sich viele langlebige Ergebnisse. Ein Paket, für das seit drei Jahren kein Commit mehr vorgenommen wurde, wird von seinem Betreuer keinen CVE-Fix erhalten, ganz gleich, wie viele Tickets darauf verweisen.
Die SecureChain-Abdeckung umfasst derzeit npm, PyPI und Maven; Go, Rust und PHP sind für die Zukunft geplant.
Was passiert im Inneren der Rohrleitung?
Artifactory ist die Quelle, aus der die Builds bezogen werden. Daher ist es der einzige Ort, an dem eine Korrektur eingebracht werden kann, ohne dass ein Entwickler gebeten werden muss, etwas zu ändern.
Bei der „Zero-Touch Remediation“ wird eine anfällige Komponente mit dem besten verfügbaren Partner-Patch gemäß Ihrer Richtlinie abgeglichen, über die von Ihnen bereits genutzte Pipeline angewendet und eine signierte Bescheinigung für die Maßnahme über JFrog AppTrust aufgezeichnet. Wenn Ihre Richtlinie ein aus der Quelle neu erstelltes, kontinuierlich gepatchtes Paket bevorzugt, wird die SecureChain-Version bereitgestellt. Der Build fordert dasselbe Paket an wie gestern und erhält ein gepatchtes Exemplar.
Kein Ticket. Keine Suche nach einer kompatiblen Version. Keine Verhandlungen mit dem Team, das den Dienst betreibt.
Der Nachweis ist wertvoller, als es zunächst den Anschein hat. Die meisten Teams können letztendlich nachweisen, dass ein Paket gepatcht wurde. Weitaus weniger können jedoch in einer Form nachweisen, die ein Prüfer ohne weitere Nachfragen akzeptiert, wann es gepatcht wurde, gegen welche CVE und nach welchem Verfahren.
Wo sich das zuerst auszahlt
Am deutlichsten profitieren davon Pakete, deren Upstream-Support eingestellt wurde, transitive Abhängigkeiten, die Ihr Team nie selbst ausgewählt hat und die sich nicht ohne Weiteres ersetzen lassen, sowie alle Umgebungen, in denen SLAs für die Fehlerbehebung vertraglich festgelegt sind und nicht nur als Zielvorgabe gelten.
Wenn Sie Artifactory bereits mit Xray oder Advanced Security betreiben, ist das Hinzufügen von SecureChain als Fix-Quelle eher eine strategische Entscheidung als eine Migration. Wenn Ihre Builds von einer anderen Quelle als JFrog bezogen werden, funktioniert SecureChain weiterhin als eigenständige, geprüfte Registry, und die Integration steht Ihnen zur Verfügung, sobald Sie sie benötigen.
So oder so: Die Veränderung, auf die man achten sollte, ist nicht die Tatsache, dass es Korrekturen gibt. Korrekturen gab es schon vorher. Es geht vielmehr darum, dass eine Korrektur in eine laufende Version gelangen kann, ohne dass jemand sie dorthin übertragen muss – und genau das macht die Fehlerbehebung nicht mehr zu einer Projektangelegenheit, sondern zu einem routinemäßigen Bestandteil der Softwareauslieferung.
Weitere Informationen zu JFrog Zero-Touch Remediation: jfrog.com/zero-touch-remediation
Weitere Informationen zu TuxCare SecureChain: tuxcare.com/securechain-for-oss
