14 — DevSecOps

Teil E — Wie man absichert. Zurück zur Übersicht.

Der klassische Ablauf: Die Anwendung ist fertig, dann kommt die Sicherheitsprüfung. Sie dauert drei Wochen, findet vierzig Befunde, und die Hälfte davon lässt sich nur mit erheblichem Umbau beheben. Der Termin steht aber. Also werden Ausnahmen genehmigt, und man nimmt sich vor, das später zu beheben — wobei „später„ ein Fachbegriff für „nie“ ist.

DevSecOps überträgt das Shift-Left-Prinzip aus Kapitel 4 auf die Sicherheit: Prüfungen finden fortlaufend und automatisiert statt, nicht als Torwächter am Ende.

Dazu kommen Secret Scanning (Zugangsdaten im Repository) und Container-Scanning (Schwachstellen im Image).

Keines dieser Verfahren ersetzt die anderen. SAST kennt den Code, aber nicht die Umgebung. DAST kennt die Umgebung, aber nicht den Code. SCA kennt beides nicht, dafür aber die Schwachstellendatenbanken — und der überwiegende Teil der ausnutzbaren Lücken in typischen Anwendungen steckt nicht im Eigenanteil, sondern in den mitgebrachten Bibliotheken.

Eine moderne Anwendung besteht zu einem großen Teil aus fremdem Code. Eine mittelgroße Python- oder JavaScript-Anwendung bringt schnell mehrere hundert Pakete mit, die überwiegend niemand je angesehen hat.

Ein SBOM (Software Bill of Materials) ist die Stückliste dazu: eine maschinenlesbare Aufstellung aller enthaltenen Komponenten mit Version und Herkunft.

# SBOM erzeugen
syft packages dir:. -o cyclonedx-json > sbom.json
 
# Gegen bekannte Schwachstellen prüfen
grype sbom:sbom.json
 
# Image signieren
cosign sign --key cosign.key registry.intern/kfz-rechner:2.5.0
 
# Signatur prüfen - vor dem Ausrollen
cosign verify --key cosign.pub registry.intern/kfz-rechner:2.5.0

# Versionen festnageln - reproduzierbare Builds
pip-compile requirements.in --generate-hashes -o requirements.txt

Automatische Aktualisierungswerkzeuge wie Renovate oder Dependabot legen Pull Requests für neue Versionen an. Zusammen mit einer belastbaren Testsuite aus Kapitel 4 wird daraus ein funktionierendes Verfahren: Der Pull Request kommt automatisch, die Pipeline prüft, ein Mensch führt zusammen.

Der häufigste Fehler beim Einführen von Scannern: Man schaltet sie ein, bekommt 1.400 Befunde und schaltet sie wieder aus.

Ein tragfähiges Vorgehen:

1. Basislinie ziehen. Alle bestehenden Befunde werden zunächst dokumentiert, aber nicht blockierend gestellt.
2. Ab jetzt keine neuen. Die Pipeline wird rot bei neuen Befunden ab „hoch“. Das ist die entscheidende Regel — sie verhindert Verschlechterung ohne den Betrieb lahmzulegen.
3. Bestand abarbeiten. Ein festes Kontingent pro Sprint, nach Risiko sortiert.
4. Ausnahmen befristen. Jede Ausnahme bekommt Begründung, Verantwortlichen und Ablaufdatum.

schwachstellen:
  stage: scannen
  script:
    # Bestand: nur berichten
    - trivy image --exit-code 0 --severity LOW,MEDIUM "$IMAGE:$TAG"
    # Neue kritische Befunde: Pipeline rot
    - trivy image --exit-code 1 --severity HIGH,CRITICAL
        --ignorefile .trivyignore "$IMAGE:$TAG"

.trivyignore

# Befristete Ausnahmen - jede mit Begründung und Ablaufdatum!
# CVE-2024-12345  bis 2026-09-30, Fix erfordert Umstieg auf lib 4.x,
#                 Ticket SEC-231, nicht erreichbar (kein Netzwerkpfad)
CVE-2024-12345

Nicht jeder Befund ist ein Risiko. Eine Schwachstelle in einer Bibliothek, deren betroffene Funktion die Anwendung gar nicht aufruft, ist real vorhanden und praktisch bedeutungslos. Umgekehrt kann ein mittelschwerer Befund an einer exponierten Stelle dringlicher sein als ein kritischer im Innern. Bewertung braucht Kontext, und der Scanner hat ihn nicht.

Werkzeuge finden bekannte Muster. Konstruktionsfehler finden sie nicht — dafür braucht es ein Gespräch, und zwar vor dem Bauen.

Vier Fragen, die für den Anfang genügen:

1. Woran arbeiten wir? (Ein Bild reicht.)
2. Was kann schiefgehen?
3. Was tun wir dagegen?
4. Haben wir gute Arbeit geleistet?

Als Gedankenstütze für die zweite Frage dient STRIDE:

Eine Stunde mit einem Whiteboard zu Beginn ersetzt keine Werkzeuge, findet aber die Sorte Fehler, die kein Werkzeug je findet.

.gitlab-ci.yml

stages: [pruefen, testen, bauen, scannen, ausrollen]
 
# ---------- schnelle Prüfungen ----------
geheimnisse:
  stage: pruefen
  image: zricethezav/gitleaks:latest
  script:
    - gitleaks detect --source . --redact --verbose

sast:
  stage: pruefen
  image: python:3.12-slim
  script:
    - pip install --quiet bandit
    - bandit -r src/ -f json -o bandit.json || true
    - bandit -r src/ -ll          # blockiert ab Schweregrad "medium"
  artifacts:
    paths: [bandit.json]
    when: always

iac-scan:
  stage: pruefen
  image: bridgecrew/checkov:latest
  script:
    - checkov -d ansible/ --compact --quiet
    - checkov -f Containerfile --framework dockerfile
 
# ---------- Abhängigkeiten ----------
sca:
  stage: testen
  image: python:3.12-slim
  script:
    - pip install --quiet pip-audit
    - pip-audit -r requirements.txt --strict
 
# ---------- Stückliste und Signatur ----------
sbom:
  stage: bauen
  image: anchore/syft:latest
  script:
    - syft "$IMAGE:$TAG" -o cyclonedx-json > sbom.json
  artifacts:
    paths: [sbom.json]
    expire_in: 1 year          # für die Nachweisführung aufbewahren

signieren:
  stage: bauen
  image: gcr.io/projectsigstore/cosign:latest
  script:
    - echo "$COSIGN_KEY" > /tmp/cosign.key
    - cosign sign --key /tmp/cosign.key "$IMAGE:$TAG"
  after_script:
    - shred -u /tmp/cosign.key
 
# ---------- Container prüfen ----------
container-scan:
  stage: scannen
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 0 --severity LOW,MEDIUM "$IMAGE:$TAG"
    - trivy image --exit-code 1 --severity HIGH,CRITICAL "$IMAGE:$TAG"

Aufgaben:

1. Bring alle Stufen zum Laufen. Wie lange dauert die Pipeline jetzt insgesamt?
2. Baue absichtlich einen SQL-String per Zeichenkettenverkettung. Findet bandit ihn?
3. Trage ein Passwort in eine Datei ein und committe. Findet gitleaks es? Nimm den Commit zurück — und wechsle das Passwort trotzdem.
4. Erzeuge die Stückliste und suche darin eine Bibliothek, von deren Existenz du nichts wusstest.
5. Setze eine Ausnahme in .trivyignore mit Begründung und Ablaufdatum.
6. Ergänze in der Ausrollstufe eine Signaturprüfung, die verhindert, dass unsignierte Images starten.

Wenn morgen früh eine kritische Schwachstelle in einer weit verbreiteten Bibliothek bekannt wird — wie lange braucht ihr für die Antwort auf die Frage, ob und wo ihr betroffen seid?

Weiter mit Kapitel 15 — DORA-Metriken, SLI, SLO und Error Budget