Getty Images/iStockphoto

Stücklisten und Security: Das müssen IT und DevOps wissen

Die Integration der Erstellung von Software-Stücklisten in den Lebenszyklus der Softwareentwicklung hilft IT- und DevOps-Teams sicherere und wartungsfreundlichere Apps erstellen.

Da die digitale Technologie und das Entwicklungstempo rasant zunehmen, sind Softwareprojekte immer komplexer geworden. Heutige Anwendungen enthalten häufig Code und Abhängigkeiten, die aus verschiedenen Quellen stammen, darunter kommerzielle, Open-Source- und andere Drittanbieterkomponenten.

Die Verwendung von Softwarekomponenten aus verschiedenen Quellen hilft DevOps-Teams dabei, Software effizienter zu kreieren und bereitzustellen und gleichzeitig die Kosten zu senken und die Skalierbarkeit für erhöhte Nachfragen zu verbessern. Diese umfangreichen Netzwerke externer Abhängigkeiten bieten jedoch auch böswilligen Akteuren die Möglichkeit, Schwachstellen auszunutzen.

Der jährliche Bericht Open Source Security and Risk Analysis von Synopsys, in dem Codebases auf Schwachstellen und Lizenzkonflikte untersucht wurden, ergab, dass 96 Prozent der rund 1.700 untersuchten Codebases Open-Source-Komponenten enthielten. Doch obwohl sich viele Anwendungen auf Open-Source-Bibliotheken stützen, ist dieser Code möglicherweise nicht völlig vertrauenswürdig.

Um Sicherheit zu gewährleisten, ist eine umfassende Liste aller Code-Bibliotheken, Komponenten und Abhängigkeiten, die bei der Entwicklung von Softwareprojekten verwendet werden, unerlässlich. Diese umfassende Inventar- oder Stückliste, das als Software Bill of Materials (SBOM) bezeichnet wird, ist zu einem Schlüsselelement des Lebenszyklus einer sicheren Softwareentwicklung geworden.

Definition einer SBOM und ihrer typischen Komponenten

Eine SBOM ist eine Liste aller Codekomponenten, die während der Entwicklung und Bereitstellung eines Softwareprojekts verwendet werden.

Der Begriff Softwarestückliste leitet sich von den Stücklisten (Bills of Materials) traditioneller Hersteller ab, in denen alle physischen Rohstoffe und anderen Montagekomponenten aufgelistet sind, die zur Herstellung eines Endprodukts benötigt werden. Er wurde in die IT-Branche importiert, um die Softwareabhängigkeiten zu beschreiben, die während des Entwicklungsprozesses verwendet werden.

SBOMs haben in letzter Zeit aufgrund der Zunahme von Angriffen auf die Lieferkette, wie zum Beispiel dem bekannten SolarWinds-Hack, und der zunehmenden Komplexität moderner Softwareprojekte große Aufmerksamkeit erlangt. In den Vereinigten Staaten hat das Weiße Haus eine Verfügung erlassen, die Softwareanbieter, die Produkte an die Bundesregierung verkaufen, dazu verpflichtet, die Sicherheit ihrer Software zu bescheinigen, ein Prozess, der wahrscheinlich die Bereitstellung einer detaillierten SBOM umfasst. Da diese Praxis allmählich auch im kommerziellen Sektor Einzug hält, werden SBOMs wahrscheinlich zu einem Muss für alle Softwareprodukte.

Eine SBOM enthält in der Regel die folgenden Informationen über jede Softwarekomponente:

  • Name, Erscheinungsdatum und Versionsnummer
  • Name des Lieferanten und Kontaktinformationen
  • Transitive Abhängigkeiten
  • Informationen zur Lizenzierung
  • Liste der zugehörigen bekannten Sicherheitsschwachstellen und deren Abhilfemaßnahmen

SBOM-Berichte können entweder manuell von den am Softwareentwicklungsprozess beteiligten Teams oder automatisch mit Hilfe eines Softwaregenerierungs-Tools erstellt werden. Die Berichte sollten in einem maschinenlesbaren Format vorliegen (zum Beispiel JSONCSV, SPDX oder RDF), um die Analyse ihres Inhalts mit anderen Automatisierungswerkzeugen zu erleichtern.

Wie passt die SBOM-Erstellung in einen DevSecOps-Workflow?

Die Integration der SBOM-Erstellung in IT- und DevOps-Workflows ist unerlässlich, um zu gewährleisten, dass die Software sicher und widerstandsfähig ist und den einschlägigen gesetzlichen Anforderungen in Bezug auf Softwaresicherheit und Lizenzierung entspricht.

Der SBOM-Prozess kann in den DevSecOps-Lebenszyklus in mehreren Phasen integriert werden:

  • Entwicklung. Entwickler sollten bereits in den frühen Phasen des Entwicklungsprozesses mit der Erstellung einer SBOM beginnen, bevor die Anwendung bereitgestellt wird. Auf diese Weise wird sichergestellt, dass das Entwicklungsteam alle im Projekt verwendeten Softwarekomponenten nachverfolgt, Sicherheitsschwachstellen identifiziert und geeignete Maßnahmen ergreift, um den Code zu sichern oder gefährdete Komponenten zu entfernen.
  • CI/CD. DevOps-Teams können die SBOM-Erstellung in ihre CI/CD-Pipelines integrieren, um automatisch eine Liste aller Open-Source- oder Drittanbieter-Abhängigkeiten und Codes zu erstellen. Mit der generierten SBOM können DevOps-Teams anfällige Komponenten erkennen, bevor sie die Anwendung bereitstellen.
  • Testen. In der Software-Testphase kann das Sicherheitsteam zur SBOM beitragen, indem es die kritischsten Komponenten in der Software-Lieferkette identifiziert. Auf diese Weise können DevOps-Teams mehr Zeit auf die Gewährleistung der Sicherheit dieser Komponenten vor der Bereitstellung verwenden.

Tools für die Erstellung von SBOMs

DevOps-Teams können aus einer breiten Palette von Tools wählen, um eine SBOM zu erstellen. Die folgenden sind einige der beliebtesten Open-Source-Optionen:

  • CycloneDX Maven Plug-in. Dieses Java-Plug-in kann eine SBOM für ein Paket oder ein ganzes Softwareprojekt erstellen.
  • SBOM Tool. Dieses Kommandozeilen-Tool, das in CI/CD-Pipelines integriert werden kann, läuft auf macOS, Linux und Windows und erzeugt SBOMs, die mit der SPDX 2.2-Spezifikation kompatibel sind.
  • Syft. Dieses Kommandozeilen-Tool und diese Bibliothek generieren SBOMs aus Container-Images und Dateisystemen.
  • SPDX SBOM Generator. Dieses Tool generiert SPDX-kompatible SBOMs aus Paketmanagern oder Build-Systemen. Es kann die Beziehungen zwischen den Komponenten ermitteln und die Lizenzierungs- und Konformitätsinformationen der einzelnen Komponenten identifizieren.

Welchen Nutzen haben SBOMs für die Sicherheit?

Obwohl SBOMs Cyberangriffe auf IT-Systeme nicht direkt verhindern können, bieten sie DevOps-Teams verschiedene Vorteile, die potenzielle Angriffsvektoren entschärfen können.

Effizientere Erkennung von und Reaktion auf Bedrohungen

SBOMs verbessern die Sicherheit, indem sie einen vollständigen Einblick in alle im Softwareprojekt verwendeten Komponenten ermöglichen. Dadurch kann das Entwicklungsteam Sicherheitsschwachstellen in allen Komponenten in Echtzeit aufspüren und sofort handeln, um das Risiko zu adressieren und zu minimieren, bevor Bedrohungsakteure es ausnutzen können.

Dies wiederum beschleunigt die Reaktion auf Vorfälle. Ein SBOM hilft IT-Teams, im Falle eines Sicherheitsvorfalls gefährdete Komponenten schnell zu identifizieren, wodurch die Zeit für die Untersuchung und Behebung des Sicherheitsproblems verkürzt wird.

Geringeres Sicherheitsrisiko in der Softwarelieferkette

SBOMs verbessern die Transparenz der Softwarelieferkette, indem sie Einblick in alle Softwarekomponenten geben, unabhängig davon, ob sie innerhalb oder außerhalb des Unternehmens entstanden sind. Dies hilft IT-Teams, Anzeichen für einen Angriff auf die Softwarelieferkette frühzeitig zu erkennen.

Abbildung 1: Bei einem Angriff auf die Softwarelieferkette verschaffen sich Cyberkriminelle Zugang zum Ziel, indem sie eine Sicherheitslücke eines Dritten ausnutzen.
Abbildung 1: Bei einem Angriff auf die Softwarelieferkette verschaffen sich Cyberkriminelle Zugang zum Ziel, indem sie eine Sicherheitslücke eines Dritten ausnutzen.

Incident-Response-Teams können SBOMs nutzen, um gefährdete Softwarekomponenten zu identifizieren, die möglicherweise während eines Angriffs auf die Lieferkette eingeführt wurden. Wenn eine kompromittierte Komponente im Softwareprodukt gefunden wird, kann das Entwicklungsteam daran arbeiten, das Problem zu beheben. Dieser proaktive Ansatz kann potenzielle Sicherheitsverletzungen verhindern und die Integrität der Software gewährleisten.

Einhaltung von Branchen-, Regierungs- und Lizenzanforderungen

SBOMs können technische Teams auch bei der Erfüllung ihrer Compliance-Verpflichtungen in einer immer enger werdenden globalen Gesetzeslandschaft unterstützen. Neue und sich weiterentwickelnde Sicherheitsvorschriften verlangen von Softwareanbietern die Einhaltung strenger Anforderungen zum Schutz der persönlichen Daten der Benutzer.

Beispielsweise legen Industriestandards wie der Payment Card Industry Data Security Standard (PCI DSS) und HIPAA Beschränkungen für die Verwendung bestimmter Softwarekomponenten fest, und Drittanbieter verlangen manchmal bestimmte Bedingungen für die Verwendung ihrer Komponenten in einer bestimmten Anwendung. Mithilfe von SBOMs können Entwickler und IT-Teams die Verwendung jeder Komponente nachverfolgen, um sicherzustellen, dass sie diese Lizenz- und Verwendungsbedingungen erfüllt, und so rechtliche und finanzielle Strafen vermeiden.

Bessere Kommunikation zwischen DevSecOps-Teams

SBOMs können auch die Zusammenarbeit und Kommunikation zwischen allen an einem Softwareprojekt beteiligten Parteien verbessern, darunter Entwickler, Sicherheits- und IT-Ops-Teams sowie andere Abteilungen.

Die Pflege eines umfassenden Inventars aller in einer Anwendung verwendeten Codekomponenten ermöglicht es IT-, Sicherheits- und DevOps-Teams, neu entdeckte Schwachstellen in allen Komponenten zu überwachen und zu beheben, bevor sie von Bedrohungsakteuren ausgenutzt werden können. SBOMs erleichtern sachkundige Diskussionen, indem sie ein gemeinsames Vokabular zur Verfügung stellen, um Schwachstellen und funktionale Probleme von Softwarekomponenten innerhalb des Softwareprojekts zu diskutieren.

Erfahren Sie mehr über Data-Center-Betrieb

ComputerWeekly.de
Close