Skip to main content

Removing SQLite from DataHub Dockerfiles to Satisfy Security Scanning Policies

Angelo Bresci
Updated

Area: Deployment Issues

Sub-Area: Container Security / CVE Remediation

Issue

When building DataHub Docker images in environments that route OS package installations through an internal artifact proxy or curation policy (such as JFrog Artifactory with CVSS-based blocking rules), builds may fail because the SQLite package is flagged by one or more CVEs and blocked before it can be installed. This affects the frontend, gms, mae-consumer, mce-consumer, and upgrade images, all of which included an explicit apk add sqlite line in DataHub versions prior to v1.6.0.1. Because no single SQLite version available on Alpine 3.22 clears every reported CVE simultaneously, organizations with strict curation policies cannot install the package at all. The correct remediation is to remove SQLite from the Dockerfiles entirely, as it is not required by any of these images at runtime or build time.

Error Messages

  • ERROR: sqlite-3.49.2-r1: Permission denied

You Might Be Asking

  • Is SQLite actually required for DataHub's frontend, gms, mae-consumer, mce-consumer, or upgrade images to function?
  • Is SQLite a direct DataHub dependency or does it come from the base image?
  • Can I safely remove SQLite from these Dockerfiles without breaking DataHub?
  • Which SQLite version is fully remediated for all reported CVEs on Alpine 3.22?
  • How does SQLite dependency change when upgrading to DataHub v1.6.0.x (Wolfi/Chainguard base images)?

Solution

  1. Understand why SQLite is present in older DataHub Dockerfiles.

    In DataHub releases prior to v1.6.0.1, the following five Dockerfiles each contained an explicit SQLite installation as a workaround for an older Alpine SQLite CVE (introduced in 2023 via PR #8032):

    • docker/datahub-frontend/Dockerfile
    • docker/datahub-gms/Dockerfile
    • docker/datahub-mae-consumer/Dockerfile
    • docker/datahub-mce-consumer/Dockerfile
    • docker/datahub-upgrade/Dockerfile

    The relevant line in each Dockerfile looks like this:

    && apk --no-cache add bash coreutils gcompat sqlite libc6-compat \

    This workaround was removed upstream as unused starting with v1.6.0.1 (PR #17996).

  2. Confirm SQLite is not required at runtime or build time.

    All five images are Java-based (or Node-based for the frontend). None of them call the sqlite3 binary or load the SQLite engine during normal operation. If your scanner also reports an ebean-platform-sqlite JAR inside the GMS WAR or the consumer/upgrade JARs, that file contains only Ebean's SQL-dialect definition class — it contains no SQLite engine code and does not require the SQLite OS package to be present.

    SQLite is used only by the optional DataHub Lite developer tool (a local CLI feature), which is entirely separate from the server-side Docker images described here.

  3. Remove SQLite from the apk add line in each affected Dockerfile.

    Edit each of the five Dockerfiles and remove sqlite from the package installation line. Also remove any adjacent comment referencing the old SQLite CVE upgrade rationale. Example before and after:

    # BEFORE
RUN set -x \
    && apk --no-cache add bash coreutils gcompat sqlite libc6-compat \
    ...

# AFTER
RUN set -x \
    && apk --no-cache add bash coreutils gcompat libc6-compat \
    ...

    If you also build the mysql-setup or postgres-setup images, those Dockerfiles install SQLite in the same pattern and can have it removed as well.

  4. Verify SQLite is fully absent from each built image.

    After rebuilding, run the following check against each image to confirm no SQLite package remains:

    docker run --rm --entrypoint sh <image-name> -c 'apk info -v | grep -i sqlite'

    The command should return no output. If sqlite-libs appears, a package you added is pulling it in transitively. Use the following commands to trace the dependency chain: 

    # Find what requires sqlite-libs
docker run --rm --entrypoint sh <image-name> -c 'apk info -r sqlite-libs'

# If that returns a library, trace further up the chain
docker run --rm --entrypoint sh <image-name> -c 'apk info -r <library-name>'

    Continue tracing until you reach a package listed in /etc/apk/world. That is the top-level package pulling in SQLite.

  5. Record the CVE status for governance documentation.

    For teams that need to document remediation decisions, the CVE coverage on Alpine 3.22 is as follows:

    • CVE-2026-11822 and CVE-2026-11824 — Fixed in SQLite 3.53.2. Alpine 3.22 ships only 3.49.2-r1, so no installable version on this base clears these two findings.
    • CVE-2025-70873 — Relates to SQLite's zipfile extension; Alpine's sqlite3 build does not include that extension.
    • CVE-2019-9936 and CVE-2019-9937 — Fixed in SQLite 3.28.0 (released 2019).

    Because no Alpine 3.22 SQLite package clears all five findings simultaneously, removal is the only fully compliant remediation path for these images on Alpine 3.22.

Additional Notes

Upgrading to v1.6.0.1 or later (Wolfi/Chainguard base images): Starting with v1.6.0.1, DataHub's upstream Dockerfiles no longer install the sqlite package explicitly, and the base image switches from Alpine to Wolfi (Chainguard). However, the published v1.6.0.2 images still contain the sqlite-libs package (version 3.53.4 on Wolfi) as an indirect dependency of curl, pulled in through its LDAP and Kerberos libraries. Version 3.53.4 includes fixes for CVE-2026-11822 and CVE-2026-11824, but whether your curation policy still matches the 2019 CVEs against this version depends on your policy configuration. Additionally, since v1.6.0.x images are based on Wolfi rather than Alpine, an Alpine remote in your artifact proxy will not cover their package installations. The relevant Dockerfile build arguments and their defaults are: 

BASE_IMAGE=cgr.dev/chainguard/wolfi-base:latest
APK_REPOSITORY_URL=https://apk.cgr.dev/chainguard

kafka-setup image: DataHub dropped the kafka-setup Dockerfile in v1.3.0. If you are still building an older version of that image, note that it installs python3, which pulls in sqlite-libs as its own transitive dependency. This cannot be removed via the apk add line alone.

DataHub Lite: The datahub Python CLI uses Python's built-in sqlite3 standard library module for the optional DataHub Lite local storage feature. This is not a separately installed OS package; its version is tied to the Python runtime. This applies only to developer workstation usage of the CLI, not to any server-side Docker image.

Minimum SQLite version for DataHub Lite / ingestion SDK: If you use DataHub Lite in a developer context, SQLite ≥ 3.24.0 is required (for UPSERT support). This requirement does not apply to any of the five server-side images discussed in this article.

Related Documentation

Tags: sqlite, cve-remediation, dockerfile, container-security, apk, alpine, wolfi, chainguard, artifactory, vulnerability-scanning