Tema: security
-
Vigilar la caducidad de certificados TLS en todos los endpoints, no solo en el sitio web principal
Un certificado caducado es una interrupción con un momento exactamente predecible; sondear la fecha notAfter de cada certificado realmente servido (web, API, correo, paneles internos, balanceadores de carga) desde el exterior, alertar con antelación suficiente para renovar a mano, y comprobar los intermedios además del certificado hoja.
-
Cómo comprobar si una conexión TLS negoció realmente X25519MLKEM768
Distinguir una capacidad poscuántica instalada del grupo seleccionado en una conexión TLS real mediante los detalles del navegador, OpenSSL, curl y las pruebas del lado del servidor.
-
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.
-
Corrección de vulnerabilidades KEV del kernel Linux: contrastar cada CVE con el paquete de la distribución y el kernel en ejecución
Hacer seguimiento por separado de cinco fallos del kernel explotados. Utilizar las correcciones de paquetes de cada distribución y confirmar el kernel arrancado o la cobertura explícita del parcheo en vivo; una medida de mitigación para un subsistema no resuelve los fallos de los demás.
-
Se hizo commit de un secreto: por qué no basta con borrar el archivo y cuál es el orden de respuesta
Una credencial subida a un repositorio Git persiste en el historial, en los forks, en los clones, en las cachés y en los registros de CI. Reescribir el historial reduce la exposición futura, pero no puede recuperar las copias ya hechas, así que el primer paso es revocar y rotar la credencial, luego limpiar el historial y después comprobar si se usó.
-
Permisos de archivos en Unix y la umask
Cada archivo tiene bits de permiso de lectura, escritura y ejecución para propietario, grupo y otros, además de los bits setuid, setgid y sticky; los archivos nuevos reciben sus permisos según la umask del proceso. Los secretos deben ir en archivos con modo 0600, los directorios necesitan el permiso de ejecución para poder recorrerse, y los servicios deben ejecutarse con un usuario dedicado.
-
System Integrity Protection y el Signed System Volume: qué protegen, y por qué no desactivarlos
SIP restringe incluso a root la posibilidad de modificar rutas del sistema protegidas o procesos protegidos; el Signed System Volume sella criptográficamente todo el volumen del sistema y lo verifica en cada arranque. Juntos explican por qué /usr/local es escribible pero /usr no lo es, y por qué desactivar SIP no es una solución legítima ante un error de permisos.
-
Diseñar límites de tasa que protejan el servicio e informen al cliente
Limitar según la identidad que se pueda verificar (cuenta, prefijo de red), usar contadores atómicos en ventanas fijas o deslizantes, responder con 429 y Retry-After, mantener presupuestos separados para lecturas, escrituras y registros, y publicar los límites efectivos.
-
Política de sudo como archivos independientes en /etc/sudoers.d, verificados con visudo -c
Añadir una regla acotada como su propio archivo bajo /etc/sudoers.d, validado con visudo antes de que surta efecto, mantiene la política de sudo auditable y evita que un error de sintaxis bloquee el acceso a todo el mundo. Esta metodología también trata el riesgo de las reglas NOPASSWD demasiado amplias y dónde registra sudo sus decisiones.
-
Vincular la identidad de publicación en npm y PyPI con los artefactos aprobados de cada versión
La publicación de confianza mediante OIDC elimina los tokens de publicación almacenados, pero su seguridad sigue dependiendo del flujo de trabajo autorizado. Separar la compilación de la publicación, proteger las aprobaciones y verificar la identidad del artefacto sin interpretar su procedencia como un veredicto sobre la presencia de malware.
-
Recorrido por un servicio de carga de archivos: tickets directos al almacenamiento, escaneo asíncrono y cuotas
Un recorrido de diseño para cargas que evitan los servidores de aplicación: un ticket que reserva cuota y devuelve una URL de carga firmada, un paso de finalización que verifica el objeto almacenado, un worker de escaneo que lo promueve o lo elimina, reglas de ciclo de vida para las cargas abandonadas, y un modelo de estado que explica cada objeto almacenado.
-
Prevenir cross-site scripting mediante la codificación de salida
Escapar los datos según el contexto exacto en el que se insertan (texto HTML, atributo, JavaScript, URL, CSS), usar un motor de plantillas que escape por defecto, no construir nunca HTML mediante concatenación de cadenas, y respaldarlo con una CSP estricta.
-
Cisco Secure Email Gateway y SD-WAN Manager: verificación de correcciones y conservación de pruebas de intrusión
Mantener registros de remediación separados para el escáner de correo y SD-WAN Manager. Verificar las correcciones realmente instaladas, conservar las pruebas antes de una recuperación que altere el sistema y seguir la investigación específica de cada producto.
-
Los servicios de enlaces cortos con identificadores secuenciales reciben más solicitudes de enumeración que los servicios con identificadores aleatorios
Hipótesis: un acortador de URL cuyas claves son un contador codificado en base62 permite que cualquiera recorra todos los enlaces, mientras que las claves aleatorias de longitud fija hacen que la mayoría de los intentos fallen; la propuesta es que los servicios secuenciales presentan una proporción mayor de solicitudes de claves existentes procedentes de clientes que nunca recibieron el enlace, y que la proporción de respuestas 404 no distingue entre ambos casos.
-
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.
-
La especificación Standard Webhooks frente a la cabecera HMAC de Shopify y al token de secreto compartido de GitLab
La especificación Standard Webhooks define las cabeceras webhook-id, webhook-timestamp y webhook-signature, un secreto en base64 con prefijo whsec_ cuyos bytes decodificados son la clave HMAC y una firma v1,<base64> sobre "{id}.{timestamp}.{payload}"; los tokens de firma de GitLab (GitLab 19.0, disponibilidad general en 19.1) la implementan tal cual. Shopify, en cambio, envía en X-Shopify-Hmac-SHA256 un HMAC en base64 del cuerpo sin procesar, y el antiguo X-Gitlab-Token de GitLab es un simple secreto compartido, no un HMAC en absoluto.
-
Verificar la manipulación de paquetes RPM instalados con rpm -V
rpm -V compara los archivos instalados con las sumas de comprobación, permisos y propiedad registrados en el momento de instalar el paquete, y sus códigos de salida de una sola letra indican exactamente qué cambió. Esta metodología cubre cómo leer esa salida y sus límites como comprobación de integridad.
-
La política del mismo origen: qué es un origen y qué aísla
Un origen es el esquema, el host y el puerto de una URL. Un script puede leer y modificar documentos, almacenamiento y respuestas del mismo origen; las lecturas entre orígenes se bloquean de forma predeterminada, mientras que las escrituras entre orígenes, como los envíos de formularios, y la incrustación, como imágenes y scripts, suelen estar permitidas. CORS relaja las lecturas; aun así siguen siendo necesarias las defensas contra CSRF.
-
Tras la llegada de un informe de vulnerabilidad: acusar recibo, evaluar, corregir en privado, divulgar
Una vez que un informe llega al contacto de seguridad del proyecto, el trabajo es una secuencia con fechas: acusar recibo con rapidez, clasificar (funciona como se espera, error, solicitud de función, vulnerabilidad), acordar un embargo con quien reporta, desarrollar la corrección en privado, obtener un identificador CVE y luego publicar y difundir un aviso que nombre las versiones afectadas y corregidas y reconozca a quien reportó. La guía para mantenedores de la OpenSSF y las indicaciones de divulgación de GitHub describen este proceso; este artículo lo resume para un proyecto con entre uno y cinco mantenedores.
-
Aislar en un sandbox las acciones de un agente: límites de sistema de archivos, red y credenciales
Un agente que ejecuta comandos o código debería hacerlo dentro de un límite que restrinja qué archivos puede tocar, qué hosts puede alcanzar y qué secretos puede leer; los contenedores con capacidades reducidas y un perfil seccomp, los núcleos en espacio de usuario como gVisor, una red denegada por defecto y credenciales de corta vida y alcance limitado son los componentes básicos.
Legible por máquina: JSON