GitHub liefert kein Default-SCA-Tool wie GitLab. Du musst zwei Dinge kombinieren: das Plattform-Feature Dependabot und eine SCA-Action aus dem Marketplace. In Teil 3 der GitHub DevSecOps Serie verdrahten Patrick Steger und ich beides in unsere Pipeline — und merken auf die harte Tour, dass der Marketplace-Pfad nicht so glatt läuft, wie es die Slides suggerieren.
Was SCA ist und warum du beide Wege brauchst#
Software Composition Analysis — auch Dependency Scanning genannt — findet bekannte Schwachstellen in den Libraries, die deine Anwendung nutzt. Hat eine Library ein CVE und du nutzt sie, trägt deine Anwendung dieses CVE mit. Neue CVEs zu bestehenden Libraries werden ständig entdeckt — ein einmaliger Scan reicht nicht. Du brauchst Scans bei jedem Commit und zeitgesteuerte Scans gegen unverändertem Code.
Auf GitHub heisst das: zwei Tools, die sich ergänzen. Eine SCA-Action in der Pipeline gibt dir Scan-on-Commit unter deiner direkten Kontrolle. Das Plattform-Feature Dependabot liefert kontinuierliches Scannen, Alerts und automatisch erzeugte Fix-Pull-Requests, unabhängig von deinen Commits. In der Praxis findet die Kombination Dinge, die jedes Tool für sich übersieht.
Dependabot aktivieren#
Dependabot ist ein GitHub-Feature, kein Workflow. Du aktivierst es unter Settings → Code security and analysis. Zuerst den Dependency Graph einschalten — das baut das Inventar deiner Abhängigkeiten auf. Dann Dependabot Alerts aktivieren (damit GitHub dich informiert, wenn ein neues CVE eine deiner Abhängigkeiten betrifft) und Dependabot Security Updates (damit Pull Requests mit dem Upgrade direkt geöffnet werden).
Es gibt noch eine dritte Option, Dependabot Version Updates, die für jede neue Minor-Version PRs öffnet — unabhängig von CVEs. Wir haben sie ausgelassen — jedes Minor-Upgrade als PR wird schnell zu Lärm.
Einmal aktiviert, scannt Dependabot das Repo im Hintergrund. Unter Insights → Dependency Graph siehst du das Inventar: unsere pom.xml zeigte maven-surefire, Spring Boot — und erfreulicherweise sogar die GitHub Actions, von denen unsere Workflows abhängen. Im Security-Tab erscheinen die Dependabot-Alerts, sobald welche existieren.
SCA-Action in die Pipeline einbauen#
Es gibt keine offizielle GitHub-SCA-Action, also gehen wir in den Marketplace und nehmen CRDA — CodeReady Dependency Analysis von Red Hat, das im Hintergrund Snyk nutzt. Wir aktivieren ausserdem GitHub Advanced Security unter Settings → Code security and analysis (kostenpflichtig für private Repos), damit die Scan-Ergebnisse im Security-Tab landen.
Wir fügen einen sca-Step in die Hauptpipeline, der einen separaten sca.yml-Workflow aufruft und Secrets weiterreicht. Der SCA-Workflow braucht den Build vorher, weil er die aufgelösten Abhängigkeiten scannt — also setzen wir needs: build.
Der sca.yml-Workflow selbst hat fail-fast: false, weil wir das vollständige Set an Findings wollen und nicht nur das erste. Er läuft auf einer Matrix verschiedener Betriebssysteme, checkt das Repo aus, installiert Java, installiert das CRDA-Tool, ruft redhat-actions/crda@v1.2 auf und lädt die SARIF-Findings hoch, damit GitHub sie rendern kann.
CRDA braucht zwei Secrets: einen SNYK_KEY (du legst dir einen kostenlosen Snyk-Account auf app.snyk.io an und kopierst den API Key aus den Account Settings) und einen GitHub-Token für den OpenShift-Tools-Installer (der Default-GITHUB_TOKEN reicht). Beide kommen unter Settings → Secrets → Actions.
Was wirklich passiert ist#
Der erste Run lief. Pipeline gebaut, SCA-Job ausgeführt, CRDA hat gescannt, Vulnerabilities tauchten unter Security → Code Scanning auf, sortierbar nach Tool, Severity, Branch und Rule. Echte Findings gegen die absichtlich veraltete Spring-Boot-Version, die wir gepinnt hatten.
Dann wollten wir die Pipeline eine Stunde später neu starten — und alles fiel auseinander. CRDA lief in Connection Timeouts. Der Snyk Key funktionierte zwei oder drei Scans und verweigerte dann die Authentifizierung. Patrick war deutlich: so wie es jetzt ist, ist das nicht enterprise-tauglich. Gut zu wissen, wenn du CRDA für den produktiven Einsatz evaluierst.
Eine Kleinigkeit hat uns ausserdem überrascht: die Severity-Labels in der GitHub-UI heissen “error / warning / note” statt “critical / high / medium / low”, wie wir es aus der Security-Welt kennen. Nicht falsch — aber anders. Triagier-Skripte entsprechend anpassen.
Dependabot vs Pipeline-Scan#
Kurios: nach einiger Wartezeit meldete Dependabot keine Alerts auf demselben Repository, in dem CRDA echte Vulnerabilities fand. Wir haben nicht herausgefunden, warum. Die Lehre: keines der beiden Tools ist allein die ganze Antwort — Dependabot für die kontinuierliche Plattform-Sicht, ein Pipeline-SCA-Tool für Scan-on-Commit, und eine echte Evaluation, welchem Drittanbieter-Tool du tatsächlich vertraust.
Key Takeaways#
GitHub hat kein Default-SCA-Tool. Du baust die SCA-Fähigkeit selbst auf, indem du Dependabot (Plattform) mit einer Marketplace-Action kombinierst.
Dependabot zuerst aktivieren. Dependency Graph, Alerts und Security Updates sind drei Toggles in den Settings. Version Updates lieber weglassen — sonst bekommst du für jeden Minor-Bump einen PR.
Der Marketplace-SCA-Pfad ist holprig. CRDA + Snyk funktioniert in Demos, war aber unter Last unzuverlässig. Connection Timeouts und kurzlebige API-Keys machten es enterprise-untauglich.
Pipeline-SCA braucht
needs: build. Der Scan läuft auf den aufgelösten Abhängigkeiten, also muss der Build-Job vorher fertig sein. Eigene Workflow-Datei aus Main aufrufen, Secrets weiterreichen.Severity-Labels sind anders. GitHub zeigt im Code Scanning “error / warning / note” — nicht das gewohnte “critical / high / medium / low”. Triage entsprechend anpassen.
SCA-Tool vor dem Commit ernsthaft evaluieren. Das im Video gezeigte ist nicht die Antwort. Wähle ein Tool mit Track Record, vernünftigen API-Limits und stabilem Scanner — und teste es unter realer Last, bevor du es in jede Pipeline verdrahtest.