![\"\"](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2022\/09\/01175034\/863x300.png\")
<\/p>\n<\/p>\n
Der von Unternehmen erstellte Code ist nur der Beginn der modernen Softwareentwicklung. Tats\u00e4chlich macht der Code von Erstanbietern oft nur einen kleinen Teil\u00a0\u2013 mitunter lediglich 10\u00a0%\u00a0\u2013 der Artefaktsammlung<\/a> einer Anwendung aus.<\/p>\n Die Software-Lieferkette eines Unternehmens umfasst zahlreiche Bestandteile aus unterschiedlichen Quellen: Open-Source-Paketen, kommerzieller Software, Infrastructure-as-code- bzw. IaC-Dateien, Containern, Betriebssystem-Images und mehr. Folglich sind bei der abzusichernden Lieferkette unz\u00e4hlige Risikopunkte<\/em> zu ber\u00fccksichtigen. Auch birgt sie aufgrund von menschlichen Fehlern und Nachl\u00e4ssigkeiten, schlechter Qualit\u00e4t sowie b\u00f6swilligen Angriffen ein gro\u00dfes Potenzial f\u00fcr Sicherheitsbedrohungen.<\/p>\n Das Wissen um diese anf\u00e4lligen Risikopunkte<\/em> ist f\u00fcr den Schutz Ihrer Software-Lieferkette <\/a>wichtig. Diese jedoch mit Einzell\u00f6sungen beheben zu wollen, ist Sisyphusarbeit\u00a0\u2013 eine an einem Punkt ausgemerzte Bedrohung kann sich leicht unerkannt an anderer Stelle erneut etablieren.<\/p>\n Der vollst\u00e4ndige Schutz Ihrer Lieferkette vor Bedrohungen erfordert durchg\u00e4ngige Wachsamkeit. Diese Wachsamkeit beginnt bereits, bevor Ihre Entwickler externe Pakete abrufen, und ist auch bei der Entwicklung von eigenem Code, der Codekompilierung, der Erstellung von Interim-Builds sowie der Ver\u00f6ffentlichung und Verteilung bis hin zur Produktion\u00a0\u2013 und sogar \u00fcber die Bereitstellung hinaus\u00a0\u2013 erforderlich. Dabei gilt es nicht nur, Schwachstellen und andere Sicherheitsprobleme aufzudecken. Ohne Kenntnisse des Kontexts k\u00f6nnen Sie das wahre Risiko nicht reell bewerten.<\/p>\n Bedrohungen der Software-Lieferkette lassen sich (grob) in zwei Kategorien unterteilen.<\/p>\n Bei der einen Art nutzen Angreifer die \u201eoffene Natur\u201c der Lieferkette, um Informationen \u00fcber die Software<\/em> zu gewinnen. Ein g\u00e4ngiges Beispiel ist der Versuch, einen Webdienst remote abzubilden oder eine Software f\u00fcr IoT-Devices einzuschleusen, um sich mit den verwendeten Open-Source-Paketen vertraut zu machen. F\u00fcr die Hacker ist es daraufhin ein Leichtes, mit diesen Paketen verbundene CVE-Informationen ausfindig zu machen, mehr \u00fcber die Sicherheitskonfigurationen der Pakete zu erfahren oder sogar noch unbekannte Schwachstellen (Zero-Day-L\u00fccken<\/a>) zu ermitteln. Nachdem Angreifer ausreichend Kenntnisse \u00fcber Angriffswege erlangt haben, k\u00f6nnen sie zum n\u00e4chsten Schritt \u00fcbergehen.<\/p>\n Dabei wird die Lieferkette genutzt, um \u00f6ffentliche oder private Repositorys mit sch\u00e4dlichen Paketen und Schadcode zu injizieren<\/em> oder vorhandenen Code zu ver\u00e4ndern.<\/p>\n Bedrohung der Software-Lieferketten \u00fcber zwei Angriffswege<\/em><\/p>\n Werfen wir einen Blick auf vier g\u00e4ngige Risiken f\u00fcr die Software-Lieferkette, die diese f\u00fcr Angriffe anf\u00e4llig machen k\u00f6nnen:<\/p>\n Komponenten von Drittanbietern\u00a0\u2013 wie etwa Open-Source- und kommerzielle Software\u00a0\u2013 k\u00f6nnen unbeabsichtigte Schwachstellen enthalten. Viele davon sind bekannt und in der CVE-Liste (Common Vulnerabilities and Exposure<\/a> = h\u00e4ufige Schwachstellen und Risiken) aufgef\u00fchrt.<\/p>\n Sie k\u00f6nnen diese Risiken mittels einer SCA-L\u00f6sung (Software Component Analysis)<\/a> aufdecken. Dabei wird die SBOM (Software Bill of Materials)<\/a> eines Codes oder Artefakts identifiziert und mit bekannten CVEs verglichen. F\u00fcr den Vergleich werden meist die Metadaten der identifizierten Software und \u00f6ffentliche CVE-Datenbanken herangezogen.<\/p>\n Sie ben\u00f6tigen jedoch auch ausreichend Informationen, um risikobasierte Entscheidungen treffen und automatisieren<\/a> zu k\u00f6nnen. Eine erweiterte Datenbank ist daf\u00fcr unabdingbar. Damit lassen sich nicht nur mehr Risiken verfolgen, sondern auch eingehende Sicherheitsuntersuchungen<\/a> durchf\u00fchren. Dies erm\u00f6glicht es Ihnen, alle Optionen zur Minderung dieser Risiken zu verstehen und die effektivste und kosteng\u00fcnstigste Methode zu w\u00e4hlen.<\/p>\n Gleicherma\u00dfen wichtig sind Kontextanalysen<\/a>, um die Angriffswahrscheinlichkeit \u00fcber die verschiedenen Sicherheitsl\u00fccken zu ermitteln. M\u00f6glicherweise wird eine anf\u00e4llige Funktion in einer Komponente nicht von der Anwendung genutzt oder ein anf\u00e4lliger Prozess nie in einer Produktionsversion ausgef\u00fchrt. Bestimmte Konfigurationen k\u00f6nnen eine CVE-Liste auch nutzlos machen.<\/p>\n Auch bei scheinbar sicheren Komponenten lassen sich potenzielle operationelle Risiken<\/a> erkennen. Ein seit L\u00e4ngerem nicht verwaltetes Open-Source-Paket wurde beispielsweise vielleicht auch nicht ausreichend hinsichtlich Sicherheitsproblemen \u00fcberwacht. In diesen F\u00e4llen besteht trotz fehlender Gewissheit hinsichtlich Schwachstellen ein erh\u00f6htes Bedrohungspotenzial.<\/p>\n Diese bekannten und potenziellen Risiken k\u00f6nnen und sollten an folgenden Punkten entdeckt werden:<\/p>\n Fehler sind bei der Codierung nichts Au\u00dfergew\u00f6hnliches. Logische Fehler, schlechte Verschl\u00fcsselungen und potenzielle Speichermanipulationen erh\u00f6hen die Anf\u00e4lligkeit von Anwendungen etwa f\u00fcr RCE- (Remote Code Execution) und DoS-Angriffe (Denial-of-Service). Diese Fehler k\u00f6nnen mitunter jahrelang unbemerkt in Code von Erst- und Drittanbietern lauern<\/a>, bevor sie erkannt werden.<\/p>\n Sie sind als \u201eZero-Day\u201c-Bedrohungen bekannt\u00a0\u2013 zum einen wegen der Dauer ihrer Bekanntheit, aber auch aufgrund dessen, dass Sicherheitsteams f\u00fcr die Behebung in bereits entwickelter Software \u201enull Tage\u201c haben.<\/p>\n Um potenzielle Zero-Day-Bedrohungen zu erkennen und zu vermeiden, m\u00fcssen alle Komponenten und Anwendungen getestet werden. Dabei ist die Interaktion zwischen unterschiedlichen Bin\u00e4rdateien, Prozessen und Diensten zu ber\u00fccksichtigen. Mit Tools f\u00fcr die statische Codeanalyse<\/a> (zur \u00dcberpr\u00fcfung der Codequelle) sowie die dynamische Codepr\u00fcfung (zum Testen des ausgef\u00fchrten Codes) lassen sich in der Regel 85\u00a0% der Fehler identifizieren. Dabei werden pro Release meist jedoch auch Tausende von Eintr\u00e4gen generiert, sodass Fachkenntnisse erforderlich sind, um die Ergebnisse zu interpretieren und zu priorisieren. Neben bekannten Problemen k\u00f6nnen auch Schwachstellen<\/a> existieren, die nicht zwingend angreifbar sind.<\/p>\n Mit fortschrittlicheren Technologien, die eine symbolische Ausf\u00fchrung, Datenflussanalysen und automatisiertes Fuzzing vereinen, k\u00f6nnen Sie den Anteil an Falschmeldungen drastisch reduzieren und Schwachstellen identifizieren, die mit konventionellen SAST- und DAST-Verfahren nicht erkennbar sind. Die kombinierte Analyse von Quell- und Bin\u00e4rdateien kann auch zu besseren Ergebnissen f\u00fchren. Dies erm\u00f6glicht es Entwicklern, Sicherheitsteams und Produktionsmanagern, sich auf die Behebung kritischer Fehler zu konzentrieren.<\/p>\n Trotz akribischer Ma\u00dfnahmen k\u00f6nnen jederzeit neue Schwachstellen erkannt werden und bereits bereitgestellte Software beeintr\u00e4chtigen. Ein kontinuierlicher SCA-Scan erm\u00f6glicht mitunter eine schnelle Benachrichtigung bez\u00fcglich brandaktueller CVEs, die sich auf Produktionssoftware auswirken. Mit umfangreichen SBOM-Metadaten<\/a> lassen sich die vollst\u00e4ndigen Auswirkungen einer Schwachstelle in Ihrem Unternehmen schnell ermitteln und mindern oder in allen Ihren Anwendungen beheben<\/a>. Durch die ordnungsgem\u00e4\u00dfe Integration mit Code und Artefakt-Repositorys k\u00f6nnen schnell innerhalb des gesamten Unternehmens Ma\u00dfnahmen ergriffen werden, um die identifizierte Bedrohung abzuschw\u00e4chen.<\/p>\n Nicht alle Schwachstellen sind im Code zu finden. Sie k\u00f6nnen sich auch in Bin\u00e4rdateien wie EPMs, Containern mit JAR-Dateien, Firmware sowie unterst\u00fctzenden Artefakten wie Konfigurations- oder IaC-Dateien verbergen. Fehlkonfigurationen, schlechte Verschl\u00fcsselung, die Offenlegung von Secrets und privaten Schl\u00fcsseln sowie Probleme mit dem Betriebssystem stellen potenzielle Angriffsfl\u00e4chen dar.<\/p>\n Diese Nebenprodukte menschlicher Fehler sind in der Regel auf Unachtsamkeit zur\u00fcckzuf\u00fchren und schleichen sich meist unauff\u00e4llig in gro\u00dfe Entwicklungsprojekte ein. Schnell f\u00fcr Testzwecke erstellte Konfigurationen k\u00f6nnen versehentlich f\u00fcr die Produktion bereitgestellt werden. Diese Risiken lassen sich oft leicht eliminieren, w\u00e4hrend sich die Erkennung und anschlie\u00dfende Systemwiederherstellung deutlich schwieriger gestalten.<\/p>\n Selbst kleine Versehen k\u00f6nnen gro\u00dfen Schaden anrichten. Der ber\u00fcchtigte Hackerangriff auf SolarWinds<\/a> begann mit einer Passwortoffenlegung auf einem \u00f6ffentlichen GitHub-Server<\/a>. Dadurch konnte sch\u00e4dlicher Code injiziert werden, der letztendlich zur Offenlegung vertraulicher Regierungsdaten f\u00fchrte. Verwirrung hinsichtlich der Abh\u00e4ngigkeit<\/a> zwischen Paketen mit \u00e4hnlichen Namen kann ebenfalls ohne b\u00f6se Absicht entstehen. Dies ist insbesondere bei einer schlecht konfigurierten Aufl\u00f6sung des Paket-Repositorys<\/a> der Fall.<\/p>\n Diese Probleme m\u00fcssen m\u00f6glichst fr\u00fch erkannt werden, bevor sie in die Produktion gelangen. Nehmen Sie diese potenziellen Risiken mindestens ebenso ernst, wie Sicherheitsl\u00fccken in Ihrem Code. Wenden Sie diese Wachsamkeit auch durchg\u00e4ngig auf den Sicherheitsstatus Ihrer Pipelines an.<\/p>\n Vors\u00e4tzliche Bedrohungen, egal, ob durch externe Angreifer oder b\u00f6swillige Insider, k\u00f6nnen am schwierigsten zu ermitteln sein. Diese Angriffe erfolgen h\u00e4ufig \u00fcber bereits \u00fcberpr\u00fcfte Komponenten. Trojaner, Bots, Ransomware, Cryptomining und Spyware werden oft als Nutzlasten mit den bereits er\u00f6rterten Schwachstellenarten eingeschleust. Das Infiltrieren beliebter Repositorys mit sch\u00e4dlichen Paketen, Hackerangriffe auf Administratorkonten, um vorhandene Pakete zu manipulieren, oder die Injektion von Code in kompromittierte Quell-Repositorys sind g\u00e4ngige Angriffsmethoden \u00fcber die Hintert\u00fcr.<\/p>\n Werden diese Angriffe erst nach der Bereitstellung erkannt, ist es in der Regel zu sp\u00e4t. Der Schaden ist bereits angerichtet und kann extrem kostspielig sein. Aus diesem Grund sollten Sie Ihre gesamte Pipeline davor sch\u00fctzen:<\/p>\n W\u00e4hrend sich einige dieser Risiken einzeln mindern lassen, sind Punktl\u00f6sungen lediglich Warnsysteme\u00a0\u2013 die nur da helfen, wo Sie sie gezielt einsetzen.<\/p>\n Auch separate Sicherheitsl\u00f6sungen n\u00fctzen daher nur bedingt. Infolge der begrenzten Reichweite kann damit nicht der vollst\u00e4ndige Kontext eines Risikos innerhalb der gesamten Software-Lieferkette analysiert und bewertet werden. Unabh\u00e4ngig von den Repositorys und den Softwareverwaltungsl\u00f6sungen w\u00e4re es selbst bei extrem genauen Punktl\u00f6sungen f\u00fcr die Sicherheit \u00e4u\u00dferst schwierig, das identifizierte Problem effektiv zu mindern oder zu beheben.<\/p>\n Ein umfassender Sicherheitsstatus muss Ihnen neben der \u00dcberwachung einzelner Pipeline-Punkte auch die M\u00f6glichkeit geben, die Zusammenh\u00e4nge zwischen verschiedenen Problemen und Sicherheitsrisiken zu verstehen\u00a0\u2013 was mit separaten Nischenl\u00f6sungen nicht zu bewerkstelligen ist.<\/p>\n F\u00fcr die Softwaresicherheit ist eine durchg\u00e4ngige Wachsamkeit wichtig. Diese beginnt bei der IDE des Entwicklers und endet in der Produktion. Sie erzwingt einen konsistenten \u00dcberblick \u00fcber die Risiken und erm\u00f6glicht deren Minderung in Entwicklungs- und Produktionsumgebungen gleicherma\u00dfen. Ihre Sicherheitsl\u00f6sungen m\u00fcssen Ihre Software-Lieferkette ganzheitlich sch\u00fctzen und umfangreiche Ma\u00dfnahmen erm\u00f6glichen. F\u00fcr die unternehmensweite Konsistenz ist es wichtig, dass die L\u00f6sung in einer zentralen Datenquelle f\u00fcr alle Ihre Bin\u00e4rdateien<\/a> ausgef\u00fchrt wird und umfangreich mit Ihren DevOps-Tools<\/a> integriert ist.<\/p>\nDie vier wichtigsten Trends bei den Risiken f\u00fcr Software-Lieferketten<\/h2>\n
![\"Software](\"https:\/\/media.jfrog.com\/wp-content\/uploads\/2022\/09\/22202257\/Software-supply-chain-attacks-Two-main-paths.png\")
<\/p>\n1. Bekannte Schwachstellen<\/h3>\n
\n
2. Unbekannte Schwachstellen (Zero-Day-Bedrohungen)<\/h3>\n
3. Nicht codespezifische Probleme<\/h3>\n
4. Sch\u00e4dlicher Code<\/h3>\n
\n
Durchg\u00e4ngige Wachsamkeit f\u00fcr das Risikomanagement der Software-Lieferkette<\/h2>\n