¿Es Raisetalk seguro? Lo que medimos, corregimos y publicamos

Una base sana ayer ya no lo es hoy

Un software no se degrada porque se toque. Se degrada porque el mundo a su alrededor se mueve. No ha modificado una línea de código en tres semanas y, sin embargo, su producto quizá sea vulnerable esta mañana: acaba de publicarse una CVE sobre una dependencia transitiva que nunca eligió explícitamente, la imagen base de su contenedor incorpora una biblioteca de sistema que acaba de quedarse sin soporte, un binario entregado por un proveedor integra una versión congelada en tiempo de compilación de una biblioteca de terceros, un ajuste cloud que hace un año se consideraba aceptable se ha convertido en una mala práctica documentada.

El ritmo de publicación de vulnerabilidades supera hoy el centenar diario, sumando todos los fabricantes. A ese ritmo, la pregunta pertinente para evaluar a un proveedor no es «¿están ustedes certificados?». Es: ¿qué ocurre en su casa entre el instante en que se publica una vulnerabilidad y el instante en que queda corregida? Cuánto tiempo, mediante qué mecanismo, con qué prueba, y quién decide que está corregida.

Esa pregunta nos concierne especialmente. Raisetalk trata grabaciones de llamadas, transcripciones y datos personales de clientes finales que nunca han oído hablar de nosotros: simplemente llamaron a su banco, a su aseguradora o a su compañía energética. La confianza que se nos otorga es una confianza delegada, y ese tipo de confianza se demuestra en lugar de declararse.

Por eso este artículo describe la mecánica, no la intención. Lo que medimos, con qué frecuencia, qué ocurre cuando salta una alerta, qué publicamos y, por último, cómo se compara este enfoque con las otras dos respuestas clásicas del mercado: la certificación y el test de intrusión.

Lo que analizamos, de forma permanente

Nos apoyamos en Aikido Security como plataforma de análisis y protección. La razón de esa elección es sencilla: la cobertura. Muchas herramientas hacen muy bien una cosa, el análisis estático del código o el control de la postura cloud. El problema es que un atacante no elige su puerta de entrada según cómo esté repartido su instrumental. Una clave de API olvidada en un archivo de configuración, una CVE en un paquete de sistema de una imagen de contenedor y un rol IAM demasiado amplio en una cuenta de servicio le valen exactamente igual.

Seis superficies se vigilan, por tanto, de forma continua.

Este último punto merece una precisión, porque rara vez se hace. Un escáner que se detiene en la página de acceso solo analiza el escaparate. Por eso hemos abierto al escáner un acceso autenticado a la API, para que explore también lo que hay detrás de la autenticación, allí donde están las rutas que manipulan realmente los datos. Resulta más incómodo, ya que genera mecánicamente más hallazgos. Precisamente por eso es útil.

Lo que protege mientras el código se ejecuta

Analizar es encontrar lo que podría ser explotado. Proteger es detener lo que está siendo explotado. Lo uno no sustituye a lo otro, y utilizamos dos componentes distintos para la segunda mitad del trabajo.

Un cortafuegos aplicativo integrado en la API. Zen no se ejecuta delante de la aplicación como un WAF clásico situado en el frontal: se ejecuta dentro del proceso de la aplicación, lo que le da acceso a un contexto que el frontal no tiene. No ve solo una cadena sospechosa en una petición HTTP, ve la consulta SQL realmente construida, el comando realmente ejecutado, la ruta de archivo realmente abierta. Puede distinguir así una cadena que se parece a una inyección de otra que efectivamente produce una. En nuestro caso funciona en modo bloqueo desde el otoño de 2025, y no en simple observación: un intento detectado se interrumpe, no solo se registra.

Es una decisión que tiene un coste, y conviene decirlo: un cortafuegos en modo bloqueo puede, en teoría, interrumpir una petición legítima. Lo asumimos, y por eso las actualizaciones de versión de este componente se tratan con la misma prudencia que un cambio funcional, comprobando qué modifican en las decisiones de bloqueo antes de desplegarlas.

El control de los puestos de trabajo. El segundo componente afecta a nuestras propias máquinas, aquellas desde las que desarrollamos y administramos la producción. Cifrado del disco, bloqueo de sesión, actualizaciones del sistema, antivirus activo: estos controles se verifican de forma continua en cada puesto. No es cumplimiento decorativo. Una plataforma intachable administrada desde un portátil sin cifrar y olvidado abierto en un tren sigue siendo una plataforma vulnerable, y quien ataca a un fabricante de software rara vez empieza por el producto.

Qué ocurre cuando salta una alerta

Aquí se juega la diferencia entre una plataforma de análisis comprada y una práctica de seguridad real. Una herramienta que reporta doscientas alertas produce doscientas alertas. No produce seguridad. La seguridad empieza en la etapa siguiente, la que nadie enseña en una demostración.

Nuestro proceso está escrito y se sigue cada vez en el mismo orden.

1. La agrupación por causa raíz. Un grupo de treinta y seis hallazgos casi nunca son treinta y seis problemas. A menudo es una sola línea en un archivo de bloqueo de dependencias, proyectada sobre tres imágenes de contenedores y dos repositorios. El primer paso consiste, pues, en separar la causa raíz única de las superficies afectadas, y en decir cuántas correcciones distintas hacen falta realmente. Eso evita confundir el volumen de alertas con la carga de trabajo, y tratar de urgencia treinta y seis síntomas en lugar de un problema.

2. La apertura de un ticket, con su plazo. Cada grupo tratado da lugar a un ticket en el repositorio correspondiente, con su severidad y su plazo de resolución. Nada vive únicamente en un panel: lo que no tiene ticket no tiene responsable, y lo que no tiene plazo no tiene prioridad.

3. La verificación en nuestro propio código. Es la etapa que el escáner no puede hacer por nosotros. Una CVE anunciada sobre una biblioteca no dice si el código vulnerable es alcanzable desde el nuestro. Vamos a leer los archivos afectados, a confirmar la versión realmente instalada, la restricción realmente declarada y quién la invoca de verdad. Una vulnerabilidad de tipo SSRF en una función que nunca llamamos no tiene la misma urgencia que una deserialización alcanzable desde una ruta pública. Esta verificación produce a veces la conclusión inversa a la alerta: falso positivo, código muerto o corrección ya aplicada. En ese caso, la decisión queda registrada con su motivo, nunca mediante un archivado silencioso.

4. La corrección, y todo lo que la acompaña. Un plan de remediación no se detiene en el cambio de versión. Incluye explícitamente las etapas fuera del código: reconstrucción de la imagen, rotación de un secreto, reescritura del historial si una credencial ha quedado expuesta, reinicio del servicio afectado. Un secreto retirado del código fuente pero todavía válido en el proveedor no es un secreto corregido.

5. La verificación tras el despliegue, y luego el cierre por una persona. Comprobamos que la corrección está efectivamente presente en lo que se ejecuta, y no solo en lo que se ha subido al repositorio. Una imagen reconstruida pero no desplegada, un tráfico que sigue fijado a la revisión anterior tras una vuelta atrás: estas desviaciones son clásicas, y convierten una corrección en la ilusión de una corrección. Solo entonces un ser humano cierra el ticket.

La base de fortificación, en detalle

Una mecánica de detección solo vale lo que vale la base sobre la que se aplica. He aquí, sin ánimo de exhaustividad, los principios que rigen hoy la infraestructura de Raisetalk. No son declarativos: cada uno se verifica de forma continua mediante los análisis descritos más arriba, y cualquier desviación se convierte en una alerta.

• Ningún contenedor se ejecuta con privilegios de administrador. Tanto los procesos maestros como los procesos de trabajo se ejecutan bajo una cuenta sin privilegios, y los servicios escuchan en puertos no privilegiados.
• Las imágenes no contienen ningún binario con bit SUID, y un control hace fallar la construcción de la imagen si aparece alguno. Una etapa de instalación añadida más adelante podría reintroducir uno sin que nada lo señalara: una fortificación que no se vigila a sí misma se pierde siempre en la siguiente actualización.
• El arranque seguro está activo en las máquinas virtuales, de modo que la cadena de arranque se verifica antes de que el sistema se cargue.
• El acceso de administración pasa por la identidad, nunca por una clave compartida. Autenticación mediante la identidad cloud, claves SSH de proyecto bloqueadas, acceso a las máquinas por túnel autenticado en lugar de exponer un puerto de administración.
• Cada servicio se ejecuta con una cuenta dedicada, limitada a los permisos que realmente necesita, y nunca con una cuenta por defecto: estas últimas llevan, por construcción, roles demasiado amplios.
• La base de datos impone ella misma el cifrado de las conexiones, en lugar de dejarlo a la buena voluntad del cliente que se conecta.
• El sitio público aplica una política de seguridad de contenido estricta, hasta prohibir los estilos en línea: una restricción real para quien escribe los componentes, y una superficie de inyección menos.

Ninguno de estos puntos es espectacular por separado. Es su combinación, y sobre todo el hecho de que se verifiquen de forma permanente y no una sola vez en la instalación, lo que constituye el trabajo real.

Dónde estamos, a 19 de agosto de 2026

En la fecha de publicación de este artículo, el panel no presenta ninguna alerta abierta en todo el perímetro. Los informes de cumplimiento generados por la plataforma arrojan los siguientes resultados.

La plataforma sitúa además a Raisetalk entre el 5 % de aplicaciones mejor protegidas de su parque. Es una comparación relativa facilitada por un tercero, y como tal la citamos.

La transparencia: el informe, bajo petición

Un proveedor que afirma que todo va bien le pide que le crea. Preferimos dejarle mirar.

El distintivo presente en el pie de todas las páginas de este sitio abre un formulario de solicitud de acceso al informe de auditoría de seguridad. El informe se genera a partir del estado real de la plataforma en el momento de la solicitud, y no a partir de un documento fijo redactado de una vez por todas: es la misma fuente que produce las cifras anteriores.

¿Por qué bajo petición y no en acceso libre? Porque un informe de seguridad describe un perímetro técnico, y saber a quién se comunica forma parte de la higiene elemental. El formulario es breve y la solicitud se tramita con rapidez.

Es también, para nosotros, un compromiso unilateral. Publicar un distintivo que da acceso a una medida independiente de nuestro estado de seguridad significa aceptar de antemano que un mal mes quede a la vista. Es precisamente lo que hace útil la información el resto del tiempo.

Los otros enfoques, y por qué llegan después

Dos respuestas dominan el mercado cuando un comprador plantea la cuestión de la seguridad. Ambas son legítimas, y ambas resultan insuficientes por sí solas. Nuestra posición se resume en una palabra: el orden.

La certificación ISO 27001

ISO/IEC 27001 certifica un sistema de gestión de la seguridad de la información. Un organismo acreditado comprueba que ha identificado sus riesgos, definido medidas, documentado sus procedimientos y que mantiene vivo el conjunto. El certificado tiene una validez de tres años, con auditorías de seguimiento anuales. Es un trabajo serio, que estructura de forma duradera una organización, y es una señal fuerte para un comprador.

Sus límites derivan de su propia naturaleza, y no tienen nada de polémico. La auditoría procede por muestreo, en una fecha determinada. Valida un sistema de gestión, no el estado técnico de su producto en el instante en que su cliente potencial lee el certificado. Nada en un certificado obtenido en marzo le informa sobre la vulnerabilidad crítica publicada en octubre en una dependencia de la aplicación. El certificado acredita que la organización dispone de un proceso para tratarla, lo que es muy distinto de acreditar que la ha tratado.

Es una fotografía, tomada por un profesional, con un excelente equipo. Sigue siendo una fotografía.

El test de intrusión (pentest)

El test de intrusión aporta lo que ningún escáner sabe producir: la inteligencia de un atacante humano. Encadenar tres debilidades individualmente menores para obtener un acceso que no debería existir, desviar una lógica de negocio perfectamente conforme al código, acceder al objeto de otro cliente manipulando un identificador: eso no se detecta mediante análisis de patrones.

Sin embargo, su límite es presupuestario, y es estructural. Se compra un número de días, luego se define un perímetro. Todo lo que queda fuera del perímetro no se prueba, y el informe a menudo no lo dirá, o lo dirá en letra muy pequeña... Describirá lo que se ha encontrado allí donde se ha buscado. Como la certificación, el test vale para una fecha, una versión y sobre todo un perímetro limitado. El despliegue del mes siguiente invalida una parte.

Los tres enfoques, uno al lado del otro

Estas tres columnas no se sustituyen entre sí. Se complementan, en ese orden. Certificarse sin disponer de control continuo es documentar limpiamente un proceso que no se sabe ejecutar. Encargar un test de intrusión sobre un perímetro donde quedan dependencias vulnerables conocidas es pagar a precio de experto el descubrimiento de lo que un escáner encuentra gratis en una noche. Y encargarlo sobre un perímetro estrecho, elegido precisamente porque ya se domina, es comprar una buena noticia en lugar de una información: queda decidida en el momento en que se redacta el perímetro, no en el momento del test. Un test de intrusión útil es aquel cuyo perímetro se ha elegido por su dificultad, y cuya extensión se comunica junto con la conclusión.

Nuestra secuencia es, por tanto, esta: primero la medida permanente y la corrección sistemática, porque es lo que protege realmente los datos de nuestros clientes hoy. Se contempla una certificación ISO 27001 para más adelante, y un test de intrusión externo figura en nuestra hoja de ruta: vendrán a validar y completar unos cimientos existentes, no a sustituirlos ni a hacer sus veces.

Lo que el control continuo no sustituye

Sería deshonesto terminar sin decir dónde se detiene lo que aquí describimos.

Una plataforma de análisis no conoce su negocio. Sabe que una consulta SQL se construye por concatenación. No sabe que un usuario de un equipo nunca debe ver las evaluaciones de otro equipo. Esas reglas son propias de nuestro producto, y ninguna base de vulnerabilidades las contiene. Por eso mantenemos internamente nuestro propio modelo de amenazas: las unidades de despliegue, las superficies de entrada, las fronteras de confianza y las reglas de negocio que nunca deben ceder. Se revisa y se actualiza como si fuera código, y sirve de mapa cuando buscamos aquello que ninguna herramienta buscará en nuestro lugar.

Una puntuación de cumplimiento no es una garantía. Indica que no queda ningún problema conocido en el perímetro observado. Es valioso, y no dice nada de las vulnerabilidades que todavía no son públicas. Nadie puede prometer lo contrario, y conviene desconfiar de quien lo hace.

La seguridad sigue siendo una cadena. Incluye a nuestros subcontratistas, a nuestros proveedores de modelos de IA, al alojamiento y al uso que sus propios equipos hacen de la plataforma. Por eso mismo el control de acceso por roles y perímetros y la seudonimización de los datos personales forman parte del mismo asunto que las vulnerabilidades: determinan qué sigue protegido el día en que algo cede en otro punto.

La última palabra

Podríamos haber escrito un artículo corto: «cero vulnerabilidades, trece marcos, 5 % superior». Habría sido exacto, y no habría probado nada. Las cifras que cuentan en seguridad no son las que se exhiben, son las que se pueden explicar: de dónde vienen, qué cubren, qué dejan fuera y qué ocurre el día en que se degradan.

La seguridad de un software no es un estado, es un ritmo. No se demuestra con un documento anual, sino con la capacidad de tratar, semana tras semana, lo que la medición saca a la luz, incluso cuando resulta incómodo, incluso cuando obliga a reconstruir una máquina o a retocar un componente que funcionaba perfectamente.

Y porque la afirmación de un proveedor nunca vale tanto como la verificación de un comprador: el informe está al pie de esta página.

Compruébelo usted mismo

• Solicitar el informe de auditoría de seguridad: acceder al formulario, o hacer clic en el distintivo del pie de página.
• Nuestras respuestas sobre los datos y el RGPD: las preguntas frecuentes
• Plantearnos una pregunta concreta: www.raisetalk.com/es/contact

Las cifras citadas en este artículo corresponden al estado constatado el 19 de agosto de 2026. Evolucionan: en eso reside precisamente su interés. Un panel de seguridad que no se ha movido en seis meses no es señal de un producto estable, es señal de una medición detenida. La buena pregunta que hay que hacer a un proveedor, incluidos nosotros, no es «¿su puntuación es buena hoy?». Es «¿qué ocurre en su casa el día en que deja de serlo?».