Actualizaciones y gestión de vulnerabilidades

En 2017, Equifax sufrió una brecha a través de una vulnerabilidad sin parchear en Apache Struts. El parche llevaba dos meses disponible. Simplemente no lo habían aplicado. Una de las mayores filtraciones de datos de la historia, completamente evitable con una actualización a tiempo.

Usted no es Equifax, pero la lección aplica. La mayoría de las brechas no provienen de exploits sofisticados de zero-day. Ocurren porque alguien no actualizó el software con una vulnerabilidad conocida y publicada. Los atacantes escanean constantemente en busca de software desactualizado. Cuando se publica un CVE crítico, los intentos de explotación comienzan en cuestión de horas.

Este capítulo establece un sistema para saber cuándo su software tiene vulnerabilidades y realmente corregirlas antes de que los atacantes las encuentren.

Por qué se descuidan las actualizaciones

Todo el mundo sabe que las actualizaciones son importantes. ¿Por qué se saltan entonces?

«Podría romper algo». Esta es la grande. Actualiza una biblioteca y de repente la mitad de sus pruebas fallan. Parchea el SO y un servicio crítico deja de funcionar. Después de algunas malas experiencias, la gente se vuelve cautelosa. Las actualizaciones se acumulan.

Nadie es responsable. Los desarrolladores asumen que operaciones se encarga de las actualizaciones. Operaciones asume que los desarrolladores se encargan de sus dependencias. Nadie está revisando los servidores que «simplemente funcionan».

Sin visibilidad. No sabe qué versiones está ejecutando. No sabe qué CVEs le afectan. Se entera cuando algo falla o cuando un investigador de seguridad le envía un correo.

Lleva tiempo. Ejecutar actualizaciones, probar, desplegar: no es un trabajo glamuroso. Cuando hay trabajo de producto que entregar, las actualizaciones se posponen indefinidamente al «próximo sprint».

El Security Champion no parchea todo personalmente. Pero crea visibilidad y responsabilidad para que las actualizaciones realmente sucedan.

Los dos tipos de actualizaciones

Piense en las actualizaciones en dos categorías:

Sistema operativo e infraestructura

Son sus servidores, contenedores, servicios en la nube. Actualizaciones del kernel de Linux, actualizaciones de paquetes, actualizaciones de imágenes base de Docker.

Quién suele ser responsable: DevOps, administradores de sistemas, o quienes gestionan la infraestructura.

Estrategia de actualización: Automática donde sea posible, ventanas programadas para actualizaciones manuales.

Riesgo si se descuida: Ejecución remota de código, escalada de privilegios, compromiso total del sistema.

Dependencias de aplicaciones

Son las bibliotecas y paquetes de los que depende su código. Paquetes npm, bibliotecas de Python, gems de Ruby, módulos de Go.

Quién suele ser responsable: Los desarrolladores, pero a menudo nadie en concreto.

Estrategia de actualización: PRs automatizados de Dependabot/Renovate, ciclos de revisión periódicos.

Riesgo si se descuida: Ataques a la cadena de suministro, vulnerabilidades conocidas en las bibliotecas que usa.

Ambos importan. Un SO completamente parcheado no sirve de nada si su aplicación tiene una versión vulnerable de Log4j.

Configuración de actualizaciones automáticas

Las actualizaciones automáticas suenan aterradoras hasta que se da cuenta de que la alternativa es no tener actualizaciones en absoluto.

Servidores Linux

Para servidores Ubuntu/Debian, active las actualizaciones no atendidas:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Esto instala actualizaciones de seguridad automáticamente. Puede configurar qué se actualiza automáticamente en /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
};

// Automatically reboot if required
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "03:00";

Para RHEL/CentOS/Rocky:

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer

¿Debería reiniciar automáticamente? Para servidores no críticos, sí. Para producción, probablemente quiera programar los reinicios durante las ventanas de mantenimiento. Pero las actualizaciones del kernel no tienen efecto hasta el reinicio: si nunca reinicia, está ejecutando kernels vulnerables.

Contenedores Docker

Sus contenedores heredan vulnerabilidades de sus imágenes base. Si está ejecutando python:3.9 de hace dos años, está ejecutando con dos años de vulnerabilidades sin parchear.

Estrategia 1: Reconstrucciones periódicas

Reconstruya y vuelva a desplegar contenedores semanalmente, aunque su código no haya cambiado. Esto descarga imágenes base actualizadas con los últimos parches.

Añada esto a su pipeline de CI:

# GitHub Actions example
on:
  schedule:
    - cron: '0 3 * * 0'  # Every Sunday at 3 AM
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build with fresh base image
        run: docker build --pull -t myapp:latest .

El flag --pull obliga a Docker a comprobar si hay imágenes base actualizadas.

Estrategia 2: Use imágenes base mínimas

Menos paquetes = menos vulnerabilidades. Considere:

• alpine en lugar de ubuntu para aplicaciones simples
• Imágenes distroless para producción (sin shell, superficie de ataque mínima)
• Imágenes slim específicas del lenguaje (python:3.11-slim, node:20-slim)

Servicios en la nube

AWS, GCP y Azure gestionan las actualizaciones de infraestructura para los servicios gestionados. Pero usted sigue siendo responsable de:

• Instancias EC2/Compute Engine/VM — son sus servidores, actualícelos
• Imágenes de contenedores en ECS/EKS/GKE — reconstruya regularmente
• Versiones de runtime de Lambda/Cloud Functions — actualice cuando se publiquen nuevos runtimes
• Bases de datos gestionadas — algunas actualizaciones requieren ventanas de mantenimiento programadas

Compruebe su consola en la nube para detectar recursos desactualizados. AWS tiene Trusted Advisor (nivel gratuito limitado), GCP tiene Security Command Center.

Actualizaciones de dependencias con Dependabot (o Renovate)

Dependabot de GitHub es gratuito y gestiona la parte más tediosa de las actualizaciones de dependencias: saber que existen. Si usa GitLab, Bitbucket o desea más opciones de configuración, Renovate es una excelente alternativa con funcionalidad similar.

Configuración de Dependabot

Cree .github/dependabot.yml en su repositorio:

version: 2
updates:
  # JavaScript/npm
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10

  # Python
  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"

  # Docker
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"

  # GitHub Actions
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Dependabot creará pull requests cuando las dependencias tengan actualizaciones.

Hacer que Dependabot sea útil

El problema con Dependabot es la fatiga de PRs. Abre 15 PRs a la semana y la gente empieza a ignorarlos.

Agrupe las actualizaciones que no son de seguridad:

- package-ecosystem: "npm"
  directory: "/"
  schedule:
    interval: "weekly"
  groups:
    dev-dependencies:
      patterns:
        - "*"
      update-types:
        - "minor"
        - "patch"

Esto agrupa las actualizaciones menores y de parche en PRs únicos, reduciendo el ruido.

Priorice las actualizaciones de seguridad:

Las actualizaciones de seguridad de Dependabot son independientes de las actualizaciones de versión. Actívelas en la configuración de su repositorio (Settings → Security → Dependabot alerts). Estas crean PRs específicamente para vulnerabilidades conocidas.

Configure la fusión automática para actualizaciones de bajo riesgo:

# In your CI workflow
- name: Auto-merge Dependabot PRs
  if: github.actor == 'dependabot[bot]'
  run: gh pr merge --auto --squash "$PR_URL"
  env:
    PR_URL: ${{ github.event.pull_request.html_url }}
    GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Haga esto solo si tiene buena cobertura de pruebas. De lo contrario, estará desplegando automáticamente fallos.

Análisis de vulnerabilidades más allá de Dependabot

Dependabot comprueba sus dependencias declaradas. Pero hay más que analizar.

Snyk

Snyk ofrece un nivel gratuito que incluye:

• Análisis de dependencias (similar a Dependabot, pero con más contexto)
• Análisis de imágenes de contenedores
• Análisis de Infraestructura como Código

Para equipos pequeños, el nivel gratuito suele ser suficiente. Intégrelo en su CI:

# GitHub Actions
- name: Run Snyk
  uses: snyk/actions/node@master  # or /python, /docker, etc.
  env:
    SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

Snyk le proporciona clasificaciones de gravedad y contexto de explotabilidad que ayudan a priorizar las correcciones.

Trivy para contenedores

Trivy es gratuito y analiza imágenes de contenedores en busca de vulnerabilidades del SO y de bibliotecas:

# Scan a local image
trivy image myapp:latest

# Scan in CI
trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:latest

El --exit-code 1 hace que su pipeline falle si se encuentran vulnerabilidades altas/críticas. Útil para evitar que se desplieguen imágenes vulnerables.

Funciones de seguridad de GitHub

GitHub ofrece varias funciones de seguridad gratuitas:

• Alertas de Dependabot — Notificaciones cuando las dependencias tienen vulnerabilidades conocidas
• Análisis de código — SAST (análisis estático) usando CodeQL
• Análisis de secretos — Detecta credenciales comprometidas accidentalmente

Active todas estas en Settings → Security. Son gratuitas para repositorios públicos e incluidas en GitHub Advanced Security para repositorios privados.

Herramientas para la gestión de vulnerabilidades

Aquí hay una lista completa de herramientas, organizadas por categoría y coste.

Análisis de dependencias

Gratuitas/Código abierto:

• Dependabot — Integrado en GitHub, analiza dependencias y abre PRs. Configuración cero para repositorios de GitHub.
• Renovate — Más flexible que Dependabot, soporta más plataformas (GitLab, Bitbucket, Azure DevOps). Autohospedado o use la versión alojada gratuita de Mend.
• OWASP Dependency-Check — Analiza Java, .NET, Node.js, Python, Ruby. Herramienta de línea de comandos, ideal para CI/CD. Completamente gratuita.
• Grype — Escáner de vulnerabilidades rápido de Anchore. Analiza imágenes de contenedores y sistemas de archivos. Código abierto.
• Safety — Comprobador de dependencias específico para Python. CLI gratuita, comprueba contra la base de datos de PyUp.io.
• npm audit / yarn audit — Integrados en npm y yarn. Ejecute npm audit para ver vulnerabilidades en sus node_modules.

Comerciales con niveles gratuitos:

• Snyk — Nivel gratuito: 200 pruebas/mes, ilimitado para código abierto. Cubre dependencias, contenedores, IaC.
• Socket — Se centra en ataques a la cadena de suministro (typosquatting, paquetes maliciosos). Gratuito para código abierto.
• Mend (formerly WhiteSource) — Gratuito para proyectos de código abierto mediante Mend Bolt. Funciones empresariales para planes de pago.

Empresariales:

• Sonatype Nexus Lifecycle — Inteligencia profunda sobre componentes, aplicación de políticas. Caro pero completo.
• Veracode SCA — Parte de la plataforma de seguridad de aplicaciones de Veracode.
• Black Duck — De Synopsys. Análisis completo de licencias y seguridad.

Seguridad de contenedores

Gratuitas/Código abierto:

• Trivy — El escáner gratuito de referencia. Cubre imágenes, sistemas de archivos, repositorios git, Kubernetes. Desarrollo activo.
• Grype — Más rápido que Trivy en algunos benchmarks, buena detección de vulnerabilidades.
• Clair — De Red Hat/Quay. Diseñado para registros de contenedores. Configuración más compleja.
• Docker Scout — Integrado en Docker Desktop y Docker Hub. Nivel gratuito disponible.
• Cosign — Firma y verifica imágenes de contenedores. Parte del proyecto Sigstore.

Comerciales:

• Snyk Container — Se integra con registros y CI/CD. Parte de la plataforma Snyk.
• Aqua Security — Plataforma completa de seguridad para contenedores y Kubernetes. Precios empresariales.
• Sysdig Secure — Protección en tiempo de ejecución más análisis de vulnerabilidades.
• Prisma Cloud (Twistlock) — Seguridad de contenedores de Palo Alto. Empresarial.

Análisis de vulnerabilidades de infraestructura

Gratuitas/Código abierto:

• OpenVAS — Escáner de vulnerabilidades con todas las funciones. La edición comunitaria es gratuita. Analiza redes y hosts en busca de vulnerabilidades.
• Nuclei — Escáner rápido basado en plantillas. Excelente para comprobaciones personalizadas. Comunidad muy activa.
• Nmap — No es un escáner de vulnerabilidades en sí, pero es esencial para el descubrimiento. Úselo con scripts para detección básica de vulnerabilidades.
• Lynis — Auditoría de seguridad para Linux/Unix. Comprueba la configuración, no las vulnerabilidades.

Comerciales:

• Nessus — Estándar del sector. La versión Essentials (16 IPs) es gratuita. La versión Professional empieza en ~$3.000/año.
• Qualys — Plataforma de análisis basada en la nube. Precios empresariales.
• Rapid7 InsightVM — Gestión de vulnerabilidades con seguimiento de remediación.
• AWS Inspector — Analiza instancias EC2 e imágenes de contenedores en AWS. Pago por análisis.

Gestión de parches

Gratuitas/Código abierto:

• Ansible — Automatice la aplicación de parches en servidores. Gratuito y de código abierto. Curva de aprendizaje pronunciada pero potente.
• Puppet / Chef — Gestión de configuración que puede aplicar niveles de parche. Núcleos de código abierto.

Nativas en la nube:

• AWS Systems Manager Patch Manager — Gratuito para recursos de AWS. Defina líneas base de parches, programe ventanas de parcheo.
• Azure Update Management — Incluido con Azure. Gestione actualizaciones en VMs Windows y Linux.
• GCP OS Patch Management — Parte de VM Manager. Parchee VMs de Compute Engine.

Comerciales:

• Automox — Gestión de parches nativa en la nube. Funciona en Windows, macOS, Linux. Precio por endpoint.
• ManageEngine Patch Manager Plus — En local o en la nube. Compatible con muchos SO y aplicaciones de terceros.
• Ivanti — Gestión de parches empresarial.

SBOM (Software Bill of Materials)

Los SBOMs se están volviendo esenciales para el cumplimiento y la seguridad de la cadena de suministro. Listan todos los componentes de su software.

Gratuitas/Código abierto:

• Syft — Genera SBOMs a partir de imágenes de contenedores y sistemas de archivos. Genera salida en formatos SPDX y CycloneDX.
• Trivy — También genera SBOMs. Use trivy image --format spdx myimage:latest.
• CycloneDX — Estándar de SBOM con herramientas para muchos lenguajes (Maven, npm, pip, etc.).

Comerciales:

• Anchore Enterprise — Generación de SBOM más aplicación de políticas y cumplimiento.
• Dependency-Track — Plataforma de código abierto para seguimiento de SBOMs y vulnerabilidades en su portfolio. Autohospedado.

Qué elegir para una empresa pequeña

Si está empezando, aquí hay un stack práctico:

1. Dependabot o Renovate para actualizaciones de dependencias (gratuito)
2. Trivy para análisis de contenedores (gratuito)
3. Funciones de seguridad de GitHub para análisis de código y detección de secretos (gratuito para repositorios públicos)
4. OpenVAS o Nessus Essentials para análisis de infraestructura (gratuito)
5. Ansible para automatización de parches si tiene muchos servidores (gratuito)
6. Syft para generación de SBOM si lo necesita para cumplimiento (gratuito)

Añada herramientas comerciales cuando:

• Necesite paneles centralizados para muchos repositorios
• El cumplimiento requiera informes específicos
• Quiera inteligencia de priorización (qué vulnerabilidades son realmente explotables)
• Esté escalando más allá de lo que los niveles gratuitos soportan

Construcción de un proceso de monitorización de CVEs

Estar al tanto de las vulnerabilidades en su stack específico requiere algo más que el análisis automatizado.

Conozca su stack

Primero, documente lo que está ejecutando. Como mínimo:

• Lenguajes de programación y versiones (Python 3.11, Node 20, etc.)
• Frameworks (Django 4.2, Express 4.18, React 18)
• Bases de datos (PostgreSQL 15, MongoDB 7)
• Infraestructura (Ubuntu 22.04, nginx 1.24, Redis 7)
• Dependencias SaaS críticas (Stripe SDK, AWS SDK, etc.)

Esto debería llevar 30 minutos compilarlo. Guárdelo en algún lugar accesible para todos: su hoja de cálculo de inventario de SaaS es un buen lugar.

Configure alertas para su stack

Opción 1: Bases de datos de CVEs directamente

Suscríbase a alertas de:

• NVD — La base de datos nacional de vulnerabilidades, completa pero ruidosa
• CISA KEV — Vulnerabilidades conocidas explotadas, lista más pequeña de problemas activamente explotados

Opción 2: Páginas de seguridad de proveedores

La mayoría de los proyectos importantes tienen listas de anuncios de seguridad:

• Ubuntu Security Notices
• Node.js Security Releases
• Django Security Releases
• PostgreSQL Security

Suscríbase a los feeds RSS o listas de correo de sus dependencias críticas.

Opción 3: Alertas agregadas

• OSV — Base de datos de vulnerabilidades de código abierto, bien organizada
• GitHub Advisory Database — Buena para dependencias que usa desde GitHub

La revisión semanal de CVEs

Configure un evento recurrente en el calendario: «Revisión de CVEs», 30 minutos, una vez a la semana.

Durante este tiempo:

1. Compruebe las alertas de Dependabot/Snyk que se abrieron esta semana
2. Examine CISA KEV en busca de nuevas entradas que coincidan con su stack
3. Revise las noticias de seguridad para detectar vulnerabilidades importantes (una revisión rápida de RSS o seguimiento de investigadores de seguridad en Twitter/Mastodon)
4. Priorice qué necesita parchearse esta semana frente al mes que viene

No se trata de leer cada CVE. Se trata de no ser sorprendido por los críticos.

Priorización de qué actualizar

No toda vulnerabilidad requiere acción inmediata. Aquí hay un marco práctico de priorización:

Parchee inmediatamente (en 24-48 horas)

• Gravedad crítica/alta Y activamente explotada
• Afecta sistemas expuestos a Internet
• CISA lo añade a la lista KEV

Ejemplos: Log4Shell, ProxyLogon, zero-days recientes en navegadores.

Parchee esta semana

• Gravedad crítica/alta, aún no explotada
• Afecta sistemas internos con datos sensibles
• Tiene un exploit de prueba de concepto publicado

Parchee este mes

• Gravedad media
• Requiere condiciones específicas para ser explotado
• Afecta sistemas no críticos

Evalúe durante los ciclos regulares

• Gravedad baja
• Vulnerabilidades teóricas sin exploits prácticos
• Consideraciones de defensa en profundidad

En caso de duda, mire la puntuación CVSS y si hay explotación activa. Una vulnerabilidad teórica sin exploit conocido es menos urgente que una vulnerabilidad moderada con un módulo de Metasploit.

Cómo leer un CVE y evaluar el riesgo real

Cuando aparece un CVE en sus alertas, así puede evaluar rápidamente si debe preocuparse:

1. Compruebe la puntuación y el vector CVSS

Las puntuaciones CVSS van de 0 a 10. Pero la puntuación sola no es suficiente: mire el vector:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Partes clave:

• AV (Attack Vector): N=Red (peor), A=Adyacente, L=Local, P=Físico
• AC (Attack Complexity): L=Baja (fácil de explotar), H=Alta (requiere condiciones específicas)
• PR (Privileges Required): N=Ninguno (peor), L=Bajo, H=Alto
• UI (User Interaction): N=Ninguna (peor), R=Requerida

Una vulnerabilidad accesible por red, de baja complejidad, sin autenticación es peor que un exploit local de alta complejidad que requiere acceso de administrador, incluso si ambos puntúan 8.0.

2. Compruebe si hay explotación conocida

• ¿Está en CISA KEV? → Los atacantes la están usando activamente
• ¿Hay un módulo de Metasploit? → Los script kiddies pueden explotarla
• ¿Hay informes de explotación? → Compruebe Twitter/Mastodon, noticias de seguridad

Un CVE con explotación activa es urgente independientemente de la puntuación CVSS.

3. Compruebe si realmente es vulnerable

• ¿Usa el componente afectado?
• ¿Está habilitada la función/característica vulnerable?
• ¿Está expuesta a la red o solo es interna?

Ejemplo: Una vulnerabilidad crítica en mod_proxy de Apache no le afecta si usa nginx.

4. Compruebe si ya está protegido

A veces otras defensas mitigan el riesgo:

• Reglas del WAF que bloquean el ataque
• Segmentación de red que limita la exposición
• El servicio vulnerable no está accesible desde Internet

Esto no significa «no parchee», pero afecta a la prioridad.

5. Lea el aviso, no solo el titular

Las noticias de seguridad a menudo sensacionalizan. El aviso real del proveedor le dice:

• Exactamente qué versiones están afectadas
• Cuál es la solución
• Soluciones alternativas si no puede actualizar de inmediato
• Si la vulnerabilidad requiere una configuración específica

Creación de responsabilidad

Las actualizaciones no ocurren sin propietarios.

Asigne responsabilidades de actualización

En su inventario de SaaS o en un documento separado, asigne propietarios:

Sistema	Responsable de actualización	Frecuencia de actualización	Última actualización
Servidores Ubuntu	DevOps lead	Auto semanal + manual mensual	2024-01-15
Imágenes base Docker	Cada equipo	Reconstrucciones semanales	Continuo
Dependencias npm	Equipo frontend	Revisión semanal de Dependabot	2024-01-12
Dependencias Python	Equipo backend	Revisión semanal de Dependabot	2024-01-12
PostgreSQL	DevOps lead	Trimestral o parches críticos	2024-01-01

Haga seguimiento de la deuda de actualizaciones

Mantenga un registro simple de las actualizaciones pendientes:

Componente	Versión actual	Última versión	Días de retraso	Bloqueador
React	17.0.2	18.2.0	180	Cambios que rompen compatibilidad, necesita pruebas
lodash	4.17.15	4.17.21	90	Ninguno, simplemente descuidado

Revise esto mensualmente. Las cosas que llevan más de 90 días necesitan una decisión: actualizar, aceptar el riesgo o reemplazar la dependencia.

La reunión mensual de actualizaciones

15 minutos, una vez al mes. Asistentes: Security Champion, DevOps lead, un desarrollador por equipo.

Orden del día:

1. Revisar los CVEs críticos del mes pasado (2 min)
2. Comprobar el registro de deuda de actualizaciones para detectar retrasos (3 min)
3. Decidir qué se prioriza el mes siguiente (5 min)
4. Revisar los fallos o retrocesos de actualizaciones (5 min)

Eso es todo. La visibilidad regular evita que las actualizaciones se pierdan.

Consejos prácticos que ahorran tiempo y problemas

Estos son los trucos que no están en la documentación oficial pero que facilitan su trabajo.

Verifique que las actualizaciones automáticas realmente funcionan

Configure las actualizaciones automáticas y luego compruebe que se están ejecutando. Un fallo común: unattended-upgrades instalado pero nunca ejecutándose.

# Ubuntu/Debian: check last run
cat /var/log/unattended-upgrades/unattended-upgrades.log | tail -50

# Check if it's scheduled
systemctl status apt-daily-upgrade.timer

# RHEL/CentOS: check dnf-automatic
journalctl -u dnf-automatic-install.service --since "7 days ago"

Si los registros están vacíos o el temporizador está desactivado, sus actualizaciones «automáticas» no están ocurriendo.

Script de auditoría de versiones rápida

Antes de poder actualizar, necesita saber qué está ejecutando. Este comando le da una instantánea rápida:

# Get all installed packages with versions (Debian/Ubuntu)
dpkg-query -W -f='${Package} ${Version}\n' > installed-packages.txt

# For Python projects
pip freeze > python-deps.txt

# For Node projects
npm list --depth=0 > node-deps.txt

# For Docker base images in your codebase
grep -r "FROM " --include="Dockerfile*" . | sort -u

Guarde estas instantáneas. Cuando se publique un CVE, puede hacer grep rápidamente para ver si está afectado.

La regla del viernes

Nunca despliegue actualizaciones el viernes por la tarde. Si algo falla, tendrá que arreglarlo durante el fin de semana o dejarlo roto hasta el lunes.

Los mejores momentos para parchear:

• Martes o miércoles por la mañana (tiempo de recuperación antes del fin de semana)
• Después de una versión importante, no antes (no añada variables antes de grandes despliegues)
• Durante las horas de menor tráfico para sistemas de producción

Configure sus horarios de actualización automática en consecuencia. Ese tiempo de reinicio 03:00 en los ejemplos de configuración no es aleatorio.

Actualizaciones canarias para producción

No actualice todos los servidores de producción a la vez. Si tiene varios servidores:

1. Actualice primero un servidor (el canario)
2. Monitorice durante 15-30 minutos
3. Si no hay problemas, actualice el resto
4. Si hay problemas, revierta el canario antes de tocar los demás

Para Kubernetes, use actualizaciones progresivas con sondas de preparación. Para servidores tradicionales, el parámetro serial de Ansible le permite actualizar en lotes.

Lista de verificación de retroceso de emergencia

Antes de cualquier actualización significativa, sepa cómo revertir:

Para paquetes:

# Debian/Ubuntu: downgrade to specific version
apt install package=1.2.3-4

# See available versions
apt-cache policy package

Para contenedores:

# Keep previous image tagged
docker tag myapp:latest myapp:previous
docker build -t myapp:latest .

# Rollback = redeploy previous tag
docker run myapp:previous

Para bases de datos: Tome una instantánea antes de cualquier actualización de versión de base de datos. En serio. Siempre. Los retrocesos de bases de datos son dolorosos sin instantáneas.

Para VMs en la nube: Tome una instantánea de la instancia antes de actualizaciones importantes del SO. AWS, GCP y Azure lo soportan. Es un seguro barato.

Haga de los changelogs sus aliados

Cuando Dependabot o Renovate abra un PR, no lo fusione a ciegas. Dedique 60 segundos:

1. Haga clic en el enlace del changelog (generalmente en la descripción del PR)
2. Busque «BREAKING CHANGES» o «deprecation»
3. Compruebe si es una corrección de seguridad (priorice estas)

La mayoría de las actualizaciones van bien. Pero la única vez que se salte esto y rompa producción, deseará haber invertido ese minuto.

Alertas de Slack/Teams para CVEs críticos

Configure alertas automáticas para no tener que recordar comprobarlo:

Opción 1: RSS a Slack

Use IFTTT o Zapier para canalizar feeds RSS a un canal de Slack:

• CISA KEV RSS: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
• NVD RSS: https://nvd.nist.gov/feeds/xml/cve/misc/nvd-rss.xml

Opción 2: GitHub a Slack

GitHub puede enviar alertas de Dependabot a Slack mediante webhooks. Settings → Integrations → Slack → Subscribe to security alerts.

Opción 3: Integración de Snyk con Slack

Si usa Snyk, tienen integración nativa con Slack. Las nuevas vulnerabilidades en sus proyectos se publican automáticamente en su canal.

La carpeta de marcadores de «páginas de seguridad de proveedores»

Cree una carpeta de marcadores del navegador con páginas de seguridad de sus dependencias críticas. Cuando se publique un CVE importante, puede comprobar rápidamente si sus proveedores tienen actualizaciones:

• El rastreador de seguridad de su distribución Linux
• La página de seguridad de su lenguaje (Python, Node, etc.)
• Los anuncios de seguridad de su framework
• Los boletines de seguridad de su proveedor de nube

Lleva 2 minutos configurar. Ahorra 20 minutos de búsquedas durante un incidente.

Los archivos de bloqueo: el héroe olvidado

Asegúrese de que está enviando archivos de bloqueo:

• package-lock.json o yarn.lock para Node
• Pipfile.lock o poetry.lock para Python
• go.sum para Go
• Gemfile.lock para Ruby

Los archivos de bloqueo garantizan que todos instalen exactamente las mismas versiones. Sin ellos, npm install en su portátil podría obtener versiones diferentes a npm install en CI.

Dependabot actualiza los archivos de bloqueo automáticamente. Si actualiza manualmente, ejecute siempre el comando de instalación para regenerar el archivo de bloqueo.

Prueba de actualizaciones sin CI completo

Para pruebas locales rápidas de actualizaciones de dependencias:

# Create a branch
git checkout -b test-update

# Update the dependency
npm update lodash  # or pip install --upgrade package

# Run tests locally
npm test

# If tests pass, commit and push
# If tests fail, reset
git checkout -- package.json package-lock.json

Esto es más rápido que esperar a CI para cada pequeña actualización. Úselo para actualizaciones rutinarias; use CI completo para parches de seguridad.

La línea base «conocida como buena»

Mantenga un registro de qué versiones funcionan juntas. Cuando todo funcione correctamente:

# Capture working state
npm list --depth=0 > known-good-$(date +%Y%m%d).txt
pip freeze > known-good-python-$(date +%Y%m%d).txt

Al depurar problemas de actualización, puede comparar con su estado conocido como bueno para ver qué cambió.

Manejo de dependencias abandonadas

Algunas dependencias dejan de recibir actualizaciones de seguridad. Señales de abandono:

• Sin commits en más de 12 meses
• Sin respuesta a problemas de seguridad
• El mantenedor anunció el fin de vida

Para estas:

1. Compruebe si hay un fork mantenido activamente
2. Considere reemplazarla por una alternativa
3. Si debe mantenerla, audite el código usted mismo o aíslela

El ecosistema de npm tiene problemas particulares con los paquetes abandonados. Herramientas como Socket marcan específicamente estos riesgos.

Taller: configure actualizaciones y monitorización de vulnerabilidades

Reserve de 2 a 3 horas para esto.

Parte 1: Active las actualizaciones automáticas (45 minutos)

1. Audite sus servidores para ver la configuración de actualización actual
2. Active unattended-upgrades en servidores Ubuntu/Debian
3. Active dnf-automatic en servidores RHEL/CentOS/Rocky
4. Verifique que las actualizaciones automáticas están funcionando (compruebe los registros)
5. Documente los servidores en los que optó por NO activar las actualizaciones automáticas y por qué

Parte 2: Configure Dependabot (30 minutos)

1. Cree .github/dependabot.yml en sus repositorios principales
2. Configure todos los ecosistemas de paquetes relevantes
3. Active las alertas de seguridad de Dependabot en la configuración del repositorio
4. Revise los PRs existentes de Dependabot y fusiónelos o ciérrelos

Parte 3: Añada análisis de contenedores (30 minutos)

1. Añada Trivy o Snyk a un pipeline de CI
2. Configúrelo para fallar en vulnerabilidades ALTAS/CRÍTICAS
3. Analice sus imágenes actuales y documente los hallazgos
4. Corrija o documente los problemas críticos encontrados

Parte 4: Construya su proceso de monitorización de CVEs (30 minutos)

1. Documente su stack tecnológico (lenguajes, frameworks, infraestructura)
2. Suscríbase a los anuncios de seguridad de sus 5 dependencias más críticas
3. Configure un recordatorio semanal en el calendario para la revisión de CVEs
4. Cree su tabla de responsabilidades de actualización

Entregables:

• Actualizaciones automáticas activadas en todos los servidores aplicables
• Dependabot configurado para todos los repositorios
• Análisis de contenedores en al menos un pipeline de CI
• Stack tecnológico documentado
• Responsabilidades de actualización asignadas
• Revisión semanal de CVEs programada

Cómo explicárselo a la dirección

Si alguien pregunta por qué invirtió tiempo en esto:

«Configuré actualizaciones de seguridad automáticas para nuestros servidores y análisis de vulnerabilidades automatizado para nuestro código y contenedores. La mayoría de las brechas ocurren a través de vulnerabilidades conocidas y parcheadas: los atacantes escanean en busca de software desactualizado. Ahora sabremos cuándo tenemos componentes vulnerables y tenemos un proceso para parchearlos antes de que los atacantes los encuentren. Esto llevó unas pocas horas configurarlo y funciona automáticamente.»

Versión corta: «Automaticé nuestra aplicación de parches de seguridad para que no suframos una brecha por vulnerabilidades conocidas.»

Autoevaluación: ¿realmente lo hizo?

Antes de continuar, verifique que ha completado estos elementos.

Actualizaciones automáticas

• Unattended-upgrades o dnf-automatic activados en servidores
• Verificó que las actualizaciones se están ejecutando realmente (comprobó los registros)
• Documentó los servidores excluidos y por qué
• Imágenes de contenedores configuradas para reconstrucción semanal (o proceso manual documentado)

Análisis de dependencias

• Dependabot activado en los repositorios principales
• Configurado para todos los ecosistemas de paquetes relevantes (npm, pip, docker, etc.)
• PRs existentes de Dependabot revisados y procesados
• Snyk o Trivy integrado en al menos un pipeline de CI

Monitorización de CVEs

• Stack tecnológico documentado (lenguajes, frameworks, versiones)
• Suscrito a anuncios de seguridad para dependencias críticas
• Recordatorio semanal de revisión de CVEs configurado en el calendario
• CISA KEV comprobado contra su stack

Responsabilidad

• Responsabilidades de actualización asignadas para cada tipo de sistema
• Deuda de actualizaciones documentada (qué está atrasado y por qué)
• Revisión mensual de actualizaciones programada

Si puede marcar al menos 12 de estos 15 elementos, está listo para continuar.

Qué viene después

Ahora tiene visibilidad sobre sus vulnerabilidades y un proceso para parchearlas. Los huecos obvios se están cerrando automáticamente.

Próximo capítulo: seguridad del correo electrónico — SPF, DKIM, DMARC y cómo proteger a su empresa de los ataques de phishing y suplantación de identidad.