OSV-Scanner Kılavuzu: Java, Docker ve Kubernetes Ortamlarında Kurulum ve Kullanım

OSV-Scanner Kılavuzu: Java, Docker ve Kubernetes Ortamlarında Kurulum ve Kullanım

26 Nisan 2026 Kapalı Yazar: emrecaglaryildiz

Genel Bakış

OSV-Scanner, açık kaynak bağımlılıkları, lockfile dosyaları, SBOM çıktıları ve konteyner imajlarını tarayarak bilinen güvenlik açıklarını tespit eden bir güvenlik tarama aracıdır. Araç, Google tarafından yayınlanan OSV ekosisteminin bir parçasıdır ve zafiyet eşleştirmelerini OSV veritabanı üzerinden yapar. Java projeleri, Docker imajları ve artefact seviyesindeki taramalar için komut satırından doğrudan kullanılabildiği gibi CI/CD süreçlerine de entegre edilebilir.[1][2][3][4]

Bu kılavuz, özellikle Java uygulamaları, Docker image’ları ve Kubernetes üzerinde çalışan iş yükleri için OSV-Scanner kurulumunu, temel kullanım komutlarını, otomasyon örneklerini ve operasyonel önerileri kapsar.[2][4][5]

OSV-Scanner Ne İşe Yarar?

OSV-Scanner; proje dizinlerini, manifest ve lockfile dosyalarını, SBOM belgelerini ve container image’larını tarayabilir. Desteklenen tarama yöntemleri sayesinde hem source seviyesinde hem de build sonrası image seviyesinde görünürlük sağlar. Bu yaklaşım, zafiyetlerin yalnızca kaynak koddaki bağımlılıklarda değil, işletim sistemi paketleri ve image içine gömülü bileşenlerde de yakalanmasına yardımcı olur.[3][4][5][2]

Pratikte en yaygın kullanım alanları şunlardır:

  • Java Maven veya Gradle projelerindeki bağımlılıkların taranması.[2]
  • Docker image’larının registry’ye gönderilmeden önce kontrol edilmesi.[4]
  • Kubernetes cluster’ında çalışan pod image’larının periyodik olarak taranması.[5]
  • JSON çıktı üreterek pipeline, SIEM veya başka otomasyon mekanizmalarına veri sağlanması.[6][2]

Kurulum

Binary ile kurulum

OSV-Scanner resmi dokümantasyonunda, farklı platformlar için hazır dağıtımlar ve kurulum seçenekleri sunulmaktadır. Binary yöntemi, özellikle Linux sunucularında ve CI runner ortamlarında en sade kurulum yaklaşımıdır.[3]

Linux için örnek kurulum adımları:

chmod +x osv-scanner
sudo mv osv-scanner /usr/local/bin/
osv-scanner --version

Bu yaklaşımda binary dosyasının çalıştırılabilir yapılması ve PATH içinde bir dizine taşınması yeterlidir. Sürüm doğrulaması için osv-scanner --version komutu kullanılabilir.[3]

Go ile kurulum

Go geliştirme ortamı bulunan sistemlerde araç doğrudan kaynak üzerinden kurulabilir. Bu yöntem, özellikle geliştirici makinelerinde veya Go tabanlı toolchain kullanan ortamlarda kullanışlıdır.[3]

go install github.com/google/osv-scanner/cmd/osv-scanner@v1

Kurulumdan sonra binary tipik olarak GOPATH/bin altına yerleşir; bu dizinin PATH değişkenine eklenmesi gerekir.[3]

Docker ile kurulum gerektirmeden kullanım

OSV-Scanner, container imajı olarak da dağıtılır ve bu sayede host sisteme ek binary kurmadan çalıştırılabilir. Özellikle Docker yüklü CI ortamlarında bu yöntem en pratik seçenektir.[7][4]

docker run --rm ghcr.io/google/osv-scanner:latest --version

Docker tabanlı çalıştırma, version drift riskini azaltır ve merkezi şekilde güncel imaj kullanılmasına imkân verir.[4][7]

Java Projelerinde Kullanım

Maven ve Gradle proje taraması

OSV-Scanner, proje dizinini rekürsif biçimde tarayarak desteklenen manifest ve lockfile dosyalarını otomatik tespit edebilir. Java projeleri için en temel yaklaşım, repository kök dizininde source taraması çalıştırmaktır.[2]

osv-scanner scan -r .

Bu komut, alt dizinlerde bulunan desteklenen bağımlılık tanım dosyalarını da inceleyerek zafiyet bulgularını terminalde raporlar. Monorepo yapılarında ya da çok modüllü Java projelerinde özellikle faydalıdır.[2]

Maven manifest odaklı örnek

Maven tabanlı projelerde pom.xml dosyası bağımlılık çözümleme için temel girdidir. Gerekli durumlarda daha hedefli tarama için manifest veya lockfile benzeri girişler ayrıca belirtilebilir.[2]

osv-scanner scan --lockfile=pom.xml

Bu kullanım, kontrollü test senaryolarında veya yalnızca belirli bir modülün taranmak istendiği durumlarda tercih edilebilir.[2]

SBOM üzerinden Java taraması

Java projelerinde CycloneDX gibi araçlarla SBOM üretip bu dosyayı OSV-Scanner ile taramak mümkündür. Bu yöntem, build sonucu oluşan yazılım bileşen listesinin saklanması ve sonradan yeniden taranabilmesi açısından faydalıdır.[2]

Örnek akış:

./gradlew cyclonedxBom
osv-scanner scan --sbom=build/reports/bom.json

SBOM taraması, doğrudan source taramaya ek olarak denetim izi ve artefact temelli güvenlik süreçlerini güçlendirir.[2]

Docker Image Taraması

Doğrudan image taraması

OSV-Scanner, image tarama moduyla yerel Docker daemon üzerinde bulunan ya da erişilebilir container image’larını tarayabilir. Bu yöntem, Java uygulamasının yalnızca bağımlılıklarını değil, image içinde bulunan işletim sistemi paketlerini ve artefact bileşenlerini de değerlendirmeye yardımcı olur.[4]

osv-scanner scan image my-java-app:latest

Tarama sonucunda image içinde bulunan etkilenen paketler ve ilgili zafiyet kayıtları raporlanır. Uygulama image’larının deployment öncesi kontrolü için temel komut budur.[4]

Docker container içinden image tarama

Host sisteme kurulum yapılmadan, resmi imaj üzerinden image taraması çalıştırılabilir.[7][4]

docker run --rm ghcr.io/google/osv-scanner:latest \
  scan image my-java-app:latest

Bu kullanım, ephemeral runner yapıları ve immutable CI ajanları için uygundur.[7][4]

JSON çıktı ile raporlama

OSV-Scanner, otomasyon dostu olacak şekilde JSON çıktı üretebilir. Bu çıktı, jq, Python veya SIEM/SOAR akışları ile işlenebilir.[6][2]

osv-scanner scan image my-java-app:latest --format=json > osv-image-report.json

Benzer şekilde source taramaları için de JSON çıktı alınabilir:

osv-scanner scan -r . --format=json > osv-source-report.json

JSON raporları, pipeline içerisinde eşik bazlı karar mekanizmaları kurmak için uygundur.[6][2]

Kubernetes Ortamlarında Kullanım

OSV-Scanner doğrudan bir Kubernetes admission controller değildir; ancak cluster’da kullanılan image’ların taranması için etkili biçimde kullanılabilir. En doğru yaklaşım, Kubernetes tarafını üç aşamada ele almaktır: build zamanı tarama, registry öncesi image tarama ve cluster’da çalışan image’ların periyodik taranması.[5][4]

Cluster’daki image’ları listeleyip tarama

Kubernetes cluster’ında çalışan pod’ların kullandığı image listesi kubectl ile çıkarılabilir. Sonrasında her benzersiz image için OSV-Scanner çalıştırılarak toplu tarama yapılabilir.[5]

IMAGES=$(kubectl get pods --all-namespaces -o jsonpath='{.items[*].spec.containers[*].image}' | tr ' ' '\n' | sort -u)

for img in $IMAGES; do
  echo "Scanning $img"
  osv-scanner scan image "$img" --format=json >> osv-k8s-images.json
done

Bu örnek, cluster’da fiilen çalışan image’lara odaklandığı için operasyonel önceliklendirme açısından değerlidir.[5]

Periyodik tarama yaklaşımı

Kubernetes üzerinde DaemonSet ya da CronJob benzeri desenlerle düzenli tarama planlanabilir. Örnek senaryoda, pod içindeki süreç belirli aralıklarla image listesini çekip her image için scan image komutunu çalıştırır.[5]

Örnek yaklaşım:

apiVersion: apps/v1
kind: DaemonSet
meta
  name: osv-scanner-daemonset
  namespace: security
spec:
  selector:
    matchLabels:
      app: osv-scanner
  template:
    meta
      labels:
        app: osv-scanner
    spec:
      containers:
      - name: osv-scanner
        image: ghcr.io/google/osv-scanner:latest
        command: ["/bin/sh", "-c"]
        args:
          - |
            while true; do
              IMAGES=$(kubectl get pods --all-namespaces -o jsonpath='{.items[*].spec.containers[*].image}' | tr ' ' '\n' | sort -u)
              for img in $IMAGES; do
                osv-scanner scan image "$img"
              done
              sleep 86400
            done

Bu model, proof-of-concept için uygundur; üretim ortamında RBAC, secret yönetimi, kaynak limitleri, çıktı toplama ve erişim yetkileri ayrıca tasarlanmalıdır.[5]

CI/CD Entegrasyonu

OSV-Scanner, komut satırı yapısı sayesinde GitLab CI, GitHub Actions ve benzeri pipeline’lara kolayca entegre edilebilir. En iyi sonuç, source taraması ile image taramasının birlikte uygulanmasıyla elde edilir.[4][2]

GitLab CI örneği

Aşağıdaki örnek, önce Java uygulamasını derler, ardından üretilen image’ı tarar ve JSON rapor oluşturur:[4][2]

stages:
  - build
  - scan

build:
  stage: build
  image: maven:3.9-eclipse-temurin-17
  script:
    - mvn -B package

scan-osv:
  stage: scan
  image: docker:24
  services:
    - docker:dind
  script:
    - docker build -t my-registry/my-java-app:$CI_COMMIT_SHA .
    - docker run --rm -v "$PWD":/src ghcr.io/google/osv-scanner:latest \
        scan -r /src --format=json > osv-source-report.json
    - docker run --rm ghcr.io/google/osv-scanner:latest \
        scan image my-registry/my-java-app:$CI_COMMIT_SHA --format=json > osv-image-report.json

Bu yapı, kaynak bağımlılıkları ile final image içeriğini ayrı ayrı görünür hale getirir.[4][2]

GitHub Actions örneği

GitHub Actions üzerinde de benzer şekilde tarama job’ı tanımlanabilir.[4][2]

name: OSV Scan

on:
  push:
  pull_request:

jobs:
  osv-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Build image
        run: docker build -t my-java-app:${{ github.sha }} .

      - name: Source scan
        run: |
          docker run --rm -v "$PWD":/src ghcr.io/google/osv-scanner:latest \
            scan -r /src --format=json > osv-source-report.json

      - name: Image scan
        run: |
          docker run --rm ghcr.io/google/osv-scanner:latest \
            scan image my-java-app:${{ github.sha }} --format=json > osv-image-report.json

Bu örnek, pull request ve push olaylarında otomatik güvenlik taraması başlatmak için temel bir iskelet sağlar.[2][4]

Önerilen Operasyonel Akış

Java, Docker ve Kubernetes ağırlıklı ortamlarda en verimli yaklaşım çok katmanlı tarama modelidir. Bu model, zafiyetleri mümkün olduğunca erken yakalarken production’a taşınan image’lar üzerinde de kontrol sağlar.[5][4][2]

Önerilen sıralama:

  1. Geliştirme aşamasında source taraması çalıştırmak: osv-scanner scan -r .[2]
  2. Build sonrası image taraması yapmak: osv-scanner scan image my-app:tag[4]
  3. JSON raporları pipeline artefact’ı olarak saklamak.[6][2]
  4. Kubernetes cluster’da çalışan image’ları günlük veya saatlik periyotlarla yeniden taramak.[5]
  5. Kritik bulguları ticket, SIEM veya uyarı mekanizmalarına göndermek.[6][2]

Bu yaklaşım, özellikle sürekli güncellenen base image kullanan Java servislerinde sonradan ortaya çıkan CVE’lerin daha hızlı fark edilmesini sağlar.[5][4]

Sık Kullanılan Komutlar

AmaçKomutKaynak
Proje dizinini taramaosv-scanner scan -r .[2]
Maven manifest taramaosv-scanner scan --lockfile=pom.xml[2]
SBOM taramaosv-scanner scan --sbom=build/reports/bom.json[2]
Docker image taramaosv-scanner scan image my-java-app:latest[4]
Docker içinden image taramadocker run --rm ghcr.io/google/osv-scanner:latest scan image my-java-app:latest[7][4]
Source JSON raporuosv-scanner scan -r . --format=json > osv-source-report.json[2]
Image JSON raporuosv-scanner scan image my-java-app:latest --format=json > osv-image-report.json[2][6]
K8s image listesini çekmekubectl get pods --all-namespaces -o jsonpath='{.items[*].spec.containers[*].image}'[5]

Dikkat Edilmesi Gerekenler

OSV-Scanner’ın etkinliği, taranan manifest, lockfile, image ve SBOM verisinin doğruluğuna bağlıdır. Source taraması tek başına her zaman yeterli olmayabilir; çünkü final image içine eklenen işletim sistemi paketleri ve runtime katmanları ayrıca risk taşıyabilir. Bu nedenle Java uygulamaları için source ve image taramasının birlikte kullanılması daha doğru bir güvenlik pratiğidir.[4][2]

Kubernetes tarafında ise yalnızca manifest YAML dosyalarını incelemek yerine, cluster’da gerçekten çalışan image’ları taramak daha anlamlı sonuç üretir. Ayrıca üretim ortamında tarama bileşenlerine minimum yetki verilmesi, log ve sonuçların merkezi toplanması ve schedule yoğunluğunun cluster kaynaklarına uygun planlanması gerekir.[5]

Sonuç

OSV-Scanner, Java uygulamaları, Docker image’ları ve Kubernetes üzerinde çalışan iş yükleri için hafif ama etkili bir zafiyet tarama yaklaşımı sunar. En iyi sonuç, source düzeyi tarama, image düzeyi tarama ve cluster’da kullanılan image’ların periyodik yeniden taranmasının birlikte uygulanmasıyla elde edilir.[2][4][5]

Özellikle Java tabanlı mikroservis mimarilerinde, bu çok katmanlı model hem build öncesi hem de deployment sonrası güvenlik görünürlüğünü ciddi biçimde artırır.[4][5][2]

Kaynaklar
[1] Google, OSV Scanner’ı Yayınladı – ÇözümPark https://www.cozumpark.com/google-osv-scanneri-yayinladi/
[2] Usage | OSV-Scanner – Google https://google.github.io/osv-scanner/usage/
[3] OSV-Scanner – Google https://google.github.io/osv-scanner/
[4] Scanning Methods https://google.github.io/osv-scanner/usage/scan-image
[5] osv-scanner Kubernetes集成:集群安全扫描指南 https://blog.csdn.net/gitblog_00608/article/details/151298375
[6] Json Output https://www.anmalkov.com/blog/how-to-use-google-osv-scanner
[7] How To Use This Image https://hub.docker.com/r/anmalkov/osv-scanner

5/5 - (3 votes)