10 Kategorien von Sicherheitstools, die zur Gewährleistung der Sicherheit der Software-Lieferkette erforderlich sind

Von Ericka Chickowski

CSO-Mitarbeiter, CSO |

Während Sicherheitsverantwortliche bei der Einrichtung von Sicherheitsprogrammen für die Software-Lieferkette voranschreiten, sehen sie sich mit den ihnen zur Verfügung stehenden Tools mit einer guten und einer schlechten Nachrichtensituation konfrontiert – im wahrsten Sinne des Wortes: Die Technologie schreitet rasant voran, im Guten wie im Schlechten.

Die gute Nachricht an der sich schnell weiterentwickelnden Software-Supply-Chain-Sicherheitstechnologie ist, dass das hohe Tempo der Innovation zunehmend Möglichkeiten bietet, mehr Sichtbarkeit und Transparenz über die große Vielfalt an Komponenten und Codes zu erlangen, die in Software-Portfolios einfließen.

Die schlechte Nachricht ist jedoch, dass Experimente und Innovationen gleichzeitig in viele verschiedene Richtungen gehen und die Tools-Landschaft eine verwirrende Mischung aus neuen und sich entwickelnden Kategorie-Akronymen und Nischenprodukten ist.

Bei einigen davon handelt es sich um traditionellere Anwendungssicherheitstools, die immer entwicklerfreundlicher werden. Bei anderen handelt es sich um traditionelle Entwicklertools, die sicherheitsorientierte Kontrollen und Funktionen erweitern, um den Herausforderungen von Lieferkettenrisiken zu begegnen. Wieder andere tauchen aus der DevSecOps-Welt auf – speziell entwickelt, um die gegenseitige Zusammenarbeit zwischen diesen Stämmen zu fördern.

„Einer der Gründe, warum es so schwierig ist, sich ein klares Bild von der Sicherheit der Software-Lieferkette zu machen, liegt darin, dass es so viele Teile in der Lieferkette gibt, an denen etwas schief gehen kann“, sagt Tom Goings, Produktberater bei Tanium, gegenüber CSO. „Man kann Schwachstellen direkt in Software einschleusen lassen, wie das SolarWinds-Beispiel von vor ein paar Jahren, Schwachstellen in gängigen Bibliotheken wie Log4j oder sogar so etwas wie eine kompromittierte Zertifizierungsstelle (CA).“

Während mehrere Software-Supply-Chain-Security-Produkt-Stacks und -Plattformen sich auf dem Markt zu konsolidieren beginnen, ist der Funktionsmix dieser Produkte allgegenwärtig.

Die Haupttoolkategorie, auf die sich diese Plattformen konzentrieren, ist die Software-Kompositionsanalyse (SCA) und Tools zur Erstellung von Software-Stücklisten (SBOMs), den sogenannten „Zutatenlisten“ moderner Software. Während SCA und SBOMs in der Regel das Rückgrat vieler Sicherheitstools für die Software-Lieferkette bilden, sollte dies eigentlich nur die Spitze des Eisbergs für CISOs sein, die versuchen, eine Roadmap zur Unterstützung eines umfassenden Programms zur Verwaltung von Lieferkettenrisiken zu entwickeln.

„Wenn es um die Sicherheit der Lieferkette geht, konzentrieren sich die Leute auf die Verwendung von Tools wie SCA und schauen sich SBOMs an“, sagt Dale Gardner, Senior Director und Analyst für Anwendungssicherheit bei Gartner, gegenüber CSO. „Das sind sehr wichtige Teile der Lösung. Aber sie sind eigentlich nur eine Art Teillösung.“

Viele andere bewegliche Teile sind beteiligt, darunter Geheimnisverwaltung, Abhängigkeitszuordnung und -verwaltung, CI/CD-Pipeline-Sicherheit, effektive Repository-Verwaltung und mehr. Die meisten Experten sind sich einig, dass es für Sicherheitsteams schwierig sein wird, alles, was sie benötigen, von einem Anbieter zu finden.

„Ich würde behaupten, dass es keinen einzigen Anbieter gibt, der alle Herausforderungen im Zusammenhang mit der Software-Lieferkettensicherheit auf eine Weise bewältigt, die den Anforderungen aller Unternehmen gerecht wird“, erklärt Michael Born, Senior Manager für Anwendungssicherheit beim Beratungsunternehmen Coalfire. Er erklärt dem CSO, dass mangelnde Konsolidierung nicht unbedingt eine schlechte Sache sei. „Dies würde Unternehmen potenziell Risiken aussetzen, die mit der Bindung an einen Anbieter verbunden sind, und könnte dazu führen, dass die Organisation schneller reift oder sich verändert, als der Anbieter mithalten kann.“

Diese Fragmentierung ist nicht nur ein Ergebnis der organischen Innovation, die aus verschiedenen technischen Perspektiven kommt (entwicklungsorientierte Tools, betriebsorientierte Tools, sicherheitsorientierte Tools), sondern auch die Tatsache, dass eine Reihe unterschiedlicher Anwendungsfälle angesprochen werden.

„Wir müssen ziemlich genau sagen, um welches Risiko oder welchen Anwendungsfall es sich handelt, um die richtigen Softwarelösungen oder den richtigen Gesamtlösungs-Stack zu finden, um diese zu lösen“, erklärt Sharon Chand, Cyber Leiter der risikosicheren Lieferkette für den Bereich Cyber ​​Risk Services von Deloitte. „Denn welche Art von Lösung ich wirklich benötige, hängt davon ab, wo ich mich in diesem Sicherheitsszenario der Software-Lieferkette befinde. Wenn ich ein Softwareproduzent bin, sieht es anders aus, als wenn ich ein Softwarekonsument bin. Und noch häufiger.“ Nicht jeder wird an bestimmten Punkten im gesamten Lebenszyklus der Lieferkette beides erreichen.“

Wie Unternehmen das alles zusammenstellen, hängt stark von ihren Anwendungsfällen, ihrer Infrastruktur sowie der Zusammensetzung der Fähigkeiten und der Kultur ihrer Teams ab. Leider gibt es noch keine einfache Schaltfläche zum Aufbau dieses Stapels.

Die folgende Liste bietet CISOs eine gute Einstiegscheckliste für die Planung des Software-Supply-Chain-Sicherheitslösungspakets, das für sie geeignet ist. Die Liste ist nicht zu 100 % vollständig – und wird sich wahrscheinlich schnell ändern. Aber es umfasst die wichtigsten Toolkategorien und Funktionen, die Sicherheitsverantwortliche wahrscheinlich für ihre Roadmap für die Sicherheit der Software-Lieferkette berücksichtigen möchten.

SCA-Tools sind derzeit vielleicht vor allem für ihre Rolle bei der Sicherheit der Software-Lieferkette bekannt, aber die Entstehungsgeschichte dieser Kategorie begann in noch prosaischerem Terrain. Diese Tools wurden ursprünglich entwickelt, um Entwicklerteams dabei zu unterstützen, die Nutzung ihrer Open-Source-Komponenten in ihren Builds zu verfolgen und so die Lizenzkonformität in den Griff zu bekommen. Als die Sicherheit der Lieferkette immer mehr an Bedeutung gewann, integrierten SCA-Tools eine tiefergehende Analyse und Verwaltung von Schwachstellen und Sicherheitsrisiken im Zusammenhang mit den verfolgten Komponenten und wurden zu einer der wichtigsten Methoden für Unternehmen, um SBOMs zu erstellen und ihre Open-Source-Nutzung zu steuern. Mend.io (ehemals WhiteSource), FOSSA und Synopsys Black Duck sind Paradebeispiele für diesen Evolutionspfad.

SCA ist nicht die einzige Option zum Generieren von SBOMs. Zu den weiteren SBOM-Generierungsmethoden gehören die Verwendung von Befehlszeilenschnittstellen-Tools (CLI) wie CycloneDX CLI und SPDX Tool, Laufzeitanalysen wie Rezilion oder Binäranalysen wie ReversingLabs. Für Anbieter, die Software-Supply-Chain-Lösungs-Stacks oder -Ökosysteme aufbauen, ist SCA jedoch in der Regel von entscheidender Bedeutung. Einige von ihnen sind SCA-Anbieter, die sich durch interne Entwicklung oder Akquisition auch auf die anderen unten beschriebenen Tool-Kategorien spezialisiert haben. Andere haben möglicherweise von Anfang an mit einer Plattformmentalität begonnen, bei der die Entwickler im Mittelpunkt standen, einschließlich SCA in einer Mischung aus Supply-Chain-Tools; Snyk ist ein gutes Beispiel dafür. Es gab auch weitere Partnerschaften wie die kürzlich zwischen Synopsys und ReversingLabs angekündigte, die die Sicherheitsfunktionen der Lieferkette erweitert, ohne Kunden an eine einzige Plattform zu binden.

Die Absicherung der Softwarelieferkette im Kern ist ein Appsec-Problem. Daraus folgt nur, dass herkömmliche Appsec-Code-Scanning-Tools in diesem Lösungspaket eine Rolle spielen werden. Die Tools SAST (Static Application Security Testing), DAST (Dynamic Application Security Testing), IAST (Interactive Application Security Testing) und RASP (Runtime Application Scanning Protection) sowie der umsichtige Einsatz von Penetrationstests können Unternehmen dabei helfen, ihren eigenen internen Code zu testen Bieten Sie weitere Überprüfungen des Codes von Drittanbietern an, um als Rückhalt für Risiken zu fungieren, die „ansonsten mit gängigen SCA- oder SBOM-Testtools und -Techniken übersehen werden könnten“, sagt Born of Coalfire.

Die Beibehaltung mehrerer Ebenen während eines vollständigen Code-Scans ist seiner Meinung nach von entscheidender Bedeutung, ebenso wie die stichprobenartigen Penetrationstests.

„SCA- und SBOM-Produkte stützen sich auf bekannte, zuvor identifizierte Schwachstellen, wohingegen eine gründliche Bewertung der Anwendungsdurchdringung bei der Untersuchung von Bibliotheken und Frameworks von Drittanbietern die Nutzung anfälliger Codes aufdecken kann, die zuvor an anderer Stelle möglicherweise nicht gemeldet wurden“, sagt er.

Da Unternehmen ihre eigenen SBOMs erstellen und SBOMs von ihren Anbietern übernehmen, wird die Aggregation, Anreicherung und Verwaltung dieser Artefakte ein immer wichtigerer Teil ihrer Operationalisierung sein. Beispielsweise wird das Hinzufügen von VEX-Informationen (Vulnerability Exploitability Exchange) ein immer wichtigerer Bestandteil der Kontextualisierung von SBOMs sein. Zu den Daten, mit denen diese Tools möglicherweise SBOM-Informationen anreichern könnten, gehören auch Komponentenzustandsprüfungen wie die OpenSSF Scorecard-Daten und Exploit Prediction Scoring System (EPSS)-Scores aus der Known Exploited Vulnerabilities (KEV)-Datenbank von CISA.

Darüber hinaus wird die einfache Aggregation von SBOM-Informationen über Softwareportfolios und Geschäftsbereiche hinweg ein wachsendes Anliegen für Sicherheitsverantwortliche sein. Dies ist immer noch ein neu entstehender Bereich, der sich noch nicht wirklich zu einer von Branchenanalysten identifizierten Kategorie entwickelt hat. Daher müssen CISOs nach diesen Funktionen in SCA+-ähnlichen Tools, Open-Source-Tools und neuen Plattformen suchen, die ihren Erwartungen entsprechen ihre eigenen kategoriedefinierenden Pfade. Einige Beispiele sind Cybellum, Anchore und Rezilion sowie neue Open-Source-Tools wie Bomber.

Das Scannen und Verwalten gemeinsamer Geheimnisse entwickelt sich schnell von der Kategorie eigenständiger Tools zu einer Funktion, die in jede Art von Software-Supply-Chain-Sicherheitstools integriert wird. Das liegt daran, dass in Quellcode, Konfigurationsdateien und Infrastrukturcode eingebettete Geheimnisse in Entwicklungs- und Live-Umgebungen immer noch weit verbreitet sind und es dringend erforderlich ist, das Problem in den Griff zu bekommen.

„Geheimnisse wie Anmeldedatendateien, private Schlüssel, Passwörter und API-Tokens sollten nicht in einem Quellcodeverwaltungs-Repository gespeichert werden“, empfiehlt ein kürzlich aktualisierter Gartner-Bericht. „Verwenden Sie ein Secrets-Management-Tool, um Geheimnisse sicher zu speichern und zu verschlüsseln, Zugriffskontrollen durchzusetzen und Geheimnisse zu verwalten (d. h. erstellen, rotieren und widerrufen).“

Dabei handelt es sich um eine grundlegende Werkzeugkomponente, da Angreifer gemeinsame Geheimnisse ausnutzen können, um die Integrität der Software-Lieferkette eines Unternehmens vollständig zu untergraben.

Abhängigkeitsmanagement und -analyse sind eine weitere etwas unklare Kategorie mit einem hohen Grad an Überschneidungen mit anderen Werkzeugkategorien wie SCA und SBOM-Aggregation. Aber es lohnt sich, darauf hinzuweisen, denn es bringt einige der schwerwiegendsten Sicherheitsprobleme der Software-Lieferkette auf den Punkt.

Eine der größten Beschwerden von Sicherheitsbefürwortern über den heutigen Zustand von SBOMs ist, dass sie immer noch Schwierigkeiten haben, transitive Abhängigkeiten im Zusammenhang mit der aufgezählten Software zu kommunizieren.

CISOs und ihre Teams benötigen bessere Möglichkeiten, um das verborgene Abhängigkeitsnetz, das sich über ihre Anwendungen, APIs, CI/CD-Pipeline-Komponenten und Infrastruktur als Code erstreckt, abzubilden und zu verwalten. Zu den verfügbaren Tools gehören Abhängigkeitszuordnungstools, auf die sich Leistungs- und Belastbarkeitsbeteiligte ebenfalls stützen, beispielsweise die von Datadog und Atlassian. Darüber hinaus integrieren SCAs und SBOM-Management-Tools diese Funktionen häufig in ihren Mix. Ein bemerkenswerter Akteur, der kürzlich in diesem Bereich auf den Markt kam, ist Endor Labs, das im Oktober 2022 aus dem Stealth-Modus kam und sich selbst als „Dependency Lifecycle Management“-Lösung bezeichnete. Letzten Monat war das Unternehmen Finalist in der Innovation Sandbox der RSA Conference.

Obwohl Artefakt-Repositorys und Container-Register per se keine Sicherheitstools sind, kann ihre Verwendung zusammen mit disziplinierten Richtlinien und Verfahren eine große Rolle bei der Bewältigung von Risiken in der Lieferkette spielen. Das Einrichten vertrauenswürdiger Artefakt-Repositorys und Container-Registrierungen ist ein grundlegender Bestandteil der Infrastruktur zur Einrichtung „sicherer Leitplanken“ für Entwickler. Das Anbieten zentralisierter Quellen genehmigter Komponenten ist eine proaktive Möglichkeit, Probleme zu vermeiden und eine solide Steuerung dessen zu etablieren, was in die Software eines Unternehmens einfließt.

„Die Repositories fungieren als vertrauenswürdige Quelle für sanktionierte und überprüfte Artefakte und Softwarekomponenten“, schreiben die Analysten von Gartner. „Dies ermöglicht eine zentralisierte Governance, Sichtbarkeit, Überprüfbarkeit und Rückverfolgbarkeit bis hin zu Software-‚Bestandteilen‘.“

Das Signieren von Code wird immer mehr zur bewährten Methode, um die Integrität von Code und Containern sicherzustellen, während Entwickler Software über ihren Lebenszyklus hinweg festschreiben und bereitstellen. Es handelt sich um einen Prozess, der nicht nur für den Aufbau starker interner Kontrollen gegen Manipulationen von entscheidender Bedeutung ist, sondern auch für den Aufbau des Kundenvertrauens in Produkte, die an externe Kunden versendet werden. Natürlich sind Code-Signing-Zertifikate ein beliebtes Ziel für Angreifer in der Software-Lieferkette. Daher müssen CISOs und ihre Teams sicherstellen, dass sie die richtigen Tools auswählen und Kontrollen einrichten, um sicherzustellen, dass ihr Code-Signing-Prozess wirklich sicher ist. Zu den Schwergewichten in dieser Kategorie gehören Garantir, Keyfactor, CircleCI, Cosign und Venafi.

Die Continuous-Integration-/Continuous-Delivery-Pipeline ist Teil der Software-„Fabrik“, auf die sich Entwickler bei der Erstellung ihres Codes stützen, und daher ein wesentlicher Bestandteil der gesamten Lieferkette. Daher sind Sicherheitstools zur Absicherung dieser Umgebungen Teil eines soliden Sicherheitsprogramms für die Lieferkette. Wir haben uns bereits mit dem Geheimnismanagement befasst, einem wichtigen Aspekt dieser Kategorie. Andere umfassen CI/CD-Richtlinien und Governance-Management, wie sie Unternehmen wie Apiiro und Cycode produzieren, sowie gut implementierte privilegierte Zugriffskontrolle und starke Authentifizierung.

Die meisten der bisher beschriebenen Tools konzentrieren sich in erster Linie darauf, tief in die Komponenten von Drittanbietern einzudringen, die in intern entwickelter Software verwendet werden. Aber was ist mit all der kommerziellen Software von Drittanbietern, über die Unternehmen nicht so viel Einblick haben? Hier spielen Tools und Prozesse für das Risikomanagement von Drittanbietern (TPRM) eine Rolle. Auch wenn die bundesstaatlichen SBOM-Anforderungen in den kommenden Jahren für mehr Transparenz bei Softwareanbietern sorgen, sind die meisten Unternehmen derzeit ziemlich blind. Obwohl TPRM-Risikobewertungstools wie SecurityScorecard oder RiskRecon dieses Problem nicht vollständig lösen können, können sie zumindest als Stellvertreter für Risiken fungieren, die Unternehmen potenziell dazu veranlassen könnten, herauszufinden, wo sie mit bestimmten Anbietern und Softwareanbietern zusammenarbeiten müssen, um tiefer in ihre Risiken einzutauchen Code.

„Ich denke, das TPRM-Angebot kann dann von Nutzen sein, wenn es ein Risiko gibt und ich in der Lage bin, es zu erkennen. Vielleicht möchte ich meine Bemühungen wirklich auf SCA und das Verständnis der Zusammensetzung der Software konzentrieren“, sagt Chand von Deloitte. „Es wird eher zu einer Risikominderungstechnik als zu einer Erdnussbutterlösung, die ich über die gesamte Software verteile, die ich produziere oder erwerbe.“

Sie sagt, dass es in der Welt der Software-Lieferkettensicherheit immer noch an einer soliden Tool-Verbindung zwischen Appsec-Risiken und Geschäftsrisiken mangelt, und glaubt, dass die nächste große Chance für Innovation wahrscheinlich darin liegen wird, wie Anbieter und Praktiker TPRM-Plattformen und ein breiteres Supply Chain Risk Management (SCRM) verknüpfen können ) Prozesse mit Daten aus SBOMs und der CI/CD-Pipeline.

Die zugrunde liegende Infrastruktur, die zum Testen und Bereitstellen von Code verwendet wird, ist auch der Code selbst und ein grundlegender Bestandteil der Lieferkette. Daher sollten CISOs zumindest die Einbindung von Infrastructure-as-Code (IaC)-Scans und Sicherheitstools als Teil ihrer umfassenderen Sicherheitsinitiative für die Lieferkette in Betracht ziehen. Diese Tools bewegen sich tendenziell an der Grenze zwischen Software-Supply-Chain-Sicherheitstools und Cloud-nativen Anwendungsschutzplattformen (CNAPP), was wohl damit beginnt, in den Bereich der Cloud-Sicherheit und des allgemeinen Sicherheitsbetriebs vorzudringen. Aber CNAPP bietet noch viele weitere Unterstützungsangebote für die Sicherheit der Lieferkette, insbesondere im Hinblick auf Containertransparenz und Laufzeitsicherheit. Container sind ein wachsendes Angriffsziel in der Software-Lieferkette und Laufzeitsicherheitsmaßnahmen können eine Absicherung für Workloads bieten, sobald sie in Produktion gehen.

Copyright © 2023 IDG Communications, Inc.