In den letzten Jahren wurde viel darüber geschrieben SBOM – Software-Stückliste. Bei all dieser Offenlegung haben die Leute das Gefühl, dass sie gut genug wissen, was es zu erklären gilt – es handelt sich um eine Liste von Softwarebestandteilen, es ist wichtig für Transparenz und Sicherheit und es hilft dabei, vorübergehende Abhängigkeiten aufzudecken. Das alles ist wahr.
Dennoch ist die SBOM nicht so eindeutig, wie es scheint. Bedenken Sie zum einen, dass für jede neue Bibliotheksversion oder jeden neuen Patch die Veröffentlichung eines neuen SBOM erforderlich ist, um auf dem neuesten Stand zu bleiben. Oft ändern oder patchen Sie jeweils nur eine oder zwei Bibliotheken, sodass Sie einfach deren neue Bestandteile aufschlüsseln, diese zur SBOM hinzufügen und alles andere beim Alten lassen können, oder?
Und was ist mit dem Konzept des „Bekannt-Unbekannten“? Wenn die Entwickler wissen, dass ihnen etwas fehlt, können sie es als „Bekannt-unbekannt“ eingeben und die Lücken später (oder gar nicht) ergänzen.
Es gibt auch Software-Artefakte, die sehr komplex sind und mehrere ineinandergreifende Elemente umfassen, von denen jedes ein eigenständiges Software-Artefakt ist. Jedes Element hat oft seine eigene, separate SBOM, und der gesamte Build kann eine größere, aggregierte SBOM haben.
Dies alles zeigt, dass Sie anstelle einer klaren, einfachen SBOM-Datei möglicherweise eine Vielzahl verschiedener, sich ständig ändernder Elemente erhalten, die Sie ständig so aktuell wie möglich halten müssen.
Das ist alles schön und gut, aber welchen Unterschied würde es für irgendjemanden machen, wenn eine SBOM oder ein Teil einer SBOM nicht so genau oder aktuell wäre, wie sie sein könnten? Was können wir tun, um sowohl die Herkunft als auch die Genauigkeit des SBOM zu bewahren?
In diesem Artikel untersuchen wir die Verwendung des SBOM bei Schwachstellenscans und der Offenlegung von Schwachstellen. Wir werden über kryptografisches Signieren sprechen und sehen, wie das Signieren eines SBOM oder von Teilen davon es als Sicherheits- und Transparenztool nützlicher macht. Wir werden auch über Metadaten sprechen und warum sie bei der SBOM- und anderen Artefaktproduktion so wichtig sind, insbesondere wenn sie kryptografisch in einer Bescheinigung angemeldet sind.
Beginnen Sie hier: Was ist kryptografisches Signieren überhaupt?
Mit kryptografischen Signaturen wird die Integrität und Richtigkeit digitaler Dateien oder Ordner überprüft. Eine signierte Datei kann nicht manipuliert werden, ohne dass die Signatur ungültig wird. Daher würde sie sofort entdeckt, sobald jemand versucht, das signierte Dokument zu überprüfen.
Das macht digitale Signaturen zu einem unschätzbar wertvollen Werkzeug im Arsenal der Software-Sicherheit Industrie und es gibt bereits zahlreiche Anwendungen für das einfache Konzept der digitalen oder kryptografischen Signatur digitaler Assets.
Wie funktioniert es? Digitale Signaturen basieren auf asymmetrischer Kryptographie, bei der eine Entität über zwei Schlüssel verfügt – einen privaten Schlüssel und einen öffentlichen Schlüssel. Die beiden Schlüssel sind so miteinander verknüpft, dass ein mit dem privaten Schlüssel signiertes Dokument mit dem öffentlichen Schlüssel verifiziert werden kann. Eine Überprüfung würde sowohl bedeuten, dass das Dokument in keiner Weise manipuliert wurde (selbst die Änderung eines einzigen Bits würde die Signatur nicht mehr überprüfen) als auch die Identität des Unterzeichners oder zumindest die Identität des verwendeten Schlüssels beweisen.
Was machen Sie mit dieser SBOM?
SBOMs sind nicht nur lange, komplizierte Dateien mit Informationen zu Softwarekomponenten. Sie sind Ihr Tor, um genau zu wissen, aus welchen Komponenten Ihr Software-Artefakt besteht. Sie müssen die vollständige Komponentenliste kennen, denn auch wenn Sie denken, Sie wüssten genau, was Sie eingebunden haben, ist die Wahrscheinlichkeit groß, dass mit jeder hinzugefügten Bibliothek, die Sie ausgeliefert haben, zahlreiche versteckte und vorübergehende Abhängigkeiten entstehen, von denen jede Träger einer Schwachstelle sein oder diese ausnutzen könnte ist jetzt in der Software enthalten, die Sie an Ihre Kunden versenden.
Sobald Sie über eine SBOM und die vollständige Liste der Inhaltsstoffe verfügen, können Sie diese Liste anhand bekannter Schwachstellendatenbanken scannen und sehen, welche Schwachstellen in Ihrer Software enthalten sind. Aber das ist erst der Anfang. Wie jeder, der schon einmal einen Schwachstellenscan durchgeführt hat, weiß, können die Ergebnisse selbst eines einfachen Artefaktscans leicht Hunderte (oder mehr) Schwachstellen umfassen.
Hier beginnt die harte Arbeit, jede Schwachstelle zu kartieren, zu sehen, ob sie in Ihrer spezifischen Softwarezusammensetzung ausnutzbar sein könnte, diese Informationen zu dokumentieren und mit den ausnutzbaren Schwachstellen umzugehen, indem Sie sie patchen und beheben, vorzugsweise in der Reihenfolge der Gefahr, die sie darstellen (live). Exploits in freier Wildbahn sind gefährlicher als ein theoretischer Exploit, der noch nie stattgefunden hat.
All diese Arbeiten sowie die Dokumentation und Behebung von Schwachstellen sind für Sie als Softwarehersteller wichtig, aber auch für Ihre Kunden, Partner und potenziellen Prüfer.
Sie möchten wissen, dass Sie sich potenzieller Schwachstellen bewusst sind und dass Sie den Überblick behalten und Fehler beheben und beheben, damit diese keine Auswirkungen auf SIE als Ihre Kunden oder Partner haben.
Da die Zeit, die Sie für einen Scan benötigen, in dieser Hinsicht wichtig ist, da ständig neue Schwachstellen ans Licht kommen, ist das Signieren Ihres SBOM zusammen mit den Metadaten, wann es erstellt wurde, eine gute Möglichkeit zu zeigen, dass Sie wirklich auf dem Laufenden sind Ihrer Schwachstellenliste.
Auf diese Weise können Sie nachweisen, dass Sie von einer Sicherheitslücke im Voraus wussten und diese nicht relevant ist (mithilfe eines ÄRGERN Hinweis), dass es in einer bestimmten Version nicht vorhanden ist oder dass es zum Zeitpunkt der Veröffentlichung Ihrer letzten Version noch nicht einmal existierte.
Wo kann ich mich anmelden?
Ersetzen wir nun diese einfache Zutatenlistendatei durch einen der komplexeren Anwendungsfälle, die am Anfang des Artikels beschrieben wurden. Sobald Sie mehrere SBOMs zu einer größeren, aggregierten Version zur Beschreibung Ihres vollständigen Artefakts zusammengefasst haben, wird das Signieren und Überprüfen jedes einzelnen Teils dieser aggregierten Version immer wichtiger. Nehmen wir an, Sie erstellen eine neue Version eines komplexen Software-Artefakts. In dieser neuen Version hat sich nur Teil 1 eines dreiteiligen Artefakts geändert. Die anderen beiden Teile bleiben genau gleich. Warum sollten Sie Zeit und Ressourcen damit verschwenden, das vollständige dreiteilige SBOM zu erstellen, alle drei auf Schwachstellen zu scannen und alle drei auf relevante Exploits abzubilden? Die einzigen Änderungen gab es in Teil 3, also ist dies der einzige, in den Sie die Arbeit investieren sollten. Wenn Sie bei der letzten Erstellung alle drei SBOMs und Schwachstellenscans signiert haben, können Sie die Informationen der anderen beiden Teile mit dem Wissen einbeziehen, dass dies möglich ist. Es wurde nicht geändert. Sie können dann jederzeit nachweisen, dass die SBOMs für die Teile 3 und 3 mit den Originalversionen identisch sind. Sie können die Scans natürlich noch einmal durchführen, wenn Sie Angst vor neuen Schwachstellen haben, aber das liegt ganz bei Ihnen und Ihrer Software Risikoanalyse.
Es ist aus zahlreichen Gründen nützlich, Ihren Kunden, Partnern und Prüfern nachweisen zu können, wann und wie oft Sie SBOMs erstellt und auf Schwachstellen überprüft haben. Nicht zuletzt kann es vor Gericht dazu verwendet werden, zu beweisen, dass Sie nicht für den Schaden eines Exploits haftbar sind, da Sie alles getan haben, um geschützt zu werden, und dadurch eine Entschädigung erhalten haben sicherer Hafen.
Von hier aus weiter
Wie bereits erwähnt, ist eines der Probleme beim digitalen Signieren von Softwareartefakten oder Dateien der Aufwand im Umgang mit Schlüsselverwaltungssystemen. Sobald wir diesen Aufwand beseitigen, indem wir etwas wie Sigstore verwenden, um die Verwendung einer herkömmlichen PKI zu umgehen und den Signatur- und Verifizierungsablauf zu automatisieren, gibt es kaum einen Grund, dieses Sicherheitstool nicht zu verwenden. Wenn Sie bedenken, dass die Identität, die zum Signieren einer Datei oder eines Artefakts verwendet wird, auch in einer Richtlinie zur Überprüfung der Sicherheit Ihrer CI/CD-Pipeline verwendet werden kann, sollten Sie noch motivierter sein, damit zu beginnen, fast alles zu signieren, was Ihnen in den Sinn kommt.
Das Signieren von Dateien mit ihren Metadaten kann Ihnen helfen, den Zeitpunkt und Ort ihrer Entstehung sowie die Person und das System, in dem sie erstellt wurden, zu überprüfen – alles relevante Informationen, wenn man sie durch die Brille eines Sicherheitsspezialisten betrachtet. Zu erkennen, ob die Person, das System und die Zeit mit dem Unternehmen und der Pipeline übereinstimmen, in der die Software erstellt wurde, ist eine gute Idee, wenn ein einfacher Ersatz eine unterschriebene, überzeugende Fälschung darstellen kann – bis die singende Person überprüft wird.
Wenn man bedenkt, dass die Nutzung des Tools, das ich zum Signieren und Überprüfen von Beweismitteln vorschlagen würde, kostenlos ist, sollten Sie wirklich keine Entschuldigung haben. Schauen Sie sich unseren vollständigen Artikel an Valint – unser Validation-Integrity-Tool, um zu sehen, was Sie sonst noch damit machen können, und beginnen Sie noch heute mit der Signierung Ihrer SBOMs und anderer generierter Beweise.
Diese Inhalte werden Ihnen von Scribe Security zur Verfügung gestellt, einem führenden Anbieter von End-to-End-Sicherheitslösungen für die Software-Lieferkette, der modernste Sicherheit für Code-Artefakte sowie Code-Entwicklungs- und Bereitstellungsprozesse in der gesamten Software-Lieferkette bietet. Weitere Informationen.
Zusammenhängende Artikel
