Escaneo de Vulnerabilidades 14 min de lectura

Escaneo de Vulnerabilidades en Linux: Guía Práctica con Lynis, OpenSCAP y Trivy

Aprende a escanear vulnerabilidades en servidores Linux con Lynis, OpenSCAP y Trivy. Auditoría de configuración, cumplimiento CIS y detección de CVEs con scripts de automatización listos para producción.

Editorial Team

Por qué el escaneo de vulnerabilidades es imprescindible en 2026

Cada servidor Linux en producción es un objetivo. Da igual si gestionas una sola máquina virtual o una flota de cientos de nodos — si no estás escaneando tus sistemas de forma proactiva, básicamente estás operando a ciegas. Y en 2026, operar a ciegas es prácticamente una invitación para los atacantes.

El panorama de amenazas ha cambiado muchísimo. Los ciclos de explotación se han acortado a horas gracias al reconocimiento asistido por IA, y las vulnerabilidades en paquetes del sistema, bibliotecas y configuraciones incorrectas se explotan antes de que muchos administradores siquiera se enteren. Súmale regulaciones como PCI DSS 4.0, HIPAA y el RGPD exigiendo evidencia de auditorías periódicas, y el resultado es claro: el escaneo de vulnerabilidades ya no es opcional.

Es un requisito de cumplimiento normativo.

La buena noticia es que hay herramientas de código abierto maduras y realmente potentes que cubren todo el espectro del escaneo de seguridad. En esta guía vamos a trabajar con tres de ellas: Lynis para auditorías de configuración del host, OpenSCAP para cumplimiento normativo con benchmarks CIS y STIG, y Trivy para escaneo de vulnerabilidades en paquetes del sistema y contenedores. Usadas en conjunto, son un arsenal bastante formidable.

Entendiendo los tipos de escaneo de seguridad

Antes de meternos de lleno en las herramientas, vale la pena entender las diferencias entre los distintos enfoques. No todos los escáneres hacen lo mismo, y conocer sus particularidades te permite construir una estrategia de seguridad completa en vez de dejar huecos sin cubrir.

Auditoría de configuración (host-based)

Herramientas como Lynis analizan la configuración del sistema desde dentro del propio host. Revisan cientos de parámetros: permisos de archivos, configuración del kernel, servicios activos, políticas de contraseñas, cifrado, logging y mucho más. No buscan CVEs específicos, sino configuraciones inseguras o que se desvían de las mejores prácticas. Piénsalo como tener un auditor experto revisando cada rincón de tu servidor, sin que tengas que pagarle por hora.

Escaneo de cumplimiento normativo

OpenSCAP opera bajo el estándar SCAP definido por NIST y compara la configuración de tu sistema contra perfiles predefinidos como los benchmarks CIS o las STIG del DoD. Genera reportes auditables que demuestran cumplimiento (o incumplimiento) con estándares específicos. Básicamente, es la herramienta que tu auditor de seguridad quiere ver cuando te pide evidencias.

Escaneo de vulnerabilidades conocidas (CVE)

Trivy consulta bases de datos de vulnerabilidades (NVD, advisories de distribuciones) para identificar paquetes instalados con CVEs conocidos. Funciona tanto en sistemas de archivos locales como en imágenes de contenedores, lo que lo hace esencial para servidores tradicionales y entornos cloud-native por igual.

Lynis: auditoría de seguridad completa desde el host

Lynis es, probablemente, la herramienta de auditoría de seguridad más conocida para sistemas Unix y Linux. Lleva activa desde 2007, es de código abierto (GPLv3), no requiere agentes y puede ejecutarse incluso sin instalación — simplemente descomprimiendo el tarball. Realiza más de 300 comprobaciones individuales y genera un índice de endurecimiento (Hardening Index) con una puntuación de 0 a 100.

Personalmente, es una de las primeras herramientas que instalo en cualquier servidor nuevo. La relación esfuerzo-resultado es difícil de superar.

Instalación de Lynis

Puedes instalar Lynis desde los repositorios de tu distribución o directamente desde el repositorio oficial de CISOfy para tener la versión más reciente:

# Debian/Ubuntu - desde repositorios del sistema
sudo apt update && sudo apt install lynis -y

# RHEL/CentOS/Fedora
sudo dnf install lynis -y

# Instalación desde el repositorio oficial de CISOfy (recomendada para versión más reciente)
# Añadir la clave GPG
sudo wget -O - https://packages.cisofy.com/keys/cisofy-software-public.key | sudo apt-key add -

# Añadir el repositorio
echo "deb https://packages.cisofy.com/community/lynis/deb/ stable main" | sudo tee /etc/apt/sources.list.d/cisofy-lynis.list
sudo apt update && sudo apt install lynis -y

# Verificar versión instalada
lynis show version

Ejecutar una auditoría completa

Ejecutar un escaneo con Lynis es bastante directo. La auditoría completa suele tardar entre 2 y 5 minutos, dependiendo del sistema:

# Auditoría completa del sistema (requiere root para resultados completos)
sudo lynis audit system

# Auditoría rápida sin interacción manual
sudo lynis audit system --quick

# Auditoría con salida para parseo (útil para scripts)
sudo lynis audit system --quick --no-colors 2>&1 | tee /var/log/lynis-audit-$(date +%Y%m%d).log

Interpretar los resultados

Después de ejecutar la auditoría, Lynis muestra un resumen con varias secciones clave. Estas son las que deberías revisar primero:

# Ver el índice de endurecimiento (Hardening Index)
grep "hardening_index" /var/log/lynis-report.dat

# Listar todas las advertencias (prioridad alta)
grep "warning\[\]" /var/log/lynis-report.dat

# Listar todas las sugerencias de mejora
grep "suggestion\[\]" /var/log/lynis-report.dat

# Ver el resumen de resultados por categoría
grep "pam_" /var/log/lynis-report.dat
grep "firewall_" /var/log/lynis-report.dat

Un dato que conviene tener en cuenta: las instalaciones frescas de Linux suelen obtener puntuaciones entre 55 y 65. No te alarmes si tu primer resultado no es brillante. Un servidor de producción correctamente endurecido debería apuntar a 80 o más. Cada advertencia incluye un identificador de test (como AUTH-9286 o FIRE-4512) que puedes buscar para obtener la explicación detallada y los pasos de remediación.

Automatizar Lynis con cron

Para mantener una postura de seguridad continua, lo ideal es programar auditorías automáticas. Este script ejecuta Lynis, guarda el reporte y envía una notificación si la puntuación baja por debajo de un umbral que tú definas:

#!/bin/bash
# /usr/local/bin/lynis-scheduled-audit.sh
FECHA=$(date +%Y%m%d-%H%M)
REPORTE_DIR="/var/log/lynis/reportes"
UMBRAL_MINIMO=75

mkdir -p "$REPORTE_DIR"

# Ejecutar auditoría
lynis audit system --quick --no-colors --report-file "$REPORTE_DIR/lynis-$FECHA.dat" \
  --log-file "$REPORTE_DIR/lynis-$FECHA.log" > /dev/null 2>&1

# Extraer el índice de endurecimiento
INDICE=$(grep "hardening_index" "$REPORTE_DIR/lynis-$FECHA.dat" | cut -d= -f2)

# Contar advertencias
WARNINGS=$(grep -c "warning\[\]" "$REPORTE_DIR/lynis-$FECHA.dat")

# Alerta si la puntuación es baja
if [ "$INDICE" -lt "$UMBRAL_MINIMO" ]; then
  echo "ALERTA: Índice Lynis=$INDICE (umbral=$UMBRAL_MINIMO), Advertencias=$WARNINGS" \
    | systemd-cat -t lynis-audit -p warning
fi

# Limpiar reportes de más de 90 días
find "$REPORTE_DIR" -name "lynis-*.dat" -mtime +90 -delete
find "$REPORTE_DIR" -name "lynis-*.log" -mtime +90 -delete
# Añadir al crontab — ejecutar cada domingo a las 3:00 AM
sudo crontab -e
# Agregar esta línea:
0 3 * * 0 /usr/local/bin/lynis-scheduled-audit.sh

OpenSCAP: cumplimiento normativo con benchmarks CIS y STIG

Donde Lynis brilla por su flexibilidad y facilidad de uso, OpenSCAP destaca en el cumplimiento normativo estandarizado. Si necesitas demostrar ante un auditor que tu servidor cumple con los benchmarks CIS, los requisitos de PCI DSS o las STIG del Departamento de Defensa de EE.UU., esta es tu herramienta. Utiliza el protocolo SCAP definido por NIST para almacenar y procesar datos de seguridad de forma estandarizada.

Honestamente, la curva de aprendizaje de OpenSCAP es un poco más pronunciada que la de Lynis, pero los reportes que genera son exactamente lo que piden las auditorías formales.

Instalación de OpenSCAP y SCAP Security Guide

# RHEL/CentOS/Rocky/AlmaLinux 9
sudo dnf install -y openscap-scanner scap-security-guide openscap-utils

# Debian/Ubuntu
sudo apt install -y libopenscap8 ssg-debian ssg-ubuntu

# Verificar instalación
oscap --version

# Listar los perfiles de seguridad disponibles para tu distribución
# RHEL 9:
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Ubuntu 22.04:
oscap info /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

Ejecutar un escaneo con perfil CIS

El escaneo CIS compara la configuración de tu sistema contra el benchmark CIS, uno de los estándares de seguridad más reconocidos a nivel mundial. Cada regla se evalúa como «aprobada» o «fallida», y el resultado se exporta como un reporte HTML bastante detallado:

# Escaneo CIS Level 2 - Server en RHEL 9
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --results /var/log/openscap/cis-results-$(date +%Y%m%d).xml \
  --report /var/log/openscap/cis-report-$(date +%Y%m%d).html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Escaneo CIS en Ubuntu 22.04
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level2_server \
  --results /var/log/openscap/cis-results-$(date +%Y%m%d).xml \
  --report /var/log/openscap/cis-report-$(date +%Y%m%d).html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

El reporte HTML generado es extraordinariamente completo. Incluye cada regla evaluada, su resultado (pass/fail), una descripción del riesgo y, en la mayoría de casos, la remediación exacta. Lo puedes abrir en cualquier navegador y compartirlo directamente con tu equipo de auditoría sin tener que formatear nada.

Remediación automática con OpenSCAP

Una de las funcionalidades más útiles (y potentes) de OpenSCAP es su capacidad de generar scripts de remediación automática, tanto en Bash como en Ansible:

# Generar un playbook de Ansible para remediar las fallas detectadas
sudo oscap xccdf generate fix \
  --fix-type ansible \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --output /var/log/openscap/remediacion-cis.yml \
  /var/log/openscap/cis-results-$(date +%Y%m%d).xml

# Generar un script Bash de remediación
sudo oscap xccdf generate fix \
  --fix-type bash \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --output /var/log/openscap/remediacion-cis.sh \
  /var/log/openscap/cis-results-$(date +%Y%m%d).xml

Precaución importante: nunca ejecutes los scripts de remediación directamente en producción sin revisarlos línea por línea antes. He visto casos donde una remediación automática deshabilitó el acceso SSH o rompió la autenticación de una aplicación web. Revisa cada cambio, prueba en staging y aplica de forma controlada.

Trivy: escaneo de vulnerabilidades CVE en host y contenedores

Trivy (versión 0.69 a fecha de marzo de 2026) es el escáner de vulnerabilidades open source más popular para entornos cloud-native. Desarrollado por Aqua Security, detecta CVEs conocidos en paquetes del sistema operativo, dependencias de aplicaciones, imágenes de contenedores y configuraciones de infraestructura como código.

Lo que más me gusta de Trivy es su velocidad. Y la facilidad para integrarlo en pipelines CI/CD lo convierte en una herramienta prácticamente indispensable si trabajas con contenedores.

Instalación de Trivy

# Instalación en Debian/Ubuntu
sudo apt install -y wget apt-transport-https gnupg
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | gpg --dearmor | sudo tee /usr/share/keyrings/trivy.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb generic main" | sudo tee /etc/apt/sources.list.d/trivy.list
sudo apt update && sudo apt install trivy -y

# Instalación en RHEL/CentOS/Fedora
sudo rpm -ivh https://github.com/aquasecurity/trivy/releases/latest/download/trivy_0.69.2_Linux-64bit.rpm

# Instalación con snap (cualquier distribución)
sudo snap install trivy

# Verificar versión
trivy version

Escanear el sistema de archivos local

Trivy puede escanear directamente el sistema operativo del host en busca de paquetes con vulnerabilidades conocidas. Esto es justo lo que necesitas para mantener tus servidores de producción al día:

# Escanear el sistema de archivos raíz del host
sudo trivy rootfs /

# Filtrar solo vulnerabilidades altas y críticas
sudo trivy rootfs --severity HIGH,CRITICAL /

# Generar un reporte en formato tabla con detalles
sudo trivy rootfs --severity HIGH,CRITICAL --format table / 2>&1 | tee /var/log/trivy-host-$(date +%Y%m%d).txt

# Generar reporte en formato JSON para procesamiento automatizado
sudo trivy rootfs --severity HIGH,CRITICAL --format json --output /var/log/trivy-host-$(date +%Y%m%d).json /

Escanear imágenes de contenedores

Si trabajas con Docker o Podman, Trivy puede escanear imágenes antes de desplegarlas. Esto te ahorra más de un dolor de cabeza:

# Escanear una imagen Docker
trivy image nginx:latest

# Escanear solo vulnerabilidades con fix disponible
trivy image --ignore-unfixed alpine:3.19

# Escanear imagen local que aún no se ha subido al registro
trivy image --input ./mi-aplicacion.tar

# Fallar el pipeline si se detectan vulnerabilidades críticas (ideal para CI/CD)
trivy image --exit-code 1 --severity CRITICAL mi-registro.example.com/mi-app:v2.1

Integración con GitHub Actions

Para integrar Trivy en tu pipeline CI/CD con GitHub Actions, añade este workflow a tu repositorio. Es sorprendentemente sencillo:

# .github/workflows/trivy-scan.yml
name: Trivy Security Scan
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  trivy-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Docker image
        run: docker build -t mi-app:${{ github.sha }} .

      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: mi-app:${{ github.sha }}
          format: sarif
          output: trivy-results.sarif
          severity: HIGH,CRITICAL

      - name: Upload Trivy scan results
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: trivy-results.sarif

Estrategia combinada: un plan de escaneo integral

Cada herramienta cubre un aspecto diferente de la seguridad. Usarlas por separado deja huecos. Usarlas juntas te da una visión completa.

Bueno, entonces ¿cómo las combinamos de forma práctica? Aquí tienes un script que ejecuta las tres herramientas de una sola vez y recopila los resultados en un directorio unificado:

#!/bin/bash
# /usr/local/bin/security-scan-completo.sh
# Plan de escaneo integral: Lynis + OpenSCAP + Trivy

FECHA=$(date +%Y%m%d-%H%M)
RESULTADO_DIR="/var/log/security-scans/$FECHA"
mkdir -p "$RESULTADO_DIR"

echo "=== Inicio del escaneo de seguridad integral: $FECHA ==="

# 1. Lynis — Auditoría de configuración
echo "[1/3] Ejecutando auditoría Lynis..."
lynis audit system --quick --no-colors \
  --report-file "$RESULTADO_DIR/lynis-report.dat" \
  --log-file "$RESULTADO_DIR/lynis.log" > /dev/null 2>&1

LYNIS_SCORE=$(grep "hardening_index" "$RESULTADO_DIR/lynis-report.dat" | cut -d= -f2)
LYNIS_WARNINGS=$(grep -c "warning\[\]" "$RESULTADO_DIR/lynis-report.dat")
echo "  Lynis: Hardening Index=$LYNIS_SCORE, Advertencias=$LYNIS_WARNINGS"

# 2. OpenSCAP — Cumplimiento CIS (ajustar el perfil y datastream según tu distro)
echo "[2/3] Ejecutando escaneo OpenSCAP CIS..."
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --results "$RESULTADO_DIR/openscap-results.xml" \
  --report "$RESULTADO_DIR/openscap-report.html" \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml > /dev/null 2>&1

SCAP_PASS=$(grep -c 'result">pass' "$RESULTADO_DIR/openscap-results.xml" 2>/dev/null || echo "N/A")
echo "  OpenSCAP: Reglas aprobadas=$SCAP_PASS"

# 3. Trivy — Vulnerabilidades CVE
echo "[3/3] Ejecutando escaneo Trivy..."
trivy rootfs --severity HIGH,CRITICAL \
  --format json \
  --output "$RESULTADO_DIR/trivy-results.json" / > /dev/null 2>&1

TRIVY_VULNS=$(jq '[.Results[].Vulnerabilities // [] | length] | add' "$RESULTADO_DIR/trivy-results.json" 2>/dev/null || echo "0")
echo "  Trivy: Vulnerabilidades HIGH/CRITICAL=$TRIVY_VULNS"

echo "=== Escaneo completado. Reportes en: $RESULTADO_DIR ==="

En cuanto a la frecuencia recomendada: Lynis semanalmente, OpenSCAP mensualmente (o después de cada cambio de configuración significativo), y Trivy diariamente o en cada despliegue de contenedores. Así cubres configuraciones, cumplimiento normativo y vulnerabilidades conocidas de forma continua.

Automatización a escala con Ansible

Si gestionas múltiples servidores, ejecutar estas herramientas manualmente en cada uno no escala. Simplemente no es viable. Con Ansible puedes centralizar los escaneos y recopilar los resultados automáticamente:

# playbook-security-scan.yml
---
- name: Escaneo de seguridad centralizado
  hosts: servidores_produccion
  become: yes
  tasks:
    - name: Ejecutar auditoría Lynis
      command: lynis audit system --quick --no-colors
      register: lynis_result
      changed_when: false

    - name: Extraer Hardening Index de Lynis
      shell: grep "hardening_index" /var/log/lynis-report.dat | cut -d= -f2
      register: lynis_score
      changed_when: false

    - name: Escanear vulnerabilidades con Trivy
      command: trivy rootfs --severity HIGH,CRITICAL --format json --output /tmp/trivy-scan.json /
      register: trivy_result
      changed_when: false

    - name: Recopilar resultados de Trivy
      fetch:
        src: /tmp/trivy-scan.json
        dest: "./resultados/{{ inventory_hostname }}/trivy-scan.json"
        flat: yes

    - name: Mostrar resumen
      debug:
        msg: "{{ inventory_hostname }}: Lynis Score={{ lynis_score.stdout }}"

Un consejo: combina esto con el rol devsec.hardening de Ansible Galaxy para no solo detectar problemas, sino también remediar automáticamente las configuraciones inseguras de SSH, sysctl y auditd según las mejores prácticas de la industria. Es una combinación que funciona muy bien en la práctica.

Preguntas frecuentes

¿Cuál es la diferencia entre un escáner de vulnerabilidades y una herramienta de auditoría de seguridad?

Un escáner de vulnerabilidades como Trivy busca paquetes de software con CVEs conocidos — fallos de seguridad documentados con un identificador público. Una herramienta de auditoría como Lynis, en cambio, revisa la configuración general del sistema (permisos, servicios, cifrado, logging) para detectar debilidades que no necesariamente tienen un CVE asociado pero que igualmente exponen al sistema. Lo ideal es usar ambos tipos para tener una visión completa.

¿Lynis modifica la configuración de mi servidor?

No, en absoluto. Lynis es una herramienta de solo lectura. Ejecuta comprobaciones y genera reportes, pero nunca toca archivos, configuraciones ni servicios del sistema. Todos los cambios que recomienda deben aplicarse manualmente. OpenSCAP puede generar scripts de remediación, pero tampoco los ejecuta automáticamente — siempre requiere que el administrador tome la decisión final.

¿Puedo usar OpenSCAP en distribuciones que no sean Red Hat?

Sí, aunque hay que ser honesto: el soporte es más robusto en distribuciones basadas en RHEL (CentOS, Rocky, AlmaLinux, Fedora). El proyecto SCAP Security Guide también proporciona perfiles para Ubuntu, Debian y SUSE, pero la cobertura de reglas puede ser menor. Si usas Ubuntu o Debian, la combinación de Lynis (que funciona perfectamente en cualquier distribución) con Trivy suele ser más práctica que depender solo de OpenSCAP.

¿Con qué frecuencia debo ejecutar escaneos de vulnerabilidades?

Depende del tipo de escaneo. Para CVEs con Trivy, lo ideal es ejecutar escaneos diariamente o — mejor aún — integrarlos en tu pipeline CI/CD para que cada despliegue se verifique automáticamente. Para auditorías de configuración con Lynis, una vez por semana es buena frecuencia. Para cumplimiento normativo con OpenSCAP, mensualmente o después de cada cambio importante de configuración.

¿Trivy puede escanear servidores Linux tradicionales o solo funciona con contenedores?

Trivy es conocido principalmente por el escaneo de contenedores, pero desde hace varias versiones soporta también el escaneo del sistema de archivos local con trivy rootfs / y el escaneo de repositorios Git remotos. Así que sí, es perfectamente válido para servidores Linux tradicionales sin contenedores, donde detectará paquetes del sistema operativo con CVEs conocidos.

Sobre el Autor Editorial Team

Our team of expert writers and editors.