Saltar al contenido
ViWith
Avisarme
‹ Inicio

Seguridad

Divulgación responsable

Versión 1.0 · Última actualización: 30 de julio de 2026 · Chile

▲Si ya encontraste algo y quieres saltarte la lectura: escríbenos a seguridad@viwith.com con los pasos para reproducirlo. Acusamos recibo en 3 días hábiles y no emprenderemos acciones legales por una investigación hecha según esta política.

Construimos un producto de seguridad. Sería incoherente pedirle a nuestros clientes que confíen en él y, al mismo tiempo, tratar como una amenaza a quien nos avisa de una falla. Agradecemos el trabajo de la comunidad de investigación, y esta página define cómo trabajar juntos sin riesgo para ninguna de las dos partes.

01 Qué es la plataforma

Saber qué hace el producto ayuda a apuntar donde importa. ViWith detecta datos personales y secretos corporativos antes de que salgan de una organización hacia una herramienta de IA u otro destino externo. Tiene cuatro piezas:

  • Una extensión de navegador que analiza el contenido en el equipo del usuario, antes del envío.
  • Un proxy de IA que sustituye cada dato sensible por un token de ida y lo restaura a la vuelta.
  • Un SDK y una API para conectar sistemas propios del cliente.
  • Una plataforma web de cumplimiento con el dashboard, las alertas y la auditoría.

El diseño parte de que el contenido no llega a nuestros servidores: a la plataforma solo cruzan metadatos (tipo de dato detectado, acción, fecha y un hash). Todo lo que rompa esa frontera, el aislamiento entre organizaciones o el control de acceso es, para nosotros, lo más grave que nos puedes reportar.

02 Autorización expresa Ley 21.459

Esto no es una formalidad. En Chile, el artículo 2 de la Ley N.º 21.459 sobre delitos informáticos sanciona a quien accede a un sistema informático «sin autorización o excediendo la autorización» que posee, superando barreras técnicas o medidas de seguridad. Y la leyno contempla una excepción general para quien investiga vulnerabilidades: la autorización la tiene que dar el titular del sistema.

Por lo tanto, y de forma expresa: autorizamos a investigar los sistemas listados en la sección 03 a toda persona que se ajuste a esta política. Mientras te mantengas dentro de este marco:

  • Consideramos tu investigación autorizada para efectos de la Ley 21.459.
  • No iniciaremos ni apoyaremos acciones legales en tu contra, civiles ni penales, por esa investigación.
  • Si un tercero inicia acciones por una investigación que respetó esta política, declararemos públicamente que estaba autorizada.

Esta autorización cubre únicamente sistemas de nuestra titularidad. No podemos autorizarte a acceder a sistemas de nuestros clientes ni de nuestros proveedores, y no lo hacemos. Tampoco te exime de cumplir la ley en todo lo demás.

03 Alcance

Dentro del alcance:

  • viwith.com y los subdominios de nuestra titularidad.
  • La extensión de navegador y sus mecanismos de detección.
  • El SDK, la API y el proxy de IA, en sus entornos públicos o de prueba.
  • La plataforma web: autenticación, control de acceso, aislamiento entre organizaciones, dashboard y auditoría.
  • Configuración de DNS y TLS de esos dominios.

Fuera del alcance:

  • Sistemas de nuestros clientes, aunque ViWith esté desplegado en ellos, y cualquier instalación self-hosted que no sea nuestra.
  • Servicios de terceros que usamos (infraestructura, correo, DNS), aunque respondan bajo un dominio nuestro. Repórtalos a su programa correspondiente.
  • Los modelos de IA de terceros a los que el producto se conecta.

Ante la duda, pregunta antes de probar: escríbenos a seguridad@viwith.com y te respondemos.

04 Reglas de investigación

Estas reglas son la condición de la autorización de la sección 02. Quien las rompa queda fuera de ella, y actuaremos en consecuencia:

  • Detente ante datos personales. Si un hallazgo te da acceso a datos de personas reales, para de inmediato: no leas más de lo mínimo para confirmarlo, no los descargues, no los copies, no los compartas, y avísanos el mismo día. Vendemos protección de datos; una investigación que los expone nos deja peor que la vulnerabilidad.
  • No filtres, no modifiques, no borres. Accede al mínimo necesario para demostrar el hallazgo: un registro basta para probar una fuga, no hace falta la base entera.
  • No degrades el servicio. Nada de denegación de servicio, fuerza bruta masiva ni pruebas de carga.
  • Usa cuentas propias. Si necesitas una de prueba, pídela y te la damos. Nunca uses la cuenta de un cliente sin su permiso explícito y previo.
  • Sin ingeniería social a nuestro equipo, clientes o proveedores: phishing, vishing, smishing o pretexting quedan prohibidos. Tampoco accesos físicos.
  • Sin condiciones ni presión. No aceptamos reportes sujetos a pago, con plazos ultimátum ni con la amenaza de publicar para forzar una respuesta.

05 Qué nos sirve

Nos interesa sobre todo lo que rompa el aislamiento entre organizaciones, el control de acceso o el principio de que el contenido del cliente no llega a nuestros servidores: ejecución remota, inyección SQL o de comandos, XSS con impacto real, CSRF en acciones sensibles, escalada de privilegios, IDOR, fallas de autenticación o de sesión, exposición de secretos, path traversal y errores de configuración explotables.

06 Qué no consideramos vulnerabilidad

Salvo que demuestres un impacto concreto y explotable, esto no lo tratamos como hallazgo:

  • Cabeceras de seguridad ausentes o mal configuradas (incluidas HSTS y CSP) sin un ataque demostrado.
  • Configuración de SPF, DKIM, DMARC o BIMI.
  • DNSSEC y DANE.
  • Suites de cifrado TLS consideradas débiles, sin una prueba de concepto que funcione.
  • Puertos abiertos sin una vulnerabilidad asociada.
  • Self-XSS, o ataques que exigen que la víctima pegue código en su consola.
  • Clickjacking en páginas sin acciones que cambien de estado.
  • Enumeración de usuarios o correos sin impacto adicional.
  • Ausencia de límites de tasa en endpoints no sensibles.
  • Banderas de cookies faltantes en cookies que no son de seguridad.
  • Inyección en la cabecera Host sin mostrar cómo la explota un tercero.
  • Condiciones de carrera que no comprometen a usuarios, al equipo ni al negocio.
  • Divulgación de archivos o rutas públicas conocidas (robots.txt, sitemap y similares).
  • Versiones de software desactualizadas sin prueba de explotación real.
  • Resultados crudos de un escáner automático, sin análisis ni verificación manual.
  • Daño teórico, sin riesgo real demostrable.
  • Hallazgos que requieren un dispositivo ya comprometido, acceso físico o un navegador sin soporte.

07 Cómo reportar

Solo por correo, a seguridad@viwith.com. Un hallazgo por reporte, e incluye:

  • Tipo de vulnerabilidad y tu estimación de severidad.
  • La URL, el endpoint o el componente afectado.
  • Pasos para reproducirla, con el detalle suficiente para repetirla sin adivinar.
  • Prueba de concepto: petición, script, captura o video. Si incluyes enlaces, que sean accesibles sin credenciales nuestras.
  • El impacto que ves y, si tienes una idea, cómo lo mitigarías.
  • Si piensas publicarlo, en qué fecha.

Español o inglés, los dos nos sirven. Si tu reporte contiene datos sensibles (credenciales, datos personales, capturas con información de terceros), escríbenos primero sin adjuntarlos y coordinamos un canal cifrado antes de que los envíes.

Nuestros datos de contacto de seguridad también están publicados en formato legible por máquina en /.well-known/security.txt (RFC 9116).

08 Cómo procesamos tu reporte

Al recibirlo lo clasificamos, y te decimos en cuál de estos estados quedó. Sin silencios:

EstadoQué significa
IncompletoNo hay datos suficientes para evaluarlo ni reproducirlo. Te decimos qué falta.
No reproducibleNo pudimos repetirlo con lo que enviaste. Te pedimos precisiones y lo volvemos a evaluar.
No confirmadoLo intentamos y estamos razonablemente seguros de que no es una vulnerabilidad. Te explicamos por qué.
DuplicadoAlguien lo reportó antes y ya está en curso. Te avisamos cuando se corrija.
No se corregiráLo confirmamos, pero decidimos asumir el riesgo. Te decimos con franqueza el motivo.
Se corregiráConfirmado y priorizado. Te mantenemos al tanto y te pedimos que verifiques el arreglo.

La evaluación del impacto la hacemos nosotros, no el reportante. Si no estás de acuerdo, dilo: hemos cambiado de opinión antes con un buen argumento.

09 Plazos

EtapaPlazo
Acuse de recibo3 días hábiles
Clasificación en uno de los estados de la sección 0810 días hábiles
Estado del avance, mientras siga abiertoCada 15 días
Aviso de correcciónAl desplegar el arreglo

El tiempo de corrección depende de la severidad. Mantendremos tu identidad en reserva salvo que la ley nos obligue a revelarla o que tú prefieras lo contrario.

10 Divulgación coordinada

Te pedimos no publicar el hallazgo hasta que esté corregido, o hasta que acordemos una fecha. Nuestro compromiso de vuelta es no usar eso para dilatar: si a los 90 díascorridos desde tu reporte no lo hemos corregido ni acordado contigo un plazo mayor, quedas libre de publicar. Un plazo que no vence es una mordaza, y no es lo que queremos.

Cuando publiques, con gusto revisamos el borrador para verificar los detalles técnicos. Revisar no es censurar: qué publicas lo decides tú.

11 Reconocimiento

Seamos claros: hoy no tenemos un programa de recompensas económicas. Somos un equipo en etapa inicial, y prometer un pago que no podemos sostener sería peor que no ofrecerlo.

Sí está en nuestros planes abrirlo. Y cuando ocurra, los reportes que hayamos recibido hasta entonces entran en la consideración: no vamos a partir la cuenta de cero con quien ayudó antes de que hubiera algo que repartir.

Mientras tanto, lo que sí ofrecemos: crédito público con tu nombre o seudónimo, si lo quieres, en el aviso de corrección y en un agradecimiento permanente en esta página; una respuesta técnica de parte de quien arregla el problema; y aviso directo cuando el arreglo esté desplegado.

Y una puerta abierta. Si tu trabajo demuestra nivel, la conversación puede terminar en una oferta de trabajo. Acá creemos en demostrar por sobre prometer: un reporte bien hecho, con su análisis, su prueba de concepto y su propuesta de mitigación, dice más de alguien que cualquier certificado o título. Si te interesa esa conversación, dilo en el mismo correo.

12 Notas sobre reportes frecuentes

Hay dos que recibimos seguido y conviene adelantar:

  • Rotación de IP para saltarse el límite de tasa. Sí, se puede: es la naturaleza de un límite por IP, no una falla que podamos "arreglar". Tenemos protección adicional para el tráfico automatizado. Un reporte de esto no califica salvo que muestres un impacto real más allá del propio salto.
  • Claves públicas en el cliente. Las claves de API que un frontend expone por diseño, y que están pensadas para ser públicas, no son una filtración. Si crees que una de las nuestras sí otorga acceso indebido, demuéstralo y lo tomamos muy en serio.

13 Si el hallazgo involucra datos personales Ley 21.719

Si una vulnerabilidad implica acceso no autorizado a datos personales, además de corregirla nos corresponde evaluar el deber de reportarla. Con la Ley 21.719 vigente desde el 1 de diciembre de 2026, el responsable debe comunicar las vulneraciones de seguridad a la Agencia de Protección de Datos Personales sin dilaciones indebidas, y avisar a los titulares cuando haya datos sensibles involucrados. Tu reporte es la primera pieza de ese proceso: por eso pedimos que nos avises el mismo día.

ViWith

Hecho en Chile · Calibrado para la Ley 21.719

  • contacto@viwith.com
  • Reportar vulnerabilidad
  • Privacidad
  • Términos

© 2026 ViWith · El contenido analizado nunca se almacena ni sale de tu perímetro.