OpenSCAP en 2026 : auditer CIS et STIG sur RHEL, Ubuntu et Debian avec le SCAP Security Guide
OpenSCAP automatise l'audit CIS Benchmarks et DISA STIG sur RHEL 10, Ubuntu 24.04 et Debian 13. Installation, premier scan, tailoring, remédiation Ansible et intégration GitLab CI en un seul guide pratique.
OpenSCAP est le scanner open source qui automatise l'audit de conformité d'un serveur Linux face aux référentiels CIS Benchmarks, DISA STIG, PCI-DSS ou BSI IT-Grundschutz en consommant le contenu du SCAP Security Guide (SSG). Concrètement, une commande oscap xccdf eval lit un data stream XML, évalue plusieurs centaines de règles en quelques minutes, produit un rapport HTML pass/fail, et peut générer un script Bash ou un playbook Ansible pour corriger automatiquement les écarts détectés. Ce guide couvre l'installation sur RHEL 10, Ubuntu 24.04 et Debian 13, le premier audit, la personnalisation par tailoring, la remédiation Ansible et l'intégration CI/CD.
OpenSCAP 1.4 (février 2026) implémente les standards NIST SCAP 1.3 : XCCDF, OVAL, ARF et CPE, garantissant des rapports interopérables entre outils.
Le SCAP Security Guide 0.1.79+ fournit les profils cis_level1_server, cis_level2_server, stig, ospp, pci-dss et le nouveau profil BSI pour la plupart des distributions Linux serveur.
Sur RHEL 8/9/10, le paquet scap-security-guide est aligné sur CIS v4.0.0 et DISA STIG V2R6/V2R7. Sur Ubuntu 22.04 et 24.04, il s'installe via ssg-base et ssg-debderived.
La commande oscap xccdf generate fix --fix-type ansible convertit les règles échouées en playbook YAML directement exécutable, réduisant le durcissement manuel de plusieurs jours à quelques heures.
Un fichier de tailoring XML permet d'adapter un profil officiel (désactiver une règle, changer une valeur) sans modifier le contenu upstream, ce qui préserve la reproductibilité des audits.
Intégré à un pipeline CI/CD, OpenSCAP transforme la conformité en test de régression : chaque image de base est scannée avant publication et le build échoue sous un seuil de score fixé.
OpenSCAP en 2026 : vue d'ensemble et nouveautés
OpenSCAP est le seul scanner de conformité open source certifié NIST SCAP 1.3 Validated, ce qui en fait la brique commune de la plupart des solutions commerciales de compliance-as-code (Red Hat Insights, Foreman, ANSSI PACS, etc.). La version 1.4.0 publiée en février 2026 apporte deux évolutions structurantes : le support natif des image builder blueprints comme cible de remédiation, et un moteur OVAL réécrit qui divise par deux le temps d'évaluation sur les gros profils STIG (près de 400 règles). Honnêtement, sur mon dernier scan STIG d'une flotte de 40 VM RHEL 9, la différence était flagrante : on passait de 11 minutes à un peu moins de 6 par hôte.
Côté contenu, le SCAP Security Guide 0.1.79 (juin 2026) ajoute le profil BSI IT-Grundschutz Basic-Protection pour l'écosystème allemand, aligne les profils CIS de RHEL 8 sur la version 4.0.0 du benchmark, met à jour le STIG à la révision V2R6, et retire la règle sshd_use_strong_kex désormais couverte par les system-wide crypto policies. Sur Ubuntu, Canonical publie en parallèle le projet Ubuntu Security Guide (USG), qui réutilise le même contenu SSG mais ajoute une commande usg fix capable de remédier directement les non-conformités.
En pratique, un ingénieur SecOps s'appuiera sur OpenSCAP pour trois cas d'usage complémentaires : audit périodique d'un parc existant, durcissement initial de nouvelles images de base (via oscap-anaconda-addon ou Image Builder), et test de régression de conformité dans un pipeline CI/CD.
SCAP, XCCDF, OVAL : les standards derrière l'outil
SCAP (Security Content Automation Protocol) n'est pas un outil mais une spécification maintenue par le NIST qui empile six standards ouverts. Comprendre cette architecture aide à débugger les rapports et à écrire ses propres règles.
XCCDF (Extensible Configuration Checklist Description Format) décrit les profils et les règles lisibles par un humain : « Le service telnet doit être désactivé ».
OVAL (Open Vulnerability and Assessment Language) décrit la vérification machine associée : « Le fichier /etc/systemd/system/multi-user.target.wants/telnet.socket ne doit pas exister ».
CPE (Common Platform Enumeration) identifie la plateforme cible (cpe:/o:redhat:enterprise_linux:10).
ARF (Asset Reporting Format) est le format XML unifié utilisé pour la sortie --results.
CVE / CCE mappent les résultats vers des identifiants publics (utile pour l'audit).
Un data stream (-ds.xml) est simplement un conteneur XML qui embarque tous ces composants pour une distribution donnée. C'est le seul fichier que oscap ingère en pratique, inutile de manipuler les composants individuellement.
Quelle différence entre CIS Benchmarks et DISA STIG ?
Les deux référentiels visent le durcissement d'un système Linux mais poursuivent des objectifs et un rythme différents. Le choix impacte à la fois le nombre de règles à passer et l'effort d'accréditation.
Critère
CIS Benchmarks
DISA STIG
Éditeur
Center for Internet Security (ONG)
Defense Information Systems Agency (DoD US)
Public visé
Entreprises, cloud, PME
Systèmes d'information de la Défense américaine
Niveaux
Level 1 (baseline) / Level 2 (sensible)
CAT I / II / III selon la sévérité
Fréquence de mise à jour
Trimestrielle à annuelle (v4.0.0 en 2026)
Trimestrielle (V2R6 juillet 2026)
Format natif
PDF + XCCDF gratuit
XCCDF signé DoD
Nombre de règles (RHEL 10)
~180 (L1) / ~250 (L2)
~380
Coût
Gratuit pour usage interne
Gratuit, domaine public
Profil OpenSCAP
cis_level1_server
stig
En pratique, un service SaaS commercial démarrera avec CIS Level 1 (peu intrusif, ratio bénéfice/effort optimal) puis étudiera Level 2 pour les workloads sensibles. Un prestataire du secteur défense ou aéronautique visera directement le STIG, plus strict, notamment sur la journalisation auditd et les politiques PAM. La bonne nouvelle : les deux profils s'exécutent avec le même binaire oscap et la même syntaxe.
Comment installer OpenSCAP sur Ubuntu 24.04, RHEL 10 et Debian 13 ?
L'installation se résume à deux composants : le scanner (openscap-scanner ou libopenscap8) et le contenu (scap-security-guide, ssg-*). Le contenu se met à jour indépendamment du scanner ; il faut donc en surveiller la version.
Sur RHEL 10, AlmaLinux 10 et Rocky Linux 10
# Installation du scanner et du contenu SSG
sudo dnf install -y openscap-scanner scap-security-guide
# Vérification des versions
oscap --version | head -1
rpm -q scap-security-guide
# Emplacement du contenu
ls /usr/share/xml/scap/ssg/content/ | grep rhel10
Sur Ubuntu 24.04 LTS et Ubuntu 22.04
# Sur Ubuntu 24.04, le scanner est dans openscap-scanner
sudo apt update
sudo apt install -y openscap-scanner openscap-utils \
ssg-base ssg-debderived ssg-debian
# Vérification
oscap --version
ls /usr/share/xml/scap/ssg/content/ | grep -E 'ubuntu|debian'
# Optionnel : Ubuntu Security Guide (Ubuntu Pro requis)
# sudo pro enable usg
# sudo apt install -y usg
Sur Debian 13 (Trixie)
sudo apt update
sudo apt install -y libopenscap8 ssg-base ssg-debian ssg-debderived
# Debian n'expédie pas le paquet openscap-scanner ; libopenscap8
# fournit le binaire oscap. Sur Debian 12, il faut le compiler ou
# utiliser le backport.
which oscap
oscap --version
Exécuter un premier audit CIS Level 1 avec oscap
Une fois le contenu installé, un audit se déroule en trois temps : lister les profils disponibles, exécuter l'évaluation, ouvrir le rapport HTML. La commande oscap info est votre meilleur ami. Elle affiche la liste des profils et leur identifiant complet, indispensable pour la ligne de commande.
# 1. Lister les profils disponibles pour Ubuntu 24.04
sudo oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml
# Extrait de la sortie :
# Profiles:
# Title: CIS Ubuntu 24.04 LTS Benchmark for Level 1 - Server
# Id: xccdf_org.ssgproject.content_profile_cis_level1_server
# Title: CIS Ubuntu 24.04 LTS Benchmark for Level 2 - Server
# Id: xccdf_org.ssgproject.content_profile_cis_level2_server
# Title: DISA STIG for Ubuntu 24.04
# Id: xccdf_org.ssgproject.content_profile_stig
# 2. Créer un répertoire pour les résultats
sudo mkdir -p /var/log/openscap
STAMP=$(date +%Y%m%d-%H%M)
# 3. Lancer l'évaluation CIS Level 1 Server
sudo oscap xccdf eval \
--profile xccdf_org.ssgproject.content_profile_cis_level1_server \
--results /var/log/openscap/results-${STAMP}.xml \
--report /var/log/openscap/report-${STAMP}.html \
--oval-results \
/usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml
# Code retour :
# 0 = toutes les règles applicables ont passé
# 1 = erreur d'exécution
# 2 = au moins une règle a échoué
echo "Score OpenSCAP : exit code $?"
Sur une installation Ubuntu 24.04 Server minimale, il faut compter environ 3 à 5 minutes pour un scan CIS Level 1 (180 règles), 8 à 12 minutes pour un STIG complet. Le rapport HTML est autonome (CSS embarqué), il peut donc être servi directement via nginx ou envoyé par mail. Le fichier results-*.xml au format ARF est destiné à l'archivage long-terme et au diff entre deux exécutions.
Comment interpréter un rapport OpenSCAP ?
Le rapport HTML s'ouvre sur un score global (par exemple 62.5%) qui correspond au ratio des règles passées, pondéré par leur poids XCCDF. Ne vous focalisez pas sur le score brut : deux règles CAT I échouées pèsent plus lourd qu'une trentaine de règles cosmétiques. Le tableau des résultats est filtrable par sévérité (high / medium / low) et par statut (pass / fail / notapplicable / notchecked).
Pour chaque règle échouée, le rapport détaille :
Rationale : pourquoi cette règle existe (menace, référence CIS ou STIG).
Description : ce que la règle attend, en langage humain.
Remediation : un extrait de shell ou Ansible qui corrige la non-conformité.
Le statut notapplicable mérite attention : il signifie que la règle ne s'applique pas à ce système (ex. : règle Kubernetes sur un serveur bare-metal). Ces règles ne doivent pas fausser le score. En revanche, notchecked révèle une règle qui n'a pas de check OVAL automatisé. Elle exige donc une vérification manuelle et doit être suivie hors OpenSCAP.
Personnaliser un profil avec un fichier de tailoring
Aucun profil upstream n'est parfaitement adapté à un contexte donné : votre entreprise utilise peut-être xrdp volontairement, ou impose une politique de mots de passe plus stricte que CIS. Modifier directement les fichiers dans /usr/share/xml/scap/ssg/ est une mauvaise idée (la moindre mise à jour du paquet écrase vos changements). La solution officielle est le fichier de tailoring : un XML séparé qui référence le profil parent et exprime les surcharges (règles désactivées, variables ajustées).
Le moyen le plus simple de générer un tailoring est l'outil graphique SCAP Workbench :
sudo apt install -y scap-workbench # Ubuntu / Debian
sudo dnf install -y scap-workbench # RHEL / Fedora
scap-workbench &
# 1. Ouvrir le data stream ssg-ubuntu2404-ds.xml
# 2. Cliquer "Customize" à côté du profil CIS Level 1
# 3. Décocher les règles inapplicables, ajuster les valeurs
# (ex. var_password_pam_minlen = 14 au lieu de 8)
# 4. Enregistrer sous ssg-ubuntu2404-tailoring.xml
À l'exécution, on passe le tailoring via l'option --tailoring-file :
Notez le suffixe _customized ajouté automatiquement à l'identifiant du profil par SCAP Workbench. Cette convention permet de tracer l'origine du profil dans les rapports d'audit externe. Versionnez ce tailoring dans Git au même titre que votre infrastructure-as-code, c'est la représentation formelle de votre politique interne.
Générer et appliquer une remédiation Ansible
La fonctionnalité la plus puissante d'OpenSCAP est la génération automatique de remédiations aux formats bash, Ansible, Puppet, Kickstart, Ignition ou Kubernetes. Deux stratégies existent : générer la remédiation à partir du profil entier (traite toutes les règles, même celles déjà conformes) ou à partir des résultats d'un scan (ne remédie que les règles échouées).
# Stratégie 1 : playbook complet à partir du profil
sudo oscap xccdf generate fix \
--profile xccdf_org.ssgproject.content_profile_cis_level1_server \
--fix-type ansible \
--output /etc/ansible/playbooks/cis-l1-full.yml \
/usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml
# Stratégie 2 : playbook ciblé sur les échecs du dernier scan
sudo oscap xccdf generate fix \
--fix-type ansible \
--output /etc/ansible/playbooks/cis-l1-fixes.yml \
--result-id "" \
/var/log/openscap/results-20260805-1000.xml
# Exécution du playbook (mode check d'abord !)
ansible-playbook -i inventory.yml \
/etc/ansible/playbooks/cis-l1-fixes.yml --check --diff
# Application effective
ansible-playbook -i inventory.yml \
/etc/ansible/playbooks/cis-l1-fixes.yml
Pour aller plus loin, combinez OpenSCAP avec les directives de durcissement systemd (ProtectSystem, PrivateTmp, etc.) qui ne sont pas encore intégralement couvertes par les profils CIS mais renforcent significativement la posture d'un service applicatif exposé.
Intégrer OpenSCAP dans un pipeline DevSecOps
La conformité ponctuelle a peu de valeur : ce qui compte est de la maintenir dans le temps. Trois patterns permettent d'automatiser OpenSCAP à grande échelle, du poste développeur au serveur de production.
Scan à l'installation avec oscap-anaconda-addon
Sur RHEL, AlmaLinux, Fedora et Rocky Linux, l'installeur Anaconda propose un onglet Security Policy pour appliquer un profil SCAP dès la fin de l'installation. En kickstart, ajoutez :
Pour les conteneurs, exécutez oscap-podman ou oscap-docker qui scannent une image sans la démarrer, en montant son système de fichiers en lecture seule :
Ce job publie le rapport HTML comme artefact GitLab, échoue si le score passe sous 90 %, et alimente le tableau de bord de sécurité via un fichier JUnit converti (utilisez oscap-report ou un simple XSLT). Couplé à un scan de vulnérabilités comme Trivy et à un audit de politique MAC comme SELinux, vous obtenez une chaîne scan / durcissement / preuve alignée sur les exigences du Cyber Resilience Act européen.
Oui. OpenSCAP est un logiciel libre publié sous licence LGPL 2.1, sponsorisé par Red Hat et maintenu par une communauté active. Le contenu du SCAP Security Guide (ComplianceAsCode/content) est également gratuit sous licence BSD-3-Clause, y compris les profils CIS Benchmarks et DISA STIG pour la plupart des distributions. Seul Ubuntu Security Guide (USG), qui étend le contenu SSG côté Canonical, nécessite un abonnement Ubuntu Pro pour la fonctionnalité usg fix.
Quelle est la différence entre OpenSCAP et Lynis ?
Lynis est un script shell qui applique un ensemble de vérifications propriétaires : facile à lancer, mais non standardisé. OpenSCAP consomme du contenu SCAP interopérable (XCCDF/OVAL) publié par le NIST, CIS et DISA, et produit des rapports acceptés par les auditeurs (ISO 27001, HDS, PCI-DSS). Pour un usage individuel rapide, Lynis suffit ; pour un audit formel ou une chaîne DevSecOps, OpenSCAP est la référence.
Comment mettre à jour le contenu SCAP Security Guide ?
Sur RHEL et dérivés : sudo dnf upgrade scap-security-guide. Sur Ubuntu et Debian : sudo apt install --only-upgrade ssg-base ssg-debderived. Pour tester une version bêta ou une révision spécifique du benchmark, clonez ComplianceAsCode/content depuis GitHub, compilez le contenu avec ./build_product ubuntu2404, puis pointez oscap vers le fichier build/ssg-ubuntu2404-ds.xml généré.
Peut-on utiliser OpenSCAP pour scanner un conteneur ou une image Docker ?
Oui, via les wrappers oscap-docker (Docker) et oscap-podman (Podman). Ils montent le système de fichiers de l'image en lecture seule et exécutent oscap dessus sans démarrer le conteneur. Le profil anssi_bp028_high ou le CIS Docker Benchmark conviennent pour un audit d'image de base avant publication dans un registre privé.
OpenSCAP remplace-t-il un scanner de vulnérabilités comme Trivy ou OpenVAS ?
Non, les deux sont complémentaires. OpenSCAP audite la configuration (SSH, PAM, sysctl, permissions, services) selon un référentiel de durcissement. Un scanner de vulnérabilités comme Trivy ou OpenVAS compare les versions logicielles installées à une base CVE pour détecter des paquets à patcher. Une posture de sécurité solide combine les deux : OpenSCAP pour la conformité configuration, Trivy pour la veille CVE.
