Automatiser les scans de sécurité dans la CI pour les serveurs Linux avec OpenSCAP et 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.

Architecture : Où les scans s’exécutent-ils de manière pertinente dans une pipeline CI/CD ?

Pour Linux-serveurs dans des environnements cloud ou de virtualisation, un modèle éprouvé s’est imposé : scanner non pas le «serveur en cours d’exécution», mais l’image et la modification de configuration. Cela réduit les effets de bord et rend les résultats plus reproductibles.

Modèle de pipeline éprouvé (orienté image)

• Build : construire l’image/le template (Packer, Image Builder, scripts de build internes).
• Provisioning : appliquer le durcissement (Ansible, Salt, Chef, modules Cloud-init). C’est ici que la ligne de base est définie.
• Scan : exécuter OpenSCAP et Lynis contre l’artefact construit (p. ex. dans une VM, via chroot, via une approche conteneur selon les capacités de l’outil).
• Gate : vérifier les résultats par rapport à des seuils (p. ex. «pas de High-Findings», «Compliance >= X %»).
• Publish : publication dans le registre/le dépôt de templates uniquement en cas de succès.

Si vous devez malgré tout scanner un hôte cible «en cours d’exécution» (p. ex. en staging), faites-le de manière contrôlée : instance de staging dédiée, données fixes, pas de secrets productifs et limites claires de durée d’exécution. Sinon, les scans génèrent des findings ambigus (par exemple à cause de paquets de débogage temporaires ou de points de montage changeants).

Prérequis : Ce que vous devez clarifier avant d’automatiser

Les scans automatisés échouent rarement à cause de l’outil, mais plutôt en raison de conditions-cadre non clarifiées. Clarifiez au préalable :

1) Systèmes cibles et référence de benchmark

• Distributions et versions (RHEL/Alma/Rocky, Debian/Ubuntu, SLES).
• Classes de rôle (Web, DB, Jump Host, Bastion, nœud Kubernetes).
• Benchmarks pertinents (CIS, DISA STIG, politiques internes). «Benchmark» signifie ici : état souhaité défini, et non une «Best Practice» approximative.

2) Modèle de confiance et droits

OpenSCAP et Lynis nécessitent pour de nombreux contrôles des droits élevés (root), car ils lisent des fichiers système, des paramètres du noyau ou des configurations de services. Dans une CI, c’est délicat : vous ne voulez pas exécuter du code arbitraire en tant que root. Mesures typiques :

• Effectuer les scans dans des runners isolés (VM dédiée, containers/VM éphémères, pas de runners partagés).
• Seules des sources de pipeline signées/de confiance peuvent déclencher les jobs de scan (protection de branche, Code-Owner, gates de merge).
• Aucun secret productif dans le job de scan. Les scans nécessitent rarement des secrets applicatifs – si c’est le cas, c’est un signal d’alerte.

3) Format des résultats et conservation

Définissez dès le départ quels artefacts vous stockez : rapport HTML (lisible), XML/JSON (lisible par machine), ainsi qu’un bref résumé pour le Gate. Planifiez la rétention (durée de conservation) et l’accès (audit, sécurité, exploitation).

Scans de sécurité dans la CI : mise en œuvre avec OpenSCAP et Lynis comme job réexécutable

Ce qui suit présente une approche opérationnelle, facile à reproduire dans GitLab CI ou des systèmes similaires. L’objectif n’est pas un YAML « parfait » pour chaque plateforme, mais un modèle : installer les outils, lancer le scan, archiver les artefacts, évaluer les seuils.

Étape 1 : installer les outils (tenir compte de la distribution)

Les paquets OpenSCAP portent des noms différents selon la distribution. Sur les systèmes de type RHEL, il s’agit généralement de openscap-scanner et scap-security-guide (SSG, un paquet de contenu courant). Sur Debian/Ubuntu, on trouve openscap-scanner et éventuellement des paquets de contenu séparés. Lynis est souvent disponible en tant que paquet ou est fourni en téléchargement vérifié. Pour la CI, privilégiez les dépôts officiels ; à défaut, figez la version et la somme de contrôle.

#!/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

Pourquoi c’est important : de nombreux cas de « pipeline cassée » proviennent d’un mismatch de contenu (profils inexistants) ou de dépendances manquantes (p. ex. des modules Python pour certains checks). Gardez les versions des outils et du contenu sous contrôle, sinon les résultats changeront sans modification volontaire de votre ligne de base.

Étape 2 : scan OpenSCAP avec profil et artefacts de rapport

OpenSCAP utilise généralement la CLI oscap. Les éléments clés sont : le fichier de contenu (p. ex. SSG), l’ID de profil (p. ex. CIS Level 1) et la sortie. Pour la CI, il est pertinent de générer à la fois le Result XML (lisible par machine) et le HTML-Report (lisible par des humains).

#!/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"

Quand cela échoue :

• Mauvais contenu : le fichier SSG ne correspond pas à la distribution/version. Un contenu AlmaLinux sur Ubuntu n’a pas de sens.
• Profil introuvable : L’ID de profil est incorrecte. Vérifiez préalablement les profils disponibles.
• « Not applicable » Flut : De nombreuses règles ne sont pas applicables car des rôles/packages manquent. Dans ce cas, le profil est trop générique ou vous scannez le mauvais artefact.

Étape de vérification du contenu (afficher les profils) :

#!/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'

Étape 3 : Exécuter l’audit Lynis et le rendre quantifiable

Lynis génère des rapports dans /var/log/lynis-report.dat et /var/log/lynis.log. Pour le CI, copiez les fichiers dans un répertoire d’artefacts. De plus, vous avez besoin d’une petite analyse qui extrait une métrique du rapport (p. ex. Hardening-Index) ou compte les alertes à haut risque.

#!/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"

Pourquoi || true est utilisé ici : Lynis n’utilise pas toujours les codes de sortie comme les CI-Gates l’attendent. Il est préférable de laisser Lynis s’exécuter, de sauvegarder les artefacts et d’implémenter la logique du gate vous-même selon des critères clairs (p. ex. indice minimal ou nombre de catégories d’avertissements). Cela évite les « false negatives » où le job s’arrête avant que les rapports ne soient sauvegardés.

Étape 4 : Logique de gate avec seuils (et pourquoi commencer petit)

Un contrôle de sécurité n’est utile que s’il est stable. Commencez avec des règles conservatrices :

• Le gate n’échoue que pour les findings critiques (p. ex. certaines règles OpenSCAP que vous définissez comme « must pass »).
• Tout le reste est reporté comme avertissement et transféré en tickets/backlog.
• Les seuils sont resserrés progressivement une fois la ligne de base établie.

Exemple : gate simple basé sur le Hardening-Index Lynis (pour démarrer, pas comme seule source de vérité) :

#!/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)"

Piège : un index unique peut masquer des améliorations dans un domaine alors qu’un autre se détériore. Utilisez l’indice comme une alerte précoce, mais définissez à moyen terme des critères impératifs concrets (p. ex. « connexion root par SSH désactivée », « Auditd actif », « droits critiques des fichiers corrigés »).

Exemple : structure de jobs GitLab-CI avec artefacts

L’exemple suivant présente une structure générale que vous adapterez à votre environnement. Il s’agit des principes : runner isolé, artefacts, étapes claires, et un gate qui ne perd pas les rapports.

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/

Important pour l’exploitation: le Runner doit permettre des actions en root (ou vous effectuez le scan dans une VM que le job ddemarre). Sur des Shared-Runners, cela n’est souvent pas autoris recommandé.

Flux Cloud et workflows d’image: ce qui change par rapport au Bare Metal

Dans les environnements cloud (IaaS, VM-Templates, Golden Images), deux effets sont pertinents:

Htes phemres et drive de la baseline

Lorsque les instances sont reconstruites régulièrement, le CI est l’endroit appropripour s’assurer que les nouvelles images ne rgressent pas. La drive survient plutôt (hotfixes sur des htes en production). Dans ce cas, les équipes combinent des scans CI (avant la release) avec des jobs de conformité périodiques (p. ex. mensuels) sur des htes représentatifs.

Cloud-init, agents et valeurs par défaut spécifiques au fournisseur

Cloud-init peut modifier les paramètres SSH, les utilisateurs, les clés d’hôte ou les sources de paquets. Les images du fournisseur apportent souvent aussi leurs propres agents (p. ex. pour le monitoring, les Guest Tools). Cela entraîne des findings qui ne sont pas nécessairement «insécurisés», mais divergents. Règle pratique: scannez l’artefact après vos étapes de provisioning et avec les agents qui seront réellement présents ensuite. Sinon vous obtiendrez une baseline qui ne sera jamais atteinte en production.

Dépannage: problèmes courants et comment les résoudre de manière systématique

Problème 1: OpenSCAP ne trouve pas les profils ou génère des rapports vides

• Cause: fichier DataStream incorrect (SSG) ou ID de profil erronée.
• Vérification: oscap info sur le fichier DS, comparer les profils, vérifier les chemins par distribution.
• Solution: ne pas coder en dur le chemin du contenu dans la pipeline, mais le définir par matrice OS (p. ex. variable par job).

Problème 2: de nombreux «fail» dus à l’environnement CI plutôt qu’à la baseline cible

• Cause: vous scannez un environnement de build qui ne correspond pas au rôle serveur ultérieur (mounts manquants, paramètres du kernel différents, paquets temporaires).
• Vérification: vérifier la liste des rôles et des paquets, exécuter le scan dans une VM plus proche de la production.
• Solution: placer l’étape de scan à la fin de la construction de l’image et limiter au maximum la variation de l’environnement.

Problème 3: Lynis signale des «skipped tests» ou des indications contradictoires

• Cause: outils manquants (p. ex. netstat/ss), droits restreints, environnement conteneur sans systemd, système de fichiers en lecture seule.
• Vérification : lire le log Lynis, réinstaller ciblé­ment les dépendances manquantes.
• Solution : ne pas exécuter les scans dans des containers trop restreints, mais dans une VM/contexte privilégié ou dans l’image elle‑même.

Problème 4 : Gate est instable en raison de résultats variables

• Cause : versions de paquets non épinglées, contenu variable, environnement non déterministe.
• Vérification : consigner les versions des outils et du contenu, verrouiller les entrées de build (repos, miroirs, états de version).
• Solution : « Policy as Code » : versionner la baseline et les exceptions, planifier les mises à jour de manière consciente (p. ex. pipeline de rafraîchissement du contenu mensuelle).

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

• Périmètre : Quelles versions d’OS et quels rôles sont couverts ? Quels benchmarks sont pertinents ?
• Isolation : runners/VM dédiés, pas de shared runners avec accès root.
• Déterminisme : contrôler les versions des outils et du contenu, maintenir la stabilité de l’environnement de scan.
• Artefacts : HTML pour lecture humaine, XML/ARF pour machine, rétention définie.
• Baseline : mesurer d’abord, puis fixer des seuils. Documenter les exceptions.
• Conception du Gate : commencer avec quelques critères obligatoires ; durcir ensuite.
• Opérationnalisation : convertir les constats en tickets/backlog, responsabilités claires.

Stratégie de repli : que faire si le Gate bloque soudainement tout ?

Un security gate devient dangereux lorsqu’il arrête des déploiements de manière non contrôlée, sans processus praticable. Prévoir donc une stratégie de repli qui équilibre sécurité et capacité de livraison :

1) « Soft Fail » en transition

En phases initiales : le job peut échouer sans bloquer l’ensemble du release (p. ex. seulement un avertissement). Dès que les baselines sont stables, passer au « Hard Fail » pour des critères clairement définis.

2) Break-Glass avec documentation

Lorsqu’un correctif urgent doit être déployé, il faut une exception contrôlée : p. ex. approbation de merge par Security/Operations et génération automatique d’un log d’exception (ID du ticket, date d’expiration). Ce qui importe, ce n’est pas le tooling, mais que les exceptions soient visibles et limitées dans le temps.

3) Versionnement de la baseline et rollback

Versionnez les profils, le tailoring (règles adaptées) et les seuils. Si une mise à jour de contenu génère soudainement de nouveaux échecs, vous pouvez revenir à la dernière baseline fonctionnelle. C’est la différence entre « la CI nous bloque » et « nous maîtrisons les changements ».

Conclusion : OpenSCAP et Lynis en CI apportent de la sérénité à la conformité et au hardening

Les scans de sécurité automatisés dans la CI ne sont pas une fin en soi. Bien mis en œuvre, ils offrent précisément ce dont les équipes d’administration ont besoin au quotidien : contrôles reproductibles, rapports traçables et alertes précoces avant que des mauvaises configurations ne se glissent dans de nouvelles images et rollouts. OpenSCAP apporte la perspective structurée des benchmarks, Lynis la vue pragmatique d’audit et de hardening. La clé réside dans des baselines stables, l’isolation propre des runners, des artefacts clairs et un gate qui se durcit progressivement. En procédant ainsi, on réduit le drift, on diminue le stress d’audit et on peut opérationnaliser les exigences de sécurité sans bloquer la delivery.

Pour ce sujet, Linux Hardening et les scans de conformité sont également importants. L’article remet ces aspects en perspective de manière compréhensible et montre ce qui importe au quotidien.