Sicherheits-Scans in CI für Linux-Server automatisieren mit OpenSCAP und Lynis

Wer Linux-Server heute betreibt, kennt das Grundproblem: Sicherheits- und Compliance-Anforderungen sind selten einmalige Projekte, sondern wiederkehrende Nachweise. Trotzdem werden Checks oft „nach Gefühl“ oder nur vor Audits ausgeführt. Genau hier setzt die Automatisierung von Sicherheits-Scans in CI an: Sie machen Härtung und Compliance messbar, wiederholbar und vor allem früh sichtbar – bevor ein Image ausgerollt oder eine Konfigurationsänderung produktiv wird.

In diesem Beitrag geht es praxisnah darum, wie Sie OpenSCAP und Lynis in eine CI-Pipeline integrieren. OpenSCAP steht für „Security Content Automation Protocol“ und prüft mit standardisierten Inhalten (z. B. XCCDF/OVAL) systematisch Konfigurationen gegen Benchmarks wie CIS oder STIG. Lynis ist ein bewährtes Linux-Audit-Tool, das Härtungshinweise, Schwachstellenindikatoren und Betriebsrisiken aus der Perspektive eines Admin-Audits zusammenträgt. Beide Tools ergänzen sich: OpenSCAP liefert strukturierte Compliance-Ergebnisse, Lynis liefert pragmatische Maßnahmen und „Operator-Wissen“. Ziel ist ein Setup, das im Alltag funktioniert: klare Baselines, saubere Artefakte, nachvollziehbare Schwellenwerte, und eine Rückfallstrategie, wenn ein Gate plötzlich zu hart ist.

Warum Sicherheits-Scans in CI bei Linux-Servern mehr bringen als „Security einmal im Quartal“

CI (Continuous Integration) wird im Infrastruktur-Kontext oft als Pipeline rund um Images, IaC (Infrastructure as Code) oder Konfigurationsmanagement verstanden. Der Gewinn ist nicht „mehr Scans“, sondern kürzere Feedback-Zyklen und weniger Drift (Abweichung von der Soll-Konfiguration über Zeit).

• Frühe Erkennung: Fehlkonfigurationen (z. B. SSH-Policy, Sysctl, Paketstände) werden beim Build oder vor dem Merge sichtbar, nicht erst nach dem Rollout.
• Nachvollziehbarkeit: Scan-Reports sind Pipeline-Artefakte. Sie lassen sich versionieren, vergleichen und für Audits belegen.
• Standardisierung: Ein Security Gate in CI zwingt zu Baselines, Ausnahmeprozessen und klaren Zuständigkeiten.
• Skalierung: Einmal etabliert, prüft dieselbe Logik hunderte Hosts/Images ohne zusätzlichen Aufwand.

Wichtig: CI-Scans ersetzen kein laufendes Monitoring, kein Patch-Management und kein Incident Response. Sie sind ein Qualitätsfilter für Änderungen an Images und Konfigurationen – und reduzieren die Wahrscheinlichkeit, dass Sie technische Schulden in Produktion „einbacken“.

OpenSCAP und Lynis: Rollen, Stärken und typische Missverständnisse

OpenSCAP in zwei Sätzen

OpenSCAP ist eine Toolchain, die SCAP-Content verarbeitet. SCAP-Content besteht u. a. aus XCCDF (Checklisten- und Bewertungslogik) und OVAL (Prüfdefinitionen). Praktisch heißt das: Sie wählen ein Profil (z. B. CIS Level 1) und OpenSCAP bewertet den Zielzustand. Ergebnis ist ein strukturierter Report (XML/HTML), der sich für Compliance und Vergleichbarkeit eignet.

Lynis in zwei Sätzen

Lynis führt lokal ein Audit aus und liefert Findings, Hinweise und Hardening-Vorschläge. Es ist weniger „Benchmark-getrieben“, dafür sehr praxisorientiert: Dateirechte, Dienste, Kernel-Settings, Logging, Authentifizierung, Integriäts-Checks, Bootloader-Aspekte. Ergebnis ist ein Textreport plus Kennzahlen, die man als Gate interpretieren kann.

Typische Missverständnisse im Betrieb

• „Ein Tool reicht“: In der Praxis decken OpenSCAP und Lynis unterschiedliche Blickwinkel ab. Kombiniert sind sie robuster gegen blinde Flecken.
• „CI scannt Produktion“: CI sollte primär Artefakte scannen (Images, Golden AMIs, Container-Basen, VM-Templates). Produktionsscans gehören eher in geplante Jobs (z. B. zentral orchestriert) mit Change-Fenstern.
• „Alles muss auf 100%“: Benchmarks enthalten Anforderungen, die nicht in jedes Betriebsmodell passen (z. B. strikte Passwortregeln bei reiner SSH-Key-Auth). Sie brauchen Baselines und dokumentierte Ausnahmen.

Architektur: Wo laufen die Scans in einer CI/CD-Pipeline sinnvoll?

Für Linux-Server in Cloud- oder Virtualisierungsumgebungen hat sich ein Muster bewährt: Scan nicht den „laufenden Server“, sondern das Image und die Konfigurationsänderung. Das reduziert Seiteneffekte und macht Ergebnisse reproduzierbarer.

Bewährtes Pipeline-Muster (Image-orientiert)

• Build: Image/Template bauen (Packer, Image Builder, eigene Build-Skripte).
• Provisioning: Härtung anwenden (Ansible, Salt, Chef, Cloud-init-Module). Hier entsteht die Baseline.
• Scan: OpenSCAP und Lynis gegen das gebaute Artefakt ausführen (z. B. in einer VM, per chroot, per Container-Approach je nach Toolfähigkeit).
• Gate: Ergebnisse gegen Schwellenwerte prüfen (z. B. „keine High-Findings“, „Compliance >= X%“).
• Publish: Nur bei Erfolg ins Registry/Template-Repository.

Wenn Sie dennoch einen „laufenden“ Zielhost scannen (z. B. Staging), machen Sie es kontrolliert: dedizierte Staging-Instanz, feste Daten, keine produktiven Secrets und klare Laufzeitlimits. Andernfalls erzeugen Scans unklare Findings (zum Beispiel durch temporäre Debug-Pakete oder wechselnde Mounts).

Voraussetzungen: Was Sie vor der Automatisierung klären sollten

Automatisierte Scans scheitern selten am Tool, sondern an ungeklärten Rahmenbedingungen. Klären Sie vorab:

1) Zielsysteme und Benchmark-Bezug

• Distributionen und Versionen (RHEL/Alma/Rocky, Debian/Ubuntu, SLES).
• Rollenklassen (Web, DB, Jump Host, Bastion, Kubernetes Node).
• Relevante Benchmarks (CIS, DISA STIG, interne Policies). „Benchmark“ bedeutet hier: definierter Sollzustand, nicht „Best Practice nach Gefühl“.

2) Vertrauensmodell und Rechte

OpenSCAP und Lynis benötigen für viele Checks erhöhte Rechte (root), weil sie Systemdateien, Kernel-Parameter oder Service-Konfigurationen auslesen. In CI ist das heikel: Sie wollen nicht beliebigen Code mit Root ausführen. Typische Gegenmaßnahmen:

• Scans in isolierten Runnern (dedizierte VM, ephemeral Container/VM, keine Shared Runner).
• Nur signierte/vertrauenswürdige Pipeline-Quellen dürfen Scan-Jobs triggern (Branch-Protection, Code-Owner, Merge-Gates).
• Keine produktiven Secrets im Scan-Job. Scans brauchen selten Applikationssecrets – wenn doch, ist das ein Warnsignal.

3) Ergebnisformat und Aufbewahrung

Definieren Sie früh, welche Artefakte Sie speichern: HTML-Bericht (lesbar), XML/JSON (maschinenlesbar), sowie eine kleine Zusammenfassung für das Gate. Planen Sie Retention (Aufbewahrungsdauer) und Zugriff (Audit, Security, Betrieb).

Sicherheits-Scans in CI: Umsetzung mit OpenSCAP und Lynis als wiederholbarer Job

Im Folgenden ein praxistauglicher Ansatz, der sich in GitLab CI oder ähnlichen Systemen leicht abbilden lässt. Das Ziel ist nicht ein „perfektes“ YAML für jede Plattform, sondern ein Muster: installiere Tools, führe Scan aus, archiviere Artefakte, werte Schwellen aus.

Schritt 1: Tooling installieren (Distribution beachten)

OpenSCAP-Pakete heißen je nach Distribution unterschiedlich. Auf RHEL-artigen Systemen sind das typischerweise openscap-scanner und scap-security-guide (SSG, ein verbreitetes Content-Paket). Auf Debian/Ubuntu sind es openscap-scanner und ggf. separate Content-Pakete. Lynis ist oft als Paket verfügbar oder wird als geprüfter Download eingebunden. Für CI empfiehlt sich: möglichst aus offiziellen Repos, andernfalls mit Fixierung auf Version und Prüfsumme.

#!/usr/bin/env bash
set -euo pipefail

# Beispiel: RHEL/Alma/Rocky
sudo dnf -y install openscap-scanner scap-security-guide lynis

# Beispiel: Debian/Ubuntu (Paketnamen können je Release variieren)
# sudo apt-get update
# sudo apt-get -y install openscap-scanner lynis
# Content (SSG) kann je nach Repo-Lage separat sein

Warum das wichtig ist: Viele „Pipeline bricht“ Fälle kommen aus Content-Mismatch (Profile existieren nicht) oder aus fehlenden Abhängigkeiten (z. B. Python-Module für einzelne Checks). Halten Sie Tool- und Content-Versionen unter Kontrolle, sonst ändern sich Ergebnisse ohne bewusste Änderung an Ihrer Baseline.

Schritt 2: OpenSCAP-Scan mit Profil und Report-Artefakten

OpenSCAP nutzt meist oscap als CLI. Entscheidend sind: Content-Datei (z. B. SSG), Profil-ID (z. B. CIS Level 1) und Output. Für CI ist es sinnvoll, sowohl Result XML (maschinenlesbar) als auch HTML-Report (für Menschen) zu erzeugen.

#!/usr/bin/env bash
set -euo pipefail

OUTDIR="artifacts/openscap"
mkdir -p "$OUTDIR"

# Beispielpfad für SSG auf RHEL-artigen Systemen (je nach Distro/Version prüfen)
SSG_DS="/usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml"
PROFILE="xccdf_org.ssgproject.content_profile_cis"

# Scan gegen das lokale System (typisch in einer ephemeral VM/Build-Umgebung)
# --results-arf erzeugt ein ARF (Asset Reporting Format), gut für Weiterverarbeitung
sudo oscap xccdf eval 
  --profile "$PROFILE" 
  --results-arf "$OUTDIR/results.arf.xml" 
  --report "$OUTDIR/report.html" 
  "$SSG_DS"

Wann das scheitert:

• Falscher Content: SSG-Datei passt nicht zur Distribution/Version. Ein AlmaLinux-Content auf Ubuntu ergibt Unsinn.
• Profil nicht vorhanden: Profil-ID stimmt nicht. Prüfen Sie verfügbare Profile vorab.
• „Not applicable“ Flut: Viele Regeln sind nicht anwendbar, weil Rolle/Packages fehlen. Dann ist das Profil zu generisch oder Sie scannen das falsche Artefakt.

Prüfschritt zum Content (Profile anzeigen):

#!/usr/bin/env bash
set -euo pipefail

SSG_DS="/usr/share/xml/scap/ssg/content/ssg-almalinux9-ds.xml"
oscap info "$SSG_DS" | sed -n '1,200p'

Schritt 3: Lynis-Audit ausführen und scorebar machen

Lynis erzeugt Berichte unter /var/log/lynis-report.dat und /var/log/lynis.log. Für CI kopieren Sie die Dateien in ein Artefaktverzeichnis. Zusätzlich brauchen Sie eine kleine Auswertung, die aus dem Report eine Kenngröße extrahiert (z. B. Hardening-Index) oder High-Risk-Warnungen zählt.

#!/usr/bin/env bash
set -euo pipefail

OUTDIR="artifacts/lynis"
mkdir -p "$OUTDIR"

sudo lynis audit system --quick --no-colors || true

# Reports in Artefakte kopieren
sudo cp -a /var/log/lynis-report.dat "$OUTDIR/" || true
sudo cp -a /var/log/lynis.log "$OUTDIR/" || true

# Beispiel: Hardening-Index aus report.dat extrahieren
# (Format kann je Version variieren; daher defensiv parsen)
HARDENING_INDEX=$(awk -F= '/^hardening_index=/{print $2}' "$OUTDIR/lynis-report.dat" | tail -n1)
HARDENING_INDEX=${HARDENING_INDEX:-0}

echo "Lynis hardening_index=$HARDENING_INDEX" | tee "$OUTDIR/summary.txt"

Warum || true hier vorkommt: Lynis verwendet Exit-Codes nicht immer so, wie CI-Gates sie erwarten. Besser ist, Lynis laufen zu lassen, Artefakte zu sichern und die Gate-Logik selbst anhand von klaren Kriterien zu implementieren (z. B. Mindestindex oder Anzahl bestimmter Warnkategorien). Das verhindert „false negatives“, bei denen der Job abbricht, bevor Reports gesichert sind.

Schritt 4: Gate-Logik mit Schwellenwerten (und warum Sie klein starten sollten)

Ein Security Gate ist nur dann nützlich, wenn es stabil ist. Starten Sie mit konservativen Regeln:

• Gate bricht nur bei kritischen Findings ab (z. B. bestimmte OpenSCAP-Regeln, die Sie als „must pass“ definieren).
• Alles andere wird als Warnung reportet und in Tickets/Backlog überführt.
• Schwellenwerte werden bewusst verschärft, nachdem die Baseline etabliert ist.

Beispiel: einfaches Gate auf Lynis-Hardening-Index (als Einstieg, nicht als alleinige Wahrheit):

#!/usr/bin/env bash
set -euo pipefail

MIN_INDEX=${MIN_INDEX:-70}
REPORT="artifacts/lynis/lynis-report.dat"

IDX=$(awk -F= '/^hardening_index=/{print $2}' "$REPORT" | tail -n1)
IDX=${IDX:-0}

if [ "$IDX" -lt "$MIN_INDEX" ]; then
  echo "FAIL: Lynis hardening_index $IDX ist kleiner als Mindestwert $MIN_INDEX"
  exit 2
fi

echo "OK: Lynis hardening_index $IDX (>= $MIN_INDEX)"

Stolperfalle: Ein einzelner Index kann Verbesserungen in einem Bereich verdecken, während ein anderer Bereich schlechter wird. Nutzen Sie den Index als „Frühwarnung“, aber definieren Sie mittelfristig konkrete Muss-Kriterien (z. B. „Root-Login per SSH deaktiviert“, „Auditd aktiv“, „kritische Dateirechte korrigiert“).

Beispiel: GitLab-CI-Jobstruktur mit Artefakten

Das folgende Beispiel zeigt eine grobe Struktur, die Sie an Ihre Umgebung anpassen. Es geht um die Prinzipien: isolierter Runner, Artefakte, klare Stages, und ein Gate, das Reports nicht verliert.

stages:
  - build
  - scan

variables:
  MIN_INDEX: "70"

scan_security:
  stage: scan
  image: almalinux:9
  tags:
    - isolated-runner
  script:
    - bash ci/install-tools.sh
    - bash ci/run-openscap.sh
    - bash ci/run-lynis.sh
    - bash ci/gate-lynis.sh
  artifacts:
    when: always
    expire_in: 30 days
    paths:
      - artifacts/openscap/
      - artifacts/lynis/

Wichtig für den Betrieb: Der Runner muss so gebaut sein, dass Root-Aktionen möglich sind (oder Sie scannen innerhalb einer VM, die der Job startet). In Shared-Runnern ist das oft nicht zulässig – und aus Security-Sicht auch nicht empfehlenswert.

Cloud- und Image-Workflows: Was sich gegenüber Bare Metal ändert

In Cloud-Umgebungen (IaaS, VM-Templates, Golden Images) sind zwei Effekte relevant:

Ephemeral Hosts und Baseline Drift

Wenn Instanzen regelmäßig neu gebaut werden, ist CI der richtige Ort, um sicherzustellen, dass neue Images nicht regressieren. Drift entsteht dann eher durch „Day-2“-Änderungen (Hotfixes auf laufenden Hosts). Für diesen Fall kombinieren Teams CI-Scans (vor Release) mit periodischen Compliance-Jobs (z. B. monatlich) auf repräsentativen Hosts.

Cloud-init, Agenten und Provider-spezifische Defaults

Cloud-init kann SSH-Settings, User, Hostkeys oder Paketquellen verändern. Provider-Images bringen außerdem oft eigene Agenten mit (z. B. für Monitoring, Guest Tools). Das führt zu Findings, die nicht „unsicher“, aber abweichend sind. Praxisregel: Scannen Sie das Artefakt nach Ihren Provisioning-Schritten und mit den Agenten, die später wirklich vorhanden sind. Sonst bekommen Sie eine Baseline, die in der Realität nie erreicht wird.

Troubleshooting: Häufige Fehlerbilder und wie Sie sie systematisch lösen

Problem 1: OpenSCAP findet Profile nicht oder liefert leere Reports

• Ursache: falsche DataStream-Datei (SSG) oder falsche Profil-ID.
• Prüfung: oscap info auf die DS-Datei, Profile vergleichen, Pfade je Distribution verifizieren.
• Lösung: Content-Pfad in der Pipeline nicht hardcoden, sondern pro OS-Matrix setzen (z. B. Variable je Job).

Problem 2: Viele „fail“ wegen CI-Umgebung statt Ziel-Baseline

• Ursache: Sie scannen eine Build-Umgebung, die nicht der späteren Serverrolle entspricht (fehlende Mounts, andere Kernel-Parameter, temporäre Pakete).
• Prüfung: Rollen- und Paketliste prüfen, Scan in einer VM ausführen, die näher an Produktion ist.
• Lösung: Scan-Stage an das Ende des Image-Builds setzen und die Umgebung minimal variieren lassen.

Problem 3: Lynis meldet „skipped tests“ oder widersprüchliche Hinweise

• Ursache: fehlende Tools (z. B. netstat/ss), eingeschränkte Rechte, Container-Umgebung ohne Systemd, read-only FS.
• Prüfung: Lynis-Log lesen, gezielt die fehlenden Abhängigkeiten nachinstallieren.
• Lösung: Scans nicht in zu stark eingeschränkten Containern ausführen, sondern in VM/privilegiertem Kontext oder im Image selbst.

Problem 4: Gate ist instabil wegen wechselnder Ergebnisse

• Ursache: nicht gepinnte Paketstände, wechselnder Content, nicht deterministische Umgebung.
• Prüfung: Tool- und Content-Versionen loggen, Build-Inputs pinnen (Repos, Mirror, Versionsstände).
• Lösung: „Policy as Code“: Baseline und Ausnahmen versionieren, Updates bewusst einplanen (z. B. monatliche Content-Refresh-Pipeline).

Checkliste: Von „erster Scan“ zu belastbarem CI-Security-Gate

• Scope: Welche OS-Versionen und Rollen werden abgedeckt? Welche Benchmarks sind relevant?
• Isolation: Dedizierte Runner/VMs, keine Shared Runner mit Root.
• Determinismus: Tool/Content-Versionen kontrollieren, Scan-Umgebung stabil halten.
• Artefakte: HTML für Menschen, XML/ARF für Maschinen, Retention definiert.
• Baseline: Erst messen, dann Schwellen setzen. Ausnahmen dokumentieren.
• Gate-Design: Start mit wenigen Muss-Kriterien; später verschärfen.
• Operationalisierung: Findings in Tickets/Backlog, Verantwortlichkeiten klar.

Rückfallstrategie: Was tun, wenn das Gate plötzlich alles blockiert?

Ein Security Gate ist dann gefährlich, wenn es unkontrolliert Deployments stoppt, ohne dass ein gangbarer Prozess existiert. Planen Sie deshalb eine Rückfallstrategie, die Sicherheit und Lieferfähigkeit balanciert:

1) „Soft Fail“ als Übergang

In frühen Phasen: Job darf fehlschlagen, aber blockiert nicht den gesamten Release (z. B. nur Warnung). Sobald Baselines stabil sind, wechseln Sie auf „Hard Fail“ für klar definierte Kriterien.

2) Break-Glass mit Dokumentation

Wenn ein dringender Fix ausgerollt werden muss, brauchen Sie eine kontrollierte Ausnahme: z. B. Merge-Approval durch Security/Operations und automatische Erzeugung eines Ausnahme-Logs (Ticket-ID, Ablaufdatum). Wichtig ist nicht das Tooling, sondern dass Ausnahmen sichtbar und zeitlich begrenzt sind.

3) Baseline-Versionierung und Rollback

Versionieren Sie Profile, Tailoring (angepasste Regeln) und Schwellenwerte. Wenn ein Content-Update plötzlich neue Failures erzeugt, können Sie auf die letzte funktionierende Baseline zurück. Das ist der Unterschied zwischen „CI blockiert uns“ und „wir steuern Änderungen“.

Fazit: OpenSCAP und Lynis in CI bringen Ruhe in Compliance und Hardening

Automatisierte Sicherheits-Scans in CI sind kein Selbstzweck. Richtig umgesetzt schaffen sie aber genau das, was Admin-Teams im Alltag brauchen: reproduzierbare Checks, nachvollziehbare Reports und frühzeitige Warnungen, bevor sich Fehlkonfigurationen in neue Images und Rollouts einschleichen. OpenSCAP liefert die strukturierte Benchmark-Perspektive, Lynis die pragmatische Audit- und Härtungssicht. Der Schlüssel liegt in stabilen Baselines, sauberer Isolation der Runner, klaren Artefakten und einem Gate, das schrittweise verschärft wird. Wer so vorgeht, reduziert Drift, spart Audit-Stress und kann Sicherheitsanforderungen operationalisieren, ohne die Delivery zu blockieren.

Für dieses Thema sind auch Linux Hardening und Compliance Scans wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.