Application Security Scan

Política de Privacidad

Última actualización: 31 de julio de 2026.

Estado del documento. Describe con precisión qué datos maneja la aplicación hoy y está redactada bajo el marco de la Ley 25.326 de Protección de Datos Personales de Argentina. Queda un campo marcado como [PENDIENTE] —el email/domicilio de contacto del responsable del tratamiento— para completar antes de publicarla. Si vas a tener clientes o usuarios en la Unión Europea, Brasil u otras jurisdicciones con su propia ley de protección de datos (RGPD, LGPD, etc.), esta política necesita una revisión adicional específica para esos marcos antes de ofrecerles el Servicio.

Índice

Responsable del tratamiento
Qué datos se recolectan
Finalidad y base legal
Con quién se comparte
Transferencias y proveedores externos
Retención y eliminación
Seguridad
Derechos del titular de los datos
Menores de edad
Cambios a esta política
Contacto

1. Responsable del tratamiento

El responsable del tratamiento de los datos personales recolectados a través de Application Security Scan (internamente ghscan) es [RAZÓN SOCIAL / CUIT PENDIENTE] ("el Proveedor"), en los términos de la Ley 25.326 de Protección de Datos Personales de la República Argentina.

2. Qué datos se recolectan

Dato	De dónde sale	Por qué
Datos de la organización y de la cuenta (nombre de organización, usuario, email, contraseña hasheada, rol)	Alta por autoservicio o por un administrador	Autenticación, control de acceso por rol y aislamiento entre organizaciones (multi-tenant)
Email de verificación / recuperación de contraseña	Flujo de signup y de "olvidé mi contraseña"	Confirmar la titularidad de la cuenta y permitir el restablecimiento seguro de contraseña (enlaces de un solo uso, con vencimiento)
URL del repositorio o de la aplicación (DAST)	Alta de proyecto o de aplicación DAST	Identificar qué clonar/analizar (estático) o qué URL analizar en caliente (dinámico)
Código fuente	Clonado del repo (`git clone --depth 1`)	Ejecutar el análisis estático — se clona en un directorio temporal que se borra automáticamente al terminar el escaneo; no se persiste el código en sí, solo los hallazgos que las herramientas reportan
Tokens de acceso a repos privados y a Jira propio del Cliente	Ajustes (GitHub/GitLab/Bitbucket/Jira)	Clonar repos privados / crear tickets vinculados a hallazgos — se guardan cifrados (Fernet/AES) en la base de datos, nunca en texto plano
Configuración de SSO (certificado x509 del IdP, client secret OIDC)	Ajustes → Single Sign-On (plan Enterprise)	Permitir el login contra el proveedor de identidad propio de la organización — se guarda cifrada, igual que los tokens de git host
Hallazgos y metadatos de escaneo	Resultado de Trivy, Opengrep, Gitleaks, Checkov y OWASP ZAP	Mostrar el reporte, su histórico y comparaciones entre escaneos
Estado de triage y motivo de supresión de un hallazgo	Acciones del usuario en el panel	Seguimiento de remediación; el motivo de una supresión queda registrado, no se oculta
Dirección IP	Requests al servidor	Rate limiting de login, signup, recuperación de contraseña y SSO (protección contra fuerza bruta y abuso)
Registro de auditoría (usuario, acción, fecha)	Acciones administrativas (cambios de rol, altas, tickets de soporte, etc.)	Trazabilidad interna de la organización, visible para sus administradores
Contenido de tickets de soporte/upgrade (título, descripción, organización, usuario)	Formulario "Soporte" del panel	Gestionar la solicitud — ver Sección 4 sobre a dónde se envía

3. Finalidad y base legal

Los datos se recolectan y tratan con la finalidad determinada de prestar el Servicio contratado (o su período de prueba) y con base en el consentimiento que el titular presta al registrarse y aceptar estos Términos y esta Política, conforme al art. 5 de la Ley 25.326. No se utilizan para fines distintos a los aquí descriptos, ni se venden a terceros.

4. Con quién se comparte

Hosts de repositorio (GitHub/GitLab/Bitbucket): el Servicio se conecta a ellos solo para clonar el código que el propio Cliente registró, usando el token que el Cliente configuró — no se comparten datos del Cliente con el host más allá de esa operación de clonado.
Motor de análisis estático (Opengrep/SAST): corre siempre contra un ruleset local fijo. A diferencia de su configuración por defecto, el Servicio nunca usa --config=auto, por lo que el código fuente ni ninguna métrica de uso se envía a ningún servicio de reglas de terceros para resolver el análisis.
Base de vulnerabilidades de Trivy: Trivy consulta su base pública de CVEs para poder detectar vulnerabilidades nuevas — esta consulta no incluye código fuente ni datos del repositorio, solo actualiza la base de firmas que usa localmente.
Secretos detectados (Gitleaks): nunca se muestran ni se guardan como valor real — solo la regla, el archivo y la ubicación donde se encontraron, tanto en el reporte como en la base de datos.
Jira propio del Cliente: si el Cliente configura su propia integración de Jira, los datos del hallazgo que decida vincular (título, severidad, archivo) se envían a la instancia de Jira que el propio Cliente configuró y con sus propias credenciales.
Jira del Proveedor (soporte y solicitudes de upgrade): cuando el Cliente usa el menú "Soporte" o solicita un cambio de plan, se crea un ticket en una instancia de Jira operada por el Proveedor, compartida entre todos los clientes del Servicio. Ese ticket incluye el contenido que el propio usuario escribió (título, descripción, tipo), el nombre de su organización y su nombre de usuario — nunca código fuente ni el detalle de hallazgos de seguridad.
Proveedor de identidad (SSO): si la organización activa SSO, el login se valida contra el IdP que el propio Cliente configuró (Okta, Azure AD, Google Workspace, etc.) — el intercambio se limita a la autenticación (identidad del usuario), no a datos de escaneos.
Proveedor de email (SMTP): se usa exclusivamente para enviar los correos de verificación de cuenta y de recuperación de contraseña.

5. Transferencias y proveedores externos

La infraestructura de hosting, base de datos y correo saliente puede estar operada por proveedores de infraestructura ubicados fuera de Argentina [DETALLAR PROVEEDOR/PAÍS DE HOSTING CUANDO ESTÉ DEFINIDO]. En ese caso, dicha transferencia internacional de datos se realiza conforme a lo previsto por la Ley 25.326 y la normativa de la Agencia de Acceso a la Información Pública (AAIP) sobre transferencia internacional de datos personales.

6. Retención y eliminación

El histórico de escaneos (estático y DAST) se conserva según el límite configurado en Ajustes por cada organización (por defecto, los últimos 30 escaneos por rama o entorno trackeado); al superarse ese número, se eliminan los registros más antiguos. Al eliminar un proyecto o una aplicación DAST se elimina también su histórico, reglas de supresión y estados de triage asociados. Al darse de baja una organización, sus datos se eliminan conforme al plazo de retención vigente al momento de la baja; el Cliente puede solicitar una exportación de sus datos (JSON, SARIF o PDF) antes de ese momento.

7. Seguridad

Medidas de seguridad aplicadas sobre los datos descriptos en la Sección 2:

Contraseñas de usuario almacenadas con hash, nunca en texto plano.
Tokens de acceso a repos privados, credenciales de Jira propio y secretos de configuración SSO cifrados en reposo (Fernet/AES) antes de escribirse en la base de datos.
API keys de acceso programático almacenadas solo como hash (SHA-256) — ni el Proveedor con acceso a la base puede recuperar el valor original.
Rate limiting por IP en login, signup, recuperación de contraseña y rutas de SSO, contra ataques de fuerza bruta.
HTTPS forzado configurable (con header HSTS y cookie de sesión marcada Secure) cuando el despliegue corre detrás de un proxy con TLS.
Aislamiento estricto de datos entre organizaciones a nivel de cada endpoint de la API.
Ningún hallazgo de secretos (Gitleaks) incluye el valor real detectado, en ningún lugar del sistema.
Los escaneos DAST en modo Full Scan requieren confirmación explícita de autorización antes de ejecutarse (ver Términos de Servicio, Sección 8).

8. Derechos del titular de los datos

Conforme a la Ley 25.326, el titular de los datos personales tiene derecho a acceder, rectificar, actualizar y solicitar la supresión de sus datos personales, de forma gratuita, en los intervalos que la ley establece. Dentro del Servicio, cualquier usuario admin de una organización puede ejercer estos derechos sobre los datos de su organización directamente desde el panel (exportación vía JSON/SARIF/PDF, eliminación de proyectos, usuarios o de la organización completa) o escribiendo al contacto de la Sección 11. El titular de los datos tiene además derecho a presentar una reclamación ante la Agencia de Acceso a la Información Pública (AAIP), autoridad de control en materia de protección de datos personales en Argentina, si considera que sus derechos no fueron respetados.

9. Menores de edad

El Servicio está dirigido a organizaciones y profesionales, y no está destinado a menores de edad. No se recolectan intencionalmente datos de menores.

10. Cambios a esta política

Esta política puede actualizarse para reflejar cambios en el Servicio o en la normativa aplicable. Los cambios materiales se notificarán con razonable anticipación (por email a la cuenta administradora, o aviso en el panel).

11. Contacto

Consultas sobre esta Política o para ejercer los derechos de la Sección 8: [EMAIL DE CONTACTO DE PRIVACIDAD PENDIENTE].