Política de Seguridad
SPHIOR Ledger for Jira
Esta Política de Seguridad describe cómo SPHIOR ("nosotros") protege SPHIOR Ledger for Jira (la "App") y los sistemas que respaldan su desarrollo y operación. Para conocer cómo tratamos los datos, consulte nuestra Política de privacidad en https://ledger.sphior.com/privacy.
1. Arquitectura y protección de datos
SPHIOR Ledger está construida sobre Atlassian Forge y es elegible para el programa Runs on Atlassian. · Cero egress de red saliente. El manifest de la App no declara hosts externos; todo el procesamiento ocurre dentro del runtime de Forge gestionado por Atlassian. · Almacenamiento aislado por tenant. Todos los datos persistentes residen en Forge Storage (per-install SQL), dentro de su tenant Atlassian. No operamos base de datos externa, log shipper ni endpoint de analytics. · Sin sub-procesadores de terceros. La App no tiene ninguno. · Cifrado en tránsito: TLS 1.2+ para cada llamada de API, aplicado por la plataforma Forge de Atlassian. · Cifrado en reposo: Forge Storage está cifrado por Atlassian. Consulte el Trust Centre de Atlassian en https://www.atlassian.com/trust para controles a nivel de plataforma.
2. Libro mayor a prueba de manipulaciones
El libro de auditoría de la propia App está protegido por una cadena de hashes SHA-256. Cada snapshot referencia el hash del registro anterior; las ediciones silenciosas al ledger rompen la cadena y se exponen en el verificador de integridad in-app. Los clientes pueden verificar de forma independiente el contenido de cada pack mediante las firmas incluidas en cada evidence pack exportado.
3. Gestión de vulnerabilidades y desarrollo seguro
· Análisis de seguridad automatizado. Dado que la auditoría de seguridad web (DAST/SAST/SCA autenticado) es el negocio principal de SPHIOR, ejecutamos SAST (análisis estático de código), SCA (escaneo de dependencias / open-source) y DAST autenticado contra las superficies accesibles de la App de forma regular (al menos trimestralmente y antes de releases significativas). · Software bill of materials (SBOM). Las dependencias están fijadas mediante lockfiles; se mantiene un SBOM que se revisa en cada release. · Plazos de remediación. Los hallazgos de los escaneos se triagan y remedian bajo plazos definidos, alineados con la Marketplace Security Bug Fix Policy de Atlassian (los problemas críticos se priorizan para la release más temprana posible). · Parcheo de runtime. El runtime de Forge, el motor Forge SQL y Forge Storage son mantenidos por Atlassian; adoptamos prontamente las actualizaciones de runtime recomendadas por Atlassian y no ejecutamos versiones de runtime no soportadas. · Análisis estático y revisión. TypeScript en modo strict, ESLint y forge lint se ejecutan en cada commit; los cambios se revisan por pares antes del merge a la rama main. · Sin secretos en el código fuente. Los repositorios no contienen credenciales, tokens ni secretos compartidos; la App no solicita PATs ni contraseñas del usuario final, y Forge gestiona todos los tokens de plataforma. · Pruebas de penetración. Realizamos pruebas de seguridad autenticadas internas; las pruebas de penetración independientes por terceros están en nuestro roadmap.
4. Respuesta a incidentes de seguridad
Ante un incidente de seguridad confirmado que afecte a la App: 1. Triage iniciado dentro de las 24 horas tras la confirmación. 2. Notificación al cliente enviada por email a la dirección contact-for-security-issues registrada para las instalaciones afectadas, dentro de las 72 horas tras la confirmación de impacto material, alineada con las expectativas del Artículo 33 del GDPR. 3. Análisis de causa raíz y plan de remediación. Los arreglos con impacto en clientes se publican en Atlassian Marketplace a través del pipeline estándar de actualización. 4. Informe post-incidente compartido con los clientes afectados y resumido públicamente en esta página cuando proceda. Los eventos de seguridad sospechosos pueden reportarse a security@sphior.com en cualquier momento. Acusamos recibo dentro de un día hábil.
5. Controles de acceso (interno)
· Privilegio mínimo. El acceso a los repositorios de código, la Atlassian Developer Console y el despliegue en producción se restringe a los mantenedores de la App según el principio de necesidad de conocer. No utilizamos cuentas compartidas ni credenciales de producción compartidas. · Repositorio de código. La rama main está protegida con status checks requeridos (TypeScript, lint y las pruebas deben pasar antes del merge). · Developer Console. El acceso se restringe a la cuenta de publicador (founder@sphior.com) y utiliza autenticación a nivel de cuenta Atlassian con autenticación multifactor (MFA) habilitada. · Autenticación multifactor. Se exige MFA en todas las cuentas con acceso al código fuente, la Developer Console y las herramientas de despliegue. · Revisión periódica de accesos. La lista de cuentas con acceso a los sistemas de desarrollo y despliegue se revisa al menos trimestralmente, y el acceso se revoca prontamente cuando deja de ser necesario. · El despliegue en producción se realiza mediante la Atlassian Forge CLI; no se utilizan credenciales de producción compartidas.
6. Cumplimiento y certificaciones
Estado de cumplimiento: · Obligaciones de Data Processor del GDPR: adoptadas (véase Política de privacidad §10). · Obligaciones de Service Provider del CCPA: adoptadas (sin venta de información personal; procesamiento limitado a fines comerciales). · Programa Runs on Atlassian: elegible. · SOC 2 Type II: roadmap (post-lanzamiento). · ISO 27001: roadmap (post-lanzamiento). · HIPAA: no certificada — la App no está pensada para almacenamiento de PHI. Actualmente no contamos con certificaciones SOC 2 ni ISO 27001. La elegibilidad de la App en Runs on Atlassian hereda las certificaciones a nivel de plataforma de Atlassian para la infraestructura subyacente; los clientes que requieran nuestras propias certificaciones pueden contactarnos sobre el calendario del roadmap.
7. Divulgación responsable
Damos la bienvenida a investigación de seguridad sobre la App. Por favor reporte hallazgos en privado a security@sphior.com incluyendo: · Descripción del problema · Pasos para reproducir · Evaluación del impacto · Mitigaciones sugeridas Nos comprometemos a: · Acusar recibo de su reporte en 1 día hábil · Proporcionar una decisión inicial de triage en 5 días hábiles · No emprender acciones legales contra investigadores de buena fe que sigan esta política La participación en el Atlassian Marketplace Security Bug Bounty Program es un ítem del roadmap; hasta nuestra inscripción, por favor divulgue directamente a nosotros.
8. Controles de seguridad del lado del cliente
La App se administra a través de la interfaz de administración existente de Jira y hereda la autenticación, autorización y audit-log de Jira. Recomendamos encarecidamente: · Restringir permisos de administrador de Jira a un conjunto mínimo de personas de confianza. · Habilitar autenticación de dos factores en todas las cuentas Atlassian. · Revisar periódicamente la tabla Recent activity en la App para confirmar que el pipeline de snapshots funciona como se espera. · Generar y archivar evidence packs como parte de su rutina de auditoría — los packs contienen firmas independientes que los clientes pueden verificar fuera de la App.
9. Seguridad de estaciones de trabajo y desarrolladores
· Cifrado de disco completo. Las estaciones de trabajo de desarrollo usan cifrado de disco completo (p. ej. FileVault). · Bloqueo de pantalla y MFA. Las estaciones de trabajo se bloquean automáticamente al estar inactivas y requieren autenticación; el acceso a las cuentas requiere MFA. · Parcheo. Los sistemas operativos y las herramientas de desarrollo se mantienen al día con las actualizaciones de seguridad del proveedor. · Protección de endpoints. Las estaciones de trabajo ejecutan protección contra malware en endpoints soportada por el proveedor. · Higiene de credenciales. Los secretos y tokens nunca se incluyen en el control de versiones; los tokens de plataforma son gestionados por Forge.
10. Registro y monitoreo
· Logs de la plataforma Forge. Los logs de ejecución de la App están disponibles a través de la plataforma Atlassian Forge (forge logs) y la Developer Console; no enviamos logs a ningún sistema externo. · Sin datos de clientes en los logs. El logging de la aplicación se redacta para evitar registrar datos personales o configuración cruda de los clientes; los identificadores se minimizan. · Observabilidad in-app. La App expone su propia salud operativa — tasa de éxito de captura, integridad de la cadena de hashes y actividad reciente — directamente en la interfaz de administración, de modo que los administradores puedan confirmar el funcionamiento correcto sin herramientas externas.
11. Continuidad del negocio y recuperación ante desastres
· Durabilidad respaldada por la plataforma. Los datos persistentes residen en Forge Storage gestionado por Atlassian, que hereda los controles de respaldo, replicación y durabilidad a nivel de plataforma de Atlassian. Consulte el Trust Centre de Atlassian en https://www.atlassian.com/trust. · Sin infraestructura independiente. Dado que la App se ejecuta íntegramente dentro del runtime de Forge, no existe un servidor, base de datos ni servicio operado por SPHIOR que pueda fallar de forma independiente a la plataforma de Atlassian. · Recuperabilidad del código fuente. El código fuente de la aplicación está bajo control de versiones y puede volver a desplegarse en el Atlassian Marketplace a través del pipeline de publicación estándar. · Exportación del lado del cliente. Los administradores pueden generar y archivar evidence packs en cualquier momento, lo que proporciona una copia verificable de forma independiente del ledger fuera de la App.
12. Inteligencia artificial
SPHIOR Ledger no utiliza inteligencia artificial ni modelos de machine-learning en su funcionalidad principal. La captura de configuración, el diffing, el hash-chaining, la atribución y el mapeo de cumplimiento son completamente deterministas. No se envía ningún dato de clientes a ningún servicio de IA/ML — en coherencia con la arquitectura de cero egress de la App.
13. Revisión y comunicación de la política
Esta Política de Seguridad y nuestras prácticas internas de seguridad se revisan al menos anualmente, y siempre que se produzca un cambio significativo en la App o en su entorno operativo. Las prácticas pertinentes se comunican a cualquier contratista o tercero involucrado en el desarrollo o las operaciones. La fecha de "Última actualización" indicada arriba refleja la revisión más reciente.
14. Contacto
Eventos de seguridad: security@sphior.com Contacto general: support@sphior.com Consultas de privacidad: véase la Política de privacidad en https://ledger.sphior.com/privacy
Última actualización: 2026-06-29