gcc
The official GCC image — the GNU Compiler Collection, providing compilers for C, C++, and other languages for building native software in containers and CI pipelines.
What is GCC?
The GCC image packages the GNU Compiler Collection, including gcc and g++ along with the toolchain pieces needed to compile native code, so you can build C and C++ software in a container without installing a compiler on the host. GCC is the long-standing standard compiler for the open-source world, used to build the Linux kernel, system libraries, databases, and countless applications, and it also supports languages such as Fortran, Go, and Ada. The official image is published with a version tag for each GCC release, which lets teams pin an exact compiler for reproducible builds, and it is commonly used as the build stage of a multi-stage Dockerfile and as a CI job image for compiling and testing native code. It is used by systems and embedded teams, by open-source maintainers, and by platform teams standardizing a toolchain.
What is Echo's GCC image?
Echo's GCC image is a hardened build of GCC 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 Makefiles, CMake builds, compiler flags, and CI pipeline configuration. 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 GCC deployments, the distroless variant keeps all runtime operations — compilation, linking, build tool execution, and test builds — fully intact while minimizing exposure; the default variant suits systems and platform teams that need shell access for debugging builds, inspecting headers and libraries, or running ad-hoc compiler commands.
What is the difference between Echo's GCC image and the public GCC image?
Public GCC images ship on bases that include OS-level tooling convenient for development but which contribute CVEs that accumulate on a build toolchain environment used in production. GCC images run inside CI pipelines and operational jobs with access to source code, build credentials, and release artifacts. OS-level CVEs in the base image — particularly in libraries such as glibc, binutils, make, and openssl — create exploitable paths in an environment that application-level controls never see. Because tooling images are pulled and executed constantly across pipelines, they are also a steady source of scanner noise — every package in the base becomes a finding your security team must triage, even when none of it is exercised by the job. Echo's build retains everything GCC needs for compilation, linking, build tool execution, and test builds while removing the packages that don't belong in a production GCC build toolchain environment. As we covered in our post on how to protect your company from software supply chain attacks, build and automation images that run with access to source code, credentials, and deployment targets are a high-value path into everything downstream. 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 GCC image with Echo's GCC image?
Yes. Echo's GCC image is a drop-in replacement. Update the FROM line in your Dockerfile and your workloads keep running. Makefiles, CMake and autotools builds, compiler and linker flags, pinned GCC versions, and test builds all continue to work without changes to your source code or CI configuration.
Is Echo's GCC 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 GCC workloads inside FedRAMP boundaries, where a build toolchain environment that compiles code and produces the binaries that ship downstream must meet cryptographic requirements across the full stack — including the OpenSSL and TLS libraries bundled with the GCC image.
What is Echo's vulnerability management SLA on the GCC 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 tooling image that is pulled and run constantly across pipelines with access to source code, build credentials, and release artifacts.
Is Echo's GCC 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 GCC deployments, the distroless variant is the leaner, more secure choice; for systems and platform teams that need shell access for debugging builds, inspecting headers and libraries, or running ad-hoc compiler commands, the default variant is the right fit.
How does Echo achieve such a drastic CVE reduction in GCC?
Echo's GCC image is built from source with only the absolute essentials needed to run the GCC build toolchain environment, which significantly shrinks the attack surface. Echo also patches aggressively over time, with backports available so you can stay on the GCC 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 GCC 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 systems and platform teams running GCC under an ATO — whether that's native service builds, embedded firmware toolchains, or compiled libraries shipped into government environments — Echo's hardened GCC image keeps the build toolchain environment layer in-boundary and compliant without requiring custom hardening scripts or manual base image patching between compliance cycles.
.avif)