---
title: "Docker İmajları'nın Güvenilirliği Nasıl Kontrol Edilir?"
slug: "005-docker-imajlarinin-guvenilirligi-nasil-kontrol-edilir"
date: "2024-12-19"
category: "linux"
tags: ["linux","docker","security","devops"]
excerpt: "Bu yazıda, Docker projelerinizin güvenliğini nasıl sağlayabileceğinizi detaylı bir şekilde ele alacağız."
coverImage: "/images/posts/005-docker-imajlarinin-guvenilirligi-nasil-kontrol-edilir/cover.webp"
author: "Erhan ÜRGÜN"
seoTitle: "Docker İmajları'nın Güvenilirliği Nasıl Kontrol Edilir?"
seoDescription: "Bu yazıda, Docker projelerinizin güvenliğini nasıl sağlayabileceğinizi detaylı bir şekilde ele alacağız."
featured: false
published: true
---

Bilgisayarınızda veya sunucunuzda çalışan Docker tabanlı uygulamalar ne kadar güvenli? Bilmediğiniz açıklar nedeniyle hack'lenmek an meselesi olabilir.

Aralık 2025'te paylaşılan bir araştırma, Docker Hub'da 10 binden fazla imajın içinde public olarak erişilebilen veritabanı şifreleri, API anahtarları ve bulut servis kimlik bilgileri barındırdığını ortaya koydu. Saldırganların doğrudan kullanabileceği bilgilerden bahsediyoruz; rakamı görünce ben de oldukça şaşırdım.

Backend geliştirici olarak Docker ile her gün çalışıyorum: API geliştirirken, CI/CD pipeline'ları kurarken. Container teknolojisi artık vazgeçilmez. Ama bu gücün yanında gelen sorumluluk, konuştuğum geliştiricilerin önemli kısmında karşılığını bulmuyor. Bu yazıda Docker imajlarını gerçek anlamda güvenli hale getirmek için kullandığım pratik adımları derliyorum.

## Docker İçin İlk Adımlar: Sistem ve Konteyner Analizi

Docker güvenliğinden bahsetmek kolaydır, ancak uygulamak başka. Başlangıç noktalarından biri, sisteminizde çalışan konteynerlerin detaylı analizidir. Çünkü **ne güvence altına alırız, bunu başlangıçta görmemiz lazım.**

### 1. Konteynerlerin Aktif Durumunu Kontrol Edin

Docker imajının ve ona bağlı konteynerlerin güvenliğinden emin olmak için ilk adım, çalışan konteynerlerin durumunu ve davranışlarını analizlemektir. Bunun için basit fakat güçlü komutlar var:

```bash
# Tüm konteynerlerin durumunu listeleyin (aktif ve durdurulmuş)
docker ps -a

# Belirli bir konteynerde çalışan prosesleri inceleyin
docker top <CONTAINER_NAME>

# Konteynerde yapılan değişiklikleri kontrol edin
docker diff <CONTAINER_ID>
```

**Senaryolar - Bunlar Size Ne Söylüyor?**

**Aktif Durumu Görüntüleyin:**

Bir Docker imajı kullanarak çalıştırdığınız uygulamada beklenmeyen bir davranış varsa, ilk yapmanız gereken şey `docker ps -a` komutudur. Çıktı şuna benzer olabilir:

```plaintext
CONTAINER ID  IMAGE        COMMAND                 STATUS              PORTS               NAMES
d1e8f5c6e987  nginx:latest "/docker-entrypoint.…"  Up 2 hours          0.0.0.0:80->80/tcp  web_server
a3f6c9e4a231  mysql:8.0    "docker-entrypoint.s…"  Exited (1) 2 days ago                   db_server
```

Burada ne görmeli ki? `web_server` konteyneri aktif durumda çalışıyor. Ancak `db_server` neden durdurulmuş? Eğer siz bu durdurmayı yapmadıysanız, bu bir sorun işareti olabilir. Çöküş mü yaşadı? Kaynak yetersizliği mi var? Zafiyet istismarı mı oldu?

**Prosesleri Analiz Edin:**

İmajın çalışan proseslerinde beklenmeyen bir işlem var mı? `docker top` ile bu durumu analiz edin:

```plaintext
UID         PID    PPID   C   STIME   TTY     TIME     CMD
root        1234   0      0   10:00   ?       00:00:05 nginx: master process
www-data    1240   1234   0   10:00   ?       00:00:02 nginx: worker process
```

Burada dikkat etmeniz gereken nokta: **Neden** `root` kullanıcısı olarak çalışıyor? Buna biraz sonra detaylı çözüm sunacağım, fakat şimdilik bilmeniz gereken şey, bu **kritik bir güvenlik sorunu** olduğudur.

**Konteyner Değişikliklerini Tespit Edin:**

`docker diff` komutu, konteynerin dosya sisteminde yapılan tüm değişiklikleri gösterir. Bu, imajınızın temiz olup olmadığını anlamanıza yardımcı olur:

```plaintext
C /etc
A /etc/my.cnf
D /var/lib/mysql/tmp
```

Burada:

* **C /etc**: `/etc` dizini değiştirilmiş
 
* **A /etc/my.cnf**: Yeni bir dosya eklenmiş
 
* **D /var/lib/mysql/tmp**: Bir dosya veya dizin silinmiş
 

**Uyarı:** Eğer bu değişiklikler imajın temel alındığı duruma uymuyorsa, anormal bir etkinlik söz konusu olabilir. Bir saldırgan veya yanlış yapılandırma, konteynerı değiş tokuş etmiş olabilir.

### 2. Proses Ağacına Derinlemesine Bakarak Anormallikleri Keşfedin

Belki konteyner içindeki basit prosesler yeterli değil. Daha derin bir analiz için **pstree** aracını kullanabilirsiniz:

```bash
# Proses ağacını görüntülemek için
(command -v pstree || sudo apt install -y psmisc) && pstree -p
```

Bu komut, tüm proseslerin bağımlılık ağacını gösterir. Saldırgan bir proses çalıştırıyor mu? Şüpheli bir bağlantı var mı? Bu komut ortaya çıkarır. (**btop** gibi araçlar ile de kontrol sağlayabilirsiniz)

## Docker Konteynerlerinin Taraması: Güvenlik Zafiyetlerini Bulma

Bu noktada sorunun gerçek boyutu ortaya çıkıyor. Docker imajları, çoğu zaman üçüncü taraf kaynaklardan gelir ve bu kaynakların güvenilir olduğunu varsaymak **tehlikeli bir hata** olabilir. Zafiyet tespiti için ise **Docker Scout, Trivy** gibi yeni nesil araçlar kullanmalısınız.

### 1. **Docker Scout - Native Docker Çözümü**

**Docker Scout**, Docker'ın resmi güvenlik taraması aracıdır ve 2023'ten beri Docker Desktop ve CLI'nin içine entegre edilmiştir. Bu araç, **Docker Hub hesabınız** ile direkt çalışır ve ek kurulum gerektirmez. (Ama olurda gerekirse bkz: [https://docs.docker.com/scout/install](https://docs.docker.com/scout/install/))

**Neden Docker Scout Özel?**

* Docker CLI ve Desktop'a direkt entegredir
 
* Uygulamanızın tüm bileşenlerinin detaylı listesini sunar (**SBOM**)
 
* Yeni CVE'ler ortaya çıktığında otomatik olarak raporlarınız güncellenir
 
* Güvenlik açıklarını kapatmak için doğru sürüm önerileri sunar
 
* Vulnerability Exploitability eXchange - açıkların gerçekten kullanılabilir olup olmadığını gösterir (**VEX**)
 

**Kurulum ve Kullanım:**

**Docker Scout**, en son **Docker** sürümlerinde varsayılan olarak kurulu gelir. Kullanmak için yalnızca Docker Hub'a giriş yapmanız gerekir:

```bash
# Docker Hub hesabınıza giriş yapın
docker login

# Ardından imaj taraması yapabilirsiniz
# ör: docker scout cves {taranacak_imaj}
docker scout cves vitodeploy/vito:latest
```

**Docker Scout Komutları:**

```bash
# Hızlı genel bakış (5-10 saniye)
docker scout quickview vitodeploy/vito:latest

# Detaylı CVE raporu
docker scout cves vitodeploy/vito:latest

# Sadece kritik açıkları göster
docker scout cves --only-severity critical vitodeploy/vito:latest

# EPSS skor ile sıralama (Exploit Prediction Scoring System)
docker scout cves --epss vitodeploy/vito:latest

# JSON formatında çıktı (CI/CD'ye entegre etmek için)
docker scout cves --format json vitodeploy/vito:latest

# Sadece base imajdan gelen açıkları göster
docker scout cves --only-base vitodeploy/vito:latest

# Sadece düzeltilebilir açıkları göster
docker scout cves --only-fixed vitodeploy/vito:latest

# CISA KEV kataloğu içindeki tehlikeli açıkları göster
docker scout cves --only-cisa-kev vitodeploy/vito:latest

# SARIF formatında (güvenlik araçlarına entegre etmek için)
docker scout cves --format sarif --output scan_report.sarif vitodeploy/vito:latest

# Temel imaj güncelleme önerilerini görüntülek için
docker scout recommendations vitodeploy/vito:latest
```

**Docker Scout'un Avantajları:**

* **Kurulum yok** - Docker zaten kurlu ise hemen kullanılabilir
 
* **Docker Desktop UI** - Güzel görsel arayüz (Win/Mac vb)
 
* **Otomatik güncelleme** - Yeni CVE'ler bulunduğunda otomatik raporunuz güncellenir
 
* **VEX desteği** - Açıkların gerçekten exploitable olup olmadığını gösterir
 

**Docker Scout'un Sınırlamaları:**

* Docker Hub hesabı gerekli
 
* Remote imajları taramak için giriş gerekli
 
* Ücretsiz versiyon sadece açık kaynak projeler için tam özellikleri sunuyor
 
* Secret scanning ve IaC taraması desteklemez
 

### 2. **Trivy - Açık Kaynaklı Çok Amaçlı Çözüm**

**Trivy**, Docker Scout'tan daha fazla özellik sunan açık kaynaklı bir araçtır. Secret detection, IaC (Infrastructure as Code) taraması ve daha esnek kullanım seçenekleri sunar. ([https://trivy.dev](https://www.trivy.dev/))

Ben paket yöneticisi olarak **[nala](https://gitlab.com/volian/nala)**'yı kullanıyorum. Nala, APT'nin üzerine inşa edilmiş daha modern ve okunabilir bir arayüz. Kurulumları daha temiz gösteriyor, paralel indirme yapıyor ve işlem geçmişi tutuyor. Ama endişelenmeyin - eğer siz klasik APT kullanıyorsanız, komutlardaki `nala` yerine `apt` yazmanız yeterli. Birebir aynı şekilde çalışır.

**Kurulum:**

```bash
sudo nala install wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo nala update
sudo nala install trivy -y
```

**Kullanım:**

```bash
# Temel tarama
trivy image vitodeploy/vito:latest

# Sadece kritik açıkları göster
trivy image --severity CRITICAL vitodeploy/vito:latest

# JSON çıktısı
trivy image --format json vitodeploy/vito:latest

# Secret scanning de yap
trivy image --scan-secret vitodeploy/vito:latest

# IaC taraması (Dockerfile, YAML vb.)
trivy config ./

# SBOM oluştur
trivy image --format cyclonedx --output sbom.json vitodeploy/vito:latest

# Belirli bir CVE'yi ara
trivy image --severity HIGH,CRITICAL vitodeploy/vito:latest
```

**Trivy'nin Avantajları:**

* **Açık kaynaklı** - Tamamen özgür ve şeffaf
 
* **Çok amaçlı** - CVE, secret, IaC, Kubernetes taraması
 
* **Hızlı** - Docker Scout'dan hızlı çalışır
 
* **Giriş gerektirmez** - Kurulu ve kullanılmaya hazır
 
* **Esnek** - Birçok filtreleme seçeneği
 
* **SBOM desteği** - Software Bill of Material oluşturabilir
 

**Trivy'nin Sınırlamaları:**

* CLI odaklı - Grafik arayüzü yok
 
* Docker Scout kadar entegreli değil
 

### 3. **Grype - SBOM Odaklı Tarayıcı**

**Grype**, Chainguard tarafından geliştirilmiş, SBOM (Software Bill of Material) üzerinden tarama yapan bir araçtır. Hızlı, doğru ve hafif bir alternatif. ([https://github.com/anchore/grype](https://github.com/anchore/grype))

**Kurulum:**

```bash
curl -sSfL https://get.anchore.io/grype | sudo sh -s -- -b /usr/local/bin
```

**Kullanım:**

```bash
# Temel tarama
grype vitodeploy/vito:latest

# Table formatında
grype vitodeploy/vito:latest -o table

# JSON çıktısı
grype vitodeploy/vito:latest -o json

# Sadece kritik açıkları göster
grype vitodeploy/vito:latest --fail-on critical
```

**Grype'nin Avantajları:**

* **Çok hızlı** - En hızlı tarayıcılardan biri
 
* **Temiz çıktı** - Anlaması kolay raporlar
 
* **SBOM merkezli** - DevOps iş akışına uygun
 
* **Hafif** - Docker Scout'tan daha az kaynak kullanır
 

**Grype'nin Sınırlamaları:**

* Secret scanning yok
 
* IaC taraması yok
 

### 4. **Snyk - Kurumsal Çözüm**

**Snyk**, özellikle başarılı DevOps/DevSecOps ekipleri tarafından kullanılan, daha güçlü ve ticari bir araçtır. Dependency updates ve vulnerability remediation gibi advanced özellikleri sunar. ([https://snyk.io](https://snyk.io/))

**Kurulum:**

```bash
npm install -g snyk
snyk auth
```

**Kullanım:**

```bash
snyk container test vitodeploy/vito:latest
snyk container test --severity-threshold=high vitodeploy/vito:latest
```

### **Hangi Aracı Seçmeliyim?**

| Araç | Avantajı | Dezavantajı | Kurulum |
| --- | --- | --- | --- |
| **Docker Scout** | Native, entegre, otomatik update | Giriş gerekli, sınırlı özellik | Hazır (Docker içinde) |
| **Trivy** | Açık kaynaklı, çok amaçlı, hızlı | CLI odaklı | `apt install trivy` |
| **Grype** | Çok hızlı, hafif, temiz | Sınırlı özellik | `curl install` |
| **Snyk** | Kurumsal, otomatik fix | Ücretli, giriş gerekli | `npm install` |

**Başlangıç için tavsiye:** Docker Scout ile başlayın, daha sonra automation için Trivy'yi ekleyin.

## Tehdit Yüzeyi Anlamak: Docker'da Neler Yanlış Gidebilir?

Docker imajlarının güvenliğini sağlamadan önce, hangi risklere karşı korunmamız gerektiğini anlamak önemli. **Üç ana tehdidi kategorize edebilirim:**

**1. Bilinmeyen Açıklar (CVE - Common Vulnerabilities and Exposures)**

Base imajınızdan başlayarak, uygulamanızın bağımlılıkları arasında defalarca kez paket ve kütüphaneler kullanıyorsunuz. Ubuntu, Debian, Alpine Linux gibi base imajlar, hatta siz bile, bu paketlerin en son sürümünü kullanmıyor olabilirsiniz. Sonuç? **Binlerce bilinen açık, üretim ortamınızda canlı halde bekliyor.** Ama dikkat edin - her CVE kritik değildir. Bazı açıklar sizin kullanım durumunuzda hiç işlev görmeyebilir.

**2. Sırlar ve Kimlik Bilgileri**

Belki siz de yaptınız - build aşamasında bir .env dosyasını yanlışlıkla Docker imajınıza gömüştünüz. Ya da API anahtarını Dockerfile'a doğrudan yazdınız. Bu bilgiler imaja bir kez girdikten sonra, imajı çalıştırdığınız her container'da erişilebilir durumda kalıyor. Araştırmaya göre, kimlik bilgileri sızdırılan projelerin **%75'i**, kimlik bilgilerini revoke etmemiş - yani yıllarca hack edilebilir durumdalar.

**3. Kötü Niyetli İmajlar**

Docker Hub'da `mysqldatabase` veya `nginxserver` gibi, popüler araçlara benzeyen **sahte imajlar** bulunuyor. Siz yanlışlıkla bunları çektiğinizde, malware ve backdoor'lar doğrudan üretim ortamınıza giriyor.

## Adım Adım Çözümler: Docker İmajlarınızı Koruma Altına Almak

### 1. Non-Root Kullanıcı ile Çalıştırma - En Kritik Adım

En kritik güvenlik önlemi, konteynerı root olarak çalıştırmamaktır. Varsayılan olarak, Docker container'ları `root` kullanıcısı olarak çalıştırır. Eğer bir saldırgan container'a giriş yapabilirse, sistem üzerinde tam kontrol kazanır.

**Docker-compose.yml'de uygulanması çok basittir:**

```yaml
services:
  vito:
    image: vitodeploy/vito:latest
    container_name: vito-deploy
    restart: unless-stopped
    user: "1000:1000"
    security_opt:
      - no-new-privileges:true
    ports:
      - "3000:3000"
    volumes:
      - anchor_data:/data

volumes:
  anchor_data:
```

`user: "1000:1000"` parametresi, konteynerı UID 1000 ve GID 1000 ile çalıştırır. Bu UID ve GID değerleri imajda tanımlanmış olmalıdır. Eğer imaj varsayılan olarak root ile çalışıyorsa, imajı kendi UID/GID'nizle özelleştirmeniz gerekir.

`security_opt: no-new-privileges:true` de önemli - bu, konteyner içindeki bir işlemin ayrıcalık yükseltme yapmasını engeller.

**Gerçek Dünya Senaryosu:** Bir Node.js uygulaması geliştirirken, root kullanıcı olarak çalışmıştı. Bir zafiyet nedeniyle saldırgan container'a giriş yapabildi. Eğer non-root olarak çalışsaydı, yapabileceği zarar çok daha az olurdu.

### 2. Sırları Runtime'da Yönetin - Asla İmajda Değil

Eğer uygulamanız API anahtarına veya veritabanı şifresine ihtiyaç duyuyorsa, **asla** Dockerfile'a koymayın. Bunları runtime'da yönetin:

```yaml
services:
  vito:
    image: vitodeploy/vito:latest
    container_name: vito-deploy
    secrets:
      - db_password
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt
```

Ya da daha profesyonel ortamlar için, **Vault**, **AWS Secrets Manager** gibi çözümler kullanın. Bu, gizli anahtarlarınızı merkezi olarak yönetmenizi ve hemen revoke etmenizi sağlar.

### 3. Rootless Mode - İleri Seviye Güvenlik

Eğer maksimum güvenlik istiyorsanız, **Rootless Docker** devreye girebilir. Bu, Docker daemon'ın kendisinin de root olmadan çalışmasını sağlar.

**Neden önemli?** Varsayılan Docker'da, **daemon root** olarak çalışır. Eğer bir saldırgan container'dan **breakout** yapabilirse, doğrudan host sistemine erişim elde eder. **Rootless mode**'da, daemon bile **non-root** çalışır, böylece **privilege escalation** neredeyse imkansız hale gelir.

**Rootless Mode Aktivasyonu:**

```bash
# Rootless Docker'ı kurun: https://docs.docker.com/engine/security/rootless
dockerd-rootless-setuptool.sh install

# Rootless ortamında çalıştığınızı onaylayın
docker run --rm busybox whoami
# Çıktı: root (ama bu, container içinde namespaced bir "root"tür)

# Host'ta aslında hangi user olduğunu görmek için
ps aux | grep dockerd
# rootless user'ın adı görünür
```

**DİKKAT:** Rootless mode bazı özellikler (GPU erişimi, bazı network modları) desteklemez/sınırlı, ama çoğu üretim uygulaması için yeterlidir!

### 4. Kapasite Sınırlandırması ve Privilege Restriction

Bir imaj ne kadar uygun görünse de, container'a sınırlı **resource** ve **capability** vermek, başarılı bir saldırı durumunda hasarı sınırlandırır:

```yaml
services:
  vito:
    image: vitodeploy/vito:latest
    container_name: vito-depoloy
    user: "1000:1000"
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 256M
    read_only: true
    tmpfs:
      - /tmp
      - /run
    ports:
      - "127.0.0.1:3000:3000"
```

**Ne Yaptı?**

* `cap_drop: ALL` - Tüm Linux capabilities'i çıkardık
 
* `cap_add: NET_BIND_SERVICE` - Sadece port binding için gerekli olanı ekledik
 
* `read_only: true` - Dosya sistemi salt okunur
 
* `tmpfs` - Geçici dosyalar için bellek-tabanlı volumes
 
* `127.0.0.1:3000:3000` - Sadece localhost'tan erişim
 
* CPU ve memory sınırları - DoS saldırılarına karşı koruma
 

Bu ayarlar, konteynerı neredeyse "kilitli" bir ortamda çalıştırıyor. Saldırgan, **privilege escalation** yapamazsa ve sistem kaynaklarına da erişemezse, yapabileceği zararın çok sınırlı olduğu anlamına geliyor.

### 5. Minimal Base İmajları Seçin

"**Neden bu kadar önemli?**" diye soruyorsunuz. Çünkü bir base imaj ne kadar büyükse, o kadar fazla paket içeriyor ve o kadar fazla potansiyel açık bulunuyor.

* **Alpine Linux**: 5MB
 
* **Debian**: 100MB+
 
* **Ubuntu**: 300MB+
 

Fark büyük... Dockerfile'ınızda bunu yazıyor olabilirsiniz:

```dockerfile
FROM ubuntu:latest
```

Bunu bu şekilde değiştirin:

```dockerfile
FROM alpine:3.20
```

**Multi-Stage Build ile Daha Da İyisi:**

Geliştirme sırasında birçok araç ve **dependency**'ye ihtiyacınız olabilir (compiler, test framework'ler). Fakat üretimde bunlara hiç ihtiyaç yok. **Multi-stage build** bunu yapabilir:

```dockerfile
# Build stage
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp .

# Runtime stage
FROM alpine:3.20
COPY --from=builder /app/myapp /usr/local/bin/
CMD ["myapp"]
```

İlk imaj 2GB, final imaj 50MB. Güvenlik açısından, 50MB'da 2GB'dan çok daha az açık vardır.

### 6. Ağ Segmentasyonu - Container'ları İzole Edin

Eğer birden fazla konteyner kullanıyorsanız, varsayılan Docker bridge ağı tüm container'ları birbiriyle iletişim kurması için açık hale getirir. Bu **büyük bir güvenlik açığı** olabilir.

```yaml
services:
  web:
    image: nginx:latest
    networks:
      - web_network
    ports:
      - "80:80"

  db:
    image: postgres:15
    networks:
      - db_network

  api:
    image: myapi:latest
    networks:
      - web_network
      - api_db_network

networks:
  web_network:
    driver: bridge
  db_network:
    driver: bridge
  api_db_network:
    driver: bridge
```

Bu yapılandırmada:

* **Web** ve **API** birbiriyle konuşabilir
 
* **API** ve **DB** birbiriyle konuşabilir
 
* Fakat **Web** direkt **DB**'ye erişemez
 

Eğer web container'ı hack edilse bile, saldırgan veritabanına direkt erişemez. Bu, **lateral movement'i engeller.**

### 7. Port Güvenliği - Harici Erişimi Kısıtlayın

Yalnızca gerekli portları açın ve localhost'a bağlayın:

```yaml
ports:
  - "127.0.0.1:3000:3000"  # Sadece localhost'tan erişim - server ip
```

Eğer harici erişim gerekiyorsa, **reverse proxy** (Nginx, Traefik) arkasına koyun ve TLS kullanın.

### 8. Dosya ve Proses Takibi - Anormallikleri Keşfedin

Konteyner çalışırken içinde gerçekleşen olayları izlemek, anormal davranışın tespiti için **kritik önem** taşır.

**Lsof ve Strace Kullanımı:**

```bash
# Dosya bağlantılarını izleme
sudo nala install -y lsof
lsof | grep -i IPv4

# Sistem çağrılarını kayıt alma (yavaş, dikkat edin)
sudo nala install -y strace
strace -c -p <PROCESS_ID>
```

Bu araçlar, konteynerde ne olup bittiğini görmenizi sağlar.

### 9. İmaj Kaynak Kontrolü - Nereden Geliyorsa Oradan Bilin

Docker Hub'da bulduğunuz her imaj, iyi niyetli birisi tarafından oluşturulmamış olabilir. Kontrol etmelisiniz:

* **İmaj kimin tarafından yayınlandı?** Resmi kuruluşları (Docker, Github, Red Hat, Canonical vb.) tercih edin
 
* **Kaç kişi bu imajı kullanıyor?** Milyonlar mı, yoksa yüzlerce mi?
 
* **Son güncelleme tarihi nedir?** Eğer 2 yıldır güncellenmediyse, şüpheyle yaklaşmanızda fayda var!
 
* **GitHub repository'si var mı?** Dockerfile ne kadar basit ve şeffaf?
 

### 10. İmaj Güncellemelerini İzleyin ve Otomatize Edin

Düzenli olarak güncellemeleri kontrol edin. İdeal olarak CI/CD pipeline'ınızda Docker Scout veya Trivy'yi otomatize edin:

```bash
# GitHub Actions örneği
name: Container Security Scan
on: [push]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: docker/setup-buildx-action@v2
      - run: |
          docker build -t myapp:latest .
          docker scout cves myapp:latest
```

## Runtime Security - Üretimde Gerçek Zamanlı Koruma

Üretim ortamınızda container'lar çalışırken, **gerçek zamanlı güvenlik izlemesi** yapmanız gerekir. Bu, sadece tarama yapmaktan ötesine geçer.

**Sysdig**, **Falco**, **AccuKnox** gibi araçlar, container davranışlarını izler ve anormal aktiviteleri tespit eder. Örneğin:

* Container'da açılmayan bir shell session'ı tespit et
 
* Beklenmayan bir ağ bağlantısı engelle
 
* Dosya sistemi değişikliklerini kayıt altına al
 
* Credential sızıntısını canlı olarak tespit et
 

**Runtime Security Araçları:**

* [Sysdig](https://sysdig.com) - CNAPP platformu
 
* [Falco](https://falco.org) - CNCF açık kaynaklı runtime detection
 
* [AccuKnox](https://accuknox.com) - Zero Trust CNAPP
 

Bu araçlar, **zero-day exploitler** bile karşısında koruma sağlayabilir.

## Tam Güvenli Yapılandırma Örneği

Şu ana kadar öğrendiğiniz her şeyi bir araya getirin:

```yaml
version: '3.8'

services:
  vito:
    image: vitodeploy/vito:latest
    container_name: vito-deploy
    restart: unless-stopped
    
    # Güvenlik
    user: "1000:1000"
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    read_only: true
    
    # Gizli Anahtarlar
    secrets:
      - api_key
    environment:
      API_KEY_FILE: /run/secrets/api_key
    
    # Kaynak Sınırlandırması
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: 512M
        reservations:
          cpus: "0.25"
          memory: 256M
    
    # Ağ ve Port
    ports:
      - "127.0.0.1:3000:3000"
    networks:
      - internal
    
    # Geçici Dosyalar
    tmpfs:
      - /tmp
      - /run
    
    volumes:
      - anchor_data:/data

volumes:
  anchor_data:

networks:
  internal:
    driver: bridge

secrets:
  api_key:
    file: ./secrets/api_key.txt
```

## CI/CD'de Docker Scout Entegrasyonu

Modern DevSecOps iş akışında, tarama işlemi otomatik olmalıdır. Docker Scout'u CI/CD pipeline'ınıza örnek olarak bu şekilde ekleye bilirsiniz:

**GitHub Actions:**

```yaml
name: Docker Scout Scan
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  scout:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: docker/setup-buildx-action@v2
      
      - name: Build Docker image
        run: docker build -t myapp:${{ github.sha }} .
      
      - name: Run Docker Scout
        run: |
          docker scout cves myapp:${{ github.sha }} \
            --exit-code \
            --only-severity critical,high
```

**GitLab CI:**

```yaml
security:scan:
  stage: security
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker scout cves $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  allow_failure: false
```

## Deneyimlerim

**Bir PHP uygulamasında key tespit ettim.** Dockerfile'da `ENV DATABASE_PASSWORD=mysecret123` yazılmıştı. Git history'de de vardı. Bulut sistemine geçtim ve bu şifreyi revoke ettim. Sonrasında, her commit'te secret scanning yapan pre-commit hook'ları kurdum. `git-secrets` veya `truffleHog` harika araçlar.

**En sevdiğim hikaye:** Docker Scout ile bir imajda 45 açık buldum. Hızlı bir şekilde `docker scout cves --only-fixed` komutu ile sadece düzeltilebilir olanları filtreledim ve 2 saat içinde hepsini kapattım. **Docker Scout**'un otomatik **remediation önerileri** sayesinde, hangi paket versiyonunu yüklemem gerektiğini tam olarak biliyordum.

## Dikkat: Her CVE Sizi Endişelendiremez

Eğer **Docker Scout** veya **Trivy** gibi araçlar kullanıyorsanız, "critical" yazısını gördüğünüzde paniğe kapılmayın. Her critical CVE sizin için kritik değildir. Kendinize şu soruları sorup cevap verin:

* Açık hangi kütüphanede?
 
* Siz o kütüphaneyi kullanıyor musunuz?
 
* Kodunuzu nasıl tetikleyebilir?
 
* Sizin mimari bu saldırıya karşı açık mı?
 

Geçtiğimiz ay, Docker Scout'ta "critical" ile işaretlenmiş bir açık gördüm. Ama açık, yalnızca `/etc/passwd` dosyasını yazma iznine sahip olmayan kullanıcılar tarafından tetiklenebiliyordu. Biz her zaman non-root çalıştırıyor olduğumuz için, bu açık bizim için hiç önem taşımıyordu.

## Güvenlik sürekli bir süreç

Docker imajı güvenliği bir kez yapılıp biten iş değil; sürekli bir süreç. Her gün yeni CVE'ler bulunuyor, yeni imaj versiyonları çıkıyor, yeni saldırı teknikleri ortaya çıkıyor. Yapmanız gereken:

1. **Taramayı otomatize edin** - Docker Scout veya Trivy'yi CI/CD'ye entegre edin
 
2. **Minimal imajlar kullanın** - Attack surface'i azaltın
 
3. **Non-root user'lar çalıştırın** - Privilege escalation'ı engelle
 
4. **Gizli key’lerinizi ayrı yönetin** - Asla imajın içine koyma
 
5. **Runtime security kullanın** - Sadece tarama yeterli değil
 
6. **Ağ segmentasyonu yapın** - Container'ları izole et
 
7. **Registry'yi kilitleyin** - Sadece güvenilir imajları çek
 

Bu adımları takip ettiğinizde uygulamalarınız çok daha güvende olur. En güzeli, gecenin bir yarısı sunucu açıklarıyla paniğe kapılmazsınız çünkü tarama otomatik çalışıyor ve durumu kontrol altında tutuyorsunuz.

Başlamak için ne yapmalısınız? Hemen Docker Hub'daki mevcut imajlarınızı Docker Scout ile tarayın. Tek komut uzağınızda:

```bash
docker login # Docker hub hesabınıza giriş gerekli
docker scout cves vitodeploy/vito:latest
```

Buna alternatif olarak Trivy'yi de kurup kullanmaya başlayabilirsiniz:

```bash
trivy image vitodeploy/vito:latest
```