Skip to content
Entropy Data

Vulnerability Handling

According to our System Security Policy, we use Vulnerability Monitoring Tools to regularly monitor and scan our systems and hosted applications for vulnerabilities. Vulnerability scanning must occur continuously, and scans must be initiated whenever new vulnerabilities that may affect the system are identified or reported by vendors or security advisories.

Reporting a Vulnerability to Us

Please report security vulnerabilities to security@entropy-data.com. Do not report them through a public issue tracker or support ticket.

Helpful details to include: the affected version or container image tag, a description of the issue and its impact, steps to reproduce, and any known mitigation.

We acknowledge your report within 3 working days and tell you how we assess it. Remediation then follows the timelines described below. We ask that you give us reasonable time to release a fix before disclosing the issue publicly, and we are happy to credit you unless you prefer otherwise.

Monitoring of Vulnerabilities

We use these tools to identify and monitor vulnerabilities:

  • Dependabot alerts to identify vulnerabilities in our dependencies
  • GitHub code scanning (CodeQL) for static analysis of our own source code, run daily across Java/Kotlin, JavaScript/TypeScript, Python, and our GitHub Actions workflows
  • Docker Scout to monitor vulnerabilities in container images

At build time, we also create a Software Bill of Material (SBOM) and attach it to our container builds to enable customers to scan for vulnerabilities.

Remediation of Vulnerabilities

Based on the risk level and applicability of the reported vulnerabilities, we act immediately or plan to upgrade to a fixed version within 30 days.

We currently have this strategy to remediate vulnerabilities:

  • Base-Image: Container images are built on the Debian image bundled with the BellSoft Liberica JDK (bellsoft/liberica-openjdk-debian), and run on BellSoft's hardened Alpaquita Linux runtime image bundled with the Liberica JRE (bellsoft/liberica-runtime-container). The runtime image is roughly half the size of the Debian one and carries considerably fewer CVEs. In the Dockerfile, we pin the major version so that bugfix versions get updated automatically.
  • Java-Libraries: We use GitHub Dependabot to automatically create pull requests when an upgraded version is available. We aim to go with the latest stable version of libraries. Pull requests are typically merged within 7 days.

We are aware that container images and libraries constantly have a few open CVEs, and we accept this risk. We trust BellSoft and the Alpaquita and Debian communities to work on providing bug fixes as needed.

In addition, we have subscribed to relevant mailing lists and newsletters to be informed when severe vulnerabilities become public.

We recommend setting up an automated SBOM monitoring for deployed versions of the self-hosted Docker container image and upgrading to the latest available version to address severe security issues in the base image or in Java libraries.