Software Composition Analysis kümmert sich um die Bibliotheken, die du einbindest. Aber was ist mit dem Code, den dein Team selbst schreibt? Genau dafür ist Static Application Security Testing da. In Teil 5 unserer GitLab DevSecOps Serie integrieren Patrick Steger und ich SAST in die Pipeline, bauen ein paar realistische Schwachstellen in unser Spring-Boot-Beispiel ein und schauen zu, wie GitLab sie aufgreift.
Was SAST tatsächlich macht#
SAST scannt deinen Source Code auf Security-Schwachstellen, ohne die Anwendung auszuführen. Patrick bringt das klassische Beispiel: Kryptografie. Greifst du zu einem schwachen Cipher oder verwendest die normale Random-Klasse, um etwas zu erzeugen, das unvorhersehbar sein müsste, ist das eine Schwachstelle — und genau das, was ein statischer Analyzer beim Lesen des Codes erkennen kann.
SAST in GitLab nutzt primär Semgrep, einen Open-Source-Pattern-Scanner. Je nach Sprache kommen weitere Tools dazu. Für unser Java-Beispiel wird Semgrep mit SpotBugs kombiniert. Jedes Tool hat eigene Stärken und Schwächen; die Kombination erweitert die Abdeckung.
SAST in die Pipeline einhängen#
Der Mechanismus ist derselbe wie bei allem, was wir bisher hinzugefügt haben. Wir öffnen .gitlab-ci.yml, ergänzen eine include-Zeile, die das von GitLab bereitgestellte Template SAST.gitlab-ci.yml referenziert, committen auf master — und die Pipeline übernimmt den Rest.
Bevor wir die Zeile hinzufügen, vereinfacht Patrick die Spring-Boot-Mainklasse und ergänzt einen neuen Controller mit absichtlich eingebauten Problemen. Das Finding, das wir von SAST erwarten, sitzt auf Zeile 47: ein unsicheres java.util.Random, wo SecureRandom hingehört. Ein vorhersehbarer Pseudozufallsgenerator überall dort, wo kryptografische Schlüssel oder Tokens entstehen, ist genau die Art von Befund, die SAST aufzeigen soll.
Zwei Tools unter der Haube#
Öffnest du das Template und suchst nach Java, siehst du, dass GitLab zwei Scanner orchestriert: Semgrep und SpotBugs. Die Pipeline bekommt entsprechend zwei neue Jobs — semgrep-sast und spotbugs-sast. Klickst du in einen davon hinein, zeigt das Log das gewohnte Rezept: Docker-Image ziehen, Scanner ausführen, Findings ins GitLab-Vulnerability-System hochladen.
Die Job-Logs sind nicht der Ort, an dem du die Ergebnisse liest. Sie sind laut und nicht für Menschen gemacht. Die eigentliche Oberfläche ist der Security-Tab der Pipeline mit dem SAST-Filter. Dort taucht unser “Predictable Pseudorandom Generator”-Finding genau dort auf, wo wir es erwartet haben — mit direktem Sprung in die Source-Datei auf Zeile 47.
Wo die Findings leben#
GitLab bietet zwei Sichten auf Schwachstellen. Der Security-Tab der Pipeline zeigt, was dieser Lauf gefunden hat. Security & Compliance → Vulnerability Report auf Projektebene gibt dir die Governance-Sicht — alles über alle Pipelines hinweg, mit Filtern und Triage. Diese Governance-Sicht braucht die Ultimate Edition. Die SAST-Scanner selbst laufen mit der freien Lizenz. Gut zu wissen, bevor jemand auf Basis von Screenshots einen Vertrag unterschreibt.
Was das bringt#
Eine include-Zeile bringt zwei Scanner, zwei neue Pipeline-Jobs, automatische Vulnerability-Uploads und eine saubere UI für die Triage. Verglichen damit, dasselbe auf einer anderen Plattform von Hand zusammenzubauen, ist das wirklich günstig. Der Trade-off: Du akzeptierst die Auswahl, die GitLab für dich trifft — welche Tools laufen und welche Regeln aktiv sind. Für die meisten Teams ist das die richtige Wahl — starte mit dem Template, und investiere erst in eigene Regeln oder zusätzliche Scanner, wenn du belegen kannst, dass die Defaults etwas übersehen, das dir wichtig ist.
Key Takeaways#
SAST scannt deinen Code, nicht die Dependencies. SCA deckt Drittbibliotheken ab; SAST geht um den Code, den dein Team schreibt. Beides gehört in die CI und beantwortet unterschiedliche Fragen.
Eine
include-Zeile bringt zwei Scanner. Das von GitLab bereitgestellte TemplateSAST.gitlab-ci.ymlverdrahtet Semgrep und für Java zusätzlich SpotBugs. Du musst weder Tools auswählen noch installieren noch Docker-Images pflegen.Mehrere Scanner verbessern die Abdeckung. Jedes Tool hat eigene Stärken. Semgrep und SpotBugs zusammen finden mehr als jedes für sich allein — und du bekommst das mit dem Template gratis.
Findings im Security-Tab lesen, nicht im Job-Log. Das Pipeline-Log zeigt nur, dass der Scanner gelaufen ist. Die eigentlichen Schwachstellen findest du im Security-Tab der Pipeline, mit Deep-Links in die betroffene Code-Stelle.
RandomstattSecureRandomist genau der Bug, für den SAST da ist. Vorhersehbare Pseudozufallsgeneratoren in Security-Kontexten sind ein Lehrbuch-Finding für statische Analyse. Schreibt dein Team Krypto- oder Auth-Code, rechtfertigt allein das die wenigen Minuten, SAST zu aktivieren.Scannen ist gratis; Governance ist Ultimate. Die SAST-Scanner laufen im Free Tier. Der projektübergreifende Vulnerability Report unter Security & Compliance braucht die Ultimate Edition. Plane das in deine Tier-Wahl ein und nimm nicht an, dass die Dashboards aus Screenshots zur freien Version gehören.