GitHub, 15.000'den fazla depoda tespit edilen binlerce gizli veri sızıntısı uyarısını yönetmek için geliştirdiği stratejiyi ve elde ettiği başarıyı paylaştı.
Ne oldu?
GitHub güvenlik ekibi, kod tabanlarındaki kimlik bilgilerini ve gizli anahtarları koruma altına almak amacıyla başlattığı büyük ölçekli temizlik operasyonunda, 15.000'den fazla depo (repository) genelinde tespit edilen 20.000'den fazla "secret" (gizli anahtar, API token'ı ve şifre) uyarısını dokuz ay içinde sıfırlamayı başardı. İlk incelemede ürkütücü görünen bu 20.000 uyarının yaklaşık %90'ının (18.000 adet), test ortamlarında kullanılan pasif veya sahte anahtarlardan ibaret olduğu anlaşılarak hızlıca elendi. Kalan 2.000'den fazla aktif veya potansiyel risk taşıyan uyarının ise kapsamlı doğrulama süreçleri, durumsal oyun planları (playbook) ve departmanlar arası iş birlikleri sayesinde başarılı bir şekilde temizlenmesi veya güvenli hale getirilmesi sağlandı.
Neden önemli?
Yazılım geliştirme süreçlerinde API anahtarlarının ve şifrelerin yanlışlıkla genel veya özel depolarda paylaşılması, günümüzde en yaygın siber güvenlik zafiyetlerinden biridir. GitHub gibi küresel ölçekteki bir platformun bile geçmişten gelen kod alışkanlıkları ve miras (legacy) sistemler nedeniyle bu sorunla karşı karşıya kalması, her ölçekteki teknoloji firmasının benzer riskler altında olduğunu göstermektedir. Kod depolarına sızan gizli anahtarlar, saldırganların üretim sistemlerine yetkisiz erişim sağlamasına ve ciddi veri ihlallerine yol açabilir.
GitHub'ın bu süreci yönetirken kullandığı yöntemler, büyük şirketlerin güvenlik ekiplerinin binlerce uyarı karşısında paniklemek yerine "gürültüyü sinyalden ayırmasının" önemini kanıtlamaktadır. Güvenlik taramalarındaki yanlış pozitifleri hızla kapatmak, doğrulama (validity checking) mekanizmalarıyla hangi anahtarların gerçekten aktif olduğunu anlamak ve yeni kod yüklemelerini "Push Protection" ile kaynaktan engellemek, modern DevSecOps süreçlerinin temel yapı taşları haline gelmiştir.
Kim veya ne etkileniyor?
Bu durum, GitHub'ın kendi altyapısını geliştiren mühendislik ekiplerinden müşteri destek birimlerine, hata ödül (bug bounty) programı araştırmacılarından platformu entegrasyonlarla kullanan kurumsal müşterilere kadar çok geniş bir ekosistemi doğrudan etkiliyor. Güvensiz bir şekilde saklanan anahtarlar sadece kaynak kodda değil; destek biletlerinde, hata bildirim raporlarında ve wiki sayfalarında da bulunabiliyordu. Dolayısıyla, kimlik doğrulaması yetersiz olan tüm iç ve dış sistemler, API entegrasyonları ve bu entegrasyonların bağlı olduğu üçüncü taraf bulut sağlayıcıları bu güvenlik temizliği sürecinde doğrudan etkilenen unsurlar arasında yer almaktadır.
Ne yapılmalı?
Şirketlerin ve yazılım geliştiricilerin kod güvenliğini sağlamak için güvenlik tarama araçlarını etkinleştirmesi, kodlerin depoya gönderilmesini denetleyen "Push Protection" özelliğini zorunlu kılması ve her şeyden önce de depoların ve gizli anahtarların kalıcı sahiplerini belirlemesi gerekmektedir. Aktif bir sızıntı tespit edildiğinde, geçmiş git geçmişini silerek geliştirici süreçlerini bozmak yerine öncelikle sızan anahtarın iptal edilmesi veya döndürülmesi (rotation) uygulanmalıdır. GitHub'ın bu süreçte geliştirdiği geçerlilik kontrolü ve sahiplik özellikleri artık platformda yerleşik olarak sunulduğu için, organizasyonların bu araçları istisnasız bir şekilde tüm kurumsal düzeyde aktif hale getirmesi en kritik savunma adımıdır.
Kaynaklar:
- GitHub Blog: How GitHub used secret scanning to reach inbox zero
- GitHub Blog: GitHub's Engineering Fundamentals Program