Automatizzare le scansioni di sicurezza in CI per server Linux con OpenSCAP e Lynis

Chi gestisce oggi server Linux conosce il problema di fondo: i requisiti di sicurezza e compliance raramente sono progetti una tantum, ma prove ricorrenti. Tuttavia i controlli vengono spesso eseguiti „a sentimento“ o solo prima degli audit. Ed è proprio qui che interviene l’automazione dei scan di sicurezza nella CI: rendono l’hardening e la compliance misurabili, ripetibili e, soprattutto, visibili in anticipo — prima che un’immagine venga distribuita o una modifica di configurazione entri in produzione.

In questo contributo si spiega in termini pratici come integrare OpenSCAP e Lynis in una pipeline CI. OpenSCAP sta per „Security Content Automation Protocol“ e verifica, con contenuti standardizzati (p.es. XCCDF/OVAL), le configurazioni in modo sistematico rispetto a benchmark come CIS o STIG. Lynis è un collaudato strumento di audit per Linux che aggrega indicazioni di hardening, indicatori di vulnerabilità e rischi operativi dalla prospettiva di un audit amministrativo. Entrambi gli strumenti si completano: OpenSCAP fornisce risultati di compliance strutturati, Lynis fornisce misure pragmatiche e know‑how operativo. L’obiettivo è un setup funzionante nella pratica: baseline chiare, artefatti puliti, soglie tracciabili e una strategia di fallback se un gate dovesse diventare improvvisamente troppo severo.

Perché gli scan di sicurezza nella CI sui server Linux apportano più valore della „Security einmal im Quartal“

La CI (Continuous Integration) è spesso intesa, nel contesto infrastrutturale, come una pipeline che ruota attorno a immagini, IaC (Infrastructure as Code) o gestione della configurazione. Il vantaggio non è „più scan“, ma cicli di feedback più brevi e meno drift (deviazione dalla configurazione voluta nel tempo).

• Rilevamento precoce: le errate configurazioni (p.es. policy SSH, sysctl, stato/versio­ni dei pacchetti) diventano visibili durante il build o prima del merge, non solo dopo il rollout.
• Tracciabilità: i report di scan sono artefatti della pipeline. Possono essere versionati, confrontati e prodotti a supporto degli audit.
• Standardizzazione: un security gate nella CI impone baseline, processi per le eccezioni e responsabilità chiare.
• Scalabilità: una volta stabilita, la stessa logica verifica centinaia di host/immagini senza sfori aggiuntivi.

Importante: gli scan in CI non sostituiscono un monitoraggio continuo, il patch management né l’incident response. Sono un filtro di qualità per le modifiche a immagini e configurazioni — e riducono la probabilità di introdurre debiti tecnici in produzione.

OpenSCAP e Lynis: ruoli, punti di forza e fraintendimenti tipici

OpenSCAP in due frasi

OpenSCAP è una toolchain che elabora SCAP‑Content. Lo SCAP‑Content comprende, tra l’altro, XCCDF (logica di checklist e valutazione) e OVAL (definizioni di check). In pratica: si sceglie un profilo (p.es. CIS Level 1) e OpenSCAP valuta lo stato obiettivo. Il risultato è un report strutturato (XML/HTML), adatto per compliance e confrontabilità.

Lynis in due frasi

Lynis esegue un audit locale e produce risultati, indicazioni e suggerimenti di hardening. È meno „guidato da benchmark“ e più orientato alla pratica: permessi dei file, servizi, impostazioni del kernel, logging, autenticazione, controlli di integrità, aspetti del bootloader. Il risultato è un report testuale più metriche che si possono interpretare come un gate.

Fraintendimenti tipici in esercizio

• „Uno strumento basta“: nella pratica OpenSCAP e Lynis coprono prospettive differenti. Combinati sono più robusti contro i punti ciechi.
• „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

Definire precocemente quali artefatti conservare: report HTML (leggibile), XML/JSON (leggibile dalle macchine), nonché un breve riepilogo per il gate. Pianificate la retention (periodo di conservazione) e gli accessi (audit, sicurezza, operazioni).

Scans di sicurezza in CI: implementazione con OpenSCAP e Lynis come job ripetibile

Di seguito un approccio pratico, facilmente replicabile in GitLab CI o in sistemi analoghi. L’obiettivo non è un „perfetto“ YAML per ogni piattaforma, ma uno schema: installare gli strumenti, eseguire lo scan, archiviare gli artefatti, valutare le soglie.

Passo 1: Installazione degli strumenti (attenzione alla distribuzione)

I pacchetti OpenSCAP hanno nomi diversi a seconda della distribuzione. Su sistemi di tipo RHEL sono tipicamente openscap-scanner e scap-security-guide (SSG, un diffuso pacchetto di content). Su Debian/Ubuntu sono openscap-scanner e, eventualmente, pacchetti di contenuto separati. Lynis è spesso disponibile come pacchetto o viene integrato come download verificato. Per CI si consiglia: preferibilmente dai repository ufficiali, altrimenti con fissazione di versione e checksum.

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

Perché è importante: molti casi di „pipeline che si interrompe“ derivano da mismatch dei contenuti (i profili non esistono) o da dipendenze mancanti (es. moduli Python per singoli controlli). Tenete sotto controllo le versioni di tool e content, altrimenti i risultati cambiano senza una modifica consapevole della vostra baseline.

Passo 2: OpenSCAP-Scan con profilo e artefatti di report

OpenSCAP usa di solito oscap come CLI. Determinanti sono: il file di content (p.es. SSG), l’ID del profilo (p.es. CIS Level 1) e l’output. Per CI è utile generare sia il Result XML (leggibile dalle macchine) sia il HTML-Report (per gli umani).

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

Quando questo fallisce:

• Content errato: il file SSG non corrisponde alla distribuzione/versione. Un contenuto AlmaLinux-Content su Ubuntu produce risultati insensati.

Passo di verifica per il contenuto (visualizzare i profili):

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

Passo 3: Eseguire l’audit Lynis e renderlo misurabile

Lynis genera rapporti in /var/log/lynis-report.dat e /var/log/lynis.log. Per CI copiate i file in una directory degli artefatti. Inoltre serve una breve analisi che estragga dal report una metrica (per esempio l’hardening index) o conti gli avvisi ad alto rischio.

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

Perché compare || true qui: Lynis non utilizza sempre i codici di uscita come si aspetterebbero i gate CI. È preferibile lasciare Lynis eseguire, preservare gli artefatti e implementare la logica del gate con criteri chiari (p.es. indice minimo o numero di categorie di avviso). Questo evita „false negatives“, cioè che il job si interrompa prima che i report siano salvati.

Passo 4: Logica del gate con soglie (e perché iniziare in piccolo)

Un security gate è utile solo se è stabile. Iniziate con regole conservative:

• Il gate fallisce solo per finding critici (p.es. specifiche regole OpenSCAP che definite come „must pass“).
• Tutto il resto viene riportato come avviso e trasferito in ticket/backlog.
• Le soglie vengono rese più stringenti consapevolmente, dopo aver stabilito la baseline.

Esempio: semplice gate basato sull’hardening index di Lynis (come punto di partenza, non come unica verità):

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

Insidie: un singolo indice può mascherare miglioramenti in un’area mentre un’altra peggiora. Usate l’indice come „allerta precoce“, ma definite a medio termine criteri vincolanti concreti (p.es. „login root via SSH disabilitato“, „auditd attivo“, „permessi critici dei file corretti“).

Esempio: struttura di job GitLab-CI con artefatti

Il seguente esempio mostra una struttura di massima che adattate al vostro ambiente. Si tratta dei principi: runner isolato, artefatti, stage chiari e un gate che non perda i report.

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/

Importante per il funzionamento: il Runner deve essere costruito in modo che siano possibili azioni con privilegi di root (oppure eseguite la scansione all’interno di una VM che il job avvia). Nei runner condivisi questo spesso non è consentito – e dal punto di vista della sicurezza non è consigliabile.

Flussi di lavoro cloud e image: cosa cambia rispetto al Bare Metal

Negli ambienti cloud (IaaS, VM-template, Golden Images) sono rilevanti due effetti:

Host effimeri e deriva della baseline

Se le istanze vengono ricostruite regolarmente, la CI è il luogo corretto per garantire che i nuovi image non vadano in regressione. La deriva si verifica piuttosto a causa di modifiche „Day-2“ (Hotfixes su host in esercizio). In questo caso i team combinano CI-Scans (prima del release) con job di compliance periodici (p. es. mensili) su host rappresentativi.

Cloud-init, agenti e default specifici del provider

Cloud-init può modificare impostazioni SSH, utenti, hostkey o sorgenti dei pacchetti. Gli image dei provider includono inoltre spesso agent propri (p. es. per monitoring, Guest Tools). Questo genera finding che non sono „insicuri“, ma divergenti. Regola pratica: scansionate l’artefatto dopo i vostri passaggi di provisioning e con gli agent che saranno effettivamente presenti in seguito. Altrimenti otterrete una baseline che nella realtà non viene mai raggiunta.

Troubleshooting: problemi ricorrenti e come risolverli in modo sistematico

Problema 1: OpenSCAP non trova i profili o produce report vuoti

• Causa: file DataStream errato (SSG) o ID del profilo errata.
• Verifica: oscap info sul file DS, confrontare i profili, verificare i percorsi per ogni distribuzione.
• Soluzione: non hardcodare il percorso del content nella pipeline, ma impostarlo per matrice OS (p. es. variabile per job).

Problema 2: molti „fail“ a causa dell’ambiente CI invece della baseline target

• Causa: state scansionando un ambiente di build che non corrisponde al ruolo del server finale (mount mancanti, parametri del kernel diversi, pacchetti temporanei).
• Verifica: controllare lista dei ruoli e dei pacchetti, eseguire lo scan in una VM più vicina alla produzione.
• Soluzione: porre la fase di scan alla fine del build dell’image e limitare le variazioni dell’ambiente.

Problema 3: Lynis segnala „skipped tests“ o indicazioni contrastanti

• Causa: strumenti mancanti (p. es. netstat/ss), permessi limitati, ambiente container senza systemd, filesystem in sola lettura.
• Verifica: leggere i log di Lynis, reinstallare miratamente le dipendenze mancanti.
• Soluzione: eseguire le scansioni non in container eccessivamente ristretti, ma in VM/contesto privilegiato o nell’immagine stessa.

Problema 4: il Gate è instabile a causa di risultati variabili

• Causa: versioni dei pacchetti non vincolate, contenuti variabili, ambiente non deterministico.
• Verifica: registrare le versioni di tool e contenuti, bloccare gli input di build (repo, mirror, stati delle versioni).
• Soluzione: „Policy as Code“: versionare baseline e eccezioni, pianificare consapevolmente gli aggiornamenti (p. es. pipeline mensile di refresh dei contenuti).

Lista di controllo: dalla „prima scansione“ a un CI-Security-Gate affidabile

• Ambito: quali versioni OS e quali ruoli sono coperti? Quali benchmark sono rilevanti?
• Isolamento: Runner/VM dedicate, niente shared runner con root.
• Determinismo: controllare versioni di tool e contenuti, mantenere stabile l’ambiente di scansione.
• Artefatti: HTML per persone, XML/ARF per macchine, definire la retention.
• Baseline: misurare prima, poi impostare soglie. Documentare le eccezioni.
• Design del Gate: iniziare con pochi criteri obbligatori; in seguito irrigidire.
• Operationalizzazione: inserire i findings in ticket/backlog, responsabilità chiare.

Strategia di fallback: cosa fare se il Gate improvvisamente blocca tutto?

Un Security Gate è pericoloso se blocca i deployment in modo incontrollato, senza un processo praticabile. Pianificate quindi una strategia di fallback che bilanci sicurezza e capacità di consegna:

1) „Soft Fail“ come transizione

Nelle fasi iniziali: il job può fallire, ma non deve bloccare l’intero rilascio (p. es. solo avviso). Una volta stabilizzate le baseline, passare a „Hard Fail“ per criteri chiaramente definiti.

2) Break-Glass con documentazione

Se è necessario distribuire una correzione urgente, serve un’eccezione controllata: p. es. merge-approval da Security/Operations e generazione automatica di un log delle eccezioni (ID ticket, data di scadenza). Ciò che conta non è il tooling, ma che le eccezioni siano visibili e limitate nel tempo.

3) Versionamento delle baseline e rollback

Versionate profili, tailoring (regole adattate) e soglie. Se un aggiornamento dei contenuti genera improvvisamente nuovi fallimenti, potete tornare all’ultima baseline funzionante. Questa è la differenza tra „la CI ci blocca“ e „gestiamo i cambiamenti“.

Conclusione: OpenSCAP e Lynis in CI portano stabilità su compliance e hardening

Le scansioni di sicurezza automatizzate in CI non sono un fine a se stante. Se implementate correttamente forniscono esattamente ciò di cui i team di amministrazione hanno bisogno nella pratica quotidiana: check riproducibili, report tracciabili e avvisi precoci, prima che le misconfigurazioni si insinuino in nuove immagini e rollout. OpenSCAP fornisce la prospettiva strutturata del benchmark, Lynis quella pragmatica di audit e hardening. La chiave sta in baseline stabili, in una solida isolazione dei runner, in artefatti definiti e in un gate che venga irrigidito progressivamente. Chi adotta questo approccio riduce il drift, diminuisce lo stress degli audit e può operationalizzare i requisiti di sicurezza senza bloccare la delivery.

Per questo tema sono importanti anche Linux hardening e scansioni di compliance. Il contributo inquadra questi aspetti in modo comprensibile e mostra su cosa concentrarsi nella pratica quotidiana.