Güvenli bir GitHub deposunun bakımını yapma
Burada, GitHub deposu yöneticilerinin kullanımına sunulan temel güvenlik araçları ve tekniklerinden bazılarını ele alacağız.
Not
Aşağıdaki içerik, güvenli kod yazmanın temellerini değil, gitHub deposunda kullanılacak önemli güvenlik konularını, araçları ve özellikleri kapsar.
Güvenli bir geliştirme stratejisinin önemi
Uygulama güvenliği önemlidir. Haber hizmetleri sıklıkla bir şirketin sistemlerinin ve çalınan özel şirket ve müşteri verilerinin ihlal edilmesiyle ilgili hikayeler taşır.
O halde güvenli bir geliştirme stratejisi planlarken üzerinde düşünülmesi gereken sorunlar nelerdir? Açıkçası, bilgileri erişimi olmaması gereken kişilere ifşa edilmekten korumamız gerekir, ancak daha da önemlisi, bilgilerin yalnızca uygun olduğunda değiştirildiğinden veya yok edildiğinden emin olmamız gerekir.
Verilere kimlerin eriştiğini doğru şekilde doğruladığımızdan ve bunu yapmak için doğru izinlere sahip olduklarından emin olmamız gerekir. Geçmiş veya arşiv verileri veya günlükler aracılığıyla bir sorun olduğunda kanıt bulabilmeliyiz.
Güvenli uygulamalar derlemenin ve dağıtmanın birçok unsuru vardır. Göz önünde bulundurulması gereken üç şey şudur:
Genel bir bilgi sorunu var: Birçok geliştirici ve diğer personel, güvenliği anladığını varsayar ancak anlamaz. Siber güvenlik, sürekli olarak gelişen bir disiplindir. Süreklilik gösteren bir eğitim ve öğrenim programı esastır.
Kodun doğru ve güvenli bir şekilde oluşturulması gerekir: Kodun doğru oluşturulduğundan ve gerekli özellikleri güvenli bir şekilde uyguladığından emin olmamız gerekir. Özelliklerin güvenlik göz önünde bulundurularak tasarlandığından da emin olmamız gerekir.
Uygulamaların kurallar ve düzenlemelere uyması gerekir: Kodun gerekli kural ve düzenlemelere uygun olduğundan emin olmamız gerekir. Kodu oluştururken uyumluluğu test edip dağıtımdan sonra bile düzenli aralıklarla yeniden test etmeliyiz.
Her adımda güvenlik
Güvenlik, bir uygulamaya veya sisteme daha sonra ekleyebileceğiniz bir şey değildir. Güvenli geliştirme, yazılım geliştirme yaşam döngüsünün her aşamasının bir parçası olmalıdır. Bu kavram, kritik uygulamalar ve hassas veya çok gizli bilgileri işleyen uygulamalar için daha da önemlidir.
Uygulamada, ekipleri geliştirdikleri işlemlerden sorumlu tutmak için geliştirme yaşam döngüsünde işlemlerin sola kayması veya daha önce tamamlanması gerekir. Son geçitteki adımları dağıtım zamanında daha erken bir adıma taşıyarak daha az hata yapılır ve geliştiriciler daha hızlı ilerleyebilir.
Uygulama güvenliği kavramları geçmişte geliştiriciler için bir odak noktası değildi. Eğitim ve öğretim sorunlarının dışında, kuruluşlarının özelliklerin hızlı geliştirilmesini vurguladığı içindir.
Ancak DevOps uygulamalarının kullanıma sunulmasıyla birlikte, güvenlik testlerinin işlem hattıyla tümleştirilmesi daha kolaydır. Güvenlik testi, güvenlik uzmanlarının gerçekleştirdiği bir görev olmak yerine, gündelik teslim süreçlerinin bir parçası olmalıdır.
Genel olarak, yeniden çalışma zamanı dikkate alındığında geliştirme yaşam döngüsünün önceki bölümlerinde DevOps uygulamalarınıza güvenlik eklenmesi, geliştirme ekiplerinin sorunları daha önce yakalamasına olanak tanır. Sorunları daha önce yakalamak, kaliteli yazılım geliştirmek için gereken genel süreyi azaltabilir.
Sola kaydırma bir işlem değişikliğidir, ancak tek bir denetim veya belirli bir araç değildir. Tüm güvenliğinizi geliştirici odaklı hale getirmek ve geliştiricilere bulundukları yerde güvenlik geri bildirimi vermekle ilgili.
Güvenlik sekmesi özellikleri
GitHub, depolarda ve kuruluşlarda verilerin güvenliğini sağlamaya yardımcı olan güvenlik özellikleri sunar. Güvenlik sekmesini bulmak için:
GitHub.com deponun ana sayfasına gidin.
Depo adının altında Güvenlik'i seçin.
Deponuzda ve kod tabanınızda güvenlik açıklarını önlemeye yardımcı olmak için Güvenlik sekmesinde GitHub iş akışınıza özellikler ekleyebilirsiniz. Bu özellikler şunları içerir:
- Deponuza dosya
SECURITY.mdekleyerek projenizdeki bir güvenlik açığının nasıl bildirileceğini belirtmenize olanak sağlayan güvenlik ilkeleri. - GitHub deponuzun savunmasız bir bağımlılık veya kötü amaçlı yazılım kullandığını algıladığında sizi bilgilendiren Dependabot uyarıları .
- Deponuzdaki güvenlik açıkları hakkındaki bilgileri özel olarak tartışmak, düzeltmek ve yayımlamak için kullanabileceğiniz güvenlik önerileri.
- Kodunuzdaki güvenlik açıklarını ve hataları bulmanıza, önceliklendirmenize ve düzeltmenize yardımcı olan kod taraması .
Daha fazla bilgi için bkz . GitHub güvenlik özellikleri.
Not
Kötü amaçlı yazılımlara yönelik Dependabot uyarı önerileri şu anda beta aşamasındadır ve değiştirilebilir. Yalnızca GitHub tarafından gözden geçirilmiş olan öneriler Dependabot uyarılarını tetikler.
Şimdi bu özelliklerden bazılarını keşfedecek ve yazılım geliştirme yaşam döngüsünün tüm aşamalarında güvenlik ve operasyonel sorumlulukları dağıtmanın yollarını öğreneceğiz.
güvenlik ilkesini SECURITY.md ile iletme
GitHub'ın topluluk avantajları önemli olsa da potansiyel riskler de taşır. Herkesin genel kullanıma açık şekilde hata düzeltmeleri önerebilmesi, belirli sorumlulukları beraberinde getirir. En önemlisi, bilgilerin sorumlu ifşasıdır; buna uyulmaması durumunda, temeldeki hataların düzeltilebilmesi için önce güvenlik ihlalleri oluşabilir. Güvenlik sorunlarını bildirmek veya ele almak isteyen geliştiriciler, endişelerini sorumlu şekilde göstermek için bir deponun kökünde SECURITY.md dosyasını arar. Bu dosyada rehberlik sağlamak, sonuçta bu kritik sorunların çözümünü hızlandırır.
SECURITY.md hakkında daha fazla bilgi edinmek için bkz. Deponuza güvenlik ilkesi ekleme.
GitHub Güvenlik Önerileri
GitHub Güvenlik Önerileri, depo bakımcıların bir projedeki güvenlik açığını özel olarak tartışmasına ve düzeltmesine olanak sağlar. Depo bakımcıları bir düzeltme üzerinde işbirliği yaptıktan sonra, güvenlik açığını projenin topluluğuna genel olarak açıklamak için güvenlik önerisini yayımlayabilir. Depo bakımcıları, güvenlik önerilerini yayımlayarak, topluluklarının paket bağımlılıklarını güncelleştirmesini ve güvenlik açıklarının sonuçlarını araştırmasını kolaylaştırır. GitHub yayımlanan önerileri Ortak Güvenlik Açıkları ve Etkilenmeler (CVE) listesinde depolar. Bu liste, listelenen bir güvenlik açığına sahip yazılımları kullanan etkilenen depoları otomatik olarak bilgilendirmek için kullanılır. Daha fazla bilgi için bkz . Depo güvenlik önerileri hakkında.
.gitignore ile hassas dosyaları deponuzdan uzak tutun
Bir işlemede yer alan dosyalar kolayca geliştiricilerin gözünden kaçabilir. Bazen gözden kaçırılan bu dosyalar, ara derleme dosyaları gibi zararsız olabilir. Ancak, birisinin istemeden hassas verileri işleme riski her zaman vardır. Örneğin, birisi kötü amaçlı bir aktörün kullanabileceği bir API anahtarı veya özel yapılandırma verileri işleyebilir. Bu riskten kaçınmaya yardımcı olan bir teknik, dosyaları oluşturmak ve korumaktır .gitignore . Bu dosyalar, git komut satırı yardımcı programı gibi istemci araçlarına, bir işleme için dosyalar toplanırken yolları ve desenleri yoksaymasını bildirir.
Aşağıdaki örnekte, dosyaları yoksaymak için yaygın kullanım örneklerinden bazıları gösterilmektedir:
# User-specific files - Ignore all files ending in ".suo"
*.suo
# Mono auto generated files - Ignore all files starting with "mono_crash."
mono_crash.*
# Build results - Ignore all files in these folders found at any folder depth
[Dd]ebug/
[Rr]elease/
x64/
x86/
# Root config folder - Ignore this directory at the root due to leading slash
# Removing the slash would ignore "config" directories at all depths
/config
# Ignore intermediate JS build files produced during TypeScript build at any
# folder depth under /Web/TypeScript. This won't ignore JS files elsewhere.
/Web/TypeScript/**/*.js
Deponuz birden çok .gitignore dosya içerebilir. Klasörleri ve alt klasörleri için üst ayarlardan öncelikli olan yeni .gitignore dosyalarındaki alanlar geçersiz kılınarak üst dizinlerden ayarlar devralınır. Kök .gitignore dosyayı korumak önemlidir, ancak proje dizinine dosya .gitignore eklemek, projenin üst öğeden ayrı olarak korunması daha kolay olan belirli gereksinimleri olduğunda (örneğin, yoksayılmaması gereken dosyalar) yararlı olabilir.
.gitignore hakkında daha fazla bilgi edinmek için bkz. Dosyaları yoksayma. Gitignore deposundaki çeşitli platformlar için sunulan başlangıç .gitignore dosyaları koleksiyonuna da göz atın.
Depodan hassas verileri kaldırma
.gitignore Dosyalar, katkıda bulunanların hassas verileri işlemekten kaçınmalarına yardımcı olmak için yararlı olsa da, yalnızca güçlü bir öneridir. Geliştiriciler yeterince motive olduklarında dosya eklemek için bu sorunu geçici olarak çözebilir ve bazen dosya yapılandırmasını karşılamadıkları .gitignore için dosyalar gözden kaçabilir. Proje katılımcıları her zaman depoya veya geçmişine dahil edilmemesi gereken verileri içeren işlemeleri arıyor olmalıdır.
Önemli
Herhangi bir noktada GitHub'a işlenen tüm verilerin gizliliğinin ihlal edildiğini varsaymalısınız. Bir işlemenin üzerine yazmak, verilerin gelecekte erişilebilir olmayacağından emin olmak için yeterli değildir. GitHub’dan hassas verileri kaldırmaya ilişkin eksiksiz bir rehber için bkz. Depodan hassas verileri kaldırma.
Dal koruma kuralları
Bir veya daha fazla dal için belirli iş akışlarını zorunlu kılmak için bir dal koruma kuralı oluşturabilirsiniz. Örneğin, korumalı dal ile birleştirilmiş tüm çekme istekleri için gözden geçirmeyi onaylama veya durum denetimlerini geçirmeyi zorunlu kılabilirsiniz.
Dalını koruyan iş akışlarını kullanarak aşağıdakileri yapabilirsiniz:
- Kod değişikliklerinin derlendiğini doğrulamak için derleme çalıştırma
- Yazım hatalarını ve iç kodlama kurallarına uyumluluğu denetlemek için bir linter çalıştırın
- Kodun davranış değişikliklerini denetlemek için otomatikleştirilmiş testler çalıştırma
- Vb.
CODEOWNERS dosyası ekleme
Deponuza bir CODEOWNERS dosyası ekleyerek, deponuzdaki yollara tek tek ekip üyelerini veya tüm ekipleri kod sahibi olarak atayabilirsiniz. Bu kod sahipleri daha sonra, yapılandırıldıkları bir yoldaki dosyalarda yapılan değişiklikler üzerinde çekme isteği gözden geçirmeleri için gereklidir.
# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js @js-owner
# Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocat
CODEOWNERS dosyasını deponun kökünde veya docs veya .github klasöründe oluşturabilirsiniz.