Git Güvenliği: 10 Best Practice ile Kapsamlı 2026 Rehberi

# Git Güvenliği: 10 Best Practice ile Kapsamlı 2026 Rehberi Her yıl milyarlarca satır kod Git depolarında depolanıyor ve yönetiliyor. Ancak, bu muazzam dijital varlığın güvenliği, 2026'da siber saldırıların artan karmaşıklığı karşısında kritik bir öneme sahip. Birçok geliştirici, Git'i sadece bir versiyon kontrol sistemi olarak görürken, onun sunduğu güvenlik mekanizmalarını ve potansiyel zafiyetlerini göz ardı ediyor. Peki, kod tabanınızın bütünlüğünü ve gizliliğini nasıl garanti altına alabilirsiniz? Bu kapsamlı 2026 rehberinde, Git'in iç güvenlik mimarisinden başlayarak, en güncel best practice'lere, ileri seviye tekniklere ve yaygın hataların çözümlerine kadar her şeyi derinlemesine inceleyeceğiz. İster bireysel bir geliştirici olun ister büyük bir ekibin parçası, bu rehber sayesinde Git depolarınızı siber tehditlere karşı daha dirençli hale getirecek, üretim ortamında karşılaştığımız en yaygın güvenlik sorunlarına pratik çözümler bulacak ve 2026'nın güvenlik standartlarına uygun bir Git iş akışı oluşturacaksınız. Hazırsanız, kodunuzu güvence altına alma yolculuğuna başlayalım! ## Git Güvenliği Nedir? Git güvenliği, versiyon kontrol sistemi Git'i kullanarak depolanan kod tabanının ve ilgili meta verilerin yetkisiz erişime, değişikliğe veya ifşaya karşı korunması süreçlerinin bütünüdür. Bu, kod bütünlüğünü sağlamak, kimlik doğrulama mekanizmalarını güçlendirmek, erişim kontrollerini sıkılaştırmak ve potansiyel zafiyetleri proaktif olarak yönetmek anlamına gelir. Git'in 2026 itibarıyla kararlı sürümü olan 2.46.0 ve sonraki sürümleri, bu güvenlik prensiplerini destekleyen güçlü mekanizmalar sunar. Detaylı olarak ele alındığında, Git güvenliği sadece `git push` ve `git pull` komutlarının güvenli bir şekilde çalışmasını sağlamakla kalmaz. Aynı zamanda, commit geçmişinin değiştirilemezliğini, commit'lerin kimlik doğrulamasını (imzalama), hassas verilerin depolamasını engellemeyi, branch koruma kurallarını uygulamayı ve CI/CD süreçlerinde güvenlik açıklarını tespit etmeyi kapsar. Git'in dağıtık yapısı, her geliştiricide kodun tam bir kopyasının bulunması nedeniyle, merkezi sistemlere göre farklı güvenlik zorlukları ve fırsatları sunar. Bu nedenle, her bir geliştiricinin ve ekibin güvenlik farkındalığı, Git güvenliğinin temelini oluşturur. ## Neden Git Güvenliği Önemlidir? Git güvenliği, modern yazılım geliştirme süreçlerinde kod tabanının ve dolayısıyla tüm projenin kritik bir bileşenidir. 2026 itibarıyla siber güvenlik tehditlerinin boyutu ve karmaşıklığı göz önüne alındığında, Git depolarının korunması artık bir lüks değil, zorunluluktur. İşte Git güvenliğinin neden bu kadar hayati olduğuna dair somut faydalar ve ele aldığı problemler: * **Kod Bütünlüğü ve Değiştirilemezlik**: Git'in temelinde yatan SHA-1 (veya gelecekteki sürümlerde SHA-256) hash mekanizması, her commit'in benzersiz bir kimliğe sahip olmasını sağlar. Bu, geçmişin manipüle edilmesini zorlaştırır. Ancak, yetkisiz `git push --force` işlemleri veya kötü niyetli commit'ler bu bütünlüğü bozabilir. Güvenlik, bu tür manipülasyonları engellemeyi hedefler. * **Hassas Veri Sızıntısını Önleme**: API anahtarları, veritabanı şifreleri, kişisel tanımlayıcı bilgiler (PII) gibi hassas verilerin yanlışlıkla Git depolarına commit edilmesi, ciddi güvenlik ihlallerine yol açabilir. Git güvenliği, bu tür verilerin depoya girmesini engelleyen mekanizmalar (örn. `git-secrets`, pre-commit hook'lar) sunar. * **Yetkisiz Erişim ve Kod Hırsızlığı**: Özellikle özel (private) depolarda, kod tabanının yetkisiz kişiler tarafından erişilmesi veya çalınması, fikri mülkiyet hırsızlığına ve rekabet avantajının kaybedilmesine neden olabilir. Doğru kimlik doğrulama (SSH anahtarları, token'lar) ve yetkilendirme (branch koruma, erişim listeleri) bu riski minimize eder. * **Tedarik Zinciri Güvenliği (Supply Chain Security)**: Bir projenin bağımlılıkları (libraries, packages) genellikle Git depolarından çekilir. Eğer bir bağımlılık deposu tehlikeye atılırsa, projenize kötü amaçlı kod enjekte edilebilir. Git güvenliği, imzalı commit'ler ve güvenilir kaynak kontrolleri ile bu riski azaltmaya yardımcı olur. * **Denetlenebilirlik ve Sorumluluk**: Hangi değişikliğin kim tarafından, ne zaman yapıldığının net bir kaydı, güvenlik ihlallerinin tespiti ve sorumluların belirlenmesi için hayati öneme sahiptir. Güvenli Git uygulamaları, bu denetlenebilirliği artırır. * **Yasal ve Düzenleyici Uyumluluk**: GDPR, HIPAA, ISO 27001 gibi birçok yasal ve düzenleyici çerçeve, hassas verilerin ve fikri mülkiyetin korunmasını gerektirir. Güvenli Git uygulamaları, bu uyumluluk gereksinimlerini karşılamaya yardımcı olur. **Kimler için uygun, kimler için değil?** Git güvenliği, yazılım geliştiren her birey ve ekip için uygun ve gereklidir. Küçük kişisel projelerden büyük kurumsal uygulamalara kadar her ölçekteki projede uygulanmalıdır. “Benim projem küçük, kim saldıracak ki?” düşüncesi, 2026'da artık geçerli değildir; otomatik tarayıcılar ve botlar, savunmasız depoları sürekli aramaktadır. Dolayısıyla, Git kullanan herkes için Git güvenliği birincil öncelik olmalıdır. ## Git vs Alternatif SCM'ler: Güvenlik Karşılaştırması Git, dağıtık yapısıyla modern yazılım geliştirmenin omurgası haline gelmiş olsa da, piyasada Mercurial ve Subversion (SVN) gibi başka versiyon kontrol sistemleri de bulunmaktadır. Her birinin güvenlik yaklaşımı ve sunduğu özellikler farklılık gösterir. İşte 2026 itibarıyla bu üç sistemin güvenlik odaklı bir karşılaştırması: | Özellik | Git (Dağıtık) | Mercurial (Dağıtık) | Subversion (Merkezi) | | :--------------------- | :----------------------------------------------- | :------------------------------------------------ | :-------------------------------------------------- | | **Kod Bütünlüğü** | SHA-1 (veya SHA-256) hash ile her commit'in ve objenin bütünlüğü sağlanır. Kriptografik olarak güçlü. | SHA-1 hash ile Git'e benzer bütünlük sağlar. | Sunucu tarafında veritabanı bütünlüğü. Dosya bazında revizyon takibi. | | **Değiştirilemezlik** | Geçmiş, hash'ler aracılığıyla kriptografik olarak imzalanır. `git rebase` veya `git push --force` ile değiştirilebilir ancak bu iz bırakır. | Git'e benzer şekilde geçmiş bütünlüğü. Geçmiş manipülasyonu iz bırakır. | Merkezi sunucu veritabanı sayesinde geçmiş değiştirilemezdir. | | **Kimlik Doğrulama** | SSH anahtarları, HTTPS token'ları, GPG ile commit imzalama. | SSH anahtarları, HTTPS token'ları. | Kullanıcı adı/şifre, LDAP, Kerberos. | | **Erişim Kontrolü** | Repository bazında genellikle barındırma hizmeti (GitHub, GitLab) tarafından sağlanır. Branch koruma kuralları. | Repository bazında barındırma hizmeti tarafından sağlanır. | Sunucu tarafında dizin ve dosya bazında granüler yetkilendirme. | | **Hassas Veri Yönetimi**| `git-secrets`, `git-crypt`, `pre-commit hook`'lar ile engelleme. Dışarıdan araçlarla entegrasyon gerekir. | `hgsubversion` eklentisi ile SVN entegrasyonu. `strip` komutuyla geçmiş temizliği. | Merkezi sunucuda hassas verilerin depolanmaması için katı kurallar uygulanabilir. | | **Denetlenebilirlik** | Commit geçmişi, yazar bilgileri. İmzalı commit'ler ile yazar doğrulaması. | Git'e benzer denetlenebilirlik. | Merkezi sunucuda tüm işlemlerin loglanması. | | **Dağıtık Yapının Etkisi**| Her geliştiricide tam kopya olması, tek noktadan saldırı riskini azaltır ancak her kopyanın güvenliği önemlidir. | Git'e benzer dağıtık yapı avantajları ve zorlukları. | Merkezi sunucuya bağımlılık, tek noktadan saldırı riskini artırır. | | **Topluluk ve Ekosistem**| Çok geniş topluluk, zengin güvenlik araçları ve entegrasyonlar. | Orta büyüklükte topluluk, bazı güvenlik eklentileri. | Azalan topluluk, daha eski güvenlik yaklaşımları. | **Yorum**: 2026 itibarıyla Git, dağıtık yapısı ve güçlü kriptografik bütünlük mekanizmaları sayesinde genel olarak daha üstün bir güvenlik modeli sunmaktadır. Özellikle GPG ile commit imzalama ve geniş ekosistemindeki güvenlik araçları, Git'i öne çıkarmaktadır. SVN, merkezi yapısı nedeniyle granüler erişim kontrolünde avantaj sağlayabilirken, tek bir sunucuya bağımlılık ve dağıtık geliştirme modeline adaptasyon eksikliği güvenlik zafiyetleri yaratabilir. Mercurial ise Git'e oldukça benzer bir güvenlik profiline sahiptir, ancak ekosistem büyüklüğü ve araç çeşitliliği açısından Git'in gerisindedir. ## Temel Git Güvenlik Ayarları ve Kurulumu Git'i güvenli bir şekilde kullanmaya başlamak, doğru yapılandırma ve temel ayarların uygulanmasıyla mümkündür. Bu bölümde, 2026'nın en güncel Git sürümü (örneğin 2.46.0) üzerinden temel güvenlik ayarlarını adım adım ele alacağız. ### 1. Git Kullanıcı Bilgilerini Doğru Yapılandırma Her commit'in bir yazar bilgisi vardır. Bu bilgilerin doğru ve tutarlı olması, denetlenebilirlik açısından kritik öneme sahiptir. Gerçek adınızı ve kurumsal e-posta adresinizi kullanın. ```bash git config --global user.name "Burak Balkı" git config --global user.email "burak.balki@example.com" # Bu bilgileri kontrol edin git config --list | grep user ``` > **Pro Tip**: Kurumsal projeler için `--global` yerine `--local` veya `--system` kullanarak farklı depolar için farklı kimlikler tanımlayabilirsiniz. Özellikle kişisel ve iş projelerini ayırırken bu önemlidir. ### 2. Güvenli Kimlik Doğrulama Mekanizmaları: SSH ve HTTPS Token'ları Parola tabanlı kimlik doğrulama yerine SSH anahtarları veya kişisel erişim token'ları (Personal Access Tokens - PATs) kullanmak, Git işlemlerinizi çok daha güvenli hale getirir. #### SSH Anahtarları ile Kimlik Doğrulama SSH anahtarları, şifre gerektirmeyen, kriptografik olarak güvenli bir kimlik doğrulama yöntemidir. 2026 itibarıyla RSA yerine ECDSA veya Ed25519 gibi modern algoritmalar tercih edilmelidir. 1. **SSH Anahtar Çifti Oluşturma (Ed25519 önerilir)**: ```bash ssh-keygen -t ed25519 -C "burak.balki@example.com" # Anahtarınızı kaydetmek için bir parola belirleyin. Bu, özel anahtarınızın çalınması durumunda ek bir güvenlik katmanı sağlar. ``` 2. **SSH Agent'ı Başlatma ve Anahtarı Ekleme**: ```bash eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519 ``` 3. **Genel Anahtarı Git Barındırma Sağlayıcınıza Ekleme**: `~/.ssh/id_ed25519.pub` içeriğini GitHub, GitLab veya Bitbucket hesabınızın SSH ayarları bölümüne kopyalayın. #### Kişisel Erişim Token'ları (PATs) ile Kimlik Doğrulama (HTTPS için) Eğer HTTPS kullanıyorsanız, kullanıcı adı ve parola yerine PAT'ler kullanın. PAT'ler, belirli izinlerle ve belirli bir süre için oluşturulabilir, böylece çalınmaları durumunda riski azaltır. 1. **PAT Oluşturma**: Git barındırma sağlayıcınızın ayarlarından (örn. GitHub -> Settings -> Developer settings -> Personal access tokens) yeni bir token oluşturun. Yalnızca gerekli izinleri (örn. `repo`, `read:org`) verin ve süresini sınırlayın. 2. **Git Credential Helper Kullanımı**: PAT'inizi doğrudan komut satırına yazmak yerine Git credential helper kullanın. Bu, token'ınızın hafızada veya güvenli bir depoda saklanmasını sağlar. ```bash git config --global credential.helper store # İlk push veya pull işleminde PAT'inizi girdiğinizde, helper bunu kaydedecektir. # Alternatif olarak, macOS için `osxkeychain`, Windows için `wincred` kullanabilirsiniz. git config --global credential.helper osxkeychain # macOS için git config --global credential.helper wincred # Windows için ``` ### 3. Otomatik Düzeltmeleri Kapatma (Autocorrect) Git'in otomatik düzeltme özelliği, yanlış yazılan komutları düzeltmeye çalışır. Ancak bu, kötü niyetli bir saldırganın yanıltıcı komutlarla sizi yanlış bir işlem yapmaya yönlendirmesine neden olabilir. Bu özelliği kapatmak güvenlik açısından önerilir. ```bash git config --global help.autocorrect 0 ``` Bu temel adımları uygulayarak Git kullanımınızın güvenlik seviyesini önemli ölçüde artırabilirsiniz. Unutmayın, güvenlik sürekli bir süreçtir ve bu ayarlar sadece başlangıçtır. ## Git Commit ve Push Güvenliği Uygulamaları Git'in temel işlemlerinden olan commit ve push, kod tabanının evrimini belirler. Bu işlemlerin güvenli bir şekilde yapılması, kod bütünlüğünü korumak ve yetkisiz değişiklikleri engellemek için hayati öneme sahiptir. 2026'nın modern geliştirme ortamlarında, bu süreçleri güçlendirmek için çeşitli uygulamalar mevcuttur. ### 1. Commit'leri GPG Anahtarları ile İmzalama Commit imzalama, bir commit'in gerçekten iddia edilen kişi tarafından yapıldığını kriptografik olarak doğrular. Bu, kötü niyetli kişilerin başkası adına commit yapmasını veya geçmişi manipüle etmesini engeller. GPG (GNU Privacy Guard) anahtarları bu amaçla yaygın olarak kullanılır. 2026 itibarıyla SHA-256 veya daha güçlü algoritmalarla imzalama tercih edilmelidir. 1. **GPG Anahtarı Oluşturma**: ```bash gpg --full-generate-key # Çıkan yönergeleri takip edin. Ed25519 veya RSA 4096 bit önerilir. # Anahtar oluşturulduktan sonra `gpg --list-secret-keys --keyid-format LONG` komutuyla anahtar kimliğinizi (Key ID) alın. ``` 2. **Git'i GPG Anahtarı ile Yapılandırma**: ```bash git config --global user.signingkey git config --global commit.gpgsign true # Her commit'i otomatik imzala ``` 3. **Commit İmzalama**: ```bash git commit -m "Güvenli commit mesajı" # Otomatik olarak imzalanacaktır # Manuel olarak imzalamak için: # git commit -S -m "Güvenli commit mesajı" ``` 4. **İmzalı Commit'i Doğrulama**: Git barındırma sağlayıcınızda (GitHub, GitLab) GPG anahtarınızı ekledikten sonra, commit'lerinizin yanında "Verified" etiketi görünecektir. Yerel olarak doğrulamak için: ```bash git log --show-signature ``` > **Deneyim Notu**: Production ortamında ekip olarak GPG imzalama zorunluluğu getirdiğimizde, başlangıçta bazı geliştiriciler için kurulum süreci biraz zorlayıcı olabiliyor. Ancak, bu yatırım, kod tabanının sorumluluk ve bütünlük açısından sağladığı güveni katbekat artırıyor. Özellikle açık kaynak projelerde bu, projenin güvenilirliğini artırır. ### 2. Pre-commit Hook'ları ile Hassas Veri Sızıntısını Engelleme Pre-commit hook'lar, commit işlemi tamamlanmadan önce belirli kontrolleri çalıştırmanıza olanak tanır. Bu, hassas verilerin (API anahtarları, şifreler) yanlışlıkla depoya commit edilmesini engellemek için mükemmel bir yöntemdir. 1. **`.git/hooks/pre-commit` Dosyasını Düzenleme**: ```bash #!/bin/sh # Git'in kendisi tarafından sağlanan git-secrets aracını kullanmak en iyisidir. # Kurulum için: git clone https://github.com/awslabs/git-secrets.git && cd git-secrets && make install # Ardından her repoda: git secrets --install && git secrets --register-aws # Basit bir örnek: "password" veya "secret" kelimesini içeren dosyaları kontrol et # Bu sadece bir örnek olup production için daha sağlam araçlar kullanılmalıdır. if git diff --cached | grep -E 'password|secret|api_key|private_key'; then echo "\033[0;31mHATA: Commit'iniz hassas anahtar kelimeler içeriyor. Lütfen kontrol edin.\033[0m" exit 1 fi # Büyük dosyaların commit edilmesini engelle MAX_FILE_SIZE_MB=10 for file in $(git diff --cached --name-only --diff-filter=A); do if [ $(du -m "$file" | awk '{print $1}') -gt $MAX_FILE_SIZE_MB ]; then echo "\033[0;31mHATA: '$file' dosyası çok büyük (>$MAX_FILE_SIZE_MB MB). Lütfen .gitignore'a ekleyin veya büyük dosya depolama (LFS) kullanın.\033[0m" exit 1 fi done exit 0 ``` 2. **Hook'u Çalıştırılabilir Yapma**: ```bash chmod +x .git/hooks/pre-commit ``` > **Uyarı**: `pre-commit` hook'ları yereldir ve kolayca atlatılabilir (`git commit --no-verify`). Bu nedenle, sunucu tarafı `pre-receive` hook'ları ile birlikte kullanılmaları, tam güvenlik sağlamak için kritiktir. ### 3. Sunucu Tarafı Pre-receive Hook'ları ile Push Politikaları Uygulama `pre-receive` hook'ları, bir `git push` işlemi sunucuya ulaşmadan önce çalışır. Bu, zorunlu commit imzalama, belirli branch'lere push yapma kısıtlamaları veya hassas veri taramaları gibi global güvenlik politikaları uygulamak için en güçlü mekanizmadır. Bu hook'lar genellikle Git barındırma sağlayıcınız (GitHub, GitLab, Bitbucket) tarafından yönetilir ve yapılandırılır. Örneğin, GitLab'da "Push Rules" veya GitHub'da "Branch Protection Rules" bu hook'ların bir soyutlamasıdır. * **Örnek `pre-receive` hook senaryosu (Sunucu tarafı)**: * Tüm commit'lerin imzalı olmasını zorunlu kılma. * `master` veya `main` branch'ine doğrudan push yapılmasını engelleme (sadece merge request/pull request üzerinden izin verme). * Belirli dosya türlerinin (örn. `.env`, `.pem`) depoya girmesini engelleme. Bu uygulamalar, Git depolarınızın bütünlüğünü ve güvenliğini hem yerel geliştirme aşamasında hem de sunucu tarafında sağlamak için vazgeçilmezdir. ## Git Repository Güvenliği: İleri Seviye Teknikler Repository güvenliği, sadece commit ve push işlemlerini değil, aynı zamanda depolama, erişim ve yönetim katmanlarını da kapsar. 2026'da kurumsal seviyede Git kullanımı, ileri seviye tekniklerin uygulanmasını gerektirir. ### 1. Branch Koruma Kuralları (Branch Protection Rules) Kritik branch'ler (örn. `main`, `develop`, `release`) üzerinde değişiklik yapılmasını kısıtlamak, kod kalitesini ve güvenliğini artırır. Bu kurallar genellikle Git barındırma platformları tarafından sağlanır. * **Gereksinimler**: Pull Request (PR) onayı, belirli sayıda onaylayıcı, CI/CD testlerinin geçmesi, commit imzalama zorunluluğu. * **Örnek Yapılandırma (GitHub/GitLab benzeri)**: ```json { "branch": "main", "protection_rules": [ {"type": "require_pull_request_reviews", "required_approving_review_count": 2}, {"type": "require_status_checks", "contexts": ["ci/build", "ci/test", "security/snyk"]}, {"type": "require_signed_commits"}, {"type": "restrict_pushes", "allowed_users": [], "allowed_teams": []} ] } ``` ### 2. Hassas Veri (Secrets) Yönetimi API anahtarları, veritabanı şifreleri gibi hassas verilerin Git depolarında saklanması büyük bir güvenlik riskidir. Bu tür veriler, Git dışında güvenli bir şekilde yönetilmelidir. * **Çözümler**: Ortam değişkenleri, Secret Management servisleri (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault), `git-crypt` gibi araçlar. #### `git-crypt` ile Şifreleme `git-crypt`, hassas dosyaları Git deposu içinde şifrelemenizi sağlar. Dosyalar commit edildiğinde şifrelenir, çekildiğinde deşifre edilir. 1. **Kurulum (Örnek: Debian/Ubuntu)**: ```bash sudo apt-get install git-crypt ``` 2. **Depoyu Başlatma**: ```bash git crypt init ``` 3. **Hassas Dosyaları Belirleme (`.gitattributes`)**: ```bash # .gitattributes dosyasına ekleyin secrets/*.env filter=git-crypt diff=git-crypt config/db.json filter=git-crypt diff=git-crypt ``` 4. **Anahtar Ekleme (GPG ile)**: ```bash git crypt add-gpg-user # Veya paylaşılan anahtar dosyası ile: # git crypt export-key /path/to/keyfile ``` 5. **Kullanım**: `git crypt status` ile şifreli dosyaları kontrol edin. Artık bu dosyaları commit edebilirsiniz; Git otomatik olarak şifreleyecektir. > **Tecrübe Paylaşımı**: Son projemizde, `git-crypt` kullanarak API anahtarlarını ve diğer hassas yapılandırma bilgilerini güvenli bir şekilde yöneterek, geliştiricilerin yerel ortamlarında dahi bu bilgilere güvenli erişimini sağladık. Bu, CI/CD süreçlerinde de otomatik deşifreleme ile entegre edilerek büyük kolaylık sağladı. ### 3. Git LFS (Large File Storage) ile Büyük ve Hassas Olmayan Dosyaları Yönetme Büyük ikili dosyalar (resimler, videolar, derlenmiş çıktılar) Git geçmişini şişirir ve performansı düşürür. Ayrıca, yanlışlıkla hassas veri içeren büyük dosyaların geçmişe eklenmesi durumunda, bunları temizlemek çok zor olabilir. Git LFS, bu tür dosyaların Git deposu dışında depolanmasını sağlar, sadece pointer'ları Git içinde kalır. 1. **Kurulum**: ```bash git lfs install ``` 2. **Dosya Türlerini İzleme**: ```bash git lfs track "*.psd" git lfs track "*.zip" git add .gitattributes ``` 3. **Kullanım**: Artık `.psd` veya `.zip` uzantılı dosyaları commit ettiğinizde, Git LFS bunları otomatik olarak yönetecek ve deponun boyutunu küçültecektir. ## Git Güvenliğinde Best Practices & Anti-Patterns Git güvenliği, sadece teknik ayarlar ve araçlarla sınırlı değildir; aynı zamanda geliştirme ekibinin benimsediği kültürel yaklaşımları da içerir. İşte 2026'da Git depolarınızı güvende tutmak için uygulanması gereken best practice'ler ve kaçınılması gereken anti-pattern'lar: * **✅ DOĞRU**: **Tüm Commit'leri İmzalayın.** * **Neden**: Commit'lerin kimliğini kriptografik olarak doğrular, geçmiş manipülasyonunu zorlaştırır ve sorumluluk sağlar. Git barındırma sağlayıcılarında "Verified" etiketi, güveni artırır. * **❌ YANLIŞ**: **Hassas Verileri (Secrets) Depoya Commit Edin.** * **Neden**: API anahtarları, şifreler gibi hassas verilerin depoya girmesi, ciddi güvenlik ihlallerine yol açar. Bir kez depoya girdiklerinde, geçmişten tamamen silmek çok zordur. * **✅ DOĞRU**: **Branch Koruma Kurallarını Uygulayın.** * **Neden**: `main` gibi kritik branch'lere doğrudan push yapılmasını engeller, kod incelemesini (PR/MR) zorunlu kılar ve CI/CD testlerinin geçmesini şart koşar. Bu, kod kalitesini ve güvenliğini artırır. * **❌ YANLIŞ**: **Zayıf veya Paylaşılan SSH Anahtarları/PAT'ler Kullanın.** * **Neden**: Güvenliği zayıf veya birden fazla kişi tarafından kullanılan kimlik doğrulama mekanizmaları, yetkisiz erişim riskini artırır. Her kullanıcının kendi güçlü ve benzersiz anahtarı olmalıdır. * **✅ DOĞRU**: **Pre-commit ve Pre-receive Hook'ları Kullanın.** * **Neden**: Hassas verilerin sızmasını engellemek, kod standartlarını zorunlu kılmak ve güvenlik açıklarını erken aşamada tespit etmek için otomatik kontroller sağlar. `pre-receive` hook'ları, yerel atlatmaları engeller. * **❌ YANLIŞ**: **`git pull --rebase` veya `git reset --hard` Komutlarını Bilinçsizce Kullanın.** * **Neden**: Bu komutlar Git geçmişini yeniden yazar veya yerel değişiklikleri geri alınamaz şekilde siler. Dikkatli kullanılmadığında veri kaybına veya yanlış geçmiş bilgisine yol açabilir. Özellikle paylaşılan branch'lerde `rebase` dikkatli olunmalıdır. * **✅ DOĞRU**: **`.gitignore` Dosyasını Doğru ve Kapsamlı Kullanın.** * **Neden**: Derleme çıktıları, `node_modules`, `.env` dosyaları gibi gereksiz veya hassas dosyaların depoya girmesini engeller. Bu, hem depo boyutunu küçük tutar hem de güvenlik risklerini azaltır. * **❌ YANLIŞ**: **Eski Git Sürümlerini Kullanmaya Devam Edin.** * **Neden**: Eski Git sürümleri, bilinen güvenlik açıklarına sahip olabilir. 2026'da en güncel kararlı sürümleri (örn. Git 2.46.0) kullanmak, bilinen zafiyetlere karşı korunmanızı sağlar. * **✅ DOĞRU**: **Düzenli Güvenlik Denetimleri ve Tarama Araçları Kullanın.** * **Neden**: Depolarınızda potansiyel güvenlik açıklarını, hassas veri sızıntılarını veya zafiyet içeren bağımlılıkları tespit etmek için otomatik araçlar (örn. `git-secrets`, SAST araçları) kullanın. * **❌ YANLIŞ**: **Uzun Ömürlü Feature Branch'ler Kullanın ve Sürekli Merge Yapmayın.** * **Neden**: Uzun ömürlü branch'ler, güvenlik yamalarının veya kritik güncellemelerin ana branch'e entegrasyonunu geciktirir. Sık ve küçük merge'ler, güvenlik açıklarını daha hızlı tespit etmeyi ve düzeltmeyi kolaylaştırır. ## Yaygın Git Güvenlik Açıkları ve Çözümleri Git'in kendisi oldukça güvenli bir sistem olmasına rağmen, yanlış kullanım veya hatalı yapılandırmalar güvenlik açıklarına yol açabilir. İşte 2026'da geliştiricilerin sıkça karşılaştığı Git güvenlik sorunları ve etkili çözümleri: ### 1. Hassas Verilerin Depoya Sızması (Hardcoded Secrets) * **Problem**: API anahtarları, veritabanı şifreleri, kimlik doğrulama token'ları gibi hassas bilgilerin doğrudan kod içine veya yapılandırma dosyalarına yazılıp Git deposuna commit edilmesi. * **Sebep**: Geliştiricinin farkındalık eksikliği, hızlı çözüm arayışı, yerel test ortamları için geçici çözümlerin unutulması. * **Çözüm**: * `git-secrets` gibi araçları `pre-commit` hook olarak kullanın. Bu araçlar, bilinen secret paternlerini tarayarak commit'leri engeller. * Hassas verileri ortam değişkenleri, Secret Management servisleri (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) veya `git-crypt` ile şifreleyerek yönetin. * `.gitignore` dosyasını `*.env`, `config.json` (hassas içerikli) gibi dosyaları içerecek şekilde doğru yapılandırın. ### 2. Yetkisiz Commit'ler ve Kimlik Sahtekarlığı * **Problem**: Bir saldırganın, başka bir geliştiricinin kimliğine bürünerek commit yapması veya geçmişi manipüle etmesi. * **Sebep**: Zayıf kimlik doğrulama (paylaşılan hesaplar), GPG imzalama zorunluluğunun olmaması, `user.email` ve `user.name` bilgilerinin doğrulanmaması. * **Çözüm**: * **GPG ile Commit İmzalama**: Tüm commit'lerin GPG anahtarları ile imzalanmasını zorunlu kılın. Git barındırma sağlayıcınızda GPG anahtarınızı kaydedin. * **Branch Koruma Kuralları**: `require_signed_commits` seçeneğini etkinleştirerek imzalanmamış commit'lerin kritik branch'lere merge edilmesini engelleyin. * **Güçlü Kimlik Doğrulama**: SSH anahtarları veya kişisel erişim token'ları kullanın ve bunları düzenli olarak denetleyin. ### 3. `git push --force` ile Geçmiş Manipülasyonu * **Problem**: Bir geliştiricinin `git push --force` komutunu kullanarak paylaşılan bir branch'in geçmişini yeniden yazması, bu da başkalarının çalışmalarını kaybetmesine veya denetlenebilirliği bozmasına neden olması. * **Sebep**: Hatalı `rebase` işlemleri, geçmişi temizleme isteği, yanlışlıkla yapılan işlemler. * **Çözüm**: * **Branch Koruma Kuralları**: Kritik branch'lerde `Allow force pushes` seçeneğini devre dışı bırakın. Bu, `git push --force` komutunun bu branch'lere uygulamasını engeller. * **Eğitim**: Ekip üyelerini `rebase` ve `force push` gibi komutların riskleri konusunda eğitin. Paylaşılan branch'lerde bu komutları kullanmaktan kaçınmaları gerektiğini vurgulayın. * **Denetim Logları**: Git barındırma platformunuzun denetim loglarını düzenli olarak inceleyerek `force push` gibi şüpheli aktiviteleri takip edin. ### 4. Büyük ve Hassas Olmayan Dosyaların Depoya Eklenmesi * **Problem**: Büyük ikili dosyaların (resimler, derlenmiş çıktılar) veya hassas olmasa da gereksiz dosyaların Git deposuna eklenmesi, depo boyutunu artırır ve klonlama süresini uzatır. Ayrıca, bu dosyalar yanlışlıkla hassas veri içerebilir. * **Sebep**: `.gitignore` dosyasının eksik veya hatalı yapılandırılması, Git LFS kullanımının bilinmemesi. * **Çözüm**: * **`.gitignore` Optimizasyonu**: Her projeye özel, kapsamlı bir `.gitignore` dosyası kullanın. `gitignore.io` gibi araçlardan faydalanın. * **Git LFS Kullanımı**: Büyük ikili dosyalar için Git LFS'yi benimseyin. Bu, depo boyutunu yönetilebilir tutar ve hassas olmayan büyük verileri Git geçmişinden ayırır. > **Stack Overflow Anketleri**: 2026 Stack Overflow geliştirici anketlerinde, "hardcoded secrets" ve "yanlışlıkla yapılan force push'lar" hala en çok karşılaşılan Git güvenlik sorunları arasında yer almaktadır. Bu sorunların çoğu, doğru araçların ve süreçlerin uygulanmasıyla kolayca önlenebilir. ## Git Audit ve İzleme ile Güvenlik Git güvenlik duruşunuzu sürekli olarak iyileştirmek için, depolarınızdaki aktiviteleri denetlemek ve izlemek hayati öneme sahiptir. 2026'da modern güvenlik yaklaşımları, proaktif izleme ve hızlı tepki mekanizmalarını gerektirir. Bu bölümde, Git depolarınızdaki güvenlik olaylarını nasıl izleyeceğinizi ve denetleyeceğinizi ele alacağız. ### 1. Git Barındırma Sağlayıcısı Denetim Logları GitHub, GitLab, Bitbucket gibi platformlar, repository'lerdeki tüm önemli eylemleri (push, pull request merge, branch koruma değişiklikleri, kullanıcı erişimleri) loglar. Bu loglar, güvenlik ihlallerini tespit etmek ve olay sonrası analiz yapmak için paha biçilmezdir. * **İzlenecek Önemli Olaylar**: * `git push --force` işlemleri. * Branch koruma kurallarının değiştirilmesi veya devre dışı bırakılması. * Yeni kullanıcıların veya botların depolara erişim kazanması. * Hassas depolara (private repositories) yetkisiz erişim denemeleri. * PAT'lerin oluşturulması veya silinmesi. * **Erişim ve Analiz**: Bu loglara genellikle platformun yönetim panelinden erişilir ve SIEM (Security Information and Event Management) sistemlerine entegre edilebilir. ### 2. Commit Geçmişi Analizi Git'in kendi `log` komutu, denetim için güçlü bir araçtır. Özellikle `git log --grep`, `git log --author`, `git log --since` gibi parametrelerle belirli commit'leri veya yazar aktivitelerini filtreleyebilirsiniz. * **Örnek: Belirli bir kelimeyi içeren commit'leri bulma** ```bash git log --grep="password" -p # "password" kelimesini içeren commit'leri ve değişikliklerini göster git log --author="bad_actor@example.com" --since="2026-01-01" # Belirli bir yazarın belirli tarihten sonraki commit'lerini göster ``` * **GPG İmza Doğrulama**: `git log --show-signature` komutu, commit'lerin GPG imzalarını ve doğrulama durumlarını gösterir. İmzalanmamış veya doğrulanamayan commit'ler güvenlik riski taşıyabilir. ### 3. Güvenlik Tarama Araçları Entegrasyonu CI/CD pipeline'larınıza güvenlik tarama araçları entegre etmek, kod tabanınızdaki zafiyetleri ve hassas veri sızıntılarını proaktif olarak tespit etmenizi sağlar. * **SAST (Static Application Security Testing) Araçları**: Kodu derlemeden veya çalıştırmadan güvenlik açıklarını tarar (örn. SonarQube, Bandit, Semgrep). ```yaml # GitLab CI/CD örneği: SAST taraması sast_job: stage: test image: docker:latest