SBOM ist das Fundament für Softwaretransparent und Cyber-Resilienz.
CycloneDX ist eine der drei von NTIA/CISA empfohlenen SBOM-Spezifikationen und gehört zu den beliebtesten SBOM-Spezifikationen.
Die OWASP Foundation hat Anfang dieses Monats die Version 1.6 von CycloneDX veröffentlicht.
Neben verschiedenen Verbesserungen führt Version 1.6 die Fähigkeit ein, ein kryptografisches Software-Verzeichnis (Cryptographic Bill of Materials - CBOM) zu erstellen und CycloneDX-Bescheinigungen (CDXA) zu spezifizieren.
Lassen Sie uns einen genaueren Blick darauf werfen.
Post-Quanten-Kryptografie (PQC)
Mit dem Fortschreiten des Quantencomputings wird es letztendlich in der Lage sein, die gesamte veraltete Kryptografie zu brechen, die für digitale Signaturen und Verschlüsselung verwendet wird. Die CISA betreibt eine Post-Quantum-Kryptografie-Initiative (PQC), um Bundesbehörden und die Privatwirtschaft auf diesen Quantensprung vorzubereiten. Eine der frühen Empfehlungen lautet, mit der Erstellung eines kryptografischen Inventars der verwendeten Assets zu beginnen.
Hier kommt CycloneDX 1.6 ins Spiel.
Kryptografische Stückliste (CBOM)
Die CBOM ist eine Erweiterung der SBOM, die kryptografische Eigenschaften enthält. OWASP hat zusammen mit der Veröffentlichung von CycloneDX 1.6 einen maßgeblichen Leitfaden für CBOM (Authoritative Guide to CBOM) herausgegeben, um das Erstellen und Nutzen von CBOM zu unterstützen.
Die Forschung von IBM im Bereich CBOM hat CycloneDX Version 1.4 erweitert, um Folgendes aufzunehmen:
Komponente:
crypto-assetEigenschaften (Properties):
cryptoPropertiesAbhängigkeiten:
dependencyType
CycloneDX 1.6 erreicht dasselbe durch:
Hinzufügen eines
cryptographic-assetzu den unterstützten KomponententypenHinzufügen von
provideszu seinemdependencies-Knoten, um die Identifizierung eines kryptografischen Werts (Funktionalität, Dateien) zu unterstützen, der von einer Komponente bereitgestellt wirdHinzufügen von
cryptoPropertieszumcomponents-Knoten, um Details der kryptografischen Assets zu erfassen
cryptoProperties spielt eine Schlüsselrolle bei der Dokumentation einer Vielzahl kryptografischer Assets und der zugehörigen Metadaten, wie zum Beispiel:
assetType— die Art des beschriebenen Assets: Algorithmus, Zertifikat, Protokoll oder zugehöriges MaterialalgorithmProperties— Wenn der Asset-Typ einalgorithmist, beschreibt dies Algorithmus-Eigenschaften wie Primitiv, Kurve, Padding, Umgebung und Sicherheitsniveau (klassisch und nistQuantum)certificateProperties— Wenn der Asset-Typ eincertificateist, beschreibt dies Zertifikat-Eigenschaften wie Name, Aussteller, Gültigkeitszeitraum, Format und SignaturdetailsprotocolProperties— Wenn der Asset-Typ einprotocolist, kann dies den spezifischen Typ („tls“, „ipsec“), die Version, die verwendeten Cipher Suites und die ikev2-Transformationstypen spezifizierenrelatedCryptoMaterialProperties— Wenn der Asset-Typ einrelated-crypto-materialist, beschreibt dies zusätzliche Details wie Größe, Format, Wert, Erstellungs-, Aktualisierungs- und Aktivierungsdaten
Der maßgebliche Leitfaden für CBOM enthält Beispiele, darunter eines zur Beschreibung von „AES-128-GCM“.
Die CBOM-Erweiterung verweist auf die Forschung von IBM im Bereich CBOM und bedankt sich dafür. Daher sollte jede Implementierung sowohl die Spezifikation als auch die IBM-Forschung als Hintergrundinformationen heranziehen.
CycloneDX Attestations (CDXA)
CycloneDX 1.6 fügt Attestierungen hinzu und beschreibt dies als „Compliance as Code“. OWASP hat zusammen mit der Veröffentlichung von CycloneDX 1.6 auch einen richtungsweisenden Leitfaden für Attestierungen (Authoritative Guide to Attestations) herausgegeben, um die Erstellung und Nutzung von CDXA zu begleiten.
Darüber hinaus hat OWASP einen richtungsweisenden Leitfaden für Attestierungen veröffentlicht.
CDXA zielt darauf ab, Attestierungen zu nutzen, um Sicherheitsanforderungen zu erfüllen, die Erstellung von Nachweisen zu automatisieren, mit Prüfern zu kommunizieren und als Standard für maschinenlesbare Versionen ihrer Anforderungen zu dienen.
Compliance als Code
Im CDXA-Ansatz wird die Standardkonformität wie folgt unterteilt und strukturiert:
Definieren von Standardanforderungen
Geltendmachen von Ansprüchen bezüglich dieser Anforderungen
Erfassen von Nachweisen zur Untermauerung dieser Ansprüche
Unterzeichnen des Testats (Attestation), das alle oben genannten Punkte auflistet
Testate sind eine Reihe von Ansprüchen (Claims), Gegenansprüchen (Counterclaims) und den dazugehörigen Nachweisen.
Im CDXA-Ansatz werden die Ansprüche, Gegenansprüche, Nachweise und die dazugehörigen Metadaten alle innerhalb der SBOM dokumentiert und von der testierenden Partei kryptografisch signiert.
Um dies zu erreichen, fügt CycloneDX 1.6 Folgendes hinzu:
einen
definitions-Knoten, um einen Standard und dessen Details zu spezifiziereneinen
declarations-Knoten, um die damit verbundenen Ansprüche, Nachweise, Signaturen und Metadaten zu erfassen
Definitionen
Der definitions-Knoten dient zur detaillierten Beschreibung des Standards und unterstützt die Standard-Versionierung sowie Konformitätsstufen.
CDXA wird mit Nachweisschemata für gängige Sicherheitsstandards geliefert:
NIST Secure Software Development Framework (SSDF)
PCI Secure Software Life Cycle (PCI-SLC)
Build Security in Maturity Model (BSIMM)
OWASP Application Security Verification Standard (ASVS)
OWASP Mobile Application Security Verification Standard (MASVS)
OWASP Software Component Verification Standard (SCVS)
Es kann auch ein benutzerdefinierter Standard mit Nachweisanforderungen erstellt werden.
Die SSDF-Anforderungen sind beispielsweise im CycloneDX-Repository aufgeschlüsselt.
Erklärungen
Der declarations-Knoten ist die eigentliche Erfassung von Ansprüchen im Zusammenhang mit dem SBOM-Inhalt und den Standardanforderungen.
CDXA unterstützt die Erfassung der Liste der unterzeichneten Ansprüche der Bewertungspartei, einschließlich Begründung, Beweisen, Gegenbeweisen und Minderungsstrategien.
Der OWASP Authoritative Guide to Attestations enthält Beispiele dafür, wie Ansprüche beglaubigt werden können.
CDXA macht einen großen Schritt in Richtung automatischer Beweiserstellung für viele Anforderungen, benötigt jedoch zusätzliche Werkzeuge, um spezifische Details zu erfassen.
Beispiel: SSDF PW2.1: „Eine qualifizierte Person (oder Personen) haben, die nicht am Design beteiligt war(en).“
CycloneDX schreitet weiter voran, um die Abdeckung der SBOM zu verbessern und die Daten effektiver zu interpretieren und zu nutzen.
CBOM und CDXA werden das Risikomanagement der Post-Quanten-Kryptographie und die „Compliance as a Code“-Bewegung erheblich vorantreiben.