DE/EN Kostenlos testen
← Zurück zum Blog 12. Juni 2026 · bram-devos

ts-scan aus einem Docker-Image betreiben

ts-scan aus einem Docker-Image betreiben: Eine Schritt-für-Schritt-Anleitung

In den letzten zwei Jahren als Leiter unseres OSPO bei einem mittelständischen Logistikunternehmen in Flandern habe ich eine Lektion auf die harte Tour gelernt: Das beste Compliance-Tooling der Welt nützt nichts, wenn Ihre Teams nicht zweimal hintereinander dieselben Scan-Ergebnisse reproduzieren können. Versionsdrift in lokalen Python-Umgebungen, ein Kollege mit einer anderen pip-Version, ein CI-Agent, der drei Minor-Releases hinterherhinkt — jedes dieser Probleme untergräbt still und leise Ihre OpenChain-ISO-5230-Konformität, noch bevor Sie überhaupt beim Audit ankommen.

Deshalb haben wir ts-scan auf einen Docker-basierten Workflow umgestellt, und ich möchte Ihnen genau zeigen, wie wir das gemacht haben.

Warum containerisierte SCA alles verändert

Lokale Toolchain-Installationen sind ein Compliance-Risiko. Ich habe es immer wieder erlebt: Ein Entwickler scannt lokal, bekommt grünes Licht, pusht in die CI — und die Pipeline meldet plötzlich ein Dutzend neuer Findings, weil die transitive Abhängigkeitsauflösung auf dem Agent anders funktioniert. Das zu debuggen kostet Zeit — und, noch wichtiger, es untergräbt das Vertrauen in den gesamten SCA-Prozess.

Ein containerisiertes ts-scan-Image löst dieses Problem an der Wurzel. Jedes Teammitglied, jeder CI-Runner, jeder abgeschottete Build-Server führt exakt dieselbe Binary mit exakt demselben Dependency-Resolver aus. Das ist Prozesskonsistenz im wörtlichsten Sinne — und deckt sich direkt mit dem, was OpenChain ISO 5230 von dokumentierten, wiederholbaren Prozessen verlangt.

Es gibt auch ein Onboarding-Argument: Wenn ein neuer Kollege in mein Team kommt, will ich keinen halben Tag mit Tool-Setup verbringen. Mit einem Container lautet die Onboarding-Anweisung buchstäblich vier Worte: Image ziehen, scannen.

Voraussetzungen

Bevor Sie starten, benötigen Sie:

  • Docker Engine ≥ 20.10 auf der Zielmaschine oder dem CI-Agent
  • Ein TrustSource-Konto mit aktivem API-Key (erstellbar unter Settings → API Keys in der TrustSource-Oberfläche)
  • Das Package-Manifest Ihres Zielprojekts — package.json, pom.xml, requirements.txt, go.mod, je nach Ökosystem
  • Netzwerkzugriff auf registry.hub.docker.com und den TrustSource-API-Endpunkt (api.trustsource.io). In abgeschotteten Umgebungen müssen Sie das Image zunächst in Ihre interne Registry spiegeln — dazu weiter unten mehr.

Das offizielle ts-scan-Docker-Image ziehen

Zunächst einfach:

docker pull trustsource/ts-scan:latest

Für alles über einen schnellen Proof-of-Concept hinaus sollten Sie auf einen konkreten Tag pinnen. latest eignet sich zum Ausprobieren, aber in einer Produktionspipeline brauchen Sie Reproduzierbarkeit und Audit-Nachvollziehbarkeit:

docker pull trustsource/ts-scan:1.x.y

Nach dem Pull prüfen Sie, was Sie tatsächlich erhalten haben:

docker inspect trustsource/ts-scan:1.x.y --format='{{.Id}}'

Gleichen Sie diesen Digest mit den veröffentlichten Release Notes im TrustSource-GitHub-Repository ab. Das dauert dreißig Sekunden und liefert Ihnen einen konkreten Artefakt-Hash, den Sie in Ihren Compliance-Unterlagen referenzieren können.

Wenn Ihre Supply-Chain-Policy verlangt, dass alle externen Images über eine interne Registry laufen — in regulierten Logistik- und Fertigungsumgebungen zunehmend Standard —, taggen Sie um und pushen:

docker tag trustsource/ts-scan:1.x.y registry.internal.example.com/ospo/ts-scan:1.x.y
docker push registry.internal.example.com/ospo/ts-scan:1.x.y

Da ts-scan Open Source ist, lässt sich das Dockerfile selbst prüfen. Das zählt, wenn Ihr Security-Team fragt, was genau in Ihrer Build-Umgebung läuft.

Zugangsdaten sicher übergeben

Hier sehe ich die meisten Fehler. Machen Sie das niemals so:

# NICHT so — landet in der Shell-Historie
docker run -e TS_API_KEY=mysecretkey trustsource/ts-scan:latest

Verwenden Sie stattdessen eine Env-Datei, die per .gitignore ausgeschlossen ist:

# .env (niemals committen)
TS_API_KEY=your_api_key_here
TS_PROJECT=your_project_key_here
docker run --rm --env-file .env -v $(pwd):/scan trustsource/ts-scan:latest --scan /scan

Die minimal erforderlichen Variablen zur Laufzeit sind TS_API_KEY und TS_PROJECT. Der Modulname wird automatisch aus dem gescannten Artefakt abgeleitet — Sie müssen ihn nicht fest codieren.

Für Enterprise-Umgebungen gehen Sie noch einen Schritt weiter:

  • GitHub Actions: Encrypted Secrets verwenden und als Umgebungsvariablen im Workflow-YAML injizieren
  • GitLab CI: CI/CD-Variablen als masked und protected setzen
  • HashiCorp Vault oder AWS Secrets Manager: Zugangsdaten zur Laufzeit über Ihre Orchestrierungsschicht mounten, oder ein Sidecar-Pattern in Kubernetes nutzen

Das Prinzip ist immer dasselbe: Zugangsdaten sind Laufzeitkonfiguration, niemals fest ins Build eingebacken.

Den Scan ausführen und Ergebnisse an TrustSource übergeben

Sind die Zugangsdaten geklärt, ist der eigentliche Scan unkompliziert:

docker run --rm \
  --env-file .env \
  -v $(pwd):/scan \
  trustsource/ts-scan:latest \
  --scan /scan

Was dabei im Hintergrund passiert:

  1. ts-scan erkennt automatisch Ihr Abhängigkeits-Ökosystem anhand der Manifest-Dateien in /scan
  2. Es löst transitive Abhängigkeiten auf — nicht nur die direkten, wo die interessantesten Compliance-Findings meist stecken
  3. Es baut die resultierende SBOM zusammen und sendet sie direkt per API an Ihr TrustSource-Projekt

Nach Abschluss des Laufs navigieren Sie zu Ihrem Projekt in der TrustSource-Oberfläche. Sie sehen dort eine neu erstellte SBOM-Version. Von dort aus können Sie neu geflaggte OSS-Komponenten prüfen, Lizenz-Findings durchsehen und kontrollieren, ob Komponenten auf der Sperrliste Ihrer Organisation stehen.

Beim ersten Lauf gegen einen unserer älteren Java-Microservices fanden wir drei transitive Abhängigkeiten mit GPL-2.0-only-Lizenzen, die zwei Jahre lang niemandem aufgefallen waren. Containerisierte SCA macht den Prozess nicht nur sauberer — sie macht Findings sichtbar, die manuelle Prozesse übersehen.

ts-scan in Ihre CI/CD-Pipeline einbetten

Der Befehl docker run lässt sich ohne zusätzliche Plugins in jede Pipeline einfügen. Hier ein minimales GitLab-CI-Beispiel:

sca-scan:
  image: docker:20.10
  services:
    - docker:dind
  script:
    - docker pull registry.internal.example.com/ospo/ts-scan:1.x.y
    - docker run --rm
        --env TS_API_KEY=$TS_API_KEY
        --env TS_PROJECT=$TS_PROJECT
        -v $CI_PROJECT_DIR:/scan
        registry.internal.example.com/ospo/ts-scan:1.x.y
        --scan /scan
        --wait-for-analysis
        --exit-on-vulns CRITICAL
        --exit-on-legal INCOMPATIBLE

Zwei Flags verdienen besondere Erwähnung:

  • --wait-for-analysis: Der Container wartet, bis TrustSource seine Policy-Bewertung abgeschlossen hat, bevor er beendet wird — so wird Ihr Pipeline-Gate aussagekräftig
  • --exit-on-vulns CRITICAL und --exit-on-legal INCOMPATIBLE: Diese brechen den Build ab, wenn kritische Schwachstellen- oder Lizenz-Schwellenwerte überschritten werden. So wird aus SCA ein echtes Qualitäts-Gate statt einer reinen Reporting-Übung.

Aus Sicht der OpenChain-Konformität liefert das Speichern des Image-Tags (1.x.y) in Ihrer Pipeline-as-Code-Datei — Ihrem Jenkinsfile, .gitlab-ci.yml oder GitHub-Actions-Workflow — Compliance-Auditoren eine direkte Rückverfolgbarkeit von jedem Build zu einer konkreten Tool-Version. Das ist ein konkreter, dokumentierbarer Konformitätsgewinn, auf den ich in unseren letzten zwei internen Audits verwiesen habe.

Kernaussagen und nächste Schritte

Containerisierte SCA mit ts-scan beseitigt zwei der größten praktischen Hürden für konsistente Open-Source-Compliance: Toolchain-Overhead und Reproduzierbarkeitslücken. Das ist kein philosophisches, sondern ein operatives Argument. Dasselbe Image, überall, jedes Mal.

Drei Dinge, die Sie heute tun sollten:

  1. Das Image ziehen und gegen ein reales Projekt laufen lassen, um zu sehen, was zurückkommt
  2. Ihren Secrets-Manager anbinden, damit Zugangsdaten niemals im Klartext oder in der Shell-Historie landen
  3. Die Scan-Stage mit den passenden Exit-Flags in die Pipeline Ihres Main-Branches einbauen

Von dort aus lohnt sich ein Blick auf TrustSources SBOM Management und das Compliance-Dashboard, um die Ergebnisse über Ihr gesamtes Portfolio hinweg zu operationalisieren. Wer die OpenChain-Konformität beschleunigen möchte: TrustSource bietet auch begleitete Onboarding-Sessions an — einen Blick wert, wenn Sie unter Zeitdruck von einem Kunden- oder Regulierungs-Audit stehen.

Das Tooling existiert. Der Container ist bereit zum Ziehen. Es gibt keinen guten Grund, warum Ihr nächster Pipeline-Lauf kein sauberes SCA-Gate enthalten sollte.

Zur Person

Leitet das OSPO bei einem flämischen Logistik-Unternehmen, aktiv in der OpenChain WG.

Gastbeitrag. Community-Partner aus der OpenChain Working Group. Nicht vergütet.