--- type: News Article title: "Supply-Chain-Sicherheit: CI/Lock mit kryptografischer Provenienz" description: "CI/Lock signiert Build-Ausführungen kryptografisch und schließt eine Lücke in der Software-Lieferkette. Relevant für KMU mit GitHub-Pipeline." resource: https://brunosan.de/ki-praxis/2026-06-30-supply-chain-sicherheit-ci-lock-mit-kryptografischer-proveni.html tags: ["ai_tools", "KIMittelstand", "SupplyChainSecurity", "OpenSource", "CICD"] timestamp: 2026-06-30T00:00:00+02:00 okf_version: "0.1" publisher: DoWell UG author: BrunoSan category: "ai_tools" det_uuid: cecb2532-741f-5186-933b-f73b349c9ecf --- # Supply-Chain-Sicherheit: CI/Lock mit kryptografischer Provenienz CI/Lock signiert Build-Ausführungen kryptografisch und schließt eine Lücke in der Software-Lieferkette. Relevant für KMU mit GitHub-Pipeline. Das Open-Source-Werkzeug CI/Lock erstellt signierte Nachweise darüber, was in einer CI-Pipeline tatsächlich ausgeführt wurde. Entwickelt wurde es vom Team hinter dem CNCF-Projekt Witness, das bereits an der NIST-Richtlinie 800-204D für "Pipeline Observer" mitgearbeitet hat. Das Tool steht unter Apache-2.0-Lizenz auf GitHub, wie das Projekt auf cilock.dev ankündigt. Anlass sind zwei Supply-Chain-Angriffe im März, bei denen innerhalb einer Woche 75 von 76 Versionstags des Github-Repositories aquasecurity/trivy-action kompromittiert und zwei litellm-Releases auf PyPI mit einem Stealer in einer .pth-Datei verteilt wurden. Beide Vorfälle folgten demselben Muster: Continuous-Integration-Pipelines führten Code aus, dem sie keinen Grund hatten zu vertrauen, mit Zugangsdaten, die sie nicht hätten halten sollen. Im Nachhinein konnte niemand beweisen, was tatsächlich gelaufen ist. "The agent did it" ist keine Provenienz, schreiben die Entwickler - gemeint ist, dass eine bloße Behauptung über die Ausführung eines KI-Agenten nicht als Herkunftsnachweis gilt. Unter Provenienz (provenance) versteht man in der Software-Sicherheit den kryptografisch verifizierbaren Nachweis über Herkunft und Ausführung von Code. Das Tool umschließt einen Befehl mit "cilock run", protokolliert Kommandos, gelesene Dateien, Umgebungsvariablen und Artefakte und signiert das Ergebnis als in-toto/DSSE-Attestierung. Standardmäßig arbeitet es keyless, in GitHub Actions also ohne gespeicherte Schlüssel, sondern mit dem OIDC-Token (OpenID Connect) des Runners. Das Werkzeug versteht sich zudem in beide Richtungen mit Witness und bringt über 50 modulare Attestoren mit, die einzeln eingebunden werden können. **Was bedeutet das konkret für Ihren Betrieb?** Für KMU, die CI/CD-Pipelines auf GitHub Actions betreiben, reduziert CI/Lock den Aufwand für signierte Build-Nachweise auf einen Befehl - "Ihr erster signierter Build dauert etwa eine Minute", verspricht der Anbieter. Der Overhead liegt laut eigenen Tests bei rund 36 Prozent auf einem npm install, was für die meisten Build-Pipelines vertretbar ist. Praktisch bedeutet das: Selbst wenn ein Angreifer Tags oder Pakete kompromittiert, lässt sich im Nachhinein belegen, welcher Code tatsächlich gelaufen ist und welche Dateien er gelesen hat - etwa ein Auslesen von /proc/self/environ, das typische Credential-Sweep-Muster. Das Werkzeug ersetzt allerdings keine Runtime-Sicherung wie Harden-Runner, sondern liefert forensische Beweise und blockiert lediglich das Release. Der Trend zu auditierten Pipelines zeigt sich auch in der Software-Lieferkette datengetriebener Workflows, etwa im Google-Beispiel einer Looker-GitOps-Pipeline mit gesteuerten Freigaben und automatischen Rollbacks. Mittelfristig dürften signierte Build-Nachweise zum Standard werden, nicht zuletzt weil Behörden wie NIST in der Richtlinie 800-204D entsprechende "Pipeline Observer" einfordern. Auch KI-Agenten wie Claude Code, Codex oder Cursor können mit dem Werkzeug Builds ausführen und Nachweise sammeln, die Signatur der Release-Policy bleibt jedoch zwingend menschlich. Wer in den nächsten Monaten Audit-Anforderungen seiner Kunden oder Auftraggeber erwartet, sollte die Integration in einer Test-Pipeline frühzeitig erproben. # Handlungsempfehlung Installieren Sie CI/Lock diese Woche in einer Test-Pipeline mit 'go install github.com/aflock-ai/rookery/cilock/cmd/cilock@latest' und messen Sie den Overhead gegen den Referenzwert von 36 Prozent bei einem npm install. # Citations [1] [cilock.dev](https://cilock.dev/) [2] [discuss.google.dev](https://discuss.google.dev/t/looker-gitops-building-a-secure-automated-deployment-rollback-pipeline/376625)