Kuruluşlar İçin GitHub Güvenliğini Sıfırdan Sertleştirme Rehberi

GitHub artık sadece bir kod barındırma platformu değil. Günümüzde çoğu mühendislik organizasyonu için GitHub, kimlik yönetimi, yazılım tedarik zinciri, sürekli entegrasyon/sürekli dağıtım (CI/CD), gizli anahtar deposu, dağıtım orkestratörü ve üretim değişiklik kontrol sisteminin tümünün merkezinde yer alıyor. Bu nedenle, GitHub’ı üretim kontrol düzlemi gibi korumak hayati önem taşıyor.

Bu rehber, bir CISO’nun organizasyon genelinde GitHub’ı nasıl sıkılaştırabileceğine dair pratik bir yaklaşım sunuyor. Yüksek seviyeli önerilerden öte, doğrudan uygulanabilir, denetlenebilir ve zamanla geliştirilebilir bir sertleştirme temelini hedefliyor. Hedef basit: GitHub’ın gevşek yönetimi nedeniyle kaynak kodun, iş akışlarının, gizli anahtarların, derleme sistemlerinin, yayın süreçlerinin ya da üretim ortamlarının tehlikeye atılmaması.

Rehberin Katmanlı Kullanımı

Bu rehber üç farklı düzeyde kullanılabilir:

• Yönetici Katmanı (Executive Baseline): CISO, Baş Mühendislik Yöneticisi ve Platform liderleri için. GitHub’ın neden bir Tier-0 mühendislik kontrol düzlemi olduğunu tanımlar.
• Güvenlik Standardı (Security Standard): Güvenlik, Platform Mühendisliği, Uygulama Güvenliği (AppSec) ve DevSecOps ekipleri için. Zorunlu kontrolleri, kanıtları, istisnaları ve sahipliği belirler.
• Operasyonel El Kitabı (Operational Runbook): SOC ekipleri, repository sahipleri ve yayın mühendisleri için. Kurulum, izleme, tespit ve çeyreklik incelemeleri destekler.

Kontrol Dili ve Anlamı

Rehberdeki ifadelerin anlamları şu şekilde yorumlanmalıdır:

• Must / Required: Zorunlu temel kontrol. Belgelenmiş istisna olmadıkça uygulanması gerekir.
• Should / Recommended: Güçlü öneri. Sapmaların belgelenmiş gerekçesi olmalıdır.
• May / Optional: Bağlama bağlı kontrol. Repository sınıflandırması ve risk düzeyine göre değerlendirilir.
• Exception: Zaman sınırlı, risk kabul edilmiş sapma. Sahibi, telafi edici kontrolleri ve inceleme tarihiyle birlikte belgelenmelidir.

Her zorunlu kontrolün nihayetinde aşağıdaki şekilde haritalanması gerekir:

Kontrol Kimliği → Gereklilik → Sahip → Uygulama → Kanıt → İzleme → İstisna Yolu

Bu yaklaşım, rehberin uzun bir kontrol listesinden ibaret olup uygulanamaz hale gelmesini engeller.

Temel Varsayımlar

Bu rehber aşağıdaki varsayımlar altında hazırlanmıştır:

• GitHub Organizasyonu veya GitHub Enterprise Cloud kullanımı.
• Repository’lerde üretim uygulama kodları, altyapı olarak kod (IaC), otomasyonlar, CI/CD iş akışları ve iç araçlar yer alır.
• GitHub Actions aktif olarak kullanılıyor veya planlama aşamasında.
• Geliştiriciler normal değişiklikler için pull request’leri kullanır.
• Bazı repository’ler AWS, Azure, GCP, Kubernetes, paket kayıt defterleri veya dağıtım araçlarına bağlanır.
• Kontrollerin uygulanabilir, denetlenebilir ve operasyonel olarak gerçekçi olması hedeflenir.

Bir özelliğin GitHub Enterprise, GitHub Advanced Security, GitHub Secret Protection veya plan bazlı yeteneklere bağlı olduğu durumlarda, kullanımdan önce lisans ve yeteneklerin doğrulanması gerekir.

GitHub Yeteneği ve Lisans Doğrulama Matrisi

Bu standardı uygulamadan önce, kullanılan GitHub planında ve kurumsal yapılandırmada hangi yeteneklerin mevcut olduğunu doğrulamak önemlidir. GitHub özellikleri zamanla değişebilir ve bazı kontroller yalnızca aşağıdaki yeteneklere sahip planlarda kullanılabilir:

• Enterprise kimlik yönetimi: SAML SSO, SCIM, Enterprise Managed Users (EMU). Kurumsal/kuruluş kimlik ayarları ve kimlik sağlayıcı (IdP) tabanlı erişim incelemeleri.
• Organizasyon genelinde repository yönetimi: Organizasyon veya kurumsal kurallar. Özel repository’ler için kuralların API/IaC aracılığıyla yönetimi.
• Gizli anahtarların korunması: Secret tarama ve push koruması. GitHub Secret Protection veya üçüncü parti araçlarla desteklenebilir.
• Kod güvenliği: CodeQL/code tarama, varsayılan kurulum, güvenlik genel bakışı. Code Security veya GitHub Advanced Security (GHAS) gerektirir.
• Bağımlılık güvenliği: Dependabot uyarıları, bağımlılık incelemesi, güvenlik güncellemeleri. Repository güvenlik ayarları ve paket ekosistemi desteği.
• Denetim izleme: Denetim log kaydı/ihracı/API/streaming. Kurumsal ve organizasyon düzeyinde denetim log ayarları ve SIEM’e aktarım.
• CI/CD kimlik federasyonu: GitHub Actions OIDC. Bulut sağlayıcı ve GitHub Actions uyumluluğu.
• Artefakt bütünlüğü: GitHub artefakt onayları veya dış imzalama/bütünlük doğrulaması. Actions ve yayın iş akışları desteği.
• Runner izolasyonu: Runner grupları, ephemeral runner’lar, barındırılan runner kontrolleri. Kurumsal Actions runner ayarları ve kısa ömürlü runner örnekleri.

Yaygınlaştırma Kuralı:

Güvenlik hedefini zayıflatmayın çünkü yerel bir özellik mevcut değil. Ya gerekli GitHub yeteneğini etkinleştirin, onaylı üçüncü parti bir kontrol kullanın ya da telafi edici kontrollerle birlikte belgelenmiş bir zaman sınırlı istisna oluşturun.

1. Yönetişim Modeli: GitHub’ı Tier-0 Mühendislik Platformu Olarak Kabul Etmek

Organizasyonların yaptığı en büyük hatalardan biri GitHub’ı sadece mühendislik ekiplerinin sahipliğinde bir geliştirici aracı olarak görmektir. Bu yaklaşım yetersiz kalır.

GitHub için resmi bir sahiplik modeli oluşturulmalıdır. Bu model aşağıdaki alanları kapsamalıdır:

• Enterprise ve organizasyon ayarları: CISO / Baş Mühendislik Yöneticisi sorumluluğundadır. Merkezi politika, erişim kontrolü ve denetlenebilirlik sağlar.
• Repository sahipliği: Mühendislik liderliği ve repository bakıcıları tarafından yönetilir. Güvenli değişiklik kontrolü ve kod sahipliği sağlar.
• GitHub Actions: Platform Mühendisliği, DevOps ve DevSecOps ekipleri tarafından yönetilir. Kontrollü CI/CD yürütülmesini sağlar.
• Gizli anahtarlar ve token’lar: Güvenlik ve Platform ekipleri tarafından yönetilir. Uzun ömürlü yönetilmemiş kimlik bilgileri kullanılmamalıdır.
• OAuth / GitHub Uygulamaları: Güvenlik Platformu tarafından onaylı entegrasyonlar kullanılır.
• Kendi kendine barındırılan runner’lar: Platform Mühendisliği ve Altyapı/DevOps ekipleri tarafından izole edilmiş, izlenen ve mümkünse ephemeral runner’lar tercih edilir.
• Güvenlik uyarıları: AppSec ekipleri tarafından takip edilir.

Bu model, GitHub’ın sadece bir kod barındırma aracı değil, organizasyonun tüm mühendislik süreçlerinin güvenliğini sağlayan kritik bir bileşen olduğunu kabul eder. Gelecekteki tehditlere karşı esnek ve ölçeklenebilir bir güvenlik yapısı oluşturur.