Seguridad

Lacre guarda las evidencias de control de cambios de sus clientes, así que un fallo de seguridad en la app es lo más grave que le puede pasar. Esta página dice cómo informar de uno, qué hacemos al recibirlo y qué datos guarda la app.

Cómo informar de una vulnerabilidad

Escribe a security@lacreapp.com con:

• qué has encontrado y qué permite hacer (ver o cambiar qué, y con qué cuenta o permisos de Jira);
• los pasos para reproducirlo, en tu propio sitio de Jira;
• la versión de Lacre, que se ve en la página de gestión de apps del sitio de Jira, y el navegador, si importa.

Te pedimos que:

• pruebes solo en un sitio de Jira tuyo o de prueba, con datos ficticios, nunca en el de otra organización;
• no accedas, copies ni borres datos que no sean tuyos más allá de lo necesario para demostrar el fallo, y nos digas si lo has hecho;
• no hagas pruebas de denegación de servicio ni de carga contra Jira o Forge;
• no publiques los detalles hasta que la corrección esté disponible o hayan pasado 90 días desde tu aviso, lo que ocurra antes; si necesitas más margen o menos, lo hablamos.

Un fallo de Jira, de Forge o de otra parte de la plataforma de Atlassian, y no de Lacre, se informa a Atlassian en su programa de Bugcrowd. Lacre no tiene programa de recompensas.

Qué hacemos al recibirlo

1. Acuse en 2 días laborables (de lunes a viernes, hora de Madrid), con quién lo lleva y, si ya se puede, una primera valoración.
2. Valoración de la gravedad con CVSS y, sobre todo, con lo que permite hacer con las evidencias de un cliente.
3. Corrección en estos plazos, contados desde que lo confirmamos:

Ningún plazo pasa de los de la política de corrección de Atlassian para las apps del Marketplace (10 días las críticas, 4 semanas las altas, 12 las medias y 25 las bajas).

4. Aviso: te avisamos cuando la corrección esté en producción. Si el fallo ha expuesto datos de clientes, lo comunicamos a Atlassian en 48 horas, como pide el acuerdo de partners del Marketplace, y a los clientes afectados, y lo anotamos en la página de estado. Si quieres, te nombramos en las notas de la versión.

Qué datos guarda Lacre

Lacre guarda solo lo necesario para sellar y verificar. A las personas las identifica por su identificador de cuenta de Atlassian (accountId), nunca por su nombre o su correo, y pregunta el nombre a Jira cada vez que lo enseña. Lo que sí guarda tal cual es lo que se sella de la incidencia (el resumen, la descripción, los valores de los campos elegidos) y los textos de la lista, que pueden nombrar a alguien si así se escribieron; en la lista de campos que se pueden elegir no se ofrecen los que guardan personas.

• Los sellos: el registro sellado (el estado de la incidencia que se sella, con el tipo, el resumen, el estado, las etiquetas, los componentes, las versiones, la prioridad, la resolución, la fecha de su última actualización, los campos que haya elegido quien administra el proyecto y los accountId de la persona asignada y la que informa; la lista de comprobación con quién marcó cada punto y cuándo; el riesgo, la aprobación, quién firmó y cuándo) y lo que lo acompaña (las claves y los ids de la incidencia y del proyecto, el hash, la versión de la app).
• La descripción de cada incidencia sellada, tal como estaba al sellar, aparte del registro (en él solo va su hash), hasta 200 KiB. Es contenido de la incidencia y puede llevar nombres y menciones.
• Las marcas de la lista de una incidencia aún sin sellar: qué puntos están marcados, por quién y cuándo. Se borran al sellar.
• Las alteraciones: el primer cambio que anota Lacre después de cada sello: qué campos de la incidencia cambiaron y cuándo, sin quién.
• Los ajustes de cada proyecto (la lista, los roles, los campos, el idioma, y quién los guardó por última vez y cuándo) y el registro de actividad de la página de ajustes: quién (accountId) cambió los ajustes, exportó, preparó una hoja de evidencia o borró los datos, y cuándo.
• Los borrados en curso: mientras se borran los datos de un proyecto, desde cuándo y quiénes (accountId, hasta veinte) lo siguen. Se quita al acabar el borrado.
• Los datos de la instalación: cuándo se instaló Lacre y con qué versión, sin datos personales.

Los registros técnicos de la app (los de Forge) llevan códigos de resultado, claves de proyecto y de incidencia, identificadores de sellos y de campos, recuentos y el tipo y el estado de la licencia, nunca nombres, correos ni el contenido de las incidencias.

Dónde y durante cuánto tiempo

• Dónde: en el almacén de la app en Forge, la plataforma de apps de Atlassian, separado para cada sitio de Jira que instala Lacre, en la infraestructura de Atlassian. Lacre no tiene servidores propios y no envía datos a ningún sitio fuera de Atlassian; tampoco usa analítica ni cookies. Además, cada sello se copia en una propiedad de su incidencia (lacre.seal.<hash>), que guarda Jira con la incidencia.
• Cuánto tiempo: mientras la app esté instalada, salvo que quien administra un proyecto borre sus datos desde los ajustes de Lacre. Al desinstalar, Atlassian conserva el almacén 28 días y después lo borra; las copias de los sellos en las propiedades siguen en las incidencias hasta que se borren en Jira. Borrar los datos de un proyecto deja la constancia del borrado en el registro de actividad (quién, cuándo y qué proyecto), los ajustes del proyecto (por defecto y con Lacre desactivado) y los sellos que no son solo suyos (los de incidencias que Jira da hoy en otro proyecto y los anteriores a un sello de la misma incidencia hecho en otro proyecto, para no romper su cadena), hasta que se desinstale la app.
• Quién los ve: las personas de vuestro sitio de Jira, según sus permisos. Nosotros no tenemos acceso al almacén ni a las incidencias de ninguna instalación: solo vemos los registros técnicos descritos arriba, y el soporte nunca pide acceso al sitio, contenido de incidencias ni exportaciones.

Permisos que pide

Ningún permiso para salir de Atlassian ni para administrar el sitio.

Cómo está hecha

• Cada acción de una persona comprueba en Jira, con la cuenta de quien la hace, que puede hacerla: ver la incidencia para sellar, tener el rol que el proyecto pide para sellar o aprobar, administrar el proyecto para la página de ajustes. Algunas operaciones las hace la app con su propia identidad (guardar la copia de un sello en su incidencia, anotar una alteración, saber qué incidencias son hoy de un proyecto al borrar sus datos), siempre después de comprobar a la persona cuando hay una detrás.
• Todo lo que llega del navegador o de Jira se valida antes de usarlo, y lo que se pinta en pantalla se pinta como texto.
• Las dependencias van fijadas a una versión exacta y se revisan en busca de vulnerabilidades en cada cambio y cada semana.
• Cada cambio pasa pruebas automáticas, una revisión de código y una de seguridad antes de integrarse, y cada versión se prueba en un entorno aparte antes de llegar a los clientes.
• Los sellos se pueden verificar sin Lacre: cómo se verifica un sello.