Bevor wir Security-Tools an irgendetwas anschliessen, brauchen wir ein Repository, eine Pipeline und einen lauffähigen Build. In Teil 2 unserer GitHub DevSecOps Serie legen Patrick Steger und ich ein privates GitHub-Repo für einen kleinen Java-Spring-Boot-Service an, aktivieren GitHub Actions und verdrahten eine Pipeline aus zwei Workflows, die den Code kompiliert und die Unit Tests ausführt. Das ist das Skelett, an dem in der Serie alles Weitere hängt.
Die Anwendung, um die wir bauen#
Wir verwenden in der ganzen Serie dieselbe einfache Java-Spring-Boot-Anwendung — ein Web-Service, der “Spring is here!” zurückliefert, plus ein Unit Test, der den Service aufruft und das Ergebnis prüft. Klein genug, um auf einen Bildschirm zu passen, real genug, um in den nächsten zehn Sessions jedes DevSecOps-Tool sauber demonstrieren zu können.
Voraussetzungen und Lizenzierung#
GitHub gibt es als SaaS in der Cloud oder On-Premise via GitHub Enterprise. Wichtig vorab: Wenn du ein privates Repository und die Advanced Security Features willst, brauchst du eine Enterprise-Lizenz. Wir setzen beides ein — also läuft das hier auf Enterprise. Wer nur öffentliche Repositories braucht, kommt mit dem Free Tier sehr weit.
Das Repository anlegen#
Einloggen, New klicken, und du kannst ein bestehendes Repo importieren oder neu starten. Wir starten neu. Owner ist unser Enterprise-Account. Repository-Name ist DevSecOpsDemo. Sichtbarkeit privat. README, .gitignore und License-Templates lassen wir für das Demo weg — in einem echten Projekt willst du sie auf jeden Fall ausgefüllt haben.
Sobald das Repo existiert, lohnt sich ein kurzer Rundgang durch die Tabs:
- Code — das Repository selbst
- Issues — einfaches Issue-Tracking; auch fürs Backlog-Management nutzbar
- Pull requests — Thema einer späteren Session
- Actions — hier leben unsere Pipelines
- Projects — leichtgewichtiges Projektmanagement
- Wiki — Code-Dokumentation
- Security — der Tab, den wir intensiv für SAST, SCA und Secret Scanning brauchen
- Insights — Contributor-Statistiken und der Dependency Graph
- Settings — Repo-Konfiguration
Actions sicher aktivieren#
Falls der Actions-Tab fehlt, geh auf Settings → Actions → General und aktiviere Actions dort. An dieser Stelle lohnt sich ein kurzer Stopp, denn das ist die erste echte Security-Entscheidung in einem GitHub-Projekt.
Actions sind kleine eigenständige Anwendungen. In der Regel Code, den du nicht selbst geschrieben hast, läuft in deiner Pipeline, mit potenziellem Zugriff auf Secrets. Du hast vier Stufen:
- Jede Action aus dem Marketplace zulassen
- Nur Enterprise-Actions zulassen
- Enterprise-Actions plus eine konkrete Allowlist
- Actions deaktivieren
Aus reiner Security-Sicht ist die sicherste Variante “nur Enterprise-Actions” — du reviewst die Community-Actions, die du wirklich willst, kopierst sie in deinen Enterprise-Bereich, machst ein Security-Review und nutzt diese Kopien. Im Demo erlauben wir alles, um zügig vorwärts zu kommen — in einem Enterprise-Umfeld solltest du das nicht.
Den Code importieren#
Zurück auf den Code-Tab → Import code. Wir zeigen GitHub auf unser bestehendes Projekt, warten kurz, und der Source-Tree taucht auf: die Spring-Boot-Anwendung unter src/main/java, der Controller, der “Spring is here!” zurückgibt, und die Tests unter src/test.
Zwei Workflows: Main Pipeline und Build Pipeline#
GitHub nennt Pipelines Workflows, und sie liegen in .github/workflows/. Wir splitten unsere Pipeline bewusst in zwei Dateien: eine Main Pipeline, die orchestriert, und eine Build Pipeline, die sie aufruft. Workflows zu splitten hält jede Datei klein und erlaubt es dir, die Build Pipeline später aus anderen Workflows wiederzuverwenden.
Lege .github/workflows/main-pipeline.yml an. Tipp: Im File-Editor von GitHub kannst du Slashes im Dateinamen tippen, um Ordner inline zu erzeugen. Die Main Pipeline bekommt einen klaren, nummerierten Namen (00 - Main CI/CD Pipeline), triggert auf push auf main (mit sinnvollen Path-Ignore-Filtern) und auf workflow_dispatch, sodass wir sie manuell starten können, und definiert einen build Job, der unsere build.yml aufruft und die nötigen Secrets weiterreicht.
Nummerierte Namen — 00 - Main, 10 - Build — klingen banal, machen die Actions-UI aber lesbar, sobald du ein Dutzend Workflows nebeneinander hast. Empfehlung.
Nächste Datei: .github/workflows/build.yml. Name: 10 - Build Pipeline. Trigger sind workflow_dispatch (manuell ausführen) und workflow_call (von einem anderen Workflow aufrufbar — genau das nutzt die Main Pipeline).
Der Build Job deklariert die nötigen Permissions, läuft auf ubuntu-latest und kettet eine Reihe von Schritten aneinander, die jeweils eine Action aufrufen. Die Actions: Source-Code mit actions/checkout@v3 auschecken, Java aufsetzen, mit Maven kompilieren, Output-Verzeichnis vorbereiten, Tests ausführen, Test-Result-Verzeichnis vorbereiten, das Application-Binary als Artifact hochladen, die Test-Ergebnisse als ZIP zum Download bereitstellen und die Test-Ergebnisse im GitHub-UI veröffentlichen.
Beide Dateien auf main committen und ab in den Actions-Tab.
Der Pipeline beim Laufen zuschauen#
Im Actions-Tab startet die Main Pipeline, und die Build Pipeline läuft direkt darunter — die nummerierten Namen reihen sich sauber auf. Klickst du rein, bekommst du eine Übersichtsseite: Gesamtdauer, Status, ausgeführte Jobs, drei gefundene Tests, das Application-Binary und die Test-Ergebnisse als Artifacts (als ZIP herunterladbar) und die Test-Ergebnisse direkt im UI gerendert. Klickst du auf den Build Job, hast du das volle Log direkt vor dir.
Woher die Actions kommen#
Wir haben actions/checkout@v3 ohne grosse Erklärung benutzt. Sie kommt aus dem GitHub Marketplace, dem Ort, an dem du Actions findest. Die Checkout-Action stammt von einem verified creator — GitHub bürgt für ihn. Verified Creators sind die sicherere Wahl. Noch sicherer: Source der Verified Action ins Enterprise-Repo kopieren, Security-Review machen und sie von dort konsumieren. Das ist das Modell, das du willst, wenn produktiver Code davon abhängt.
Key Takeaways#
Wähle das Lizenzmodell, das zu dem passt, was du bauen willst. Private Repos plus Advanced Security brauchen GitHub Enterprise. Diese Entscheidung früh treffen — sie prägt alles Weitere.
Actions bewusst aktivieren, nicht per Default. “Alles aus dem Marketplace erlauben” ist bequem und riskant. In Enterprise-Kontexten ist “nur Enterprise” plus kuratierte Allowlist die richtige Baseline.
Workflows liegen in
.github/workflows/. Dieser Ordner ist die gesamte Konfigurationsfläche der Pipeline. Allein zu wissen, dass es ihn gibt, ist die halbe Miete.Workflows für Orchestrierung und Wiederverwendung splitten. Eine Main Pipeline, die eine Build Pipeline (via
workflow_call) aufruft, hält jede Datei klein und erlaubt es, später grössere Pipelines zu komponieren, ohne den Build neu zu schreiben.Nutze ein Naming-Schema wie
00 - Main,10 - Build. Wirkt pedantisch — bis du zehn Workflows hast. Dann ist es das Einzige, was die Actions-UI lesbar hält.Verwende verified Actions oder importiere sie ins Enterprise. Marketplace-Actions laufen in deiner Pipeline mit Zugriff auf deine Secrets. Behandle sie wie Code von Dritten. Verified Creators sind das Minimum; ins Enterprise importierte und reviewte Kopien sind das Optimum.