Segurança e divulgação de vulnerabilidades
Última atualização: agosto de 2026
Última atualização: agosto de 2026
As bibliotecas de componentes eSeGeCe estão embutidas em aplicações que rodam em produção, muitas vezes expostas à internet. Levamos a sério os relatos de falhas de segurança e preferimos saber de um problema cedo a ler sobre ele mais tarde em outro lugar. Esta página descreve como nos contatar, o que acontece depois do seu relato e com o que nos comprometemos em troca.
Use nosso formulário de contato e coloque "segurança" no assunto. Ele chega diretamente aos desenvolvedores, não a uma fila de chamados de primeiro nível, e é nosso ponto de contato único para assuntos de segurança. Você não precisa de contrato de suporte nem de licença válida para relatar uma vulnerabilidade.
Inclua o máximo possível do seguinte:
Se quiser criptografar seu relato, diga isso em uma primeira mensagem sem detalhes técnicos e combinaremos um canal com você.
Pedimos que você nos dê um prazo razoável para lançar uma correção antes de publicar, e o prazo com que trabalhamos é de 90 dias a partir da data do seu relato. Se uma falha estiver sendo explorada ativamente, ou se uma correção demorar mais do que o esperado, conversaremos com você sobre os prazos em vez de deixar o relógio correr em silêncio. Não tomaremos medidas judiciais contra quem relata uma vulnerabilidade de boa-fé e segue esta política.
Estão no escopo as bibliotecas de componentes eSeGeCe em todas as edições suportadas, incluindo sgcWebSockets, sgcSign, sgcOpenAPI, sgcIndy e sgcBiometrics, junto com o código de exemplo e as demos que distribuímos, e este site.
Estão fora do escopo achados que afetam apenas software de terceiros que não distribuímos, relatos gerados por um scanner automatizado sem impacto demonstrado e tudo o que exija atacar nossa infraestrutura ou outro cliente. Não realize testes de negação de serviço, não ataque nossos servidores por força bruta e não acesse dados que não sejam seus.
Se o seu achado estiver em um componente de terceiros sobre o qual construímos, como Indy, zlib ou OpenSSL, relate-o mesmo assim. Encaminharemos o relato a quem o mantém, como exige o artigo 13(6) do Regulamento de Ciberresiliência da UE, e acompanharemos a correção até nossas próprias versões.
As correções de segurança são entregues como parte das versões normais do produto, publicadas várias vezes por ano com o código-fonte completo. Uma licença inclui atualizações durante seu período de assinatura, e as correções de segurança de uma versão principal permanecem disponíveis por pelo menos cinco anos a partir do seu lançamento. Como toda licença inclui o código-fonte completo, você nunca depende de nós para inspecionar, corrigir ou recompilar o código que distribui.
Mantemos, para cada versão, um SBOM legível por máquina no formato CycloneDX, listando os componentes de primeiro nível com que nossos produtos são construídos e suas licenças. O Regulamento de Ciberresiliência exige que os fabricantes o elaborem e o mantenham na documentação técnica, não exige que o publiquem, por isso o fornecemos mediante solicitação em vez de publicá-lo aqui. Licenciados e autoridades de fiscalização do mercado podem solicitá-lo pelo nosso formulário de contato, informando o produto, a edição e a versão em questão.
Se você está nos avaliando como fornecedor no âmbito do Regulamento de Ciberresiliência da UE, Regulamento (UE) 2024/2847, nossa declaração sobre o que o CRA significa para produtos construídos com os componentes eSeGeCe está em uma página separada.
Tudo desta página, inclusive relatos de vulnerabilidades, chega até nós pelo nosso formulário de contato.