OpenSCAP e CIS Benchmark 2026: Guida Pratica al Compliance Auditing su Linux con Remediation Ansible
Come scansionare, misurare e correggere la conformità CIS Benchmark su Linux nel 2026 con OpenSCAP 1.4 e SCAP Security Guide 0.1.80: esempi eseguibili su RHEL 9/10 e Ubuntu 24.04, generazione automatica di playbook Ansible e monitoraggio continuo con systemd timer.
OpenSCAP è l'implementazione open-source dello standard NIST SCAP che consente di scansionare, misurare e correggere automaticamente la configurazione di un sistema Linux rispetto al CIS Benchmark. Nel 2026, con SCAP Security Guide 0.1.80 e i profili CIS RHEL 10 v1.0.1, RHEL 9 v2.0.0 e RHEL 8 v4.0.0, il flusso di lavoro completo (scansione, generazione di script Ansible o Bash, e monitoraggio continuo) richiede meno di trenta minuti per un server. Questa guida mostra come implementare un ciclo di compliance auditing riproducibile su Ubuntu 24.04 LTS e RHEL 9/10, con esempi eseguibili e le trappole che possono, onestamente, bloccarvi in produzione se non state attenti.
OpenSCAP 1.4.x combinato con SCAP Security Guide 0.1.80 fornisce profili CIS Level 1 e Level 2 aggiornati per RHEL 8/9/10, Ubuntu 22.04/24.04 e Debian 12.
Un'installazione minimale di Ubuntu Server tipicamente parte da 40–60% di compliance CIS Level 1; con remediation Ansible mirata si raggiunge stabilmente l'85%+ senza rompere i servizi.
Il comando oscap xccdf generate fix produce sia playbook Ansible sia script Bash direttamente dal file dei risultati XCCDF, riducendo l'errore umano nella correzione.
Regole come disable_ctrlaltdel_reboot o configure_crypto_policy possono bloccare l'accesso remoto: eseguirle sempre in staging con una sessione root aperta.
La compliance è un processo continuo, non un evento singolo: automatizzare con cron o systemd timer e inviare i risultati a Wazuh o a un SIEM per rilevare la deriva di configurazione.
Cos'è OpenSCAP e come funziona SCAP
OpenSCAP è il framework open-source, mantenuto da Red Hat e dalla comunità ComplianceAsCode/content, che implementa il Security Content Automation Protocol (SCAP) definito dal NIST. In pratica, permette di descrivere in XML un baseline di sicurezza (per esempio il CIS Benchmark) e poi di eseguire, in modo ripetibile e verificabile, tre operazioni distinte: valutare lo stato attuale di un sistema, produrre un report leggibile, e generare uno script di remediation. Nel 2026 il pacchetto scap-security-guide alla versione 0.1.80 include i profili CIS aggiornati per RHEL 10 (policy 1.0.1), RHEL 9 (2.0.0) e RHEL 8 (4.0.0), oltre a profili STIG DISA, PCI-DSS 4.0 e HIPAA.
Il cuore del formato è duplice. XCCDF (Extensible Configuration Checklist Description Format) descrive cosa deve essere vero: la regola, il rationale, e il codice di remediation associato. OVAL (Open Vulnerability Assessment Language) descrive invece come verificare se la regola è soddisfatta, in modo indipendente dalla shell o dalla distribuzione. Il risultato è un flusso deterministico: lo stesso data-stream SCAP applicato allo stesso host produce lo stesso verdetto, il che rende OpenSCAP adatto alle verifiche in preparazione a un audit PCI-DSS o ISO 27001. Ogni regola è ancorata a un identificatore CCE (Common Configuration Enumeration) del NIST, che permette il mapping incrociato tra CIS, STIG e le proprie policy interne.
Come installare OpenSCAP su Ubuntu e RHEL nel 2026
Su RHEL, Rocky Linux o AlmaLinux 9/10 tutti i pacchetti sono ufficialmente supportati e mantenuti nella base repository. Il comando è breve:
Su Ubuntu 24.04 LTS e Debian 12 la situazione è leggermente diversa. openscap-scanner è in main, ma il pacchetto ssg-debderived (che contiene i profili CIS per Ubuntu) è fornito da scap-security-guide. Per un baseline aggiornato consigliamo di compilare i data-stream direttamente dall'upstream:
# Ubuntu 22.04 / 24.04
sudo apt update
sudo apt install -y libopenscap8 openscap-utils openscap-common ssg-debian ssg-debderived
# Verifica che i data-stream siano presenti
ls /usr/share/xml/scap/ssg/content/ | grep ubuntu
# ssg-ubuntu2404-ds.xml
Per ambienti containerizzati esiste anche l'immagine ufficiale quay.io/complianceascode/openscap, utile in pipeline GitLab o GitHub Actions dove non si vuole installare OpenSCAP sull'host runner. In quel caso è possibile montare il filesystem del target come volume read-only e scansionarlo dall'esterno, un pattern comune quando si valutano immagini base prima della pubblicazione. È un approccio complementare a quello descritto nella nostra guida alla sicurezza dei container Linux.
Come eseguire una scansione CIS Benchmark con oscap
Il primo passo pratico è elencare i profili disponibili all'interno del data-stream. Su RHEL 9 il comando è:
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
Nell'output vengono elencati i profili XCCDF. I quattro più comuni per la compliance CIS sono:
xccdf_org.ssgproject.content_profile_cis_server_l1, CIS Level 1 Server
xccdf_org.ssgproject.content_profile_cis, CIS Level 2 Server
La scansione vera e propria è una singola invocazione. Il consiglio (imparato a mie spese la prima volta che ho dovuto rifare tutto perché avevo dimenticato il file XML) è di generare sempre sia il file XML dei risultati, per la remediation successiva, sia il report HTML, per la revisione umana:
Il flag --oval-results è particolarmente utile in fase di debugging: produce anche i risultati OVAL grezzi, così è possibile capire perché una specifica regola sia stata valutata come fail. Su un'installazione minimale di Ubuntu 24.04 aspettatevi una compliance iniziale tra il 40% e il 60% per CIS Level 1; su RHEL 9 con installazione "server minimal" il baseline è spesso già intorno al 65%. L'exit code di oscap è 2 quando ci sono regole fail, il che è utile per integrare la scansione in una pipeline CI/CD e bloccare un deploy se il punteggio scende sotto una soglia predefinita.
Come interpretare i risultati: XCCDF, OVAL e CCE
Il report HTML è la vista più comoda per un primo passaggio. Ogni regola è raggruppata per severità (High, Medium, Low) e categoria (SSH, filesystem, autenticazione, servizi di rete, audit e logging). Per ogni fail il report include tre elementi decisivi: la rationale (perché la regola esiste), la remediation description (cosa fare in linguaggio naturale) e i reference identifiers, cioè CCE, CIS reference numbers e, dove applicabile, l'ID di riga del PCI-DSS o della sezione STIG. Questa mappatura è il motivo per cui un solo pass di OpenSCAP soddisfa più framework contemporaneamente.
Un pattern spesso trascurato è la lettura del file XCCDF results in modo programmatico. Con xmllint e XPath si possono estrarre solo le regole fallite di severità high, per esempio per generare un ticket JIRA automatico:
xmllint --xpath \
"//*[local-name()='rule-result' and @severity='high' and \
*[local-name()='result']/text()='fail']/@idref" \
/var/log/compliance/cis-l1-results.xml
Remediation automatica con Ansible e Bash
OpenSCAP non è solo uno scanner: è anche un generatore di remediation. Dal file dei risultati XCCDF si producono due output distinti, entrambi ready-to-execute. Il primo è uno script Bash monolitico:
Il secondo, e preferibile in ambienti gestiti a scala, è un playbook Ansible. Ogni task del playbook è annotato con l'ID della regola CIS e il CCE corrispondente, il che semplifica il tracciamento in git:
L'approccio più maturo è tenere il playbook di remediation sotto controllo di versione, includere tag Ansible per ogni categoria di regole (--tags "SSH,PAM,auditd") e utilizzare --skip-tags per escludere le regole non applicabili al proprio ambiente. Ogni eccezione va documentata con un compensating control ai fini dell'audit: un file EXCEPTIONS.md in repo con la motivazione e la data di revisione è sufficiente per la maggior parte dei framework. Se avete già seguito la nostra guida all'hardening SSH con FIDO2 e crittografia post-quantum, molte regole della categoria SSH risulteranno già passate al primo scan (in un mio deploy recente il salto è stato da 62% a 78% senza toccare nient'altro).
Qual è la differenza tra CIS Level 1 e Level 2?
CIS Level 1 raccoglie le raccomandazioni di base applicabili a praticamente qualsiasi workload produttivo con impatto operativo minimo: password policy, disabilitazione di servizi non necessari, permessi corretti su file sensibili, configurazione base di SSH e sysctl. Sono le regole per cui il rapporto costo/beneficio è schiacciante e che nel 99% dei casi non rompono nulla. Un server di produzione senza almeno Level 1 dovrebbe essere considerato non conforme.
CIS Level 2 aggiunge controlli per ambienti ad alta sicurezza: mandatory access control (SELinux/AppArmor forzato in enforcing), audit logging completo con auditd, restrizioni sui cipher suite di SSH (esclusione di CBC, HMAC-SHA1), disabilitazione di IPv6 se non usato, e vincoli sui parametri kernel che possono interferire con debugger o strumenti di profilazione. È il baseline tipico per sistemi che processano dati regolamentati (PCI-DSS, HIPAA, dati classificati). Il costo operativo è reale: alcune regole richiedono profili AppArmor personalizzati o rendono più complessa la gestione remota, e vanno testate in staging.
La regola pratica del 2026 è semplice: applicare Level 1 su tutti i server, Level 2 solo dopo aver validato che il ruolo del server lo giustifichi. Il salto tipico di hardening index, misurato con Lynis (uno strumento complementare a OpenSCAP), è da 60 a 75–80 con Level 1 applicato, e fino a 85+ con Level 2 mirato.
Come automatizzare la compliance continua
Una scansione una tantum ha valore quasi nullo. Le configurazioni cambiano (patch, package upgrade, modifiche di un collega in ssh_config alle 3 di notte) e nel giro di settimane un sistema a 85% torna a 60%. L'automazione è quindi la parte non negoziabile di un programma di compliance. Il pattern minimo è un systemd timer settimanale che esegue oscap, salva risultato datato, e notifica se lo score scende:
Lo script openscap-cis-scan.sh esegue la scansione, archivia i risultati in /var/log/compliance/ con timestamp, e invia il file XCCDF al SIEM. Se avete già in produzione un agent per il monitoraggio dell'integrità dei file (per esempio dalla nostra guida completa a Wazuh su Linux), potete inoltrare direttamente i risultati XML come custom log, e usare regole Wazuh personalizzate per generare alert quando lo score scende sotto una soglia. Questo trasforma la compliance da attività periodica a segnale operativo in tempo reale, integrandola con il perimetro di rete che avete già hardenato seguendo la nostra guida a nftables 2026.
Errori comuni e trappole da evitare
Il primo errore è eseguire il playbook di remediation completo su un server di produzione senza revisione. Alcune regole hanno effetti collaterali gravi: disable_ctrlaltdel_reboot disabilita il reboot da tastiera anche in emergenza, configure_crypto_policy può ridurre i cipher SSH accettati al punto da tagliare fuori un client legacy, e rpm_verify_permissions può cambiare i permessi di file mantenuti da software non gestito da rpm. Sempre eseguire in staging, tenere una sessione root aperta durante il primo apply su un server, e disporre di un rollback plan. (In un progetto passato ho tagliato fuori metà del team perché il playbook ha rifiutato le chiavi RSA "legacy" dei laptop più vecchi. Non lo rifarò.)
Il secondo errore è confondere OpenSCAP con uno scanner di vulnerabilità. OpenSCAP misura la configurazione, non la presenza di CVE in software installato. Un sistema può essere al 100% CIS e avere un OpenSSL vulnerabile: sono controlli complementari. Per la parte CVE servono strumenti come Grype, Trivy o gli scanner della vostra vendor. Il terzo errore ricorrente è eseguire la scansione con un utente non privilegiato: circa il 20% delle regole richiede lettura di file come /etc/shadow o kernel parameter, e restituirà notchecked senza sudo. Il report può sembrare passato, ma è incompleto. Riferimento autoritativo sul flusso completo: CIS compliance on RHEL using OpenSCAP pubblicato da Red Hat, e la documentazione ufficiale del progetto OpenSCAP.
Domande frequenti
OpenSCAP funziona anche su Debian e Ubuntu, o solo su Red Hat?
OpenSCAP funziona su qualsiasi distribuzione Linux, macOS e persino Windows. I profili SCAP Security Guide per Ubuntu 22.04 e 24.04 sono mantenuti attivamente nel progetto ComplianceAsCode e includono i profili CIS Level 1 e Level 2, oltre a STIG. La copertura è più ampia su RHEL/Rocky/AlmaLinux perché è la piattaforma principale di sviluppo, ma il gap si è chiuso significativamente nel 2026.
Qual è la differenza tra OpenSCAP e Lynis?
Lynis è uno scanner opportunistico più agile che restituisce un hardening index con raccomandazioni testuali, ideale per un primo assessment. OpenSCAP è basato sullo standard NIST SCAP, produce output XML formalmente verificabile e genera automaticamente script di remediation. Nella pratica sono complementari: Lynis per assessment rapidi, OpenSCAP quando serve compliance certificabile.
Posso applicare CIS Benchmark in modalità dry-run prima di modificare il sistema?
Sì. Il playbook Ansible generato da oscap xccdf generate fix può essere eseguito con ansible-playbook --check --diff per vedere ogni modifica senza applicarla. Per lo script Bash è più difficile un dry-run puro; il pattern consigliato è testare in una VM identica alla produzione prima di applicare in ambiente reale.
Quanto tempo richiede una scansione OpenSCAP tipica?
Su un server medio con SSD e CIS Level 1 profile la scansione completa richiede tra 45 secondi e 2 minuti. Level 2 aggiunge circa il 30% per via delle verifiche audit e crypto policy. Il collo di bottiglia è tipicamente I/O nel controllare permessi filesystem, non CPU.
OpenSCAP verifica anche la presenza di CVE nei pacchetti installati?
OpenSCAP può eseguire scansioni CVE tramite gli OVAL feed forniti dai vendor (Red Hat, Debian, Ubuntu) usando oscap oval eval, ma il caso d'uso primario resta la compliance di configurazione. Per un vulnerability management completo si combina OpenSCAP con Trivy, Grype o scanner enterprise.
Come blindare SSH nel 2026: dalla crittografia post-quantum di OpenSSH 10 alle chiavi hardware FIDO2, passando per certificati SSH, CrowdSec e una configurazione sshd_config a prova di attacco.
