Veri Bütünlüğünü Koruyarak NVD Veritabanı Senkronizasyonu

NVD Senkronizasyonu Önce Veri Kalitesi Problemidir

Ekipler NVD senkronizasyonunu genellikle zamanlanmış bir import görevi olarak ele alır: son feed'i çek, yerel veri deposunu güncelle, devam et. Bu yaklaşım gerçek zorluğu küçümsüyor. Kayıtları indirmek kolay kısım. Asıl zor olan; neyin değiştiğine, hangi revizyonların operasyonel anlam taşıdığına ve bir CVE kaydı özsel biçimde güncellendiğinde aşağı akış sistemlerinin ve iş akışlarının nasıl tepki vermesi gerektiğine olan güveni korumak.

NVD Senkronizasyon İş Akışı: Kaynaktan Karara

Ulusal Zafiyet Veritabanı (National Vulnerability Database — NVD), ekiplerin dikkatle mimari kurması gereken bir REST API sunuyor. Aşağıdaki tablo kaynaktan yerel istihbarata kadar tam iş akışını özetliyor:

| Aşama | Ayrıntı |

|-------|---------|

| Kaynak | NVD REST API v2.0 (nvd.nist.gov/developers) |

| API Uç Noktası | pubStartDate / lastModStartDate parametreli /rest/json/cves/2.0 |

| Temel Veri Alanları | cveId, cvssMetricV31, configurations (CPE), references, weaknesses (CWE) |

| Senkronizasyon Sıklığı | Tam: haftalık. Delta (yalnızca değişenler): 2 saatte bir önerilir |

| API Hız Limitleri | API anahtarsız: 30 saniyede 5 istek. API anahtarlı: 30 saniyede 50 istek |

API anahtarı kaydı ücretsiz ve 5 dakika altında tamamlanıyor. Anahtarsız üretim senkronizasyon pipeline'ı çalıştıran ekipler, özellikle 250.000'den fazla kayıtlık tam CVE corpus'unu çekerken hız sınırlarına çarpar. Anahtarlı, güvenli istek hızlarında tüm NVD corpus'unun ilk tam senkronizasyonu yaklaşık 90 dakikada tamamlanıyor. Bununla birlikte asıl değer, hızdan değil tutarlılıktan geliyor.

Revizyonlar Neden Önemli?

Zafiyet verisi ilk yayınlandıktan sonra değişmez değildir. Analiz olgunlaştıkça CVSS taban skorları revize edilir. Vendor advisory'leri geldiğinde etkilenen ürün kapsamı daraltılır ya da genişletilir. Referans koleksiyonları büyür. Tehdit istihbarat kaynaklarından gelen enrichment verisi, orijinal NVD girişinden günler veya haftalar sonra ortaya çıkabilir. Senkronizasyon modeli her CVE tanımlayıcısını değişmez kabul ederse — yalnızca ilk alımda güncelleyip sonraki revizyonları yok sayarsa — yerel istihbarat kalitesi sessizce ve sürekli düşer.

Güvenilir Pipeline Neye İhtiyaç Duyar?

Sağlam bir senkronizasyon pipeline'ı tipik olarak şunları gerektirir:

CVE kayıtlarını yinelenen kayıt oluşturmaksızın revizyonlar boyunca izleyen kararlı identifier yönetimi.

önemsiz metadata değişikliklerini operasyonel açıdan anlamlı skor veya kapsam güncellemelerinden ayırt eden revizyon farkına duyarlı update mantığı.

veri kümesini parçalayan yinelenen kayıtları önlemek için vendor ve ürün adlarının deterministik normalizasyonu.

eksikleri veri bozulması olarak yorumlamadan kısmi veya gecikmeli enrichment'i zararsız biçimde işleme.

yalnızca aktif operasyonel iş akışları için özsel önem taşıyan değişimleri aşağıya yayan downstream sinyal üretimi.

Bu mimari olmadan zafiyet veritabanı, zaman damgası olarak yüzeysel biçimde güncel kalırken içerik açısından giderek güvenilmez hale gelir.

MyVuln Yaklaşımı

MyVuln, NVD senkronizasyonundan tam değeri ancak pipeline yalnızca ingestion hacmi değil, değişim yönetimi etrafında tasarlandığında üretir. Platform, zararsız bir referans URL güncellemesini, remediation önceliklendirme tartışmalarını yeniden açması gereken bir CVSS skoru revizyonundan veya CPE kapsam değişikliğinden ayırt ediyor ve bu operasyonel açıdan anlamlı değişimleri doğrudan Intel Feed'de görünür kılıyor. Bu ayrım, canlı bir istihbarat varlığını eskiyen bir veri arşivinden ayıran şeydir.

NVD verisini çekmek çoğu kurum için teknik olarak zor değildir; zorlu olan bu veriyi zaman içinde güvenilir biçimde yaşatmaktır. Aynı CVE kaydı ilerleyen günlerde güncellenebilir, referansları değişebilir, CPE eşlemesi düzeltilebilir, CVSS vektörü revize edilebilir ya da üretici başlangıçta belirsiz bıraktığı etki kapsamını netleştirebilir. Senkronizasyon hattı bu değişiklikleri yalnızca "güncel kayıt alındı" düzeyinde işliyorsa analist için sistem görünüşte canlı ama gerçekte opak hale gelir. Kritik soru kaydın var olup olmadığı değil; son incelemeden bu yana neyin değiştiğidir.

İyi tasarlanmış NVD senkronizasyonu geçmiş durumu (historical state) birincil sınıf veri olarak saklar. Değişim izlemek için somut bir şema:

CREATE TABLE cve_change_log (
  id          BIGSERIAL PRIMARY KEY,
  cve_id      TEXT NOT NULL,
  changed_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
  field       TEXT NOT NULL,       -- örn. 'cvss_score', 'cpe_mapping', 'reference'
  old_value   TEXT,
  new_value   TEXT,
  source      TEXT DEFAULT 'nvd'
);

Bu log yerinde olduğunda analist bir CVE kaydını açtığında hemen şunu görür: "CVSS skoru 12.11.2024'te 7,5'ten 9,8'e yükseldi — önceliği yeniden değerlendir." Bu kayıt olmadan yeniden değerlendirme asla gerçekleşmez; kimse elle kontrol etmedikçe.

Dahası senkronizasyon hattı "kaynağın söylediği şey" ile "kurumun bu kaydı nasıl yorumladığı" arasındaki farkı da kalıcı biçimde görünür tutmalıdır. Üretici bir sorunu orta önemde değerlendirirken kurum ilgili varlığın kritiği nedeniyle daha acil davranmayı tercih edebilir. Ya da tersine, NVD yüksek şiddetli gösterse de etkilenen ürün ortamda bulunmuyorsa pratik öncelik düşük kalabilir. Bu yorum katmanı ham kaynak verisiyle birlikte sürümlenerek saklandığında platform tutarlı ve denetlenebilir hale gelir. Senkronizasyon böylece arka planda çalışan veri yükleme görevinden çıkıp; önceliklendirmeye güven kazandıran şeffaf bir kayıt zinciri haline gelir.