Thought Leadership
Microsoft führt im neuen Visual Studio Code 1.123 eine Update-Verzögerung von zwei Stunden ein, um automatische Supply-Chain-Angriffe einzudämmen.
Microsoft hat für seine integrierte Entwicklungsumgebung Visual Studio Code eine Sicherheitsfunktion eingeführt, um Bedrohungen für die Software-Lieferkette zu minimieren. Ab der Version 1.123 wird bei aktivierten automatischen Aktualisierungen eine standardmäßige Verzögerung von zwei Stunden angewendet, bevor neue Versionen von Erweiterungen installiert werden.
„Wenn automatische Updates aktiviert sind, werden neue Versionen zwei Stunden nach ihrer Veröffentlichung automatisch aktualisiert, was eine zusätzliche Schutzschicht gegen problematische oder potenziell kompromittierte Versionen bietet.“
Microsoft
Anwender behalten weiterhin die Möglichkeit, Aktualisierungen über eine entsprechende Schaltfläche jederzeit manuell und ohne Wartezeit anzustoßen. Befindet sich eine Erweiterung in der Warteschleife, zeigt die Detailansicht der Software den genauen Grund für die Verzögerung sowie den geplanten Zeitpunkt des automatischen Updates an. Diese Sicherheitsverzögerung greift jedoch nicht bei Erweiterungen, die von verifizierten und vertrauenswürdigen Herausgebern stammen. Dazu zählen Veröffentlichungen von Microsoft selbst sowie von GitHub und OpenAI. Diese zertifizierten Erweiterungen erhalten Updates weiterhin ohne zeitliche Verzögerung.
Nicht nur Visual Studio Code: Trend zu künstlichen Abkühlphasen
Die Maßnahme von Microsoft reiht sich in eine Serie ähnlicher Sicherheitskontrollen ein, die in jüngster Zeit von verschiedenen Paketmanagern und Ökosystemen implementiert wurden. Wenige Tage vor der Ankündigung von Microsoft integrierte RubyGems eine optionale Cooldown-Funktion in die Version Bundler 4.0.13. Diese erlaubt es Entwicklern, eine zeitbasierte Installationsverzögerung für neu veröffentlichte Softwarepakete (Gems) zu konfigurieren, um das Risiko durch kompromittierte Konten zu verringern.
Auch andere populäre Plattformen für die Softwareentwicklung haben im vergangenen Jahr vergleichbare Mechanismen eingeführt, um Mindestalter-Schwellenwerte für Paketinstallationen festzulegen:
- Bun nutzt die Funktion minimumReleaseAge ab Version 1.3
- npm verwendet die Konfiguration min-release-age ab Version 11.10.0
- pnpm setzt auf minimumReleaseAge ab Version 10.16
- Yarn bietet die Option npmMinimalAgeGate ab Version Berry 4.10.0
Hintergrund dieser koordinierten Abwehrmechanismen ist die starke Zunahme von Supply-Chain-Vorfällen, bei denen Angreifer Entwicklersysteme infiltrieren, um Schadsoftware an nachgelagerte Endnutzer zu verteilen. Durch das künstliche Hinauszögern der Installationen wird das Zeitfenster minimiert, in dem sich kompromittierte Softwarepakete unbemerkt verbreiten können, bevor sie von Sicherheitsanalysten oder Plattformbetreibern als bösartig eingestuft und aus den Registern entfernt werden.
(red)
