Über SBOMs, BitBucket und OWASP Dependency Track

Das Museum alter und neuer Architekturen, mit dem ich zu tun habe, zwang mich dazu, mich mit ihrer Sicherung zu befassen. Zum Beispiel kann eine alte Abhängigkeit CVE werden oder ein solides Open-Source-Projekt kann kommerziell werden. Hier kommt das Konzept eines Software-Bestandsmaterials (SBOM) ins Spiel, um die Lizenz- und Abhängigkeitslandschaft von Systemen zu katalogisieren. Dieses Build-Artefakt wird dann analysiert, um festzustellen, ob die Bestandteile:

1. anfällig für Ausbeutung sind oder
2. unter unerwünschten Bedingungen lizenziert sind, wie zu kommerziell oder zu räuberisch.

Dieser Artikel wird erklären, wie man eine solche Verwundbarkeit kontrollieren kann, indem man:

1. BitBucket-Pipes zur SBOM-Erstellung verwendet und
2. wie OWASPs Dependency Track es analysieren kann.

Kenne dein Risiko

Nicht zu wissen, was sich in deinem Code und deinen Containern verbirgt, ist schön, aber gefährlich. Allerdings kann das Durchlaufen aller Komponenten durch einen Abhängigkeitsanalysator überwältigendes Feedback geben. Es ist besser, im Teamkultur zu integrieren, dass die Menge der Abhängigkeitsprobleme heute immer geringer sein sollte als gestern.

Wikipedia besagt: „Das Open Worldwide Application Security Project (OWASP) ist eine Online-Community, die frei verfügbare Artikel, Methoden, Dokumentationen, Tools und Technologien auf den Gebieten IoT, Systemsoftware und Webanwendungssicherheit produziert.“ Es ist daher nicht überraschend, dass sie eine Plattform zur Verfolgung und Analyse von Schwachstellen in Systemen bereitstellen. Sein auffälligstes Merkmal ist sein Hauptdashboard:

Der größte Graph in der Mitte zeigt die Anzahl der Schwachstellen für alle verfolgten Projekte an. Metriken zu kritischen, mittleren und niedrigen Schwachstellen werden direkt darunter angezeigt. Dependency Track ruft bekannte Schwachstellen von einer oder mehreren Quellen ab. Die bekannteste davon ist die Liste der Common Vulnerabilities and Exposures (CVE) aus der National Vulnerability Database der Vereinigten Staaten. Jeder CVE wird eine Kritikalitätsstufe von unbekannt und niedrig bis kritisch zugewiesen. Diese Risikoanalyse wird von Dependency Track regelmäßig im Hintergrund durchgeführt, wobei das relevante Software-Bestandsverzeichnis (SBOM) als Eingabe verwendet wird. 

Der Abschnitt direkt unter dem größten Graphen zeigt Verstoßdetails, wobei Richtlinien entsprechend dessen konfiguriert sind, was als wichtig erachtet wird. Man kann bestimmte Abhängigkeiten als unerwünscht kennzeichnen oder festlegen, dass bestimmte Lizenzen oder sogar Lizenzgruppen im Dashboard angezeigt und gemeldet werden sollen. Dieses Rückmeldesystem ist auf einer pro Richtlinie basierenden Grundlage konfigurierbar.

Der oberste Abschnitt zeigt dann Portfolio-Schwachstellen, gefährdete Projekte, verwundbare Komponenten und eine Risikobewertung im Laufe der Zeit.

Es gibt weitere Ansichten, Diagramme und Statistiken wie den Fortschritt bei der Überprüfung, die Anzahl der Schwachstellen pro Projekt im Laufe der Zeit und die Anzahl der Schwachstellen pro Komponente im Laufe der Zeit, unter anderem, aber lassen Sie uns lieber darauf eingehen, wie BitBucket das SBOM für Dependency Track generieren und senden kann.

BitBucket bereitet das SBOM vor

Die Vorbereitung des SBOM erfolgt im BitBucket CI/CD-Pipeline, die nach dem Zusammenführen von Pull-Requests mit dem Hauptzweig ausgeführt wird. Dadurch wird sichergestellt, dass die Dashboards immer auf dem neuesten Stand sind. 

Ich habe eine BitBucket-Pipe verwendet, die syft umschließt, um ein CycloneDX SBOM zu generieren. Die syft-Befehle für Code- und Container-Untersuchungen unterscheiden sich leicht.

Code-Sniffing

Der syft-Befehl zur Analyse von Code vom Stamm Ihres Projekts lautet wie folgt:  

syft --output cyclonedx-json=code-cdx-sbom.json -v --java-use-network true .

Dieser Befehl gibt das SBOM in eine Datei namens code-cdx-sbom.json aus und verwendet das Netzwerk, um Lizenzinformationen aus dem Internet abzurufen; beispielsweise von den zentralen Maven-Repositories.

Die syft BitBucket Pipe von shiftleftcyber (danke!) wird dann im Skriptblock der BitBucket-Pipeline konfiguriert, um diesen Befehl syft wie folgt zu umschließen:

- pipe: docker://ccideas/syft-bitbucket-pipe:1.0.0

  variables:

    SYFT_CMD_ARGS: '. --output cyclonedx-json=code-cdx-sbom.json'

    SYFT_JAVA_USE_NETWORK: 'true'

Das Readme des Syft-Projekts listet eine beeindruckende Reihe von unterstützten Sprachen auf, aber ich habe es nur in einem Java und JavaScript Projekt mit einem Python Projekt im Backlog verwendet.

Was lauert in Ihren Containern?

Um einen Container aus Ihrem Register zu scannen, führt man den folgenden Befehl im Rahmen eines „docker login“ aus:

syft --output cyclonedx-json=container-cdx-sbom.json docker.s2c.co.za/container:latest --from registry

Die entsprechende BitBucket-Pipe ist:

- pipe: docker://ccideas/syft-bitbucket-pipe:1.0.0

  variables:

    SYFT_REGISTRY_AUTH_USERNAME: sadilar

    SYFT_REGISTRY_AUTH_PASSWORD: $DOCKER_PWD

    SYFT_CMD_ARGS: 'docker.s2c.co.za/container:latest --output cyclonedx-json=container-cdx-sbom.json --scope all-layers'

Der Schalter all-layers weist syft an, alle Schichten des Container-Images zu inspizieren und nicht nur das endgültige Produkt.

BitBucket als Medium der Hinterlegung

Alles was bleibt, ist für Dependency Track, das SBOM aufzunehmen. Ich habe die Schwester-Pipe der BitBucket-Pipe verwendet, die das SBOM generiert hat:

- pipe: docker://ccideas/sbom-utilities-pipe:1.5.0

  variables:

    PATH_TO_SBOM: code-cdx-sbom.json

    SEND_SBOM_TO_DTRACK: 'true'

    DTRACK_URL: https://deptrack.test.s2c.co.za

    DTRACK_PROJECT_ID: df3327b2-5439-43ab-bb33-1f24228b6074

    DTRACK_API_KEY: $DTRACK_TEST

Ich habe drei Eingabeparameter spezifiziert:

1. URL der Dependency Track Instanz
2. Die ID des Dependency Track Projekts, um das SBOM zu laden
3. Der API-Schlüssel zur Autorisierung des Uploads

Die Projekt-ID kann leicht gefunden werden, indem man im Projektansicht auf „Details anzeigen“ klickt:

Gefolgt von der Kopie des Objektidentifikators am Ende:

Der API-Schlüssel befindet sich im gleichnamigen Eingabefeld des Automation Teams, das über das Menü Administration im linken Panel zugänglich ist:

Fazit

Frühere Vorfälle haben gezeigt, dass die Ausnutzung von Schwächen häufig zu Dienstunterbrechungen führt, die auf benachbarte Systeme oder Branchen übergreifen können. Dies verursacht unerwartete Kosten und Unannehmlichkeiten. Die Wiederherstellung davon wird Entwickler und Ressourcen von den Zielen des Teams ablenken.

Die Lizenzierung eines offenen Projekts kann zudem kommerziell werden und dazu führen, dass eine Organisation nachträgliche Lizenzgebühren auferlegt bekommt. Auf der anderen Seite können Forderungen erhoben werden, kritische IP, die zur Erlangung des Wettbewerbsvorteils genutzt wird, aufgrund von ausbeuterischen Lizenzbedingungen als Open Source freizugeben.

Es liegt daher in der Verantwortung jedes Entwicklers, aktive Strategien zur Bekämpfung dieser Risiken umzusetzen und zu unterstützen. Sollte Ihr Code auf BitBucket sein, kann der oben skizzierte Ansatz Ihrem System helfen, mit dem Programm zurechtzukommen. Der Dependency Track API beschränkt den Zugang jedoch nicht ausschließlich auf BitBucket, und es muss Möglichkeiten geben, die Software Bill of Materials von anderen CI/CD-Pipeline-Technologien dorthin zu bringen.