Nur wenn Sie wissen, was drinsteckt, können Sie sich sicher sein, dass alles mit rechten Dingen zugeht. Das gilt für Fast Food wie für Software.
Foto: Geka – shutterstock.com
Um Software abzusichern, muss man wissen, was in ihrem Code steckt. Aus diesem Grund ist eine Software Bill of Material, SBOM oder Software-Stückliste heute unerlässlich. Der SolarWinds-Angriff sowie die Log4j-Schwachstelle haben verdeutlicht, wie wichtig es ist, die Sicherheit von Softwarelieferketten in den Fokus zu nehmen – insbesondere, wenn es um Open Source Software geht. , der geht – SBOMs: Formale und maschinenlesbare Metadaten, die ein Softwarepaket und seinen Inhalt eindeutig identifizieren. Die Software-Stücklisten können auch andere Informationen enthalten, etwa Copyright- oder Lizenzdaten. Dabei ist eine Software Bill of Material so konzipiert, dass sie organisationsübergreifend ausgetauscht werden kann. Besonders hilfreich ist eine SBOM, um die Transparenz über die von den Teilnehmern einer Softwarelieferkette gelieferten Komponenten zu gewährleisten.
SBOM – Best Practices
Eine SBOM sollte beinhalten:
die Open-Source-Bibliotheken der Anwendung;
Plugins, Erweiterungen und andere Zusatzmodule;
von In-House-Entwicklern selbst geschriebenen Quellcode;
Informationen über die Versionen dieser Komponenten, ihren Lizenzierungs- und Patch-Status;
automatische kryptografische Signatur und Überprüfung von Komponenten;
automatische Scans, um SBOMs als Teil der CI/CD-Pipeline zu erstellen.
Dabei sollte eine Software Bill of Material ein einheitliches Format verwenden. Zu den gängigen SBOM-Formaten gehören:
Software Package Data Exchange (SPDX),
Software Identification (SWID) Tagging und
OWASP CycloneDX.
Bislang hat sich keiner der drei Standards von den anderen abgesetzt und einen De-facto-Industriestandard geschaffen. Um SBOMs praktikabel zu machen, sollte die SBOM-Erstellung nicht nur automatisiert, sondern in die CI/CD-Pipeline integriert werden. Oder wie die National Telecommunications and Information Administration (NTIA) es , Tools zu verwenden, die folgende Funktionen mitbringen:
SBOMs während des Build-Prozesses erstellen;
Quellcode und Binärdateien (wie Container-Images) analysieren;
SBOMs bearbeiten;
SBOMs in lesbaren Formaten anzeigen, vergleichen, importieren und validieren;
SBOM-Inhalte von einem Format oder Dateityp in andere übersetzen, beziehungsweise die Informationen zusammenführen;
Einbindung anderer Tools über APIs und Bibliotheken;
Keines der folgenden acht Tools erfüllt (bislang) all diese Empfehlungen. Wir empfehlen Ihnen, die Tools auszuprobieren und anschließend zu ermitteln, welches für Ihre Zwecke am besten geeignet ist. Diese acht SBOM-Tools verdienen Ihre Aufmerksamkeit:
Die Flaggschiff-Programme von FOSSA sind ein Open Source License Compliance Manager und ein Open Source Vulnerability Scanner. Der Ansatz von FOSSA sieht vor, dass Sie das SBOM-Tool in Ihr bevorzugtes Versionskontrollsystem wie GitHub, BitBucket oder GitLab integrieren. Sie können auch die CLI von FOSSA verwenden und das Tool lokal ausführen oder es in Ihre CI/CD-Pipeline integrieren.
In jedem Fall identifiziert FOSSA im Rahmen eines Projektscans automatisch sowohl direkte als auch indirekte Abhängigkeiten in der Codebasis.
.
Dieses eigenständige Open-Source-Tool tut das, was sein Name verspricht: SPDX-SBOMs aus aktuellen Paketmanagern oder Build-Systemen erstellen. Sie können seine CLI verwenden, um SBOM-Daten aus Ihrem Code zu erzeugen. Das Tool erzeugt Berichte über Komponenten, Lizenzen, Copyrights und Sicherheitsreferenzen Ihres Codes. Diese Daten werden in der SPDX v2.2-Spezifikation exportiert.
Dieses quelloffene SBOM-Projekt lässt sich gut mit SPDX SBOM Generator kombinieren. Anstatt mit Paketmanagern oder Build-Systemen zu arbeiten, erzeugt dieses SCA-Tool und die Python-Bibliothek eine SBOM für Container-Images und Docker-Dateien. Darüber hinaus lassen sich auch SBOMs im SPDX-Format erzeugen.
bei unserer Schwesterpublikation CSOonline.com erschienen.
SOCIAL SHARE CARD GENERATOR