Container Image Scanning: Mengidentifikasi dan Mitigasi Kerentanan di Docker & Kubernetes Anda

1. Pendahuluan

Di dunia pengembangan web modern, Docker dan Kubernetes telah menjadi tulang punggung bagi banyak aplikasi. Mereka memungkinkan kita untuk mengemas aplikasi beserta semua dependensinya ke dalam container yang portabel dan dapat dijalankan di mana saja. Keren, kan? Tapi, kemudahan ini datang dengan tanggung jawab baru: keamanan container.

Banyak developer fokus pada keamanan kode aplikasi mereka, yang tentu saja sangat penting. Namun, seringkali terlupakan bahwa aplikasi kita tidak berdiri sendiri. Ia berjalan di atas base image, menggunakan berbagai library pihak ketiga, dan dikemas dalam image Docker yang kompleks. Setiap lapisan ini bisa menjadi pintu masuk bagi kerentanan keamanan. Bayangkan jika aplikasi Anda seaman benteng, tapi fondasinya rapuh karena ada celah di salah satu dependensi di dalam image Docker Anda. 😱

Di sinilah Container Image Scanning berperan. Ini adalah praktik penting dalam DevSecOps yang bertujuan untuk mengidentifikasi kerentanan keamanan di dalam image container Anda bahkan sebelum mereka mencapai produksi. Dengan memindai image secara proaktif, kita bisa “menggeser keamanan ke kiri” (shift-left security), menemukan masalah lebih awal, dan mencegahnya menjadi bom waktu di lingkungan produksi.

Artikel ini akan memandu Anda memahami mengapa image scanning sangat krusial, jenis kerentanan apa yang dicari, tools populer yang bisa Anda gunakan, serta strategi praktis untuk mengintegrasikannya ke dalam workflow pengembangan Anda. Mari kita bangun aplikasi yang bukan hanya cepat dan skalabel, tapi juga tangguh dan aman!

2. Apa Itu Container Image Scanning dan Mengapa Penting?

Secara sederhana, Container Image Scanning adalah proses menganalisis image Docker atau OCI (Open Container Initiative) lainnya untuk menemukan kerentanan keamanan, miskonfigurasi, atau masalah kepatuhan lainnya.

💡 Mengapa tidak cukup hanya mengamankan runtime container?

Beberapa developer mungkin berpikir, “Ah, nanti saja kita amankan saat container sudah berjalan di Kubernetes.” Ini adalah pemahaman yang keliru. Mengapa?

Kerentanan di Build Time: Banyak kerentanan berasal dari dependensi yang disertakan saat image dibangun (misalnya, versi lama dari library openssl atau log4j). Kerentanan ini sudah ada di dalam image bahkan sebelum container diluncurkan.
Permukaan Serangan yang Lebih Kecil: Dengan memindai di awal, Anda bisa mencegah image yang rentan masuk ke registry atau, lebih parah, ke produksi. Ini mengurangi permukaan serangan secara signifikan.
Biaya Perbaikan Lebih Murah: Menemukan dan memperbaiki kerentanan di tahap pengembangan jauh lebih murah daripada memperbaikinya di produksi, di mana dampaknya bisa jadi insiden keamanan, downtime, atau pelanggaran data.

📌 Analoginya: Memeriksa kualitas bahan bangunan sebelum membangun rumah (image scanning) jauh lebih baik daripada mencari retakan di fondasi setelah rumah jadi dan dihuni (runtime security). Keduanya penting, tapi yang pertama mencegah masalah struktural sejak awal.

3. Jenis-jenis Kerentanan yang Dicari

Scanner image container biasanya mencari beberapa kategori kerentanan:

Common Vulnerabilities and Exposures (CVEs): Ini adalah daftar kerentanan keamanan yang diketahui dan teridentifikasi secara publik di berbagai software dan library. Scanner akan membandingkan komponen di image Anda dengan database CVEs yang luas.
- Contoh: Versi glibc yang rentan, openssl dengan bug keamanan, atau dependensi NPM/PyPI/Maven yang sudah diketahui memiliki CVE.
Miskonfigurasi (Misconfigurations): Ini bisa berupa pengaturan yang tidak aman di dalam image itu sendiri atau di Dockerfile yang digunakan untuk membangunnya.
- Contoh: Menggunakan root sebagai user default, mengekspos port yang tidak perlu, atau menyertakan secrets dalam image.
Secrets yang Bocor (Leaked Secrets): Terkadang, tanpa sengaja secrets seperti API key, token, atau kredensial database bisa masuk ke dalam image saat proses build. Ini adalah risiko besar!
- Contoh: File .env atau kunci SSH yang tidak sengaja tercopy ke dalam image.
Informasi Lisensi (License Information): Meskipun bukan kerentanan keamanan langsung, scanner juga bisa membantu mengidentifikasi lisensi open-source yang digunakan dalam image. Ini penting untuk kepatuhan hukum, terutama di lingkungan korporat.

4. Tools Populer untuk Container Image Scanning

Ada banyak tools yang tersedia, baik open-source maupun komersial. Berikut adalah beberapa yang populer dan sering digunakan:

4.1. Trivy: Scanner Simpel dan Efektif

Trivy adalah salah satu scanner kerentanan open-source yang paling populer dan mudah digunakan. Ia mendukung pemindaian image OS (Alpine, RHEL, CentOS, dll.), dependensi application-specific (Bundler, Composer, npm, yarn, pip, dll.), dan bahkan Infrastructure as Code (IaC).

Cara Menggunakan Trivy (CLI)

Pertama, instal Trivy. Anda bisa melihat dokumentasi resminya untuk cara instalasi sesuai OS Anda. Di Linux, bisa seperti ini:

# Untuk Debian/Ubuntu
sudo apt-get install wget apt-transport-https gnupg
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo deb https://aquasecurity.github.io/trivy-repo/deb/ stable main | sudo tee /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install trivy

# Atau via Homebrew di macOS
brew install aquasecurity/trivy/trivy

Setelah terinstal, Anda bisa langsung memindai image Docker:

# Memindai image nginx terbaru
trivy image nginx:latest

# Memindai image Anda sendiri
trivy image my-app:1.0.0

# Memindai dengan output JSON (berguna untuk CI/CD)
trivy image --format json -o report.json my-app:1.0.0

# Memindai hanya kerentanan dengan tingkat keparahan CRITICAL atau HIGH
trivy image --severity CRITICAL,HIGH my-app:1.0.0

✅ Contoh Output Trivy (disimplifikasi):

2023-10-26T10:00:00Z INFO Detecting OS vulnerabilities...
2023-10-26T10:00:00Z INFO Detecting application vulnerabilities...

nginx:latest (debian 11.7)
==========================
Total: 10 (HIGH: 2, MEDIUM: 5, LOW: 3)

┌──────────────────┬───────────────────┬───────────┬───────────────────┬──────────────────────────────────────────────────────────┐
│     Library      │   Vulnerability   │ Severity  │ Installed Version │                   Fixed Version                    │
├──────────────────┼───────────────────┼───────────┼───────────────────┼──────────────────────────────────────────────────────────┤
│ libexpat1        │ CVE-2022-43680    │ HIGH      │ 2.2.10-2+deb11u4  │ 2.2.10-2+deb11u5                                         │
│                  │                   │           │                   │                                                          │
│ curl             │ CVE-2023-38545    │ HIGH      │ 7.74.0-1.3+deb11u1│ 7.74.0-1.3+deb11u2                                       │
│                  │                   │           │                   │                                                          │
│ openssl          │ CVE-2023-0464     │ MEDIUM    │ 1.1.1n-0+deb11u5  │ 1.1.1n-0+deb11u6                                         │
└──────────────────┴───────────────────┴───────────┴───────────────────┴──────────────────────────────────────────────────────────┘

Output ini sangat jelas, menunjukkan library yang rentan, CVE-nya, tingkat keparahan, versi terinstal, dan versi yang sudah diperbaiki. Ini adalah informasi yang Anda butuhkan untuk mengambil tindakan.

4.2. Clair

Clair adalah open-source vulnerability scanner yang dikembangkan oleh CoreOS (sekarang Red Hat). Clair biasanya berjalan sebagai service dan mengindeks image container Anda, kemudian mencocokkannya dengan database kerentanan yang terus diperbarui. Ini lebih cocok untuk skala besar dan integrasi dengan container registry seperti Harbor.

4.3. Aqua Security (Komunitas & Komersial)

Aqua Security adalah pemimpin di bidang keamanan cloud-native. Mereka menyediakan berbagai solusi, termasuk Trivy (yang mereka akuisisi), serta platform komersial yang lebih lengkap untuk vulnerability scanning, runtime protection, dan compliance di seluruh siklus hidup container.

4.4. Harbor (Container Registry dengan Scanning)

Harbor adalah open-source container registry yang menawarkan fitur image scanning bawaan (menggunakan Clair atau Trivy). Jika Anda menjalankan private container registry, Harbor adalah pilihan yang sangat baik karena ia mengintegrasikan pemindaian langsung ke dalam alur kerja registry. Setiap image yang di-push bisa langsung dipindai.

5. Integrasi dalam Pipeline CI/CD: Shift-Left Security

🎯 Kunci dari image scanning yang efektif adalah mengintegrasikannya ke dalam pipeline CI/CD Anda. Ini memungkinkan Anda untuk secara otomatis memindai image setiap kali ada perubahan kode atau build baru, dan bahkan menghentikan build jika ditemukan kerentanan serius.

Berikut adalah alur kerja yang direkomendasikan:

Build Image: Setelah kode Anda di-commit dan di-build, Docker image akan dibuat.
Scan Image: Sebelum image di-push ke container registry, jalankan vulnerability scanner (misalnya Trivy).
Evaluasi Hasil: Analisis laporan scanning.
- Jika ditemukan kerentanan CRITICAL atau HIGH, Anda bisa mengkonfigurasi pipeline untuk gagal (fail). Ini mencegah image yang sangat rentan masuk ke registry.
- Untuk kerentanan MEDIUM atau LOW, Anda bisa memutuskan untuk melanjutkan build tetapi mencatatnya sebagai peringatan untuk ditangani nanti.
Push ke Registry: Jika scanning berhasil (atau sesuai kebijakan), image di-push ke container registry Anda.
Deploy ke Lingkungan Staging/Produksi: Image yang sudah “bersih” kemudian bisa di-deploy.

Contoh Integrasi Trivy di GitLab CI/CD (Konsep)

# .gitlab-ci.yml
stages:
  - build
  - scan
  - push

variables:
  DOCKER_IMAGE_NAME: my-app
  DOCKER_IMAGE_TAG: $CI_COMMIT_SHORT_SHA

build_image:
  stage: build
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t $DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG .
    - docker save $DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG > my-app.tar # Simpan image untuk stage selanjutnya
  artifacts:
    paths:
      - my-app.tar

scan_image:
  stage: scan
  image: docker:latest # Menggunakan image docker untuk akses dind
  services:
    - docker:dind
  before_script:
    - apk add --no-cache wget # Instal wget untuk Trivy
    - wget -qO - https://aquasecurity.github.io/trivy-repo/apk/delcar.pub | apk add -uU /dev/stdin # Tambah public key Trivy
    - echo https://aquasecurity.github.io/trivy-repo/apk/ >> /etc/apk/repositories # Tambah repo Trivy
    - apk add --no-cache trivy # Instal Trivy
    - docker load -i my-app.tar # Load image yang sudah di-build
  script:
    - trivy image --severity CRITICAL,HIGH --exit-code 1 $DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG
    # --exit-code 1 akan membuat pipeline gagal jika ada kerentanan CRITICAL atau HIGH
    - echo "Image scanning completed successfully."
  dependencies:
    - build_image

push_image:
  stage: push
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker load -i my-app.tar
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker tag $DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG $CI_REGISTRY/$CI_PROJECT_PATH/$DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG
    - docker push $CI_REGISTRY/$CI_PROJECT_PATH/$DOCKER_IMAGE_NAME:$DOCKER_IMAGE_TAG
  dependencies:
    - scan_image
  only:
    - main # Hanya push ke registry jika di branch main

⚠️ Penting: Pastikan Anda memahami dan menyesuaikan exit code dan severity threshold Trivy dengan kebijakan keamanan tim Anda. Terlalu ketat bisa menghambat pengembangan, terlalu longgar bisa membahayakan.

6. Strategi Mitigasi dan Best Practices

Menemukan kerentanan adalah langkah pertama, memperbaikinya adalah langkah selanjutnya. Berikut adalah beberapa strategi dan best practices:

Pilih Base Image yang Minimal dan Terpercaya:
- ❌ Hindari ubuntu:latest atau debian:latest sebagai base image untuk aplikasi produksi Anda. Mereka seringkali memiliki banyak package yang tidak perlu dan meningkatkan permukaan serangan.
- ✅ Gunakan base image yang lebih kecil dan bertujuan tunggal seperti alpine, distroless, atau runtime image spesifik (misalnya node:lts-slim, python:3.9-slim-buster). Ini mengurangi jumlah komponen yang perlu dipindai dan potensi kerentanan.
- ✅ Selalu gunakan tag yang spesifik dan immutable (misalnya node:18-alpine bukan node:latest) untuk reproduksibilitas.
Minimalisasi Dependensi:
- Hanya instal package dan library yang benar-benar dibutuhkan oleh aplikasi Anda.
- Hapus build dependencies setelah proses build selesai (lihat multi-stage builds di bawah).
Perbarui Dependensi Secara Berkala:
- Kerentanan baru ditemukan setiap hari. Pastikan Anda secara rutin memperbarui base image dan dependensi aplikasi Anda ke versi terbaru yang aman. Otomatisasi proses ini dengan Dependabot atau RenovateBot.

Gunakan Multi-Stage Builds:

Ini adalah praktik terbaik Dockerfile untuk membuat image produksi yang ramping dan aman. Anda menggunakan satu stage untuk build aplikasi dengan semua tools yang dibutuhkan, lalu stage lain untuk menyalin hanya executable dan dependensi runtime ke base image yang minimal.
Contoh:

# Stage 1: Build aplikasi
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

# Stage 2: Image produksi yang ramping
FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/build ./build
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["npm", "start"]

Dengan cara ini, tools build (seperti kompiler, linter, dll.) tidak akan ada di image produksi Anda.

Pahami dan Tangani False Positives:
- Terkadang, scanner mungkin melaporkan kerentanan di komponen yang sebenarnya tidak dieksekusi atau tidak dapat dieksploitasi dalam konteks aplikasi Anda. Ini disebut false positive.
- Pahami laporan, lakukan riset, dan jika memang false positive, Anda bisa menekan (suppress) laporan tersebut dengan alasan yang jelas. Namun, jangan jadikan ini alasan untuk mengabaikan semua laporan!
Tentukan Kebijakan (Policy) dan Ambang Batas (Threshold):
- Tim Anda harus menyepakati tingkat keparahan (severity) kerentanan apa yang dapat diterima dan apa yang harus segera diperbaiki.
- Misalnya, semua kerentanan CRITICAL dan HIGH harus diperbaiki sebelum image di-deploy ke produksi. Kerentanan MEDIUM mungkin diberi batas waktu perbaikan 7 hari.
- Integrasikan kebijakan ini langsung ke pipeline CI/CD Anda dengan --exit-code pada scanner.
Scan Secara Berkala di Registry:
- Bahkan setelah image di-push ke registry, kerentanan baru bisa ditemukan di kemudian hari. Gunakan fitur scanning otomatis di container registry Anda (seperti Harbor, AWS ECR, Google Container Registry) untuk memindai image secara berkala dan mendapatkan notifikasi tentang kerentanan baru.

Kesimpulan

Container Image Scanning bukan lagi pilihan, melainkan keharusan mutlak dalam pengembangan aplikasi modern yang menggunakan Docker dan Kubernetes. Dengan mengintegrasikan scanning ke dalam pipeline CI/CD Anda, memilih base image yang tepat, dan secara proaktif mengelola dependensi, Anda telah mengambil langkah besar dalam membangun aplikasi yang lebih aman dan tangguh.

Ingat, keamanan adalah tanggung jawab bersama. Dengan tools dan praktik yang tepat, kita bisa “menggeser keamanan ke kiri” dan memastikan setiap image yang kita deploy sebersih dan seaman mungkin. Mari jadikan image scanning sebagai bagian tak terpisahkan dari workflow pengembangan Anda!