Saya Memindai 30 Image Docker Populer. 10 Masih Percaya Root CA yang Sudah Dicabut Chrome

Versi bahasa Inggris dengan metodologi lengkap: The eMudhra Fallout, Part 2: I Scanned 30 Docker Images.

Mulai 27 Oktober 2026, Chrome menghapus emSign ECC Root CA - G3 dari daftar root yang dipercayainya. Mozilla NSS sudah menghapusnya sejak 20 Oktober. Browser di laptop kamu sudah aman. Pertanyaan yang lebih penting untuk tim backend: bagaimana dengan image Docker yang kamu pakai minggu ini?

Saya memindai 30 image Docker paling umum dan membuka setiap trust store di dalamnya. Hasilnya: 10 image masih membawa root yang sudah dicabut itu.

TL;DR

• Setelah insiden kunci lemah di delapan intermediate CA eMudhra, Mozilla mencabut root emSign ECC Root CA - G3 pada 20 Oktober, dan Chrome menyusul pada 27 Oktober. Browser memperbarui dirinya sendiri; image container tidak.
• Dari 30 image yang saya pindai pada 24 Oktober 2026: 10 masih membawa G3, 10 sudah tanpa G3, dan 10 tidak punya bundle CA sama sekali.
• Image yang terlihat “sudah dipatch” bisa tetap rentan: python:3.12-slim bersih di bundle sistem, tapi salinan certifi di dalam pip masih membawa G3.
• Image baru belum tentu sudah berisi perbaikan: amazonlinux:2023 dan amazoncorretto:21 dibangun 23 Oktober, tiga hari setelah perbaikan NSS, dan masih membawa keempat root emSign.
• Perbaikannya murah: cari semua bundle, cek isinya, lalu rebuild dengan --pull. Checklist lengkapnya ada di bawah.

Kenapa ini urusan backend, bukan browser

Chrome memblokir delapan intermediate CA itu lewat CRLSet dalam hitungan jam setelah laporan masuk pada 17 Oktober (Google Security Blog). Firefox terlindungi lewat OneCRL pada 19 Oktober. Lalu NSS 3.131.1 pada 20 Oktober mencabut kepercayaan pada emSign ECC Root CA - G3, emSign Root CA - C1, dan emSign ECC Root CA - C3 (oss-security).

Masalahnya, CRLSet dan OneCRL hanya dipakai browser. curl, requests di Python, net/http di Go, Node, dan JVM tidak membacanya, dan secara default juga tidak mengecek revocation. Untuk aplikasi seperti itu, satu-satunya kontrol adalah isi trust store. Kalau root-nya masih ada di sana, aplikasi akan tetap menerima rantai sertifikat ke root tersebut.

Hasil pemindaian

Saya membaca layer image langsung dari registry (tanpa Docker daemon), mengambil isi akhir setiap trust store, lalu memeriksa sertifikat di dalamnya. Yang diperiksa: bundle sistem (/etc/ssl/certs/ca-certificates.crt dan padanannya di keluarga RHEL), certifi/cacert.pem, dan cacerts milik Java.

Kelompok	Image
Masih membawa G3 (10)	alpine:3.20, golang:1.24-alpine, amazonlinux:2023, amazoncorretto:21, eclipse-temurin:17-jre, eclipse-temurin:21-jre, distroless base-debian12, distroless static-debian12, python:3.12-slim, python:3.12-alpine
Bundle ada, G3 sudah hilang (10; empat di antaranya, berbasis Debian trixie, masih membawa root C1 dan C3 yang juga dicabut NSS)	alpine:3.22, alpine:latest, redhat/ubi9-minimal, python:3.13, python:3.13-slim, node:22-alpine, nginx:stable, nginx:alpine, httpd:2.4, curlimages/curl
Tidak ada bundle CA (10)	debian:12, debian:12-slim, debian:13-slim, ubuntu:22.04, ubuntu:24.04, node:20-slim, node:22-slim, node:24-slim, redis:7, postgres:16

Tiga pelajaran yang paling berguna untuk tim:

1. Satu image bisa punya lebih dari satu trust store. python:3.12-slim sudah bersih di bundle sistem, tapi pip membawa salinan certifi sendiri yang masih berisi G3. Image Java seperti Temurin punya bundle Ubuntu dan cacerts milik JDK, dan keduanya masih membawa G3.

2. Tanggal build bukan jaminan. amazonlinux:2023 dan amazoncorretto:21 dibangun 23 Oktober, tapi keempat root emSign masih ada di dalamnya.

3. “Tidak ada bundle” bukan berarti aman. debian:12-slim dan image node:*-slim tidak membawa ca-certificates. Begitu Dockerfile kamu menjalankan apt-get install ca-certificates, versi yang terpasang tergantung mirror hari itu, atau cache build lama kamu.

Checklist untuk tim

Jalankan di dalam container dari image kamu sendiri, bukan base image-nya, karena layer kamu bisa menambah trust store baru. Image minimal (Alpine, distroless) sering tidak punya openssl, keytool, bahkan shell; untuk image seperti itu, docker create image-nya lalu salin file bundle dengan docker cp dan periksa di mesin kamu.

1. Inventaris trust store

find / \( -name 'ca-certificates.crt' -o -name 'cacert.pem' -o -name 'ca-bundle.crt' -o -name cacerts \) 2>/dev/null

2. Cek root di setiap bundle PEM

openssl storeutl -noout -text -certs /etc/ssl/certs/ca-certificates.crt | grep 'emSign ECC Root CA - G3'

3. Cek keystore Java

keytool -list -cacerts -storepass changeit | grep -i emsign

4. Rebuild dari layer segar, lalu ulangi langkah 1 sampai 3

docker build --pull --no-cache -t aplikasi:ca-refresh .

5. Perbaiki sesuai jenis store

• Bundle sistem: pakai base image yang sudah memuat ca-certificates terbaru, atau tambahkan apt-get update && apt-get install -y ca-certificates / apk upgrade ca-certificates di layer kamu.
• certifi: jalankan pip install -U certifi (menurut Endor Labs dan SafeDep, versi 2026.10.19 sudah menghapus G3). Salinan certifi di dalam pip baru ikut berubah kalau pip-nya diperbarui. Lebih baik lagi, arahkan Python ke bundle sistem dengan SSL_CERT_FILE, supaya hanya ada satu bundle yang perlu dirawat.
• Java: pakai build JDK yang sudah memuat pembaruan, atau hapus alias emSign dari cacerts dengan keytool -delete sampai vendor JDK merilis versi baru.

6. Jadikan rutin. Jadwalkan rebuild mingguan dengan --pull dan tambahkan langkah 2 sebagai cek di CI. Insiden CA berikutnya akan datang, dan yang menentukan seberapa cepat kamu aman adalah jadwal rebuild, bukan jadwal browser.

Batasan data

• Pemindaian dilakukan sekali, 24 Oktober 2026, untuk linux/amd64. Tag image terus bergerak, jadi ulangi sebelum mengutip angka ini.
• Yang diperiksa hanya bundle sistem, certifi, dan cacerts Java. Trust store bawaan Node dan bundle yang dibawa aplikasi tidak termasuk.
• Versi paket perbaikan per distro berasal dari sumber sekunder (Endor Labs, SafeDep), kecuali yang terlihat langsung di image.
• Keberadaan root hanya menunjukkan bahwa klien akan menerima rantai ke root itu, bukan bukti ada serangan.

Penutup

Vendor browser menangani insiden ini dalam hitungan jam. Image container punya jalur pasokan yang berbeda, dengan jam yang berbeda, dan tidak akan berubah sampai kamu rebuild. Empat perintah di checklist di atas cukup untuk tahu posisi tim kamu hari ini.

Di tim kamu, siapa yang bertanggung jawab memastikan trust store di image produksi tetap mutakhir?