Política de Segurança
SPHIOR Ledger for Jira
Esta Política de Segurança descreve como a SPHIOR ("nós") protege o SPHIOR Ledger for Jira (o "App") e os sistemas que sustentam seu desenvolvimento e operação. Para como tratamos os dados, consulte nossa Política de Privacidade em https://ledger.sphior.com/privacy.
1. Arquitetura e proteção de dados
O SPHIOR Ledger é construído sobre o Atlassian Forge e é elegível para o programa Runs on Atlassian. · Zero egress de rede externa. O manifest do App não declara hosts externos; todo o processamento ocorre dentro do runtime Forge gerenciado pela Atlassian. · Armazenamento isolado por tenant. Todos os dados persistentes residem no Forge Storage (per-install SQL), dentro do seu tenant Atlassian. Não operamos nenhum banco de dados externo, log shipper ou endpoint de analytics. · Sem sub-processadores de terceiros. O App não possui nenhum. · Criptografia em trânsito: TLS 1.2+ para cada chamada de API, aplicada pela plataforma Forge da Atlassian. · Criptografia em repouso: Forge Storage é criptografado pela Atlassian. Veja o Trust Centre da Atlassian em https://www.atlassian.com/trust para controles a nível de plataforma.
2. Ledger à prova de manipulação
O ledger de auditoria do próprio App é protegido por uma cadeia de hashes SHA-256. Cada snapshot referencia o hash do registro anterior; edições silenciosas no ledger quebram a cadeia e são expostas no verificador de integridade in-app. Clientes podem verificar independentemente o conteúdo de pack via assinaturas incluídas em cada evidence pack exportado.
3. Gestão de vulnerabilidades e desenvolvimento seguro
· Varredura de segurança automatizada. Como a auditoria de segurança web (DAST/SAST/SCA autenticados) é o negócio principal da SPHIOR, executamos SAST (análise estática de código), SCA (varredura de dependências / código aberto) e DAST autenticado contra as superfícies alcançáveis do App de forma regular (pelo menos trimestralmente e antes de releases significativos). · Software bill of materials (SBOM). As dependências são fixadas via lockfiles; um SBOM é mantido e revisado a cada release. · Prazos de remediação. As descobertas das varreduras são triadas e remediadas dentro de prazos definidos, alinhados à Atlassian Marketplace Security Bug Fix Policy (problemas críticos priorizados para o release mais cedo possível). · Patching de runtime. O runtime Forge, o motor Forge SQL e Forge Storage são mantidos pela Atlassian; adotamos prontamente as atualizações de runtime recomendadas pela Atlassian e não executamos versões de runtime sem suporte. · Análise estática e revisão. TypeScript em modo strict, ESLint e forge lint executam em cada commit; mudanças são revisadas por pares antes do merge no branch main. · Sem segredos no código-fonte. Repositórios não contêm credenciais, tokens ou segredos compartilhados; o App não solicita PATs ou senhas do usuário final, e o Forge gerencia todos os tokens de plataforma. · Pen-testing. Realizamos testes de segurança autenticados internamente; pen-testing independente por terceiros está em nosso roadmap.
4. Resposta a incidentes de segurança
No caso de um incidente de segurança confirmado que afete o App: 1. Triagem iniciada em até 24 horas após confirmação. 2. Notificação ao cliente enviada por email para o endereço contact-for-security-issues cadastrado das instalações afetadas, em até 72 horas após confirmação de impacto material, alinhada com as expectativas do Artigo 33 do GDPR. 3. Análise de causa raiz e plano de remediação. Correções com impacto ao cliente são publicadas no Atlassian Marketplace via pipeline padrão de atualização. 4. Relatório pós-incidente compartilhado com clientes afetados e resumido publicamente nesta página quando apropriado. Eventos de segurança suspeitos podem ser reportados a security@sphior.com a qualquer momento. Confirmamos recebimento em até 1 dia útil.
5. Controles de acesso (interno)
· Privilégio mínimo. O acesso aos repositórios de código-fonte, ao Atlassian Developer Console e ao deploy em produção é restrito aos mantenedores do App conforme a necessidade de conhecimento. Não utilizamos contas compartilhadas nem credenciais de produção compartilhadas. · Repositório de código-fonte. O branch main é protegido com status checks obrigatórios (TypeScript, lint e testes devem passar antes do merge). · Developer Console. O acesso é restrito à conta publicador (founder@sphior.com) e usa autenticação a nível de conta Atlassian com autenticação multifator (MFA) habilitada. · Autenticação multifator. MFA é exigida em todas as contas com acesso ao código-fonte, ao Developer Console e às ferramentas de deploy. · Revisão periódica de acesso. A lista de contas com acesso aos sistemas de desenvolvimento e deploy é revisada pelo menos trimestralmente, e o acesso é revogado prontamente quando não mais necessário. · O deploy em produção é realizado via Atlassian Forge CLI; nenhuma credencial de produção compartilhada é utilizada.
6. Conformidade e certificações
Status de conformidade: · Obrigações de Data Processor do GDPR: adotadas (ver Política de Privacidade §10). · Obrigações de Service Provider do CCPA: adotadas (sem venda de informações pessoais; processamento limitado a fins comerciais). · Programa Runs on Atlassian: elegível. · SOC 2 Type II: roadmap (pós-lançamento). · ISO 27001: roadmap (pós-lançamento). · HIPAA: não certificado — o App não se destina a armazenamento de PHI. Não possuímos atualmente certificações SOC 2 ou ISO 27001. A elegibilidade do App em Runs on Atlassian herda as certificações a nível de plataforma da Atlassian para a infraestrutura subjacente; clientes que necessitem de nossas próprias certificações podem nos contatar sobre o cronograma do roadmap.
7. Divulgação responsável
Acolhemos pesquisa de segurança sobre o App. Por favor reporte descobertas privadamente a security@sphior.com com: · Descrição do problema · Passos de reprodução · Avaliação de impacto · Mitigações sugeridas Comprometemo-nos a: · Confirmar recebimento do seu reporte em 1 dia útil · Fornecer decisão inicial de triagem em 5 dias úteis · Não promover ações legais contra pesquisadores de boa-fé que sigam esta política Participação no Atlassian Marketplace Security Bug Bounty Program é item de roadmap; até a inscrição, por favor divulgue diretamente a nós.
8. Controles de segurança do lado do cliente
O App é administrado pela interface de admin existente do Jira e herda autenticação, autorização e audit-log do Jira. Recomendamos fortemente: · Restringir permissões de admin Jira a um conjunto mínimo de pessoas confiáveis. · Habilitar autenticação de dois fatores em todas as contas Atlassian. · Revisar periodicamente a tabela Recent activity in-app para confirmar que o pipeline de snapshots opera como esperado. · Gerar e arquivar evidence packs como parte de sua rotina de auditoria — packs contêm assinaturas independentes verificáveis fora do App.
9. Segurança de estações de trabalho e desenvolvedores
· Criptografia de disco completo. As estações de trabalho de desenvolvimento usam criptografia de disco completo (por exemplo, FileVault). · Bloqueio de tela e MFA. As estações de trabalho bloqueiam automaticamente quando ociosas e exigem autenticação; o acesso à conta requer MFA. · Patching. Sistemas operacionais e ferramentas de desenvolvimento são mantidos atualizados com as atualizações de segurança dos fornecedores. · Proteção de endpoint. As estações de trabalho executam proteção contra malware de endpoint com suporte do fornecedor. · Higiene de credenciais. Segredos e tokens nunca são commitados no controle de versão; os tokens de plataforma são gerenciados pelo Forge.
10. Logging e monitoramento
· Logs da plataforma Forge. Os logs de execução do App estão disponíveis através da plataforma Atlassian Forge (forge logs) e do Developer Console; não enviamos logs para nenhum sistema externo. · Sem dados de cliente nos logs. O logging da aplicação é escrito de forma a evitar o registro de dados pessoais ou da configuração bruta do cliente; os identificadores são minimizados. · Observabilidade in-app. O App expõe sua própria saúde operacional — taxa de sucesso de captura, integridade da cadeia de hashes e atividade recente — diretamente na interface de admin, para que os administradores possam confirmar a operação correta sem ferramentas externas.
11. Continuidade de negócios e recuperação de desastres
· Durabilidade suportada pela plataforma. Os dados persistentes residem no Forge Storage gerenciado pela Atlassian, que herda os controles de backup, replicação e durabilidade a nível de plataforma da Atlassian. Veja o Trust Centre da Atlassian em https://www.atlassian.com/trust. · Sem infraestrutura separada. Como o App é executado inteiramente dentro do runtime Forge, não há servidor, banco de dados ou serviço operado pela SPHIOR que possa falhar independentemente da plataforma Atlassian. · Recuperabilidade do código-fonte. O código-fonte da aplicação é versionado e pode ser reimplantado no Atlassian Marketplace através do pipeline padrão de publicação. · Exportação do lado do cliente. Os administradores podem gerar e arquivar evidence packs a qualquer momento, fornecendo uma cópia do ledger verificável independentemente fora do App.
12. Inteligência artificial
O SPHIOR Ledger não utiliza nenhum modelo de inteligência artificial ou de machine learning em sua funcionalidade principal. Captura de configuração, diffing, encadeamento de hashes, atribuição e mapeamento de conformidade são totalmente determinísticos. Nenhum dado de cliente é enviado a qualquer serviço de IA/ML — consistente com a arquitetura zero-egress do App.
13. Revisão e comunicação da política
Esta Política de Segurança e nossas práticas internas de segurança são revisadas pelo menos anualmente, e sempre que ocorrer uma mudança significativa no App ou em seu ambiente operacional. As práticas relevantes são comunicadas a quaisquer contratados ou terceiros envolvidos no desenvolvimento ou nas operações. A data de "Última atualização" acima reflete a revisão mais recente.
14. Contato
Eventos de segurança: security@sphior.com Contato geral: support@sphior.com Consultas de privacidade: ver Política de Privacidade em https://ledger.sphior.com/privacy
Última atualização: 2026-06-29