Tema: compliance
-
Registros de auditoría: qué registrar, cómo mantenerlos íntegros y quién puede leerlos
Un registro de auditoría responde quién hizo qué a qué objeto, cuándo y con qué resultado; lo escribe la aplicación para cada acción relevante para la seguridad, se mantiene separado de los logs de depuración, se protege contra alteraciones trasladándolo con prontitud a almacenamiento de solo anexado o de escritura única, y se lee solo bajo un acceso registrado y restringido.
-
Preparación del proceso de gestión de vulnerabilidades de un fabricante conforme al CRA: recepción, pruebas y plazos de notificación
Una propuesta de protocolo de preparación vincula la recepción de avisos de vulnerabilidades y los registros de componentes con la decisión de notificar conforme al CRA. Separa la obligación de notificación ya aplicable en 2026 de los requisitos más amplios de gestión de vulnerabilidades aplicables en diciembre de 2027.
-
Comprobar el ciclo de vida de soporte de un sistema operativo antes de automatizar sobre él
Automatizar flujos de parcheo, actualización o cumplimiento sobre un host que ya superó su fin de vida genera una confianza falsa: ya no llegarán más correcciones de seguridad, independientemente de lo que informe la automatización. Esta metodología indica dónde publica cada fabricante principal sus fechas de ciclo de vida y cómo incorporar una comprobación de fin de vida como paso previo.
-
Elegir una licencia de código abierto
Las licencias permisivas (MIT, Apache-2.0) permiten la reutilización con atribución; las licencias copyleft (GPL, AGPL) exigen que los trabajos derivados sigan siendo abiertos; Apache-2.0 añade una concesión de patente. La elección depende de lo que se quiera permitir hacer a quienes usen el código más adelante, comprobando la compatibilidad con las dependencias.
-
Listas de materiales de software con SPDX y CycloneDX
Un SBOM es un inventario legible por máquina de los componentes de un artefacto de software; SPDX y CycloneDX son los dos formatos de uso extendido, y generar uno por cada versión respalda la coincidencia de vulnerabilidades y la revisión de licencias.
-
Notificaciones del CRA desde septiembre de 2026: supuestos, plazos y plataforma única de notificación
El CRA exige a los fabricantes notificar las vulnerabilidades de productos explotadas activamente y los incidentes graves de seguridad de productos. Ambos tienen etapas de 24 y 72 horas, pero el plazo de sus informes finales comienza en momentos distintos.
-
Listas de materiales de software (SBOM): el inventario de la propia cadena de suministro
Una lista de materiales de software enumera de forma legible por máquina qué componentes, en qué versión, forman parte de un artefacto entregado. SPDX (ISO/IEC 5962:2021) y CycloneDX (OWASP) son los formatos más extendidos; se genera por versión a partir del artefacto compilado, se guarda junto a él y se usa para contrastarla con los avisos de vulnerabilidades y las obligaciones de licencia. Junto con las pruebas de procedencia (SLSA), hace verificable la cadena de suministro.
-
CIS Benchmarks y DISA STIG como base de hardening: qué son y cómo aplicarlos de forma selectiva
Los CIS Benchmarks y las DISA STIG son dos conjuntos de recomendaciones de configuración mantenidos de forma independiente; ambos ofrecen niveles de perfil seleccionables en lugar de un único objetivo fijo. Aplicar un perfil completo sin registrar las excepciones es una forma habitual de que el trabajo de hardening interrumpa un servicio en producción.
-
Notificación de ciberataques en Suiza y CRA: distintas obligaciones para operadores y fabricantes de productos
La obligación suiza de notificación para infraestructuras críticas abarca los ciberataques que cumplen los criterios de notificación y afectan a operadores sujetos a la norma. El CRA se refiere a fabricantes que suministran productos al mercado de la UE, incluidos los suizos; la similitud de los plazos iniciales no hace intercambiables los destinatarios ni los supuestos de notificación.
-
CRA y código abierto: diferencias entre colaboradores, fabricantes y administradores de software de código abierto
Una licencia de código abierto no determina por sí sola las obligaciones del CRA. El reglamento distingue el suministro comercial de productos, las contribuciones a software ajeno a la responsabilidad del colaborador y el apoyo sostenido de los administradores de software de código abierto, cuyas obligaciones del artículo 24 comienzan en diciembre de 2027.
-
Análisis de un host Linux frente a una línea base con OpenSCAP
oscap xccdf eval ejecuta un perfil de SCAP Security Guide contra un host en funcionamiento o una imagen sin conexión y genera un informe legible; revisar el script de remediación generado antes de ejecutarlo evita que un análisis automatizado acabe en una caída automatizada.
Legible por máquina: JSON