Praxis: Sicherheitsscans ausführen und prüfen

Eine grüne Pipeline belegt noch keinen ausgeführten Sicherheitsscan. Job-Logs und Berichtsartefakte zeigen, was untersucht wurde und welche Funde vorliegen.

SAST und Secret Detection ausführen

Für die Übung wird ein separates, geklontes Projekt mit Push-Berechtigung und einem Linux-AMD64-Runner mit Docker- oder Kubernetes-Executor benötigt. Legen Sie app.py mit dieser Python-Eingabe für SAST an:

print("Security scan practice")

Legen Sie .gitlab-ci.yml mit dieser vollständigen Konfiguration an:

stages:
  - test

include:
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml

1. Beide Dateien committen und auf einen Branch pushen. Die zugehörige Branch-Pipeline öffnen.
2. semgrep-sast und secret_detection öffnen. In den Logs prüfen, ob beide Scans abgeschlossen wurden.
3. gl-sast-report.json und gl-secret-detection-report.json aus den jeweiligen Job-Artefakten herunterladen. In jedem Bericht den Scanner und die Funde ermitteln. Die Sicherheitsansichten der Oberfläche hängen von der GitLab-Lizenz ab. Für diese Übung die JSON-Berichte verwenden.
4. Einen Fund mit Dateipfad notieren oder festhalten, dass der Scan ohne Funde abgeschlossen wurde. Niemals echte Zugangsdaten als Testdaten committen.

Erwartetes Ergebnis sind zwei abgeschlossene Scans mit herunterladbaren Berichten. Diese minimale Eingabe kann ohne Funde bleiben. Fehlt ein Job, Runner-Verfügbarkeit, unterstützte Dateien und Job-Regeln prüfen.

Dependency Scanning ergänzen, optional

Prüfen Sie vorab, ob die Instanz GitLab Ultimate, synchronisierte Paketmetadaten und die v2-Vorlage bereitstellt. Verwenden Sie eine Anwendung mit einer unterstützten Lockdatei oder einem Abhängigkeitsgraphen. Überspringen Sie diese Erweiterung, wenn die Voraussetzungen fehlen.

Ersetzen Sie die include-Liste durch:

include:
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml
  - template: Jobs/Dependency-Scanning.v2.gitlab-ci.yml

1. Anwendungsdateien und Konfiguration pushen. Bei einem offenen Merge Request dependency-scanning in der MR-Pipeline prüfen, die beiden anderen Scans in der Branch-Pipeline. Ohne offenen MR die Branch-Pipeline prüfen.
2. gl-sbom-*.cdx.json und gl-dependency-scanning-report.json aus dependency-scanning herunterladen. Eine Komponente mit Versionsnummer in der SBOM identifizieren und anschließend den Schwachstellenbericht prüfen.

Erwartetes Ergebnis sind ein Komponentenverzeichnis und ein Dependency-Scanning-Bericht. Ein erfolgreicher Job ohne diese Berichte erfüllt das Ziel nicht.

Die GitLab-Dokumentationen zu SAST, Secret Detection und Dependency Scanning beschreiben die Konfiguration im Detail.

Prüfen Sie sowohl die Ausführung des Scanners als auch seinen Bericht. Keine Funde garantieren keine schwachstellenfreie Anwendung.

Check