Dependabot'u Kapatın

• Dependabot'un aşırı bildirimleri, gerçek güvenlik sorunlarını çözmekten çok geliştiricilerin zamanını boşa harcatabiliyor
• Go ekosisteminde yaşanan örnekte olduğu gibi, etkilenmeyen depolarda bile binlerce PR ve uyarı üretilerek karmaşa yaratılıyor
• govulncheck tabanlı GitHub Action kullanıldığında yalnızca gerçekten savunmasız kod tespit edilebiliyor ve gereksiz uyarılar ortadan kaldırılabiliyor
• Bağımlılık güncellemelerini otomatik PR'lerle değil, periyodik testler ve güncel sürüm doğrulamasıyla yönetmek daha güvenli ve verimli
• Bu yaklaşım, uyarı yorgunluğunu (alert fatigue) azaltmak ve açık kaynak bakımcılarının yükünü hafifletmek açısından önemli

---

Dependabot'un sorunları

• Dependabot, çok sayıda güvenlik uyarısı ve otomatik PR üreterek geliştiricilerin gerçekten önemli sorunları ayırt etmesini zorlaştırıyor
  • Go paketi filippo.io/edwards25519 içindeki küçük bir değişiklik bile binlerce PR oluşmasına yol açtı
  • Etkilenmeyen depolara da (Wycheproof vb.) yanlış güvenlik uyarıları gönderildi
• Uyarılar, yanlış CVSS puanları ve düşük uyumluluk göstergeleri içererek gereksiz kaygı yaratıyor
• Bu aşırı bildirimler, güvenlik müdahalesinin güvenilirliğini ve verimliliğini düşüren bir etken olarak gösteriliyor

govulncheck ile alternatif

• Go Vulnerability Database, sürüm, paket ve sembol düzeyinde ayrıntılı meta veri sağlıyor
  • Örneğin GO-2026-4503 açığı yalnızca Point.MultiScalarMult sembolünü etkiliyor
• govulncheck, statik analizle yalnızca gerçekten çağrılabilir savunmasız kodu tespit ediyor
  • go mod why ile birlikte kullanıldığında dolaylı bağımlılıkların etkisini doğru biçimde değerlendirmek mümkün
  • İnceleme sonucunda, açık mevcut olsa bile kod ilgili sembolü çağırmıyorsa uyarı vermiyor
• CLI (govulncheck -json) ya da Go API'si (golang.org/x/vuln/scan) üzerinden kolayca entegre edilebiliyor

GitHub Actions ile ikame

• Dependabot yerine govulncheck GitHub Action kurularak her gün otomatik tarama yapılabiliyor
  • Yalnızca gerçek bir açık bulunduğunda bildirim gönderiliyor
  • Otomatik PR oluşturulmadığı için geliştiriciler önemli güvenlik sorunlarına odaklanabiliyor
• Yanlış uyarıları azaltmak, güvenlik uyarısı yorgunluğunu (alert fatigue) hafifletip müdahale kalitesini artırabiliyor
• Açık kaynak bakımcılarına gereksiz PR gönderilmesi sorunu da ortadan kalkıyor

Bağımlılık güncellemelerini yönetme yöntemi

• Bağımlılıklar, her projenin geliştirme döngüsüne uygun şekilde toplu olarak yönetilmeli
  • Her gün en güncel sürümlerle test yapılabilir, ancak gerçek güncellemeler yalnızca ihtiyaç duyulduğunda gerçekleştirilir
  • Go'da go get -u -t ./..., npm'de npm update komutlarıyla en güncel sürümler test edilebilir
• Bu yöntem, güvenlik açıklarına yanıt hızını ve kararlılığı birlikte sağlar
  • En güncel sürümlerle test ederek uyumluluk sorunları erkenden tespit edilebilir
  • Zararlı kod içeren bağımlılıkların hemen dağıtıma alınması engellenebilir
• geomys/sandboxed-step kullanıldığında CI ortamında gVisor ile yalıtılmış çalıştırma mümkün

Sonuç ve destek arka planı

• Dependabot'un otomasyonu çoğu zaman güvenlikten çok gürültü (noise) üretiyor
• govulncheck ve periyodik test temelli yaklaşım, daha doğru ve sürdürülebilir bir güvenlik yönetimi yöntemi
• Yazının yazarının açık kaynak bakımı, Geomys organizasyonu üzerinden Ava Labs, Teleport, Tailscale, Sentry gibi destekçiler sayesinde sürdürülüyor
• Bu model, açık kaynak ekosisteminin istikrarlı biçimde sürdürülmesine ve güvenlik kalitesinin artmasına katkı sağlıyor

[GN⁺]

Hacker News görüşleri

• Dependabot belli ölçüde değerli
  Ancak yalnızca sürüm numaralarını ve zafiyet veritabanını karşılaştıran araçlar, kodun gerçekten o zafiyete maruz olup olmadığını anlayamadığı için çok fazla gürültü üretiyor
  Son dönemde beni etkileyen araç CodeQL oldu. GitHub Advanced Security içinde çalıştırılabiliyor ve kodun gerçek akışını izleyerek girdilerin tehlikeli bir kullanıma nasıl ulaştığını gösteren tam yolu görsel olarak sunuyor
  Bu sayede gerçekten düzeltme yapılabilecek bilgi sağlıyor ve yanlış pozitif oranı düşük oluyor. Elbette Python gibi dinamik dillerde tespitten kaçabilecek kodlar olabilir ama çoğu durumda yeterince faydalı
  • Eskiden CodeQL projeye yardımcı oluyordu ama son zamanlarda sinir bozucu bir seviyeye geldiği için ekipte kapattık
    Sırf CodeQL uyarılarından kaçınmak için işe yaramayan ara değişkenler ekleme gibi yorumlar çıkıyor. Veriye aşırı uyarlanmış bir araç gibi hissettiriyor
  • “Neredeyse hiç yanlış pozitif yok” sözüne katılmak zor. Rice teoremine göre böyle kusursuz bir analiz mümkün değil
  • Benim deneyimimde CodeQL çok yanlış pozitif veriyor ve yerelde kolayca çalıştırmanın bir yolu olmadığı için satıcıya bağımlılık yaratıyor
  • Bağımlılık sürümünü yükseltmek güvenliğin artacağını garanti etmez. Yeni sürüm yeni zafiyetler de getirebilir
• NPM paketlerinde çok fazla ReDoS uyarısı çıkıyor. Bunların çoğu yalnızca istemci kodunda kullanılan paketler ama arka uçla ilgisiz uyarılar aşırı fazla. İstemci tarafı ReDoS bizim için anlamlı değil
  • Aslında DoS bir güvenlik açığı değil, erişilebilirlik sorunu diye düşünüyorum. Güvenliğin CIA üçlüsünden biri olsa da pratikte daha çok operasyonel bir meseleye yakın. DoS'u güvenlik sorunu diye sınıflandırmak sadece tarihsel bir kalıntı
  • Ben debug paketinin bakımını yapıyorum ve saçma ReDoS raporları çok fazla geliyor. Hatta CVE kaydı açılanlar bile var; bu yüzden JS ekosisteminden tamamen uzaklaşmak istiyorum
  • Yapay zeka kod inceleme araçlarında da benzer bir sorun yaşıyorum. Yerelde kullanıcı yetkileriyle çalışan bir araç olmasına rağmen girdileri gereksiz yere sanitize etmemi söylüyor. Sonuçta zaman kaybı
  • Biz de aynı sorunu yaşıyoruz. Özellikle geliştirme bağımlılıklarından gelen ReDoS uyarıları gereksiz gürültü oluşturuyor
  • ReDoS, regex motorunun bir hatası ama V8 gibi motorlar hâlâ güvenli bir regex motorunu varsayılan olarak sunmuyor
• Govulncheck, Go ekosistemindeki en iyi özelliklerden biri
  PR içinde zafiyetli bir çağrı eklendiğinde bildirim veren bir GitHub Action hazırlayıp kullanıyorum.
  Dependabot otomatik birleştirme ile birlikte kullanınca JS kod tabanını yönetmek için de iyi bir kombinasyon oluyor
  • Govulncheck de kusursuz değil. Yanlış pozitifleri var ve belirli zafiyetleri CVE numarasına göre hariç tutmanın bir yolu yok
• Dependabot faydalı ama aynı zamanda bağımlılıkları en aza indirmenin önemini her gün hatırlatıyor
  • Ben de her sabah Dependabot PR'larıyla uğraşarak güne başlıyorum.
    Testler yeterliyse yeni sürümlerde hataları da yakalayabiliyorsunuz ama bu süreç bazen açık kaynak katkısına da dönüşüyor. Uğraştırıcı ama iyi alışkanlık kazandırıyor
  • Ben de katılıyorum. Çok fazla projem yok ama Dependabot oldukça işe yarıyor
• Dependabot'un e-posta yerine depo içindeki sekmeler gibi bir yapıda yönetilmesi güzel olurdu.
  E-posta bildirimleri can sıkıyor ve PR'ların birikmesini de sevmiyorum. Sadece belli zamanlarda topluca ilgilenmek istiyorum
  • dependabot.yml ayarlarıyla çalışma sıklığını ve PR sayısını ayarlayabilirsiniz
    resmî belgeler
  • Otomatik PR'ları kapatıp yalnızca gerektiğinde elle oluşturmak da mümkün.
    Doğrudan kendin düzeltip issue sayısını azaltma yöntemi de var
  • Refined GitHub eklentisi kullanılırsa varsayılan görünüm biraz daha temiz oluyor.
    Ben şahsen Renovate öneririm. Daha fazla dili ve otomatik birleştirme seçeneğini destekliyor
• Go'daki govulncheck yaklaşımının (gerçek çağrı yolunu izleme) tüm ekosistemlerde varsayılan olması gerek
  Dependabot'un temel sorunu, bağımlılık yönetimini güvenlik sorunu sanması.
  Çağrılmayan bir fonksiyondaki zafiyet güvenlik meselesi değil, gürültüdür
  Python tarafında pip-audit --desc, Dependabot'tan daha iyi hissettiriyor.
  Kusursuz statik analiz gelene kadar üç ayda bir yapılan manuel kontroller daha güvenli bile olabilir
  • Ama müşteri böyle araçlarla kodu tarıyorsa “o fonksiyonu kullanmıyoruz” yanıtına güvenmiyor.
    Gerçek güvenlikle güvenlik uygulamaları arasındaki kopukluk burada ortaya çıkıyor
  • “Kullanmıyorsanız o fonksiyon neden hâlâ kodda duruyor?” sorusu da makul
• Sektörün neden böyle yüzeysel güvenlik tarayıcılarını benimsediğini anlamıyorum
  CVE'lerin çoğu gerçekte etkili değil ama şirketler konteyner imajlarındaki zafiyet sayısını sıfıra indirmeye çalışıyor
  Üstelik bağımlılıkları güncellediğinizde yeni CVE'ler çıkması da kaçınılmaz. Çünkü çoğu yazılım backport düzeltmesi yapmıyor
  • “Backport yapmıyor” kısmının önceki cümleyle nasıl bağlandığını pek anlayamadım
• Dependabot veya Renovate'in avantajı, dilden bağımsız çalışmaları
  Depo sayısı fazla ve diller çeşitliyse kusursuz bir CI iş akışı eklemek gerçekçi değil
  Mükemmel olmasa da hiçbir şey yapmamaktan çok daha iyi olduğunu düşünüyorum
• Dependabot'un CVSS puanının nereden geldiğini merak ediyorum.
  CVE'leri otomatik mi oluşturuyor?
  • CVSS, en kötü senaryo varsayımıyla verilen bir puan olduğu için gerçek riski yansıtmıyor.
    GitHub'ın zafiyet veritabanı kaliteden çok niceliğe odaklanıyor ve Dependabot akılsız bir spam uyarı sistemi gibi çalışıyor
  • O hatanın gerçekten gerçek bir zafiyet olup olmadığı bile şüpheli.
    Sorun sadece fonksiyon yanlış şekilde çağrıldığında ortaya çıkıyorsa, büyük ihtimalle kod zaten düzgün çalışmıyordu
• Bizim şirket de benzer sorunlar yaşıyor.
  GCP konteyner imaj taraması, Vanta'ya tonla CVE uyarısı gönderiyor ama bunların çoğu ya düzeltilemez durumda ya da gerçekte kullanılmayan yollarla ilgili
  Böyle bağlama dayalı filtreleme yapan bir araç var mı diye merak ediyorum
  • Bizim şirkette Aikido Code kullanılıyor. Yapay zeka ile zafiyetlerin gerçek etkisini filtrelemeye çalışıyor.
    Sonuçlar genel olarak olumlu ama kod tabanı büyük ve bağımlılıklar çok olduğunda CVE sayısını azaltmak hâlâ zor