Was ist eine SBOM?
Eine Software-Stückliste (SBOM) listet alle Komponenten Ihrer Software auf und sorgt so für Klarheit und Kontrolle über die Lieferketten.
SBOMs ermöglichen schnelle Reaktionen auf Schwachstellen, wie bei Log4j und SolarWinds, und stärken die Abwehr der Lieferkette.
Regulatorische Auflagen wie PCI DSS und behördliche Anforderungen binden die Sicherheit direkt an die Einführung von SBOM.
Die Automatisierung der SBOM-Generierung eliminiert Fehler und gewährleistet eine aktuelle Schwachstellenverfolgung.
Das agentenlose SBOM-Scanning von Wiz bietet Echtzeit-Einblicke und hilft Teams, den Überblick über sich ändernde Softwareumgebungen zu behalten.
Was ist eine SBOM?
Eine Software-Stückliste (SBOM) ist ein umfassendes Inventar, das alle Softwarekomponenten einer Anwendung detailliert beschreibt. Es beinhaltet Open-Source und kommerzielle Bibliotheken, API-Aufrufe, Versionen und Lizenzen von Drittanbietern.
Anwendungen, die im Supply-Chain-Ökosystem verwendet werden, sind ein Amalgam aus Elementen aus verschiedenen Quellen. Diese Quellen können Schwachstellen enthalten, die Cyberkriminelle bei Angriffen auf die Lieferkette ausnutzen könnten. Erleichterung von SBOMs Schwachstellen-Management durch die Bereitstellung von Informationen über diese Elemente.
Gartner prognostiziert, dass bis 2025
SBOM's Rolle bei der Sicherheit der Software-Lieferkette
Mit zunehmenden Angriffen auf die Lieferkette sind SBOMs zu unverzichtbaren Werkzeugen für die Verfolgung und Sicherung von Softwarekomponenten geworden. Gartner schätzt, dass bis 2025 60 % der Unternehmen werden SBOMs verlangen im Rahmen ihrer Cybersicherheitspraktiken ein deutlicher Anstieg von 20 % im Jahr 2022. Regierungsmandate, wie die des Weißen Hauses Durchführungsverordnung zur Verbesserung der Nation's Cybersicherheit, sind jetzt auch SBOMs für Organisationen erforderlich, die mit Regierungsbehörden zusammenarbeiten.
Die Vorfälle von Log4j und SolarWinds verdeutlichen die Bedeutung von SBOMs:
Log4j-Schwachstelle (CVE-2021-44228): Diese weit verbreitete Java-Bibliothek hat einen Sicherheitsalbtraum für Unternehmen auf der ganzen Welt geschaffen. Ohne SBOMs mussten sich viele Unternehmen darum bemühen, die gefährdeten Komponenten zusammenzusetzen. Aber diejenigen mit SBOMs? Sie lokalisierten betroffene Komponenten schnell und wichen massiven Auswirkungen aus.
SolarWinds-Angriff: Im Jahr 2020 kompromittierten Angreifer die SolarWinds Orion-Software, von der rund 18.000 Kunden betroffen waren, darunter führende Unternehmen und Regierungsbehörden. Eine SBOM hätte das Chaos durchbrechen und den Opfern helfen können, die Malware schnell zu verfolgen und effektiv zu reagieren.
CI/CD Security Best Practices [Cheat Sheet]
Learn about infrastructure security, code security, access, and monitoring with actionable items, code snippets, and screenshots.
Get the Cheat Sheet
Warum SBOMs wichtig sind
SBOMs bieten eine detaillierte Liste aller Komponenten einer Softwareanwendung und helfen Unternehmen, Sicherheitsrisiken zu identifizieren und zu verwalten. Sie verbessern auch die Transparenz, erleichtern die Nachverfolgung und Aktualisierung von Softwareabhängigkeiten und vieles mehr:
1. Transparenz und Sichtbarkeit
Stellen Sie sich SBOMs als Blaupause für Ihre Software vor. Sie geben Entwicklern einen klaren Überblick über alle Softwarekomponenten von Drittanbietern – wie z. B. Open-Source-Bibliotheken –, die in ihren Anwendungen verwendet werden. Diese Transparenz hilft Teams, die Risiken abzuwägen, bevor sie eine Bibliothek hinzufügen, und nach der Bereitstellung den Überblick über Schwachstellen zu behalten.
2. Einhaltung
Mit dem harten Durchgreifen von Regierungen und Industriestandards gegen die Softwaresicherheit sind SBOMs zu einem unverzichtbaren Bestandteil der Compliance geworden. Von PCI DSS bis HIPAA verlangen viele Vorschriften heute eine klare Aufzeichnung der Softwarekomponenten. Eine SBOM hilft nicht nur, diese Anforderungen zu erfüllen, sondern bewahrt Ihr Unternehmen auch vor Ärger, sei es durch Geldstrafen oder Reputationsschäden durch Lizenzpannen.
3. Incident Response und Forensik
Wenn etwas schief geht, kann eine SBOM ein Lebensretter sein. Es zeigt genau an, welche Komponente anfällig ist, und hilft den Teams, sich auf den Problembereich zu konzentrieren. Priorisieren Sie ihre Reaktionund die weiteren Auswirkungen zu bewerten.
Was sollte eine SBOM enthalten?
Eine SBOM sollte Details zu allen Open-Source- und proprietären Softwarekomponenten enthalten, die in einem Produkt verwendet werden, einschließlich ihrer Namen, Versionen und Lizenzen. Außerdem sollten die Beziehungen zwischen den Komponenten und ihre Abhängigkeiten angegeben werden.
Eine SBOM sollte Details zu allen Open-Source- und proprietären Softwarekomponenten enthalten, die in einem Produkt verwendet werden, einschließlich ihrer Namen, Versionen und Lizenzen. Es sollte auch die Beziehungen zwischen Komponenten und deren Abhängigkeiten angeben.
1. Komponenten-Identifikatoren: Dazu gehören Metadaten wie Lieferanten- und Komponentennamen, Komponentenherkunft, Beschreibung und Betreuer, Artefakt-ID, Zeitstempel, Versionsnummer und spezifische Referenzen wie Git-Commit-IDs oder SHA-1-Hashes für jede Komponente.
2. Abhängigkeiten: Die Beziehung zwischen jeder Komponente und ihren Abhängigkeiten muss klar dokumentiert werden.
3. Versionsinformationen: Dazu gehören die Versionsnummer der Software, der Dateiname und das Betriebssystem, um eine einfache Installation zu ermöglichen und Kompatibilitätsprobleme zu vermeiden. Anhand von Versionsinformationen können Sie erforderliche Updates oder Patches für jede Komponente nachverfolgen.
4. Daten zur Schwachstelle: Es ist wichtig, Informationen über bekannte Schwachstellen im Zusammenhang mit jeder Komponente anzugeben. Diese Daten können aus Schwachstellenkatalogen wie der National Vulnerability Database (NVD) oder CVE (Common Vulnerabilities and Exposures) bezogen werden.
5. Informationen zur Lizenzierung: Jede Komponente hat Lizenzbedingungen (z. B. MIT-, Apache- und BSD-Lizenzen). Die SBOM muss diese Bedingungen enthalten, um die Einhaltung der Lizenzverpflichtungen zu gewährleisten.
7. Externe Referenzen: Dazu gehören URLs oder Dokumentationen, die sich auf jede Komponente beziehen. Sie bieten zusätzlichen Kontext zu den Funktionen der Komponenten.
Wiz’s agentless SBOM allows you to gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots and deploying an agent.
Gängige SBOM-Formate
SBOMs können manuell oder automatisch generiert werden.
Das Manuelle Methode beinhaltet die Auflistung aller Softwarekomponenten und ihrer jeweiligen Versionen, Lizenzen und Abhängigkeiten in Tabellenkalkulationen. Es eignet sich nur für kleine Bereitstellungen und ist anfällig für menschliche Fehler.
Das Automatisches Verfahren umfasst die Integration von SBOM-Tools in die CI/CD-Pipeline (Continuous Integration/Continuous Deployment).
Nach der Generierung werden SBOMs in zwei Hauptformate strukturiert: CycloneDX und Software Package Data Exchange (SPDX). Im Folgenden finden Sie eine kurze Beschreibung der einzelnen Elemente.
| Format | Description |
|---|---|
| SPDX | SPDX supports representation of SBOM information, such as component identification and licensing information, alongside the relationship between the components and the application. SPDX enables information gathering and sharing in various file formats, including human-readable and machine-parsable formats such as JSON, XML, and YAML. It enhances transparency, and facilitates license compliance. |
| CycloneDX | CycloneDX supports listing internal and external components/services that make up applications alongside their interrelationships, patch status, and variants. It structures the data as an XML or JSON file, and enables you to add details such as Common Vulnerability Scoring System (CVSS) scores and descriptions to the SBOM. CycloneDX is highly extensible, allowing developers to add new capabilities as required. |
Um Ihnen ein besseres Verständnis der SBOM-Formate zu vermitteln, betrachten Sie dieses Beispiel für das CycloneDX-Inventar im JSON-Format:
{
"bomFormat": "CycloneDX",
"specVersion": "1.4",
"Seriennummer": "urn:uuid:3e673487-395b-41h8-a30f-a58468a69b79",
"Version": 1,
"Komponenten": [
{
"Art": "Bibliothek",
"Name": "nacl-Bibliothek",
"Version": "1.0.0"
}
]
}Zusätzlich zu den beiden oben behandelten Formaten können Organisationen auch SWID-Tags (Software Identification) verwenden, die in der Regel während der Bereitstellung installiert werden. SWID-Tags stellen SBOM-Informationen bereit, z. B. Veröffentlichungsdaten von Softwarekomponenten und Lizenzen. Regulierungsbehörden und die US-Regierung betrachten SWID-Tags, CycloneDX und SPDX als akzeptabel SBOM-Formate.
SBOM-Implementierung: eine Schritt-für-Schritt-Anleitung
Das Erstellen einer SBOM mag entmutigend klingen, aber die Aufteilung in überschaubare Schritte kann den Prozess erleichtern. So legen Sie los:
| Step | Process |
|---|---|
| 1. Choose SBOM tools | Start with tools that fit your workflow. Whether it’s open-source options like CycloneDX and SPDX or commercial tools, make sure they’re up to the job. Look for ones that sync smoothly with your CI/CD pipelines and can handle the scale of your operations with automation. |
| 2. Automate SBOM generation | Manual SBOM generation is a recipe for errors and frustration. Automate it instead. Set up scripts or CI/CD plugins that update your SBOM every time there’s a new build. It keeps things current and saves your team time and effort. |
| 3. Track and update software components | Software isn’t static—it evolves. Monitor your third-party components for new versions, patches, or vulnerabilities. Make reviewing and updating your SBOM a regular habit. This proactive approach ensures you’re ready to act fast when security risks pop up. |
| 4. Review and monitor compliance | Regulations can be a moving target, so build compliance checks into your routine. Does every component meet licensing and security standards? Conduct audits to double-check. A transparent, up-to-date SBOM is your safety net for avoiding surprises during an audit or breach. |
Genie's Ansatz für die SBOM-Sicherheit
Wiz Code erhöht die Sicherheit von SBOM (Software Bill of Materials), indem es einen umfassenden Einblick in die Komponenten und Abhängigkeiten innerhalb Ihrer Software bietet. Mit Echtzeit-Scans und automatisierten Sicherheitsüberprüfungen stellt Wiz Code sicher, dass Schwachstellen in Bibliotheken und Open-Source-Komponenten von Drittanbietern frühzeitig erkannt und entschärft werden.
Zu den Vorteilen der agentenlosen SBOM-Bereitstellung gehören:
Flexibilität und Einfachheit: Dedizierte Agenten sind Add-on-Services, die Ressourcen verbrauchen und laufend gewartet werden müssen, was zu einem himmelhohen Wartungsaufwand führt. Agentenlose SBOM Die Bereitstellung senkt auch die Kosten und beseitigt Kompatibilitätsprobleme zwischen Agent und Betriebssystem.
Sofortige und vollständige Transparenz: Agents müssen auf jedem Subsystem im Software-Stack installiert werden. Eine agentenlose SBOM bietet Ihnen einen vollständigen Überblick über Ihre Anwendungen' Komponenten – von den verwendeten Open-Source-Bibliotheken bis hin zum Paket und verschachtelten Abhängigkeiten – innerhalb von Minuten, ohne blinde Flecken.
SBOM-Suche: Suchen und finden Sie schnell bestimmte Betriebssystem- und Open-Source-Pakete in Cloud-Umgebungen. Diese Fähigkeit ist angesichts der jüngsten kritischen Sicherheitslücken, die in weit verbreiteten Bibliotheken wie xz-utils.
Immer auf dem neuesten Stand: Agenten erfordern eine manuelle Installation, die fehleranfällig sein kann, während ein agentenloser Ansatz ermöglicht es Ihnen, aktuelle SBOMs ohne manuelle Eingriffe zu generieren.
Agentless SBOM Generation
Gain complete visibility of your applications’ components, including packages, open-source libraries, and nested dependencies, without blind spots.
