Grype Nedir? Container ve SBOM Zafiyet Tarama Rehberi

İlgili yazılar

WireGuard Nedir? Modern ve Açık Kaynak VPN Teknolojisi

19 saat önce

CrowdSec Nedir? Açık Kaynak Collaborative Network Security Platformu

1 hafta önce

ntopng Nedir? Açık Kaynak Network Traffic Analysis ve Monitoring Aracı

2 hafta önce

🔍 Container image başarılı şekilde build oldu diye güvenli olduğu anlamına gelmez.

Image içinde:

📦 İşletim sistemi paketleri
📚 Uygulama kütüphaneleri
🧩 Framework bağımlılıkları
☕ Java paketleri
🐍 Python modülleri
📦 npm dependency’leri
🐹 Go modülleri

gibi onlarca hatta yüzlerce yazılım bileşeni bulunabilir.

Ve bu bileşenlerden herhangi biri bilinen bir güvenlik açığı taşıyor olabilir.

İşte burada devreye:

Grype 🛡️

giriyor.

---

🛡️ Grype Nedir?

Grype, Anchore tarafından geliştirilen açık kaynaklı bir Software Composition Analysis / Vulnerability Scanning aracıdır.

Temel amacı:

Software Component
↓
Version Detection
↓
Vulnerability Database Matching
↓
Known Vulnerability
↓
Risk Report

akışıyla yazılım bileşenlerinde bilinen güvenlik açıklarını tespit etmektir.

Grype şu hedefleri tarayabilir:

Container Image
Filesystem / Directory
Container Archive
OCI Image
Remote Registry Image
SBOM
Individual Package / PURL / CPE

Basit kullanım:

grype nginx:latest

Grype image içerisindeki paketleri kataloglar ve bunları bilinen vulnerability verileriyle karşılaştırır.

---

🚀 Grype Neler Yapabilir?

🔹 Container Image Vulnerability Scanning

Docker veya OCI image’larını analiz edebilir.

Örneğin:

grype nginx:latest

Sonuçta tipik olarak:

Package
Installed Version
Fixed Version
Vulnerability ID
Severity
EPSS / Risk

gibi bilgiler görülebilir.

---

🔹 Filesystem Taraması

Sadece container image taramak zorunda değilsiniz.

Bir proje dizini de analiz edilebilir:

grype ./my-project

Bu özellik özellikle application dependency analizi için değerlidir.

---

🔹 SBOM Üzerinden Vulnerability Scanning

Grype’ın güçlü kullanım senaryolarından biri önceden oluşturulmuş SBOM’u taramaktır.

Örneğin:

grype sbom:./sbom.json

veya:

grype sbom.json

Desteklenen yaygın SBOM formatları arasında:

Syft JSON
SPDX
CycloneDX

bulunur.

Bu yöntem özellikle CI/CD ve Software Supply Chain Security süreçlerinde değerlidir.

---

🧩 Syft + Grype

Anchore ekosisteminde iki araç birbirini çok iyi tamamlar:

Syft
↓
Software Inventory / SBOM

Grype
↓
Vulnerability Analysis

Kısa ifade:

Syft neyin içinde olduğunu söyler.
Grype bunlardan hangilerinin bilinen zafiyet taşıdığını söyler.

Örneğin doğrudan pipe kullanılabilir:

syft nginx:latest -o json | grype

Mantık:

Container Image
↓
Syft
↓
SBOM
↓
Grype
↓
Vulnerability Findings

---

🏭 DevSecOps Pipeline İçinde Grype

Asıl değer Grype’ı yalnızca manuel çalıştırmak değil, CI/CD pipeline içerisine koyduğunuzda ortaya çıkar.

Örnek akış:

Developer
↓
Git Repository
↓
CI Pipeline
↓
Application Build
↓
Container Build
↓
Syft
↓
SBOM
↓
Grype
↓
Vulnerability Scan
↓
Security Gate
↓
Container Registry
↓
Kubernetes

Örneğin production’a giden image içerisinde High veya Critical seviyede açık varsa pipeline durdurulabilir.

grype myapp:1.0 --fail-on high

Mantık:

No High/Critical vulnerability
        ↓
      PASS

High/Critical vulnerability detected
        ↓
      FAIL

Böylece güvenlik kontrolü:

Build sonrası manuel işlem

olmaktan çıkıp:

CI/CD Security Gate

haline gelir.

---

🚦 Severity Tek Başına Yeterli mi?

Hayır.

Bir vulnerability’nin:

Critical

olması her zaman o açığın ortamınız açısından en kritik risk olduğu anlamına gelmez.

Örneğin iki CVE düşünelim:

CVE-A
CVSS: 9.8
Exploit görülmemiş

CVE-B
CVSS: 8.1
CISA KEV içerisinde
Aktif exploit ediliyor

Operasyonel olarak CVE-B daha acil olabilir.

Bu nedenle modern vulnerability management yaklaşımında:

Severity
+
Exploitability
+
Exposure
+
Fix availability
+
Asset criticality

birlikte değerlendirilmelidir.

Grype sonuçları:

grype image:tag --sort-by risk

veya:

grype image:tag --sort-by epss

gibi yöntemlerle önceliklendirilebilir.

Desteklenen sıralama kriterleri arasında:

Risk
Severity
EPSS
KEV
Package
Vulnerability

bulunur.

---

🎯 EPSS ve CISA KEV Neden Önemli?

Grype vulnerability verisini yalnızca CVE severity seviyeleriyle sınırlı tutmaz.

Ek risk sinyalleri olarak:

EPSS

Exploit Prediction Scoring System

Bir CVE’nin yakın gelecekte exploit edilme olasılığına ilişkin veri sağlar.

CISA KEV

Known Exploited Vulnerabilities

Gerçek dünyada aktif olarak exploit edildiği bilinen açıkları içerir.

Bu nedenle:

Critical CVE

yerine bazen:

High
+
KEV
+
High EPSS
+
Internet Exposure

daha öncelikli olabilir.

---

🔧 Fix Available Bilgisini Kullanın

Bir vulnerability bulunduğunda en önemli sorulardan biri:

Fix var mı?

Grype çıktısında:

INSTALLED
FIXED-IN

bilgileri görülebilir.

Örneğin:

openssl
Installed: 3.0.x
Fixed-in: 3.0.y

Bu bilgi remediation sürecini hızlandırır.

Sadece fix bulunan açıkları görmek için:

grype image:tag --only-fixed

kullanılabilir.

Bu özellikle patch/remediation planlamasında faydalıdır.

---

📄 Otomasyon İçin JSON ve SARIF

Grype yalnızca terminal tablosu üretmez.

Örneğin:

grype nginx:latest -o json

ile JSON rapor alınabilir.

Ayrıca:

Table
JSON
SARIF
CycloneDX
CycloneDX JSON
Template

gibi formatlar desteklenir.

Bu sayede Grype çıktısı:

CI/CD
SIEM
Security Dashboard
Ticketing System
Reporting
GitHub Security Workflow

gibi süreçlere aktarılabilir.

---

🗄️ Container Registry Taraması

Grype remote registry’den image çekerek tarama yapabilir.

Örneğin:

grype registry:registry.example.com/team/app:1.0

Private registry authentication da desteklenir.

Ancak burada doğru konumlandırma önemli:

Grype
=
Registry'deki image'ı vulnerability açısından tarayabilir.

Ama:

Grype
≠
Tam kapsamlı Container Registry Security Platform

Sürekli registry monitoring, admission control, runtime enforcement veya lifecycle policy için ek sistemler gerekebilir.

---

🧠 Grype Vulnerability Bilgisini Nereden Alıyor?

Grype kendi vulnerability database’ini kullanır.

Bu veri çeşitli upstream security kaynaklarından oluşturulur.

Örnekler:

Alpine SecDB
Debian Security Tracker
Ubuntu CVE Tracker
Red Hat Security Data
GitHub Security Advisories
NVD
Amazon Linux Security
SUSE Security
Oracle Linux Security

Ayrıca:

CISA KEV
EPSS

verileri de risk önceliklendirmesine katkı sağlar.

Grype çalıştırıldığında local vulnerability database kontrol edilir ve güncel sürüm varsa güncellenebilir.

Önemli operasyon notu:

Eski vulnerability database ile scan yapmak yanlış güvenlik algısı oluşturabilir.

Bu yüzden DB durumu kontrol edilebilir:

grype db status

Güncelleme:

grype db update

---

📝 VEX Desteği

Software Supply Chain Security tarafında önemli bir diğer kavram:

VEX — Vulnerability Exploitability eXchange

Bir vulnerability pakette mevcut olabilir ancak belirli ürün kullanımında gerçekten exploitable olmayabilir.

Örneğin:

Library vulnerable
↓
Vulnerable function kullanılmıyor
↓
Product not affected

Bu tip durumlarda VEX bilgisi vulnerability sonuçlarının daha doğru yorumlanmasına yardımcı olabilir.

Grype VEX dokümanlarını scan sırasında kullanabilir:

grype image:tag --vex vex.json

Bu, özellikle büyük enterprise SBOM süreçlerinde false-positive/noise azaltma açısından değerlidir.

---

⚠️ Grype Ne Değildir?

Grype doğru konumlandırılmalıdır.

❌ Runtime Security Tool Değildir

Çalışan container içerisindeki saldırı davranışlarını gerçek zamanlı izlemez.

Bu tip ihtiyaçlarda:

Falco
EDR/XDR
Container Runtime Security

gibi çözümler gerekir.

---

❌ Malware Sandbox Değildir

Dosyanın davranışını sandbox içinde çalıştırıp analiz etmez.

---

❌ Secret Scanner Değildir

Kod içerisindeki API key, password veya token arama temel görevi değildir.

Bu amaçla:

Gitleaks
TruffleHog

gibi araçlar kullanılabilir.

---

❌ Kubernetes Misconfiguration Scanner Değildir

RBAC, Pod Security veya Kubernetes YAML yanlış yapılandırmalarının tamamını analiz eden bir CSPM/misconfiguration scanner değildir.

---

❌ CVE Buldu Diye Exploit Edilebilir Olduğunu Kanıtlamaz

Grype temel olarak:

Package
+
Version
+
Vulnerability intelligence

eşleştirmesi yapar.

Bu nedenle:

CVE detected
≠
Automatically exploitable

Sonuçlar:

Environment
Exposure
Runtime usage
KEV
EPSS
VEX
Asset criticality

ile birlikte değerlendirilmelidir.

---

🛡️ İyi Bir Container Security Akışı Nasıl Olmalı?

Tek araç yeterli değildir.

Örneğin:

Source Code
↓
SAST
↓
Secret Scanning
↓
Dependency / SCA
↓
Container Build
↓
Syft → SBOM
↓
Grype → Vulnerability Scan
↓
Image Signing
↓
Registry
↓
Admission Control
↓
Kubernetes
↓
Runtime Security

Böylece güvenlik yalnız build aşamasına değil tüm software lifecycle’a yayılır.

---

🔥 Örnek Güvenlik Politikası

Örneğin CI/CD pipeline şöyle tasarlanabilir:

Critical vulnerability
→ FAIL

High + CISA KEV
→ FAIL

High + fix available
→ FAIL / Manual Review

Medium
→ Track

Low
→ Report

Bu yaklaşım sadece:

Kaç CVE var?

sorusunu değil:

Hangisini önce düzeltmeliyim?

sorusunu cevaplamaya yardımcı olur.

---

🎯 Kullanım Alanları

Grype özellikle şu alanlarda değerlidir:

🔹 Docker Security
🔹 Kubernetes Security
🔹 DevSecOps
🔹 Software Composition Analysis
🔹 Vulnerability Management
🔹 SBOM Security
🔹 Container Security
🔹 CI/CD Security
🔹 Software Supply Chain Security
🔹 Cloud-Native Security
🔹 GitOps Security

---

🧩 Kısa Araç Karşılaştırması

Syft
→ SBOM oluşturur.

Grype
→ Vulnerability bulur.

Cosign
→ Image/artifact imzalama ve doğrulamada kullanılabilir.

Falco
→ Runtime davranışlarını izler.

Gitleaks
→ Secret arar.

Hepsi farklı katmanları korur.

---

🔍 48s Mini-PoC

1️⃣ Test container image seçin.
2️⃣ grype image:tag ile ilk taramayı yapın.
3️⃣ High/Critical açıkları inceleyin.
4️⃣ FIXED-IN alanlarını kontrol edin.
5️⃣ Syft ile SBOM oluşturun.
6️⃣ SBOM’u Grype ile tekrar tarayın.
7️⃣ JSON rapor oluşturun.
8️⃣ Sonuçları severity bazında inceleyin.
9️⃣ EPSS/KEV önceliklendirmesini kontrol edin.
🔟 --fail-on high ile CI gate testi yapın.
1️⃣1️⃣ VEX kullanımını lab ortamında test edin.
1️⃣2️⃣ Güncel DB ile sonuçları yeniden doğrulayın.

---

🔐 Kısa Özet

Container build başarılı
≠
Container güvenli

Daha doğru yaklaşım:

Image
↓
SBOM
↓
Vulnerability Scan
↓
Risk Prioritization
↓
Security Gate
↓
Registry
↓
Deployment
↓
Runtime Security

Grype’ın değeri tam olarak burada ortaya çıkıyor.

Container’ın içinde ne olduğunu bilmek ilk adımdır.

O bileşenlerin hangi riskleri taşıdığını bilmek ise ikinci adımdır.

Syft + Grype kombinasyonu bu iki soruya oldukça sade bir açık kaynak yaklaşımı sunuyor. 🛡️

🧠 Güvenli container yalnızca çalışan container değildir; içinde ne olduğunu bildiğiniz, risklerini ölçtüğünüz ve deployment öncesinde kontrol ettiğiniz container’dır