Política de seguridad y respuesta a incidentes de Impediment Ledger for Jira

Última actualización: 2026-10-12

1. Ámbito

Esta política abarca la app de Atlassian Forge Impediment Ledger for Jira (la «App») y las cuentas, el equipo de trabajo y los repositorios que se usan para desarrollarla y publicarla. La mantiene PR Flow, nombre comercial de Árpád Kozma, empresario individual (egyéni vállalkozó) (el «Editor», «nosotros»).

PR Flow es una empresa unipersonal. Esta política recoge los controles que están realmente implantados y los pasos que seguimos cuando algo falla. Se adoptó el 2026-10-13 y se revisa al menos una vez al año y después de cada incidente de seguridad.

El tratamiento de los datos por la App se describe en el aviso de privacidad; las obligaciones de seguridad frente a los clientes figuran en la sección 11 del Contrato de licencia de usuario final.

Esta política está redactada en inglés, y prevalece la versión inglesa. Las traducciones se facilitan únicamente a título informativo.

2. Cómo informar de una vulnerabilidad

Informa de las vulnerabilidades de forma privada a [email protected], no en un canal público. Es también el contacto de seguridad que figura en la ficha de Marketplace de la App.

3. Cuentas y acceso

  • Todas las cuentas que se usan para la App tienen autenticación multifactor: GitHub, Google Workspace, la cuenta de Atlassian y la cuenta de alojamiento del sitio web.
  • Las contraseñas son únicas y se guardan en un gestor de contraseñas.
  • Solo el propietario tiene acceso al código fuente, a la app de Forge, al Developer Space y a la cuenta de partner de Marketplace. Los accesos se revisan cada trimestre (colaboradores, miembros del Developer Space, colaboradores de GitHub y tokens de despliegue) y se elimina todo lo que no sea necesario.
  • El token de despliegue de Forge se guarda únicamente en un entorno protegido de GitHub. Se renueva una vez al año, o de inmediato si se sospecha que ha quedado expuesto.

4. Equipo de trabajo

  • El equipo de desarrollo utiliza cifrado completo del disco, actualizaciones automáticas del sistema operativo y de las aplicaciones, y protección contra software malicioso.
  • No se usan versiones del sistema operativo sin soporte para el desarrollo ni para los despliegues.

5. Desarrollo y gestión de cambios

  • Cada cambio pasa, antes de subirse, comprobaciones de tipos, lint (incluidas reglas de seguridad y de detección de secretos), las baterías de pruebas unitarias, basadas en propiedades y de sistema, y una auditoría de dependencias. Las comprobaciones más largas (pruebas exhaustivas, una ejecución completa de pruebas de mutación, auditorías) se ejecutan antes de cada versión.
  • Los despliegues en producción solo se hacen desde una etiqueta de versión de la rama principal, mediante un flujo de despliegue automatizado.
  • El OWASP Top 10 y el OWASP Application Security Verification Standard (ASVS) 5.0 son la referencia del modelo de amenazas de la App.
  • Las dependencias se instalan solo desde un archivo de bloqueo, con una antigüedad mínima de publicación para los paquetes nuevos. Las actualizaciones las gestionan Renovate y Dependabot, la CI falla ante vulnerabilidades conocidas de gravedad alta o superior en las dependencias que se distribuyen con la App, y cada versión tiene una lista de materiales de software (SBOM) CycloneDX.
  • La App no necesita secretos propios; no hay ninguno guardado en el código ni en el repositorio.

6. Datos

  • La App se ejecuta en Atlassian Forge sin tráfico de salida externo (external egress). Los datos del cliente permanecen en el almacenamiento alojado de Forge del sitio de Atlassian del cliente; el Editor no tiene acceso a ellos.
  • Las acciones que un usuario realiza en la App se ejecutan con sus propios permisos de Jira, y cada resultado que se le muestra se filtra según lo que ese usuario puede ver.
  • Los registros no contienen datos personales, credenciales ni tokens; solo se registran campos estructurados permitidos.
  • El código fuente y su historial se guardan en GitHub; la App puede reconstruirse y volver a desplegarse desde cualquier etiqueta de versión.

7. Respuesta a incidentes

Seguimos las app security incident management guidelines de Atlassian:

  • Detectar y registrar. Anotar qué se observó, cuándo y qué puede verse afectado (la App, cuentas, tokens, sitios de clientes).
  • Contener. Revocar o renovar los tokens y contraseñas expuestos, desactivar la función afectada o volver a la última versión correcta, y suspender los despliegues hasta conocer la causa.
  • Notificar. Avisar a Atlassian a través del portal de soporte Developer and Marketplace en un plazo de 48 horas desde que tengamos conocimiento de un incidente que afecte a clientes o a sus datos, y avisar a los clientes afectados sin demora indebida, con la plantilla de comunicación de incidentes de Atlassian.
  • Corregir y verificar. Corregir la causa, añadir una prueba de regresión y publicar pasando por las comprobaciones habituales.
  • Revisar. Dejar por escrito qué ocurrió y qué cambia, y actualizar esta política.

El plan se repasa una vez al año como ejercicio de simulación, con un token expuesto y un informe de vulnerabilidad como escenarios.

8. Continuidad

  • La App se ejecuta en Atlassian Forge; no hay servidores de PR Flow que restaurar.
  • Si se pierde el equipo de trabajo, el código se restaura desde GitHub, las cuentas se recuperan con códigos de recuperación multifactor guardados sin conexión y se renueva el token de despliegue.

9. Contacto

Informes de seguridad: [email protected]. Otras preguntas: soporte.