Security & Vulnerability Disclosure | eSeGeCe

Security & Vulnerability Disclosure

Last updated: August 2026

The eSeGeCe component libraries are built into applications that run in production, often on the open internet. We take reports of security defects seriously and we would rather hear about a problem early than read about it later. This page describes how to reach us, what happens after you write, and what we commit to in return.

Reporting a vulnerability

Use our contact form and put "security" in the subject. It reaches the developers directly, not a first-line ticket queue, and it is our single point of contact for security matters. You do not need a support contract or a valid licence to report a vulnerability.

Please include as much of the following as you can:

  • Product, edition and version. For example sgcWebSockets 2026.8.0 Enterprise, or the exact revision if you build from source.
  • Affected component. The unit, class or protocol involved, such as the HTTP/2 server or the MQTT client.
  • Environment. Delphi or C++ Builder version, target platform, and the TLS backend in use if the issue is transport related.
  • Reproduction. A minimal project, a packet capture, or a sequence of steps. The smaller the repro, the faster the fix.
  • Impact. What an attacker gains, and whether authentication or a specific configuration is required.

If you would like to encrypt your report, say so in a first message without technical detail and we will arrange a channel with you.

What we do when a report arrives

  • Acknowledgement within 5 working days. You get a human reply confirming we received the report and who is looking at it.
  • Assessment within 10 working days. We confirm or reject the finding, tell you our severity assessment, and give you an expected timeline.
  • Fix. Critical and high severity defects are addressed in a targeted release. Lower severity findings are scheduled into the next regular release.
  • Notification. The fix is described in the release notes shipped with the product and published in the change log on this site.
  • Credit. We name the reporter in the advisory if you want to be named, and we stay silent about you if you prefer.

Coordinated disclosure

We ask that you give us a reasonable window to release a fix before you publish, and 90 days from the date of your report is the window we work to. If a defect is being actively exploited, or if a fix is going to take longer than expected, we will talk to you about the timing rather than let the clock run out in silence. We will not use legal threats against anyone who reports a vulnerability in good faith and follows this policy.

Scope

In scope are the eSeGeCe component libraries in every supported edition, including sgcWebSockets, sgcSign, sgcOpenAPI, sgcIndy and sgcBiometrics, together with the sample and demo code we distribute, and this website.

Out of scope are findings that only affect third party software we do not distribute, reports produced by an automated scanner with no demonstrated impact, and anything that requires you to attack our infrastructure or another customer. Please do not run denial of service tests, brute force our servers, or access data that is not yours.

Reporting a vulnerability in a component we use

If your finding is in a third party component we build on, such as Indy, zlib or OpenSSL, tell us anyway. We will forward the report to the upstream maintainers, as required of us under Article 13(6) of the EU Cyber Resilience Act, and we will track the fix into our own releases.

Security updates and support period

Security fixes are delivered as part of the normal product releases, which ship several times a year with full source code. A licence includes updates for its subscription period, and security fixes for a given major version remain available for at least five years from its release. Because every licence includes the complete source, you are never dependent on us to inspect, patch or rebuild the code you ship.

Software Bill of Materials

We maintain a machine readable SBOM in CycloneDX format for every release, listing the top level components our products are built from and their licences. The Cyber Resilience Act requires manufacturers to draw one up and keep it in the technical documentation, it does not require them to publish it, so ours is provided on request rather than posted here. Licensees and market surveillance authorities can request it through our contact form, stating the product, edition and version concerned.

Regulatory context

If you are assessing us as a supplier under the EU Cyber Resilience Act, Regulation (EU) 2024/2847, our statement on what the CRA means for products built with the eSeGeCe components is on a separate page.

Contact

Everything on this page, vulnerability reports included, reaches us through our contact form.