{"id":2801,"date":"2022-02-07T12:54:41","date_gmt":"2022-02-07T12:54:41","guid":{"rendered":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/?p=2801"},"modified":"2022-07-08T14:00:15","modified_gmt":"2022-07-08T14:00:15","slug":"security-und-compliance-in-softwareprojekten","status":"publish","type":"post","link":"https:\/\/blogs.zeiss.com\/digital-innovation\/de\/security-und-compliance-in-softwareprojekten\/","title":{"rendered":"Security und Compliance in Softwareprojekten \u2013 Dependencies unter Kontrolle bringen"},"content":{"rendered":"\n
\"Symbolbild:<\/figure>\n\n\n\n
<\/div>\n\n\n\n

Dieser Blogbeitrag befasst sich mit den hohen Anspr\u00fcchen an Security und Compliance, die wir an jedes Softwareprojekt stellen. Daf\u00fcr verantwortlich ist in jedem Projekt ein ausgebildeter Security Engineer. Dabei stellen ihn insbesondere die unz\u00e4hligen Dependencies in Softwareprojekten, welche in ihrer Vielzahl von Versionen unter Kontrolle gebracht werden m\u00fcssen, vor gro\u00dfe Herausforderungen.<\/p>\n\n\n\n

\"\"
Abbildung 1: Ein Ausschnitt aus dem Abh\u00e4ngigkeits-Graph eines npm Paketes, aus npmgraph.js.org\/?q=mocha<\/em><\/figcaption><\/figure>\n\n\n\n
<\/div>\n\n\n\n

Herausforderungen in Softwareprojekten<\/h2>\n\n\n\n

Gro\u00dfe Softwareprojekte bestehen schon seit langer Zeit aus kleineren Teilen, die f\u00fcr ihr jeweiliges Gebiet wiederverwendet werden k\u00f6nnen. Komponenten, bei denen es nicht um geheime Funktionalit\u00e4t geht, werden zunehmend als \u201eFOSS (Free and Open Source Software)\u201c ver\u00f6ffentlicht. Das bedeutet \u201equelloffen\u201c (Open Source) und mit einer freien Lizenz zur Weiterverwendung.<\/p>\n\n\n\n

Dabei ist es f\u00fcr die Einsch\u00e4tzung und Pr\u00e4vention von Sicherheitsl\u00fccken \u00e4u\u00dferst wichtig, eine vollst\u00e4ndige \u00dcbersicht \u00fcber alle eingebundenen Drittbibliotheken zu haben. Denn jedes unserer importierten Module kann ebenfalls mit mehreren Abh\u00e4ngigkeiten verbunden sein. Schnell steigt dann die Anzahl an zu beobachtenden Abh\u00e4ngigkeiten in die Tausende und es ist nicht einfach, zwischen allen Versionen den \u00dcberblick \u00fcber Lizenzen und Sicherheitsl\u00fccken zu behalten.<\/p>\n\n\n\n

Die Auswirkung der Problematik wird z. B. klar, wenn man F\u00e4lle von \u201eSupply chain attacks\u201c und \u201eDependency Hijacking\u201c der letzten Jahre liest. Eine interessante Meta-Analyse ist \u201eWhat Constitutes a Software Supply Chain Attack? \u201c von Ax Sharma (https:\/\/blog.sonatype.com\/what-constitutes-a-software-supply-chain-attack). Den Umgang mit diesen Komponenten in gro\u00dfen wie kleinen Softwareprojekten aus Sicht eines Security Engineers m\u00f6chten wir weiter erl\u00e4utern.<\/p>\n\n\n\n

<\/div>\n\n\n\n

L\u00f6sungsm\u00f6glichkeiten mittels FOSS Scanner<\/h2>\n\n\n\n

\u00dcber die Zeit haben sich einige Projekte dem Problem der Kenntlichmachung von FOSS-Komponenten gewidmet. Es gibt Programme zum Erstellen von Bill of Material (BOM) und \u00dcbersichten zu Sicherheitsrisiken, welche wir verprobt haben.<\/p>\n\n\n\n

Weiter gibt es gro\u00dfe Kataloge wie den \u201eNode Paketmanager\u201c (npm), die selbst ausf\u00fchrliche Informationen zu den jeweils angebotenen Komponenten geben.<\/p>\n\n\n\n

Auch wenn es diese freien und quelloffenen Komponenten gratis gibt, so sind sie nicht ohne Aufwand, besonders in langlebigen und wichtigen Softwareprojekten.<\/p>\n\n\n\n

Wir haben f\u00fcr die Evaluierung den OWASP-Dependency Check<\/em> (DC) und das OSS Review Toolkit<\/em> als kombinierte L\u00f6sung f\u00fcr das Auffinden von Sicherheitsproblemen mit DC und \u00dcberpr\u00fcfung der Einhaltung der Lizenzbestimmungen eingesetzt. Im Vergleich zu kommerziellen L\u00f6sungen wie BlackDuck bieten diese frei und kostenlos die M\u00f6glichkeit einer \u00dcbersicht \u00fcber die FOSS-Komponenten in Projekten und die Bewertung von Risiken.<\/p>\n\n\n\n

Das war aber unserer Erfahrung nach mit Mehraufwand sowohl in der Konfiguration als auch bei der kontinuierlichen \u00dcberpr\u00fcfung, d. h. neuen Scans auf neue Sicherheitsprobleme, verbunden.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Verantwortung als Software Engineer<\/h2>\n\n\n\n

Unsere Richtlinien f\u00fcr sichere Entwicklung und den Einsatz von Open Source geben die notwendigen Prozesse und Ziele vor, an dem sich unsere Security Engineers in Vertretung der Projekte orientieren. Der vielleicht wichtigste Ausschnitt daraus wird im folgenden Abschnitt aufgef\u00fchrt:<\/p>\n\n\n\n

It is our responsibility that the following so called Essential FOSS Requirements<\/em> are fulfilled:<\/p>\n\n\n\n