Da Entwickler zunehmend unter Druck geraten, Projekte schnell zu liefern, kommt es zu zunehmenden Konflikten zwischen Entwicklungs-und Sicherheitsteams. Und Angreifer nutzen diesen Konflikt aus, um Softwarelieferketten anzugreifen.
Welchen Bedrohungen sind Unternehmen also ausgesetzt und was können sie tun, um sich zu schützen? Wir haben mit Pete Morgan, Mitbegründer und CSO des Lieferkettensicherheitsunternehmens Phylum gesprochen, um es herauszufinden.
BN: Warum ist die Softwarelieferkette ein so attraktives Ziel für Angreifer?
PM: Es gibt drei Hauptgründe, warum schlechte Akteure auf Softwarelieferketten abzielen:
Entwickler sind die neuen High-Value Ziele: Angreifer kennen die Ziele einer Lieferung Chain Compromise sind Softwareentwickler oder privilegierte Infrastrukturen. Die Kompromittierung eines der beiden Ziele führt zu Cloud-Zugriffsschlüsseln, SSH-Schlüsseln, Signaturschlüsseln und anderen Geheimnissen. Diese Schlüssel haben oft eine lange Lebensdauer, was bedeutet, dass eine unentdeckte Kompromittierung Angreifern viel Zugriff und Zeit gibt, um die nächsten Schritte sorgfältig zu planen. Es gibt eine Reihe blinder Flecken, die es auszunutzen gilt: Die Software-Lieferkette ist ein sich ständig änderndes Konzept. Open-Source-Pakete werden in 85 Prozent – 95 Prozent der Anwendungen verwendet und von Fremden im Internet erstellt und gepflegt. Entwickler verwenden diese Pakete ohne Aufsicht oder Kontrolle durch das Sicherheitsteam. Das Abbilden der wahren Angriffsfläche für die Software-Lieferkette eines Unternehmens ist kompliziert und variiert je nach Unternehmen und hinterlässt viele Lücken. Es ist noch schwieriger, es im Laufe der Zeit konstant zu halten, was Angreifern verschiedene Möglichkeiten bietet. Die Verteidigung muss perfekt sein, Angreifer müssen nur einmal gewinnen. Niedrige Investitionen für große Gewinne: Die Kosten für einen Angriff auf die Softwarelieferkette sind extrem niedrig und oft kostenlos. Einige Angriffe erfordern nur die Ausführung eines Skripts und das Warten. Bis Unternehmen ihre Sicherheitsprogramme für die Software-Lieferkette verbessern, wissen Angreifer, dass sie nicht so hart arbeiten oder ausgeklügelte Angriffe verwenden müssen, um erfolgreich zu sein.
BN: Was sind die größten Reibungspunkte zwischen Entwicklungs-und Sicherheitsteams?
PM: Sicherheitsteams wollen mehr Transparenz und Kontrolle über den Entwicklungsprozess, und Entwickler wollen möglichst wenige Hindernisse für Innovationen wie möglich. Wenn Ziele, Richtlinien und Prozesse nicht gut aufeinander abgestimmt sind oder in diesem Fall oft widersprüchlich sind, kommt es natürlich zu Spannungen.
BN: Wie kann Sicherheit die Beziehung zu Entwicklungsteams verbessern?
PM: Empathie ist ein enormer Faktor, wenn es darum geht, Gemeinsamkeiten zwischen diesen beiden Teams zu finden, und es ist wichtig, dass diese beiden Teams harmonisch zusammenarbeiten, um wichtige Geschäftsziele zu erreichen. Sicherheitsteams sollten Entwickler in die frühen Phasen der Sicherheitsentscheidungen einbeziehen und es ihnen leicht machen, Richtlinien zu übernehmen, und Entwickler sollten aufgeschlossen bleiben, wenn sie gebeten werden, Sicherheitspraktiken in ihre Prozesse zu integrieren. Offene Kommunikationswege, regelmäßiges Feedback darüber, was funktioniert und was nicht funktioniert, und die Einführung von Technologien, die die Durchsetzung von Richtlinien automatisieren und Probleme kontextualisieren, ohne den Entwicklungsprozess zu unterbrechen, werden zu einer effektiveren Zusammenarbeit führen.
BN: Warum ist Malware in Open-Source-Paketen so gefährlich?
PM: Oh, wo soll ich anfangen! Bösartige Pakete unterscheiden sich von herkömmlicher Malware darin, dass die meisten bösartigen Pakete keine Schwachstellen ausnutzen oder einen Benutzer dazu verleiten müssen, sie auszuführen. Ein Entwickler, der das falsche Paket installiert oder ein Paket mit der falschen Abhängigkeit installiert, kann kompromittiert werden, und in 99 Prozent der Fälle werden sie es nie erfahren.
Die meisten Entwickler haben einfach nicht die Zeit oder die Tools für eine Analyse das Risiko der von ihnen verwendeten Verpackungen. Pakete haben Abhängigkeiten, die Abhängigkeiten haben, und diese Kette kann 20-30 Ebenen umfassen und Zehntausende von Open-Source-Paketen umfassen. Die meisten Organisationen scannen immer noch nur nach Schwachstellen und Lizenzmissbrauch, sodass Malware leicht unentdeckt bleibt: Es ist ein Zerschlagen und Greifen nach Schlüsseln und Geheimnissen, um dann weitere Angriffe zu starten.
BN: Welche sind einige Andere Risiken im Zusammenhang mit Open-Source-Code, die oft übersehen werden?
PM: Es gibt viele, aber eines sticht besonders hervor, der Betreuerwechsel. Es handelt sich nicht um eine Software-Schwachstelle oder ein bösartiges Paket; Es ist eines von vielen Autorenrisiken, die sich aus gängigen Praktiken im Open-Source-Ökosystem ergeben. Manchmal hat ein Entwickler nicht mehr das Interesse oder die Zeit, ein beliebtes Open-Source-Paket zu pflegen. Sie möchten es oft für die Benutzer funktionsfähig halten, die sich darauf verlassen, und geben die Betreuerschaft an eine andere Person oder Gruppe ab. Es ist unglaublich schwierig, die Motive und Anreize des neuen Betreuers zu überprüfen, also wird die Kontrolle über diese Pakete einfach in die Hände eines anderen Fremden aus dem Internet gelegt. Wenn ein böswilliger Autor die Kontrolle über ein Paket übernimmt, das in einer Anwendung verwendet wird, führt dies zu einem neuen Risiko, das im ursprünglichen Build nicht berücksichtigt wurde.
BN: Wie wichtig ist es, sich dessen bewusst zu sein und Abhängigkeiten verwalten?
PM: Wir sollten Abhängigkeiten kritisch gegenüberstehen, da die langfristige Einbeziehung jedes Pakets die Angriffsfläche drastisch erweitert. Wir müssen das Risiko der Wiederverwendung von Code verstehen, der sich ständig ändert, um Software effektiv zu schützen. Andernfalls werden Unternehmen weiterhin Code von Fremden aus dem Internet mit der Strategie wiederverwenden, nur das Beste zu hoffen. Das ist der Grund, warum die Softwarelieferkette gerade so viel in den Nachrichten ist.
BN: Wie können SBOMs zu Sichtbarkeit und Sicherheit beitragen?
PM: SBOMs sind ein Schritt in die richtige Richtung, aber ich befürchte, dass Vorschriften und Mandate zur umfassenden Einführung des SBOM-Prozesses zu viel Bewegung führen werden, ohne dass die Softwaresicherheit sinnvoll verbessert wird. Die Idee, Einblick in die Komponenten eines Softwareprojekts zu bekommen, ist ein Kinderspiel, aber der SBOM-Prozess, den ich herumgereicht sehe, ist kläglich mangelhaft, da er nur unvollständige Momentaufnahmen liefert.
Die von SBOM bereitgestellten Informationen reicht nicht aus, um die Angriffsfläche der Softwarelieferkette abzudecken, und die Auswirkungen für Anbieter-und Verbraucherorganisationen, den Prozess der Verwendung von SBOM zu übernehmen, gehen von einer Realität aus, in der die Budgets für Anwendungssicherheit und/oder Produktsicherheit praktisch unbegrenzt sind. SBOM-Formate und-Prozesse müssen sich erheblich weiterentwickeln, bevor sie sinnvoll übernommen werden können.
BN: Welche Standards, Normen oder Verhaltensweisen müssen sich ändern, damit Unternehmen ihre Softwarelieferketten optimal schützen können?
PM: Ein grundlegender Mentalitätswandel ist erforderlich. Unternehmen müssen verstehen, dass sie jetzt und wahrscheinlich schon seit langer Zeit einem erheblichen Risiko in der Softwarelieferkette ausgesetzt sind. Die Sicherheit der Softwarelieferkette steckt noch in den Kinderschuhen, daher entwickeln sich Angriffe täglich weiter und Abwehrmaßnahmen wurden erst in den letzten Jahren geschaffen. Gehen Sie davon aus, dass Ihre Entwickler aktiv ins Visier genommen werden und dass Sie einem nicht erkannten Risiko in der Software-Lieferkette ausgesetzt sind. Sobald Sie das falsche Sicherheitsgefühl durchbrochen haben, können Sie an einem ehrlichen Ort beginnen, um ein effektives Programm aufzubauen, das basierend auf Ihren individuellen Bedürfnissen skaliert werden kann.
Bildnachweis: Manczurov/Shutterstock