Automatizar escaneos de seguridad en CI para servidores Linux con OpenSCAP y Lynis

Quien opera hoy servidores Linux conoce el problema fundamental: los requisitos de seguridad y cumplimiento rara vez son proyectos puntuales, sino pruebas recurrentes. Aun así, las comprobaciones a menudo se realizan “por intuición” o solo antes de las auditorías. Aquí es donde entra la automatización de los escaneos de seguridad en CI: hacen que el endurecimiento y el cumplimiento sean medibles, repetibles y, sobre todo, visibles pronto —antes de que se despliegue una imagen o se aplique un cambio de configuración en producción.

En este artículo tratamos de forma práctica cómo integrar OpenSCAP y Lynis en una canalización CI. OpenSCAP representa el “Security Content Automation Protocol” y, con contenidos estandarizados (p. ej. XCCDF/OVAL), comprueba de forma sistemática las configuraciones frente a benchmarks como CIS o STIG. Lynis es una herramienta de auditoría probada para Linux que compila indicios de endurecimiento, indicadores de vulnerabilidad y riesgos operativos desde la perspectiva de una auditoría de administrador. Ambas herramientas se complementan: OpenSCAP proporciona resultados de cumplimiento estructurados y Lynis ofrece medidas pragmáticas y conocimiento operativo. El objetivo es un montaje que funcione en el día a día: bases claras, artefactos limpios, umbrales trazables y una estrategia de retroceso cuando una puerta (gate) resulta de repente demasiado estricta.

Por qué los escaneos de seguridad en CI para servidores Linux aportan más que “seguridad una vez al trimestre”

CI (Continuous Integration) se entiende en el contexto de infraestructura a menudo como la canalización en torno a imágenes, IaC (Infrastructure as Code) o la gestión de configuraciones. La ganancia no es “más escaneos”, sino ciclos de retroalimentación más cortos y menos deriva (desviación respecto a la configuración objetivo a lo largo del tiempo).

• Detección temprana: las malas configuraciones (p. ej. políticas SSH, sysctl, versiones de paquetes) quedan visibles durante el build o antes del merge, no solo tras el despliegue.
• Trazabilidad: los informes de escaneo son artefactos de la canalización. Pueden versionarse, compararse y documentarse para auditorías.
• Estandarización: un Security Gate en CI obliga a definir baselines, procesos de excepciones y responsabilidades claras.
• Escalabilidad: una vez establecida, la misma lógica comprueba cientos de hosts/imágenes sin esfuerzo adicional.

Importante: los escaneos en CI no sustituyen el monitoring continuo, la gestión de parches ni el Incident Response. Son un filtro de calidad para los cambios en imágenes y configuraciones —y reducen la probabilidad de que incorpore usted deuda técnica en producción.

OpenSCAP y Lynis: roles, fortalezas y malentendidos típicos

OpenSCAP en dos frases

OpenSCAP es una cadena de herramientas que procesa SCAP-Content. SCAP-Content consiste, entre otros, en XCCDF (listas de verificación y lógica de evaluación) y OVAL (definiciones de comprobación). En la práctica: selecciona un perfil (p. ej. CIS Level 1) y OpenSCAP evalúa el estado objetivo. El resultado es un informe estructurado (XML/HTML) adecuado para cumplimiento y comparación.

Lynis en dos frases

Lynis realiza una auditoría local y entrega hallazgos, indicaciones y propuestas de hardening. Es menos “guiado por benchmarks” y más orientado a la práctica: permisos de archivos, servicios, ajustes del kernel, registro, autenticación, comprobaciones de integridad, aspectos del bootloader. El resultado es un informe en texto más métricas que se pueden interpretar como un gate.

Malentendidos típicos en la operación

• «Con una sola herramienta basta»: en la práctica, OpenSCAP y Lynis cubren ángulos diferentes. Combinados son más robustos frente a puntos ciegos.
• „CI scannt Produktion“: CI debería escanear principalmente artefactos (imágenes, Golden AMIs, bases de contenedores, plantillas de VM). Los escaneos en producción deberían pertenecer a trabajos planificados (p. ej. orquestados de forma central) con ventanas de cambio.
• „Alles muss auf 100%“: Los benchmarks contienen requisitos que no encajan en todo modelo operativo (p. ej. reglas estrictas de contraseñas en entornos con autenticación exclusivamente por clave SSH). Necesitan líneas base y excepciones documentadas.

Arquitectura: ¿Dónde tiene sentido ejecutar los escaneos en una CI/CD-Pipeline?

Para Linux-Server en entornos de nube o de virtualización se ha comprobado efectivo un patrón: no escanear el „servidor en ejecución“, sino la imagen y el cambio de configuración. Esto reduce los efectos secundarios y hace los resultados más reproducibles.

Patrón probado de pipeline (orientado a imágenes)

• Build: construir la imagen/plantilla (Packer, Image Builder, scripts de build propios).
• Provisioning: aplicar endurecimiento (Ansible, Salt, Chef, módulos Cloud-init). Aquí se genera la línea base.
• Scan: ejecutar OpenSCAP y Lynis contra el artefacto construido (p. ej. en una VM, vía chroot, o con un enfoque basado en contenedores según la capacidad de la herramienta).
• Gate: verificar los resultados frente a umbrales (p. ej. „no High-Findings“, „Compliance >= X%“).
• Publish: publicar en el Registry/Template-Repository solo si tiene éxito.

Si aun así escanea un host objetivo „en ejecución“ (p. ej. Staging), hágalo de forma controlada: instancia de Staging dedicada, datos fijos, sin secretos productivos y límites claros de tiempo de ejecución. De lo contrario, los escaneos generan hallazgos poco claros (por ejemplo, por paquetes de depuración temporales o montajes variables).

Requisitos previos: Qué debe aclarar antes de la automatización

Los escaneos automatizados rara vez fallan por la herramienta; más bien por condiciones marco no definidas. Aclare lo siguiente de antemano:

1) Sistemas objetivo y relación con benchmarks

• Distribuciones y versiones (RHEL/Alma/Rocky, Debian/Ubuntu, SLES).
• Clases de rol (Web, DB, Jump Host, Bastion, Kubernetes Node).
• Benchmarks relevantes (CIS, DISA STIG, políticas internas). „Benchmark“ significa aquí: estado objetivo definido, no „mejor práctica por intuición“.

2) Modelo de confianza y permisos

OpenSCAP y Lynis requieren para muchos checks privilegios elevados (root), porque leen archivos del sistema, parámetros del kernel o configuraciones de servicios. En CI esto es delicado: no quiere ejecutar código arbitrario con root. Medidas habituales:

• Escaneos en runners aislados (VM dedicada, containers/VM efímeros, sin Shared Runner).
• Solo fuentes de pipeline firmadas/confiables deben poder disparar jobs de escaneo (Branch-Protection, Code-Owner, Merge-Gates).
• No incluir secretos productivos en el job de escaneo. Los escaneos rara vez necesitan secretos de la aplicación; si los requieren, es una señal de alarma.

3) Formato de resultados y retención

Defina desde el principio qué artefactos va a almacenar: informe HTML (legible), XML/JSON (legible por máquinas), así como un pequeño resumen para el Gate. Planifique la retención (periodo de conservación) y los accesos (auditoría, seguridad, operaciones).

Escaneos de seguridad en CI: implementación con OpenSCAP y Lynis como trabajo repetible

A continuación se presenta un enfoque práctico que se puede reproducir fácilmente en GitLab CI o en sistemas similares. El objetivo no es un YAML „perfecto“ para cada plataforma, sino un patrón: instalar herramientas, ejecutar el escaneo, archivar artefactos, evaluar umbrales.

Paso 1: Instalar herramientas (tener en cuenta la distribución)

Los paquetes de OpenSCAP se llaman de forma diferente según la distribución. En sistemas tipo RHEL suelen ser típicamente openscap-scanner y scap-security-guide (SSG, un paquete de contenido común). En Debian/Ubuntu son openscap-scanner y, si procede, paquetes de contenido separados. Lynis suele estar disponible como paquete o se integra como descarga verificada. Para CI se recomienda: preferiblemente desde repositorios oficiales; en caso contrario, fijar versión y suma de verificación.

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

Por qué es importante: Muchos casos de „pipeline se rompe“ provienen de desajustes de contenido (perfiles que no existen) o de dependencias faltantes (p. ej. módulos Python para comprobaciones concretas). Controle las versiones de las herramientas y del contenido; de lo contrario los resultados cambiarán sin una modificación deliberada de su línea base.

Paso 2: Escaneo OpenSCAP con perfil y artefactos de informe

OpenSCAP suele usar oscap como interfaz de línea de comandos. Lo determinante es: archivo de contenido (p. ej. SSG), ID de perfil (p. ej. CIS Level 1) y salida. Para CI es recomendable generar tanto Result XML (legible por máquinas) como HTML-Report (para personas).

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

Cuándo falla:

• Contenido incorrecto: el archivo SSG no se ajusta a la distribución/version. Un AlmaLinux-Content en Ubuntu no tiene sentido.
• Perfil no existente: la ID de perfil no coincide. Compruebe de antemano los perfiles disponibles.
• Exceso de „Not applicable“: muchas reglas no son aplicables porque faltan roles/paquetes. Entonces el perfil es demasiado genérico o está escaneando el artefacto equivocado.

Paso de comprobación del contenido (mostrar perfiles):

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

Paso 3: Ejecutar la auditoría Lynis y convertirla en una métrica

Lynis genera informes en /var/log/lynis-report.dat y /var/log/lynis.log. Para CI, copie los archivos en un directorio de artefactos. Además necesita un pequeño análisis que extraiga del informe una medida (p. ej., el índice de hardening) o cuente las advertencias de alto riesgo.

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

Por qué aparece aquí || true: Lynis no siempre usa códigos de salida como esperan los gates de CI. Es preferible dejar que Lynis se ejecute, asegurar los artefactos y aplicar la lógica del gate con criterios claros (p. ej., índice mínimo o número de categorías de advertencia). Eso evita falsos negativos que hacen que el job falle antes de que se aseguren los informes.

Paso 4: Lógica del gate con umbrales (y por qué conviene empezar con cautela)

Un Security Gate solo es útil si es estable. Empiece con reglas conservadoras:

• El gate solo falla ante hallazgos críticos (p. ej., determinadas reglas de OpenSCAP que usted define como «must pass»).
• Todo lo demás se reporta como advertencia y se deriva a tickets/backlog.
• Los umbrales se endurecen deliberadamente después de que se establece la línea base.

Ejemplo: gate simple en el índice de hardening de Lynis (como punto de partida, no como único criterio):

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

Trampa: un único índice puede ocultar mejoras en un área mientras otra empeora. Use el índice como «alerta temprana», pero defina a medio plazo criterios obligatorios concretos (p. ej., «inicio de sesión root por SSH deshabilitado», «auditd activo», «permisos críticos de archivos corregidos»).

Ejemplo: estructura de trabajo de GitLab-CI con artefactos

El siguiente ejemplo muestra una estructura aproximada que debe adaptar a su entorno. Se trata de los principios: runner aislado, artefactos, etapas claras y un gate que no pierda los informes.

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 para la operación: el Runner debe construirse de forma que sean posibles acciones como root (o debe escanearse dentro de una VM que el job arranque). En Shared-Runners esto a menudo no está permitido — y desde el punto de vista de la seguridad tampoco es recomendable.

Flujos de trabajo en la nube e imágenes: qué cambia respecto a Bare Metal

En entornos en la nube (IaaS, plantillas de VM, Golden Images) son relevantes dos efectos:

Hosts efímeros y deriva de la línea base

Si las instancias se reconstruyen con regularidad, la CI es el lugar adecuado para asegurarse de que las nuevas imágenes no introduzcan regresiones. La deriva surge más bien por cambios «Day-2» (Hotfixes en hosts en ejecución). Para este caso, los equipos combinan escaneos de CI (antes del release) con trabajos periódicos de cumplimiento (p. ej., mensuales) en hosts representativos.

Cloud-init, agentes y valores predeterminados específicos del proveedor

Cloud-init puede modificar la configuración de SSH, usuarios, claves de host o fuentes de paquetes. Las imágenes del proveedor además suelen traer sus propios agentes (p. ej., para monitorización, Guest Tools). Esto conduce a hallazgos que no son «inseguros», pero sí divergentes. Regla práctica: escanee el artefacto después de sus pasos de aprovisionamiento y con los agentes que realmente estarán presentes luego. Si no, obtendrá una línea base que en la realidad nunca se alcanza.

Resolución de problemas: fallos comunes y cómo solucionarlos de forma sistemática

Problema 1: OpenSCAP no encuentra perfiles o genera informes vacíos

• Causa: archivo DataStream incorrecto (SSG) o ID de perfil errónea.
• Comprobación: Ejecute oscap info sobre el archivo DS, compare perfiles y verifique las rutas por distribución.
• Solución: No codifique en duro la ruta de contenido en la pipeline; establézcala según la matriz de OS (p. ej., una variable por job).

Problema 2: Muchos «fail» debido al entorno CI en lugar de la línea base objetivo

• Causa: está escaneando un entorno de build que no corresponde con la función del servidor posterior (montajes faltantes, parámetros de kernel distintos, paquetes temporales).
• Comprobación: verifique la lista de roles y paquetes; ejecute el escaneo en una VM que se asemeje más a producción.
• Solución: coloque la etapa de escaneo al final del build de la imagen y mantenga las variaciones del entorno al mínimo.

Problema 3: Lynis reporta «skipped tests» o indicaciones contradictorias

• Causa: herramientas ausentes (p. ej., netstat/ss), permisos restringidos, entorno de contenedor sin Systemd, sistema de archivos montado como solo lectura.

Problema 4: el Gate es inestable debido a resultados variables

• Causa: estados de paquetes no fijados, contenido variable, entorno no determinista.
• Comprobación: registrar las versiones de herramientas y de contenido, fijar los inputs del build (repositorios, mirrors, estados de versión).
• Solución: «Policy as Code»: versionar la baseline y las excepciones, planificar las actualizaciones de forma consciente (p. ej., una pipeline mensual de refresco de contenido).

Lista de comprobación: De «primer escaneo» a un CI-Security-Gate fiable

• Alcance: ¿Qué versiones de SO y qué roles se cubren? ¿Qué benchmarks son relevantes?
• Aislamiento: Runners/VM dedicados, no usar shared runners con acceso root.
• Determinismo: controlar las versiones de herramientas/contenido, mantener estable el entorno de escaneo.
• Artefactos: HTML para personas, XML/ARF para máquinas, retención definida.
• Baseline: primero medir, luego fijar umbrales. Documentar las excepciones.
• Diseño del Gate: empezar con pocos criterios obligatorios; endurecerlos más tarde.
• Operacionalización: convertir los hallazgos en tickets/backlog, responsabilidades claras.

Estrategia de retroceso: ¿qué hacer si el Gate bloquea de repente todo?

Un security gate resulta peligroso cuando detiene despliegues de forma incontrolada y no existe un proceso viable. Por eso, planifique una estrategia de retroceso que equilibre seguridad y capacidad de entrega:

1) «Soft Fail» como transición

En fases tempranas: el job puede fallar, pero no debe bloquear todo el release (p. ej., solo advertencia). Una vez que las baselines estén estables, cambie a «Hard Fail» para criterios claramente definidos.

2) Break-Glass con documentación

Si hay que desplegar una corrección urgente, necesita una excepción controlada: p. ej., aprobación de merge por Security/Operations y generación automática de un registro de excepciones (ID de ticket, fecha de expiración). Lo importante no es el tooling, sino que las excepciones sean visibles y tengan limitación temporal.

3) Versionado de la baseline y rollback

Versione los perfiles, el tailoring (reglas adaptadas) y los umbrales. Si una actualización de contenido genera de repente nuevas fallas, puede volver a la última baseline funcional. Esa es la diferencia entre «la CI nos bloquea» y «gestionamos los cambios».

Conclusión: OpenSCAP y Lynis en CI aportan estabilidad a compliance y hardening

Los escaneos de seguridad automatizados en CI no son un fin en sí mismos. Bien implementados, proporcionan exactamente lo que los equipos de administración necesitan en el día a día: comprobaciones reproducibles, informes trazables y advertencias tempranas antes de que las malas configuraciones se introduzcan en nuevas imágenes y despliegues. OpenSCAP ofrece la perspectiva estructurada de benchmark, Lynis la visión pragmática de auditoría y hardening. La clave está en baselines estables, una separación limpia de los runners, artefactos claros y un Gate que se endurece progresivamente. Quien actúa así reduce la deriva, ahorra estrés en auditorías y puede operacionalizar requisitos de seguridad sin bloquear la entrega.

Para este tema, también son importantes Linux hardening y los scans de compliance. El artículo sitúa estos aspectos de forma comprensible y muestra en qué se debe incidir en el día a día.