Security statement and vulnerability handling

This page collects what security reviewers ask most often: how vulnerabilities in the Gluesync images are found and fixed, which TLS versions and ciphers Gluesync accepts and how to use your own certificate, and short answers for a security questionnaire.

It states what the product does today. For commitments that are contractual, such as response times for a vulnerability, ask your MOLO17 contact: this page does not make them.

How vulnerabilities in the images are handled

What is scanned, and when

Topic Practice

Topic	Practice
Scanner	Trivy, in vulnerability mode. It looks for known CVEs in the operating system packages and in the libraries inside each image. It does not scan for secrets or for configuration mistakes.
Scope	Every image that the Gluesync kit starts: Core Hub, Conductor, Chronos, the reverse proxy, Prometheus and Grafana.
Severity reported	`HIGH` and `CRITICAL`.
Moment	The kit of each release is scanned: the release pipeline waits until all the image tags of a version are published, and then scans that version. Scheduled scans run in addition.
Result	A spreadsheet per scan: a summary sheet with the number of findings by severity, and one sheet per kit folder with, for each finding, the image, the package, the CVE identifier, the severity, the installed and the fixed version, the title, the CVSS score, the CWE and a link to the advisory. MOLO17 keeps each report together with the Gluesync version it was produced for.

Scanner

Trivy, in vulnerability mode. It looks for known CVEs in the operating system packages and in the libraries inside each image. It does not scan for secrets or for configuration mistakes.

Scope

Every image that the Gluesync kit starts: Core Hub, Conductor, Chronos, the reverse proxy, Prometheus and Grafana.

Severity reported

HIGH and CRITICAL.

Moment

The kit of each release is scanned: the release pipeline waits until all the image tags of a version are published, and then scans that version. Scheduled scans run in addition.

Result

A spreadsheet per scan: a summary sheet with the number of findings by severity, and one sheet per kit folder with, for each finding, the image, the package, the CVE identifier, the severity, the installed and the fixed version, the title, the CVSS score, the CWE and a link to the advisory. MOLO17 keeps each report together with the Gluesync version it was produced for.

How findings are fixed

Regular cycle. The operating system packages, the bundled runtimes and the third-party images are refreshed on a quarterly cycle. See Security updates and CVE patch cycle.
Critical findings. They are assessed case by case and can be fixed outside the cycle.
How a fix reaches you. As a new image tag in a new Gluesync release. A running container is not patched in place: update with the procedure of your deployment and test the release in a development environment first.
Present is not exploitable. A scanner reports that a vulnerable library is in an image, not that the vulnerable code can be reached. MOLO17 checks each finding against the product: whether Gluesync uses the vulnerable function, and whether it can be reached from the REST API, the Control Plane, an agent message or an imported configuration. The outcome is a classification of the finding, for example not affected or fixed in release X.

What is inside the images

The images contain different runtimes, which matters when a scanner lists an advisory for one of them:

Image	Main runtime
Core Hub	Java 21 (Azul Zulu OpenJDK), on a Linux base image.
Conductor	Node.js, on a Linux base image.
Chronos	Python, on a Linux base image.
Reverse proxy, Prometheus, Grafana	Third-party images, written in Go.

Image

Main runtime

Core Hub

Java 21 (Azul Zulu OpenJDK), on a Linux base image.

Conductor

Node.js, on a Linux base image.

Chronos

Python, on a Linux base image.

Reverse proxy, Prometheus, Grafana

Third-party images, written in Go.

To check what an image contains instead of trusting the report alone, run the runtime of the image, for example docker run --rm --entrypoint java <image> -version for Core Hub, or docker exec <conductor container> node --version.

FAQ

How do I get the latest CVE report for my Gluesync version?

Open a ticket in the support portal and say which Gluesync version you run. MOLO17 produces one scan per release, so the report that matches your version is the one to ask for.

My scanner reports a CVE in a Gluesync image. What do I do?

Check that the image is the official one with the official tag. MOLO17 can assess its own images only: a rebuilt image, or one with extra drivers added, can contain libraries that are not Gluesync’s.
Update to the latest Gluesync 2.3 release, which carries the latest image refresh.
If the CVE is still reported, open a ticket with the CVE identifier, the path of the file or the package that the scanner names, the image tag, and a copy of the scanner finding. You receive a classification of that finding.

Which Gluesync releases are patched?

Check the release notes of the release that you plan to update to. The support window of each release line is described in Enterprise support.

How do I report a vulnerability in Gluesync?

Write to security@molo17.com. See Report a security issue.

TLS versions, ciphers and certificates

What does Gluesync accept?

There are two TLS endpoints in a kit. Browsers and API clients reach the reverse proxy, which forwards to Core Hub over HTTPS.

Endpoint Protocols Cipher suites (TLS 1.2)

Endpoint	Protocols	Cipher suites (TLS 1.2)
Core Hub, HTTPS and secure WebSockets (port `1717`)	TLS 1.2 only. TLS 1.3 is not enabled on this listener; TLS 1.0 and 1.1 are refused.	`ECDHE-RSA-AES256-GCM-SHA384`, `ECDHE-RSA-AES128-GCM-SHA256`, `ECDHE-RSA-CHACHA20-POLY1305`, `DHE-RSA-AES256-GCM-SHA384`, `DHE-RSA-AES128-GCM-SHA256`, `DHE-RSA-CHACHA20-POLY1305`, `ECDHE-RSA-AES256-SHA384`, `ECDHE-RSA-AES128-SHA256`, `DHE-RSA-AES256-SHA256`, `DHE-RSA-AES128-SHA256`
Reverse proxy of the kit (Traefik, port `443`)	TLS 1.2 and TLS 1.3. TLS 1.0 and 1.1 are refused.	`ECDHE-RSA-AES256-GCM-SHA384`, `ECDHE-RSA-AES128-GCM-SHA256`, `ECDHE-RSA-CHACHA20-POLY1305`, `ECDHE-RSA-AES256-SHA`, `ECDHE-RSA-AES128-SHA`

Core Hub, HTTPS and secure WebSockets (port 1717)

TLS 1.2 only. TLS 1.3 is not enabled on this listener; TLS 1.0 and 1.1 are refused.

ECDHE-RSA-AES256-GCM-SHA384, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-CHACHA20-POLY1305, DHE-RSA-AES256-GCM-SHA384, DHE-RSA-AES128-GCM-SHA256, DHE-RSA-CHACHA20-POLY1305, ECDHE-RSA-AES256-SHA384, ECDHE-RSA-AES128-SHA256, DHE-RSA-AES256-SHA256, DHE-RSA-AES128-SHA256

Reverse proxy of the kit (Traefik, port 443)

TLS 1.2 and TLS 1.3. TLS 1.0 and 1.1 are refused.

ECDHE-RSA-AES256-GCM-SHA384, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-CHACHA20-POLY1305, ECDHE-RSA-AES256-SHA, ECDHE-RSA-AES128-SHA

The lists above were measured on a Gluesync 2.3 kit with an RSA certificate. They are not configured by Gluesync: Core Hub follows the defaults of the Java runtime of its image, and the proxy follows its own defaults, so the lists can change when an image is updated. Measure your own installation if a policy requires the exact list, for example with openssl s_client -connect <host>:<port> -tls1_2 -cipher <suite>.

How do I restrict the protocols and ciphers that browsers can use?

Do it on the reverse proxy, which is the endpoint that browsers reach. Add TLS options to the certs.yml file in the proxy folder of the kit, next to the certificate definition, and restart the proxy:

tls:
  options:
    default:
      minVersion: VersionTLS12
      cipherSuites:
        - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

With these options the proxy accepts only these two suites on TLS 1.2, and still negotiates TLS 1.3 (its suites are not configurable). Set minVersion: VersionTLS13 to accept TLS 1.3 only. These options apply to the proxy: the listener of Core Hub itself is not changed by them.

How do I use my own certificate?

Three places hold certificates, each with its own page:

What Where it is used How

What	Where it is used	How
Reverse proxy	The certificate that browsers see.	Replace `gluesync-cert.pem` and `gluesync-key.pem` of the kit, and keep the names. See Configuring the reverse proxy certificate.
Core Hub	HTTPS and secure WebSockets between Core Hub, the modules and the agents.	Set `SSL_ENABLED=true`, mount a JKS or PKCS12 keystore, and point `security-config.json` to it. See HTTPS and secure WebSockets.
Databases and services	Connections from the agents to your databases.	Upload a trust store, and a key store when the database asks for a client certificate. See Secure database and service connections.

Reverse proxy

The certificate that browsers see.

Replace gluesync-cert.pem and gluesync-key.pem of the kit, and keep the names. See Configuring the reverse proxy certificate.

Core Hub

HTTPS and secure WebSockets between Core Hub, the modules and the agents.

Set SSL_ENABLED=true, mount a JKS or PKCS12 keystore, and point security-config.json to it. See HTTPS and secure WebSockets.

Databases and services

Connections from the agents to your databases.

Upload a trust store, and a key store when the database asks for a client certificate. See Secure database and service connections.

List every host name and every IP address that clients use in the Subject Alternative Names of the certificate: a name that is missing makes browsers and API clients refuse it. Restart the proxy and Core Hub after replacing certificates.

Which TLS versions do the agents use towards databases?

The agents are TLS clients inside the Java runtime of Core Hub. They negotiate with the defaults of that runtime: TLS 1.3 is preferred, and TLS 1.0, TLS 1.1 and the static RSA suites are disabled. A legacy database that only offers them, such as an unpatched SQL Server 2008 or 2012, fails to connect. Lowering the TLS floor for the whole Core Hub process is possible with a setting that is described in the SQL Server troubleshooting page, and it is meant for databases on a trusted network only. See SQL Server troubleshooting.

Answers for security questionnaires

The answers cover the product as delivered. Items that depend on your deployment, such as the network, the host and the identity provider, are yours to complete.

Question Answer More

Question	Answer	More
Is data encrypted in transit between the browser or API client and Gluesync?	Yes. Core Hub serves HTTPS and secure WebSockets with TLS 1.2, and the reverse proxy of the kit with TLS 1.2 and TLS 1.3. You can install your own certificate.	TLS versions, ciphers and certificates
Is data encrypted in transit between Gluesync and the databases?	Yes, when TLS is enabled on the connection of the agent. It is set per connection, with a trust store and optionally a key store.	Secure database and service connections
Is data encrypted between the Gluesync components?	The components talk over secure WebSockets when TLS is enabled. With the Enterprise with Advanced Security license, the messages between nodes are also encrypted with AES-256, using a Diffie-Hellman key agreement.	Node-to-node encryption
How do users authenticate?	With local accounts that follow a password policy (at least 8 characters, with a lowercase letter, an uppercase letter and a symbol, and a password change at the first sign-in), or with single sign-on through OpenID Connect, which lets your identity provider enforce its own rules. Scripts and tools use personal API tokens.	Users and roles, OIDC authentication, Personal API Tokens
How is access controlled?	Roles decide what a user can do, and a personal API token never has more access than its user, with permission scopes that narrow it further.	Users and roles
How long do sessions last?	Sessions are JSON Web Tokens that expire after 72 hours by default. A Super Admin can change this.	Users and roles
Are credentials shown in clear text?	No. Passwords of connections are masked in what the Control Plane and the API return.
Does Gluesync call home to check the license?	No. The license is a signed file that Core Hub verifies locally, so it works in an air-gapped network.	Licensing
Which data does Gluesync send to MOLO17?	The replicated data goes only from your sources to your targets. Remote log collection is off by default, sends only `ERROR` logs and uses TLS. Anonymous usage analytics (pages and features used, no customer data) are on by default and can be switched off in Settings → Support. Logs reach MOLO17 for a ticket only when you upload them. The AI features contact the provider that you configure.	Logging, System requirements
How are vulnerabilities in the images managed?	Images are scanned with Trivy at each release and on a schedule, and findings are fixed in the quarterly cycle or, for critical ones, earlier.	How vulnerabilities in the images are handled
How do I report a vulnerability?	Write to security@molo17.com.	Report a security issue

Is data encrypted in transit between the browser or API client and Gluesync?

Yes. Core Hub serves HTTPS and secure WebSockets with TLS 1.2, and the reverse proxy of the kit with TLS 1.2 and TLS 1.3. You can install your own certificate.

TLS versions, ciphers and certificates

Is data encrypted in transit between Gluesync and the databases?

Yes, when TLS is enabled on the connection of the agent. It is set per connection, with a trust store and optionally a key store.

Secure database and service connections

Is data encrypted between the Gluesync components?

The components talk over secure WebSockets when TLS is enabled. With the Enterprise with Advanced Security license, the messages between nodes are also encrypted with AES-256, using a Diffie-Hellman key agreement.

Node-to-node encryption

How do users authenticate?

With local accounts that follow a password policy (at least 8 characters, with a lowercase letter, an uppercase letter and a symbol, and a password change at the first sign-in), or with single sign-on through OpenID Connect, which lets your identity provider enforce its own rules. Scripts and tools use personal API tokens.

Users and roles, OIDC authentication, Personal API Tokens

How is access controlled?

Roles decide what a user can do, and a personal API token never has more access than its user, with permission scopes that narrow it further.

Users and roles

How long do sessions last?

Sessions are JSON Web Tokens that expire after 72 hours by default. A Super Admin can change this.

Users and roles

Are credentials shown in clear text?

No. Passwords of connections are masked in what the Control Plane and the API return.

Does Gluesync call home to check the license?

No. The license is a signed file that Core Hub verifies locally, so it works in an air-gapped network.

Licensing

Which data does Gluesync send to MOLO17?

The replicated data goes only from your sources to your targets. Remote log collection is off by default, sends only ERROR logs and uses TLS. Anonymous usage analytics (pages and features used, no customer data) are on by default and can be switched off in Settings → Support. Logs reach MOLO17 for a ticket only when you upload them. The AI features contact the provider that you configure.

Logging, System requirements

How are vulnerabilities in the images managed?

Images are scanned with Trivy at each release and on a schedule, and findings are fixed in the quarterly cycle or, for critical ones, earlier.

How vulnerabilities in the images are handled

How do I report a vulnerability?

Write to security@molo17.com.

Report a security issue