mysql

What is MySQL?

The MySQL image packages the mysqld database server so teams can run a relational database in a container without installing and configuring MySQL on the host. MySQL is one of the most widely deployed open-source databases in the world, powering transactional workloads across web applications, e-commerce platforms, SaaS backends, and content management systems, with the InnoDB storage engine providing ACID transactions, row-level locking, and crash recovery. The official image listens on port 3306, is initialized through environment variables such as MYSQL_ROOT_PASSWORD and MYSQL_DATABASE, runs SQL scripts placed in /docker-entrypoint-initdb.d on first start, and persists data to a mounted volume. It is used by application developers running local and CI databases, by platform teams operating replicated MySQL on Kubernetes, and by operators who need a reproducible, version-pinned database across development, staging, and production.

What is Echo's MySQL image?

Echo's MySQL image is a hardened build of MySQL on Echo's hardened base. Echo images are designed to be a drop-in replacement: swap the image reference in your Dockerfile or deployment manifest and CVEs go to zero without disrupting your my.cnf settings, replication topology, and data volumes. Every image is tested across clouds, image use cases, and deployment targets. Echo ships every image in two variants:

• Distroless variant — optimized for runtime use, with the smallest possible attack surface
• Default variant — includes essential build tools, package managers, and shells for teams that need operational access

For production MySQL deployments, the distroless variant keeps all runtime operations — query execution, InnoDB storage, replication, and backup operations — fully intact while minimizing exposure; the default variant suits database and platform teams that need shell access for running the mysql client, tuning my.cnf, or diagnosing replication and slow queries.

What is the difference between Echo's MySQL image and the public MySQL image?

Public MySQL images ship on bases that include OS-level tooling convenient for development but which contribute CVEs that accumulate on a database server used in production. MySQL images run continuously with access to application data, user credentials, and replication credentials. OS-level CVEs in the base image — particularly in libraries such as openssl, zlib, and libaio — create exploitable paths that bypass application-layer controls entirely, allowing attackers to move from a network-reachable service to host-level access. For teams running MySQL across many environments, the image is also a steady source of scanner noise in the CI pipeline — every package in the base becomes a finding your security team must triage, even when none of it is reachable from the service. Echo's build retains everything MySQL needs for query execution, InnoDB storage, replication, and backup operations while removing the packages that don't belong in a production MySQL database server. As we covered in our post on how to protect your company from software supply chain attacks, long-running services that hold sensitive data and listen on the network are among the widest attack surfaces in the container stack. Echo commits to a 7-day SLA for critical and high severity vulnerabilities, and 10 days for medium, low, and unknown — with vulnerabilities triaged within 24 hours. Echo images are recognized by all major scanners and mirrored to all major registries, so they fit into existing pipelines without changing your registry, scanner, or runtime tooling.

FAQ

Can I replace my MySQL image with Echo's MySQL image?

Yes. Echo's MySQL image is a drop-in replacement. Update the FROM line in your Dockerfile and your workloads keep running. Replication, authentication plugins, TLS settings, initialization scripts, and mounted data volumes all continue to work without changes to your schemas, connection strings, or backup tooling.

Is Echo's MySQL image FIPS-validated?

Yes. Echo's FIPS-validated images use cryptographic modules with an active FIPS 140-3 CMVP certificate, making them fit for federal use — unlike FIPS-compliant images that haven't been validated. This matters for teams running MySQL workloads inside FedRAMP boundaries, where a database server that stores transactional data and authenticates client connections must meet cryptographic requirements across the full stack — including the OpenSSL and TLS libraries bundled with the MySQL image.

What is Echo's vulnerability management SLA on the MySQL image?

Echo commits to a 7-day SLA for critical and high severity vulnerabilities, and 10 days for medium, low, and unknown — with vulnerabilities triaged within 24 hours. Patches are mirrored automatically into your private registry so you're always running a clean version — critical for a long-running service that holds application data, user credentials, and replication credentials and is reachable over the network.

Is Echo's MySQL image distroless?

Echo ships every image in two variants: a distroless variant optimized for runtime use, and a default variant that includes essential build tools, package managers, and shells. For production MySQL deployments, the distroless variant is the leaner, more secure choice; for database and platform teams that need shell access for running the mysql client, tuning my.cnf, or diagnosing replication and slow queries, the default variant is the right fit.

How does Echo achieve such a drastic CVE reduction in MySQL?

Echo's MySQL image is built from source with only the absolute essentials needed to run the MySQL database server, which significantly shrinks the attack surface. Echo also patches aggressively over time, with backports available so you can stay on the MySQL version your applications and their dependencies are certified against — avoiding a disruptive upgrade forced purely by OS-level vulnerabilities in the base image rather than by your own requirements.

Will Echo's MySQL image help us achieve FedRAMP?

Yes. The hard parts of FedRAMP — managing vulnerabilities, applying fixes, and using FIPS-validated cryptography — are baked into Echo images, including STIG-hardened configuration and ConMon/POA&M-ready reporting. For database and platform teams running MySQL under an ATO — whether that's a transactional system of record, a web application backend, or a reporting database holding government data — Echo's hardened MySQL image keeps the database server layer in-boundary and compliant without requiring custom hardening scripts or manual base image patching between compliance cycles.

‍