![\"Sicherheit](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2021\/04\/Sicherheit_klein.jpg\" "\\"Sicherheit")
Im M\u00e4rz 2024 machte die Entdeckung einer Backdoor in den zur Komprimierung genutzten \"xz\"-Tools und Bibliotheken Schlagzeilen. Aber wie gro\u00df ist die Bedrohung der IT-Sicherheit durch in Open Source-Software eingeschleuste Malware wirklich? Mir sind bereits vor einigen Tagen einige Aussagen der Eclips-Foundation zu diesem Thema untergekommen. Ich stelle die Aussagen mal hier im Blog ein.<\/p>\n
<\/p>\n
Im M\u00e4rz 2024 hat der deutsche Microsoft-Ingenieur Andres Freund einen Hackerangriff auf die Linux Software vereitelt. Nur weil Freund sehr aufmerksam war und ihm einige merkw\u00fcrdige Symptome rund um liblzma (ein Teil des xz-Pakets) unter Debian-Sid-Installationen aufgefallen waren, ist er dieser Sache nachgegangen. <\/p>\n
Er fand dann die Ursache: Das (auch von sssh benutzte) Upstream-xz-Repository und die xz-Tarballs wurden mit einem Backdoor versehen. Erst vermutete er, dass das Debian-Paket kompromittiert worden sei, stellte aber fest, dass die Backdoor im Upstream-Paket enthalten ist. Ich hatte im Beitrag Linux: Backdoor in Upstream xz\/liblzma; Kompromittierung der SSH-Server<\/a> dar\u00fcber berichtet. <\/p>\n In den Medien (und hier im Blog) wurde anschlie\u00dfend die Sicherheit von Open Source Software (OSS) in Kommentaren in Frage gestellt. Hier w\u00e4re es wichtig, eine fundierte Einordnung zur Frage Wie gro\u00df ist die Bedrohung der IT-Sicherheit durch Open Source Malware wirklich?<\/em> vorzunehmen. <\/p>\n Zun\u00e4chst einmal stellt Malware gleicherma\u00dfen eine Bedrohung f\u00fcr kommerzielle als auch f\u00fcr Open-Source-Software dar. Cybersicherheitsexperten best\u00e4tigen, dass Cyberkriminelle h\u00e4ufig auf Schwachstellen abzielen, die eine m\u00f6glichst gro\u00dfe Angriffsfl\u00e4che bieten. Ber\u00fccksichtigt man, dass bis zu 90 Prozent aller Software-Infrastrukturen auf Open Source Software (OSS) basieren, wird klar, dass OSS immer mehr zum Hauptziel von Angriffen wird. <\/p>\n Angesichts dieser Tatsachen ist es offensichtlich, dass die Bedrohungen f\u00fcr die Softwaresicherheit nicht nur real sind, sondern auch anhalten. Die beruhigende Nachricht ist jedoch, dass sich die derzeitigen Sicherheitspraktiken als wirksam erweisen. J\u00fcngste Vorf\u00e4lle wie die Linux SSH Schwachstelle und der xz utils Angriff konnten beide erfolgreich abgewehrt werden, weil die Community schnell reagiert und ihre Schutzma\u00dfnahmen umgesetzt hat. Die Zusammenarbeit der Community ist die beste Verteidigung gegen solche Angriffe. <\/p>\n Um die Abwehrma\u00dfnahmen zu verst\u00e4rken, wurde f\u00fcr die betreuten Projekte der Eclipse Foundation das SLSA-Framework \u00fcbernommen. SLSA<\/a> steht f\u00fcr \"Supply-chain Levels for Software Artifacts\", ein Security Framework. Es besteht aus einer Checkliste mit Standards und Kontrollen, um Manipulationen von Open Source Software (OSS) zu verhindern, die Integrit\u00e4t zu verbessern und Pakete und Infrastruktur zu sichern. Es ist, laut Eigenbeschreibung, der Weg von \"sicher genug\" zu gr\u00f6\u00dftm\u00f6glicher Widerstandsf\u00e4higkeit, und zwar f\u00fcr jedes Glied der Kette. <\/p>\n Neben den Ausf\u00fchrungen auf der oben verlinkten SLSA<\/a>-Seite hat Google im Juli 2021 den Beitrag Securing the software development lifecycle with Cloud Build and SLSA<\/a> mit einer Einf\u00fchrung in das Thema publiziert. <\/p>\n Mika\u00ebl Barber, Head of Security bei der Eclipse Foundation merkt dazu an, dass die Eclipse Foundation \u00fcber den SLSA-Ansatz hinaus eigene Sicherheitsrichtlinien entwickelt habe, um sicherzustellen, dass bei der Entwicklung dieser Projekte die besten Software-Sicherheitspraktiken im Mittelpunkt stehen. <\/p>\n Ebenso wichtig sei das Engagement der Eclipse Foundation, ihre Mitglieder bei der Anpassung ihrer Projekte an neue Regulierungen wie den Cybersecurity Resilience Act zu unterst\u00fctzen. Als Teil des proaktiven Ansatzes hat die Eclipse Foundation wir k\u00fcrzlich die Open Regulatory Compliance Initiative ins Leben gerufen. In der Initiative sind weitere f\u00fchrende Stiftungen wie die Apache Software Foundation, OpenSSF Foundation, Blender Foundation, OpenSSL Software Foundation, PHP Foundation, Python Software Foundation und Rust Foundation beteiligt. <\/p>\n Gemeinsam wollen die Mitglieder auf Best Practices basierende Prozessspezifikationen entwickeln, um die Einhaltung dieser sich entwickelnden Regulierungen zu erleichtern. Damit werden Organisationen, die Open Source einsetzen, in die Lage versetzt, diese Regularien effizienter umzusetzen. <\/p>\n Es tut sich also was in Punkt Software-Lieferkette – und bei Open Source Software sind die Vorg\u00e4nge transparent, was bei Closes Source-Software in der Regel so nicht nachgepr\u00fcft werden kann. Man ist bei Closes Source-Software auf die Zusicherungen der Hersteller angewiesen. <\/p>\n","protected":false},"excerpt":{"rendered":" Im M\u00e4rz 2024 machte die Entdeckung einer Backdoor in den zur Komprimierung genutzten \"xz\"-Tools und Bibliotheken Schlagzeilen. Aber wie gro\u00df ist die Bedrohung der IT-Sicherheit durch in Open Source-Software eingeschleuste Malware wirklich? Mir sind bereits vor einigen Tagen einige Aussagen … Weiterlesen Wie gro\u00df ist die Bedrohung wirklich?<\/h2>\n<\/p>\n
Eclipse Foundation nutzt das SLSA-Framework <\/h3>\n<\/p>\n
Eclipse nutzt ihre eigenen Sicherheitsrichtlinien<\/h3>\n<\/p>\n