LICENSE File, SBOM und Vulnerability Report automatisiert erzeugen

Ein praxisnahes Beispiel für die automatisierte Erstellung von Software Compliance und Sicherheitsdokumentation mit DejaCode. Lerne wie du deinen Softwareentwicklungsprozess anpasst, um LICENSE File, SBOM und Vulnerability Reports zu erstellen.

Anforderungen an einen sicheren Softwareentwicklungsprozess (DevSecOps)

Erst vor wenigen Tagen reihte sich eine weitere Supply Chain Attack auf npm - den node.js Pakete kompromittiert. Wer hier nun zum falschen Zeitpunkt das falsche Paket in seine Software gebundelt hat, liefert schadhafte Software aus.

Um zu erkennen, dass du als Softwarehersteller von diesem Angriff betroffen bist, musst du natürlich wissen welche Pakete du in welchen Versionen in deine Software einbaust und ob sie von dieser Vulnerability betroffen sind. Dabei helfen dir eine Software Bill of Materials (kurz SBOM) und ein Vulnerability Report.

Im folgenden stelle ich dir einen Ansatz vor, wie du sowohl eine SBOM als auch einen Vulnerability Report mit der Open Source Software DejaCode (und Scancode.io) automatisiert erstellen kannst. Wenn wir schonmal dabei sind, erstellen wir auch gleich noch ein LICENSE File, welches für die nötige Compliance sorgt.

Neben den Gründen wie Reputationsverlust oder wirtschaftlichem Schaden bei Angriffen, solltest du wissen, dass diese drei Artefakte - SBOM, Vulnerability Report & LICENSE File - von verschiedenen Gesetzten und Normen eingefordert werden.

Automatisierung von Software Compliance und Sicherheitsdokumentation

In den folgenden Absätzen schauen wir uns an, wie die Erstellung von LICENSE File, SBOM und Vulnerability Reports mit der Open-Source Software DejaCode und Scancode.io automatisiert werden kann.

Eine Voraussetzung für die im weiteren beschriebene Vorgehensweise ist ein grundlegender Grad an Automatisierung in deinem Softwareentwicklungsprozess. Ich gehe davon aus, dass du deine Codebase in einem Repository pflegst. Teil der Repository bzw. der Infrastruktur drum herum, sollte so gestaltet sein, dass ein Build automatisiert abläuft.

Darüber hinaus kann auch das Deployment (z.B. Deployen von Docker Images in Kubernetes) deiner Software ein Teil des automatisierten Softwareentwicklungsprozesses sein. Das Deployment betrachten wir hier allerdings nicht.

Beteiligte Komponenten an diesem DevSecOps-Prozess

In dem hier beschriebenen DevSecOps-Prozess spielen eine Reihe von Komponenten eine Rolle. Die folgende Auflistung nennt und erklärt die beteiligten Komponenten kurz.

• Codebase: Dein Source Code, welcher in einem Repository verwaltet ist (z.B. ein git-Repository in GitLab)
• Build Pipeline: Ein Prozess, der verschieden Schritte des Builds ausführt (z.B. ein GitHub Workflow oder eine GitLab Pipeline)
• Security Scanner: Meist ein CLI-Tool, welches die Codebase scannt und dabei Scan Reports oder SBOMs erstellt. Hier verwenden wir die Open-Source Software Scancode.io mit dem CLI-Tool ScanCode-Toolkit. Weitere Security Scanner findet ihr in unserem Blog:
  • Syft CLI für die Generierung von Software Bill of Materials (SBOM)
  • Trivy als vielseitiger Open Source Security Scanner
• Compliance System: Das System of Record für die Daten der SBOM. Hier verwenden wir die OSS DejaCode. DejaCode erfüllt folgende Aufgaben:
  • Open Source & Drittanbieter-Komponenten erfassen – Identifizieren und verwalten, was in den Projekten genutzt wird.
  • Compliance-Richtlinien durchsetzen – Lizenzen und Pakete prüfen, mit ScanCode.io.
  • SBOMs importieren & pflegen – Paket- und Komponentenlisten generieren, speichern und für Audits bereithalten.
  • Integration in Softwareentwicklungsprozess (DevOps) – Compliance-Features nahtlos in Entwicklungsprozesse einbinden.

Änderungen am Code

Der erste Schritt in unserem DevSecOps-Prozess ist die Änderung an der Codebase. Hier checkt eine Entwicklerin eine Änderung am Code im Repository ein. Dieser Commit stößt die Ausführung einer Build Pipeline an. Die Schritte des Builds laufen wie bisher auch automatisiert ab.

Um am Ende unsere DevSecOps-Prozesses LICENSE File, SBOM und Vulnerability Reports erzeugen zu können, fügen wir einen zusätzlichen Schritt Security Scan in die Build Pipeline ein. Dieser zusätzliche Schritt muss nicht bei jedem Entwicklungs-Build ausgeführt werden. Es ist denkbar, dass er nur z.B. nur für Releasekandidaten ausgeführt wird. Das hängt von den individuellen Prozessen ab.

Security Scan mit Scancode.io

Der zusätzliche Security Scan-Schritt ist also Teil der Build Pipeline. In diesem Schritt verwenden wir den Security Scanner, um die Codebase zu scannen. Dieser Scan kann mit dem ScanCode-Toolkit im zwei Varianten erfolgen:

1. Als Teil der Build Pipeline
2. Außerhalb der Build Pipeline

Scan der Codebase als Teil der Build Pipeline

Hierbei wird das CLI Tool in der Build Pipeline selbst ausgeführt. Dazu muss es (auf dem Worker bzw. der Build-Umgebung) installiert und ausgeführt werden. Das kann innerhalb eines GitHub Workflows zum Beispiel mittels einer GitHub Action passieren:

use-scancode-action:
runs-on: ubuntu-latest
env:
    PROJECT_NAME: "${{ github.event.repository.name }}-${{ github.ref_name }}"
steps:
    - uses: aboutcode-org/scancode-action@beta
    with:
        pipelines: "resolve_dependencies:StaticResolver"
        output-formats: "json xlsx spdx cyclonedx attribution"
        project-name: "${{ env.PROJECT_NAME }}"

GitHub Action aboutcode-org/scancode-action@beta

Scan der Codebase außerhalb der Build Pipeline

Da wir in unserem Prozess nicht die Build Pipeline mit einem (potenziell) langlaufenden Schritt wie dem Security Scan belasten wollen, lassen wir Scancode.io diesen Schritt ausführen. Dabei nutzen wir die Build Pipeline als Initiator, die den Scan startet. Das passiert mit der Hilfe der REST API von Scancode.io.

curl --location 'https://scancodeio.your-company.com/api/projects/' \
--header 'Content-Type: application/json' \
--header 'Authorization: Token ...' \
--data '{
    "name": "frontend_with_static_resolver2",
    "input_urls": "https://github.com/SecuraPoint/react-frontend.git",
    "pipeline": ["resolve_dependencies:StaticResolver"],
    "execute_now": true
}'

Ein API Call, der ein Scancode.io Scan (“Project”) startet

Innerhalb von Scancode.io wird wiederum ein Scan mit dem ScanCode-Toolkit ausgeführt. Hierbei ist Scancode.io eine Art Wrapper-Anwendung, welche die einzelnen Scans scheduled und dokumentiert. Darüber hinaus bietet Scancode.io eine Integration mit DejaCode, welche wir im folgenden Prozess nutzen wollen.

Das Ergebnis des Security Scans (egal, ob in der Build Pipeline oder in Scancode.io) ist eine SBOM.

Laden von SBOM in DejaCode

Die von Scancode.io erzeugte SBOM enthält eine Liste aller Packages (Softwarepakete dritter Hersteller), die in die eigene Software als Abhängigkeiten eingeflossen sind. Diese SBOM gilt es jetzt in DejaCode zu importieren. Dazu wird in DejaCode ein Product erzeugt. Dieses Product ist das oberste Ordnungsobjekt in DejaCode und entspricht in unserem Beispiel der Codebase in einer bestimmten Version.

Haben wir beispielsweise ein Git-Repository welches Sample Frontend heißt und dessen Code in der Version v1.0.8 gescannt wurde, so erzeugen wir dafür in DejaCode das Product mit dem Namen Sample Frontend sowie der Version v1.0.8. Das wiederum können wir über die DejaCode REST API machen:

curl --location 'https://dejacode.your-company.com/api/v2/products/' \
--header 'Content-Type: application/json' \
--header 'Authorization: Token ...' \
--data '{
    "name": "Sample Frontend",
    "version": "v1.0.8"
}'

Anlegen eines Produktes mit Version in DejaCode

Anschließend wird in das so erzeugte Product die SBOM des vorher angelegten Project in Scancode.io importiert. Nach dem erfolgreichen Import finden wir in DejaCode eine Übersicht über alle Packages, die zu unserer Codebase gehören bzw. vom Security Scan erkannt wurden.

curl --location 'https://dejacode.your-company.com/api/v2/products/[UUID_DejaCode_Product]/pull_scancodeio_project_data/' \
--header 'Authorization: Token ...' \
--form 'project_name_or_uuid="[UUID_Scancode.io_Project]"'

Import des Scan Results in DejaCode

LICENSE File erzeugen

In unserem Beispiel sind DejaCode und Scancode.io miteinander integriert. Diese Integration ist konfigurativ und beinhaltet einen Package Scan für neue Pakete. Das bedeutet, das Packages, welche in DejaCode bisher noch nicht bekannt sind, für einen Package Scan an Scancode.io übergeben werden.

Wird von DejaCode beim Import einer SBOM also ein neues Paket oder eine neue Version eines Paketes erkannt, wird ein Scan dafür über Scancode.io ausgeführt. Das Ergebnis des Scans wird in DejaCode importiert.

Während des Security Scan, ermittelt Scancode.io eine Lizenz zu dem Paket. Diese Lizenz-“Vermutung” (ein technischer Best Guess anhand des Scans) wird ebenfalls in DejaCode importiert. In DejaCode kann diese Lizenz-“Vermutung” einfach übernommen oder von einem fachkundigen User kuratiert werden.

Sind alle Packages, die in einem Product enthalten sind bestimmt, kann daraus eine passende Lizenz für das gesamte Produkt bzw. in unserem Beispiel für die gesamte Codebase abgeleitet werden. Dieses Ergebnis kann über die Funktion Attribution Report aus DejaCode exportiert werden. Dieser Report entspricht dann dem Inhalt unseres LICENSE Files.

Vulnerability Report

Zuletzt fehlt noch der Vulnerability Report für unsere Software Compliance und Sicherheitsdokumentation. Hierzu bietet DejaCode ebenfalls die passende Übersicht im Kontext des Products. Der Reiter Vulnerabilities bietet eine filter- und sortierbare Übersicht aller Vulnerabilities in unserer Codebase.

Die Vulnerabilities selbst wurden während des Security Scans in Scancode.io festgestellt. Das ScanCode-Toolkit nutzt dafür die gängigen Schwachstellendatenbanken und gleicht die gescannten Pakete mit den Vulnerabilities in den Datenbanken ab.

Fazit

Die Open-Source Software DejaCode und Scancode.io kann mit entsprechenden Automatisierungen in den DevSecOps-Prozess integriert werden. Softwareentwicklungsteams werden durch die Nutzung und Einbindung dieser Tools dabei unterstützt Software Compliance und Sicherheitsdokumentation herzustellen.

Alle notwendigen Schritte zur Generierung von LICENSE File, SBOM und Vulnerability Reports lassen sich nahtlos in den Entwicklungsprozess integrieren und müssen - einmal eingerichtet - nicht mehr zu zusätzlichen Aufwänden für die Entwicklungsteams führen.